FR 3070212 A1 20190222 FR 1757716 A 20170817 GÉNÉRATION DE DEMANDES POUR INVERSER DES PAIEMENTS PARTIELLEMENT VALIDÉS DOMAINE TECHNIQUE [0001] De façon générale, l'invention concerne des ordinateurs et des logiciels et en particulier des procédés, des systèmes et des systèmes de produits-programmes d'ordinateur qui génèrent des demandes de retour arrière pour inverser des paiements partiellement validés. CONTEXTE [0002] La technologie informatique est de plus en plus utilisée dans l'industrie du voyage pour gérer, prendre en charge, réserver, finaliser des réservations et traiter des réservations de voyage ainsi que les données qui leur sont associées. Un aspect de ces systèmes concerne l'achat et l'émission de réservations de voyage diverses. Par exemple, un voyageur peut acheter une place d'avion en utilisant une forme de paiement particulière. La forme de paiement peut, par exemple, être une carte de crédit, une carte de débit, des points sur un compte de fidélité, un portefeuille numérique, une autre méthode de paiement tel qu'un système de paiement en ligne. [0003] Parfois une réservation de voyage peut être payée en utilisant une forme de paiement unique. En utilisant cette approche, le prix entier de la réservation est payé en utilisant une seule forme de paiement. Autrement, un voyageur peut payer une réservation de voyage en utilisant de multiples formes de paiement. Spécifiquement, chaque forme de paiement peut être utilisée pour payer une portion du prix total de la réservation de voyage. Par exemple, un voyageur peut payer un billet d'avion en utilisant une combinaison de points de fidélité sur un compte et de multiples cartes de crédit. Cependant, dans certaines situations lorsque deux ou plusieurs formes de paiement sont utilisées pour payer une réservation, au moins une transaction concernant l'une des formes de paiement échoue. La forme de paiement peut échouer pour diverses raisons différentes. Par exemple, la forme de paiement peut échouer en raison de l'insuffisance de fonds sur le compte en banque si une carte de débit est utilisée. La forme de paiement peut aussi échouer s'il y a des problèmes de connexion au réseau pour vérifier le paiement. [0004] Même si une seule forme de paiement échoue, c'est alors l'ensemble de la transaction de paiement qui est considéré comme incomplet. Par conséquent, la réservation de voyage ne sera pas finalisée même si le voyageur a déjà payé une portion du prix d'achat. Par exemple, le voyageur peut payer une portion d'un billet d'avion en utilisant les points de fidélité sur son 2 dompte. Cependant, la carte de crédit utilisée pour la portion restante du prix d'achat du billet d'avion est refusée. Ainsi, même si le voyageur a payé une portion du billet d'avion en utilisant ses points de fidélité, la réservation du billet d'avion n'est pas finalisée. [0005] Si une réservation de voyage n'est pas finalisée parce qu'une ou plusieurs formes de 5 paiement ont échoué, un représentant de voyage peut alors avoir besoin de résoudre la transaction de paiement. Ceci peut s'avérer particulièrement difficile pour l'agent de voyage ou un représentant de déterminer pourquoi une transaction particulière a échoué, car un paiement est habituellement traité via de multiples chaînes. Par exemple, une transaction de carte de crédit peut impliquer un payeur, une banque émettrice, un fournisseur de paiements et un acquéreur. 10 [0006] Par conséquent, des procédés, des systèmes et des produits-programmes d'ordinateur pour améliorer la finalisation d'une réservation de produits et de services sont nécessaires. RÉSUMÉ [0007] Dans un mode de réalisation de l'invention, un système est fourni pour générer une demande de retour arrière. Le système reçoit une information indiquant une première forme de 15 paiement, une première transaction pour la première forme de paiement, l'information indiquant une seconde forme de paiement et une seconde transaction pour la seconde forme de paiement qui sont collectivement utilisées pour acheter un produit ou un service. Le système envoie une première demande d'autorisation de la première transaction pour la première forme de paiement à un premier système d'un fournisseur de paiements. Le système reçoit un avis d'approbation 20 indiquant que la première demande a été approuvée par le premier système d'un fournisseur de paiements. Le système envoie une seconde demande d'autorisation de la seconde transaction pour la seconde forme de paiement à un second système d'un fournisseur de paiements. Le système détecte un échec de la seconde demande. En réponse à la détection d'un échec de la seconde demande, le système détermine si la première forme de paiement peut être inversée ou 25 remboursée sur la base de règles commerciales. En réponse à la détermination que la première forme de paiement pour la première transaction peut être inversée ou remboursée, le système envoie une première demande de retour arrière au premier système d'un fournisseur de paiements avec des instructions pour inverser ou rembourser la première transaction. 3 [0008] Dans un mode de réalisation, le système inclut un code de programme qui, lorsqu'il est exécuté par ledit ou plusieurs processeurs, amène par ailleurs le système à recevoir une information indiquant une troisième forme de paiement et une troisième transaction pour la troisième forme de paiement utilisée pour l'achat du produit ou du service. Le système est par 5 ailleurs amené à envoyer à un troisième système d'un fournisseur de paiements une troisième demande d'autorisation de la troisième transaction pour la troisième forme de paiement. Le système reçoit également une notification d'approbation indiquant que la troisième demande a été validée par le troisième système d'un fournisseur de paiements. [0009] Dans un autre mode de réalisation, le système inclut le code de programme qui, 10 lorsqu'il est exécuté par ledit ou plusieurs processeurs, amène par ailleurs le système à envoyer une seconde demande de retour arrière au troisième fournisseur de paiements avec des instructions pour inverser ou rembourser la troisième transaction. La première demande de retour arrière et la seconde demande de retour arrière surviennent de façon asynchrone l'une par rapport àl'autre. 15 [0010] Dans un autre mode de réalisation, la première demande de retour arrière et la seconde demande de retour arrière sont placées dans une file d'attente de traitement et la première demande de retour arrière est retirée de la file d'attente de traitement après réception d'une notification d'inversion ou d'une notification de remboursement. [0011] Dans un autre mode de réalisation, une notification de remboursement n'est pas reçue 20 en réponse à la première demande de retour arrière dans un laps de temps prédéterminé et le code de programme amène par ailleurs le système à envoyer périodiquement un nombre prédéterminé de demandes secondaires pour inverser ou rembourser la première transaction au premier fournisseur de paiements à intervalles de temps prédéterminés. [0012] Dans un mode de réalisation, le système inclut un code de programme qui, lorsqu'il 25 est exécuté par ledit ou plusieurs processeurs, amène par ailleurs le système à placer la première transaction dans une file d'attente d'exception de dépassement de délai en réponse au nombre prédéterminé de demandes secondaires n'ayant pas abouti à la réception de la notification d'inversion ou de remboursement. [0013] Dans un autre mode de réalisation, les instructions pour la première demande de 30 retour arrière incluent une instruction pour inverser la première transaction. 4 [0014] Dans un autre mode de réalisation, les instructions pour la première demande de retour arrière incluent une instruction pour rembourser la première transaction. [0015] Dans un autre mode de réalisation, le système inclut un code de programme qui, lorsqu'il est exécuté par ledit ou plusieurs processeurs, amène par ailleurs le système à recevoir 5 une notification d'échec de la part du second fournisseur de paiements indiquant que la seconde demande a été refusée par le second fournisseur de paiements. [0016] Dans un autre mode de réalisation, un procédé est fourni pour générer une demande de retour arrière. Le procédé inclut la réception, via un ordinateur, d'une information indiquant une première forme de paiement et une première transaction pour la première forme de paiement, 10 l'information indiquant une seconde forme de paiement et une seconde transaction pour la seconde forme de paiement qui sont collectivement utilisées pour acheter un produit ou un service. Le procédé inclut par ailleurs l'envoi, via l'ordinateur, d'une première demande d'autorisation de la première transaction pour la première forme de paiement à un premier système d'un fournisseur de paiements. Le procédé inclut aussi la réception d'une notification 15 d'approbation indiquant que la première demande a été validée par le premier système d'un fournisseur de paiements. Le procédé inclut l'envoi, via l'ordinateur, d'une seconde demande d'autorisation de la seconde transaction pour la seconde forme de paiement à un second système d'un fournisseur de paiements. Le procédé inclut également la détection d'un échec de la seconde demande. En réponse à la détection d'un échec de la seconde demande, le procédé détermine, via 20 l'ordinateur, si la première forme de paiement peut être inversée ou remboursée sur la base de règles commerciales. En réponse à la détermination que la première forme de paiement pour la première transaction peut être inversée ou remboursée, le procédé inclut l'envoi d'une première demande de retour arrière, via l'ordinateur, au premier système d'un fournisseur de paiements avec des instructions pour inverser ou rembourser la première transaction. 25 [0017] Dans un autre mode de réalisation de l'invention, un produit-programme d'ordinateur est fourni pour sélectionner un fichier de voyage associé à un profil d'utilisateur, le produit-programme d'ordinateur comprenant un support de stockage non transitoire lisible par ordinateur et un code de programme stocké sur le support de stockage non transitoire lisible par ordinateur qui, lorsqu'il est exécuté par un ou plusieurs processeurs, amène ledit ou plusieurs processeurs à 30 recevoir une information indiquant une première forme de paiement et une première transaction 5 pour la première forme de paiement, l'information indiquant une seconde forme de paiement et une seconde transaction pour la seconde forme de paiement qui sont collectivement utilisées pour acheter un produit ou un service. Le processeur envoie une première demande d'autorisation de la première transaction pour la première forme de paiement à un premier système fournisseur de 5 paiements. Le processeur reçoit une notification d'approbation indiquant que la première demande a été validée par le premier système d'un fournisseur de paiements. Le processeur envoie une seconde demande d'autorisation de la seconde transaction pour la seconde forme de paiement à un second système fournisseur de paiements. Le processeur détecte un échec de la seconde demande. En réponse à la détection d'un échec de la seconde demande, le processeur 10 détermine si la première forme de paiement peut être inversée ou remboursée sur la base de règles commerciales. En réponse à la détermination que la première transaction avec la première forme de paiement peut être inversée ou remboursée, le processeur envoie une première demande de retour arrière au premier fournisseur de paiements avec des instructions pour inverser ou rembourser la première transaction. 15 [0018] Les divers modes de réalisation de l'invention peuvent accroître l'efficacité du traitement des données par des dispositifs informatiques et peuvent aussi améliorer la technologie relative à l'informatique en facilitant la performance informatique d'une fonction qui auparavant ne pouvait pas être effectuée par un ordinateur. [0019] Le résumé ci-dessus est bref et simplifié pour permettre une compréhension basique 20 de certains aspects des systèmes et/ou procédés détaillés dans les présentes. Ce résumé n'est pas un aperçu extensif des systèmes et/ou procédés détaillés dans les présentes. Il ne prétend, ni identifier des éléments clés ou décisifs, ni définir la portée de tels systèmes et/ou procédés. Son seul but est de présenter certains concepts de façon simplifiée en préface à la description plus détaillée qui est exposée par la suite. 25 BRÈVE DESCRIPTION DES DESSINS [0020] Les dessins, qui ont partie intégrante des spécifications, 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. Dans les dessins, des références à des chiffres similaires sont utilisées pour indiquer 30 des éléments similaires dans les diverses visualisations. 6 [0021] FIG. 1 est une vue schématique d'un environnement d'exploitation exemplaire incluant un système de vendeur, un serveur de paiements, et au moins un fournisseur de paiements pour générer une demande de retour arrière qui inverse une forme de paiement validée. [0022] FIG. 2 est une vue schématique d'un système informatique exemplaire de la FIG. 1. 5 [0023] FIG. 3 est une vue schématique du système d'un vendeur, du serveur de paiements et des fournisseurs de paiements représentés dans la FIG. 1. [0024] FIG. 4 est un organigramme qui peut être exécuté par le serveur de paiements de la FIG. 3 pour générer une demande de retour arrière qui inverse une forme de paiement validée. DESCRIPTION DÉTAILLÉE 10 [0025] Faisant maintenant référence à la FIG.!, un environnement d'exploitation 10 conforme à un mode de réalisation de l'invention peut inclure un système de vendeur 14, un serveur de paiements 16 et au moins un fournisseur de paiements 18A-18N. Le serveur de paiements16 est en communication avec le système de vendeur 14, les fournisseurs de paiement 18 et une base de données 20 pour stocker une ou plusieurs règles commerciales. 15 Chacun des systèmes de vendeurs 14, le serveur de paiements 16, les fournisseurs de paiements 18 et la base de données 20 peuvent communiquer via un réseau 26. Le réseau 26 peut inclure un ou plusieurs réseaux privés ou publics (p. ex. Internet) qui permettent l'échange de données. [0026] Le système de vendeur 14 peut fournir aux utilisateurs (p. ex. les agents de voyage) 20 une interface pour accéder à un système de distribution globale (GDS) pour permettre aux utilisateurs de rechercher et de réserver des services. Le système de vendeur 14 peut aussi inclure un serveur d'applications accessible par le système d'un voyageur (non illustré) permettant au voyageur de rechercher et de réserver des itinéraires de voyage sans l'aide d'un agent de voyage. Cette application peut comprendre, par exemple, un site web de voyage accessible par le 25 réseau 26 à l'aide d'une application cliente telle qu'un navigateur web fonctionnant sur le système du voyageur. [0027] Le serveur de paiement 16 reçoit une demande d'autorisation du système de vendeur 14 via le réseau 26 pour acheter des produites ou réserver des services. Dans un mode de réalisation non restrictif, la demande d'autorisation peut proposer de réserver un ou plusieurs 30 services relatifs un voyage tels que des billets d'avion, des réservations d'hôtel ou une location de 7 voitures en utilisant au moins deux formes de paiement. Cependant, on remarquera que le serveur de paiements divulgué 16 ne se limite pas uniquement à la réservation des services relatifs au voyage et une variété d'autres produits ou de services peuvent également être achetés. Dans les exemples tels qu'ils sont révélés, plus d'une forme de paiement est utilisée pour payer un produit 5 ou un service particulier. Des exemples de formes de paiement incluent, sans s'y limiter, une carte de crédit, une carte de débit, un compte de points de fidélité, un portefeuille numérique ou une autre méthode de paiement telle que les systèmes de paiement en ligne. [0028] En réponse à la réception de la demande d'autorisation pour réserver des services, le serveur de paiements 16 peut alors envoyer la demande d'autorisation à au moins un fournisseur 10 de paiements 18 A -18N par le réseau 26. Chaque système de fournisseur de paiements 18 peut correspondre à une forme de paiement particulière. Par exemple, un système de fournisseur de paiements 18A peut correspondre à une institution de carte de crédit particulière alors que le système de fournisseur de paiements 18B peut correspondre à une banque spécifique pour autoriser une carte de débit. En réponse à la réception d'une demande d'approbation, chacun des 15 fournisseurs de paiements 18 peut, soit autoriser, soit refuser la forme de paiement correspondante indiquée par la demande d'autorisation. [0029] Le serveur de paiements 16 inclut également un serveur de distribution 28. Comme expliqué de façon plus détaillée ci-dessous, le serveur de distribution 28 peut être utilisé pour inverser ou rembourser une transaction réussie dans certaines circonstances. En particulier, deux 20 ou plusieurs formes de paiement peuvent être utilisées pour payer la réservation d'un service spécifique. Le serveur de paiements 16 détecte au moins une transaction réussie et l'échec d'au moins une des formes de paiement et le serveur de distribution 28 cherche à inverser toutes transactions réussies. En d'autres termes, toute forme de paiement qui a déjà été validée est inversée si possible. De façon spécifique, le serveur de distribution 28 peut d'abord déterminer si 25 la forme de paiement particulière qui a déjà été validée est éligible à une inversion ou un remboursement. Cette détermination peut être basée sur des règles commerciales stockées dans la base de données 20. Si la forme de paiement est éligible à une inversion ou un remboursement, le serveur de distribution 28 peut alors envoyer une demande de retour arrière à chaque système de fournisseur de paiements 18 qui a déjà validé une forme de paiement pour l'achat d'un service 30 spécifique. 8 [Ô030] La forme de paiement peut échouer pour un nombre quelconque de raisons. Par exemple, dans un mode de réalisation la transaction peut échouer parce que le serveur de paiement 16 a été incapable de se connecter un système de fournisseur de paiements 18 correspondant en raison d'une mauvaise connectivité du réseau 26. Ainsi, le serveur de 5 paiement 16 peut détecter l'échec de la transaction si une notification n'a pas été reçue dans un laps de temps prédéterminé. Dans encore un autre mode de réalisation, la transaction peut échouer parce que forme de paiement a été refusée. Par exemple, une transaction peut être refusée s'il n'y a pas suffisamment de fonds sur le compte en banque pour l'utilisation d'une carte de débit. Par conséquent, le serveur de paiements 16 peut détecter l'échec d'une transaction sur la 10 base de la réception d'une notification d'échec de la part d'un serveur de paiements 16. Dans un autre exemple, la transaction peut être refusée si la forme de paiement a expiré. Par exemple, un utilisateur peut par inadvertance utiliser une carte de crédit expirée pour payer une réservation. Par conséquent, le serveur de distribution 28 peut détecter l'échec de la transaction sur la base de la réception d'une notification d'échec indiquant que la carte de crédit a expiré. 15 [0031] L'inversion d'un paiement signifie typiquement que la retenue des fonds sur un compte particulier est supprimée et toute autorisation pour retenir les fonds est annulée. Un remboursement signifie typiquement que tous les fonds qui ont été payés précédemment sont maintenant recrédités sur le compte d'un utilisateur. Dans un mode de réalisation, les fonds peuvent représenter de la monnaie. Dans un autre mode de réalisation, les fonds peuvent 20 représenter d'autres formes de paiement qui peuvent être utilisés pour acheter des produits ou des services tels que, sans s'y limiter, des points de fidélité de carte de crédit ou des « miles » d'une compagnie aérienne. [0032] Faisant maintenant référence à la FIG. 2, le système de vendeur 14, le serveur de paiements 16, les fournisseurs de paiements 18 de l'environnement d'exploitation 10 peuvent être 25 implémentés par un ou plusieurs dispositifs, tels que le système informatique 50. Le système informatique 50 peut inclure un processeur 52, une mémoire 54, un dispositif de stockage de mémoire de masse 56, une interface entrée/sortie (I/O) 58, et une interface homme-machine (FIMI) 60. Le système informatique 50 peut aussi être couplé de façon fonctionnelle à une ou plusieurs ressources externes 62 par l'intermédiaire du réseau 26, ou d'une interface I/0 58. Les 30 ressources externes peuvent inclure, mais de façon non exhaustive, des serveurs, des bases de 9 données, des dispositifs de stockage de masse, des dispositifs périphériques, des services de réseau en nuage, ou toute autre ressource informatique appropriée pouvant être utilisée avec le système informatique 50. [0033] Le processeur 52 peut inclure un ou plusieurs dispositifs sélectionnés : 5 microprocesseurs, microcontrôleurs, processeurs de signal numérique, micro-ordinateurs, unités centrales de traitement, des réseaux de portes programmables, des dispositifs logiques programmables, des machines à état défini, des circuits logiques, des circuits analogiques, des circuits numériques, ou tout autre dispositif servant à manipuler des signaux (analogues ou numériques) sur la base d'instructions de fonctionnement enregistrées dans la mémoire 54. La 10 mémoire 54 peut inclure un seul dispositif ou une pluralité de dispositifs de mémoire, notamment, mais sans s'y limiter, 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, l'antémémoire (cache memory) ou tout autre dispositif capable de stocker des informations. Le dispositif de 15 mémoire de masse 56 peut inclure des dispositifs de stockage de données tels qu'un disque dur, un disque optique, un dérouleur de bande magnétique, un circuit à l'état solide volatile ou non volatile ou tout autre dispositif capable de stocker des informations. [0034] Le processeur 52 peut fonctionner sous le contrôle d'un système d'exploitation 66 qui réside dans la mémoire 54. Le système d'exploitation 66 peut gérer les ressources de l'ordinateur 20 de telle façon que le code de programme de l'ordinateur, intégré sous forme d'un ou plusieurs logiciels d'application, tel que l'application 68 résidant dans la mémoire 54, puisse disposer d'instructions exécutées par le processeur 52. Dans un autre mode de réalisation, le processeur 52 peut exécuter l'application 68 directement et dans ce cas, le système d'exploitation 66 peut être omis. Une ou plusieurs structures de donnée 71 peuvent également résider dans la mémoire 54, 25 et peuvent être utilisées par le processeur 52, le système d'exploitation 66, ou l'application 68 pour stocker ou manipuler des données. [0035] L'interface I/0 58 peut fournir une interface machine qui couple le processeur 52 de façon fonctionnelle avec d'autres dispositifs et systèmes, tels que le réseau 26 ou la ressource externe 62. Le serveur d'application 68 peut ainsi collaborer avec le réseau 26 ou avec la 30 ressource externe 62 en communiquant par l'intermédiaire de l'interface I/O 58 pour fournir les 10 divers éléments, fonctions, applications, processus, modules composant les modes de réalisation de l'invention. L'application 68 peut aussi avoir un code de programme qui est exécuté par une ou plusieurs ressources externes 62, ou autrement repose sur les fonctions ou signaux fournis par d'autres composants de système ou de réseau externe au système informatique 50. En effet, au vu 5 des configurations presque infinies de matériel informatique et de logiciel possibles, les hommes de métier comprendront que les modes de réalisation de l'invention peuvent inclure des applications localisées extérieurement par rapport à l'ordinateur 50, distribuées à des ordinateurs multiples et à d'autres ressources externes 62, ou apportées par des ressources informatiques (matérielles et logicielles) qui sont fournies comme services sur le réseau 26, par exemple un 10 service d'informatique en nuage (cloud computing). [0036] Le HMI 60 peut être couplé de façon fonctionnelle avec le processeur 52 du système informatique 50 d'une manière connue pour permettre à un utilisateur d'interagir directement avec système informatique 50. Le HMI 60 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 15 capable de communiquer des données à l'utilisateur. Le HMI 60 peut aussi inclure des dispositifs de saisie et des contrôles tels qu'un clavier alphanumérique, un périphérique de pointage, des claviers, des boutons poussoir, des boutons de commande, des microphones, etc., capables d'accepter des commandes ou des saisies de l'utilisateur, et de les transmettre au processeur 52. 20 [0037] Une base de données 64 peut résider sur le dispositif de stockage de mémoire de masse 56, 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 64 peut inclure des données et les structures de données qui les supportent pour stocker et organiser les données. En particulier, la base de données 64 peut-être arrangée selon toute organisation ou structure de base de données 25 incluant, mais de façon non exhaustive, une base de données relationnelle, une base de données de type hiérarchique, une base de données en réseau, ou des combinaisons de celles-là. Un système de gestion de base de données sous forme de logiciel d'application qui s'exécute sous la forme d'instructions sur le processeur 52 peut être utilisé pour accéder à l'information ou aux données stockées dans des fichiers de la base de données 64 en réponse à une requête, lorsqu'une 11 requête peut être déterminée de façon dynamique et exécutée par le système d'exploitation 66, les autres applications 68, ou un ou plusieurs modules. [0038] Faisant maintenant référence à la FIG. 3, dans un mode de réalisation exemplaire de la divulgation le système de vendeur 14 peut inclure un module frontal 70, le serveur de 5 paiements 16 peut inclure un module dorsal 72 et le serveur de distribution 28. Le module frontal 70 du système de vendeur 14 peut être en communication avec le module dorsal 72 du serveur de paiements16. Le serveur de paiements 16 peut être communication avec au moins un fournisseur de paiements 18A-18N. Les modules 70, 72 sont représentés comme des composants distincts, ce qui peut indiquer l'utilisation de techniques de programmation modulaires. 10 Cependant, la conception du logiciel peut diminuer la mesure dans laquelle les modules 70, 72 sont distincts en combinant au moins certaines fonctions de programme de modules multiples en un seul module. En outre, les hommes de métier comprendront aisément que les fonctions attribuées aux modules 70, 72 peuvent être distribuées d'autres façons, ou sur des systèmes autres que ceux qui sont représentés. Par conséquent, les modes de réalisation de l'invention ne sont pas 15 limités à l'agencement spécifique des systèmes ou des modules représentés dans la FIG. 3. [0039] Le système de vendeur 14 inclut une interface graphique d'utilisateur (GUI) 80 qui peut être accessible par un utilisateur, tel qu'un agent de voyage. L'utilisateur peut saisir une entrée en utilisant la GUI 80 du système du vendeur 14. Spécifiquement, l'entrée saisie pas utilisateur indique une demande spécifique pour l'achat de produits ou la réservation de services. 20 Dans le mode de réalisation exemplaire tel qu'il est décrit, la demande spécifique est de réserver des services associés au voyage. L'entrée peut aussi indiquer deux ou plusieurs formes de paiement utilisées pour réserver les services associés au voyage. Le système du vendeur 14 peut ensuite initier un processus d'autorisation pour approuver les formes de paiement utilisées pour réserver les services. Spécifiquement, le module frontal 70 du système de vendeur 14 génère une 25 demande d'autorisation en réponse à la réception de l'entrée par la GUI 80. La demande d'autorisation peut représenter une demande pour réserver des services en utilisant deux ou plusieurs formes de paiement. [0040] Dans un exemple illustrateur, la demande d'autorisation peut inclure une demande pour réserver des billets d'avion pour un vol particulier. La demande d'autorisation peut aussi 30 inclure trois formes de paiement, notamment des points d'un compte de fidélité, une première 12 carte de crédit et une seconde carte de crédit. Dans un mode de réalisation, les points du compte de fidélité peuvent être des « miles » d'une compagnie aérienne également appelées « miles de voyageur fréquent » ou « points de voyage ». Les miles de compagnies aériennes font typiquement partie d'un programme de fidélité offert par les compagnies aériennes et/ou les 5 cartes de crédit dans lequel un utilisateur peut accumuler un ensemble de nombres de miles basés sur la distance parcourue par le voyageur ou le montant dépensé sur une carte de crédit. L'utilisateur peut ensuite utiliser les « miles » pour acheter des billets d'avion. Cependant, les points de fidélité inclus dans la demande d'autorisation ne sont pas suffisants pour payer la totalité du coût des billets d'avion. Par conséquent, la première et la seconde carte de crédit sont 10 utilisées pour payer le solde restant du billet d'avion. Spécifiquement chaque carte de crédit peut être utilisée pour payer la moitié du solde restant du billet d'avion. [0041] Toujours par référence à la FIG. 3, le module frontal 70 du système de vendeur 14 peut envoyer la demande d'autorisation au module dorsal 72 du serveur de paiements 16. Autrement, dans un autre mode de réalisation, le module frontal 70 du système du vendeur 14 15 peut envoyer la demande autorisation directement au serveur de paiements16. En réponse à la réception d'une demande d'autorisation, le serveur de paiements 16 peut mettre en oeuvre un processus pour valider chaque forme de paiement incluse dans la demande d'autorisation. Spécifiquement, le serveur de paiement 16 autorise de multiples transactions ou chaque transaction correspond à une des formes de paiement incluses dans la demande d'autorisation. 20 [0042] Dans l'exemple illustrateur tel qu'il est décrit, un système de fournisseur de paiements 18A peut correspondre à des points de fidélité, un système de fournisseur de paiements 18B peut correspondre à la première carte de crédit et un système de fournisseur de paiements 18N peut correspondre à la seconde carte de crédit. On notera que bien que le présent exemple inclut trois formes de paiement, le système de paiements divulgué n'est pas limité à trois 25 formes de paiement. En effet, le serveur de paiements 16 peut recevoir un nombre quelconque de formes de paiement du système du vendeur 14. Par ailleurs, bien que les trois systèmes de fournisseurs de paiements 18A, 18B et 18N soient illustrés dans la FIG. 3, un nombre quelconque de systèmes de paiements peuvent être en communication avec le serveur de paiements 16. [0043] Le serveur de paiements 16 peut générer une première demande pour autoriser une 30 première transaction correspondant aux points de fidélité du système de fournisseurs de 13 pàiements 18 A. Le système de paiements 16 peut ensuite recevoir une notification d'approbation indiquant que les points de fidélité ont été validés par le système de fournisseur de paiements 18 A. De façon similaire, le serveur de paiements 16 peut envoyer une seconde demande au système de fournisseur de paiements 18B pour l'autorisation d'une seconde 5 transaction afin d'approuver la première carte de crédit. Cependant, la première carte de crédit correspondant au système de fournisseur de paiements 18N peut échouer. Comme mentionné ci-dessus, une forme de paiement peut échouer pour un nombre quelconque de raisons. Dans l'exemple présent, la première carte de crédit a expiré. Par conséquent, le serveur de paiements 16 détecte l'échec de la seconde transaction basée sur la réception d'une notification 10 d'échec indiquant que la première carte de crédit a expiré. Le serveur de paiements 16 peut aussi générer une demande au système de fournisseur de paiements 18-N pour autoriser la seconde carte de crédit. Le serveur de paiements 16 peut ensuite recevoir une notification d'approbation indiquant que la seconde carte de crédit a été approuvée. [0044] Dans le cas de l'échec d'une des transactions pour une forme de paiement, le serveur 15 de paiements 16 détermine alors si toutes les transactions validées précédemment sont éligibles à un remboursement ou une inversion. Dans un mode de réalisation, les règles de la base de données 20 peuvent stocker les capacités des fournisseurs de paiements pour chaque fournisseur de paiements disponible. Spécifiquement, les capacités de chaque fournisseur de paiements incluent une information indiquant si une transaction correspondant à une forme de paiement peut 20 être remboursée ou inversée. Par conséquent, en réponse à la réception d'une notification d'échec indiquant qu'une transaction a échoué, le serveur de paiements16 peut rechercher dans la base de données 20 les règles commerciales correspondant au fournisseur de paiements pour les transactions validées. Le serveur de paiements 16 détermine ensuite si une transaction correspondant à une forme de paiement particulière peut être inversée ou remboursée sur la base 25 des règles commerciales stockées dans la base de données des règles 20. [0045] En réponse à la détermination que la transaction correspondant à la forme de paiement qui a échoué peut être inversée ou remboursée, le serveur de distribution 28 détermine s'il y a au moins une transaction correspondant à une forme de paiement qui a déjà été validée. Le serveur de distribution 28 peut ensuite générer une ou plusieurs demandes de retour arrière. 30 Spécifiquement, une demande de retour arrière est générée et envoyée à un système de 14 fournisseur de paiements particulier 18 pour chaque transaction correspondant à une forme de paiement qui a déjà été validée. [0046] On notera que chaque demande de retour arrière peut être envoyée à l'un des fournisseurs de paiements 18 d'une manière asynchrone. En d'autres termes, les demandes de 5 retour arrière peuvent survenir de manière asynchrone les unes par rapport aux autres. Dans un mode de réalisation, plusieurs demandes de retour arrière peuvent être envoyées du serveur de distribution 28 à peu près simultanément, et sont chacune envoyées à un système de fournisseur de paiements correspondant 18. Ainsi, on notera qu'une des demandes de retour arrière n'est pas dépendante du temps de réponse d'une autre demande de retour arrière. 10 [0047] Dans un mode de réalisation, le serveur de distribution 28 peut déterminer une ou plusieurs files d'attente de traitement. Spécifiquement, si une transaction indiquant qu'une forme de paiement a échoué et si deux ou plusieurs formes de paiement ont déjà été validées, le serveur de distribution 28 peut alors déterminer une ou plusieurs files d'attente de traitement. Une file d'attente de traitement peut inclure une ou plusieurs demandes de retour arrière, chacune 15 correspondant à une forme de paiement validée. Par exemple, dans l'éventualité où des points de fidélité ainsi qu'une seconde carte de crédit auraient été validés, mais que la première carte de crédit aurait été refusée, le serveur de distribution 28 créerait alors deux demandes de retour arrière. Les points de fidélité pourraient correspondre à une première demande de retour arrière et la seconde transaction par carte de crédit pourrait correspondre à une seconde demande de retour 20 arrière. La première demande de retour arrière et la seconde demande de retour arrière peuvent toutes deux être placées dans des files d'attente de traitement respectives. [0048] Il peut y avoir des files d'attente de traitement distinctes pour chaque type spécifique de vendeur ainsi que des files d'attente distinctes basées sur le fait que la forme de paiement est inversée ou remboursée. Par exemple, la première demande de retour arrière correspondant aux 25 points de fidélité peut être recréditée sur le compte de l'utilisateur et être placée dans une première file d'attente de traitement. De façon similaire, la seconde demande de retour arrière correspondant à la première carte de crédit peut être inversée et placée dans une seconde file d'attente de traitement. Dans un mode de réalisation, chaque file d'attente de traitement peut soit rembourser, soit inverser chaque transaction selon l'approche «première entrée-première sortie » 15 (First in First Out [FIFO]), signifiant que les demandes de retour arrière les plus anciennes sont envoyées d'abord à un fournisseur de paiements spécifique. [0049] Le serveur de distribution 28 peut retirer une demande de retour arrière de la file d'attente de traitement après réception d'une notification correspondante de retour arrière ou de 5 remboursement provenant du système du fournisseur de paiements respectif 18. Par exemple, en réponse à la réception d'une notification provenant du système de fournisseur de paiements 18A indiquant que les points de fidélité ont été recrédités au compte miles de la compagnie aérienne de l'utilisateur, le système de fournisseur de paiements peut ensuite retirer la première demande de retour arrière de la première file d'attente de traitement. 10 [0050] Au moins dans certains cas, une notification d'inversion ou de remboursement peut ne pas être reçue par le serveur de distribution 28 dans un laps de temps prédéterminé. Le laps de temps prédéterminé commence dès que le serveur de distribution 28 envoie la demande de remboursement au serveur de paiements correspondant 16. Si une notification de remboursement n'est pas reçue dans un laps de temps prédéterminé, le serveur de paiements 16 peut alors 15 envoyer périodiquement des demandes secondaires dans le but d'inverser ou de rembourser la transaction correspondant au système de fournisseurs de paiements particulier 18. Le serveur de paiements 16 peut continuer à envoyer un nombre prédéterminé de demandes secondaires au système du fournisseur de paiements 18 à des intervalles de temps prédéterminés. Par exemple, dans un mode de réalisation, le serveur de paiement 16 peut envoyer dix demandes secondaires 20 au système du fournisseur de paiement particulier 18, chaque seconde demande étant envoyée toutes les dix secondes. Cependant, si le serveur de paiements 16 ne reçoit pas la notification de remboursement après qu'un nombre prédéterminé de demandes secondaires a été envoyé, le serveur de paiements 16 peut alors placer la demande de retour arrière dans une file d'attente d'exception de dépassement de délai. 25 [0051] Les demandes de retour arrière placées dans la file d'attente d'exception de dépassement de délai nécessitent une action manuelle. Cela signifie que les demandes de retour arrière dans la file d'attente d'exception de dépassement de délai ne peuvent pas être traitées par un utilisateur tel qu'un agent de voyage. Au lieu de cela, un personnel technique peut résoudre les demandes de retour arrière. Spécifiquement, dès qu'une demande de retour arrière est placée dans 30 la file d'attente d'exception de dépassement de délai, une notification peut être affichée sur une 16 interface de surveillance, telle qu'une interface graphique d'utilisateur (GUI) utilisée par le personnel technique (non représentée dans les dessins). Une fois que le nombre de demandes de retour arrière excède un temps prédéterminé dans la file d'attente d'exception de dépassement de délai, une alarme ou un signal peut être déclenché pour notifier le personnel technique. Dans un 5 exemple, l'alarme peut être déclenchée dès qu'il y a cinq demandes de retour arrière dans la file d'attente d'exception de dépassement de délai. [0052] Faisant maintenant référence à la FIG.4, un organigramme décrivant un processus 100 peut être mis en oeuvre par le module frontal 70 du système du vendeur 14, le module dorsal 72 du serveur de paiements 16 et le serveur de distribution 28 pour mettre en oeuvre une ou plusieurs 10 demandes de retour arrière. [0053] Faisant maintenant référence à la fois aux FIG. 3 et 4, le processus 100 peut commencer au bloc 102. Au bloc 102, l'utilisateur saisit une entrée dans la GUI 80 du système du vendeur 14. Spécifiquement, comme expliqué ci-dessus, l'entrée indique une demande spécifique pour réserver un ou plusieurs services ou produits, ainsi que deux ou plusieurs formes de 15 paiement pour payer les services ou les produits. Le système du vendeur 14 peut ensuite initier un processus d'autorisation pour approuver les deux ou plusieurs formes de paiement. Le processus 100 peut alors poursuivre avec le bloc 104. [0054] Dans le bloc 104, le module frontal 70 du système du vendeur 14 envoie la demande d'autorisation au module dorsal 72 du serveur de paiements 16. Autrement, dans un autre mode 20 de réalisation, le module frontal 70 du système du vendeur 14 peut envoyer la demande autorisation directement au serveur de paiements16. En réponse à la réception d'une demande d'autorisation, le serveur de paiements 16 peut mettre en oeuvre un processus de validation pour valider les formes de paiement indiquées dans la demande d'autorisation. Le processus 100 peut alors poursuivre avec le bloc 106. 25 [0055] Au bloc de décision 106, le serveur de paiements 16 détecte si une des transactions pour une forme de paiement a échoué. Si aucune des formes de paiement n'a échoué, le processus 100 peut alors s'achever. Cependant, si le serveur de paiements 16 détermine qu'une ou plusieurs transactions correspondant à une des formes de paiement ont échoué, le processus 100 peut alors poursuivre au bloc 108. [0056] Au bloc 108, le serveur de distribution 28 détermine s'il y a au moins une transaction correspondant à une forme de paiement qui a déjà été validée. S'il n'y a aucune transaction correspondant à une forme de paiement qui a déjà été validée, le processus 100 peut alors s'achever. Cependant, s'il existe au moins une transaction correspondant à une forme de 5 paiement qui a déjà été validée, le processus 100 peut alors continuer au bloc 110. [0057] Au bloc 110, le serveur de paiements 16 peut déterminer si la transaction correspondant à toutes les formes de paiement validées peut être inversée ou remboursée sur la base des règles commerciales stockées dans la base de données des règles 20. Si la forme ou les formes de paiement validées ne peuvent être inversées ou remboursées, le processus 100 peut 10 alors s'achever. Cependant, si au moins une forme de paiement validée peut être inversée ou remboursée, le processus 100 peut alors continuer au bloc 112. [0058] Au bloc 112, le serveur de distribution 28 peut générer et envoyer une ou plusieurs demandes de retour arrière à un ou plusieurs fournisseurs de paiements 18. Spécifiquement, le serveur de distribution peut générer une demande de retour arrière pour chaque transaction qui a 15 déjà été approuvée, où la demande de retour arrière est envoyée à un système spécifique de fournisseur de paiements 18. On notera que les demandes de retour arrière peuvent être envoyées à l'un des fournisseurs de paiements 18 correspondant de façon asynchrone. Le processus100 peut alors poursuivre avec le bloc 114. [0059] Au bloc 114, le serveur de distribution 28 peut déterminer une ou plusieurs files 20 d'attente de traitement. La file d'attente de traitement peut inclure une ou plusieurs demandes de retour arrière qui correspondent chacune à une forme de paiement validée. Il peut y avoir des files d'attente de traitement distinctes pour chaque type spécifique de vendeur ainsi que des files d'attente de traitement distinctes selon que la forme de paiement peut être inversée ou remboursée. Le processus 100 peut alors poursuivre avec le bloc 116. 25 [0060] Au bloc de décision 116, le service de distribution 28 détermine si toutes les notifications de retour arrière ou de remboursement ont été reçues pour chaque demande de retour arrière dans un laps de temps prédéterminé. Si toutes les notifications d'inversion ou de remboursement ont été reçues par le serveur de distribution 28, le processus 100 peut alors s'achever. Cependant si une plusieurs notifications d'inversion de remboursement ne sont pas 30 reçues pendant le laps de temps prédéterminé, le processus 100 peut alors continuer au bloc 118. 18 [0i)61] Au bloc 118, le serveur de distribution 28 peut envoyer périodiques des demandes secondaires correspondant à chaque demande de retour arrière qui n'a pas reçu une notification d'inversion ou de remboursement. Le processus 100 peut alors poursuivre avec le bloc 120. [0062] Au bloc de décision 120, le serveur de distribution 28 peut continuer à envoyer un 5 nombre prédéterminé de demandes secondaires au système de fournisseur de paiements particulier 18 à des intervalles prédéterminés jusqu'à ce que le serveur de distribution 28 reçoive une notification d'inversion ou de remboursement en retour de chaque demande de retour arrière. Le processus 100 peut alors s'achever. Dans au moins certains cas, le serveur de distribution 28 ne peut pas recevoir la notification d'inversion ou de remboursement après que le nombre 10 prédéterminé de demandes secondaires a été envoyé et le processus 100 peut continuer au bloc 122. [0063] Au bloc 122, le serveur de distribution 28 peut placer les demandes de retour arrière restantes qui n'ont pas reçu une demande d'inversion ou de remboursement correspondante dans une file d'attente d'exception de délai de dépassement. Comme mentionné ci-dessus, les 15 demandes de retour arrière placées dans la file d'attente d'exception de dépassement de délai nécessitent une action manuelle. Le processus 100 peut alors s'achever. [0064] Faisant référence aux dessins en général, le système divulgué offre à un utilisateur une expérience de paiement optimisée et améliore également la technologie informatique afférente en permettant à une fonction d'obtenir une performance informatique qu'un ordinateur ne pouvait 20 pas mettre en oeuvre auparavant. C'est-à-dire, que le système divulgué améliore la technologie relative à l'informatique en permettant à un ordinateur de générer une ou plusieurs demandes de retour arrière pour inverser ou rembourser un paiement validé en réponse à l'échec d'une autre forme de paiement. Spécifiquement, si une des formes de paiement a échoué, le système divulgué peut alors générer une demande de retour arrière qui inverse ou rembourse tous les paiements qui 25 ont déjà été validés et la réservation de voyage n'est pas finalisée. Par contraste, les systèmes conventionnels peuvent maintenir la facturation d'une portion du prix de la réservation de voyage d'un voyageur. Cela est dû au fait que les systèmes conventionnels ne sont pas capables d'inverser ou de rembourser toutes les formes de paiement qui ont déjà été validées. Au lieu de cela, un représentant de voyage peut avoir besoin de résoudre la transaction de paiement afin 30 d'inverser ou de rembourser une transaction approuvée. 19 [065] 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 5 présentes comme « code de programme informatique » ou simplement «code de programme ». Un code de programme comporte typiquement des instructions lisibles par ordinateur qui résident à divers moments dans divers dispositifs de mémoire et de stockage dans un ordinateur et qui, lorsqu'elles sont lues et exécutées par un ou plusieurs processeurs dans un ordinateur, amènent l'ordinateur à effectuer des d'opérations nécessaires à l'exécution d'opérations et/ou d'éléments 10 propres à la mise en oeuvre des aspects variés des modes de réalisation de l'invention. Les instructions d'un programme, lisibles par ordinateur, pour effectuer les opérations des modes de réalisation de l'invention peuvent être, par exemple, le langage d'assemblage, ou encore un code source ou un code objet écrit en combinaison avec un ou plusieurs langages de programmation. [0066] Divers codes de programme décrits dans les présentes peuvent être identifiés, selon 15 l'application dans laquelle ils sont implémentés, dans des modes de réalisation spécifiques de l'invention. Cependant, on notera qu'une quelconque nomenclature d'un programme particulier dans les présentes 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 20 programmes informatiques peuvent être organisés selon des sous-programmes, procédures, procédés, modules, objets, et ainsi de suite, ainsi que les façons variées d'affecter les fonctionnalités d'un programme parmi diverses couches de logiciels qui sont résidents dans un ordinateur typique [p. ex., les systèmes d'exploitation, les bibliothèques, les interfaces d'application de programme (API), les applications, les petites applications « (applets)], etc. ; on 25 notera que les modes de réalisation de l'invention ne sont pas limités à l'organisation spécifique et à l'affectation spécifique des fonctionnalités de programme telles qu'elles sont décrites dans les présentes. [0067] Le code de programme mis en oeuvre dans toute application/module décrit dans les présentes peut être distribué individuellement ou collectivement comme un produit programme 30 d'ordinateur, sous une variété de formes. En particulier, le code de programme peut être 20 distribué en utilisant un médium de stockage lisible par ordinateur, disposant d'instructions de programme lisibles par ordinateur en lui même, permettant à un processeur d'effectuer des aspects des modes de réalisation de l'invention. [0068] Les supports de stockage lisibles par machine, étant intrinsèquement durables, 5 peuvent inclure des supports tangibles volatiles et non volatiles, amovibles et non amovibles, implémentés dans tout procédé ou technologie de stockage d'information, tels que des instructions de programme lisibles par machine, des structures de données, des modules de programme, ou autre donnée. Les supports de stockage lisibles par ordinateur peuvent aussi comprendre des mémoires RAM (mémoire à accès aléatoire), ROM (mémoire à lecture seule), 10 EPROM (mémoire à lecture exclusivement, programmable et effaçable), EEPROM (mémoire à lecture exclusivement, programmable et effaçable électriquement), 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 support pouvant être utilisé pour stocker 15 l'information désirée et apte à être lu par un ordinateur. Un support de stockage lisible par ordinateur ne peut être interprété comme « signaux transitoires » en soi (par exemple, des ondes radio ou toutes autres ondes électromagnétiques se propageant à travers un support de transmission telle qu'un guide d'ondes, ou des signaux électriques transmis par câble). Les instructions de programme lisibles par ordinateur peuvent être téléchargées sur un ordinateur, un 20 autre type d'appareil de traitement de données programmable ou sur tout autre dispositif de support de stockage lisible par machine, ou vers un ordinateur externe ou vers un dispositif de stockage externe par un réseau. [0069] Les instructions de programme lisibles par ordinateur, enregistrées sur un support lisible par ordinateur, peuvent être utilisées pour amener un ordinateur, d'autres types d'appareil 25 programmable de traitement de données, ou d'autres dispositifs, à fonctionner d'une façon particulière, de sorte que les instructions enregistrées sur un support lisible par ordinateur produisent un article de fabrication comprenant les instructions qui mettent en oeuvre 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 30 fournies à un ou plusieurs processeurs d'un ordinateur à usage général, un ordinateur dédié ou un 21 autre appareil programmable de traitement de données pour produire une machine, de sorte que les instructions, lorsqu'elles sont exécutées à l'aide du ou des processeurs, accomplissent une série de calculs pour mettre en oeuvre les fonctions, actions, et/ou les opérations spécifiées dans les organigrammes, diagrammes séquentiels et/ou diagrammes blocs. 5 [0070] 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 recommandées, 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 qui sont illustrés, tout en 10 restant conformes avec les modes de réalisation de l'invention. [0071] 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. Par ailleurs, les termes « comprend », « comprennent » et/ou « comprenant » lorsqu'ils sont utilisés dans ces spécifications, précisent la présence de caractéristiques, de 15 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 formes verbales « inclut », « ayant », «a », « avec » « comprend » ou des variantes, sont utilisées dans la description détaillée des revendications, ces termes sont censés être inclusifs de façon similaire au verbe 20 « comprendre ». [0072] 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 25 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 procédés et aux appareils représentatifs, et aux illustrations montrées et décrites à titre d'exemple. 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