Brevet FR2839225A1 — publié le 20031031

microprocesseur RISC. 1 2839225 La présente invention se rapporte à un procédé et à un dispositif de traitement d'une transaction électronique entre un dispositif client et un dispositif serveur. Plus précisément, l'invention se rapporte à un procédé de traitement d'une transaction électronique entre un dispositif client et un dispositif serveur, procédé dans lequel est utilisé un dispositif tiers servant d'intermédiaire de paiement pour ladite transaction. Par exemple, un dispositif intermédiaire de paiement peut être utilisé pour centraliser le traitement des paiements électroniques mis en _uvre au cours de transactions électroniques entre des dispositifs au sein d'un réseau informatique distribué. Selon cette architecture, le dispositif client effectue un paiement auprès du dispositif intermédiaire, ce dispositif serveur effectuant un paiement auprès du dispositif serveur à l'issue de la transaction. Cette architecture est particulièrement avantageuse pour un dispositif serveur faisant peu de transactions, car il ne supporte pas directement le coût du traitement du paiement par le dispositif client. On conna^'t par le document US 6,311,170 une méthode pour réaliser des paiements à l'aide d'un intermédiaire de paiement. Un système de paiement conforme à l'état de la technique et comprenant un intermédiaire de paiement va maintenant être décrit en référence à la figure 1. Plus précisément, la figure 1 représente un dispositif client C, un dispositif serveur S et un dispositif intermédiaire P et l'échange des messages entre ces différents dispositifs au cours d'une transaction électronique entre le client C et le serveur S. Dans l'exemple décrit à la figure 1, nous supposons que le dispositif client C souhaite obtenir une image I en provenance du serveur S. 2 2839225 mais le mécanisme mis en _uvre serait équivalent pour un autre type de transaction. L'image I est payante mais, comme décrit précédemment, le paiement n'est pas réalisé directement par le client C au profit du serveur S. Au contraire, le dispositif intermédiaire P sert d'intermédiaire de paiement entre le client C et le serveur S. Préalablement à tout achat auprès du dispositif serveur P. le dispositif client C émet une requête RAT d'autorisation de transaction à destination du dispositif intermédiaire P. cette requete comportant: - l'adresse S du dispositif serveur S; - l'identificateur I de l'image I à obtenir; - un montant de paiement MP; et - une pièce électronique Pj(C, P) appartenant à l'ensemble des pièces électroniques utilisables par le client C pour réaliser un paiement auprès du dispositif intermédiaire P. Par cette requête RAT d'autorisation de transaction, le dispositif client C notifie le dispositif intermédiaire P: - qu'il doit répondre positivement à une requête du dispositif serveur S pour l'autorisation de la livraison de l'image I au dispositif client C; et - qu'il accepte de payer le montant de paiement MP pour obtenir cette image I. Après l'envoi de la requête RAT d'autorisation de transaction, le dispositif client C envoie au dispositif serveur S. une requête RDT de déclenchement de transaction, cette requête comportant l'identificateur I de l'image I à obtenir. Sur réception de la requête RDT de déclenchement de transaction, le dispositif serveur S envoie au dispositif intermédiaire P une requête RAL d'autorisation de livraison de l'image I au dispositif client C. Cette requête RAL d'autorisation de livraison comporte: - l'identificateur I de l'image I demandée par le dispositif client C; et 3 2839225 - le montant de paiement MP demandé par le dispositif serveur S pour fournir l'image l au dispositif client C. Sur réception de cette requête RAL d'autorisation de livraison, le dispositif intermédiaire P vérifie s'il a reçu une requête RAT d'autorisation du dispositif client C pour obtenir l'image I. Si tel est le cas, le dispositif intermédiaire P envoie un message MVT de validité de la transaction au dispositif serveur S. ce message MVT de validité de transaction comportant une pièce Pk(P, S) appartenant à l'ensemble des pièces électroniques utilisables par le dispositif intermédiaire P pour régler le dispositif serveur S pour régler le montant MP. Sur réception du message MVT de validité de la transaction, le serveur S vérifie la validité du paiement reçu en provenance du dispositif intermédiaire P à l'étape précédente, et transmet l'image I au dispositif client C lorsque ce paiement est validé. Le mécanisme décrit à la figure 1 pose néanmoins un problème lorsque la transaction n'est pas effectuée après le paiement du dispositif client C auprès du dispositif intermédiaire P. Tel peut-être le cas si le dispositif serveur S est en panne ou, de façon plus générale, non disponible, ou si l'utilisateur du dispositif client C renonce à la transaction par exemple. La présente invention permet de résoudre ce problème en permettant l'annulation de la transaction par le dispositif intermédiaire S. La présente invention a plus particulièrement pour objet un procédé de traitement d'une transaction électronique entre un dispositif client et un dispositif serveur sur un réseau de communication. Ce procédé est mis en _uvre au sein d'un dispositif intermédiaire du réseau de communication et il comporte les étapes suivantes: - réception d'une requête d'autorisation de transaction en provenance du dispositif client, cette requête d'autorisation comportant un premier montant de paiement; - détection d'un échec de la transaction entre le dispositif serveur et le dispositif client; et 4 2839225 - envoi d'un message d'annulation de la transaction à destination du dispositif client lorsque l'échec est détecté, ce message d'annulation de la transaction comportant un montant de remboursement par le dispositif intermédiaire au profit du dispositif client. Ainsi, si le dispositif intermédiaire détecte que la transaction ne s'effectue pas correctement, il envoie un message d'annulation de la transaction au dispositif client. Ceci peut en particulier se produire lorsque le dispositif serveur est indisponible, ou si lorsque le réseau est surchargé. Ce message d'annulation est accompagné d'un remboursement par le dispositif intermédiaire au profit du dispositif client. Dans un mode préféré de réalisation, le montant de remboursement est au plus égal au montant de paiement acquitté par le dispositif client au profit du dispositif intermédiaire. Selon une première caractéristique, I'étape de détection comprend une étape de réception d'une requête d'annulation en provenance du dispositif client (C). Selon cette première caractéristique, I'utilisateur du dispositif client peut annuler expressément la transaction, par l'envoi d'une requête d'annulation au dispositif intermédiaire qui, sur réception de cette requête, constate I'annulation de la transaction. Préférentiellement, on détecte l'échec de la transaction quand une durée au moins égale à une durée prédéterminse s'est écoulée entre la réception de la requête d'autorisation de transaction et la réception de la requête d'annulation. Dans un mode particulier de réalisation, I'étape de détection comporte une tentative d'établissement d'une communication avec le dispositif serveur. Ainsi, si le dispositif serveur est injoignable, par exemple, lorsque le dispositif serveur est hors d'usage, ou lorsque le réseau de communication est surchargé, le dispositif intermédiaire détecte l'échec de la transaction et rembourse le dispositif client. 2839225 Selon une caractéristique préférée de ce mode de réalisation, on détecte l'échec de la transaction, lorsque la tentative d'établissement de communication échoue pendant une durée au moins égale à une durée prédéterminée. Cette caractéristique permet d'éviter l'annulation de la transaction en cas d'une difficulté temporaire à joindre le dispositif serveur, par exemple en cas d'engorgement passager du réseau de communication. Selon un autre mode préféré de réalisation, le procédé comporte en outre, préalablement à l'étape de détection, une étape de réception, en provenance du dispositif serveur, d'une requête d'autorisation de livraison comportant un deuxième montant de paiement. Dans ce mode préféré de réalisation, on détecte l'échec de la transaction si le deuxième montant de paiement est supérieur au premier montant de paiement. Ainsi, le dispositif intermédiaire contrôle que le montant perçu par le dispositif serveur pour effectuer la transaction, est inférieur au premier montant de paiement versé par le dispositif client au profit du dispositif intermédiaire. Corrélativement, I'invention concerne un dispositif de traitement d'une transaction électronique entre un dispositif client et un dispositif serveur sur un réseau de communication. Ce dispositif de traitement est susceptible d'être incorporé dans un dispositif intermédiaire du réseau de communication et il comporte: - des moyens de réceptio n d ' u n e req uete d 'a utorisation de transaction en provenance du dispositif client, la requête d'autorisation comportant un premier montant de paiement; - des moyens de détection d'un échec de cette transaction entre le dispositif serveur et le dispositif client; et - des moyens d'envoi d'un message d'annulation de cette transaction à destination du dispositif client lorsque 1'échec est détecté, ce message d'annulation de la transaction comportant un montant de remboursement par le dispositif intermédiaire au profit du dispositif client. 6 2839225 L'invention vise aussi un dispositif intermédiaire comportant des moyens adaptés à meffre en _uvre un procédé de traitement tel que décrit brièvement ci dessus. L'invention vise aussi un dispositif intermédiaire comportant un dispositif de traitement tel que décrit brièvement ci dessus. L'invention vise aussi un système de transaction électronique dans un réseau de communications comportant un dispositif intermédiaire tel que décrit brièvement ci dessus. L'invention vise aussi un support d'informations lisible par un système informatique, éventuellement totalement ou partiellement amovible, notamment CD-ROM ou support magnétique, tel un disque dur ou une disquette, ou support transmissible, tel un signal électrique ou optique, et comportant des instructions d'un programme d'ordinateur permeffant la mise en _uvre d'un procédé de traitement tel que décrit brièvement ci dessus, lorsque ce programme est chargé et exécuté par un système informatique L'invention vise aussi un programme d'ordinateur stocké sur un support d'informations, led it programme comportant des instructions permeffant la mise en _uvre d'un procédé de traitement tel que décrit brièvement ci dessus, lorsque ce programme est chargé et exécuté par un système informatique. Les avantages et caractéristiques particulières propres aux dispositifs de traitement, aux dispositifs intermédiaires, au système de transaction électronique, au support d'information et au programme d'ordinateur étant les mêmes que ceux exposés ci-dessus concernant le procédé de traitement selon l'invention, ils ne seront pas rappelés ici. D'autres aspects et avantages de la présente invention appara^'tront plus clairement à la lecture de la description de modes particuliers de réalisation qui va suivre, ceffe description étant donnée uniquement à titre d'exemple non limitatif et faite en référence aux dessins annexés sur lesquels: - la figure 1 déjà décrite représente un système de paiement comprenant un intermédiaire de paiement conformément à l'état de la technique; 7 2839225 - la figure 2 représente, sous forme d'organigramme, les principales étapes mises en _uvre par un dispositif client au cours d'une transaction, conformément à la présente invention; -la figure 3 représente, sous forme d'organigramme, le traitement d'une requête de déclenchement de transaction par un dispositif serveur, conformément à la présente invention; -la figure 4 représente, sous forme d'organigramme, le traitement d'une requête d'autorisation de transaction par un dispositif intermédiaire conforme à la présente invention; -la figure 5 représente, sous forme d'organigramme, le traitement d'une requête RAL d'autorisation de livraison par un dispositif intermédiaire conforme à la présente invention; - la figure 6 représente, sous forme d'organigramme, les principales étapes de traitement d'une requête d'annulation, conformément à la présente invention; -la figure 7 reprend de façon synthétique l'échange des messages et requêtes entre un dispositif intermédiaire de paiement, un dispositif serveur et un dispositif intermédiaire au cours d'une transaction électronique, conformément à la présente invention; et la figure 8 représente schématiquement un dispositif intermédiaire de paiement adapté à mettre un _uvre un procédé de traitement conforme à la présente invention, dans un mode préféré de réalisation. La fiigure 2 représente les principales étapes E200 à E250 mises en _uvre par un dispositif client C au cours d'une transaction conformément à la présente invention. Dans le mode préféré de réalisation décrit ici, les paiements s'effectuent au moyen du système PayWord tel que proposé par Rivest et Shamir. Une description de ce système peut être consultée à l'adresse I nternet http:/ltheory. Ics. m it.edu/rivest/RivestShamir-mpay. ps. Ce système consiste, d'une manière générale, à générer récursivement, à partir d'un nombre aléatoire Pn et d'une fonction de hachage h 8 2839225 (en anglais Hash function), une suite de pièces électroniques Pn, Pn 11.., Po par la formule Pn- = h(Pn) Cette fon ction de hach age a la p articu la rité de ne pas être réversible de telle sorte qu'il est en pratique impossible, à partir d'un nombre Pn, de retrouver le nombre précédent Pn. L'extrémité PO de la chane ainsi obtenue est appelée pièce racine (en anglais Root Coin) et permet de vérifier l'authenticité des autres pièces. Dans la suite de la description nous adopterons la notation P(M, N) pour désigner la série de pièces utilisoes par un dispositif M pour réaliser un paiement auprès d'un dispositif N. Par exemple, selon cette notation, la série de pièces électroniques P(C, P) est une série de pièces utilisées par le dispositif client C pour réaliser un paiement auprès du dispositif intermédiaire P. Au cours de la première étape E200 le dispositif client C envoie une requête RAT d'autorisation de transaction au dispositif intermédiaire P. Co mme décrit p récédem ment, cette req uête RAT d 'autorisation de transaction comporte: - l'adresse S du dispositif serveur S; - l'identificateur I de l'image I à obtenir; - un montant de paiement MP; et - une pièce Pj (C, P) appartenant à l'ensemble des pièces P(C, P) utilisables par le dispositif client pour réaliser un paiement auprès du dispositif intermédiaire P. Dans le mode de réalisation basé sur le système de paiement PayWord, cette pièce électronique Pj(C, P) est telle que toutes les pièces d'indice strictement inférieur à j de l'ensemble de pièces P(C, P) ont déjà été validées pour des paiements antérieurs par le dispositif intermédiaire P. L'étape E200 est suivie une étape E205 au cours de laquelle le dispositif client C envoie une requête RDT de déclenchement de transaction au dispositif serveur S. Cette requête RDT de déclenchement de transaction comporte l'identificateur I de l'image à obtenir. 9 2839225 L'étape E205 est suivie par un test E210 au cours duquel le dispositif client C vérifie si il a reçu l'image I en provenance du dispositif serveur S en réponse à la requête RDT de déclenchement de transaction émise à l'étape E205. Si tel est le cas, le résultat du test E210 est positif. Ce test termine alors la procédure mise en ceuvre par le dispositif client C pour réaliser une transaction auprès du serveur S conformément à l'invention. En revanche, si le dispositif client C n'a pas reçu l'image I en provenance du dispositif serveur S le résultat du test E210 est négatif. Ce test est alors suivi par un test E220 au cours duquel le dispositif client C vérifie si, depuis l'émission de la requête RDT de déclenchement de transaction, la durée TR_MAX s'est écoulée. Cette constante TR_MAX est mémorisée dans un registre d'une mémoire non volatile ROM du dispositif client C. Si tel est le cas, le résultat du test E220 est positif. Ce test est alors suivi par une étape E230 au cours de laquelle le dispositif client C envoie une requête RA d'annulation au dispositif intermédiaire P. Le traitement de la requête RA d'annulation par le dispositif intermédiaire P sera décrit ultérieurement en référence à la figure 6. Quoi qu'il en soit, suite à l'émission de la requête RA d'annulation vers le dispositif intermédiaire P. le dispositif client attend une réponse à la requête RA d'annulation envoyée au dispositif intermédiaire P à l'étape E230, cette réponse pouvant être: - soit un remboursement (annulation acceptée); - soit une notification de rejet de la requête RA d'annulation. L'étape E230 est suivie par un test E235 au cours duquel le dispositif client C vérifie, si la requête RA d'annulation a été acceptée par le dispositif intermédiaire P. Si tel n'est pas le cas, le résultat du test E235 est négatif. Ce test est alors suivi par le test E210 déjà décrit. 2839225 De retour au test E220, si la durée TR_MAX ne s'est pas écoulée depuis l'envoi de la requête RDT de déclenchement de transaction, le résultat de ce test est négatif. Ce test est alors suivi par un test E225 au cours duquel le dispositif client C vérifie si l'utilisateur du dispositif client C a demandé explicitement une interruption de la transaction. Si tel est le cas, le résultat du test E225 est positif. Ce test est alors suivi par l'étape E230 d'envoi de la requête RA d'annulation au dispositif intermédiaire P déjà décrite. En revanche, si l'utilisateur du dispositif client C n'a pas explicitement interrompu la transaction, le résultat du test E225 est négatif. Ce test est alors suivi par le test E210 déjà décrit. Les étapes E210, E220, E225, E230 et E235 constituent ainsi une boucle dont l'exécution se termine: - soit lorsque le résultat du test E210 est positif, ce qui se produit lorsque le dispositif client C a reçu l'image I en réponse à la requete RDT de déclenchement de transaction envoyée à l'étape E205; - soit parce que la durée TR_MAX s'est écoulée depuis l'envoi de la requête RDT de déclenchement de transaction; - soit par interruption volontaire de la transaction par l'utilisateur. Dans ces deux derniers cas, et comme déjà décrit en référence à l'étape E230, une requête RA d'annulation est envoyée au dispositif intermédiaire P. Lorsque le dispositif intermédiaire P envoie une réponse à la requête RA d'annulation représentative de l'acceptation de cette annulation, le résultat du test E235 est positif. Ce test est alors suivi par un test E240 au cours duquel le dispositif client C vérifie si le remboursement reçu du dispositif intermédiaire P est valide. 11 2839225 Dans le mode préféré de réalisation décrit iCi7 ce remboursement s'effectue au moyen des pièces électroniques P(P, C) conformément au système de paiement PayWord. Si le remboursement est valide, le résultat du test E240 est positif. Ce test est alors suivi par une étape E245 au cours de laquelle le dispositif client C encaisse le remboursement. En revanche, si le remboursement n'est pas valide, le résultat du test E240 est négatif. Ce test est alors suivi par une étape E250 de notification d'une erreur à l'utilisateur du dispositif client C. Quoi qu'il en soit, les étapes E245 et E250 terminent la procédure de transaction conformément à la présente invention. La figure 3 représente les principales étapes E300 à E350 de traitement d'une requête RDT de déclenchement de transaction par un dispositif serveur S conformément à la présente invention. Au cours de la première étape E300, le dispositif serveur S reçoit une requête RDT de déclenchement de transaction en provenance du dispositif client C pour l'obtention d'une image I. Sur réception de cette requête RDT de déclenchement de transaction, le dispositif serveur S envoie, au cours d'une étape E310, une requête RAL d'autorisation de livraison au dispositif intermédiaire P. Comme décrit précédemment, cette requête RAL d'autorisation de livraison comporte l'identificateur I de l'image I demandée et le montant de paiement MP' demandé par le dispositif serveur S pour fournir l'image I au dispositif client C. Cette étape E310 est suivie par une étape E320 au cours de laquelle le dispositif serveur S reçoit un message MVT de validation de la transaction, ce message comportant une information selon laquelle l'autorisation de livrer l'image I est accordée ou non par le dispositif intermédiaire P. L'envoi de ce message MVT de validation de ia transaction sera décrit ultérieurement en référence à la figure 5. 2 2839225 L'étape E320 est suivie par un test E330 au cours duquel le dispositif serveur S vérifie si cette autorisation est accordée. Si tel est le cas, le résultat du test E330 est positif. Ce test est alors suivi par une étape E340 au cours de laquelle le dispositif serveur S transmet l'image I au dispositif client C. En revanche, si l'autorisation n'est pas accordée par le dispositif intermédiaire P. le résultat du test E330 est négatif. Ce test est alors suivi par une étape E350 de notification d'une erreur de transaction au dispositif client C. Les étapes E340 et E350 terminent la procébure de traitement d'une requête RDT de déclenchement de transaction conformément à la présente invention. La figure 4 représente les principales étapes E400 à E450 d'une procédure de traitement d'une requête RAT d'autorisation de transaction par un dispositif intermédiaire P conformément à la présente invention. Au cours de la première étape E400, le dispositif intermédiaire P reçoit la requête RAT d'autorisation de transaction en provenance du dispositif client C. L'envoi de cette requête RAT d'autorisation de transaction a été précédemment décrit en référence à l'étape E200 de la figure 2. Cette étape E400 de réception d 'une req uête RAT d 'a utorisation de transaction est suivie par une étape E410 au cours de laquelle le dispositif intermédiaire P vérifie la validité du paiement associé à la requête RAT d'autorisation de transaction. Cette vérification s'effectue, dans le mode préféré de réalisation décrit ici, en vérifiant si la pièce électronique Pj(C, P) contenue dans la requête RAT d'autorisation permet de réaliser un paiement de montant MP, ce montant étant également compris dans la requête RAT d'autorisation. Si le paiement est valide, le résultat du test E410 est positif. Ce test est alors suivi par une étape E420 au cours de laquelle le dispositif intermédiaire P encaisse le paiement de montant MP contenu dans la requête RAT d'autorisation de transaction. 13 2839225 L'étape E420 est suivie par une étape E440 au cours de laquelle le dispositif intermédiaire P mémorise une information A(C, S) selon laquelle le dispositif client C autorise le dispositif intermédiaire P à répondre positivement à une requête RAL d'autorisation de livraison en provenance du dispositif serveur S pour la livraison de l'image I et pour un montant de paiement MP. Dans le mode de réalisation décrit ici, l'information A(C, S) comporte explicitement le montant de paiement MP et l'identificateur I de l'image I à obtenir. En revanche, si le paiement associé à la requête RAT d'autorisation de transaction n'est pas validé, le résultat du test E410 est négatif. Ce test est alors suivi par une étape E450 au cours de laquelle le dispositif intermédiaire P notifie le dispositif client C d'une erreur. Quoi qu'il en soit, les étapes E440 et E450 terminent la procédure de traitement d'une requête RAL d'autorisation de traitement conformément à la présente invention. La figure 5 représente les principales étapes E500 à E580 d'une procébure de traitement, par le dispositif intermédiaire P. d'une requête RAL d'autorisation de livraison en provenance du dispositif serveur S. Au cours d'une première étape E500, le dispositif intermédiaire P reçoit une requête RAL d'autorisation de livraison envoyée par le dispositif serveur S à l'étape E310 tel que décrit précédemment en référence à la figure 3. L'étape E500 de réception d'une requête RAL d'autorisation de livraison, est suivie par une étape E510 au cours de laquelle le dispositif intermédiaire P vérifie s'il a reçu une autorisation du dispositif client C pour la livraison d'une image I au dispositif serveur S. en comparant l'identificateur I lu dans la requête RAL d'autorisation de livraison avec l'identificateur d'image mémorisé dans l'information A(C, S) au cours de l'étape E440 précédemment décrite. En pratique, ce test consiste à lire si le registre de la mémoire non volatile A(C, S) a été mis à jour conformément à l'étape E440 décrite précédemment. 14 2839225 Si une telle autorisation n'a pas été donnce, le résultat du test E510 est nagatif. Ce test est alors suivi par une étape E550 au cours de laquelle le dispositif intermédiaire P notifie le dispositif serveur S que le client C n'a pas autorisé le dispositif intermédiaire P à accepter cette transaction. En revanche, si une telle autorisation a été donnée, le résultat du test E510 est positif. Ce test est alors suivi par un test E520 au cours duquel le dispositif intermédiaire P vérifie si le montant de paiement MP mémorisé dans l'information A(C, S) à l'étape E440 sur réception de la requête RAT d'autorisation de transaction est supérieur ou égal au montant de paiement MP compris dans la requête RAL d'autorisation de livraison reçue à l'étape E500. Si tel n'est pas le cas, cela signifie que le dispositif serveur S réclame un montant MP supérieur au montant MP réglé par le dispositif client C au profit du dispositif intermédiaire P. Dans ce cas le résultat du test E520 est négatif. Ce test est alors suivi par une étape E570 au cours de laquelle le dispositif intermédiaire P annule l'autorisation reçue du dispositif client C à l'étape E400. En pratique cela revient à mémoriser dans le registre A(C, S) la valeur 0. L'étape E570 d'annulation d'autorisation est suivie par une étape E580 au cours de laquelle le dispositif intermédiaire P rembourse le dispositif client C au moyen des pièces électroniques P(P, C). En pratique, ce remboursement est effectué par l'envoi d'un message AT d'annulation de transaction au dispositif client C. Dans le mode préféré de réalisation décrit ici, le montant de remboursement est inférieur au montant de paiement MP reçu dans la requête RAT d'autorisation de transaction à l'étape E400 déjà décrite. L'étape E580 est suivie l'étape E550 de notification déjà décrite. En revanche, si le montant MP réclamé par le dispositif serveur S estinférieur ou égal au montant MP que le client a payé pour la transaction, le résultat du test E520 est positif. 2839225 Ce test est alors suivi par une étape E530 au cours de laquelle le dispositif intermédiaire P mémorise que l'autorisation pour la transaction a été donnce au dispositif serveur S. En pratique, cela revient à mémoriser la valeur O dans ie registre A(C, S). Cette étape de mémorisation E530 est suivie par une étape E540 du paiement par le dispositif intermédiaire P du montant MP au dispositif serveur S. au moyen de pièces électroniques P(P, S). L'étape E540 de paiement du dispositif serveur S est suivie par une étape E560 au cours de laquelle le dispositif intermédiaire P envoie au dispositif serveur S un message MVT de validation de la transaction, ce message MVT comportant une information représentative de l'acception de la transaction. Les étapes E550 de notification du serveur S. et E560 d'envoi au serveur S du message MVT de validation de la transaction terminent la procédure de traitement d'une requête RAL d'autorisation de livraison selon l'invention. La figure 6 représente les principales étapes E600 à E640 de traitement d'une requête d'annulation RA par le dispositif intermédiaire P. Au cours de la première étape E600, le dispositif intermédiaire P reçoit la requête RA d'annulation envoyée par le dispositif client à l'étape E230 déjà décrite. Cette requête RA d'annulation est envoyée soit lorsqu'une durée TR_MAX s'est écoulée depuis l'envoi de la requête de RDT de déclenchement de transaction, cette requête étant restée sans réponse (résultat du test E220 positifl soit sur interruption volontaire de l'utilisateur (résultat du test E225 positif). L'étape E600 est suivie par un test E610 au cours duquel le dispositif intermédiaire vérifie si cette annulation est acceptable. Dans une première variante de réalisation, une requête d'annulation est acceptable si une durée prédéterminée s'est écoulée depuis la 16 2839225 réception de la requête RAT d'autorisation de transaction, conformément à l'étape E400 déjà décrite. Dans une deuxième variante de réalisation, cette requête RA d'annulation est acceptable si le dispositif serveur S ne peut pas être joint, dans le cas d'une panne ou d'un problème de réseau par exemple. Dans cette variante de réalisation, au cours du test E610 de vérification de l'acceptabilité de l'annulation, le dispositif intermédiaire P effectue une tentative de connexion auprès du dispositif serveur S pour vérifier s'il est effectivement hors d'atteinte. Quoi qu'il en soit, lorsque le dispositif intermédiaire P estime que la requête RA d'annulation est acceptable, le résultat du test E610 est positif. Dans ce cas, le test E610 est suivi par une étape E620 au cours de laquelle le dispositif intermédiaire P annule l'autorisation reçue du dispositif client C à l'étape E400, puis par une étape E630 de remboursement du dispositif client C. Dans le mode préféré de réalisation décrit ici, les étapes E620 et E630 sont semblables aux étapes E570 et E580 décrites précédemment en référence à la figure 5. L'étape E620 d'annulation d'autorisation est suivie par une étape E630 au cours de laquelle le dispositif intermédiaire P rembourse le dispositif client C au moyen des pièces électroniques P(P, C) pour un montant inférieur ou égal au montant de paiement MP reçu dans la requête RAT d'autorisation de transaction à l'étape E400 déjà décrite. Dans un mode de réalisation préféré, le montant de remboursement est strictement inférieur au montant de paiement MP reçu dans la requête RAT d'autorisation, la différence entre ces montants étant utilisée pour rémunérer le dispositif intermédiaire P. En revanche, si le dispositif intermédiaire P estime que la requête RA d'annulation reçue à l'étape E600 n'est pas acceptable, le résultat du test E610 est négatif. Ce test est alors suivi par une étape E640 de notification au dispositif client C du rejet de la requête RA d'annulation. 17 2839225 Quoi qu'il en soit les étapes E630 de remboursement et E640 de notification de rejet terminent la procédure de traitement d'une requete RA d'annulation conformément à la présente invention. La figure 7 reprend de façon synthétique l'échange des messages et requetes entre un dispositif client C, un dispositif serveur S et un dispositif intermédiaire P au cours d'une transaction électronique entre le client C et le serveur S. conformément à la présente invention. La figure 8 représente schématiquement un dispositif intermédiaire de paiement adapté à mettre un _uvre un procédé de traitement conforme à la présente invention, dans un mode préféré de réalisation. Ce dispositif intermédiaire de traitement peut notamment étre constitué par un ordinateur. Da ns l'exem ple de réalisation décrit ici, le d is pos itif interméd ia i re de paiement comporte une carte de communication 807 pour relier le dispositif intermédiaire à un réseau de communication, un clavier 810, un écran 809, reliés à un port d'entrées-sorties 803 d'une carte de traitement 801. La carte de traitement 801 comporte, reliés entre eux par un bus d'adresses et de données 802: - une unité centrale de traitement 800; une mémoire vive RAM 804; - une mémoire morte ROM 805; - une mémoire non volatile FLASH 806 et - le port d'entrées-sorties 803. Chacun des éléments illustrés en figure 8 est bien connu de I'homme du métier des micro-ordinateurs et, plus généralement, des systèmes de traitement de l' information. Ces éléments comm uns ne sont donc pas décrits . ICI. La mémoire vive 804 comporte notamment: - un registre REQUETE pour mémoriser tout type de requete reçue en provenance du dispositif client ou du dispositif vendeur, à savoir en particulier, une requete RAT d'autorisation de transaction, une requete RAL d'autorisation de livraison et une requete RA d'annulation; 1 8 2839225 - un registre MESSAGE pour mémoriser, préalablement à leur envoi, les messages destinés au dispositif client et au dispositif serveur et notamment les messages MVT de validité de la transaction et AT d'annulation de la transaction. La mémoire non volatile FLASH 806 comporte des registres pour mémoriser, conformément au système de paiement Payword, la pièce racine P0 et la dernière pièce valablement reçue Pj, pour les séries de pièces P(C, P), P(P, C) et P(P, S), respectivement utilisées pour: -les paiements effectués par le dispositif client C au profit du dispositif intermédiaire P; - les remboursements effectués par le dispositif intermédiaire P au profit du dispositif client CP en cas d'annulation de la transaction; et -les paiements effectués par le dispositif intermédiaire P au profit du dispositif vendeur V en cas de validation de la transaction. La mémoire non volatile FLASH 806 comporte également un registre A(C, S) pour mémoriser l'information A(C, S) selon laquelle le dispositif client C autorise le dispositif intermédiaire P à répondre positivement à une requête RAL d'autorisation de livraison en provenance du dispositif serveur S. La mémoire morte 805 est adaptée à conserver le programme de fonctionnement de l'unité centrale de traitement 800. Elle comporte notamment un registre "Program" pour mémoriser les instructions d'un programme mettant en _uvre un procédé de traitement conforme à l'invention, tel que décrit précédemment en référence aux organigrammes des figures 2 à 6. Le dispositif de traitement comporte des moyens de communication classiques connus de l'homme du métier, adaptés à communiquer, au moyen de requêtes et de messages avec d'autres dispositifs du réseau de communication. Ces moyens de communication sont en particulier constitués par la carte de communication 807 et des portions de code informatique mémorisées dans la mémoire morte ROM 805 mettant en _uvre des couches protocolaires classiques telles que TCP/IP par exemple. 1 9 2839225 Quoiqu'il en soit ces moyens de communication constituent des moyens de réception adaptés à recevoir une requête RAT d'autorisation de transaction, une requête RAL d'autorisation de livraison et d'une requête RA d'annulation telles que décrites précédemment, ainsi que des moyens d'envoi d'un message AT d'annulation de la transaction à destination du dispositif client C lorsque l'échec est détecté. Les moyens de communication sont en particulier adaptés à reconna'^tre le type d'une requête reçue et à en extraire les différents champs. Le dispositif de traitement comporte des moyens de détection d'un échec de la transaction entre le dispositif serveur S et le dispositif client C. Dans le mode préféré de réalisation décrit ici, ces moyens de détection coopèrent avec une horloge non représentée ici et sont adaptés à calculer une durée écoulée entre la réception d'une requête RAT d'autorisation de transaction et la réception d'une requête RA d'annulation. Ces moyens de détection comportent des moyens d'établissement d'une communication avec le dispositif serveur S. Dans le mode préféré de réalisation, les moyens d'établissement de la communication utilisent les services des couches protocolaires définies ci-dessus, par exemple la fonction PING connue de l'homme du métier. Plus particulièrement, les moyens d'établissement d'une communication sont adaptés à essayer d'établir une communication avec le dispositif serveur pendant une durée prédéterminée, et à générer un signal si la communication ne peut être établie pendant ladite durée. Les moyens de détection sont également adaptés à détecter I'échec de la transaction si le deuxième montant de paiement lu dans la requête RAL d'autorisation de livraison est supérieur au premier montant de paiement MP lu dans la requête RAT d'autorisation de transaction. 2839225 REVENDICATIONS 1. Procédé de traitement d'une transaction électronique entre un dispositif client (C) et un dispositif serveur (S) sur un réseau de communication, ledit procédé de traitement étant mis en _uvre au sein d'un dispositif intermédiaire (P) du réseau de communication et caractérisé en ce qu'il comporte les étapes suivantes: - réception (E400), d'une requête (RAT) d'autorisation de transaction en provenance du dispositif client (C), ladite requête (RAT) d'autorisation comportant un premier montant de paiement (MP); - détection (E510, E520) d'un échec de ladite transaction entre le dispositif serveur (S) et le dispositif client (C); et - envoi (E630, E580) d'un message (AT) d'annulation de ladite transaction à destination du dispositif client (C) lorsque ledit échec est détecté, ledit message (AT) d'annulation de la transaction comportant un montant de remboursement par le dispositif intermédiaire (P) au profit du dispositif client (C). 2. Procédé de traitement selon la revendication 1, caractérisé en ce que ladite étape de détection comprend une étape de réception d'une requête (RA) d'annulation en provenance dudit dispositif client (C). 3. Procédé de traitement selon la revendication 2, caractérisé en ce que l'on détecte l'échec de la transaction quand une durée au moins égale à une durée prédéterminée s'est écoulée entre la réception de ladite requête (RAT) d'autorisation de transaction et la réception de ladite requête (RA) d'annulation. 4. Procédé de traitement selon l'une quelconque des revendications 1 à 3, caractérisé en ce que de ladite étape de détection 2 1 2839225 comporte une tentative d'établissement d'une communication avec ledit dispositif serveur (S). 5. Procédé de traitement selon la revendication 4 caractérisé en ce que l'on détecte l'échac de la transaction, lorsque ladite tentative d'établissement de communication échoue pendant une durée au moins égale à une durse prédéterminée. 6. Procédé de traitement selon l'une quelconque des revendications 1 à 5, caractérisé en ce qu'il comporte en outre, préalablement à ladite étape de détection, une étape de réception, en provenance du dispositif serveur (S), d'une requête (RAL) d'autorisation de livraison comportant un deuxième montant de paiement (MP), et en ce que l'on détecte l'échec de la transaction si led it deuxième montant de paiement (MP) est supérieur aud it premier montant de paiement (MP). 7. Dispositif de traitement d'une transaction électronique entre un dispositif client (C) et un dispositif serveur (S) sur un réseau de communication, ledit dispositif de traitement étant susceptible d'être incorporé dans un dispositif intermédiaire (P) du réscau de communication et caractérisé en ce qu'il comporte: - des moyens de réception d'une requête (RAT) d'autorisation de transaction en provenance du dispositif client (C), ladite requête (RAT) d'autorisation comportant un premier montant de paiement (MP); - des moyens de détection d'un échec de ladite transaction entre le dispositif serveur (S) et le dispositif client (C); et - des moyens d'envoi d'un message (AT) d 'an n ulation de lad ite transaction à destination du dispositif client (C) lorsque ledit échec est détecté, ledit message (AT) d'annulation de la transaction comportant un montant de remboursement par le dispositif intermédiaire (P) au profit du dispositif client (C). 22 2839225 8. Dispositif de traitement selon la revendication 7, caractérisé en ce que lesdits moyens de détection comportent des moyens de réception d'une requête (RA) d'annulation en provenance dudit dispositif client (C). 9. Dispositif de traitement selon la revendication 8, caractérisé en ce que lesdits moyens de détection sont adaptés à calculer une durée écoulée entre la réception de ladite requête (RAT) d'autorisation de transaction et la réception de ladite requête (RA) d'annulation, et à détecter l'échec de la transaction quand ladite durée est supérieure à une durée prédéterminée. 10. Dispositif de traitement selon l'une quelconque des revendications 7 à 9, caractérisé en ce que lesdits moyens de détection comportent des moyens d'établissement d'une communication avec ledit dispositif serveur (S). 11. Dispositif de traitement selon la revendication 1O, caractérisé en ce que lesdits moyens de détection sont adaptés à détecter l'échec de la transaction, lorsque lesdits moyens d'établissement d'une communication ne parviennent pas à établir une communication avec le dispositif serveur (S) pendant une durée au moins égale à une durée prédéterminée. 12. Dispositif de traitement selon l'une quelconque des revendications 7 à 11, caractérisé en ce que lesdits moyens de réception sont adaptés à recevoir, en provenance du dispositif serveur (S), une requête (RAL) d'autorisation de livraison comportant un deuxième montant de paiement (MP,), et en ce que lesdits moyens de détection sont adaptés à détecter l'échec de la transaction si led it deuxième montant de paiement (MP) est supérieu r audit premier montant de paiement (MP). 13. Dispositif intermédiaire caractérisé en ce qu'il comporte des moyens adaptés à meffre en _uvre un procédé de traitement selon l'une quelconque des revendications 1 à 6. 23 2839225 14. Dispositif intermédiaire caractérisé en ce qu'il comporte un dispositif de traitement selon l'une quelconque des revendications 7 à 12. 15. Système de transaction électronique dans un réseau de communication caractérisé en ce qu'il comporte un dispositif intermédiaire selon la revendication 13 ou 14. 16. Support d'informations lisible par un système informatique, éventuellement totalement ou partiellement amovible, notamment CD-ROM ou support magnétique, tel un disque dur ou une disquette, ou support transmissible, tel un signal électrique ou optique, caractérisé en ce qu'il comporte des instructions d'un programme d'ordinateur permettant la mise en _uvre d'un procédé de traitement selon l'une quelconque des revendications 1 à 6, lorsque ce programme est chargé et exécuté par un système informatique. 17. Programme d'ordinateur stocké sur un support d'informations, ledit programme comportant des instructions permettant la mise en _uvre d'un procédé de traitement selon l'une quelconque des revendications 1 à 6, lorsque ce programme est chargé et exécuté par un système informatique.