Brevet FR3079987A1 — publié le 20191011

Procédé de traitement d'une transaction entre un terminal source et un terminal destinataire, système de services bancaires, terminal et programme d'ordinateur correspondants. 1. Domaine de l'invention Le domaine de l'invention est celui des communications au sein d'un réseau de communication, par exemple un réseau IP. Plus précisément, l'invention offre une solution pour la mise en oeuvre de transactions, notamment financières, entre terminaux de communication (téléphone mobile, tablette, ordinateur, etc.). L'invention trouve notamment, mais non exclusivement, des applications dans le domaine du transfert d'argent entre utilisateurs de terminaux connectés à Internet. 2. Art antérieur Le réseau IP est le support universel d'une multitude de services et applications. Certains opérateurs de télécommunications utilisent notamment ce réseau IP pour supporter leurs différentes offres de service, par exemple leurs offres de services bancaires. Les opérateurs proposent un service de porte-monnaie électronique qui permet à leurs clients d'effectuer des transactions (virement bancaire, retrait d'espèces dans des commerces partenaires, crédit sur le porte-monnaie électronique du destinataire, recharge de crédit téléphonique, etc.) depuis leur terminal vers d'autres clients ayant souscrit au service, et situés, par exemple, en France, au Mali, en Côte d'Ivoire, au Sénégal ou en Guinée. Un inconvénient d'une telle technique est qu'elle nécessite que l'émetteur et le destinataire disposent d'un compte spécifique et soient clients du même opérateur qui propose un tel service de transaction bancaire. Un autre inconvénient est que l'offre de service est limitée à quelques pays (par exemple, France, Mali, Côte d'Ivoire, Sénégal ou Guinée). Encore un autre inconvénient est que les frais bancaires peuvent être élevés. Il existe donc un besoin pour une nouvelle technique de transaction financière entre terminaux présentant un faible coût, et qui soit notamment accessible quels que soient les opérateurs et la localisation de ces terminaux. 3. Exposé de l'invention L'invention propose une solution nouvelle pour le traitement d'une transaction entre un terminal source et un terminal destinataire, mettant en oeuvre une phase de transaction comprenant : - la réception, par un système de services bancaires, dit BTS (« Banking Transfer System » 2 en anglais) source, connecté au terminal source, d'une requête de transaction en provenance du terminal source, ladite requête comportant au moins un identifiant du terminal destinataire et un montant de transaction, l'obtention, par le BTS source, d'une information de localisation du terminal destinataire, 5 à partir d'au moins une base de données de localisation, notée BLDB (« BTS Location Data Base » en anglais), et de l'identifiant du terminal destinataire, la détermination, par le BTS source, d'au moins un système de services bancaires, dit BTS destinataire, connecté au terminal destinataire, à partir de l'information de localisation du terminal destinataire, 10 - si le BTS source n'est pas le BTS destinataire, au moins une itération des étapes suivantes, mises en oeuvre tant que la requête de transaction n'a pas atteint le BTS destinataire : o sélection d'un système de services bancaires intermédiaire, dit BTS intermédiaire, en tenant compte d'au moins un critère de sélection, 15 o transmission au BTS intermédiaire de la requête de transaction ; - la transmission au terminal destinataire, par le BTS destinataire, de la requête ou d'une information relative à la requête (comme le succès ou l'échec de la transaction). L'invention propose ainsi une nouvelle solution pour le traitement d'une transaction, par exemple une transaction bancaire, reposant sur l'utilisation d'au moins un système de services 20 bancaires, auquel est connecté le terminal source, et d'au moins une base de données de localisation permettant de localiser le terminal destinataire. En particulier, si le BTS source diffère du BTS destinataire (c.-à-d. si les terminaux source et destinataire ne sont pas connectés au même BTS), l'invention propose de mettre en réseau plusieurs BTS (pouvant appartenir à des opérateurs différents, être localisés dans des régions 25 différentes, mettre en oeuvre des technologies différentes, etc.) et, si plusieurs chemins sont possibles entre le BTS source et le BTS destinataire, de sélectionner le chemin respectant au moins un critère de sélection (par exemple un nombre de BTS intermédiaires minimal, un coût de transfert minimal, une distance minimale entre les BTS, un équilibrage du nombre ou du montant des transactions entre différents opérateurs, etc.). 30 Ainsi, selon un mode de réalisation particulier, suite à une demande de transfert d'argent par exemple, les BTS mis en réseau peuvent engager une négociation globale pour aboutir au chemin de transfert qui donnera lieu à la commission de transfert la plus faible. En particulier, un mode de réalisation de l'invention propose une solution innovante 3 permettant aux opérateurs de télécommunication de diversifier leurs offres, notamment dans le secteur bancaire, en offrant à leurs clients la possibilité d'exécuter des transactions financières quels que soient leurs moyens d'accès au réseau (fixe ou mobile), quels que soient leurs moyens de communication (par ex., SMS, paquets IP), et respectant des contraintes en matière de 5 sécurité, de confidentialité, de rapidité d'exécution et de robustesse des échanges transactionnels. Selon un exemple de mise en oeuvre de l'invention, la mutualisation des ressources et/ou des procédures pour vérifier l'identité d'un utilisateur, ainsi que l'apport du « tout IP », permettent de réduire les coûts de transfert, tout en s'affranchissant des contraintes techniques 10 telles que celles observées pour les modes de transfert monétaires pratiqués actuellement (par ex., déplacement du client destinataire de la transaction vers une agence où il/elle pourra récupérer l'argent transféré, fourniture de mots de passe, etc.). Selon au moins un mode de réalisation, l'invention propose une amélioration des services de transactions bancaires en permettant notamment aux différents acteurs de bénéficier d'une 15 infrastructure de communication capable de supporter des échanges transactionnels afin de délivrer un service à valeur ajoutée attractif : transactions exécutées de manière quasi immédiate et compatibles avec l'itinérance (« roaming » en anglais) des destinataires, frais de transfert réduits, etc. Selon au moins un mode de réalisation, la solution proposée permet de résoudre au 20 moins un inconvénient des techniques de l'art antérieur, et présente au moins un des avantages ci-dessous : la solution proposée n'impose pas de contrainte technique : o le moyen de communication utilisé entre le terminal source et le BTS source peut être le réseau mobile, un service de connectivité IP, le réseau PSTN (« Public 25 Switched Telephone Network )> en anglais, ou réseau téléphonique commuté), un compte Facebook®, etc. ; o le BTS source et le BTS destinataire peuvent être distincts, et gérés par des opérateurs distincts ; o le moyen de communication utilisé entre le terminal source et le BTS source peut 30 être différent de celui utilisé entre le BTS destinataire et le terminal destinataire ; par exemple, l'émetteur de la transaction peut utiliser sa connexion Internet fixe pour initialiser la transaction, alors que le destinataire de la transaction est identifié avec un numéro de mobile ou un compte Facebook® ; 4 la solution proposée n'impose pas de contrainte géographique : les transactions ne sont pas limitées à un seul opérateur, un seul pays, ou un ensemble de pays. La connectivité globale permet un déploiement d'un service de traitement d'une transaction, par exemple un transfert d'argent, à grande échelle et de façon immédiate, tout en 5 capitalisant sur les infrastructures IP existantes, les services mobiles à valeur ajoutée, etc. la solution proposée permet de découvrir automatiquement les BTS existants, d'établir automatiquement des accords d'interconnexion, d'échanger les données de placement de transactions, de placer les transactions, etc. ; la solution proposée est dynamique : par exemple, en cas d'itinérance du destinataire, 10 une somme d'argent transférée peut être disponible dans la nouvelle zone de couverture du destinataire (notée par exemple « Visited ») et plus seulement dans sa zone de rattachement (notée par exemple « Home ») ; la solution proposée est fiable : les BTS peuvent choisir dynamiquement les chemins adéquats pour une meilleure fiabilité des transactions ; 15 un coût de transfert maximum peut être défini pour un BTS, et les frais réels peuvent être négociés à la baisse au moment de l'exécution de la transaction. Les coûts de transfert ne sont donc pas nécessairement fixes ; l'émetteur de la transaction n'a pas besoin de contacter le destinataire pour lui communiquer un mot de passe que ce dernier devrait présenter pour pouvoir récupérer 20 le montant transféré ; etc. Au moins un mode de réalisation de l'invention concerne également un système de services bancaires, dit BTS, pour le traitement d'une transaction entre un terminal source et un terminal destinataire, comprenant au moins une machine de calcul programmable ou une 25 machine de calcul dédiée configurée pour : recevoir et/ou transmettre une requête de transaction, ladite requête portant au moins un identifiant du terminal destinataire et un montant de transaction, obtenir une information de localisation du terminal destinataire, à partir d'au moins une base de données de localisation, notée BLDB, et de l'identifiant du terminal destinataire, 30 déterminer au moins un système de services bancaires, dit BTS destinataire, connecté au terminal destinataire, à partir de l'information de localisation du terminal destinataire, sélectionner au moins un système de services bancaires intermédiaire, dit BTS intermédiaire, en tenant compte d'au moins un critère de sélection. 5 En particulier, un tel BTS peut être un BTS source, un BTS intermédiaire, ou un BTS destinataire. Un BTS peut mettre en oeuvre un service dit de courtage ou « brokering » (BTS « broker ») pour sélectionner un BTS intermédiaire en tenant compte d'au moins un critère de sélection. 5 Dans le cas d'un BTS source, connecté au terminal source, le BTS source peut recevoir la requête de transaction en provenance du terminal source. Si le BTS source est le BTS destinataire, c.-à-d. s'il est également connecté au terminal destinataire, il peut transmettre la requête au terminal destinataire. Si le BTS source n'est pas le BTS destinataire, il peut transmettre la requête au BTS destinataire, éventuellement via un BTS intermédiaire. 10 Dans le cas d'un BTS destinataire, connecté au terminal destinataire, le BTS destinataire peut recevoir la requête de transaction en provenance du BTS source ou d'un BTS intermédiaire. Il peut transmettre la requête de transaction au terminal destinataire. Dans le cas d'un BTS intermédiaire, ce dernier peut recevoir la requête de transaction en provenance du BTS source ou d'un autre BTS intermédiaire. Il peut transmettre la requête de 15 transaction à un autre BTS intermédiaire ou au BTS destinataire. Par exemple, un tel BTS (source, destinataire ou intermédiaire) comprend : - au moins une entité d'exécution (BTA, pour « BTS Transfer Agent)> en anglais)) apte à mettre en oeuvre au moins une étape appartenant au groupe comprenant : o la réception et/ou transmission de la requête de transaction, 20 o l'obtention d'une information de localisation du terminal destinataire, o la détermination du BTS destinataire, o la sélection d'au moins un BTS intermédiaire. - au moins une base de données de localisation, ou des moyens d'accès à au moins une base de données de localisation externe, 25 - au moins une entité d'interconnexion (BIE, pour « BTS Interconnect Element », en anglais) permettant d'interconnecter des BTS. L'invention concerne également un terminal, source ou destinataire, utilisé pour le traitement d'une transaction. Par exemple, un tel terminal comprend au moins une machine de calcul programmable ou une machine de calcul dédiée configurée pour émettre une requête de 30 transaction, ladite requête comportant au moins un identifiant du terminal destinataire et un montant de transaction. Dans un autre mode de réalisation, l'invention concerne un ou plusieurs programmes d'ordinateur comportant des instructions pour la mise en oeuvre du procédé de traitement d'une 6 transaction selon au moins un mode de réalisation de l'invention, lorsque ce ou ces programmes est/sont exécuté(s) par un processeur. Dans encore un autre mode de réalisation, l'invention concerne un ou plusieurs supports d'informations, inamovibles, ou partiellement ou totalement amovibles, lisibles par un ordinateur, 5 et comportant des instructions d'un ou plusieurs programmes d'ordinateur pour l'exécution des étapes du procédé de traitement d'une transaction selon au moins un mode de réalisation de l'invention. Les procédés selon l'invention peuvent donc être mis en oeuvre de diverses manières, notamment sous forme câblée et/ou sous forme logicielle. 10 4. Liste des figures D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation particulier, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : la figure 1 illustre un exemple de mise en réseau de BTS pour acheminer une requête de 15 transaction d'un terminal source vers un terminal destinataire ; les figures 2A et 2B illustrent des exemples de connexion entre systèmes de services bancaires (BTS) ; la figure 3 présente les principales étapes du procédé de traitement d'une transaction selon un mode de réalisation particulier de l'invention ; 20 - la figure 4 illustre un exemple d'entités composant un BTS; la figure 5 illustre un exemple de mutualisation d'une base de données de localisation ; la figure 6 présente un exemple de mise en oeuvre d'une phase de découverte de BTS; la figure 7 présente un exemple de mise en oeuvre d'une phase d'interconnexion entre BTS; 25 - les figures 8 et 9 proposent deux exemples de mise en oeuvre d'une phase d'échange de données de localisation entre BTS; les figures 10 à 13 présentent des exemples de mise en oeuvre d'une phase de transaction, que le terminal source soit connecté au même BTS que le terminal destinataire ou pas ; 30 - la figure 14 illustre l'utilisation de plusieurs entités d'exécution au sein d'un BTS selon un mode de réalisation particulier ; la figure 15 présente un exemple de mise en oeuvre de l'invention en cas d'itinérance du terminal destinataire ; et 7 la figure 16 présente la structure simplifiée d'un BTS selon un mode de réalisation particulier. 5. Description d'un mode de réalisation de l'invention 5./ Principe général 5 Le principe général de l'invention repose sur l'utilisation d'au moins un nouveau système, appelé système de services bancaires ou BTS (« Banking Transfer System »), et la mise en réseau de tels systèmes, pour acheminer une requête de transaction d'un émetteur vers un bénéficiaire. Par exemple, comme illustré en figure 1, un ou plusieurs BTS 131, 132 peuvent être utilisés pour acheminer une requête de transaction émise par un terminal source 11 vers un 10 terminal destinataire 12, dans au moins un réseau de communication IP par exemple. Un réseau de communication IP, ou un ensemble de réseaux IP qui forment un système autonome AS (« Autonomous System »), peuvent héberger un ou plusieurs BTS. Un BTS peut être également être connecté à plusieurs AS. Un BTS peut être opéré par un opérateur bancaire. Cet opérateur bancaire peut aussi agir en tant qu'opérateur de services mobiles (c.-à-d., un opérateur 15 d'un PLMN (« Public Land Mobile Network »)), en tant qu'opérateur de service de connectivité, etc. Un BTS, selon au moins un mode de réalisation de l'invention, est donc un système utilisé pour fournir des services bancaires, tels que le transfert de fonds monétaires. Le terminal source 11, associé à l'émetteur, et le terminal destinataire 12, associé au 20 bénéficiaire, peuvent être enregistrés auprès de BTS différents. Par exemple, le terminal source 11 est connecté au BTS A 131, dit BTS source, et le terminal destinataire est connecté au BTS B 132, dit BTS destinataire. Les transactions ne sont donc pas nécessairement intra-opérateur, mais peuvent être inter-opérateur, par exemple lorsque l'émetteur est client d'un premier opérateur (Orange® par exemple) alors que le bénéficiaire est client d'un deuxième opérateur (British 25 Telecom® par exemple). Comme illustré en figures 2A et 2B, les différents BTS peuvent être connectés via le réseau Internet, ou via un ou plusieurs AS. Un BTS (par exemple le BTS B 132) peut notamment être multi-connecté, pour garantir une meilleure disponibilité de la connectivité Internet. Chaque BTS peut être identifié avec un code globalement unique, appelé identifiant BTS 30 ou BTID (« BTS Identifier »). Ce code peut être utilisé pour identifier d'une manière univoque un BTS à l'échelle mondiale. L'identifiant BTID peut par exemple utiliser un code BIC (« Bank Identifier Code ») ou code SWIFT (« Society for Worldwide Interbank Financial Telecommunication »), c.-à-d. le numéro d'identification internationale de l'opérateur bancaire 8 opérant le BTS. Un tel identifiant BTID peut notamment être utilisé pour la découverte des domaines BTS existants ou pour acheminer une requête de transaction. On présente ci-après, en relation avec la figure 3, les principales étapes d'un procédé de traitement d'une transaction entre un terminal source et un terminal destinataire, selon au moins 5 un mode de réalisation de l'invention, mises en oeuvre au cours d'une phase de transaction. En reprenant l'exemple de la figure 1, le BTS source 131 reçoit (31) une requête de transaction, par exemple dans un message de type « TRANSFER », en provenance du terminal source 11. Une telle requête porte au moins un identifiant du terminal destinataire 12 et un montant de transaction. 10 Selon au moins un mode de réalisation de l'invention, la requête de transaction comporte, en plus de l'identifiant du terminal destinataire et du montant de la transaction, au moins une information appartenant au groupe comprenant : une devise ou une unité utilisée pour la transaction, une date d'exécution de la transaction, 15 un indicateur indiquant si le terminal source souhaite être informé de l'état de la transaction. A partir de l'identifiant du terminal destinataire 12 et d'au moins une base de données de localisation 311, notée BLDB, interne au BTS source ou accessible par le BTS source, le BTS source obtient (32) une information de localisation du terminal destinataire 12. 20 Le BTS source utilise cette information de localisation du terminal destinataire 12 pour déterminer (33) le BTS destinataire 132, notamment l'identifiant BTID du BTS destinataire 132. Si le BTS source est le BTS destinataire (c.-à-d. si les terminaux source 11 et destinataire 12 sont connectés au même BTS), le BTS transmet (35) la requête de transaction au terminal destinataire, ou une information relative à la transaction (comme un succès ou un échec). On 25 note que des informations complémentaires peuvent être ajoutées à la requête de transaction avant son envoi au terminal destinataire. Si le BTS source n'est pas le BTS destinataire (c.-à-d. si l'identifiant BTID du BTS source et l'identifiant BTID du BTS destinataire sont différents), le procédé de traitement d'une transaction met en oeuvre au moins une itération 34 des étapes suivantes, tant que la requête de transaction 30 n'a pas été reçue par le BTS destinataire : - sélection 341 d'un système de services bancaires intermédiaire, dit BTS intermédiaire, en tenant compte d'au moins un critère de sélection. Par exemple, le critère de sélection appartient au groupe comprenant : 9 - un coût de transfert minimal (par exemple un taux de change et/ou des frais de commission minimaux) ; - un nombre de BTS intermédiaires minimal ; - une distance minimale entre deux BTS; 5 - un équilibrage du nombre ou du montant des transactions entre différents opérateurs ; - etc. - transmission 342 au BTS intermédiaire de la requête de transaction. On note que des informations complémentaires, comme l'identifiant BTID du BTS transmettant la 10 requête et/ou recevant la requête, peuvent être ajoutées à la requête de transaction avant son envoi au BTS intermédiaire. Le critère d'arrêt des itérations est notamment la réception, par le BTS destinataire, de la requête de transaction. Le dernier BTS « intermédiaire » sélectionné est donc, dans ce cas, le BTS destinataire. 15 Lorsqu'un BTS destinataire a reçu la requête de transaction, ce dernier peut la transmettre (35) au terminal destinataire, éventuellement accompagnée d'informations complémentaires. Le BTS destinataire peut transmettre au terminal destinataire, en complément ou à la place de la requête de transaction, une information relative à la transaction, comme un échec ou un succès. 20 Le terminal destinataire 12 peut alors confirmer au terminal source 11 la bonne réception de la requête, en utilisant le même chemin de transmission via les BTS, ou pas. 5.2 Description d'un mode de réalisation particulier A) Définitions On présente ci-après, en relation avec la figure 4, un mode de réalisation particulier de 25 l'invention, selon lequel un BTS 41, identifié par exemple par l'identifiant BTID#1, est composé de plusieurs entités physiques et/ou fonctionnelles, comprenant notamment : au moins une entité d'interconnexion 411, ou BIE (« BTS Interconnect Element »), responsable de la connexion d'un BTS avec au moins un autre BTS. Plusieurs entités d'interconnexion BIE peuvent être actives au sein d'un même BTS. De même, plusieurs BTS 30 peuvent mutualiser une même entité d'interconnexion BIE; une base de données de localisation 412, ou BLDB (« BTS Location Data Base »), stockant les informations de localisation des terminaux connectés localement au BTS ou connectés à un BTS distant. Par exemple, la BLDB comprend : 10 o une base de données locale 4121, ou LLDB (« BTS Local Data Base »), comprenant des informations de localisation relatives à au moins un terminal connecté au BTS local, identifié par un identifiant. En d'autres termes, cette LLDB est responsable de maintenir les informations de localisation (par exemple des adresses de contacts) 5 permettant de joindre les bénéficiaires connectés localement au BTS. En particulier, la LLDB peut contenir des adresses E.164, des numéros MSISDN (« Mobile Station ISDN Number »), des URI SIP (« Uniform Resource Identifier for the Session Initiation Protocol »), des adresses IP, etc. Selon un premier exemple, un opérateur BTS qui est aussi un opérateur de 10 télécommunications peut utiliser sa base MSISDN comme base LLDB pour identifier les clients qui peuvent être localement bénéficiaires d'une transaction. Selon un deuxième exemple, un opérateur BTS peut mettre en place une procédure d'enregistrement spécifique qui alimente la LLDB. o une base de données d'interconnexion 4122, ou BIDB (« BTS Interconnect Data 15 Base »), comprenant des informations de localisation relatives à au moins un terminal connecté à au moins un BTS distant. En d'autres termes, cette BIDB est responsable de la maintenance des informations de localisation (par exemple des adresses de contacts) permettant de joindre les bénéficiaires qui ne sont pas connectés au BTS local, mais à des BTS distants. 20 Par exemple, les informations de localisation relatives à au moins un terminal connecté à au moins un BTS distant comprennent : - un identifiant BTID du BTS distant, - une information de localisation (par exemple une adresse de contact) d'au moins une entité d'interconnexion BIE (du BTS distant) permettant de connecter le BTS 25 local au BTS distant (« BIE Peer » en anglais), etc. On note qu'une entité d'interconnexion BIE peut être co-localisée avec la base de données de localisation BLDB. L'accès à la BIE est par exemple effectué avec la même adresse de contact que l'accès à la BLDB. La base de données de localisation BLDB peut également être instanciée sur plusieurs BIE. 30 Dans ce cas, une synchronisation à l'aide de mécanismes dédiés peut être mise en oeuvre. Par ailleurs, la base de données de localisation BLDB peut être stockée localement dans un BTS, ou bien externalisée et accessible par le BTS. Par exemple, comme illustré en figure 5, la base de données locale peut être locale à un BTS (LLDB 51 locale au BTS 11 portant l'identifiant BTID#1, LLDB 52 locale au BTS portant l'identifiant BTID#2), et la base de données d'interconnexion BIDB peut être soit locale à un BTS, soit mutualisée entre plusieurs BTS (BIDB 53 mutualisée entre les BTS BTID#1 et BTID#2), par exemple lorsque les opérateurs BTS gérant ces BTS sont membres d'une alliance bancaire qui se charge 5 entre autres d'héberger la base de données d'interconnexion BIDB. au moins une entité d'exécution 413, ou BTA (« BTS Transfer Agent »), responsable de l'exécution des demandes de transaction. Elle assure notamment l'acheminement d'une demande de transaction vers un BIE afin de permettre au BTS connecté au destinataire de la transaction de terminer l'opération. 10 Une ou plusieurs entités BTA peuvent être activées au sein d'un BTS. Afin d'acheminer une requête de transaction, une entité BTA sollicite la base de données de localisation BLDB. Chaque entité BTA dispose des informations nécessaires pour contacter soit globalement la base de données de localisation BLDB (invocation « générique »), soit directement la base de 15 données locale LLDB ou la base de données d'interconnexion BIDB (invocation « spécifique »). Une entité BTA peut également mettre en oeuvre au moins une opération appartenant au groupe comprenant : vérifier qu'un montant de transfert maximum n'est pas atteint, vérifier la conformité du dossier de l'émetteur de la requête de transaction (par ex., 20 éléments de solvabilité, plafond attribué à l'émetteur) avec la législation en vigueur, vérifier la disponibilité des fonds à transférer, etc. Comme illustré en figure 4, un terminal 42 peut être connecté à un ou plusieurs BTS 41. Le réseau de transport 43 entre le terminal 42 et le BTS 41 peut reposer sur différentes technologies 25 (PSTN, PLMN, IP, SIP, etc.). Aucune contrainte n'est imposée quant à la nature du transport utilisé pour acheminer une requête de transfert émise par un terminal vers un BTS, notamment vers l'entité BTA du BTS. Un terminal selon l'invention est par exemple un terminal mobile, un terminal embarquant une instance logicielle spécifique, un terminal SIP, un terminal téléphonique, un 30 ordinateur personnel, etc. En particulier, un tel terminal est équipé d'une fonction autorisant le traitement de transaction, ou UTA (« User Transfer Agent »). Un terminal peut être un applicatif dédié (typiquement, une application mobile), un service accessible via un client générique (typiquement un client de messagerie ou un portail client) embarqué dans un autre client logiciel 12 (par exemple, un client WebRTC embarqué dans un navigateur Web), etc. Un tel applicatif dédié ou client logiciel peut être accessible depuis un ou plusieurs terminaux physiques. On appelle ci-après « terminal UTA », ou plus simplement terminal, tout terminal équipé d'une telle fonction permettant le traitement de transactions selon l'invention. 5 Un terminal UTA peut être identifié avec un identifiant globalement unique, appelé identifiant UTA (« UTA Identifier ») ou UTA _ID. Cet identifiant UTA est par exemple un numéro MSISDN, un URI SIP, une adresse mail, etc. Aussi, un terminal UTA peut être localisé, et donc contacté, à partir des informations de localisation. On appelle localisateur UTA (« UTA Locator ») ou UTA_LOC les informations de 10 localisation d'un terminal UTA. Un localisateur UTA est par exemple un numéro MSISDN, un URI SIP, un numéro PSTN, une adresse IP, etc. L'identifiant UTA et son localisateur UTA peuvent être identiques ou différents. Un même terminal UTA peut être associé avec plusieurs identifiants. Corolairement, un même localisateur UTA peut être utilisé pour localiser plusieurs identifiants UTA. 15 Un même identifiant UTA peut être joignable avec un ou plusieurs localisateurs UTA. L'identité du BTS à solliciter pour les transactions, ou plus spécifiquement l'identité de l'entité BTA du BTS à solliciter, peut être dynamiquement configurée sur un terminal UTA (par exemple, en utilisant l'élément d'information IE (« Information Element ») du protocole PCO (« Protocol Configuration Options »), le protocole DHCP (« Dynamic Host Configuration 20 Protocol ») ou utiliser un nom de domaine dédié (par exemple, « bta.bts.orange »). Un terminal UTA peut être connecté à un ou plusieurs BTS. Dans ce cas, l'identifiant UTA de ce terminal est présent dans les bases de données de localisation BLDB associées à ces différents BTS. Préalablement au traitement des transactions, un terminal UTA et un BTS (ou plus 25 spécifiquement une entité BTA du BTS) peuvent s'authentifier mutuellement. L'authentification mutuelle peut par exemple utiliser le protocole EAP (« Extensible Authentication Protocol ») et plus précisément EAP-TTLS (« EAP Tunneled Transport Layer Security »). L'authentification, par l'entité BTA du BTS, d'un terminal UTA connecté au BTS, et/ou l'authentification, par le terminal UTA, de l'entité BTA du BTS peuvent être mises en oeuvre au 30 cours d'une phase d'initialisation préalable à la phase de transaction. B) lnitialisation d'un BTS Afin de pouvoir traiter une transaction, le procédé de traitement d'une transaction selon au moins un mode de réalisation de l'invention met en oeuvre une phase d'initialisation d'au 13 moins un BTS. Un tel BTS peut être un BTS source, un BTS intermédiaire, ou un BTS destinataire. Selon au moins un mode de réalisation, la phase d'initialisation d'un BTS, dit BTS local, comprend la construction ou mise à jour de la base de données de localisation BLDB. Par exemple, la base de données locale LLDB est initialisée avec les identifiants et 5 localisateurs des terminaux connectés au BTS local (UTA _ID, UTA_LOC). Eventuellement, la base de données locale (LLDB) stocke également des informations relatives aux services bancaires, appartenant au groupe comprenant : un montant maximum de transfert autorisé par terminal, éventuellement par unité de temps (par exemple par jour, par semaine, par mois, etc.) ; 10 un nombre maximum de transferts autorisés par terminal, éventuellement par unité de temps (par exemple par jour, par semaine, par mois, etc.) ; etc. La base de données d'interconnexion BIDB peut également être initialisée. Au démarrage, cette base peut être vide ou alimentée par d'autres moyens. 15 La phase d'initialisation du BTS local peut également mettre en oeuvre la configuration / activation d'au moins une entité d'exécution BTA et/ou d'au moins une entité d'interconnexion BIE du BTS local avec au moins une information de localisation de la base de données de localisation BLDB. Par exemple, chacune des entités BTA et BIE est configurée avec une liste d'adresses pour contacter la base BLDB. Des adresses spécifiques, typiquement des adresses IP ou 20 des noms DNS, peuvent également être utilisées pour joindre directement la base de données locale LLDB ou la base de données d'interconnexion BIDB. A l'issue de cette phase d'initialisation, un BTS local est prêt à traiter des requêtes de transactions locales (c.-à-d. entre un terminal source et un terminal destinataire connectés au même BTS local), mais aussi à se connecter avec d'autres BTS. Aussi, le BTS local peut annoncer 25 aux BTS distants qu'il est prêt à se connecter avec eux. C) Découverte des BTS Selon au moins un mode de réalisation de l'invention, le procédé de traitement d'une transaction comprend une phase de découverte d'au moins un BTS distant, comprenant l'envoi par un BTS local, dans au moins un réseau de communication auquel est connecté le BTS local, 30 d'un message de découverte indiquant la capacité du BTS local à traiter des transactions. Par exemple, le message de découverte porte au moins un identifiant du BTS local et une information de localisation d'au moins une entité d'interconnexion permettant de connecter le BTS local avec le ou les BTS distants. Eventuellement, le message de découverte porte au moins 14 une information complémentaire appartenant au groupe comprenant : une information indiquant si le BTS local est un BTS source, destinataire, ou intermédiaire ; une information indiquant la région où opère le BTS local ; 5 un agrégat, ou une liste, d'identifiants de terminaux connectés au BTS local ; des conditions tarifaires de transfert entre BTS ; etc. En particulier, comme illustré par la figure 2B, un BTS peut utiliser les ressources d'un ou plusieurs système(s) autonome(s) pour se connecter à Internet. Par exemple, un BTS peut activer 10 un protocole de routage entre BTS (par exemple le protocole BGP) ou utiliser des routes statiques pour se raccorder au(x) réseau(x) du ou des opérateur(s) en charge de l'exploitation du ou des AS : la connexion d'un BTS à plusieurs AS permet ainsi d'améliorer la disponibilité, voire l'efficacité du service de transaction proposé par le BTS. Lorsqu'un BTS utilise les ressources du protocole BGP pour annoncer sa capacité à se 15 connecter à d'autres BTS, le message de découverte peut comporter un nouvel attribut BGP pour annoncer une telle capacité : l'attribut BTS_CAPABLE. Un tel attribut peut être défini en tant qu'attribut « Extended Community », comportant les informations suivantes : - « BSID » : l'identifiant du BTS émettant l'attribut BTS_ CAPABLE; - « BIE Locator(s) » : une liste d'adresses d'entités d'interconnexion BIE ; 20 et optionnellement : - « BTS Role » : une information indiquant si le BTS émettant l'attribut BTS_ CAPABLE est un BTS intermédiaire (ou transitaire) ou feuille (c.-à-d. source ou destination) ; - « Country Code(s) » : le ou les pays où opère ce BTS; - « UTA Prefix Aggregate » : un agrégat, ou une liste, d'identifiants de terminaux UTA 25 attachés au BTS émettant l'attribut BTS_CAPABLE. Par exemple, ce champ peut contenir « +212* » pour n'importe quelle destination au Maroc, « +2126* » pour tous les numéros mobiles commençant par « 6 », « *@orange.fr » pour tous les clients disposant d'une adresse mail « orange.fr », etc. ; - « Transfer Rate » : les conditions tarifaires de transfert inter-BTS ; 30 - etc. Le message BGP comportant l'attribut BTS_CAPABLE est propagé par les routeurs du ou des AS au(x)quel(s) est raccordé le BTS local. Un tel message est ensuite propagé par BGP dans les AS susceptibles d'être impliqués dans l'acheminement de trafic caractéristique de transactions, et 15 qui constituent tout ou partie du réseau Internet. L'activation de BGP par un BTS n'est pas obligatoire si les AS exposent des interfaces dédiées aux BTS pour injecter des informations dans BGP via ledit AS. A titre d'exemple, la figure 6 illustre un BTS local, le BTS A 61, dont l'identifiant « BTID=A » 5 est annoncé à l'aide de l'attribut BTS_CAPABLE via son opérateur d'accès qui exploite AS1 62. Cette information est transmise aux voisins d'AS1, les systèmes autonomes A52 63 et A53 64, selon les connexions BGP en place. De proche en proche, l'information selon laquelle le BTS A 61 est prêt à se connecter à d'autres BTS est ainsi propagée vers les BTS distants, tels que le BTS B 65. 10 Bien entendu, des techniques autres que l'utilisation d'un nouvel attribut BGP pour annoncer la capacité d'un BTS à se connecter à un autre BTS peuvent être mises en oeuvre, comme l'utilisation de DNS SRV (« Domain Name System SeRVice (record) ») par exemple. D) Interconnexion de BTS Selon au moins un mode de réalisation de l'invention, le procédé de traitement d'une 15 transaction comprend une phase d'interconnexion d'un BTS local avec au moins un BTS distant comprenant : l'obtention, par le BTS distant, d'une information de localisation d'au moins une entité d'interconnexion BIE permettant de connecter le BTS local avec le BTS distant. Par exemple, une telle information de localisation peut être portée par le message de 20 découverte ; l'envoi, par le BTS distant, d'un message de demande d'interconnexion à l'entité d'interconnexion BIE localisée par l'information de localisation. Selon un mode de réalisation particulier, chaque BTS dispose d'une base de données qui répertorie les accords d'interconnexion établis ou en cours d'établissement avec d'autres BTS. En 25 d'autres termes, un BTS local ne peut pas communiquer avec n'importe quel BTS distant. Un accord d'interconnexion doit exister, ou être en cours d'établissement, pour que deux BTS puissent communiquer. Une telle base de données est par exemple gérée par une entité d'interconnexion BIE responsable de la négociation des accords d'interconnexion. Cette base de données peut également être gérée par une autre entité du BTS. 30 Un BTS distant peut également filtrer le ou les messages de découverte reçu(s) (et comportant par exemple l'attribut BTS_CAPABLE) pour ne retenir que certains BTS en vue de l'établissement d'accords d'interconnexion. Ainsi, la phase d'interconnexion comprend éventuellement : 16 la vérification, par le BTS local, d'un accord d'interconnexion entre le BTS local et le BTS distant, la transmission, par le BTS local, d'un message d'acceptation ou non de la demande d'interconnexion, 5 la mise à jour de la base de données d'interconnexion (BIDB) associée au BTS local et/ou au BTS distant. A titre d'exemple, en référence à la figure 6, le BTS B 65 dispose des informations nécessaires pour envoyer un message de demande d'interconnexion vers le BTS A 61. En particulier, le BTS B 65 dispose d'au moins une adresse IP affectée à l'entité d'interconnexion BIE 10 du BTS A 61 à contacter pour initialiser une demande d'interconnexion ; cette information est contenue dans l'attribut BTS_CAPABLE. Par exemple, pour envoyer une demande d'interconnexion vers le BTS A 61, le BTS B 65 génère un message BTS_INTERCONNECT (BSID, NONCE, [CC, UTA Prefix Aggregate, Transfer Rate, ...]) qu'il envoie à l'adresse IP de l'entité d'interconnexion BIE du BTS A 61, telle qu'annoncée dans 15 l'attribut BTS_CAPABLE. Les arguments du message BTS_INTERCONNECT() comprennent par exemple : « BSID » : l'identifiant du BTS émettant le message BTS_INTERCONNECT, « NONCE)> : une clé générée aléatoirement par le BTS émettant le message BTS_INTERCONNECT. Cette clé peut être incluse dans la réponse à ce message 20 BTS_INTERCONNECT; « CC » : le ou les pays desservis par le BTS émettant le message BTS_INTERCONNECT. Cette information peut être utilisée par le BTS recevant le message BTS_INTERCONNECT pour traiter la demande d'interconnexion ; « UTA Prefix Aggregate » : un agrégat, ou une liste, d'identifiants de terminaux UTA 25 attachés au BTS émettant le message BTS_INTERCONNECT; « Transfer Rate » : les conditions tarifaires de transfert inter-BTS ; « Type » : un type associé à la demande d'interconnexion : - « 0 » ou « Bidirectional » : les requêtes en transaction peuvent être émises par le BTS émettant le message BTS_INTERCONNECT et le BTS recevant le message 30 BTS_INTERCONNECT; - « 1 » ou « Send-only » : seul le BTS émettant le message BTS_INTERCONNECT peut émettre des requêtes en transaction ; 17 - « 2 » ou « Receive-only » : seul le BTS recevant le message BTS_INTERCONNECT peut émettre des requêtes en transaction ; - d'autres valeurs peuvent également être définies. En référence à la figure 6, à réception du message de demande d'interconnexion 5 BTS_INTERCONNECT par une entité d'interconnexion BIE du BTS A 61, celui-ci procède à des vérifications, comme par exemple vérifier que le BTS B 65 ne fait pas partie d'une liste noire. Comme illustré en figure 7, pour accepter une demande d'interconnexion, le BTS A 61 peut répondre avec un message d'acceptation OK(BSID, NONCE, [CC, UTA Prefix Aggregate, Transfer Rate, Redirect_BIE, ...]). Les paramètres du message d'acception OK comprennent par 10 exemple : - « BSID » : l'identifiant du BTS émettant le message OK; - « NONCE)> : la clé générée aléatoirement par le BTS ayant émis le message BTS_INTERCONNECT, recopiée de la demande BTS_INTERCONNECT associée ; - « CC » : le ou les pays desservis par le BTS émettant le message OK; 15 - « UTA Prefix Aggregate »: un agrégat, ou une liste, d'identifiants de terminaux UTA attachés au BTS émettant le message OK; - « Transfer Rate » : les conditions tarifaires de transfert inter-BTS ; - « Redirect_BIE » : une ou plusieurs adresses IP d'entité(s) d'interconnexion BIE à utiliser pour les échanges futurs. 20 En particulier, l'information « Redirect_BIE » peut être utilisée dans au moins un mode de réalisation de l'invention dans lequel les entité(s) d'interconnexion BIE responsables de la négociation des accords d'interconnexion sont différentes des entités d'interconnexion BIE impliquées dans le traitement des requêtes en transaction. Pour refuser une demande d'interconnexion, le BTS A 61 peut répondre avec un message 25 de non acceptation NOK(BSID, NONCE, REASON_CODE, ...). Les raisons de refus d'une demande d'interconnexion sont typiquement explicitées dans le paramètre « REASON_CODE » : - « O» ou « Administratively Prohibited » : la demande d'interconnexion a été refusée pour des raisons administratives ; - « 1 » ou « Too High Transfer Rates » : la demande d'interconnexion a été refusée car 30 les commissions de transfert sont trop élevées. Une contre-proposition peut être incluse dans la réponse. Le BTS ayant émis le message BTS_INTERCONNECT peut éventuellement réémettre une demande d'interconnexion avec une autre proposition tarifaire ; 18 - « 2 » ou « Country Covered » : le pays identifié par le paramètre CC du message BTS_INTERCONNECT est déjà desservi par le BTS émettant le message NOK. Ce code d'erreur peut par exemple être utilisé si un BTS décide d'un nombre maximum de BTS qui peuvent desservir un même pays ; 5 - « 3 » ou « Overlapping UTA Aggregate » : indique que la liste des identifiants de terminaux UTA transmise comprend des terminaux UTA servis par un autre BTS. Ce code d'erreur peut par exemple être utilisé si un BTS décide d'un nombre maximum de BTS qui peuvent desservir un même terminal UTA. En cas d'acceptation d'une demande d'interconnexion, les BTS A 61 et BTS B 65 peuvent 10 alors mettre à jour leurs bases de données d'interconnexion BIDB respectives (ou une base BIDB mutualisée) pour renseigner les identifiants de BTS et les informations de localisation des entités d'interconnexion BIE à utiliser pour émettre des requêtes de transaction vers un terminal identifié dans l'agrégat (ou la liste) d'identifiants « UTA Prefix Aggregate ». Par exemple, l'entité d'interconnexion BIE du BTS B 65 maintient localement une table de 15 correspondances entre l'identifiant BTID du BTS A 61 (« Remote BTID ») et les informations de localisation de l'entité d'interconnexion BIE du BTS A 61 (« Remote BIE locators »). De même, l'entité d'interconnexion BIE du BTS A 61 maintient localement une table de correspondances entre l'identifiant BTID du BTS B 65 (« Remote BTID ») et les informations de localisation de l'entité d'interconnexion BIE du BTS B 65 (« Remote BIE locators »). 20 Ces correspondances peuvent être utilisées pour assurer l'acheminement de requêtes de transaction d'un BTS local vers un BTS distant. Ainsi, sur la base de l'identifiant BTID d'un BTS distant, une entité d'interconnexion BIE peut sélectionner le localisateur à utiliser pour transmettre la requête de transaction vers ce BTS distant. Un exemple d'association est {UTA Identifier=+212*, Remote BTID=BTID#145, Remote BIE Locators=[1.2.3.4, 2001:db8::1], ...}. 25 Une entité d'interconnexion BIE peut activer des politiques de sélection d'une entité d'interconnexion BIE distante (« Remote BIE Locator »), reposant sur des considérations telles que la répartition de charge, la résilience, etc. On peut également noter que, selon un mode de réalisation particulier, en cas d'interconnexion avec un BTS intermédiaire, un BTS local peut indiquer au BTS intermédiaire la 30 liste des identifiants de BTS et/ou de pays et/ou de régions géographiques, ..., à ne pas impliquer dans une procédure d'acheminement de transaction concernant ce BTS local. Ces préférences peuvent être enregistrées par le BTS intermédiaire dans sa base de données de localisation BLDB comme un exemple de liste noire. 19 E) Echange de données de localisation Selon au moins un mode de réalisation de l'invention, le procédé de traitement d'une transaction comprend une phase d'échange d'informations de localisation, comprenant : - la transmission, par un BTS local, à au moins un BTS distant, d'un message de localisation 5 portant au moins un identifiant d'un terminal connecté au BTS local, associé à au moins une information de localisation de ce terminal. Ces informations sont notamment extraites de la base de données de localisation BLDB, en particulier de la base de données locale LLDB associée au BTS local ; - la mise à jour de la base de données d'interconnexion BIDB associée au BTS distant à 10 réception, par le BTS distant, du message de localisation. Un tel message de localisation peut être émis en réponse à une requête émise par un BTS distant, ladite requête portant au moins une information appartenant au groupe comprenant : un identifiant du BTS distant, une clé générée par le BTS distant. 15 En variante, un tel message de localisation peut être émis périodiquement ou suite à un changement (modification de la liste des identifiants des terminaux UTA, modification de la BLDB, modification des clauses tarifaires, etc.). Par exemple, un tel message de localisation porte au moins une information appartenant au groupe comprenant : 20 un identifiant du BTS local, une clé générée par le BTS local ou le BTS distant, une liste d'identifiants des terminaux connectés au BTS local. En particulier, comme illustré par les figures 8 et 9, une fois l'interconnexion négociée avec succès entre deux BTS, les deux BTS peuvent procéder à l'échange de « cartes 25 d'identifiants » des terminaux UTA qu'ils maintiennent. En d'autres termes, un BTS local peut transmettre à un BTS distant, avec lequel il est connecté, la liste des terminaux UTA connectés au BTS local. De plus, comme la base de données de localisation BLDB associée à un BTS local (ou commune à une pluralité de BTS) porte des informations de localisation relatives à au moins un 30 terminal connecté au BTS local ou à au moins un BTS distant, il est possible d'échanger ces informations de localisation, associées à l'identifiant des terminaux concernés, entre les BTS interconnectés. D'autres informations peuvent également être échangées, telles que des règles de 20 facturation, des seuils de charge (qui peuvent être exprimés en nombre maximum de requêtes par seconde, par exemple), des contraintes réglementaires spécifiques à certains pays, etc. L'échange de ces cartes d'identifiants peut se faire à l'initiative d'un BTS ou des deux. En particulier, dans le cas où un BTS met en oeuvre un service de « brokering » pour 5 sélectionner un BTS intermédiaire, l'échange de cartes peut être soit bilatéral (le BTS transitaire ou « broker » échange le contenu de ses cartes avec chacun des BTS avec lesquels un accord d'interconnexion a été conclu), soit multilatéral, par exemple dans le contexte du service fourni par une alliance bancaire responsable de l'exploitation du BTS « broker » : dans ce dernier cas, le contenu des cartes maintenues par le BTS transitaire ou « broker » peut être diffusé à l'ensemble 10 des BTS partenaires, membres de l'alliance bancaire, et avec lesquels des accords d'interconnexion ont été établis (de facto). L'échange des identifiants des terminaux, et informations de localisation associées, peut être sollicité ou non. Il peut également être régulier ou régi par un évènement tel que la modification de la liste des identifiants UTA (si un terminal se connecte ou se déconnecte du BTS 15 local), de clauses tarifaires, etc. La figure 8 illustre plus précisément l'envoi des identifiants des terminaux, et informations de localisation associées, selon le mode sans sollicitation. Par exemple, le BTS local 82 envoie au BTS distant 81 un message de localisation BL_SEND (BSID, NONCE, UTA Prefix List, ...). Le BTS distant 81 peut répondre avec un message d'acceptation ACK (BSID, NONCE, RESULT_CODE, ...). 20 Les arguments du message BL_SENDO sont par exemple : « BSID » : l'identifiant du BTS local 82 émettant le message BL_SENDO; « NONCE)> : une clé aléatoirement générée par le BTS local 82 émettant le message BL_SENDO ; « UTA Prefix List » : une liste d'identifiants de terminaux UTA desservis par le BTS local 82 25 émettant le message BL_SENDO. Une fois le message BL_SENDO reçu par le BTS distant 81, le BTS 81 extrait les informations de localisation indiquées, met à jour sa base de données d'interconnexion BIDB 811 avec les informations de localisation, puis répond avec un message ACK() pour informer le BTS 82 ayant émis le message BL_SENDO du statut du traitement du message BL_SENDO. Les arguments 30 du message ACK() sont par exemple : « BSID » : l'identifiant du BTS 81 émettant le message ACK(); « NONCE » : la clé aléatoirement générée par le BTS 82 ayant émis le message BL_SENDO, recopiée de la requête BL_SENDO; 21 « RESULT_CODE » : l'état du traitement de la demande. Les valeurs suivantes peuvent être renseignées, à titre d'exemple : o « 0 » : Succès. o « 1 » : Echec. En cas d'échec de la requête, un sous-type peut être utilisé pour 5 préciser la cause de l'échec de la requête. Par exemple, les valeurs suivantes peuvent être indiquées : - « 0 » ou « Malformed » : indique que le message de localisation BL_SEND() n'est pas correctement formé, - « 1 » ou « Missing Mandatory Information » : indique que le message de 10 localisation BL_SENDO ne renseigne pas un champ obligatoire, - « 2 » ou « Invalid BSID » : indique que le BSID du message de localisation BL_SENDO est erroné, - « 3 » ou « Denied » : indique que le message de localisation BL_SENDO ne peut pas être traité car le BTS 82 ayant émis le message de localisation 15 BL_SENDO n'est pas autorisé à émettre ce message. La figure 9 illustre quant à elle l'envoi des identifiants des terminaux, et informations de localisation associées, selon le mode avec sollicitation. Par exemple, le BTS local 92, qui souhaite recevoir (une copie de) la carte des identifiants des terminaux UTA connectés au BTS distant 91 exprime explicitement cette demande auprès du BTS considéré, en envoyant un message 20 BL_RETRIEVE(BSID, NONCE, [Filters, ... ]). Un tel message BL_RETRIEVED peut être envoyé de manière spontanée (en cas de modification de la liste des terminaux UTA par exemple) ou à fréquence régulière. Les arguments du message BL_RETRIEVED sont par exemple : « BSID » : l'identifiant du BTS local 92 émettant le message BL_RETRIEVED, 25 « NONCE)> : une clé générée aléatoirement par le BTS local 92 émettant le message BL_RETRIEVED, et optionnellement : « Filters » : un ou plusieurs filtres (par ex. les terminaux UTA dont l'identifiant commence par +33) permettant de sélectionner certains identifiants de terminaux UTA que le BTS 30 local 92 souhaite récupérer. En effet, le BTS distant 91 ne doit pas nécessairement fournir les identifiants de tous les terminaux UTA attachés au BTS distant 91, mais seulement ceux qui correspondent aux filtres. 22 En réponse, le BTS distant 91 renvoie le message BL_SENDO comportant les identifiants des terminaux sélectionnés. Dans ce cas, le champ « NONCE » du message BL_SENDO est identique à celui du message BL_RETRIEVED. Le traitement du message BL_SENDO par le BTS local 92 est identique à celui du mode non-sollicité. 5 Les informations de localisation reçues dans un message de localisation BL_SENDO peuvent être sauvegardées dans la base de localisation BLDB (plus précisément, dans la base de données d'interconnexion BIDB). Eventuellement, ces informations de localisation peuvent être augmentées avec les informations de localisation (par exemple, l'adresse IP) de l'entité d'interconnexion BIE du BTS distant à contacter ainsi que celles de l'entité d'interconnexion BIE 10 du BTS local. Un BTS intermédiaire peut éventuellement envoyer une liste d'identifiants de terminaux UTA par défaut, notée par exemple (*), pour signifier que ce BTS est en mesure de traiter les transactions vers n'importe quel terminal UTA. Comme déjà indiqué, un tel BTS intermédiaire peut être sollicité pour acheminer une transaction entre deux BTS quand un BTS ne dispose pas 15 de chemins spécifiques pour joindre le BTS destinataire, c.-à-d. n'est pas connecté directement au BTS destinataire. Selon un mode de réalisation particulier de l'invention, un BTS peut informer d'une modification des coûts de transfert, notamment des commissions bancaires, un ou plusieurs BTS avec lequel il est connecté (BTS « partenaires »). A cet effet, une durée de validité des conditions 20 tarifaires peut aussi être communiquée. Ces informations peuvent être véhiculées par le message BL_SENDO. On peut également noter que, selon au moins un mode de réalisation de l'invention, deux BTS interconnectés peuvent s'échanger les bilans des transactions, d'une manière périodique ou à la demande d'un BTS. Pour ce faire, on utilise par exemple les messages BALANCE_SENDO, 25 BALANCE_RETRIEVE() ou ACK() : le message BALANCE_SEND(BSID, Transferin, Transfer_Out, [Start_Date, End_Date, Detailed_Logs, ...]) indique par exemple le montant des transactions reçues depuis le BTS recevant ce message (« Transferin ») et celui des transactions émises par le BTS émetteur de ce message (« Transfer_Out »), telles que maintenues par le BTS émetteur 30 du message. Le message peut indiquer le cas échéant, la période de calcul du bilan avec par exemple une date de début et une date de fin (« Start_Date », « End_Date »). 23 le message ACK(STATUS_CODE, [Transferin, Transfer_Out, Start_Date, End_Date, Detailed_Logs, ...]) est utilisé par un BTS pour confirmer à un BTS auquel il est connecté la réception d'un message BALANCE_SENDO. Par exemple, le paramètre STATUS_CODE est valorisé à « 0 » pour indiquer que le BTS 5 émettant le message ACK confirme l'exactitude du bilan avec ses propres fichiers de suivi des transactions, ou « 1 » pour signaler une erreur dans le bilan. En cas de détection d'erreur, un inventaire détaillé (« Detailed_Logs ») peut être transmis au BTS distant (ayant émis le message BALANCE_SEND()) pour faciliter les opérations de vérification. Dans ce cas, le BTS distant peut retransmettre un autre message 10 BALANCE_SEND() après correction, déclencher une procédure d'escalade, etc. le message BALANCE_RETRIEVE(BSID, [Start_Date, End_Date, ...]) peut être utilisé pour demander à un BTS distant de transmettre le bilan des opérations pendant une période spécifiée. Le BTS distant peut répondre au message BALANCE_RETRIEVE(BSID, [Start_Date, End_Date, ...]) avec le message BALANCE_SEND(). 15 F) Traitement des transactions On présente ci-après, en relation avec les figures 10 à 13, des exemples de mise en oeuvre de la phase de transaction entre un terminal source et un terminal destinataire selon au moins un mode de réalisation de l'invention. Comme indiqué précédemment, le terminal source et le terminal destinataire peuvent 20 être connectés à un même BTS, ou à des BTS différents. Dans ce dernier cas, des BTS intermédiaires peuvent être utilisés pour acheminer la requête de transaction du terminal source vers le terminal destinataire. La figure 10 illustre l'exemple d'un terminal source 101 et d'un terminal destinataire 102 connectés à un même BTS 103. La figure 11 illustre l'exemple d'un terminal source 101 connecté à 25 un BTS source 103 et d'un terminal destinataire 102 connecté à un BTS destinataire 104, les BTS source et destinataire étant directement connectés. La figure 12 illustre les messages échangés entre les différentes entités pour une transaction inter-BTS correspondant à l'exemple de la figure 11. La figure 13 illustre l'exemple d'un terminal source 101 connecté à un BTS source 103 et d'un terminal destinataire 102 connecté à un BTS destinataire 104, les BTS source et destinataire étant 30 connectés via un BTS intermédiaire 105. Le terminal source 101, identifié par l'identifiant UTA_s, émet une requête de transaction TRANSFER (), portant au moins l'identifiant UTA_d du terminal destinataire 102. Par exemple, le terminal source émet la requête TRANSFER(UTA Identifier, Amount, 24 [target_execution_date, ...]). Les arguments de la requête comprennent par exemple : « UTA Identifier » : l'identifiant UTA_d du terminal destinataire 102, « Amount » : le montant de la transaction, et optionnellement : 5 « Currency » : la devise ou l'unité utilisée pour la transaction ; en effet, le montant d'une transaction peut être, par exemple, exprimé en devises, ou en nombre d'unités créditées sur un compte de service de communication (téléphonie, volume de trafic, ...), « Target_execution_date » : une date d'exécution pour une transaction différée, « Tracking » : une information indique si l'émetteur / terminal source souhaite être 10 informé de l'état de la transaction (bénéficiaire notifié, montant d'argent transféré, etc.). L'entité d'exécution BTA 1031 du BTS source 103 reçoit la requête de transaction, et consulte la base de données de localisation BLDB 1032 (en utilisant par exemple une requête « QUERY(UTA_d) »), pour obtenir une information de localisation du terminal destinataire (LOC_UTA_d). 15 Par exemple, si le terminal source 101 et le terminal destinataire 102 sont connectés à un même BTS, comme illustré en figure 10, l'entité d'exécution BTA 1031 consulte plus spécifiquement la base de données locale LLDB. Si le terminal source 101 et le terminal destinataire 102 ne sont pas connectés à un même BTS, comme illustré en figures 11 à 13, l'entité d'exécution BTA 1031 consulte plus spécifiquement la base de données d'interconnexion BIDB, 20 soit en mode « générique », soit en mode « spécifique ». L'identifiant UTA_d du terminal destinataire 102 peut être utilisé comme clé dans la base de données de localisation BLDB 1032 pour obtenir une information de localisation LOC_UTA_d du terminal destinataire. Si aucune information n'est trouvée dans la base de données de localisation BLDB 1032 25 pour l'identifiant UTA_d du terminal destinataire 102, l'entité d'exécution BTA 1031 envoie un message d'échec au terminal source 101, par exemple la réponse FAILED(UTA Identifier, Amount, CAUSE, ...), pour l'informer de l'échec de l'opération. Le champ CAUSE peut être utilisé pour renseigner la raison de l'échec de la demande de transaction, par exemple : « 0 » ou « Administratively Prohibited » : indique que la demande a été refusée pour des 30 raisons administratives ; « 1 » ou « Maximum Exceeded » : indique qu'un montant de transfert maximum a été atteint ; « 2 » ou « Not Found » : indique que le terminal destinataire n'est pas connu ; 25 - etc. Si une information de localisation LOC_UTA_d du terminal destinataire est trouvée dans la base de données de localisation BLDB 1032 pour l'identifiant UTA_d du terminal destinataire 102, l'entité d'exécution BTA 1031 utilise l'information de localisation LOC_UTA_d pour déterminer le 5 BTS connecté au terminal destinataire. Par exemple, l'entité d'exécution BTA 1031 récupère l'identifiant du BTS à contacter, ainsi que l'adresse de l'entité d'interconnexion BIE à contacter si le BTS source n'est pas le BTS destinataire, par exemple dans un message « REPLY(BSID) ». Selon l'exemple illustré en figure 10, comme les terminaux source 101 et destinataire 102 sont connectés au même BTS, le BTS transmet (35) la requête de transaction au terminal 10 destinataire. L'entité d'exécution BTA 1031 se charge donc de relayer la requête de transaction vers le terminal destinataire en utilisant l'information de localisation LOC_UTA_d obtenue à partir de la base LLDB. L'entité d'exécution BTA 1031 peut également se charger de relayer la confirmation de la complétude (ou de son échec éventuel) de la transaction vers le terminal destinataire. Par exemple, le message de confirmation de la transaction peut être un SMS, un 15 message vocal, un code QR disponible sur un espace client, etc. Selon les exemples illustrés en figures 11 à 13, comme les terminaux source 101 et destinataire 102 ne sont pas connectés au même BTS, la requête de transaction est relayée vers l'entité d'interconnexion 1033 du BTS local 103, qui la relaie ensuite à l'entité d'interconnexion BIE 1043 du BTS destinataire 104 (figures 11 et 12) ou à l'entité d'interconnexion BIE 1053 d'un 20 BTS intermédiaire 105 (figure 13). On note que le message TRANSFER() ainsi relayé peut être assorti d'autres informations, par exemple des paramètres de type : « TRANSACTION_IDENTIFIER » : utilisé pour identifier une requête, notamment en cas de « forking » (« embranchement »), lorsque plusieurs chemins sont possibles, 25 « SECURITY_TOKEN » : identifiant de sécurité, « Target BTID » : identifiant du BTS distant vers qui le message TRANSFER() doit être acheminé, etc., qui peuvent ainsi être ajoutés dans le message TRANSFER(). 30 Selon l'exemple illustré en figures 11 et 12, la requête de transaction est relayée de l'entité d'exécution BTA 1031 vers l'entité d'interconnexion BIE 1033 du BTS local 103, sous la forme du message TRANSFER comprenant par exemple les paramètres ID (identifiant du BTS destinataire), UTA_s (identifiant du terminal source), UTA_d (identifiant du terminal destinataire) 26 et BSID (identifiant du BTS source 103). Après consultation de la table de correspondances de l'entité d'interconnexion BIE 1033 du BTS local 103, la requête de transaction est relayée de l'entité d'interconnexion BIE 1033 vers l'entité d'interconnexion BIE 1043 du BTS destinataire 104 sous la forme du message TRANSFER comprenant par exemple les paramètres ID (identifiant du 5 BTS destinataire), UTA_s (identifiant du terminal source), UTA_d (identifiant du terminal destinataire) et BSID (identifiant du BTS source 103). Une fois le message TRANSFER reçu par l'entité d'interconnexion BIE 1043 du BTS destinataire 104, l'entité d'interconnexion BIE 1043 relaie le message TRANSFER vers l'entité d'exécution BTA 1041 du BTS destinataire 104, par exemple sous la forme du message TRANSFER 10 comprenant par exemple les paramètres ID (identifiant du BTS destinataire), UTA_s (identifiant du terminal source), UTA_d (identifiant du terminal destinataire), etc.). L'entité d'exécution BTA 1041 du BTS destinataire 104 procède à des vérifications locales au BTS destinataire 104, et consulte notamment la base de données de localisation BLDB 1042 du BTS destinataire 104 pour récupérer les informations de localisation associées au terminal destinataire 102. L'entité d'exécution BTA 15 1041 relaie la requête de transaction au terminal destinataire 102 pour l'informer de la transaction, sous la forme du message TRANSFER comprenant par exemple le paramètre UTA_s (identifiant du terminal source), etc. Selon l'exemple illustré en figure 13, une fois le message TRANSFER reçu par l'entité d'interconnexion BIE 1053 du BTS intermédiaire 105, l'entité d'interconnexion BIE 1043 relaie le 20 message TRANSFER vers l'entité d'exécution BTA 1051 du BTS intermédiaire 105, qui le relaie vers l'entité d'interconnexion BIE 1054 du BTS intermédiaire 105, qui le relaie ensuite vers l'entité d'interconnexion BIE 1043 du BTS destinataire 104. L'entité d'interconnexion BIE 1043 relaie le message TRANSFER vers l'entité d'exécution BTA 1041 du BTS destinataire 104 qui procède à des vérifications locales au BTS destinataire 104, puis transmet le message au terminal destinataire 25 102 pour l'informer de la transaction. Un message de confirmation CONFIRMED() peut être envoyé au terminal destinataire et aux différentes entités (d'exécution ou d'interconnexion) ayant transmis le message TRANSFER. La confirmation peut être relayée jusqu'au terminal source 101. On note qu'un autre ordre peut être utilisé pour relayer les messages entre les différentes 30 entités. Si plusieurs chemins sont possibles entre le BTS source 103 et le BTS destinataire 104, l'entité d'exécution BTA du BTS source (ou d'un BTS intermédiaire) peut choisir le BTS distant le mieux disant (en termes de frais de commission) afin d'optimiser les coûts de transfert. 27 La requête de transaction TRANSFER() peut donc être envoyée à plusieurs BTS intermédiaires de façon à sélectionner au moins un BTS intermédiaire en respectant au moins un critère de sélection prédéterminé. De tels BTS intermédiaires peuvent notamment être localisés dans des pays différents. 5 Par exemple, un BTS courant met en oeuvre au moins une itération des étapes suivantes pour identifier un BTS suivant, le premier BTS courant étant le BTS source et le dernier BTS suivant étant le BTS destinataire : obtention d'une information de localisation d'au moins une entité d'interconnexion BIE permettant de connecter un BTS courant avec un BTS suivant, 10 transmission, à au moins un BTS suivant identifié par l'entité d'interconnexion BIE, de la requête de transaction. Une demande de transfert de fonds peut également être décomposée en plusieurs requêtes TRANSFER() envoyées à des BTS intermédiaires différents, mais dont le montant global de l'ensemble des requêtes est égal à la somme à transférer vers le terminal destinataire. Dans ce 15 cas, le champ TRANSACTION_IDENTIFIER peut être utilisé pour corréler les différentes requêtes de transaction reçues par l'entité d'exécution BTA 1041 du BTS destinataire 104. Dans un mode de réalisation particulier, un terminal UTA comprend une mémoire stockant au moins un identifiant d'au moins un BTS. Un tel terminal peut donc être configuré avec une liste de BTS. Ainsi, une même requête de transaction peut être transmise à plusieurs BTS 20 attachés au terminal UTA. Le terminal UTA peut confirmer la transaction via l'un de ces BTS (BTS source) selon un ou plusieurs critères de sélection (par exemple le BTS offrant la commission de transfert minimale). La procédure de négociation entre le terminal UTA et les BTS selon ce mode de réalisation peut utiliser les mêmes primitives que celles invoquées entre deux BTS. Dans les exemples des figures 10 à 13, on a considéré un BTS avec une seule entité 25 d'exécution BTA. Bien entendu, selon un autre mode de réalisation, plusieurs entités BTA peuvent être mises en oeuvre. Dans ce cas, l'obtention d'une information de localisation du terminal destinataire met en oeuvre au moins une itération d'obtention, par une entité d'exécution courante du BTS (BTA courante), d'une information de localisation d'au moins une entité d'exécution suivante du BTS 30 (BTA suivante), à partir de la base de données de localisation BLDB et d'au moins un identifiant du terminal destinataire. La dernière entité d'exécution délivre l'information de localisation du terminal destinataire. Par exemple, comme illustré en figure 14, plusieurs entités d'exécution BTA 14311, 14312, 28 ..., peuvent être sollicitées pour le traitement d'une transaction. La base de données de localisation BLDB 1432 comprend par exemple plusieurs bases de données locales LLDB 14321, 14322, ..., qui peuvent être activées au sein d'un BTS, chacune étant attachée à une entité d'exécution BTA. Dans cet exemple, le terminal source émet une requête de transaction à 5 destination du terminal destinataire, portant un identifiant du terminal destinataire. La requête est alors reçue par une première entité BTA 14311 (BTA_o, « Originating BTA ») qui sollicite la base de données de localisation 1432, et plus spécifiquement la base de données locale 14321 attachée à la première entité BTA 14311 pour récupérer l'information de localisation du terminal destinataire. Dans ce cas, la base de données locale 14321 retourne l'adresse d'une deuxième 10 entité BTA 14312 (BTA_t « Terminating BTA ») comme information de localisation d'au moins une entité d'exécution suivante. La première entité BTA 14311 (BTA_o) peut ainsi acheminer la requête de transaction vers la deuxième entité BTA 14312 (BTA_t), et ainsi de suite. On présente finalement, en relation avec la figure 15, un exemple de mise en oeuvre de l'invention en cas d'itinérance (« Roaming ») du bénéficiaire de la transaction. Dans cet exemple, 15 le terminal destinataire 152, identifié par UTA_d, n'est pas connecté au BTS H 153 attaché à son réseau mobile de rattachement (PLMN HOME 154), mais au BTS V 155 attaché à un réseau visité (PLMN VISITED 156). Quand la requête de transaction TRANSFER() est reçue par une entité d'exécution BTA du BTS H 153, elle sollicite la base de données de localisation BLDB 1532 pour récupérer les informations de localisation associées au terminal destinataire 152. La base BLBD 20 1532 indique que l'utilisateur du terminal destinataire 152 (identifié par un numéro MSIDN, dans cet exemple) est en itinérance et procède à une recherche du BTS V 155 associé au réseau visité. On note que, dans un mode de réalisation particulier, cette information peut être préparée par anticipation en corrélant les bases de données de localisation BLDB avec les données d'itinérance, être préparée au moment d'une transaction, faire l'objet de l'un des services fournis par un BTS 25 « broker », etc. L'identifiant d'au moins un BTS desservant le réseau visité est ensuite retourné par la base de données de localisation BLBD 1532. La requête de transaction peut ainsi être transmise au BTS V 155 du réseau visité. A l'issue de vérifications locales (le cas échéant), la transaction peut être notifiée au terminal destinataire 152. Le bénéficiaire peut alors disposer du montant de la 30 transaction, quelle que soit sa localisation. G) Finalisation de la transaction L'émetteur de la transaction peut choisir de déduire le montant de la transaction de son solde téléphonique (par ex. solde pour les clients prépayés) ou d'intégrer ce montant à la facture 29 de services de télécommunication (typiquement, pour les clients post-payés). Les moyens traditionnels de paiement (par ex. prélèvements automatiques) peuvent, naturellement, être aussi utilisés. Le bénéficiaire de la transaction peut, quant à lui, recevoir le montant de la transaction 5 dans une agence ou sur un compte bancaire. Le montant de la transaction peut aussi être converti en crédit de services de télécommunications, et utilisé pour solder des factures de télécommunications ou d'autres services choisis par le bénéficiaire. 5.3 Structures On présente finalement, en relation avec la figure 16, la structure simplifiée d'un système 10 de services bancaires BTS selon l'un des modes de réalisation décrits ci-dessus. Un tel BTS comprend une mémoire 161 comprenant une mémoire tampon, une unité de traitement 162, équipée par exemple d'une machine de calcul programmable ou d'une machine de calcul dédiée, par exemple un processeur P, et pilotée par le programme d'ordinateur 163, mettant en oeuvre le procédé de traitement d'une transaction selon un mode de réalisation de 15 l'invention. A l'initialisation, les instructions de code du programme d'ordinateur 163 sont par exemple chargées dans une mémoire RAM avant d'être exécutées par le processeur de l'unité de traitement 162. Le processeur de l'unité de traitement 162 met en oeuvre les étapes du procédé de 20 traitement d'une transaction décrit précédemment, selon les instructions du programme d'ordinateur 163, pour acheminer une requête de transaction d'un terminal source vers un terminal destinataire. Selon un mode de réalisation particulier, le processeur de l'unité de traitement 162 active au moins une instance d'une entité d'exécution BTA et/ou au moins une instance d'une entité 25 d'interconnexion BIE et/ou au moins une instance d'une base de données de localisation BLDB pour acheminer une requête de transaction d'un REVENDICATIONS1. Procédé de traitement d'une transaction entre un terminal source (11) et un terminal destinataire (12), caractérisé en ce qu'il met en oeuvre une phase de transaction comprenant : la réception (31), par un système de services bancaires, dit BTS source, connecté au terminal source, d'une requête de transaction en provenance du terminal source, ladite requête portant au moins un identifiant dudit terminal destinataire et un montant de transaction, l'obtention (32), par le BTS source, d'une information de localisation du terminal destinataire, à partir d'au moins une base de données de localisation, notée BLDB, et dudit identifiant du terminal destinataire, la détermination (33), par le BTS source, d'au moins un système de services bancaires, dit BTS destinataire, connecté au terminal destinataire, à partir de ladite information de localisation du terminal destinataire, - si le BTS source n'est pas le BTS destinataire, au moins une itération des étapes suivantes, mise en oeuvre tant que la requête de transaction n'a pas atteint le BTS destinataire : o sélection (341) d'un système de services bancaires intermédiaire, dit BTS intermédiaire, en tenant compte d'au moins un critère de sélection, o transmission (342) audit BTS intermédiaire de ladite requête de transaction ; - la transmission (35) audit terminal destinataire, par le BTS destinataire, de ladite requête ou d'une information relative à ladite transaction. 2. Procédé de traitement selon la revendication 1, caractérisé en ce que ledit critère de sélection appartient au groupe comprenant : un coût de transfert minimal ; un nombre de BTS intermédiaire minimal ; une distance minimale entre deux BTS. 3. Procédé de traitement selon l'une quelconque des revendications 1 et 2, caractérisé en ce que l'obtention d'une information de localisation du terminal destinataire met en oeuvre au moins une itération d'obtention, par une entité d'exécution courante du BTS source, d'une information de localisation d'au moins une entité d'exécution suivante du BTS source, à partir de la base de données de localisation BLDB et dudit au moins un identifiant dudit terminal destinataire, et en ce que la dernière entité d'exécution délivre l'information de localisation du 31 terminal destinataire. 4. Procédé de traitement selon l'une quelconque des revendications 1 à 3, caractérisé en ce qu'il comprend une phase préalable d'initialisation d'au moins un système de services bancaires, dit BTS local, comprenant : 5 la construction ou mise à jour de ladite au moins une base de données de localisation (BLDB), ladite base de données de localisation (BLDB) comprenant : o une base de données locale (LLDB), comprenant des informations de localisation relatives à au moins un terminal connecté au BTS local, identifié par un identifiant, 10 o une base de données d'interconnexion (BIDB), comprenant des informations de localisation relatives à au moins un terminal connecté à au moins un BTS distant, la configuration d'au moins une entité d'exécution du BTS local avec au moins une information de localisation de ladite base de données de localisation (BLDB). 5. Procédé de traitement selon la revendication 4, caractérisé en ce qu'il comprend 15 également une phase de découverte d'au moins un BTS distant, comprenant l'envoi par le BTS local, dans au moins un réseau de communication auquel est connecté le BTS local, d'un message de découverte indiquant la capacité du BTS local à traiter des transactions (BTS_CAPABLE). 6. Procédé de traitement selon l'une quelconque des revendications 4 et 5, caractérisé en ce qu'il comprend une phase d'interconnexion du BTS local avec au moins un BTS distant 20 comprenant : l'obtention, par le BTS distant, d'une information de localisation d'au moins une entité d'interconnexion (BIE) permettant d'interconnecter le BTS local avec le BTS distant, l'envoi, par le BTS distant, d'un message de demande d'interconnexion (BTSINTERCONNECT) à ladite entité d'interconnexion localisée par ladite information de 25 localisation. 7. Procédé de traitement selon l'une quelconque des revendications 4 à 6, caractérisé en ce qu'il comprend une phase d'échange d'informations de localisation, comprenant : la transmission, par le BTS local, à au moins un BTS distant, d'un message de localisation (BL_SEND) portant au moins un identifiant d'un terminal connecté au BTS local associé à 30 au moins une information de localisation de ce terminal, la mise à jour de la base de données d'interconnexion (BIDB) associée au BTS distant à réception, par le BTS distant, du message de localisation. 8. Procédé de traitement selon l'une quelconque des revendications 1 à 7, caractérisé en ce 32 que ladite requête de transaction porte également au moins une information appartenant au groupe comprenant : une devise ou une unité pour la transaction, une date d'exécution de la transaction, 5 un indicateur indiquant si le terminal source souhaite être informé de l'état de la transaction, un identifiant de la transaction, un identifiant de sécurité, et un identifiant d'un BTS distant par lequel transite ladite requête de transaction. 10 9. Système de services bancaires pour le traitement d'une transaction entre un terminal source et un terminal destinataire, comprenant au moins une machine de calcul programmable ou une machine de calcul dédiée configurée pour : recevoir et/ou transmettre une requête de transaction, ladite requête portant au moins 15 un identifiant dudit terminal destinataire et un montant de transaction, obtenir une information de localisation du terminal destinataire, à partir d'au moins une base de données de localisation, notée BLDB, et dudit identifiant du terminal destinataire, déterminer au moins un système de services bancaires, dit BTS destinataire, connecté au terminal destinataire, à partir de ladite information de localisation du terminal 20 destinataire, sélectionner au moins un système de services bancaires intermédiaire, dit BTS intermédiaire, en tenant compte d'au moins un critère de sélection. 10. Terminal utilisé pour le traitement d'une transaction, comprenant au moins une machine de calcul programmable ou une machine de calcul dédiée configurée pour : 25 émettre au moins une requête de transaction, ladite requête portant au moins un identifiant d'un terminal destinataire de la transaction et un montant de transaction. 11. Terminal selon la revendication 10, caractérisé en ce qu'il comprend une mémoire stockant au moins un identifiant d'au moins un système de services bancaires, et des moyens de sélection de l'un desdits systèmes de services bancaires, dit BTS source, en tenant compte d'au 30 moins un critère de sélection. 12. Terminal selon l'une quelconque des revendications 10 et 11, comprenant au moins une machine de calcul programmable ou une machine de calcul dédiée configurée pour recevoir ladite requête de transaction ou une information relative à ladite transaction.