Brevet FR3045901A1 — publié le 20170623

TRAITEMENT DES TRANSACTIONS IMPLIQUANT L'ÉCHANGE D'UN BILLET ÉLECTRONIQUE CONTEXTE [0001] De façon générale, l'invention concerne des ordinateurs et des systèmes informatiques et en particulier, des méthodes, des systèmes, et des logiciels informatiques qui traitent des transactions impliquant des documents pouvant être échangés pour un service de voyage. [0002] Dans l'industrie du voyage, les documents pouvant être échangés pour des services de voyage (par exemple, des billets électroniques pour voyager en avion, en train, en bus, ou en bateau) peuvent être achetés indirectement à un commerçant, telle une agence de voyages, directement à un fournisseur de services de voyage, ou indirectement par l'intermédiaire d'autres commerçants. Typiquement, le commerçant va vérifier la disponibilité des vols ou autres services de voyage pour satisfaire le projet de voyage du voyageur, et une fois qu'un service correspondant est trouvé, il va réserver le service pour le voyageur et percevoir le paiement. Le paiement peut être perçu de plusieurs façons, notamment en débitant le compte d'une carte de crédit du voyageur, ou en utilisant des points de fidélité (par exemple, les Fréquent Flier Miles d'un programme de fidélité), en échangeant un bon d'achat, en recevant des devises de la part du voyageur, ou par toute autre forme appropriée de paiement. [0003] Dans certains cas, le voyageur peut souhaiter échanger un billet acheté pour obtenir un nouveau billet. Si le nouveau billet est plus cher que l'ancien billet, le voyageur sera normalement tenu de payer la différence. Le voyageur peut également être tenu de payer une pénalité, en fonction des contraintes imposées par le commerçant ou le fournisseur de services de voyage sur le rachat de l'ancien billet. Si le nouveau billet est moins cher que l'ancien billet, la différence peut être remboursée, minorée de toute pénalité. Des paiements supplémentaires peuvent être perçus de façon similaire à celle de l'achat du billet d'origine. Les remboursements peuvent être faits sous forme de crédit imputé à un ou plusieurs comptes, par l'émission d'un bon d'achat, par paiement en espèces directement au voyageur, ou par toute autre forme de paiement. [0004] Dans certains cas, les billets peuvent être échangés plusieurs fois, avec différents modes de paiements et de règles applicables à chaque transaction. Il en résulte que les déroulements historiques de transactions de billets peuvent être très complexes. Les formes de paiement utilisées pour acheter chaque ticket ainsi que les règles applicables à la vente du ticket pouvant avoir un impact sur le mode de remboursement du billet, il peut être difficile de déterminer le montant remboursable au voyageur, ainsi que les formes de paiement qui doivent être utilisées pour des billets dont le relevé 3045901 2 historique est complexe. En conséquence, un ou plusieurs voyageurs, le commerçant, une banque intermédiaire, ou le transporteur perçoivent un montant ou nne forme de paiement qui diffère de ce qu'ils auraient normalement dû percevoir. [0005] Ainsi, des systèmes, des méthodes, et des logiciels améliorés pour le traitement de transactions sont nécessaires pour améliorer la précision des échanges et des remboursements de billets. RÉSUMÉ [0006] Dans l'un des modes de réalisation de l'invention, un système pour traiter les demandes de transaction est fourni. Le système inclut un ou plusieurs processeurs et une mémoire couplée à un ou plusieurs processeurs. La mémoire stocke les données comprises dans une base de données et dans un programme codé qui, lorsqu'il est exécuté par un ou plusieurs processeurs, permet au système, en réponse à une demande de transaction pour un document, d'extraire de la base de données un relevé historique des transactions pour ledit document, comprenant une pluralité d'occurrences de paiement, chacune étant associée à une forme de paiement. Le système filtre la pluralité d'occurrences de paiement pour déterminer un ensemble d'occurrences de paiement associées avec des formes de paiement éligibles à un remboursement, et groupe les formes de paiement associées à l'ensemble d'occurrences de paiement afin de produire un ou plusieurs agrégats de formes de paiement. Le système classe ensuite le ou les agrégats de formes de paiement selon une hiérarchie de remboursements, sélectionne un agrégat de formes de paiement à partir d'un ou de plusieurs agrégats de formes de paiement selon le rang, et détermine un montant à rembourser pour l'agrégat de formes de paiement sur la base, au moins en partie, d'une valeur résiduelle du document. [0007] Dans un autre mode de réalisation de l'invention, une méthode de traitement d'une demande de transaction et fournie. La méthode inclut, en réponse à une demande de transaction, la récupération d'un relevé historique de transaction pour le document à partir de la base de données et le filtrage d'une pluralité d'occurrences de paiement afin de déterminer un ensemble d'occurrences de paiement associé avec des formes de paiement qui ne sont pas éligibles à un remboursement. La méthode inclut par ailleurs de grouper les formes de paiement associées avec l'ensemble des occurrences de paiement pour produire un ou plusieurs agrégats de formes de paiement, en classant une ou plusieurs formes de paiement sur la base d'une hiérarchie de remboursement, en sélectionnant ledit agrégat de formes de paiement d'une ou de plusieurs formes de paiement groupées selon le rang, et en déterminant le montant à rembourser dudit agrégat de formes de paiement sur la base, au moins en partie, de la valeur résiduelle du document. 3045901 3 [0008] Dans un autre mode de réalisation de l'invention, un logiciel informatique est fourni qui comprend un support de stockage non transitoire lisible par ordinateur comprenant un programme codé. Le programme codé est configuré de sorte que, lorsqu'il est exécuté par un ou plusieurs processeurs, il provoque la récupération à partir de la base de données d'un relevé historique de transactions pour le document par un ou plusieurs processeurs, en réponse à une demande de transaction. Le programme codé provoque par ailleurs le filtrage de la pluralité des occurrences de paiement afin de déterminer l'ensemble d'occurrences de paiement associées avec les formes de paiement qui ne sont pas éligibles à un remboursement, et l'agrégat des formes de paiement associées avec l'ensemble d'occurrences de paiement pour produire un ou plusieurs agrégats de formes de paiement, par un ou plusieurs processeurs. Le programme codé provoque par ailleurs, le classement d'un ou de plusieurs agrégats de formes de paiement selon une hiérarchie de remboursement en sélectionnant l'agrégat de formes de paiement à partir d'un ou de plusieurs agrégats de formes de paiement selon le rang, et la détermination d'un montant à rembourser l'agrégat de formes de paiement sur la base, au moins en partie, de la valeur résiduelle du document. BRÈVE DESCRIPTION DES DESSINS [0009] Les dessins accompagnant et 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 fournis ci-après, servent à expliquer les modes de réalisation de l'invention. [0010] FIG. 1 est une vue schématique d'un environnement d'exploitation exemplaire incluant un système de paiement en communication avec une base de données de transactions. [0011] FIG. 2 est une vue schématique d'un ordinateur exemplaire pour fournir un environnement d'exploitation de la FIG 1. [0012] FIG. 3 est une vue schématique du système de paiement représentant une forme de module de paiement et un module de règlement. [0013] FIG. 4 est une vue schématique d'une arborescence historique de transactions représentant des transactions impliquant l'échange de documents électroniques et des occurrences de paiement. [0014] FIG. 5 est une vue schématique d'un tableau du relevé historique d'un document et un tableau FOP qui peut être utilisé pour faire le suivi de documents électroniques et des occurrences de paiement de la FIG. 4. [0015] FIG. 6 est un organigramme illustrant un processus qui peut être exécuté par le système de paiement de la FIG. 1 pour traiter une demande de transaction. 3045901 4 [0016] FIG. 7 est une vue schématique d'une arborescence historique des transactions représentant des transactions impliquant l'échange de documents électroniques et des occurrences de paiement après le remboursement d'un billet. DESCRIPTION DÉTAILLÉE [0017] Les modes de réalisation de l'invention visent des systèmes, des méthodes et des logiciels informatiques pour gérer des transactions impliquant l'échange ou le remboursement d'un document électronique, tel qu'un billet. Le document peut avoir été émis par un voyageur dans le but d'obtenir un service lié à un voyage, tel qu'un vol, un repas, un hôtel, une voiture de location, ou tout autre service. Les modes de réalisation de l'invention peuvent être implémentés sur un système de traitement des transactions comprenant un ou plusieurs ordinateurs ou serveurs en réseau. Les ordinateurs en réseau peuvent inclure un système de paiement en communication avec une base de données de transactions, et peuvent fournir des fonctions de traitement et de base de données pour des systèmes relatifs aux voyages et des modules qui gèrent les transactions. [0018] Le système de paiement peut travailler en collaboration avec la base de données de transactions pour permettre un échange ou un remboursement du document qui a été échangé une ou plusieurs fois, dont chaque échange implique une ou plusieurs formes de paiement ou dont le relevé historique de transactions implique un ou plusieurs paiements non remboursables ou des documents non remboursables. La base de données de transactions peut permettre au système de paiement de prendre en compte les contraintes relatives au remboursement ou à l'échange de documents sur la base des types de documents compris dans le relevé historique de transactions et les formes de paiement utilisées pour le règlement des documents. La base de données de transactions peut aussi permettre au système de paiement d'appliquer les politiques spécifiques à un fournisseur de services de voyage, les contraintes associées à des formes de paiement, les contraintes basées sur les normes de l'industrie, et les contraintes basées sur le relevé historique du document. Les modes de réalisation de l'invention peuvent donc déterminer quelles sont les formes de paiement à rembourser et pour quels montants. Ces remboursements peuvent être exécutés automatiquement ou soumis à un utilisateur du système pour validation. La base de données de transactions peut aussi permettre aux systèmes de réservation de réserver et confirmer des services en échange de documents. Cette capacité à tarifer les échanges de documents et les remboursements offre la possibilité aux sites Web et autres interfaces de consommateurs de permettre aux voyageurs de réviser des voyages sans l'aide d'un agent de voyage. [0019] Faisant maintenant référence à la FIG. 1, un environnement d'exploitation 10 pour le système de traitement de transaction conformément à un mode de réalisation de l'invention peut inclure un système de distribution globale (GDS) 12, une base de données de fichiers de nom de passager (PNR) 13, un système de paiement 14, une base de données de transactions 15 ou plusieurs 3045901 systèmes de fournisseurs de voyage, comme le système du transporteur 16, une base de données de billets électroniques, ci-après « e-billets » 17, un ou plusieurs systèmes de commerçants indirects, comme un système de commerçant 18, un système de banque 20, et un système de voyageur 22. Chacun des systèmes et bases de données : GDS 12, base de données PNR 13, système de paiement 14, base de données de transactions 15, système transporteur 16, base de données e-billets 17, système commerçant 18, système banque 20 et système voyageur 22, peut communiquer par un réseau 24. Le réseau 24 peut inclure un ou plusieurs réseaux privés ou publics (par exemple, Internet) qui permettent l'échange de données. [0020] Le GDS 12 peut être configuré pour faciliter la communication entre le système du transporteur 16 et le système du commerçant 18 en permettant aux agents de voyage et au transporteur émetteur, ou autre vendeur indirect de confirmer des réservations sur le système du transporteur 16 par l'intermédiaire du GDS 12. Le GDS 12 peut maintenir des liens avec une pluralité de systèmes de transporteurs par l'intermédiaire du réseau 24 permettant au GDS 12 d'orienter les demandes de réservation vers un transporteur émetteur, ou une agence de voyages vers un transporteur de fait correspondant. Le système transporteur 16 et le système commerçant 18 peuvent donc confirmer des vols sur plusieurs compagnies aériennes grâce à une seule connexion au GDS 12. [0021] En réponse au voyageur qui réserve un service de voyage, le GDS 12 peut recevoir et stocker un fichier de nom de passager (PNR) dans la base de données PNR 13. Le PNR peut comprendre un ou plusieurs dossiers de réservation qui contiennent l'information relative à l'itinéraire et au voyageur, associée avec une ou plusieurs réservations confirmées. Chaque PNR peut inclure des données définissant un itinéraire pour un voyage particulier, un passager particulier, ou un groupe de passagers particuliers. L'itinéraire défini peut inclure les services de voyage de multiples fournisseurs de services de voyage. Pour faciliter la localisation du PNR dans la base de données PNR 13, un numéro de localisation ou autre identifiant approprié peut être associé au PNR. [0022] Le système de paiement 14 peut être configuré pour stocker et extraire des données décrivant des occurrences de paiement relatives aux transactions impliquant des services de voyage, tels que la vente d'un billet ou d'un vol. En réponse aux occurrences de paiement associées avec un document suivi (par exemple, le billet), un ou plusieurs des systèmes impliqués dans l'occurrence de paiement peut demander au système de paiement 14 des données historiques pour des occurrences antérieures de paiement relatives au document suivi. La demande peut inclure des données qui identifient le document suivi ainsi que des détails relatifs à l'occurrence de paiement actuelle. En réponse à la réception de la demande, le système de paiement 14 peut rechercher dans la base de données de transactions 15 des données relatives à des paiements antérieurs impliquant le document suivi, et transmettre les résultats de la recherche au système demandeur. Le système,de paiement 14 peut aussi recevoir des données relatives à une occurrence actuelle de paiement, et mettre à jour les 3045901 6 fichiers dans la base de données de transactions 15 pour documenter l'occurrence de paiement actuelle. [0023] Les occurrences de paiement relatives aux documents suivis peuvent être détectées par le système de paiement 14 sur la base de critères applicables aux occurrences de paiement. Lorsque, pour un document suivi, une occurrence de paiement répondant à ces critères est détectée, le système de paiement 14 peut communiquer à la base de données de transaction 15 qu'une nouvelle occurrence de paiement a été détectée pour ledit document suivi. Chaque transaction peut concerner l'achat ou l'échange d'un document et peut comprendre une ou plusieurs occurrences de paiement. Le montant total des occurrences de paiement associées à une transaction peut fournir un montant requis pour couvrir un paiement total pour la transaction. [0024] La base de données de transactions 15 peut stocker et gérer les données relatives aux transactions impliquant la vente, l'échange, et le remboursement de documents de service de voyage tel qu'un billet pour un vol. Ces données peuvent inclure des données définissant des achats, des prix, des formes de paiement, des pénalités, des valeurs résiduelles, des crédits, ou toute autre donnée définissant le relevé historique d'une transaction. Les données peuvent être stockées dans une pluralité de dossiers gérés par la base de données de transactions 15. La base de données de transactions 15 peut aussi inclure un ou plusieurs tableaux qui définissent les associations entre dossiers. Ces tableaux peuvent permettre à la base de données de transactions 15 de chercher et d'extraire des données relatives au relevé historique de transactions pour un document particulier, tel qu'un billet. [0025] Le système du transporteur 16 peut inclure un système de réservation informatique (CRS) qui permet au GDS 12 ou au système du commerçant 18 de réserver et de régler des services de voyage. Le système du transporteur 16 peut aussi communiquer par Internet avec d'autres systèmes de transporteurs (non représenté), soit directement, soit par l'intermédiaire du GDS 12, pour permettre à un transporteur émetteur de vendre des billets pour des sièges offerts par le transporteur de fait. Le transporteur de fait peut ensuite facturer le transporteur émetteur pour les services fournis. Le système du transporteur peut aussi inclure un moteur de tarification qui fixe des prix pour les- services de voyage. Le moteur de tarification peut déterminer le prix d'un service de voyage ainsi que les pénalités liées à l'échange du document sur la base de règles relatives à la tarification des services de voyage. [0026] Le système transporteur 16 peut aussi inclure un système de billetterie électronique (ETS) configuré pour conserver les dossiers relatifs à l'achat, l'utilisation et l'échange de documents émis par un transporteur correspondant. Dans ce but, PETS peut accéder à la base de données PNR 13 et/ou à la base de données e-billets 17 selon les besoins pour suivre l'état des documents émis par le transporteur. La définition et le suivi des données d'un document peuvent être stockés, au moins en partie, sous la forme d'un PNR dans la base de données PNR 13, et/ou sous la forme d'un ou de plusieurs documents dans la base de données e-billets 17. [0027] Le système commerçant 18 peut être configuré pour échanger des données avec le système 3045901 7 de paiement 14 et avec un ou plusieurs systèmes de banque tels que le système de banque 20, pour exécuter une transaction résultant en une occurrence de paiement. Dans le cas d'un achat réglé au moins en partie par carte de crédit ou de débit au moment de la transaction, le système du commerçant 18 peut transmettre une demande d'autorisation au système d'une banque émettrice. En réponse à la demande d'autorisation, le système de la banque émettrice peut vérifier la validité du compte associé à la carte de crédit et vérifier que les fonds disponibles sur le compte sont suffisants pour couvrir le montant de la transaction. Le système de la banque émettrice peut ensuite transmettre une réponse à la demande d'autorisation au système du commerçant 18 indiquant que la transaction a été approuvée, refusée ou que plus d'information est nécessaire. [0028] L'achat d'un service par l'intermédiaire du système du transporteur 16, du système du commerçant 18 ou tout autre système approprié, peut impliquer la tarification, la confirmation de la réservation, et les émissions du document. Par exemple, les services définis par les documents peuvent être tarifés par le bureau de billetterie avec l'aide du moteur de tarification. Le moteur de tarification peut déterminer un tarif pour le service en calculant le prix pour chacune ou plusieurs unités qui composent l'itinéraire du billet et en additionnant ces tarifs. Le document qui en résulte peut comprendre un ou plusieurs coupons électroniques stockés dans la base de données e-billets 17, chaque coupon correspondant à l'un des segments ou services du voyage. L'itinéraire du document peut définir les segments pour lesquels le document peut être utilisé pour obtenir une carte d'embarquement et/ou d'autres services qui composent le voyage. Chaque segment défini par l'itinéraire peut comprendre un ou plusieurs segments séquentiels, chaque segment connectant une station programmée de départ à une station programmée d'arrivée. [0029] La confirmation de la réservation peut inclure la vérification de la disponibilité du service dans l'inventaire du fournisseur, par exemple, la disponibilité des places sur les segments composant l'itinéraire. Cette vérification peut inclure l'envoi d'une demande de réservation du système du commerçant 18 au GDS 12. Le GDS 12 peut à son tour faire une requête au système du transporteur 16 correspondant pour vérifier la disponibilité des services définis par le document électronique. Si les services demandés sont disponibles, les services peuvent être réservés et confirmés, et l'inventaire du transporteur est réduit en fonction de ladite confirmation de réservation. En réponse à la demande de validation d'une transaction par le voyageur, le compte du voyageur peut être débité pour le prix des services. [0030] Une fois que la transaction est achevée, le système du commerçant 18 peut transmettre les données caractérisant la transaction au système de la banque acquéreur. Le système de la banque acquéreur peut ensuite verser les fonds sur un compte du commerçant, et recouvrer les fonds auprès des banques émettrices des cartes de crédit et de débit, ou par toute autre forme de paiement utilisée 3045901 8 pour l'achat de services de voyage. [0031] Le système voyageur 22 peut comporter un ordinateur de bureau, un ordinateur portable, une tablette, un téléphone, ou tout autre matériel informatique approprié. Le voyageur peut aussi utiliser le système voyageur 22 pour rechercher, réserver et confirmer des services de voyage en accédant au GDS 12, au système du transporteur 16, au système du commerçant 18, ou tout autre système approprié par l'intermédiaire du réseau 24. Par exemple, le voyageur peut lancer une application du navigateur et utiliser ladite application du navigateur pour rechercher des services de voyages sur un site Web fourni par un fournisseur ou par un revendeur de services de voyage. Le voyageur peut ensuite réserver et confirmer un service de voyage sélectionné en rentrant l'information de paiement sur le site Web. [0032] Nous faisons maintenant référence à la FIG. 2 ; le GDS 12, la base de données PNR 13, le système de paiement 14, la base de données de transactions 15, le système du transporteur 16, la base de données e-billets 17, le système du commerçant 18, le système de la banque 20, et le système voyageur 22 de l'environnement d'exploitation 10 peuvent être implémentés sur un ou plusieurs systèmes ou appareil 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 externes 42 par l'intermédiaire du réseau 24 ou de l'interface I/O 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 qui peut être utilisée avec l'ordinateur 30. [0033] Le processeur 32 peut inclure un ou plusieurs dispositifs sélectionnés tels que des microprocesseurs, microcontrôleurs, processeurs de signal numérique, micro-ordinateurs, unités centrales de traitement, réseaux de portes programmables, réseaux logiques programmables, machines à état défini, circuits logiques, circuits analogues, circuits numériques, ou tout autre dispositif servant à manipuler des signaux (analogues ou numériques) basés 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émé, 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, la mémoire vive statique (SRAM), la mémoire dynamique à accès aléatoire (DRAM), la mémoire flash, la mémoire cache, ou tout autre dispositif capable de stocker l'information. Le dispositif de mémoire de masse 36 peut inclure des dispositifs de stockage de données tels qu'un disqiie 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 l'information. 3045901 9 [0034] 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 forme d'un ou de plusieurs logiciels d'application, telle que l'application 46 qui réside dans la mémoire 34, puisse recevoir les instructions exécutées par le processeur 32. Dans un autre mode de réalisation de l'invention, le processeur 32 peut exécuter l'application 46 directement, et dans ce cas le système d'exploitation 44 peut être omis. 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. [0035] L'interface I/O 38 peut fournir une interface machine qui est couplée de façon fonctionnelle avec le processeur 32 à d'autres dispositifs et systèmes tels que le réseau 24 ou la ressource externe 42. L'application 46 peut donc collaborer avec le réseau 24 ou 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, ou modules composant les modes de réalisation de l'invention. L'application 46 peut .aussi disposer d'un programme codé qui est exécuté par une ou plusieurs ressources externes 42, ou autrement repose sur les fonctions ou signaux fournis par le système ou les composants réseau extérieurs à l'ordinateur 30. En effet, au vu des configurations presque infinies de matériel informatique et de logiciel possibles, les professionnels disposant de compétences ordinaires en la matière comprendront que les modes de réalisation de l'invention peuvent inclure des applications localisées extérieures à l'ordinateur 30, distribuées à des ordinateurs multiples ou à d'autres ressources externes 42, ou fournis par des ressources informatiques (matériel et logiciel) qui sont fournies par un service tel un service informatique Cloud, par l'intermédiaire du réseau 24. [0036] Le HMI 40 peut être couplé dans un mode fonctionnel avec le processeur 32 de l'ordinateur 30 d'une manière connue pour permettre à l'utilisateur d'interagir directement avec l'ordinateur 30. Le 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. Le 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. [0037] Une base de données 49 peut résider dans le dispositif de mémoire de masse 36 et peut être utilisée pour collecter et organiser les données utilisées par divers systèmes et modules décrits dans la présente demande. La base de données 49 peut inclure des structures de données adaptées qui stockent et organisent les données. En particulier, la base de données 49 peut être aménagée avec toute 3045901 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à. Un système de gestion de base de données, sous forme de logiciel informatique d'application qui s'exécute sous la forme d'instructions sur le processeur 32, peut être utilisé pour accéder à l'information ou aux données stockées dans des fichiers de la base de données 49 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 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, ou autre terminologie relative aux bases de données dans certains cas, hommes de métier comprendront 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. [0038] Lorsqu'un document ancien est présenté pour un remboursement ou un échange pour un nouveau document, la partie qui accepte l'ancien document peut avoir besoin de déterminer une valeur résiduelle pour l'ancien document et les formes de paiement (par exemple, espèces, remboursement sur un compte de carte de crédit, bon d'achat, système de paiement en ligne, points de fidélité, etc.) qui peuvent être utilisées pour restituer la valeur résiduelle au voyageur. Pour déterminer la valeur résiduelle et les formes acceptables de paiement, la partie qui accepte l'ancien document peut avoir besoin de connaître les formes de paiement utilisées pour l'achat de l'ancien document, de savoir si ces formes de paiement sont remboursables, et si l'ancien document a été émis dans le cadre d'un échange de documents antérieur. [0039] D'autres contraintes peuvent affecter la valeur résiduelle et les formes acceptables de paiement incluant les contraintes imposées sur les documents (par exemple, certains paiements tels que les pénalités, ne sont pas remboursables), les politiques du transporteur émetteur du document (par exemple, les remboursements par carte de crédit ont priorité sur les remboursements en espèces ; les paiements en points de fidélité ne peuvent pas être remboursés en espèces), les contraintes basées sur les types de formes de paiement (par exemple, un transfert de banque ne peut pas être remboursé automatiquement, les bons d'achat ne sont pas remboursables), les contraintes définies par les normes de l'industrie (par exemple, l'imposition d'un nombre maximum [par exemple, trois] de formes de paiement qui peuvent être utilisées pour rembourser un document), les contraintes basées sur le relevé historique de transactions du document (par exemple, les formes de paiement disponibles pour rembourser un document doivent avoir été utilisées pour payer le document qui est remboursé ou pour les documents qui ont été échangés contre le document en cours de remboursement). Les types de formes de paiement peuvent inclure, mais de façon non exhaustive, les espèces, les cartes de crédit, 3045901 11 les bons d'achat, et les points de fidélité (par exemple, les Frequent Flier Miles ou points de fidélité pour usage fréquent. [0040] Faisant maintenant référence à la FIG. 3, le système de paiement 14 peut inclure un module de formes de paiement 50 en communication avec un système d'utilisateur 51, un module de règlement 52 en communication avec le système de la banque 20 et un système de réservation informatique 53. Le système utilisateur 51 peut comporter par exemple, le système commerçant 18 si l'utilisateur est un agent de voyage, ou le système voyageur 22 si l'utilisateur est un voyageur. Le système de réservation informatique 53 peut être fourni par exemple, par le GDS 12 ou le système du transporteur 16. [0041] Pour échanger un document, l'utilisateur doit accéder au système de réservation informatique 53 à partir du système utilisateur 51. L'utilisateur peut ensuite ouvrir un écran de remboursement de documents et sélectionner les documents qu'il souhaite échanger ou se faire rembourser. Le système utilisateur 51 peut ensuite communiquer avec le module de formes de paiement 50 pour déterminer les formes de paiement qui sont éligibles au remboursement, et le montant qui peut être remboursé pour chaque forme de paiement éligible. En réponse à la confirmation de l'utilisateur pour le remboursement par le système de réservation informatique 53, le système de réservation informatique 53 peut transmettre une demande au module de règlement 52 pour rembourser les formes de paiement. Le module de règlement peut ensuite communiquer avec le système de la banque 20 pour implémenter le remboursement. Le système de paiement 14 peut ainsi fournir un lien entre les systèmes de banque et de réservation en stockant les données de réservations confirmées à partir du système de réservation informatique 53 dans la base de données de transactions 15, et traiter les données de réservation validées pour fournir à un ou à plusieurs systèmes de banques 20, du système utilisateur 51, ou du système de réservation informatique 53, les données de paiement et de remboursement. [0042] FIG. 4 représente une vue schématique d'une arborescence historique de transactions 54 comprenant une pluralité de transactions impliquant des documents suivis. La transaction 55 peut représenter l'achat d'un document d'origine pour un prix convenu, par exemple, $2000. En réponse au voyageur qui achète le document, l'ETS peut stocker un document 56 dans la base de données e-billets 17. Chaque transaction peut inclure une ou plusieurs occurrences de paiement. Par exemple, comme le montre la transaction 55, le paiement pour le document peut être effectué par de multiples occurrences de paiement 57 à 59. L'occurrence de paiement 57 peut correspondre au paiement d'une portion du prix du document en utilisant une forme de paiement, par exemple, un bon d'achat pour $400. L'occurrence de paiement 58 peut correspondre au paiement d'une autre portion du prix du document en utilisant une autre forme de paiement, par exemple, un paiement en espèces de $400. Et 3045901 12 encore une autre occurrence de paiement 59 peut correspondre au paiement de la dernière portion du prix du document en utilisant une autre forme de paiement, par exemple, un paiement de $1200 en utilisant la carte de crédit A. [0043] La transaction 60 peut représenter un échange du document 56 contre un nouveau document, ce qui peut amener l'ETS à stocker le document 62 dans la base de données e-billet 17. Le nouveau document 62 peut avoir un prix différent (par exemple, $1200) du prix du document 56 en cours de remboursement. Par exemple, comme le montre la transaction 60, le nouveau document 62 peut être moins coûteux que l'ancien document 56. Si le nouveau document 62 est moins coûteux que l'ancien document 56, une valeur résiduelle du document 64 peut être générée dans la base de données e-billet 17. La valeur résiduelle du document 64 peut refléter le montant de la différence (par exemple, $400) entre le prix de l'ancien document 56 et le prix du nouveau document 62. La valeur résiduelle du document 64 peut être équilibrée par une occurrence de paiement 66 qui rembourse le montant résiduel sur la carte de crédit A. Le voyageur peut aussi être pénalisé pour l'échange du document. Si le voyageur est pénalisé, l'ETS peut stocker un document de pénalité 68 reflétant le coût de la pénalité dans la base de données e-billets 17. La pénalité peut ensuite être réglée en utilisant une forme de paiement appropriée, par exemple, un paiement en espèces de $50, qui va générer ensuite une autre occurrence de paiement 70. [0044] La transaction 72 peut représenter un autre échange de documents. Par exemple, le voyageur peut décider de passer à une classe supérieure, ou d'ajouter une destination, et d'échanger le document 62 en sa possession contre un nouveau document plus coûteux 74. L'échange d'un document pour un autre document plus coûteux peut déclencher des occurrences de paiement supplémentaires afin de couvrir la différence (par exemple, $800) entre l'ancien document 62 et le nouveau document 74. Par exemple, l'occurrence de paiement 76 peut correspondre au paiement du voyageur pour une portion de la différence en utilisant une forme de paiement, par exemple, un paiement de $300 en utilisant la carte de crédit A. Une occurrence de paiement 78 peut correspondre au paiement effectué par un voyageur pour une autre portion de la différence en utilisant une autre forme de paiement, par exemple un paiement de $500 en utilisant une carte de crédit B. [0045] Le voyageur peut aussi être pénalisé à nouveau, déclenchant ainsi l'émission d'un document de pénalité 80 pour le montant de la pénalité, par exemple, $50. L'émission d'un document de pénalité 80 peut donner lieu à des occurrences de paiement supplémentaires pour couvrir la pénalité, telle qu'une occurrence de paiement 82 correspondant au paiement d'une portion de la pénalité en utilisant une forme de paiement (par exemple, une charge de $40 sur la carte de crédit B), et une occurrence de paiement 84 correspondant au paiement d'une autre portion de la pénalité en utilisant une autre forme de paiement (par exemple, un paiement de $10 en utilisant un bon d'achat). [0046] Si le voyageur demande un remboursement pour un document, le commerçant aura besoin 3045901 13 de déterminer une valeur résiduelle du document et comment la valeur résiduelle doit être restituée au voyageur. Cette valeur peut dépendre à la fois du relevé historique de transactions du document en cours de remboursement, et des politiques du commerçant. Par exemple, le commerçant peut avoir des politiques qui interdisent le remboursement de documents de pénalités, interdisent le remboursement de paiement fait à l'aide d'un bon d'achat, et/ou donnent priorité aux remboursements effectués sur un compte de carte plutôt qu'à un remboursement en espèces. [0047] Nous faisons maintenant référence à la FIG. 5, pour faciliter le suivi du document, la base de données de transactions 15 peut inclure un document sous forme de tableau historique 90 et un tableau de formes de paiement (FOP) 92. Le document sous forme de tableau historique 90 peut stocker des données définissant les relations entre documents émis et documents échangés. Par exemple, quand un ou plusieurs documents précédemment achetés sont échangés contre un ou plusieurs nouveaux documents, le document sous forme de tableau 90 peut définir les documents antérieurs comme «parents » des nouveaux documents. En tout cas, le nombre de documents échangés peut être différent du nombre de nouveaux documents. Par exemple, une pluralité de documents peut être échangée contre une pluralité de nouveaux documents, ou un document peut être échangé pour une pluralité de nouveaux documents. Des informations supplémentaires stockées par le document sous forme de tableau historique 90 peuvent inclure un type de document (par exemple, un billet électronique ou divers documents électroniques (EMD), et un sous-type de document (par exemple, une valeur résiduelle ou une pénalité). Le tableau FOP 92 peut maintenir les le déroulement historique des paiements pour chaque document. Dans ce but, pour chaque occurrence de paiement, le tableau FOP 92 peut stocker un fichier d'identifiant de paiement, l'identifiant du document associé à l'occurrence de paiement (c'est-à-dire, le document de référence), le type de paiement (émission ou remboursement), la forme de paiement utilisée, et le montant du paiement correspondant. [0048] Dans un mode de réalisation exemplaire de l'invention, le document sous forme de tableau historique 90 peut inclure une colonne 94 pour stocker un identifiant de document pour le document suivi, une colonne 96 pour stocker les données définissant le type de document pour le document suivi, une colonne 98 pour stocker l'identifiant de document d'un document parent du document suivi, et une colonne 100 pour stocker les données définissant les sous-types de documents pour le document suivi. Le tableau FOP 92 peut inclure une colonne 102 pour stocker un identifiant d'occurrence de paiement pour l'occurrence de document suivi, une colonne 106 pour stocker les données définissant le type de transaction associée avec l'occurrence. de paiement suivi, une colonne 108 pour stocker les données définissant la forme de paiement associée avec l'occurrence de paiement suivi, et une colonne 110 pour stocker les données définissant le montant du paiement associé avec la forme de paiement. Chacune des colonnes dans les tableaux peut être utilisée pour stocker des données, définissant les informations correspondantes, ou un code pour localiser un dossier, un identifiant, ou 3045901 14 tout autre signe pouvant être utilisé pour identifier des fichiers de la base de données contenant l'information correspondante. [0049] Lorsqu'un document est émis, le document peut recevoir un identifiant unique et être stocké sous forme de fichier dans la base de données e-billets 17. Pour suivre ledit document, la base de données de transactions 15 peut ajouter un ou plusieurs rangs au document sous forme de tableau historique 90, et un ou plusieurs rangs au tableau FOP 92, selon qu'une occurrence de paiement est associée avec le document, ou non. En se servant des transactions exemplaires illustrées dans la FIG. 3 pour démontrer le fonctionnement du document sous forme de tableau historique 90 et le tableau FOP 92, la colonne 94 du rang 112 dans le document sous forme de tableau historique 90 peut stocker un identifiant unique (par exemple, T-001) pour les documents 56. L'identifiant unique peut comporter par exemple, un code de localisation de fichiers qui identifient un fichier dans la base de données e-billets 17 où le document 56 est stocké. La colonne 96 du rang 112 peut stocker des données définissant le type de document (par exemple, un billet), la colonne 98 du rang 112 peut stocker des données identifiant un document parent, le cas échéant, et la colonne 100 du rang 112 peut stocker des données définissant le sous-type de document, le cas échéant. [0050] Pour la transaction exemplaire 55, puisque le document 56 a été acheté sans échange d'un autre document, l'identifiant unique dans la colonne 94 du rang 112 peut être le même que l'identifiant unique dans la colonne 98 du rang 112. Dans d'autres modes de réalisation de l'invention, la colonne 98 du rang 112 peut rester vide si le document n'a pas de parent. La colonne 98 du rang 112 peut aussi être peuplée avec des données indiquant que le document identifié dans la colonne 94 n'a pas de parent. En tout cas, une personne ayant des compétences ordinaires en la matière comprendrait que la syntaxe et la configuration du document sous forme de tableau historique 90 et du tableau FOP 92 illustrés dans la FIG. 4, sont présentées à titre d'exemples uniquement, et que les modes de réalisation de l'invention ne sont pas limités à la configuration ou à la syntaxe montrée. [0051] La base de données de transactions 15 peut commencer le processus d'enregistrement d'une occurrence de- paiement 59 en attribuant un numéro d'occurrence de paiement (par exemple, PEI-001) à l'occurrence de paiement 59. Le numéro d'occurrence de paiement peut ensuite être stocké dans la colonne 102 sur un nouveau rang défini 114 du tableau FOP 92. La base de données de transaction 15 peut donc associer des données du rang 114 du tableau FOP 92 avec l'occurrence de paiement suivi 59 identifiée par un identifiant d'occurrence de paiement PEI-001. Des données supplémentaires stockées au rang 114 peuvent inclure un identifiant de document pour les documents associés avec l'occurrence de paiement suivi dans la colonne 104, des données définissant le type de transaction dans la colonne 106 (par exemple, émission d'un document), des données définissant la forme de paiement associée avec l'occurrence de paiement suivi 59 dans la colonne 108 (par exemple, carte de crédit A), et des données définissant un montant de paiement associé avec la forme de 3045901 paiement dans la colonne 110 (par exemple, $1200). Dans l'exemple présent, afin de documenter chacune des trois formes de paiement utilisées pour régler le document 56, le tableau FOP 92 peut inclure, en plus du rang 114, un rang 116 pour documenter l'occurrence de paiement 57, et un rang 118 pour documenter une occurrence de paiement 58. [0052] En réponse à la détection d'une occurrence de transaction 60, le système de paiement 14 peut déclencher l'ajout de rangs 120, 122 et 124, au document sous forme de tableau historique 90, et l'ajout de rangs 126 et 128, au tableau FOP 92, par la base de données de transactions 15. La colonne 94 du rang 120 peut stocker un identifiant de document (par exemple, T-002) qui identifie le document 62 dans la base de données e-billets 17, une colonne 96 du rang 120 peut stocker les données indiquant que le document identifié est un billet, et la colonne 98 du rang 120 peut stocker l'identifiant de document T-001 pour indiquer que le document 56 est le parent du document 62. [0053] La colonne 94 du rang 122 peut stocker un identifiant de document (par exemple, R-001) qui identifie la valeur résiduelle du document 64 dans la base de données e-billets 17, la colonne 96 du rang 122 peut stocker des données indiquant que le document R-001 est un EMD, la colonne 98 du rang 122 peut stocker l'identifiant de document T-001 pour indiquer que le document 56 est le parent de la valeur résiduelle du document 64, et la colonne 100 du rang 122 peut stocker des données définissant les sous-types de documents comme « valeur résiduelle ». [0054] La colonne 94 du rang 124 peut stocker un identifiant de document P-001 qui identifie le document de pénalité 68 dans la base de données e-billets 17, la colonne 96 du rang 124 peut stocker des données indiquant que le document de pénalité 68 est un EMD, la colonne 98 du rang 122 peut stocker l'identifiant de document T-001 pour indiquer que le document 56 est le parent du document de pénalité 68, et la colonne 100 du rang 124 peut stocker des données définissant le sous-type de document de pénalité 68 comme une « pénalité d'échange ». [0055] Dans le tableau FOP 92, la colonne 102 du rang 126 peut stocker un identifiant de document PEI-004 identifiant l'occurrence de paiement 66, la colonne 104 du rang 126 peut stocker l'identifiant de document R-001 identifiant la valeur résiduelle du document 64 dans la base de données e-billets 17, la colonne 106 du rang 126 peut stocker des données définissant le type de transaction (par exemple, un remboursement), la colonne 108 peut stocker des données définissant la forme de paiement pour le remboursement (par exemple, carte de crédit A), et la colonne 110 du rang 126 peut stocker des données définissant le montant du remboursement (par exemple, $400). [0056]. La colonne 102 du rang 128 peut stocker un identifiant d'occurrence de paiement PEI-005 identifiant une occurrence de paiement 70, la colonne 104 du rang 126 peut stocker un identifiant de document P-001 identifiant le document de pénalité 68 dans la base de données e-billets 17, la colonne 106 du rang 128 peut stocker des données définissant le type de transaction (par exemple, une émission), la colonne 108 du rang 128 peut stocker des données définissant la forme de paiement pour 3045901 16 le remboursement (par exemple, espèces), et la colonne 110 du rang 128 peut stocker des données définissant le montant du remboursement (par exemple, $50). [0057] En réponse à la détection d'une occurrence de transaction 72, le système de paiement 14 peut déclencher l'ajout de rangs 130 et 132, au document sous forme de tableau 90 et des fangs 134, 136, 138 et 140 au tableau FOP 92 par la base de données de transactions 15. La colonne 94 du rang 130 peut stocker un identifiant de document T-003 qui identifie le document 74 dans la base de données e-billets 17, une colonne 96 du rang 130 peut stocker des données indiquant que le document T-003 est un billet, et la colonne 98 du rang 130 peut stocker l'identifiant de document T002 pour indiquer que le document 62 est le parent du document 74. [0058] La colonne 94 du rang 132 peut stocker un identifiant de document P-002 qui identifie le document de pénalité 80 dans la base de données e-billets 17, la colonne 96 du rang 132 peut stocker des données indiquant que les documents P-002 est un EMD, la colonne 98 du rang 132 peut stocker l'identifiant de document T-002 pour indiquer que le document 62 est aussi le parent du document de pénalité de 80, et la colonne 100 du rang 132 peut stocker des données définissant le sous type du document de pénalité 80. [0059] Dans le tableau FOP 92, la colonne 102 du rang 134 peut stocker l'identifiant de document PEI-006 identifiant l'occurrence de paiement 76, la colonne 104 du rang 134 peut stocker l'identifiant de document T-003 identifiant le document 74 dans la base de données e-ticket 17, la colonne 106 du rang 134 peut stocker des données définissant le type de transaction (par exemple, une émission), la colonne 108 du rang 134 peut stocker des données définissant la forme de paiement (par exemple, carte de crédit A), et la colonne 110 du rang 134 peut stocker des données définissant le montant du paiement (par exemple, $300). [0060] La colonne 102 du rang 136 peut stocker identifiant d'une occurrence de paiement PEI- 007 identifiant l'occurrence de paiement 78, la colonne 104 du rang 136 peut stocker l'identifiant de document T-003 identifiant les documents 74 dans la base de données e-billets 17, la colonne 106 du rang 136 peut stocker des données définissant le type de transaction (par exemple, une émission) la colonne 108 du rang 136 peut stocker des données définissant la forme de paiement (par exemple, carte de crédit B), et la colonne 110 du rang 136 peut stocker des données définissant le montant du paiement (par exemple, $500). [0061] La colonne 102 du rang 138 peut stocker identifiant d'une occurrence de paiement PEI- 008 identifiant l'occurrence de paiement 82, la colonne 104 du rang 138 peut stocker l'identifiant de document P-002 identifiant le document de pénalité 80 dans la base de données e-billets 17, la colonne 106 du rang 138 peut stocker des données définissant le type de transaction (par exemple, une émission), la colonne 108 du rang 138 peut stocker des données définissant la forme de paiement (par exemple, carte de crédit B), et la colonne 110 du rang 138 peut stocker des données définissant le 3045901 17 montant du paiement (par exemple, $40). [0062] La colonne 102 du rang 140 peut stocker identifiant d'une occurrence de paiement PEI- 009 identifiant l'occurrence de paiement 84, la colonne 104 de la ligne 140 peut stocker l'identifiant du document de pénalité 80 dans la base de données e-billets 17, la colonne 106 du rang 140 peut stocker des données définissant le type de transaction (par exemple, une émission), la colonne 108 du rang 140 peut stocker des données définissant la forme de paiement (par exemple, bon d'achat), et la colonne 110 du rang 140 peut stocker des données définissant le montant du paiement (par exemple, $10). [0063] Faisant maintenant référence à la FIG. 6, un organigramme illustrant un processus 150 qui peut être exécuté par le système de paiement 14 en réponse à la réception d'une demande de transaction telle qu'une demande de remboursement ou d'échange de document. Le processus 150 peut déterminer une valeur résiduelle pour un document échangé ou remboursé et peut déterminer comment la valeur résiduelle devrait être répartie entre les formes de paiement disponibles. Le processus peut commencer par la récupération du relevé historique de transactions pour le document en cours de remboursement. Le relevé historique de transaction peut ensuite être utilisé pour déterminer les montants et les formes de paiement qui sont éligibles pour rembourser le document. Une fois que ces formes de paiement sont définies, le système de paiement peut distribuer les remboursements en utilisant les formes éligibles de paiement. [0064] Dans le bloc 152, le processus 150 peut retrait de l'historique de transactions de la base de données de transactions 15 pour le document en cours de remboursement ou d'échange. La base de données de transactions 15 peut, grâce à un identifiant du document en cours de remboursement, identifier des documents supplémentaires associés au document en cours de remboursement en utilisant le document sous forme de tableau 90. La base de données de transactions 15 peut ensuite, sur la base des identifiants des documents associés, identifier les occurrences de paiement en utilisant le tableau FOP 92. Le système de paiement 14 peut ensuite assembler les documents liés et les occurrences de paiement dans une arborescence historique de transactions montrant les relations entre et les occurrences de paiement associées avec chaque document. Les formes de paiement pour chaque document dans l'arborescence historique de transactions peuvent ensuite être filtrées et groupées, et les agrégats de formes de paiement qui en résultent peuvent être utilisés pour rembourser le document. [0065] Afin d'extraire le relevé historique de transactions, le système de paiement 14 peut transmettre une requête à la base de données de transactions 15. La requête peut inclure un ou plusieurs identifiants qui peuvent être utilisés pour identifier des fichiers liés au relevé historique de transaction du document. Un de ces identifiants peut être l'identifiant de document du document pour lequel la recherche de données historiques est effectuée. En réponse à la réception de la requête, la base de données de transactions 15 peut utiliser les identifiants pour chercher des documents liés et des 3045901 18 occurrences de paiement incluses dans le relevé historique de transactions du document. La base de données de transactions 15 peut ensuite transmettre une réponse au système de paiement incluant les résultats de recherche. [0066] En réponse à la réception d'un relevé historique de transaction de la base de données de transactions 15, le processus 150 peut procéder au bloc 154 et filtrer les occurrences de paiement composant le relevé historique de transactions. Ce filtrage peut être basé sur le type de document et sur la forme de paiement associé avec l'occurrence de paiement. À cette fin, le processus 150 peut extraire chaque forme de paiement des occurrences de paiement dans les résultats de recherche. Le processus 150 peut ensuite filtrer les formes de paiement extraites en appliquant les politiques du commerçant pour définir un ensemble d'occurrences de paiement qui est associé avec les formes de paiement éligibles au remboursement. Par exemple, un commerçant peut avoir des politiques qui interdisent le remboursement de paiement fait pour régler des documents de pénalité ou des montants de paiement couverts par des bons d'achat. L'application des politiques du commerçant aux formes de paiement extraites peut avoir comme conséquence l'élimination de toute occurrence de paiement correspondant à une forme de paiement inéligible (par exemple, un bon d'achat), ainsi que toute occurrence de paiement associée à un document inéligible (par exemple, une pénalité) quelle que soit la forme de paiement. [0067] Les politiques du commerçant peuvent aussi déterminer comment la valeur résiduelle est distribuée au voyageur sur la base des formes de paiement. Par exemple, le processus 150 peut donner priorité aux remboursements sur un compte de carte de crédit plutôt qu'aux paiements en espèces au voyageur. L'application de cette politique exemplaire attribuant une priorité au paiement par carte de crédit, plutôt qu'en espèces, aux formes de paiement filtrées dans le tableau 2 peut entraîner le remboursement de la valeur résiduelle 64 sur la carte de crédit A, plutôt qu'un paiement en espèces au voyageur. [0068] Une fois que les formes de paiement ont été extraites et filtrées, le processus 150 peut avancer au bloc 156. Dans le bloc 156, le processus 150 peut ensemble les formes de paiement. L'agrégat peut comporter l'addition des montants de paiement pour chaque occurrence de paiement dans le relevé historique impliquant la même forme de paiement dans un montant total pour l'agrégat de formes de paiement. Certaines des occurrences de paiement qui sont additionnées peuvent avoir une valeur négative (par exemple, une occurrence de paiement générée parle remboursement ou l'échange d'un document), dans ce cas la somme reflétera la valeur négative comme une réduction du montant total pour l'agrégat de formes de paiement. [0069] Le processus 150 peut ensuite avancer au bloc 158 et ranger les agrégats de formes de paiement selon une hiérarchie de remboursement définie par les politiques du commerçant. Par exemple, les paiements par carte de crédit peuvent être classés au-dessus des paiements en espèces 3045901 19 afin que les documents de valeur résiduelle soient équilibrés par le remboursement sur un compte de carte de crédit correspondant avant de distribuer tout paiement en espèces au voyageur. Les formes de paiement de même type (par exemple, la carte de crédit) issu de sources différentes (par exemple, différentes banques émettrices) peuvent être classées les unes par rapport aux autres en fonction d'un critère de classement secondaire défini par le commerçant. Les exemples de critères de classement secondaires peuvent inclure le montant de l'agrégat de la forme de paiement, la date d'échéance d'un paiement, un horodatage, l'identité de la banque émettrice de la carte de crédit, les taux d'intérêt, ou tout autre critère approprié. [0070] Une fois que les formes de paiement ont été groupées et classées, le processus 150 peut avancer au bloc 160. Dans le bloc 160, le processus peut répartir tout remboursement, dû au voyageur, aux formes de paiement. La distribution peut commencer avec l'agrégation de formes de paiement classé au plus haut rang. Lorsque la forme de paiement au plus haut rang est épuisée avant que la valeur résiduelle de l'occurrence de transaction soit complètement équilibrée, le processus 150 peut continuer en cascade selon la hiérarchie des agrégats de formes de paiement dans l'ensemble de formes de paiements. Ce processus peut continuer jusqu'au remboursement complet de la valeur résiduelle restante, ou jusqu'à ce qu'il n'y ait plus de forme de paiement éligible existante. Dans un autre mode de réalisation de l'invention, le processus 150 peut proposer un remboursement complet, ou partiel, de la valeur résiduelle sous la forme d'un bon d'achat avant d'affecter toute portion de la valeur résiduelle à l'une des formes de paiement. Dans tous les cas, en réponse à l'affectation de la valeur résiduelle, le processus peut ensuite avancer au bloc 162 et mettre à jour la base de données de transactions en permettant à la base de données de transactions 15 d'associer toute nouvelle occurrence de paiement avec les documents suivis correspondants. [0071] Par exemple, le processus 150 peut être déclenché par la transaction exemplaire 60 illustrée dans la FIG. 4, qui implique que le voyageur échange le document 56 contre le document 62. Au moment de la transaction 60, le relevé historique de transactions peut inclure les occurrences de paiement 57 à 59 de la transaction 55. Ces occurrences de paiement peuvent être extraites du relevé historique de transactions comme l'illustre le tableau 1. TABLEAU 1- OCCURRENCES DE PAIEMENT EXTRAITES Montant Document Occurrence de Forme de paiement 57 Bon d'achat $400 Billet 56 58 Espèces $400 Billet 56 59 Carte de crédit A $1200 Billet 56 [0072] Le filtrage des formes de paiement dans le tableau 1 qui consiste à appliquer les politiques du commerçant peut éliminer une ou plusieurs occurrences de paiement dues à une violation d'une 3045901 restriction de la forme de paiement ou du type de document permis. Par exemple, un événement de paiement 57 peut être inéligible à un remboursement en raison de la forme de paiement qui est un bon d'achat. Le filtrage des occurrences de paiement 57 à 59 qui consiste à appliquer les politiques du commerçant peut donc supprimer la prise en compte de l'occurrence de paiement 57, et produire en résultat les occurrences de paiement du tableau 2. [0073] Dans les cas comme celui qui est illustré par le tableau 2 où il n'y a qu'une seule occurrence de paiement pour chacune des formes restantes de paiement, l'étape d'agrégation des formes de paiement peut conduire à ce que le contenu des occurrences de paiement filtrées reste inchangé. Ainsi, si chaque forme de paiement dans l'ensemble des occurrences de paiement filtrées est associée avec ne pas réussir à modifier l'ensemble d'occurrences de paiement filtrées. [0074] Le classement des occurrences de paiement groupées conformément aux politiques exemplaires du commerçant décrites ci-dessus peut ordonner les agrégats de formes de paiement et classer les paiements par cartes de crédit au-dessus des paiements en espèces comme le montre le tableau 3. TABLEAU 3 - AGGRÉGATS CLASSÉS DE FORMES DE PAIEMENT Forme de paiement Montant Carte de crédit A $1200 Espèces $400 [0075] Le processus 150 peut d'abord tenter d'équilibrer les documents de valeur résiduelle en utilisant la forme de paiement classée au plus haut rang, par exemple, la carte de crédit A. La valeur résiduelle du document 64 de l'exemple présent pouvant être équilibrée par un remboursement d'une valeur moindre que le montant de la forme de paiement placé au plus haut rang, le processus peut équilibrer le document de valeur résiduelle 64 en remboursant ce montant (par exemple, 400 $) en utilisant la forme de paiement classée au plus haut rang (par exemple, la carte de crédit A). Peur documenter le relevé historique de la transaction 60, le processus peut mettre à jour la base de données de transactions 15 en stockant les fichiers qui définissent chacune des occurrences de paiement du TABLEAU 2 - OCCURRENCES DE PAIEMENT FILTRÉES Occurrence de Forme de piment Montant Document 58 Espèces $400 Billet 56 59 Carte de crédit A $1200 Billet 56 3045901 21 remboursement 66 et l'occurrence d'un paiement de pénalité 70. [0076] L'application du processus 150 au remboursement du document 74, à l'ensemble des occurrences de paiement extraites du relevé historique de transactions, peut être illustrée par le tableau 4. L'ensemble d'occurrences de paiement extrait, illustré dans le tableau 4 peut inclure les occurrences de paiement du tableau -1 ainsi que les occurrences de paiement supplémentaires survenant dans la transaction 60 et la transaction 72. C'est-à-dire que le relevé historique de transactions stockées dans la base de données de transaction 15 peut être cumulatif. TABLEAU 4 - OCCURRENCES Occurrence de paiement DE PAIEMENT EXTRAITES Montant Document Forme de paiement 57 Bon d'achat $400 Billet 56 58 Espèces $400 Billet 56 59 Carte de crédit A $1200 Billet 56 66 Carte de crédit A - $400 Valeur résiduelle 64 70 Espèces $50 Pénalité 68 76 Carte de crédit A $300 Billet 74 78 Carte de crédit B $500 Billet 74 82 Carte de crédit B $40 Pénalité 80 84 Bon d'achat $10 Pénalité 80 [0077] Le filtrage d'un ensemble d'occurrences de paiement extraites dans le tableau 4 permettant de supprimer les formes de paiement non remboursables et les types de documents non remboursables, peut produire un ensemble d'occurrences de paiement éligibles au remboursement comme l'illustre le tableau 5. TABLEAU 5 - OCCURRENCES DE PAIEMENT ÉLIGIBLES AU REMBOURSEMENT Montant Document Occurrence de Forme de paiement 58 Espèces $400 Billet 56 59 Carte de crédit A $1200 Billet 56 66 Carte de crédit A -$400 Valeur résiduelle 64 76 Carte de crédit A $300 Billet 74 78 Carte de crédit B $500 Billet 74 [0078] L'agrégation de formes de paiement dans un ensemble d'occurrences de paiement éligibles au remboursement dans le tableau 5 peut inclure l'addition des montants éligibles au remboursement, associés avec la carte de crédit A ($1,200 + $300 -$400), ce qui produit un montant total éligible à un remboursement de $1100 pour cette forme de paiement. Les agrégats de formes de paiement peuvent 3045901 22 ensuite être classés sur la base de critères principaux (par exemple, le type de forme de paiement, comme les cartes de crédit qui sont classées à un rang supérieur aux paiements en espèces) et des critères secondaires (par exemple, le montant total éligible au remboursement) pour produire un ensemble de formes de paiement éligibles au remboursement. Un ensemble exemplaire d'agrégats de formes de paiement est illustré dans le tableau 6. TABLEAU 6 - AGGRÉGATS CLASSÉS DE FORMES Forme de paiement DE PAIEMENT CLASSÉS Montant Carte de crédit A $1 100 Carte de crédit B $500 Espèces $400 [0079] Le processus peut ensuite affecter les fonds remboursés aux formes de paiement éligibles au remboursement selon leur ordre de classement jusqu'à atteindre le montant résiduel. Dans l'exemple présent, le remboursement sur le compte associé avec la forme de paiement classée au plus haut rang avec le montant disponible - $1,100= $1,300 Lorsque le montant disponible pour l'agrégat de formes de paiement classées au plus haut rang est insuffisant pour couvrir le prix du document, le processus 150 peut sélectionner l'agrégat de formes de paiement suivant dans la hiérarchie (par exemple, la carte de crédit B), et affecter le montant disponible au montant résiduel du prix du document 74. Dans l'exemple présent, le montant du remboursement éligible disponible pour l'agrégat de formes de paiement classé immédiatement après (par exemple, la carte de crédit B) est moindre que le montant non remboursé du document 74, donc le montant entier est crédité, ce qui laisse un montant résiduel non remboursé de : $1,300 $ -$500 = $800. [0080] Le processus qui consiste à sélectionner la forme de paiement suivante dans l'ordre hiérarchique et à affecter le montant disponible du prix du document peut continuer jusqu'à ce que tous les montants disponibles soient épuisés, ou jusqu'à ce que le prix total du document soit remboursé. Dans l'exemple présent, le processus 150 peut affecter la forme de paiement disponible suivante (par exemple, espèces) au solde non remboursé du document 74. Ce qui peut laisser un solde non remboursé de : $800 - $400 = $400, pouvant représenter un montant non restituable parce que les formes de paiement éligibles sont épuisées. [0081] Dans un mode de réalisation de l'invention, il peut y avoir un nombre maximum N de formes de paiement qui soient en mesure d'accepter des remboursements pour un seul document. Dans ce cas, il peut être nécessaire de rembourser un montant plus élevé que le montant groupé d'une des formes de paiement. Par exemple, dans un mode de réalisation de l'invention, une demande pour un remboursement peut produire un document de valeur résiduelle ayant une valeur de $300. Si les trois 3045901 23 premières formes de paiement dans l'exemple : la carte de crédit A, la carte de crédit B et la carte de crédit C ont des valeurs groupées de $100, $50, est $80 respectivement, et que le commerçant a comme règle : N= 3, et si les règles étaient strictement appliquées, le remboursement total serait réduit de $70. Dans ce cas, le système de paiement 14 peut simplement ajouter $70 de plus à la forme de paiement ayant le rang de priorité le plus bas, et dans ce cas le montant remboursé sur la carte de crédit C, serait de : $80 + $70 = $150. Dans un autre mode de réalisation de l'invention, plutôt que d'augmenter le montant remboursé pour une des formes de paiement, le système de paiement peut remplacer la troisième forme de paiement avec une autre forme de paiement, telle qu'un bon d'achat e-banque pour le montant du remboursement restant, par exemple, $150. [0082] Nous faisons maintenant référence à la FIG. 7 ; ayant épuisé toute forme de paiement éligible, le processus 150 peut enregistrer une occurrence de transaction 164 en stockant un document de valeur résiduelle 166 dans la base de données de transactions 15. Le système de paiement 14 peut aussi stocker des occurrences de paiement 168, 170 et 172 dans la base de données de transaction 15 pour documenter comment le montant résiduel du document a été affecté aux formes de paiement. [0083] Le système de paiement 14 peut être utilisé par un voyageur ou un commerçant tel qu'un agent de voyage, pour déterminer le montant de remboursement et les documents d'échange. Un autre utilisateur potentiel peut inclure un tiers à la transaction, tel qu'un fournisseur de services de paiement. Les fournisseurs de services de paiement peuvent inclure des sociétés, telles que des institutions financières, qui sont responsables de l'intégrité des fonds disponibles pour une forme de paiement donnée appartenant au client. Par exemple, la banque émettrice d'une carte de crédit peut être tenue pour responsable de la mauvaise utilisation de la carte de crédit et peut approuver ou refuser de débiter le compte afin de prévenir un abus. [0084] 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 lisibles par ordinateur qui résident à divers moments dans divers dispositifs de mémoire et de stockage dans un ordinateur, et qui lorsqu'il est lu et exécuté par un ou plusieurs processeurs dans un ordinateur, provoque l'exécution par l'ordinateur d'opérations et/ou d'éléments propres aux aspects variés des modes de réalisation de l'invention. Les instructions d'un programme informatique lisible par ordinateur pour effectuer les opérations des 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. [0085] Divers programmes codés décrits dans les présentes peuvent être identifiés selon 3045901 24 l'application dans laquelle ils sont implémentés dans des modes de réalisation de l'invention spécifiques. Cependant, il faut prendre conscience 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 sur un ordinateur typique (par exemple, les systèmes d'exploitation, les bibliothèques, les APIs, les applications, les applets, etc.), il faut prendre conscience 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. [[0086] Le programme codé mis en oeuvre dans toute application ou module décrit dans les présentes peut-être distribué individuellement ou collectivement comme un produit de programme dans une variété de formes. En particulier, le programme codé peut être distribué en utilisant un médium de stockage lisible par ordinateur disposant d'instructions de programme lisible par ordinateur en lui-même permettant à un processeur d'effectuer des aspects des modes de réalisation de l'invention. [0087] Les supports de stockage déchiffrables par machine étant 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 d'information telle 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 lisibles par ordinateur peuvent aussi comprendre des mémoireS RAM, ROM, EPROM (mémoire à lecture exclusivement, 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, ou tout autre médium pouvant être utilisé pour stocker l'information désirée, et apte à être lue par un ordinateur. Un support de stockage lisible par ordinateur ne peut être interprété comme « des signaux transitoires » en soi (par exemple, des ondes radio ou 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 machine 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. [0088] Les instructions de programme lisibles par ordinateur, stockées dans un support lisible par 3045901 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 lisible par ordinateur, produisent un article de fabrication comprenant les instructions qui implémentent les fonctions, les actions et/ou les opérations spécifiées dans les organigrammes, diagrammes de séquence, et/ou diagrammes blocs. Les instructions de programme informatique peuvent être fournies à 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, telles 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. [0089] Dans certains autres modes de réalisation, les fonctions, les actes et/ou des opérations spécifiées dans les organigrammes, diagrammes de séquence, et/ou des 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 tout en restant conformes avec les modes de réalisation de l'invention. [0090] 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 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 », « comporte » « 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 ». [0091] 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 3045901 concept inventif général de l'appliquant. REVENDICATIONS1. Une méthode de traitement d'une demande de transaction pour un premier document, la méthode comprenant : - en réponse à la réception d'une demande de transaction, la récupération à l'aide d'un ordinateur d'un re,levé historique de transactions pour le premier document à partir d'une base de données, le relevé historique de transactions comprenant une pluralité d'occurrences de paiement, chacune étant associée avec une forme de paiement ; - le filtrage à l'aide d'un ordinateur de la pluralité d'occurrences de paiement pour déterminer un ensemble d'occurrences de paiement associées avec des formes de paiement qui sont éligibles à un remboursement ; - l'agrégation à l'aide de l'ordinateur des formes de paiement associées avec l'ensemble des occurrences de paiement pour produire un ou plusieurs agrégats de formes de paiement ; - le classement par l'ordinateur d'un ou de plusieurs agrégats de formes de paiement selon une hiérarchie de remboursement ; - la sélection d'un premier agrégat de formes de paiement à partir d'un ou de plusieurs agrégats de formes de paiement selon le rang ; et - la détermination par l'ordinateur d'un premier montant de remboursement pour le premier agrégat de formes de paiement reposant, au moins en partie, sur une valeur résiduelle du premier document. 2. La méthode selon la revendication 1, dans laquelle chaque forme de paiement est d'un type respectif. 3. La méthode selon la revendication 2, dans laquelle le type respectif de chaque forme de paiement est un type de carte de crédit, de bon d'achat, d'espèce, ou de points de fidélité. 4. La méthode selon la revendication 2 ou la revendication 3, dans laquelle chacun d'un ou de plusieurs agrégats de formes de paiement représente un montant respectif, et un ou plusieurs agrégats de formes de paiement sont classés selon, au moins ou en partie, le type respectif ou le montant respectif. 3045901 28 5. La méthode selon toute revendication 2 à 4, dans laquelle le filtrage d'une pluralité d'occurrences de paiement pour déterminer l'ensemble d'occurrences de paiement associées avec les formes de paiement qui sont éligibles à un remboursement, comprend : - l'enlèvement au moins d'une occurrence de paiement sur la base du type respectif ou de la forme de paiement associée. 6. La méthode selon toute revendication 1 à 5, dans laquelle chacune des pluralités d'occurrences de paiement est associée avec un document ayant un type respectif, et les occurrences de paiement sont filtrées pour déterminer l'ensemble d'occurrences de paiement associées aux formes de paiement qui sont éligibles au remboursement sur la base, au moins ou en partie, d'un type respectif de document associé avec chaque occurrence de paiement. 7. La méthode selon toute revendication 2 à 6, dans laquelle chaque occurrence de paiement comporte un deuxième montant pour la forme de paiement associée, la méthode comprenant par ailleurs : - pour chaque type respectif de forme de paiement associée, l'addition des seconds montants pour produire un agrégat de formes de paiement du type respectif. 8. La méthode selon toute revendication 1 à 7, dans laquelle le premier document fait partie d'une pluralité de documents connexes, et chaque occurrence de paiement est associée avec l'une des pluralités de documents connexes. 9. La méthode selon toute revendication 1 à 8, dans laquelle le premier agrégat de formes de paiement est d'un troisième montant, et la valeur résiduelle est d'un quatrième montant, incluant par ailleurs : - le remboursement du troisième montant pour le-premier agrégat de formes de paiement lorsque le troisième montant est moindre que le quatrième montant ; et - la sélection d'un second agrégat de formes de paiement parmi un ou plusieurs agrégats de formes de paiement selon un rang ; et - la détermination d'un cinquième montant à rembourser pour le second agrégat de formes. 4e paiement sur la base, au moins en partie, d'une valeur résiduelle restante pour le premier document. 10. La méthode selon la revendication 9, dans laquelle le premier agrégat de formes de paiement est 3045901 29 classé au plus haut rang, et le second agrégat de formes de paiement est au rang suivant dans la hiérarchie des agrégats de formes de paiement. 11 La méthode selon toute revendication 1 à 10, dans laquelle la pluralité des occurrences de paiement inclut une première occurrence de paiement associée avec le premier document et une seconde occurrence de paiement associée avec un second document qui a été échangé contre le premier document. 12. La méthode selon toute revendication 1 à 10, dans laquelle la demande de transaction est pour l'échange du premier document contre un second document, et comprenant par ailleurs : - le stockage d'une nouvelle occurrence de paiement dans la base de données, la nouvelle occurrence de paiement ayant une valeur égale au premier montant ; et - l'association d'une nouvelle occurrence de paiement avec le second document dans un premier tableau de la base de données. 13. Un système pour le traitement de demandes de transaction, le système comportant - un ou plusieurs processeurs et - une mémoire couplée avec un ou plusieurs processeurs, la mémoire stockant des données comportant un programme codé qui, lorsqu'il est exécuté par un plusieurs processeurs, provoque une série d'actions, notamment: - la récupération d'un relevé historique de transaction pour le premier document à partir de la base de données en réponse à la réception d'une demande de transaction pour un premier document, le relevé historique de transaction comprenant une pluralité d'occurrences de paiement, chacune étant associée avec une forme de paiement ; - le filtrage de la pluralité des occurrences de paiement pour déterminer un ensemble d'occurrences de paiement associées avec des formes de paiement qui sont éligibles à un remboursement ; l'agrégation des formes de paiement associées avec l'ensemble d'occurrences de paiements pour produire un ou plusieurs agrégats de formes de paiement ; le classement d'un ou de plusieurs agrégats de formes de paiement sur la base d'une hiérarchie de remboursement ; - la sélection d'un premier agrégat de formes de paiement à partir d'un ou de plusieurs agrégats de formes de paiement selon le rang ; et - la détermination d'un premier montant à rembourser au premier agrégat de formes de paiement sur la base au moins empartie d'une valeur résiduelle du premier document. 3045901 30 14. Le système selon la revendication 1, dans lequel le programme codé déclenche le système qui va exécuter la méthode selon toute revendication 2 à 12. 15. Un programme informatique pour traiter des demandes de transactions qui, lorsqu'elles sont exécutées par un ou plusieurs processeurs, déclenche : - la récupération d'un relevé historique de transactions pour les documents à partir d'une base de données en réponse à la réception d'une demande de transaction pour un document, ledit relevé historique de transactions comprenant une pluralité d'occurrences de paiement, chacune étant associée avec une forme de paiement ; - le filtrage de la pluralité des occurrences de paiement pour déterminer un ensemble d'occurrences de paiement associées avec des formes de paiement qui sont éligibles à un remboursement ; - l'agrégation des formes de paiement associées avec l'ensemble d'occurrences de paiements pour produire un ou plusieurs agrégats de formes de paiement ; - le classement d'un ou de plusieurs agrégats de formes de paiement selon une hiérarchie de remboursement ; - la sélection d'un agrégat de formes de paiement d'un ou de plusieurs agrégats de formes de paiement selon le rang ; et - la détermination d'un montant à rembourser pour l'agrégat de formes de paiement en fonction, au moins en partie, d'une valeur résiduelle du document.