FR 3095540 A1 20201030 FR 1904308 A 20190424 Description Titre de l'invention : Procédé pour traiter un ensemble de commandes dans un environnement informatisé Domaine technique [0001] L'invention concerne le domaine des architectures client/serveur notamment dédiées au commerce électronique, ci-après désigné par le terme e-commerce. Contexte [0002] L'e-commerce s'est développé avec le développement d'Internet. En particulier, le paiement électronique permet aux utilisateurs d'acheter des biens et des services (ci-après appelés produits), par exemple, des billets de voyage qui sont vendus par des commerçants distants. Le commerçant distant peut être établi dans la même zone monétaire que l'utilisateur, utilisant la même devise. Dans ce cas, la devise de tarification du marchand (également appelée ci-après «devise cible») et la devise du compte en banque de l'utilisateur sont les mêmes, ce qui évite le besoin de conversion. [0003] Cependant, la devise de tarification du marchand et la devise du compte en banque de l'utilisateur peuvent être différentes. Cela peut se produire si le prix du produit est réellement attractif ou si le produit est disponible uniquement chez ce commerçant précis. Dans ce cas, la banque de l'utilisateur prend une commission. Le montant de la commission se situe aux environs de 3 % du montant de la transaction. Le pourcentage correspondant à la commission de la banque dépend de la politique de la banque, ce qui entraine une incertitude pour l'utilisateur. En outre, le taux de change actuel entre la devise de tarification et la devise de l'utilisateur peut aussi dépendre de la banque. Le prix final que l'utilisateur doit payer peut donc fluctuer et ne peut pas être précisément identifié par l'utilisateur. 100041 Cette incertitude augmente encore lorsque l'achat est effectué entre plusieurs zones monétaires. Par exemple, dans l'industrie du voyage un utilisateur ayant un compte en banque en euro peut acheter un billet d'avion en dollar auprès d'une compagnie aérienne américaine pour un vol entre l'Europe et les États-Unis. Ensuite, il peut voyager des États-Unis au Japon et acheter des billets d'avion en yen pour ce segment auprès d'une compagnie aérienne japonaise. Ainsi il n'est pas possible d'estimer avec exactitude d'une part la commission de la banque et le taux de conversion entre l'euro et le dollar et d'autre part la commission de la banque et le taux de conversion entre l'euro et le yen. 100051 En raison du manque de clarté de cette information, un utilisateur peut hésiter à finaliser une transaction. Cela impacte le nombre de ventes, ce qui peut représenter une perte substantielle de revenus pour le fournisseur du produit. 2 [0006] Pour résoudre ce problème, une approche existante utilisée dans l'industrie du voyage consiste à proposer des devises alternatives au point de vente des fournisseurs de voyages. Cependant, cela dépend généralement de la banque du commerçant qui peut prélever des frais pour des comptes locaux dans des devises différentes. En pratique, très peu de devises sont généralement acceptées (principalement le dollar). Le nombre d'utilisateurs éligibles est donc limité. [0007] Dans une autre approche, un processus de conversion de devise dynamique (DCC) qui est utilisé représente un processus par lequel le montant d'une transaction Visa ou MasterCard est converti par le commerçant dans la devise du pays de la carte de paiement. Cependant, selon un mécanisme règlementé, les majorations de taux de change sont pour la plupart plus élevées que les frais de conversion de devise de l'utilisateur de la carte qui sont évités par le DCC. Par conséquent, dans la plupart des cas, le DCC résulte en frais plus élevés pour l'utilisateur. [0008] Dans une autre approche, une tarification à multideviscs (MCP) est utilisée. MCP re- présente un service financier qui permet aux commerçants dc tarifer leurs produits dans diverses devises tout en continuant à recevoir le paiement dans leur devise. MCP n'est actuellement disponible que pour les titulaires dc cartes Visa et MasterCard. [0009] DCC et MCP sont tous deux des programmes permettant à un utilisateur dc sé- lectionner son propre pays d'origine ou la devise dans laquelle les prix doivent lui être affichés. Le paiement de l'utilisateur pour l'achat sera ensuite perçu dans la devise sélectionnée. Par ailleurs, le montant affiché à l'utilisateur au moment du paiement sera le même montant que le montant qui apparaîtra sur son relevé de compte. Les deux solutions font basculer le taux de change de la commission vers le commerçant, ce qui en retour génère pour l'utilisateur une commission pour l'utilisation de ce service. [0010] Par conséquent, il existe un besoin pour un système et un procédé qui réduisent et suppriment la commission imposée à l'utilisateur pour un produit acheté dans une devise qui est différente de la devise de sa carte de crédit. Résumé : [0011] Selon un aspect de l'invention, il est proposé un procédé implémenté par ordinateur pour traiter un ensemble de commandes dans un environnement informatisé, comprenant les étapes qui consistent à : a) recevoir un ensemble de commandes provenant d'un ensemble d'utilisateurs respectifs, chacune des commandes comprenant une valeur de produit, une devise de tarification associée à la valeur du produit, une devise de paiement associée au moyen de paiement de l'utilisateur, ladite devise de tarification et ladite devise de paiement étant différentes, chaque commande étant associée à un délai limite pour la finalisation de l'exécution de la commande, b) déterminer si ledit ensemble de commandes reçu comprend une première 3 commande et un groupe d'au moins une deuxième commande, une du groupe d'au moins une deuxième commande ayant comme devise de paiement la devise de tarification de la première commande et une du groupe d'au moins une deuxième commande ayant comme devise de tarification la devise de paiement de la première commande, c) dans ce cas, avant le plus bref délai limite de la première, et au moins de ladite au moins une deuxième commande, l'exécution de la première commande en utilisant le moyen de paiement de ladite au moins une deuxième commande, et l'exécution de ladite au moins une deuxième commande en utilisant le moyen de paiement de la première commande. [0012] Dans certains modes de réalisation, le groupe comprend au moins une deuxième commande qui comprend une deuxième commande unique, et l'étape b) peut comprendre le fait de déterminer si ladite première commande et ladite deuxième commande comprennent un couple opposé de devises comprenant la devise de tarification et la devise de paiement. [0013] Dans certains modes de réalisation, le groupe comprenant au moins une deuxième commande peut comprendre : - une deuxième commande comprenant une deuxième valeur de produit, une deuxième devise de tarification (ci-après appelée « deuxième devise cible») associée à la valeur du deuxième produit, une deuxième devise de paiement associée au moyen de paiement d'un deuxième utilisateur, ladite deuxième devise de paiement et ladite devise de tarification de la première commande étant identiques, - une troisième commande comprenant une troisième valeur de produit, une troisième devise de tarification (également appelée dans les présentes «troisième devise cible») associée à la valeur du troisième produit et étant identique à la devise de paiement de la première commande, une troisième devise de paiement associée au moyen de paiement d'un troisième utilisateur, ladite troisième devise de paiement et ladite devise de tarification de la deuxième commande étant identiques. l'étape c) peut comprendre, avant le délai le plus bref de la première, deuxième et troisième commandes, l'exécution de la première commande en utilisant le moyen de paiement de la deuxième commande, l'exécution de la deuxième commande en utilisant le moyen de paiement de la troisième commande et l'exécution de la troisième commande en utilisant le moyen de paiement de la première commande. [0014] Dans certains modes de réalisation, l'étape a) peut comprendre le fait de transmettre à l'utilisateur ayant soumis une commande, un message relatif à la probabilité de finalisation de l'exécution de la commande de l'utilisateur avant le délai limite [0015] Dans certains modes de réalisation, l'étape a) peut comprendre, pour chacune des commandes de l'ensemble de commandes, le fait de vérifier la solvabilité du moyen de paiement de l'utilisateur, relative à la valeur du produit associée à la commande, et de transmettre la commande correspondante à une banque associée au moyen de paiement de l'utilisateur lorsque la solvabilité n'est pas assurée. [0016] Dans certains modes de réalisation, le procédé implémenté par ordinateur peut comprendre une étape de stockage des commandes dans une hase de données, ladite base de données comprenant une pluralité de sous-hases de données, les commandes qui ont la même devise d'utilisateur étant regroupées dans une même sous-hase de données. [0017] Dans certains modes de réalisation, le procédé implémenté par ordinateur peut comprendre une étape de retrait de la commande de la sous-base de données si l'exécution de la commande est achevée et/ou si le délai limite de la commande s'est écoulé. [0018] Dans certains modes de réalisation, le procédé implémenté par ordinateur peut comprendre : - une étape de sélection d'une commande maître et au moins une commande auxiliaire correspondante parmi l'ensemble des commandes, ladite au moins une commande auxiliaire contribuant à l'exécution de la commande maître, la somme des valeurs de produit des commandes auxiliaires étant plus élevée ou égale à la valeur du produit de la commande maître. - une étape de génération d'au moins une transaction contractuelle, la transaction contractuelle comprenant une référence à la commande maître, et une référence à chacune d'au moins ladite une commande auxiliaire. [0019] Dans certains modes de réalisation, le procédé implémenté par ordinateur peut comprendre une étape de détermination d'une commande auxiliaire à diviser et une étape de division de ladite commande auxiliaire en une commande restante et une commande de finalisation pour l'exécution de la commande maître, et dans lequel, en réponse à l'exécution de la commande maître, le procédé comprend une étape de génération d'une autre transaction supplémentaire, ladite autre transaction supplémentaire comprenant une référence à la commande restante comme étant une nouvelle commande maître et une référence à chacune d'au moins une commande auxiliaire contribuant à l'exécution de la nouvelle commande maître. [0020] Dans certains modes de réalisation, l'étape de détermination d'une commande auxiliaire à diviser peut comprendre le fait de déterminer la commande restante correspondante dont la valeur de produit est minimisée. [0021] Dans certains modes de réalisation, le procédé implémenté par ordinateur peut comprendre une étape de transmission d'au moins une partie des commandes à une banque associée au moyen de paiement de l'utilisateur si l'exécution de la commande est partiellement achevée ou pas du tout achevée quand le délai limite de la commande s'est écoulé. [0022] Dans certains modes de réalisation, le procédé implémenté par ordinateur peut comprendre une étape de transmission d'un message à l'utilisateur relatif au résultat de l'étape h). [0023] Dans certains modes de réalisation, le procédé implémenté par ordinateur peut comprendre une étape de stockage de l'historique des commandes pour lesquelles l'exécution a été finalisée. [0024] Dans certains modes de réalisation, la commande peut être un bon de commande. [0025] Un système est également proposé pour le traitement d'un ensemble de commandes dans un environnement informatisé, le système étant configuré pour : a) recevoir, par un ordinateur, un ensemble de commandes provenant d'un ensemble d'utilisateurs respectifs, chacune des commandes comprenant une valeur de produit, une devise de tarification associée à la valeur du produit, une devise de paiement associée au moyen de paiement de l'utilisateur, ladite devise de tarification et ladite devise de paiement étant différentes, chaque commande étant associée à un délai limite pour la finalisation de l'exécution de la commande, h) déterminer, par l'ordinateur, si ledit ensemble de commandes reçu comprend une première commande et un groupe d'au moins une deuxième commande, une du groupe d'au moins une deuxième commande ayant comme devise de paiement la devise de tarification de la première commande et une du groupe d'au moins une deuxième commande ayant comme devise de tarification la devise de paiement de la première commande, c) dans ce cas, avant le délai limite le plus bref de la première et au moins de ladite au moins une deuxième commande, exécuter la première commande en utilisant le moyen de paiement de ladite au moins une deuxième commande et l'exécution de ladite au moins deuxième commande en utilisant le moyen de paiement de la première commande. [0026] Dans certains modes de réalisation, le groupe comprend au moins une deuxième commande comprenant une deuxième commande unique, le système est par ailleurs configuré pour déterminer si ladite première commande et ladite deuxième commande comprennent un couple opposé de devises comprenant une devise de tarification et une devise de paiement. [0027] Dans certains modes de réalisation, le groupe comprenant au moins une deuxième commande comprend : - une deuxième commande comprenant une deuxième valeur de produit, une deuxième devise de tarification associée à la valeur du deuxième produit, une deuxième devise de paiement associée au moyen de paiement d'un deuxième utilisateur, ladite deuxième devise de paiement et ladite devise de tarification de la 6 première commande étant identiques, - une troisième commande comprenant une troisième valeur de produit, une troisième devise de tarification associée à la valeur du troisième produit et étant identique à la devise de paiement de la première commande, une troisième devise de paiement associée au moyen de paiement d'un troisième utilisateur, ladite troisième devise de paiement et ladite devise de tarification de la deuxième commande étant identiques. le système est par ailleurs configuré pour, avant le délai le plus bref de la première, deuxième et troisième commandes, exécuter la première commande en utilisant le moyen de paiement de la deuxième commande, exécuter la deuxième commande en utilisant le moyen de paiement de la troisième commande et exécuter la troisième commande en utilisant le moyen de paiement de la première commande. [0028] Dans certains modes de réalisation, le système est par ailleurs configuré pour transmettre à l'utilisateur ayant soumis une commande, un message relatif à la probabilité de finalisation de l'exécution de la commande de l'utilisateur avant le délai limite. [0029] Dans certains modes de réalisation, le système est par ailleurs configuré pour vérifier la solvabilité du moyen de paiement de l'utilisateur relative à la valeur de produit associée à la commande et de transmettre la commande correspondante à une banque associée au moyen de paiement de l'utilisateur si la solvabilité n'est pas assurée. [0030] Dans certains modes de réalisation, le système est par ailleurs configuré pour stocker les commandes dans une base de données, ladite base de données comprenant une pluralité de sous-bases de données, les commandes qui ont la même devise d'utilisateur étant regroupées dans une même sous-base de données. [0031] Dans certains modes de réalisation, le système est par ailleurs configuré pour retirer la commande de la sous-base de données si l'exécution de la commande a été finalisée et/ou si le délai limite de la commande s'est écoulé. [0032] Dans certains modes de réalisation, si l'étape b) échoue, le système est par ailleurs configuré pour sélectionner parmi l'ensemble des commandes une commande maître et au moins une commande auxiliaire correspondante contribuant à l'exécution de la commande maître, la somme des valeurs de produit des commandes auxiliaires étant égale à la valeur du produit de la commande maître, et pour générer au moins une transaction contractuelle, la transaction contractuelle comprenant une référence à la commande maître et une référence à chacune d'au moins une commande auxiliaire. [0033] Dans certains modes de réalisation, le système est par ailleurs configuré pour dé- terminer une commande auxiliaire devant être divisée et pour diviser ladite commande auxiliaire en une commande restante et une commande de finalisation pour l'exécution de la commande maître, et dans lequel, en réponse à l'exécution de la commande maître, le système est configuré pour générer une transaction supplémentaire, ladite 7 autre transaction supplémentaire comprenant une référence à la commande restante comme étant une nouvelle commande maître, une référence à chacune de ladite au moins une commande auxiliaire contribuant à l'exécution de la nouvelle commande maître. [0034] Dans certains modes de réalisation, le système est par ailleurs configuré pour dé- terminer la commande restante correspondante dont la valeur de produit est minimisée. [0035] Dans certains modes de réalisation, le système est par ailleurs configuré pour transmettre au moins une partie des commandes à une banque associée au moyen de paiement de l'utilisateur, si l'exécution de la commande est partiellement achevée ou pas du tout achevée quand le délai limite de la commande s'est écoulé. [0036] Dans certains modes de réalisation, le système est par ailleurs configuré pour stocker une histoire des commandes pour lesquelles l'exécution est achevée. [0037] Dans certains modes de réalisation, la commande est un bon de commande. Brève description des dessins [0038] Les dessins en annexe qui sont incorporés et constituent une partie de cette spéci- fication, 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. [0039] [fig.1] illustre un cas d'utilisation pour des achats en utilisant le procédé conformément à l'invention. [0040] [fig.2] illustre un autre cas d'utilisation pour des achats utilisant le procédé conformément à l'invention. [0041] [fig.3] est un diagramme illustrant une implémentation exemplaire d'un système conformément à l'invention. [0042] [fig.4] est un diagramme illustrant l'environnement informatique du système conformément à l'invention. [0043] [fig.5] illustre un diagramme temporel du procédé conformément à l'invention. [0044] [fig.6] illustre un autre diagramme temporel du procédé conformément à l'invention. [0045] [fig.7] est une représentation schématique illustrant le cas d'une commande auxiliaire devenant une commande maître. [0046] [fig.8] est une première représentation des compartiments qui sont utilisés dans le procédé conformément à l'invention. [0047] [fig.9] est une deuxième représentation des compartiments utilisés dans le procédé conformément à l'invention. [0048] [fig.10] est une troisième représentation des compartiments qui sont utilisés dans le procédé conformément à l'invention. Description détaillée 8 [0049] Les termes « bon de commande» ou «commande » ci-après, font référence à une commande d'utilisateur qui déclenche l'achat d'un produit auprès d'un commerçant, ci-après appelé fournisseur de produit, en réponse à l'exécution d'une commande d'utilisateur. [0050] L'invention est basée sur le fait que certains marchands sont des intermédiaires pour un nombre important de transactions de paiement quotidiennes. C'est le cas pour les commerçants de l'industrie de voyage en particulier les systèmes de distribution globaux. Un système de distribution global est un système de réseaux informatisés qui permet des transactions entre les fournisseurs de services de l'industrie du voyage, principalement les compagnies aériennes les hôtels, les loueurs de voitures et les agences de voyages. Les commerçants en ligne principaux sont aussi les intermédiaires pour un nombre quotidien très important de transactions de paiement. [0051] Le procédé est exécuté par une plateforme dédiée d'un commerçant. Par exemple, comme illustré par la figure 1, un premier utilisateur qui a un moyen de paiement dans une première devise, par exemple une carte de crédit en dollar, veut acheter un billet d'avion vendu en cure auprès d'une compagnie aérienne française. La devise du moyen de paiement du premier utilisateur est différente de la devise du compte bancaire de la compagnie qui vend le billet d'avion. Le billet d'avion que le premier utilisateur veut acheter coûte 100 euros. [0052] D'autre part, un deuxième utilisateur qui a un moyen de paiement dans une deuxième devise, par exemple une carte de crédit en euro, veut acheter un billet d'avion vendu en dollar auprès d'une compagnie aérienne américaine. La devise du moyen de paiement du deuxième utilisateur est différente de la devise du compte bancaire de la compagnie qui vend le billet d'avion. Le billet d'avion que le deuxième utilisateur veut acheter coûte 115 dollars. [0053] Le jour des requêtes, le taux interbancaire (BSR) de l'euro en dollar est de 1,15. Dans ce cas, la valeur du produit du premier utilisateur correspond parfaitement à la valeur du produit du deuxième utilisateur. Par conséquent, la plateforme est capable de procéder à l'achat du paiement du billet d'avion en euro avec le moyen de paiement en euro et à l'achat du paiement du billet d'avion en dollar avec le moyen de paiement en dollar. Par conséquent, les utilisateurs peuvent acheter les billets d'avion sans aucune commission bancaire. [0054] La figure 2 illustre un autre scénario dans lequel la correspondance entre des commandes différentes peut être faite avec plus de deux utilisateurs. Dans ce cas, un premier utilisateur qui a un moyen de paiement en dollar veut acheter un billet d'avion pour 150 euros qui est équivalent à 172 dollars selon le taux interbancaire entre l'euro et le dollar. Un deuxième utilisateur qui a un moyen de paiement en euro veut acheter un billet d'avion pour 126 dollars. Un troisième utilisateur qui a un moyen de paiement 9 en cura veut acheter un billet d'avion pour 46 dollars. [0055] Une opération correspondante entre les trois commandes peut être faite. En effet, la commande du premier utilisateur est divisée en deux transactions. D'un côté, le premier utilisateur achète deux billets d'avion (le billet d'avion 126 dollars et le billet d'avion de 46 dollars) en dollars avec le moyen de paiement en dollars. D'autre part, les deux utilisateurs qui ont des moyens de paiement en cure) sont rassemblés afin d'acheter le billet d'avion qui est vendu en curo. [0056] Dans ce cas, les utilisateurs peuvent acheter les billets d'avion sans aucune commission bancaire. [0057] L'invention peut être appliquée à toute sorte de moyens de paiement électroniques, notamment par carte de crédit. [0058] La figure 3 est un diagramme illustrant une implémentation exemplaire d'un système conformément à l'invention. [0059] Dans une première étape du procédé selon l'invention, la plateforme reçoit un ensemble de bons de commande d'un ensemble d'utilisateurs qui déclenchent respectivement les bons de commande via un dispositif client 300. Dans la figure 1, seulement un utilisateur et un dispositif client 300 sont illustrés, par souci de simplicité de la présentation. Chaque bon de commande comprend une valeur de produit qui peut être convertie dans une devise standard qui peut être commune à toutes les commandes. La conversion peut se faire selon le taux interbancaire. Le BSR est un taux de change quotidien. Il est la source officielle des conversions de devises de paiement internationales utilisée par l'industrie pour la tarification et l'émission de billets (utilisés dans les ventes). Il contient les taux de change à un moment donné. Dans l'industrie du voyage, le GDS peut se procurer le BSR auprès de IATA (l'association internationale de transport aérien). [0060] La valeur du produit représente le prix des biens ou des services. Le bon de commande comprend aussi une devise de tarification associée à la valeur du produit, également appelée devise cible. La devise de tarification représente la devise dans laquelle le produit est vendu. En d'autres termes, la devise de tarification est la devise du compte bancaire du vendeur. Le bon de commande comprend aussi une devise d'utilisateur associée à un moyen de paiement de l'utilisateur. [0061] La platefonne 100 comprend un serveur à option d'adhésion 101. L'enregistrement de l'utilisateur pour l'opération correspondante est géré par le serveur à option d'adhésion 101. Le serveur à option d'adhésion 101 a trois fonctions qui sont le filtrage des utilisateurs, la reconnaissance de la participation et la vérification de solvabilité de l'utilisateur. Dans une première étape, le serveur à option d'adhésion 101 demande à l'utilisateur s'il peut participer au processus d'appariement du paiement. Si la réponse est positive, le serveur à option d'adhésion 101 fournit à l'utilisateur une es- timation de l'accomplissement de l'appariement de paiement. L'estimation est basée sur le bon de commande de l'utilisateur : la valeur du produit, la devise de tarification associée à la valeur du produit, la devise de l'utilisateur associée à un moyen de paiement de l'utilisateur et le délai limite pour la finalisation de l'achat. [0062] À cc stade, le serveur à option d'adhésion 101 vérifie aussi la solvabilité de l'utilisateur par rapport à la valeur du produit. La solvabilité peut être évaluée au regard d'une évaluation du solde du compte en banque de l'utilisateur si la commande de l'achat était finalisée. En particulier, le solde doit être au-dessus d'un niveau prédéfini si l'achat était finalisé. Si le serveur à option d'adhésion 101 détermine que l'utilisateur est solvable, une autorisation est donnée par le serveur à option d'adhésion 101 à l'utilisateur pour accéder à la plateforme. Cette autorisation est associée à une identification devant être réutilisée par la suite au cours du processus dans le centre d'action. L'action de cette vérification est effectuée par le centre d'action à la demande du serveur à option d'adhésion. Si la solvabilité n'était pas vérifiée, le serveur à option d'adhésion 101 refuserait la demande de l'utilisateur, lequel serait informé que la commande va être transmise à la banque associée au moyen de paiement de l'utilisateur. Par conséquent, il n'est pas nécessaire de passer en revue la chaîne de correspondance des commandes, ce qui réduit la complexité du processus. [0063] Le serveur à option d'adhésion 101 reçoit, du livre de commandes 102, des in- formations concernant la disponibilité de certaines devises comme cela sera décrit ci-dessous. Le serveur à option d'adhésion 101 peut aussi donner une estimation de la finalisation de la commande en fonction de l'heure de la journée. Par exemple, en raison du décalage horaire entre l'Amérique du Nord et l'Europe, un utilisateur européen qui souhaiterait payer un produit en dollar le matin peut devoir attendre quelques heures. Car, au début de l'après-midi en Europe la plupart des clients américains commencent leurs sessions d'achat. Par conséquent, le créneau horaire entre différentes zones monétaires est un paramètre qui doit être pris en compte par le serveur à option d'adhésion101 pour estimer un pourcentage de satisfaction de la demande de l'utilisateur. [0064] Dans un autre mode de réalisation, le serveur à option d'adhésion 101 peut refuser l'opération d'appariement s'il n'existe aucune demande historique de correspondance entre deux devises prédéterminées. Plutôt que de refuser la demande de l'utilisateur, le serveur à option d'adhésion 101 fournit un pourcentage d'estimation même très bas. Si le pourcentage est très bas, le serveur à option d'adhésion 101 peut conseiller à l'utilisateur de ne pas participer à l'opération d'appariement. L'utilisateur peut aussi être averti que la transaction, si elle n'est pas finalisée à 100 %, peut être finalisée par sa banque afin de finaliser sa commande. 11 [0065] Le pourcentage de finalisation de la commande via la plateforme est aussi calculé pour une durée donnée qui est le délai limite pour la finalisation de l'achat. Le délai limite est une donnée qui est associée à la commande. Ce peut-être un délai limite imposé par le commerçant. Dans un exemple de l'invention dans l'industrie du voyage, une fois que l'utilisateur a choisi une option sur un vol via le site Web de la compagnie aérienne ou par l'intermédiaire d'une agence de voyages en ligne, l'option peut être réservée pour un temps prédéterminé et ensuite annulée si l'utilisateur n'a pas finalisé l'achat. [0066] Le livre de commandes 102 stocke toutes les commandes d'achat passées par les uti- lisateurs qui ont souhaité participer. Un délai limite est associé à chaque commande. Le livre de commandes 102 stocke les commandes en utilisant le chronométreur 103 qui détermine le délai de paiement pour chaque commande. [0067] Le livre de commandes 102 est une hase de données qui contient des commandes et des transactions, et qui comprend des compartiments. Un compartiment est une sous-division du livre de commandes 102 qui contient les commandes ayant la devise d'origine, c'est-à-dire la même devise d'utilisateur. Le compartiment contient seulement des commandes qui ont la même devise d'origine. Par conséquent, chaque compartiment groupe de façon fonctionnelle des éléments de même nature. [0068] Par exemple, un premier utilisateur saisit une commande dans laquelle la devise d'utilisateur est l'euro afin d'acheter un produit en dollar. Un deuxième utilisateur saisit une commande dans laquelle la devise d'utilisateur est l'euro afin d'acheter un produit en yen. Les deux commandes sont stockées dans le même compartiment associé à l'euro. [0069] L'affectation selon la devise d'utilisateur augmente la vitesse du processus d'appariement. En effet, l'apparieur de paiements 105 sait où il peut trouver une devise déterminée puisque toutes les commandes qui ont rendu cette devise disponible sont stockées dans ce compartiment. [0070] En outre, le montant exact de la valeur disponible dans chaque devise peut être déterminé en additionnant les cellules du compartiment qui contiennent la valeur. Par conséquent, lorsque le serveur à option d'adhésion 101 reçoit une requête pour trouver une commande correspondante avec des devises opposées, le serveur à option d'adhésion 101 détermine la somme du compartiment correspondant et détermine s'il est possible d'apparier la commande entrante avec une autre. [0071] Dans chaque compartiment, les commandes d'achat peuvent être indexées avec un repère pour avoir un accès plus rapide à des transactions et à des commandes en fonction de leur identifiant. Le repère est un identifiant unique attribué par une base de données à un enregistrement. Par exemple, le repère peut être attribué selon l'ordre d'arrivée dans le livre de commandes 102. 12 [0072] Chaque compartiment stocke des transactions qui n'ont pas été satisfaites. En effet les transactions qui ont été satisfaites sont retirées du livre de commandes 102. [0073] L'apparieur de paiements 105 lit les commandes qui sont stockées dans le livre de commandes 102 et vérifie s'il est possible d'associer une commande à une autre, ou à plusieurs commandes en fonction des devises des commandes, comme illustré dans les figures 1 et 2. Lorsque rapparicur de paiement 105 a déterminé qu'une transaction a été finalisée il transmet la transaction au centre d'action 104. [0074] Le centre d'action 104 interagit avec la plateforme de paiement 200. 11 procède à l'achat des produits pour lesquels l'opération d'appariement a été complétée. Il enregistre aussi un historique de toutes les informations relatives à la commande qui a été satisfaite. [0075] Le livre de commandes 102 stocke les commandes aussi longtemps que les commandes d'achat n'ont pas été entièrement finalisées, c'est-à-dire aussi longtemps que le produit n'a pas été payé et validé. [0076] Chacun des sous-éléments de la plateforme 100, le dispositif client 300, la plateforme de paiement 200, ainsi que d'autres systèmes ou dispositifs de l'environnement d'exploitation, tels que la plateforme de réservations 400, peuvent être implémentés sur un plusieurs dispositifs ou systèmes informatiques, collectivement appelés un ordinateur, tel que l'ordinateur 26, et illustré dans la figure 4. L'ordinateur 26 peut inclure un processeur 28, une mémoire 30, un dispositif de stockage de mémoire de masse 32, une interface entrée/sortie (I/O) 34, et une interface homme-machine (HMI) 36. L'ordinateur 26 peut aussi être couplé de façon fonctionnelle à une ou plusieurs ressources externes 38 par l'intermédiaire du réseau 24 ou de l'interface 1/0 34. Les ressources externes peuvent inclure, mais de façon non exhaustive, des serveurs, des bases de données, des dispositifs de stockage de masse, des dispositifs périphériques, des services de réseau basés sur le cloud, ou toute autre ressource informatique appropriée qui peut être utilisée par l'ordinateur 26. [0077] Le processeur 28 peut inclure un ou plusieurs dispositifs sélectionnés : micropro- cesseurs, microcontrôleurs, processeurs de signaux numériques, micro-ordinateurs, unités centrales de traitement, réseaux de portes programmables, dispositifs logiques programmables, machine p[s à état défini, circuits logiques, circuits analogiques, circuits numériques, ou tout autre dispositif servant à manipuler des signaux (analogues ou numériques) basé sur des instructions de fonctionnement enregistrées dans la mémoire 30. La mémoire 30 peut inclure un seul dispositif de mémoire ou une pluralité de dispositifs de mémoire comprenant, de façon non exhaustive, la mémoire morte à lecture seule (ROM), la mémoire vive à 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, ou tout autre 13 dispositif capable de stocker des informations. Le dispositif de stockage de mémoire de niasse 32 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. [0078] Le processeur 28 peut fonctionner sous le contrôle d'un système d'exploitation 40 qui réside dans la mémoire 30. Le système d'exploitation 40 peut gérer les ressources de l'ordinateur de telle façon que le code de programme de l'ordinateur, intégré sous forme d'un ou plusieurs logiciels d'application, telle que l'application 42 qui réside dans la mémoire 30, puisse disposer d'instructions exécutées par le processeur 28. Dans un autre mode de réalisation, le processeur 28 peut exécuter l'application 42 directement et dans ce cas, le système d'exploitation 40 peut être omis. Une ou plusieurs structures de donnée 44 peuvent aussi résider dans la mémoire 30, et peuvent être utilisées par le processeur 28, le système d'exploitation 40 ou l'application 42 pour stocker ou manipuler des données. [0079] L'interface 34 peut fournir une interface machine qui couple de façon fonctionnelle le processeur 28 à d'autres dispositifs et systèmes, tels que le réseau 24 ou une ou plusieurs ressources externes 38. L'application 42 peut ainsi collaborer avec le réseau 24 ou les ressources externes 38 en communiquant via l'interface I/0 34 pour fournir les divers éléments, fonctions, applications, processus, ou modules composant les modes de réalisation de l'invention. L'application 42 peut aussi avoir un code de programme qui est exécuté par une ou plusieurs ressources externes 38 ou, autrement, repose sur les fonctions ou signaux fournis par d'autres systèmes ou composants de réseau externes à l'ordinateur 26. En effet, au vu des configurations presque infinies de matériel informatique et de logiciel possibles, les hommes de métier comprendront que les modes de réalisation de l'invention peuvent inclure des applications situées à l'extérieur de l'ordinateur 26, distribuées à des ordinateurs multiples ou à d'autres ressources externes 38, ou fournies par des ressources informatiques (matérielles et logicielles) qui sont fournies comme un service sur le réseau 24, tel qu'un service informatique cloud. [0080] Le HMI 36 peut être couplé de façon fonctionnelle avec le processeur 28 de l'ordinateur 26 d'une manière connue pour permettre à un utilisateur d'interagir directement avec l'ordinateur 26. Le HMI 36 peut inclure des affichages vidéo ou alphanumériques, un écran tactile, un haut-parleur et tout autre indicateur audio et visuel adapté capables de fournir des données à l'utilisateur. Le HMI 36 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-poussoirs, des boutons de commande, des microphones, etc., capables d'accepter des commandes ou des saisies de l'utilisateur, et de les transmettre au processeur 28. 14 [0081] La base de données 46 peut résider sur le dispositif de stockage de mémoire de niasse 32 et peut être utilisée pour collecter et organiser les données utilisées par les divers systèmes et modules décrits dans les présentes. La hase de données 46 peut inclure des données et les structures de donnée qui les supportent pour stocker et organiser les données. En particulier, la hase de données 46 peut être arrangée selon toute organisation ou structure de hase de données incluant, mais de façon non exhaustive, une hase de données relationnelle, une hase de données de type hiérarchique, une hase de données en réseau, ou des combinaisons de celles-ci. Un système de gestion de hase de données sous forme de logiciel informatique d'application qui s'exécute sous la forme d'instructions sur le processeur 28 peut être utilisé pour accéder à l'information ou aux données stockées dans des enregistrements de la hase de données 46 en réponse à une interrogation, lorsqu'une interrogation peut être déterminée de façon dynamique et exécutée par le système d'exploitation 40, les autres applications 42, ou un ou plusieurs modules. [0082] La figure 5 illustre un diagramme temporel du procédé conformément à l'invention. Les différentes étapes du procédé sont exécutées selon une échelle temporelle symbolisée par l'axe temps. Les communications à double sens entre les différents sous-éléments de la plateformc 100 et les communications entre la plateforme et les systèmes qui sont externes à la plateforme sont dénommées « MSGn » (n=1... 12). Les messages MSGn sont également illustrés dans la figure 3. Au cours d'une première étape, l'utilisateur soumet une commande X à un serveur à option d'adhésion 101 (MSG1). Dans un mode de réalisation particulier de l'invention appliquée à l'industrie du voyage, la commande X est un bon de commande pour acheter un produit de voyage, par exemple un billet d'avion, dans une devise qui est différente de la devise du moyen de paiement de l'utilisateur. Le serveur à option d'adhésion 101 analyse la commande X. Le serveur à option d'adhésion 101 vérifie la solvabilité du moyen de paiement de l'utilisateur relatif à la valeur du produit associée à la commande X (MSG2) résultant en un blocage du montant d'argent correspondant. L'étape de blocage est effectuée par le centre d'action 104. Ce dernier transmet la commande correspondante à une banque associée au moyen de paiement de l'utilisateur si la solvabilité n'est pas assurée. [0083] Lors de la reconnaissance de l'utilisateur, la commande X est stockée dans le livre de commandes 102 (MSG2bis), dans le compartiment approprié correspondant à la devise de l'utilisateur. Tant que la commande X est stockée dans le livre de commandes 102, une fonction de surveillance est mise en oeuvre par le chronométreur 103, en communication avec le livre de commandes 102 (MSG7). Une commande X contient un délai limite, la finalisation de la commande doit être traitée tant que le délai limite ne s'est pas écoulé. [0084] Ensuite la commande X est ajoutée à rapparicur de paiements 105 (MSG3). L'apparicur de paiements 105 lit les commandes qui pourraient correspondre à la commande X. L'apparieur de paiements 105 lit le compartiment de la devise du produit de la commande X. Par exemple, si, dans la commande X, la devise d'utilisateur est l'euro et que la devise du produit est le dollar, rapparicur de paiements 105 lit alors le compartiment associé au dollar. Lorsqu'une meilleure correspondance a été trouvée par rapparicur de paiements 105, telle qu'illustrée par les figures 1 et 2, l'apparicur de paiements 105 verrouille les commandes de la meilleure correspondance, et une liste de commandes qui pourraient être compatibles avec la commande X est envoyée par rapparicur de paiements 105 au centre d'action 104 afin de valider la faisabilité du paiement concernant en particulier la solvabilité des utilisateurs (MSG4). [0085] Ensuite, le centre d'action 104 envoie une demande pour enregistrer l'historique de la transaction réussie (MSG9). Les données historiques seront utilisées pour calculer les critères d'éligibilité pour le serveur à option d'adhésion 101. Il demande également au serveur de paiement de procéder au paiement des commandes associées à la transaction réussie (MSG10). Dans un mode de réalisation particulier de l'invention appliqué à l'industrie du voyage, le processus d'achat prend fin avec l'actualisation du billet de réservation, incluant l'actualisation du PNR (enregistrement de nom de passager). Dans cc but, le centre d'action 104 communique avec la plateforme de ré- servations 400 (MSG11). Chaque PNR est actualisé avec la forme de paiement qui sera associée à l'émission du billet. Les champs cachés dans la forme de paiement sont actualisés avec l'information de la carte de crédit de l'utilisateur ce qui peut être utile, par exemple, pour effectuer des remboursements. Par la suite, les commandes qui ont été impliquées dans la transaction réussie sont retirées du livre de commandes 102 (MSG6), et la fonction de surveillance est désactivée pour ces commandes (MSG7). Finalement, les utilisateurs qui ont pris part à la transaction sont avisés par le centre d'action 104 (MSG12). [0086] On remarquera que le centre d'action 104 peut aussi être capable d'assurer que les diverses correspondances effectuées n'échoueront pas ultérieurement en raison d'une autorisation refusée, ce qui bloquerait les fonds pour chaque utilisateur. Il est essentiel d'assurer une autorisation réussie. Si une autorisation échoue, cela pourrait déclencher une annulation de toutes les correspondances faites jusqu'ici. De plus, comme le processus d'autorisation avec la banque bloque les fonds sur un compte d'utilisateur pour quelques jours, l'annulation de montants déjà autorisés serait problématique. Puisque le montant global à bloquer dans la devise du moyen de paiement de l'utilisateur est connu, il est possible d'effectuer cette autorisation par avance. [0087] Dans un mode de réalisation particulier de l'invention, appliqué à l'industrie du 16 voyage, il peut notamment y avoir deux façons d'effectuer cette action : [0088] Le centre d'action 104 peut demander une autorisation directement auprès du dispositif de carte de crédit et, ensuite, chaque compagnie aérienne impliquée finalisera le paiement des fonds (peut-être partiels) avec leur acquéreur sur la hase de l'autorisation ; [0089] Le centre d'action 104 peut autoriser le montant et générer avec un partenaire un numéro de carte de crédit virtuel prépayé qui sera utilisé au cours d'autorisations subséquentes par les compagnies aériennes. Cela assure une fiabilité totale que les transactions n'échoueront pas. Cette carte de crédit virtuelle ne sera jamais vue par les utilisateurs finaux, mais sera utilisée seulement pour les transactions. [0090] Dans tous les cas, l'autorisation initiale bloquant le montant est associée à la commande pertinente. [0091] La figure 6 illustre un diagramme temporel d'un mode de réalisation du procédé selon l'invention, lorsqu'aucune correspondance n'a été trouvée dans le délai limite de la commande X. Dans ce cas, le chronométreur 103 envoie un message à l'apparicur de paiements 105, indiquant que le temps est écoulé pour la commande X, en appliquant la fonction de surveillance (MSG8). L'apparicur de paiements 105 demande ensuite au centre d'action 104 de traiter la commande X en demandant à la banque de l'utilisateur de finaliser l'achat (MSG4). Le centre d'action 104 demande à l'enregistreur historique de transaction 106 d'enregistrer l'historique de la transaction (MSG9). L'enregistrement de l'historique des transactions peut aider le serveur à option d'adhésion 101 à déterminer un pourcentage de succès de finalisation de la nouvelle commande entrante sur la base des résultats des requêtes précédentes. Le centre d'action 104 demande ensuite au serveur de paiement de procéder au paiement des commandes associées à la transaction réussie (MSG10). Dans un mode de réalisation particulier de l'invention pour l'industrie du voyage, le processus d'achat prend fin avec l'actualisation du billet de réservation, incluant la mise à jour de l'inventaire de la ligne aérienne et l'attribution d'un PNR (enregistrement de nom de passager) à l'utilisateur (MSG11). Par la suite, la commande X est retirée du livre de commandes 102 (MSG6). Finalement, l'utilisateur de la commande X est avisé par le centre d'action 104 qu'aucune correspondance n'a été trouvée (MSG12) et que l'achat a été finalisé en utilisant sa banque, ce qui pourrait entraîner des frais de commission bancaire. [0092] La figure 7 est une représentation schématique illustrant le cas dans lequel une commande auxiliaire devient une commande maître. Afin de générer une transaction, une commande Ordl est sélectionnée par le centre d'action 104. Cette commande Ordl est appelée commande maître de la première transaction TRI : elle contient la commande que la transaction TRI doit satisfaire. 17 [0093] Comme illustré par la figure 7, les commandes de la devise du produit associée à la commande maître 01 de la première transaction TRi peuvent être considérées comme des commandes auxiliaires. La commande maître 01 contient une référence à la transaction TRI ; qui est référencée comme étant une transaction contractuelle, dans laquelle elle est maître et les autres commandes ont des références à la transaction contractuelle TRi dans laquelle elles sont participantes. Quand presque la totalité de la commande maître 01 est appairée avec une ou plusieurs commandes auxiliaires (une commande auxiliaire 02 dans la figure 7), il y a peu de chances de trouver une commande qui corresponde exactement au montant restant. S'il y a une commande qui correspond exactement au montant restant, alors l'exécution de la commande maître est totalement finalisée. Ce cas est illustré dans la figure 2 qui a déjà été décrite. [0094] Sinon, une première option est de faire appel à la banque de l'utilisateur pour le petit montant restant. Avec la première option, la commission qui est prélevée par la banque est plus basse qu'avec les procédés de pointe. La deuxième option est de diviser une commande auxiliaire (commande 03) qui est désignée comme étant la commande auxiliaire 03 à diviser. La commande auxiliaire est composée d'une première partie devant être divisée 03, désignée comme commande de finalisation, pour finaliser la transaction contractuelle TRi ; l'autre partie de la commande auxiliaire devant être divisée 03 est désignée comme étant une commande restante qui devient une commande maître dans la prochaine transaction TR2, appelée transaction supplémentaire. Par conséquent, la nouvelle commande maître de la transaction supplémentaire TR2 est finalisée sur une base prioritaire. Par exemple, dans la figure 7, la commande 04 est une commande auxiliaire pour la transaction TR2. [0095] Optionnellement, le délai limite de la commande maître est plus bref que le délai limite de chacune des commandes auxiliaires. [0096] Dans un mode de réalisation particulier de l'invention, parmi toutes les commandes auxiliaires potentielles qui sont capables de finaliser la transaction TRI, la commande auxiliaire à diviser est celle dont la commande restante correspondante a une valeur de produit qui est minimisée. Par conséquent, dans l'éventualité où la transaction supplémentaire TR2 ne serait pas finalisée, le montant à convertir par la banque serait minimisé. [0097] Ce qui suit décrit les diverses contraintes qui sont prises en compte pour la fina- lisation des commandes. [0098] On note TRi la transaction ayant un repère «i ». [0099] La transaction TRI comprend un identifiant unique (i dans la notation ci-dessus), une référence à la commande maître MO à satisfaire, le délai limite de la transaction qui est égal à l'horodatage de la commande maître MO, et une liste de références aux commandes auxiliaires AOi (i=0... n) participant pour finaliser la commande maître 18 MO. [0100] Une transaction TRi intègre des commandes avec les contraintes suivantes : une garantie qu'aucune expiration des commandes auxiliaires AOk n'interrompera la transaction au cours de sa génération : pour chaque commande auxiliaire AOi, tMO M(MO) [0103] La somme des valeurs des commandes auxiliaires plus la valeur de la commande auxiliaire à diviser AOk est supérieure ou égale au montant de la commande maître. [0104] T(01) renvoie la valeur de la devise (devise de tarification) pour la commande i. [0105] M(01) renvoie la valeur de la devise pour la commande i. [0106] Le reste est minimisé : [0107] Reste(Px) = 7,2 il IT(P0i) T( C_)) - M(M0) [mos] , ! Ok, V 0i, Reste ( Ok) s Reste(0x) [0109] La Figure 8 illustre la vue dans les compartiments de la transaction. Dans chaque compartiment, M#cornrnande, CDdev = T#commande, TGdev RTGdev, CDdev, où M#commande, CDdev est le montant disponible dans la devise de paiement CDdev (correspondant à la valeur du produit) pour la commande #commande, T#commande, TGdev est la valeur du produit dans la devise cible TGdev pour la commande #commande (également appelée devise de tarification), et RTGdev, CDdev est le taux de conversion entre la devise de paiement CDdev et la devise cible TGdev. Selon un mode de réalisation particulier, le taux de conversion est le taux interbancaire (BSR) qui peut être téléchargé quotidiennement et actualisé. [0110] Le compartiment CURO contient les commandes qui sont associées au moyen de paiement dans la devise CURO. En particulier, le compartiment CURO contient une commande 01, associée à un délai limite tl pour la finalisation de l'exécution de la commande 01. M1,0 est le montant disponible dans la devise CURO pour la commande 01 (équivalent a la valeur du produit, mais dans la devise CURO), et l'utilisateur de la commande 01 veut acheter un produit ayant une valeur de produit T1,1 dans la devise cible (devise de tarification CURI pour la commande 01). Chaque compartiment contient autant de colonnes que nécessaire pour les devises cibles. Le compartiment CURI contient une commande 02, associée à un délai limite t2 pour la finalisation de l'exécution de la commande 02. M2,1 est le montant disponible dans la devise CUR I pour la commande 02 et l'utilisateur de la commande 02 veut acheter un produit ayant une valeur de produit T2,0 dans la devise cible (devise de tarification CURO pour la commande 02). 19 [0111] Une transaction contractuelle TR1 est générée. Puisque le délai limite tl est inférieur au délai limite t2, la commande 01 est la commande maître. La commande 02 est une commande auxiliaire dans l'accord de transaction TRI puisqu'elle est stockée dans compartiment CURI et est associée à la devise CURO. [0112] Le montant disponible dans la devise CURO est converti dans la devise CUR1, selon le taux interbancaire (BSR) entre les devises CURO et CURI. [0113] Après l'exécution de l'accord de transaction TR1, le montant disponible dans la devise CURO pour la commande 01 est M1,0-T2,0 et il y a encore un montant de T1,1-M2,1 à convertir dans la devise cible CUR1. [0114] Ensuite, comme illustrée par la figure 9, une autre commande 03 qui est stockée dans le compartiment CURI est impliquée pour participer à la transaction contractuelle TR1. La commande 03 est associée à un délai limite t3 pour la finalisation de l'exécution de la commande 03. M3,1 est le montant disponible dans la devise CURI pour la commande 03 et l'utilisateur de la commande 03 veut acheter un produit ayant une valeur de produit T3,0 dans la devise cible (devise de tarification CURO pour la commande 03). [0115] La commande 3 est divisée pour finaliser l'exécution de la transaction TR1. Par conséquent, lorsque la transaction contractuelle TRI a été exécutée, le montant disponible dans la devise CURO est nul. Dans le compartiment CUR1, la commande 03 a un montant disponible résiduel dans la devise CUR1. Par conséquent une autre transaction supplémentaire TR2 est générée. La commande maître est la commande 03. [0116] Une transaction peut aussi impliquer plus de deux devises, comme illustré par la figure 10. [0117] Parmi les commandes reçues, une première commande est déterminée, notamment celle qui a le délai limite le plus court (commande 01). La première commande 01 est reçue d'un premier utilisateur, comprenant une première valeur de produit T1.1, une première devise de tarification CURI associée à la première valeur de produit, une première devise d'utilisateur CURO associée au moyen de paiement du premier utilisateur. La première devise de tarification CURI est aussi appelée première devise cible. [0118] Une deuxième commande 05 est reçue d'un deuxième utilisateur, comprenant une deuxième valeur de produit T5.2, une deuxième devise de tarification CUR2 associée à la valeur du deuxième produit, une deuxième devise d'utilisateur CURI associée au moyen de paiement du deuxième utilisateur, ladite deuxième devise d'utilisateur et ladite première devise de tarification étant identiques. La deuxième devise de tarification CUR2 est aussi appelée deuxième devise cible. [0119] Une troisième commande 06 est reçue d'un troisième utilisateur, comprenant une troisième valeur de produit T6,0, une troisième devise de tarification CURO associée à la valeur du troisième produit, une troisième devise de paiement CUR2 associée au moyen de paiement d'un troisième utilisateur, ladite troisième devise de paiement et ladite devise de tarification de la deuxième commande étant identiques. La troisième devise de tarification et la devise de paiement de la première commande sont identiques. La troisième devise de tarification CUR2 est aussi appelée troisième devise cible. [0120] Avant le délai le plus bas de la première, deuxième et troisième commandes, la première commande 01 est exécutée en utilisant le moyen de paiement de la deuxième commande 05 ; la deuxième commande 05 est exécutée en utilisant le moyen de paiement de la troisième commande 06 et la troisième commande est exécutée en utilisant le moyen de paiement de la première commande 01. [0121] Dans la figure 10, trois devises sont impliquées. Le même procédé pourrait être im- plémenté pour plus de trois devises. [0122] Par conséquent, même des commandes impliquant des devises mineures (c.-à-d. des devises avec de petits volumes de transactions) peuvent être exécutées. [0123] Le mode de réalisation de l'invention impliquant trois devises ou plus peut aussi im- plémenter la division des commandes auxiliaires, afin de compléter la transaction contractuelle, car il a déjà été vu précédemment entre deux devises. [0124] TI a été montré que le procédé conformément à l'invention garantit qu'une transaction est toujours finalisée, même si cela signifie qu'il faut utiliser la banque de l'utilisateur. Le procédé garantit aussi qu'une commande pour une transaction (une à une, ou une à plusieurs) est toujours préférée à une conversion bancaire afin de finaliser une transaction. Par conséquent les commissions bancaires sont minimisées. 21 [Revendication 1] [Revendication 2] [Revendication 3] REVENDICATIONSUn procédé implémenté par ordinateur pour le traitement d'un ensemble des commandes dans un environnement informatisé, comprenant les étapes consistant à : a) recevoir un ensemble de commandes provenant d'un ensemble d'utilisateurs respectifs, chacune des commandes comprenant une valeur de produit, une devise de tarification associée à la valeur du produit, une devise de paiement associée au moyen de paiement de l'utilisateur, ladite devise de tarification et ladite devise de paiement étant différentes, chaque commande étant associée à un délai limite pour la finalisation de l'exécution de la commande, b) déterminer si ledit ensemble de commandes reçu comprend une première commande et un groupe d'au moins une deuxième commande, une du groupe d'au moins une deuxième commande ayant comme devise de paiement la devise de tarification de la première commande et une du groupe d'au moins une deuxième commande ayant comme devise de tarification la devise de paiement de la première commande, c) dans ce cas, avant le délai limite le plus bref de la première et une d'au moins ladite au moins une deuxième commande, l'exécution de la première commande en utilisant le moyen de paiement de ladite au moins une deuxième commande et l'exécution d'une de ladite au moins deuxième commande en utilisant le moyen de paiement de la première commande. Le procédé implémenté par ordinateur selon la revendication 1 dans lequel le groupe comprenant au moins une deuxième commande comprend une deuxième commande unique et dans lequel l'étape b) comprend le fait de déterminer si ladite première commande et ladite deuxième commande comprennent un couple de devises opposées de tarification et de devise de paiement. Le procédé implémenté par ordinateur selon la revendication 1 dans lequel le groupe comprenant au moins une deuxième commande comprend : - une deuxième commande comprenant une deuxième valeur de produit, une deuxième devise (le tarification associée à la valeur du deuxième produit, une deuxième devise de paiement associée au moyen de paiement d'un deuxième utilisateur, ladite deuxième devise de paiement et ladite devise de tarification de la première commande étant [Revendication 4] identiques, [Revendication 5] - une troisième commande comprenant une troisième valeur de produit, une troisième devise de tarification associée à la valeur du troisième produit et étant identique à la devise de paiement de la première commande, une troisième devise de paiement associée au moyen de paiement d'un troisième utilisateur, ladite troisième devise de paiement et ladite devise de tarification de la deuxième commande étant identiques, [Revendication 6] l'étape c) comprenant, avant le délai limite le plus bref de la première, deuxième et troisième commandes, l'exécution de la première commande en utilisant le moyen de paiement de la deuxième commande, l'exécution de la deuxième commande en utilisant le moyen de paiement de la troisième commande et l'exécution de la troisième commande en utilisant le moyen de paiement de la première commande. Le procédé implémenté par ordinateur selon l'une quelconque des revendications précédentes, dans lequel l'étape a) comprend le fait de transmettre à l'utilisateur qui a émis la commande un message relatif à la probabilité de la finalisation de l'exécution de la commande de l'utilisateur avant le délai limite. [Revendication 7] Le procédé implémenté par ordinateur selon l'une quelconque des revendications précédentes, dans lequel l'étape a) comprend, pour chacune des commandes de l'ensemble des commandes, le fait de vérifier la solvabilité du moyen de paiement de l'utilisateur relative à la valeur de produit associée à la commande et de transmettre la commande correspondante à une banque associée au moyen de paiement de l'utilisateur si la solvabilité n'est pas assurée. [Revendication 8] Le procédé implémenté par ordinateur selon l'une quelconque des revendications précédentes, comprenant une étape de stockage des commandes dans une base de données, ladite base de données comprenant une pluralité de sous-bases de données, les commandes qui ont la même devise d'utilisateur étant regroupées dans une même sous-base de données. Le procédé implémenté par ordinateur selon la revendication 6, comprenant une étape de retrait de la commande de la sous-base de données si l'exécution de la commande a été finalisée et/ou si le délai limite de la commande s'est écoulé. Le procédé implémenté par ordinateur selon l'une quelconque des revendications précédentes, comprenant : 23 [Revendication 9] [Revendication 10] [Revendication 11] [Revendication 12] [Revendication 13] - une étape de sélection parmi l'ensemble des commandes, d'une commande maître et au moins d'une commande auxiliaire correspondante, ladite au moins une commande auxiliaire contribuant à l'exécution de la commande maître, la somme des valeurs de produit des commandes auxiliaires étant plus élevée ou égale à la valeur du produit de la commande maître. - une étape de génération d'au moins une transaction contractuelle, la transaction contractuelle comprenant une référence à la commande maître, et une référence à chacune d'au moins ladite une commande auxiliaire. Le procédé implémenté par ordinateur selon la revendication 8, dans lequel il est compris une étape de détermination d'une commande auxiliaire devant être divisée et une étape de division de ladite commande auxiliaire en une commande restante et une commande de finalisation pour l'exécution de la commande maître, et dans lequel, en réponse à l'exécution de la commande maître, le procédé comprend une étape de génération d'une autre transaction supplémentaire, ladite autre transaction supplémentaire comprenant une référence à la commande restante comme étant une nouvelle commande maître et une référence à chacune d'au moins une commande auxiliaire contribuant à l'exécution de la nouvelle commande maître. Le procédé implémenté par ordinateur selon la revendication 9, dans lequel l'étape de détermination d'une commande auxiliaire à diviser comprend le fait de déterminer la commande restante correspondante dont la valeur de produit est minimisée Le procédé implémenté par ordinateur selon l'une quelconque des revendications précédentes, dans lequel il est compris une étape de transmission d'au moins une partie des commandes à une banque associée aux moyens de paiement de l'utilisateur, si l'exécution de la commande est partiellement achevée ou pas du tout achevée quand la durée limite de la commande s'est écoulée. Le procédé implémenté par ordinateur selon l'une quelconque des revendications précédentes, dans lequel il est compris une étape de transmission d'un message à l'utilisateur relatif aux résultats de l'étape b). Le procédé implémenté par ordinateur selon l'une quelconque des revendications précédentes, dans lequel il est compris une étape de stockage de l'historique des commandes pour lesquelles l'exécution a 24 [Revendication 14] [Revendication 15] été finalisée. Le procédé implémenté par ordinateur selon l'une quelconque des revendications précédentes, dans lequel la commande est un bon de commande. Un système (100) pour le traitement d'un ensemble de commandes dans un environnement informatisé, le système étant configure pour : a) recevoir, par un ordinateur, un ensemble de commandes provenant d'un ensemble d'utilisateurs respectifs, chacune des commandes comprenant une valeur de produit, une devise de tarification associée à la valeur du produit, une devise de paiement associée au moyen de paiement de l'utilisateur, ladite devise de tarification et ladite devise de paiement étant différentes, chaque commande étant associée à un délai limite pour la finalisation de l'exécution de la commande, h) déterminer, par l'ordinateur, que ledit ensemble de commandes reçues comprend une première commande et un groupe d'au moins une deuxième commande, une du groupe d'au moins une deuxième commande ayant comme devise de paiement la devise de tarification de la première commande et une du groupe d'au moins une deuxième commande ayant comme devise de tarification la devise de paiement de la première commande, c) dans ce cas, avant le plus bref délai limite de la première et au moins une d'au moins ladite une deuxième commande, exécuter la première commande en utilisant le moyen de paiement d'une de ladite au moins une deuxième commande et exécuter ladite au moins deuxième commande en utilisant le moyen de paiement de la première commande.