FR 2819960 A1 20020726 FR 0200399 A 20020114 La présente invention concerne un procédé d'annulation d'une opération exécutée à distance sur une station serveur. Aujourd'hui, de plus en plus d'ordinateurs travaillent en réseau et utilisent des services fournis par d'autres ordinateurs. Ainsi, il est courant sur un réseau de communication qu'une station client, connectée via le réseau à une ou plusieurs stations serveurs, utilise les services de l'une des stations serveurs. Ces services peuvent être par exemple l'exécution à distance d'une opération ou d'une fonction sur un objet informatique hébergé sur la station serveur. A titre d'exemple, la station client peut utiliser les services fournis par la station serveur afin de manipuler une image à distance. Ces services peuvent encore être la fourniture d'un document par la station serveur. Généralement, sur un réseau de communication, ces services fournis par les stations serveurs sont rémunérés et facturés à chaque station client. Ainsi, chaque opération est associée à un coût d'exécution mémorisé sur la station serveur. Lors de l'exécution de chacune de ces opérations, ces dernières sont facturées à la volée à la station client, c'est-à-dire au fur et à mesure de l'exécution de ces opérations. L'invention concerne plus particulièrement l'annulation d'une opération exécutée à distance sur une station serveur. L'annulation d'une telle opération (en anglais"undo") permet d'annuler les effets d'une fonction exécutée à distance. En effet, il n'est pas rare qu'un utilisateur souhaite revenir à un point de départ sur un objet manipulé, par exemple après une manipulation malencontreuse de l'objet. Il est également courant qu'un utilisateur procède par touche successive pour modifier un objet tel qu'une image, et revienne régulièrement en arrière pour supprimer certains effets indésirables. On connaît par exemple le logiciel Adobe Photoshopo qui traite une photographie numérique et applique successivement divers filtres numériques pour trouver le filtre convenant le mieux. Cette possibilité de retour en arrière et d'annulation d'une opération est unanimement plébiscitée et généralement incorporée à la plupart des logiciels du marché. La présente invention a pour but de conserver cette fonction d'annulation dans un système dans lequel les services fournis par les stations serveurs sont rémunérés et facturés à une station client du réseau. Elle permet notamment d'annuler des fonctions dans un environnement collaboratif dans lequel plusieurs stations clients ont accès aux services d'une station serveur. A cet effet, le procédé d'annulation visé par l'invention permet d'annuler à distance une fonction exécutée par une première station client sur un objet informatique stocké sur une station serveur d'un réseau de communication, l'exécution de la fonction étant adaptée à manipuler l'objet d'un état antérieur vers un état manipulé. Conformément à l'invention, ce procédé d'annulation comprend les étapes suivantes : - réception d'une requête d'annulation de l'exécution d'une fonction, émise par une station client du réseau de communication ; obtention dudit état antérieur de l'objet manipulé ; et envoi d'une réponse à la première station client via le réseau de communication, ladite réponse comprenant une somme de monnaie électronique au plus égale à un coût d'exécution associé à ladite fonction. Le procédé d'annulation conforme à l'invention permet à une station client d'annuler une opération effectuée précédemment et de rembourser au moins une partie des frais engagés pour cette exécution à la station client du réseau ayant requis l'exécution de la fonction. Ainsi, l'utilisateur peut être dédommagé des frais engagés pour l'exécution d'une fonction à distance lorsque celle-ci est annulée. En outre, l'envoi de la réponse permet d'informer la première station client de l'annulation de la fonction exécutée antérieurement sur sa requête. Selon une caractéristique préférée de l'invention, à l'étape d'envoi, la somme de monnaie électronique est inférieure ou égale à un montant perçu par la station serveur pour l'exécution de ladite fonction. Ainsi, un montant de remboursement est déterminé à partir du montant effectivement perçu par la station serveur pour l'exécution de la fonction, qui peut inclure notamment des rabais éventuels sur le coût d'exécution de la fonction. Selon une autre caractéristique avantageuse de l'invention, la somme de monnaie électronique est strictement inférieure audit montant perçu. Ainsi, le remboursement est partiel. Bien qu'un remboursement complet soit évidemment plus intéressant pour l'utilisateur, ce dernier risquerait d'abuser de la fonction d'annulation des opérations dans un tel cas. Un remboursement partiel force ainsi les utilisateurs à user de manière plus parcimonieuse de la fonction d'annulation d'une fonction, tout en leur permettant de corriger malgré tout des erreurs éventuelles de manipulation. Selon un autre caractéristique préférée de l'invention, ce procédé d'annulation comprend en outre une étape de calcul d'un coût d'annulation associé à la requête d'annulation reçue, la somme de monnaie électronique étant calculée après déduction du coût d'annulation. Ainsi, la fonction d'annulation peut elle-même être payante à l'instar des autres fonctions exécutables à distance sur la station serveur. Ce coût d'exécution de la fonction annulation, ou coût d'annulation, est ainsi déduit du montant à rembourser. Selon une autre caractéristique préférée de l'invention, le procédé d'annulation comprend en outre une étape de génération d'une monnaie électronique sur ladite station serveur, associée à ladite première station client. Ainsi, la station serveur génère sa propre monnaie électronique pour rembourser la station client ayant requis l'exécution de la fonction annulée. En pratique, lorsque la rémunération de chaque opération exécutée est réalisée au moyen d'une monnaie électronique générée par la station client, il n'est pas possible d'annuler ce paiement en retournant l'argent reçu. En effet, rien ne garantit à la station client que la station serveur ne gardera pas une copie des pièces de monnaie électronique remboursées en vue d'une utilisation frauduleuse. La génération d'une monnaie électronique propre au remboursement permet de résoudre ce problème. Selon une caractéristique préférée de l'invention, le procédé d'annulation comprend une étape de réception d'une requête d'annulation de l'exécution d'une fonction, émise par une deuxième station client du réseau de communication, cette requête d'annulation comprenant une somme de monnaie électronique, et une étape d'envoi d'une deuxième réponse à la deuxième station client via le réseau de communication, la deuxième réponse comprenant une somme de monnaie électronique au plus égale à la somme de monnaie électronique incluse dans la requête d'annulation. Pour chaque requête en annulation d'une fonction, il est possible d'identifier la station client ayant demandée l'exécution préalable de la fonction de telle sorte que la somme de monnaie électronique correspondant au remboursement au moins partiel du coût d'exécution est effectivement envoyé à la station client ayant requis l'exécution de la fonction. Ainsi, lorsque la station client requérant l'annulation d'une fonction est différente de la station client ayant requis son exécution, la station serveur envoie deux réponses : une première réponse à la première station client ayant requis l'exécution de la fonction, dans lequel un montant de remboursement est inclus, et une deuxième réponse à la deuxième station client, ayant requis l'annulation de la fonction. Cette deuxième réponse peut comprendre une somme de monnaie électronique égale à la somme de monnaie électronique incluse dans la requête d'annulation, auquel cas l'annulation de la fonction ne coûte rien à la deuxième station client. Elle peut également être strictement inférieure à la somme de monnaie électronique incluse dans la requête d'annulation, auquel cas un certain coût d'annulation est supporté par la deuxième station client du réseau de communication. En pratique, le procédé d'annulation comprend une étape de calcul d'un coût d'annulation associé à la requête d'annulation reçue de la deuxième station client du réseau de communication, et, à l'étape d'envoi de la deuxième réponse, la somme de monnaie électronique est calculée en déduisant ledit coût d'annulation de la somme de monnaie électronique incluse dans la requête d'annulation. Ainsi, un coût d'annulation est également supporté par l'utilisateur demandant l'annulation de l'exécution d'une fonction. Cela permet d'éviter qu'un utilisateur du réseau de communication annule trop fréquemment des fonctions réalisées préalablement par d'autres utilisateurs du réseau de communication. En pratique, un coût d'annulation peut être facturé à la fois à la première station client, ayant requis et payé l'exécution de la fonction, et à la deuxième station client, ayant requis l'annulation de la fonction. On peut ainsi partager les frais d'annulations entre les différents utilisateurs du réseau de communication. Corrélativement, la présente invention concerne un dispositif d'annulation d'une fonction exécutée par une première station client sur un objet informatique stocké sur une station serveur d'un réseau de communication, l'exécution de la fonction étant adaptée à manipuler ledit objet d'un état antérieur vers un état manipulé. Ce dispositif d'annulation comprend : - des moyens de réception d'une requête d'annulation de l'exécution d'une fonction, émise par une station client du réseau de communication ; des moyens d'obtention dudit état antérieur de l'objet manipulé ; et des moyens d'envoi d'une réponse à ladite première station client via le réseau de communication, ladite réponse comprenant une somme de monnaie au plus égale à un coût d'exécution associé à ladite fonction. Ce dispositif d'annulation d'une opération, incorporé dans une station serveur, présente des caractéristiques et avantages analogues à ceux décrits précédemment pour le procédé d'annulation d'une opération sur une station serveur. La présente invention concerne également une station serveur adaptée à mettre en oeuvre le procédé d'annulation d'une opération conforme à l'invention. Elle concerne aussi un ordinateur et un réseau de communication adapté à mettre en oeuvre le procédé d'annulation d'une opération conforme à l'invention. Enfin, la présente invention vise un programme d'ordinateur, lisible par un microprocesseur, comprenant des portions de code logiciel adaptées à mettre en oeuvre le procédé d'annulation d'une opération conforme à l'invention lorsque le programme d'ordinateur est chargé sur un microprocesseur. Ce réseau de communication, cet ordinateur, cette station serveur et le programme d'ordinateur présentent des caractéristiques et avantages analogues à ceux décrits précédemment. D'autres particularités et avantages de l'invention apparaîtront encore dans la description ci-après. Aux dessins annexés, donnés à titre d'exemples non limitatifs : - la figure 1 est un schéma bloc illustrant une station client et une station serveur d'un réseau de communication adapté à mettre en oeuvre le procédé d'annulation d'une opération conforme à l'invention ; - la figure 2 est un schéma bloc illustrant un ordinateur adapté à mettre en oeuvre l'invention ; - la figure 3 est un algorithme illustrant le procédé d'annulation d'une opération mis en oeuvre sur une station serveur conforme à un mode de réalisation de l'invention ; - la figure 4 est un algorithme détaillant la procédure de calcul d'un coût d'annulation utilisée à la figure 3 ; - la figure 5 est un algorithme détaillant la procédure de calcul d'un montant à rembourser utilisée à la figure 3 ; - la figure 6 est un algorithme détaillant la procédure d'envoi d'un remboursement utilisée à la figure 3 ; - la figure 7 est un algorithme détaillant la procédure d'obtention d'une somme d'argent utilisée à la figure 6 ; - la figure 8 est un algorithme illustrant un procédé d'annulation à une distance d'une opération mise en oeuvre sur une station client ; - la figure 9 est un algorithme détaillant la procédure d'obtention d'un coût d'exécution d'une opération utilisée à la figure 8 ; et - la figure 10 est un algorithme illustrant une procédure de traitement d'une lettre de change mise en oeuvre sur une station client. On va décrire tout d'abord, en référence à la figure 1, un réseau de communication adapté à mettre en oeuvre le procédé d'annulation d'une opération conforme à l'invention. Dans la suite, on considère une station client U connectée à une station serveur H. Bien entendu, dans un réseau de communication, les différents ordinateurs du réseau peuvent être tour à tour station client U ou station serveur H. En outre, dans un réseau de communication, plusieurs stations client sont en réalité connectées à chaque station serveur H. Dans cet exemple, la station client U peut utiliser les services de la station serveur H. En particulier, la station client U peut demander l'exécution d'une opération directement sur la station serveur H. Chaque opération correspond à une série d'instructions d'un programme informatique. Bien entendu, la station client U pourrait également demander d'autres services à la station serveur H, par exemple la fourniture d'un document. Par exemple, et de manière nullement limitative, la station serveur peut héberger des images numériques, et un utilisateur peut, à travers la station client U, effectuer des opérations sur l'une des images de la station serveur H. Les opérations peuvent être la conversion d'une image en noir et blanc, la rotation de l'image ou une symétrie par rapport à un axe horizontal ou vertical de l'image. Lors d'une exécution à distance d'une telle opération, l'image sera constamment stockée sur la station serveur H et ne transitera pas sur le réseau de communication. La station client se contentera d'émettre une requête d'exécution à distance de l'opération à destination de la station serveur. On va considérer dans la suite de la description, un système distribué orienté-objet (en anglais"distributed object system"). Un objet informatique est un élément comprenant des données, également appelées attributs, et des fonctions (en anglais"functions"ou"methods") utilisant éventuellement des paramètres ("input arguments"en anglais). Dans un tel système, les fonctions peuvent être appelées ou invoquées (en anglais "invoked") pour manipuler les données de l'objet. L'ensemble des fonctions applicables à un objet et des attributs constitue son interface. En pratique, la station client U comporte des moyens d'exécution et de paiement 10 pour l'exécution d'une fonction distante f sur un objet o stocké sur la station serveur H. Ces moyens ne nécessitent pas d'être décrits en détails ici pour la suite de l'exposé de l'invention. Pour la mise en oeuvre de l'invention, la station client U comporte des moyens d'envoi 11 d'une requête d'annulation d'une fonction f précédemment exécutée sur la station serveur H. Comme cela sera bien décrit ci-après, cette fonction f à annuler peut avoir été exécutée sur requête provenant de n'importe quelle station client du réseau de communication. Elle comporte également des moyens de réception 12 d'un montant de remboursement retourné par une station serveur H. Des moyens de validation et de perception 13 de la somme reçue permettent de valider le montant de remboursement retourné par la station serveur H. En particulier, des moyens de stockage 14 permettent de mémoriser des lettres de change permettant d'authentifier le montant de remboursement reçu. La mise en oeuvre de ces différents moyens sera expliquée en détail en référence aux figures 6 à 8. Corrélativement, la station serveur H comprend des moyens d'exécution et de rémunération 20 pour exécuter des fonctions suite à la réception d'une requête d'exécution émise par une station client U. Ces moyens d'exécution et de paiement 20 coopèrent avec les moyens de demande d'exécution et paiement 10 de la station client U de manière à exécuter et facturer chaque fonction f sur un objet informatique o. Ces moyens d'exécution et de rémunération 20 coopèrent avec des moyens de stockage 29 permettant de mémoriser l'identité de chaque station client Up du réseau de communication en association avec chaque fonction f exécutée sur requête de cette station client Up. Elle comprend également des moyens de réception 21 d'une requête d'annulation d'une fonction f et des moyens d'annulation 22 de cette fonction f permettant de revenir à un état de l'objet o précédant l'exécution de cette fonction f. Dans ce mode de réalisation, des moyens de stockage 23 permettent de mémoriser le montant perçu Cf par la station serveur H pour l'exécution de chaque fonction f. Ces moyens de stockage 23 coopèrent avec des moyens de calcul 24 permettant de lire et calculer le montant de remboursement. Ces moyens d'obtention 24 comprennent en outre des modes de calcul d'un coût d'annulation et des moyens de comparaison du nombre de demandes d'annulation reçues, mémorisé dans une table d'annulation 28, avec une valeur seuil prédéterminé. Des moyens d'obtention 25 permettent d'obtenir une somme d'argent S correspondant au montant de remboursement. Ces moyens d'obtention 25 coopèrent avec des moyens de stockage de pièces 26 de manière à prélever un nombre de pièces suffisant, et au moins égal au montant de remboursement associé à la fonction à annuler. Des moyens d'envoi 27 permettent d'envoyer à chaque station client le montant de remboursement. Le fonctionnement de l'ensemble de ces moyens permettant de rembourser une station client lors de l'annulation de l'exécution d'une fonction f sera expliqué ultérieurement en référence aux figures 3 et suivantes. L'ensemble de ces moyens 10-14 et 20-29 peuvent être incorporés tant au niveau d'une station client U qu'au niveau de la station serveur H dans un ordinateur tel que représenté à la figure 2. Cet ordinateur comprend de manière classique un microprocesseur 30, une mémoire morte 31 (Read Only Memory ou ROM) et une mémoire vive 32 (Random Access Memory ou RAM) comportant différents registres pour la mise en oeuvre du procédé conforme à l'invention. L'ordinateur comporte notamment une interface de communication 39 pouvant être reliée à un réseau de communication 3 pour recevoir ou transférer des requêtes ou informations. En outre, l'ordinateur comporte des moyens de stockage de documents, tel qu'un disque dur 36, ou est adapté à coopérer au moyen d'un lecteur de disque 37 avec des moyens de stockage amovibles 38 telles que des disquettes, des disques compacts ou des cartes informatiques (PC Card). Ces moyens de stockage fixes ou amovibles peuvent comporter le code du procédé d'exécution d'opérations conforme à l'invention qui, une fois lu par le microprocesseur 30, sera stocké dans le disque dur 36. A titre de variante, le programme permettant au dispositif de mettre en oeuvre l'invention pourra être stocké dans la mémoire morte 31. En seconde variante, le programme pourra être reçu pour être stocké comme décrit précédemment par l'intermédiaire du réseau de communication 3. De manière classique, l'ordinateur possède également un écran 33 permettant par exemple de servir d'interface avec un opérateur à l'aide d'un clavier 34 ou d'une souris 35 ou tout autre moyen. L'unité centrale ou microprocesseur 30 (CPU) va exécuter des instructions relatives à la mise en oeuvre de l'invention. Lors de la mise sous tension, les programmes et méthodes relatives à l'invention, stockés dans une mémoire non volatile, par exemple la mémoire morte 31, sont transférés dans la mémoire vive 32 qui contiendra alors le code exécutable de l'invention ainsi que les variables nécessaires à la mise en oeuvre de l'invention. Ainsi, la mémoire vive 32 incorporée dans une station client d'un réseau de communication comprendra des registres 14 pour stocker notamment les lettres de change délivrées par chaque station serveur H. De même, la mémoire vive 32 incorporée dans une station serveur d'un réseau de communication comprendra des registres pour stocker au moins une table de pièces 26, le montant perçu 23 pour l'exécution de chaque fonction, l'identité 29 de la station client associée à l'exécution de chaque fonction et une table d'annulation 28. Un bus de communication 40 permet la communication entre les différents sous-éléments de l'ordinateur ou liés à lui. La représentation du bus n'est pas limitative et notamment le microprocesseur est susceptible de communiquer des instructions à tout sous- élément directement ou par l'intermédiaire d'un autre sous-élément. On va décrire à présent en référence à la figure 3, le procédé d'annulation d'une opération tel qu'il est mis en oeuvre sur la station serveur H du réseau de communication, selon un mode de réalisation préféré de l'invention. Le procédé d'annulation d'une opération comporte tout d'abord une étape de réception E1 d'une requête d'annulation de l'exécution d'une opération. Cette demande d'annulation est émise par une première station client UA du réseau de communication. On rappelle ici que chaque objet informatique o est écrit dans un langage de programmation utilisé par l'application informatique propre à l'ordinateur qui héberge o et qu'il est par conséquent nécessaire d'utiliser un langage de communication commun au réseau de communication afin de partager les objets informatiques et notamment d'invoquer à distance des fonctions sur ces objets o. Sur le réseau Internet on peut utiliser un langage de communication tel que le langage XML ("eXtended Markup Language"en anglais). L'utilisation de ce langage de communication, permettant de décrire des objets informatiques sur le réseau et d'invoquer à distance des fonctions sur ces objets, est décrit en détail dans la demande de brevet européen 00 401 754.7 déposée par Canon Research Centre France S. A. Nous rappelons ci-après la description des différents champs de données qu'il est nécessaire de traduire dans le langage de communication du réseau pour permettre d'invoquer à distance des fonctions sur des objets o. Champ : interfaces Ce champ permet d'envoyer plusieurs interfaces à des applications distantes. ... Champ : interface Ce champ correspond au concept générique d'une classe d'objet, comme défini dans les langages JAVA ou C++. Une interface décrit les opérations ou fonctions qui sont supportées par un objet informatique o. Ces opérations utilisent généralement des paramètres et fournissent éventuellement un résultat. Une interface décrit également les attributs ou champ de données que tous les objets supportant cette interface contiennent lorsqu'ils sont traduits dans le langage de communication. Une interface peut également contenir une référence à d'autres interfaces, soit qu'elles s'étendent à ces autres interfaces ou fournissent seulement un raccourci (en anglais"short hand") pour utiliser ces autres interfaces. L'objet supporte alors toutes ces autres interfaces référencées. Champ : attribut Ce champ comporte la liste des attributs qu'un objet supportant l'interface contient lorsqu'il est traduit dans le langage de communication. Champ : fonctions Ce champ contient la liste des fonctions ou opérations associées à l'objet informatique supportant cette interface. ... Champ : fonction Ce champ correspond au concept générique de fonction. Une fonction est identifiée par sa signature, par exemple un nom, le type de paramètre utilisé et le type d'objet obtenu lors de l'exécution de cette fonction. Champ : arguments Ce champ contient la liste des paramètres (en anglais"input arguments") dont une fonction a besoin pour sa mise en oeuvre. ... Champ : argument Ce champ correspond à un paramètre d'une fonction et peut être par exemple un objet littéral ou un objet complexe. Le champ fonction permet ainsi d'invoquer une fonction sur un objet distant. On doit spécifier l'objet cible 0 et les paramètres de la fonction comme décrit précédemment. Conformément à l'invention, le champ fonction permet d'invoquer la fonction "annuler" sur un objet distant o. Le nom de la fonction à annuler est inclus dans le champ argument de la fonction"annuler". Une étape d'extraction E2 permet d'extraire l'identité d'une opération qui est ici une fonction f exécutée sur un objet o. Une étape de test E3 permet de vérifier si cette fonction f a déjà été exécutée sur l'objet o sur la station serveur H suite à une requête d'exécution envoyée par une station client U du réseau de communication. Dans la négative, la station serveur H envoie en retour dans une étape d'envoi E9 à la première station client UA une réponse signalant l'impossibilité d'annuler une opération f non exécutée. Si l'opération f a déjà été exécutée, on obtient dans une étape d'obtention E4 la liste de fonctions à annuler. En effet, si cette fonction f n'est pas la dernière fonction exécutée sur l'objet o sur la station serveur, l'étape d'obtention E4 permet d'obtenir la liste des opérations exécutées après l'exécution de cette opération f à annuler. Bien entendu, si la fonction f à annuler est la dernière fonction exécutée, cette liste est restreinte à cette unique fonction f. Une étape d'obtention E5 est mise en oeuvre pour obtenir l'identité de la station client UA, généralement incorporée dans la demande d'annulation de l'exécution d'une opération. Une étape d'obtention E6 est ensuite mise en oeuvre afin d'obtenir un coût d'annulation CA. En effet, comme décrit ultérieurement, le montant du remboursement effectué lors de l'annulation d'une fonction est calculé à partir d'un montant perçu et prend en compte de préférence un coût d'annulation CA. En effet, un remboursement complet, correspondant au montant effectivement perçu pour l'exécution de la fonction est plus intéressant pour chaque utilisateur du réseau de communication, mais risque de surcharger la station serveur H. Les opérations annulées ne coûtant rien aux utilisateurs, ces derniers risquent d'en abuser. En revanche, un remboursement partiel force les utilisateurs à être plus parcimonieux dans l'utilisation de la fonction d'annulation tout en leur permettant de corriger malgré tout les erreurs éventuelles de manipulation. Ainsi, en d'autres termes, la fonction d'annulation est elle-même payante à l'instar des autres fonctions exécutables à distance sur la station serveur H. On peut ainsi calculer un coût d'annulation CA associé à chaque demande d'annulation. Un exemple de calcul va être décrit ci-après en référence à la figure 4. De préférence, la station serveur appliquera un barème dégressif de telle sorte que chaque nouvelle d'annulation sera un peu moins remboursée que la précédente. En pratique, le coût d'annulation CA sera augmenté à chaque nouvelle demande d'annulation reçue par la station serveur H et émise par une même station client UA du réseau de communication. De préférence également ce barème dégressif n'entrera pas en place immédiatement. Chaque station client U bénéficiera d'un certain"crédit" d'annulation de telle sorte que le coût d'annulation sera nul si le nombre de demandes d'annulations n émises par la station client U reste inférieur à une valeur de seuil préfixée T. La procédure de calcul du coût d'annulation CA va être décrite dans un exemple de réalisation en référence à la figure 4. Une étape d'initialisation E401 permet tout d'abord d'initialiser la valeur du coût d'annulation CA à zéro. Ensuite, une étape d'obtention E402 permet d'obtenir l'identité de la station client U ayant envoyé une requête en annulation d'une fonction. Une étape de test E403 permet de vérifier si cette station client U est connue de la station serveur S. Dans la négative, une étape d'ajout E404 permet de mémoriser dans une table d'annulation 28 l'identité de cette station client U en association avec le nombre de demandes d'annulation n émises par cette station client U, initialisée ici à la valeur 0. Une étape de lecture E405 permet de lire à partir de la table d'annulation 28, après l'étape d'ajout E404 ou directement après l'étape de test E403 si la station client U est connue, le nombre d'annulations n effectuées précédemment pour la station client U. Une étape d'obtention E406 permet d'obtenir la fonction à annuler F demandée par la station client U. On vérifie ensuite dans une étape de test E407 si le nombre d'annulations n est supérieur ou égal à une valeur de seuil préfixée T, par exemple égale à 20. Dans la négative, c'est-à-dire si le nombre d'annulations n émises par la station client U reste strictement inférieur à cette valeur de seuil T, une étape de mise à jour du nombre d'annulations E411 est mise en oeuvre de telle sorte que le nombre d'annulations n est incrémentée d'une unité. Sinon, si à l'issue de l'étape de test E407, le nombre d'annulations n est supérieur ou égal à la valeur de seuil T, une étape d'obtention E408 permet d'obtenir à partir des moyens de stockage 23 le montant perçu CF pour l'exécution de la fonction F à annuler. Une étape de calcul E409 permet ensuite de calculer le coût d'annulation unitaire C pour cette fonction à annuler F. En pratique, ce coût d'annulation C représente une fraction du montant perçu CF. Ici, à titre d'exemple non limitatif, le coût d'annulation C est calculé par la formule suivante : La valeur du coût d'annulation C peut ainsi varier entre 0 et CFxt. Le paramètre t représente ainsi le taux maximal remboursable du coût d'exécution perçu pour l'exécution de la fonction à annuler. Plus le paramètre D est grand, plus le coût d'annulation C varie lentement. En fait, lorsque n-T = D, le coût d'annulation C est égal à la moitié de la valeur maximale de remboursement CF x t. Une étape de mise à jour E410 de la valeur du coût d'annulation CA est ensuite mise en oeuvre de telle sorte que : Le coût d'annulation unitaire associé à l'annulation de la fonction F est ainsi ajouté au coût d'annulation global CA. L'étape de mise à jour E411 décrite précédemment est ensuite mise en oeuvre de telle sorte que le nombre d'annulations n est incrémenté d'une unité. Une étape de test E412 permet de vérifier si une autre fonction doit être annulée dans la liste des fonctions obtenue précédemment à l'étape d'obtention E4. En effet, l'annulation d'une fonction peut nécessiter, comme décrit précédemment, l'annulation d'autres fonctions exécutées ultérieurement à la fonction F à annuler. Dans l'affirmative, on obtient dans une étape d'obtention E413 la fonction suivante F à annuler et on réitère pour celle-ci l'ensemble des étapes E407 à E412 décrites précédemment. Lorsque toutes les fonctions à annuler ont été traitées, et qu'ainsi chaque coût unitaire C associé à chaque fonction F a été calculé et ajouté les uns aux autres, une étape de mise à jour E414 permet de mettre à jour dans la table d'annulation 28 le nombre d'annulation n associé à la station client U ayant requis l'annulation d'une fonction. Une étape de réponse E415 permet d'adresser la valeur calculée du coût d'annulation CA pour la suite de la mise en oeuvre du procédé d'annulation tel qu'illustré à la figure 3. En revenant à la figure 3, une étape d'extraction E7 est ensuite mise en oeuvre afin d'extraire un paiement PA inclus dans la requête d'annulation émise par la station client UA. En effet, comme décrit précédemment, la fonction d'annulation est de préférence une fonction payante, au moins à partir d'un certain nombre d'annulations demandées par la station client, de telle sorte qu'un paiement PA doit être inclus dans la requête d'annulation pour l'exécution de cette annulation. Ce paiement peut être réalisé par l'introduction d'une somme de monnaie électronique dans la requête d'annulation. Une étape de test E8 permet de comparer la valeur du coût d'annulation CA obtenu à l'étape E6 à la valeur du paiement PA extrait à l'étape E7. Si la valeur du paiement PA est strictement inférieure au coût d'annulation CA, un message d'erreur est retourné dans une étape de réponse E9 afin de signaler à la station client UA l'impossibilité de réaliser l'annulation de la fonction F demandée. Sinon, lorsque le coût d'annulation CA est inférieur ou égal à la valeur du paiement PA, on met en oeuvre les étapes suivantes E10 à E27 afin de déterminer le montant des remboursements à effectuer et les stations clients U du réseau de communication à rembourser et afin de réaliser l'annulation proprement dite des fonctions identifiées à l'étape E4. Lors de l'annulation d'une fonction F sur la station serveur H, il est équitable de procéder au remboursement de la station client ayant requis l'exécution de cette fonction et payé ainsi son exécution. En pratique, une étape d'initialisation E10 permet d'initialiser un tableau de remboursement R. Ce tableau de remboursement R permet d'associer à chaque station client U du réseau, une somme S correspondant à un montant de remboursement à retourner à cette station client U. Une étape de mise à jour EU permet d'ajouter tout d'abord dans le tableau de remboursement R la somme à rembourser à la première station client UA ayant requis l'annulation d'une fonction. En pratique, on mémorise l'identité de la station UA et une somme S = PA-CA correspondant ainsi au paiement reçu PA de la station client UA duquel est déduit le coût d'annulation CA calculé précédemment. Une étape de sélection E12 permet ensuite de sélectionner la dernière fonction exécutée dans la liste obtenue à l'étape d'obtention E4. On vérifie dans une étape de test E13 si cette fonction est inversible, c'est-à-dire s'il existe une fonction inverse permettant de revenir à un état précédent sur l'objet o. A titre d'exemple de fonction inversible, on peut citer lors de la manipulation d'une image une rotation de l'image d'un quart de tour à droite, dont la fonction inverse est la rotation de l'image d'un quart de tour à gauche, une symétrie par rapport à un axe, dont la fonction inverse est la fonction ellemême, et/ou encore une fonction d'agrandissement d'un ratio prédéterminé, dont la fonction inverse est la fonction de diminution de l'image du même ratio. Dans le cas où cette fonction est inversible, on obtient sa fonction inverse dans une étape d'obtention E14 puis on applique dans une étape E15 cette fonction inverse à l'objet o à manipuler. Sinon, si la fonction n'est pas inversible, on obtient dans une étape d'obtention E16 l'état précédent qui a été mémorisé lors de l'exécution de la fonction à annuler, et on applique cet état précédent dans une étape E17. En effet, il est alors nécessaire de mémoriser l'état du système avant chaque exécution de chaque fonction et de revenir à cet état antérieur lors de l'annulation. Tel est le cas notamment des fonctions permettant de transformer une image en noir et blanc, d'appliquer des filtres permettant de rendre flou ou encore d'accentuer les détails d'une image. Par exemple, le logiciel PhotoShop garde en mémoire chaque version successive d'une image afin de permettre l'annulation de n'importe laquelle des opérations effectuées. Ces deux mécanismes d'annulation d'une opération sont bien connus de l'homme du métier et ne seront pas décrits plus en détail ici. On obtient ensuite dans une étape d'obtention E18 l'identité de la station client Up ayant requis, et ainsi payé, l'exécution de la fonction annulée précédemment. Une étape de calcul E19, détaillée à la figure 5, permet de calculer un montant M à rembourser à cette station client Up pour l'annulation de cette fonction. Cette procédure de calcul du remboursement M va être décrite dans un exemple de réalisation en référence à la figure 5. Une étape d'obtention E501 permet d'obtenir l'identité de la station client U ayant exécuté et payé la fonction à annuler. Une étape de test E502 permet de vérifier si cette station client U est connue de la station serveur S. Dans la négative, une étape d'ajout E503 permet de mémoriser dans une table d'annulation 28 cette station client U en association avec le nombre m de demandes d'exécution de fonctions qui sont ensuite annulées, émises par cette station client U. Ce nombre m est initialisé ici à la valeur 0. Une étape de lecture E504 permet, après l'étape d'ajout E503 ou directement après l'étape de test E502 si la station client U est connue, de lire à partir de la table d'annulation 28 le nombre d'exécutions de fonctions ensuite annulées m effectué précédemment par la station client U. Une étape de lecture E505 permet de lire dans les moyens de stockage 23 le montant perçu CF lors de l'exécution de la fonction. En effet, pour chaque fonction, un coût d'exécution c est associé et généralement mémorisé dans l'interface de l'objet o. Cependant, le montant effectivement perçu CF par la station serveur H peut être inférieur à ce coût d'exécution c, notamment lorsque la station serveur applique des rabais. Le montant de remboursement M sera donc toujours inférieur ou égal au coût d'exécution c associé à la fonction, et en particulier inférieur ou égal au montant effectivement perçu CF lors de l'exécution de cette fonction par la station serveur. On vérifie ensuite dans une étape de test E506 si le nombre d'exécutions de fonctions annulées m est supérieur ou égal à une valeur de seuil préfixé T, par exemple égal à 20. Dans la négative, c'est-à-dire si le nombre d'exécutions de fonctions annulées m émises par la station client U est strictement inférieur à cette valeur de seuil T, une étape de calcul E509 du montant M à rembourser est mise en oeuvre de telle sorte que ce montant M = CF. Ainsi, tant que le nombre d'exécutions de fonctions annulées m reste inférieur à la valeur de seuil T, le montant remboursé à la station client U correspond exactement au montant facturé CF lors de l'exécution de la fonction à annuler. Une étape de mise à jour E510 du nombre m est ensuite mise en oeuvre de telle sorte que le nombre d'exécutions de fonctions ensuite annulées m est incrémenté d'une unité. Sinon, si à l'issue de l'étape de test E506, le nombre d'exécutions de fonctions annulées m est supérieur ou égal à la valeur de seuil T, une étape de calcul E507 d'un coût d'annulation C est mise en oeuvre comme précédemment. A titre d'exemple non limitatif, le coût d'annulation C est calculé par la formule suivante : Comme précédemment, la valeur du coût d'annulation C peut varier entre 0 et CF X tR, OÙ tR est un taux maximal de remboursement en fonction du montant effectivement perçu CF lors de l'exécution de la fonction. Une étape d'association E508 permet ensuite de calculer le montant de remboursement M de telle sorte que : On déduit ainsi du montant effectivement perçu CF un coût d'annulation C dépendant du nombre d'exécutions de fonctions annulées m requis par la station client U. Le montant de remboursement M sera ainsi strictement inférieur au montant effectivement perçu CF lors de l'exécution de la fonction. L'étape de mise à jour E510 du nombre d'exécutions de fonctions annulées m est également mise en oeuvre après l'étape de calcul E508 de manière à incrémenter d'une unité ce nombre m. On met ensuite à jour dans une étape de mise à jour E511 la table d'annulation 28 à partir de cette nouvelle valeur m puis la procédure du calcul de remboursement M est terminée et la valeur calculée M est adressée pour la suite de la mise en oeuvre du procédé d'annulation tel qu'illustré à la figure 3. On met ensuite à jour la table de remboursement R. En pratique, on vérifie si le client Up ayant payé l'exécution de la fonction et pour lequel le montant M à rembourser vient d'être calculé est connu et déjà mémorisé dans le tableau de remboursement R. Dans la négative, une étape d'ajout E21 permet de mémoriser l'identité de cette station client Up dans le tableau de remboursement R en association avec une somme S à rembourser, ici initialisée à 0. Une étape de lecture E22 permet de lire ensuite la somme Sp associée à la station Up à rembourser à partir de la valeur mémorisée dans le tableau de remboursement R. Cette étape de lecture E22 est mise en oeuvre directement à l'issue de l'étape de test E20 lorsque la station client Up est déjà mémorisée dans le tableau de remboursement R. La somme à rembourser Sp à cette station client Up est ensuite mise à jour dans une étape de calcul E23 dans laquelle : Le montant de remboursement M calculé précédemment à l'étape de calcul E19 est ainsi ajouté au montant global à rembourser à la station Up. Une étape de mise à jour E24 permet ensuite de mémoriser cette nouvelle valeur de somme à rembourser Sp dans le tableau de remboursement R en association avec l'identité de la station client Up. Une étape de test E25 permet de vérifier si la liste des fonctions à annuler est épuisée. Dans la négative, on sélectionne dans une étape de sélection E26 la fonction précédente dans cette liste et on réitère sur cette fonction l'ensemble des étapes E12 à E25 décrites précédemment. On calcule ainsi pour chaque fonction à annuler le montant M à rembourser en association avec la station client U ayant payée l'exécution de cette fonction à annuler. Lorsque la liste des fonctions à annuler est épuisée, à l'issue de l'étape de test E25, une étape d'envoi E27 permet d'envoyer proprement dit les remboursements à chaque station client du réseau de communication, à partir de l'identité de ces stations clients et des valeurs de remboursement S associées mémorisées dans le tableau de remboursement R. En pratique, comme illustré à la figure 6, pour envoyer des remboursements, on génère plusieurs messages de réponse à l'attention des stations clients du réseau de communication. On lit dans une étape d'obtention E601, une première ligne du tableau R, c'est-à-dire l'identité d'une station client U et une somme à rembourser S calculée précédemment. Un message de réponse A est ensuite généré dans une étape E602 à destination de la station client U. Une étape d'obtention E603 est alors mise en oeuvre pour obtenir une somme S correspondant à la somme globale à rembourser. Cette étape est décrite en détail à la figure 7. De manière générale lors de cette étape, on génère une monnaie électronique sur la station serveur H, cette monnaie électronique étant associée à la station client U à rembourser et le montant d'argent électronique généré étant supérieur ou égal à la somme à rembourser S. En pratique, la station serveur génère une chaîne de pièces pour chaque station client, cette chaîne de pièces servant aux remboursements consécutifs de différentes opérations annulées par cette station client. Afin d'obtenir cette somme d'argent S, il est nécessaire de générer une monnaie électronique sur la station serveur H permettant de créer une suite de pièces qui peuvent ensuite être dépensées sur le réseau de communication pour rembourser la station client U. On utilise à titre d'exemple, pour générer cette monnaie électronique, un système dit PayWord proposé par Rivest et Shamir. Une description de ce système peut être consultée à l'adresse Internet http ://theory. lcs. mit. edu/-rivest/RivestShamir-mpay. ps. Ce système consiste de manière générale, à partir d'un nombre aléatoire Wn, de générer une suite de nombres à l'aide d'une fonction de hachage (en anglais Hash function). Ce système PayWord présente l'avantage d'être fiable et de ne pas requérir l'approbation d'un organisme tiers (banque, notaire, etc. ) pour valider chaque paiement individuel. En pratique, on vérifie dans une étape de test E70 si la station client U est connue de la station serveur H. Dans la négative, la station serveur tire un nombre au hasard dans une étape de tirage aléatoire E73. Soit le nombre aléatoire Wn. On applique ensuite, dans une étape de frappe de pièce E74, de manière récursive, une fonction de hachage connue telle que : Cette fonction de hachage h a la particularité de ne pas être réversible de telle sorte qu'il est impossible, à partir d'un nombre Wn-1 de retrouver le nombre précédent Wn. On obtient ainsi une série de pièces Wn, Wn-1,... W2, W1, Wo. L'extrémité Wo de la chaîne de nombres ainsi obtenue est appelée pièce racine (en anglais Root Coin) et permet de vérifier l'authenticité des différentes pièces. Ce système PayWord permet avantageusement de vérifier l'authenticité des pièces par simple application de la fonction de hachage. Lors de la génération d'une telle monnaie électronique, il est nécessaire que la station serveur H obtienne un certificat d'une banque afin de prouver son identité. Deux certificats sont utilisés : - un certificat de banque C (PKe), émis par une banque en réponse à une requête de la station serveur ; et - une lettre de change C (Wo) générée directement par la station serveur H. Le certificat de banque C (PKe) est une assurance pour chaque utilisateur que la banque honorera toute demande de rédemption de pièces authentiques. La lettre de change C (Wo) est une assurance pour chaque utilisateur que les pièces produites par la station serveur sont bien authentiques et seront honorées par la banque. En pratique, la station serveur envoie à un organisme bancaire le numéro de sa carte de crédit ainsi que sa clé publique PKe. L'organisme bancaire retourne un certificat de banque C (PKe) qui contient l'identité de l'organisme bancaire, l'identité de la station serveur et la clé publique de la station serveur PKe. Ce certificat comporte en outre une signature électronique authentifiant les informations qu'il contient, cette signature étant réalisée par la banque à l'aide de sa clé privée SKb. Une fois les différentes pièces Wo, Wu,..., Wn générées, ces pièces sont mémorisées dans une étape de mémorisation E75 dans la table des pièces 26 telle qu'illustrée à la figure 1 en association avec un identifiant de la station client U et un indice i, initialisé à la valeur 0, correspondant à l'indice de la dernière pièce utilisée dans la table des pièces 26. En outre, à partir du certificat de banque C (PKe) obtenu de la banque, la station serveur H génère dans une étape de création de lettre de change E76, un certificat ou lettre de change à destination de la station client U. Chaque lettre de change contient le certificat de banque C (PKe) précédemment reçu, l'identité du client U auquel il est destiné, ainsi que la pièce racine Wo. Cette lettre de change comporte en outre une signature électronique authentifiant les informations qu'elle contient, cette signature étant réalisée par la station serveur à l'aide de sa clé privée SKe. Après cette étape de création E76 d'une lettre de change, cette dernière est envoyée dans une étape d'envoi E77 à la station client U. Les lettres de change et les pièces sont spécifiques à un utilisateur donné. En définitive, la station client U reçoit par l'intermédiaire du certificat C (PKe) les informations suivantes : l'identité de l'organisme bancaire, de la station serveur, la clé publique de la station serveur PKe, et la pièce racine Wo. On rappelle que la clé publique de la station serveur PKe est contenue dans le certificat de la banque C (PKe). L'authenticité de cette clé peut donc être établie en comparant la valeur obtenue en décodant la signature de ce certificat à l'aide de la clé publique de la banque PKb, aux informations initiales contenues dans ce certificat (signature exclue). Par ailleurs, on rappelle que la pièce Wo est contenue dans la lettre de change de la station serveur C (Wo). L'authenticité de cette pièce peut donc être établie en comparant la valeur obtenue en décodant la signature du certificat à l'aide de la clé publique PKe précédemment authentifiée, aux informations initiales contenues dans ce certificat (signature exclue). Ainsi, par le jeu d'une double signature, chaque client est capable de vérifier qu'il est bien en possession d'une pièce racine Wo émise par un serveur, connu de la banque, et autorisé par celle-ci à émettre des pièces de monnaie électronique. Si à l'issue de l'étape de test E70 la station client U est déjà connue, on vérifie dans une étape de test E71 si la table de pièces 26 contient suffisamment de pièces utilisables par cette station serveur H pour rembourser la somme de remboursement S à la station client U. Dans la négative, une étape de suppression E72 permet d'effacer les pièces restantes dans la table de pièces 26 et on met en oeuvre les étapes décrites précédemment E73 à E77 pour générer de nouvelles pièces utilisables par la station serveur H pour rembourser la station client U. Ainsi, la table de pièces 26 est remplie automatiquement dès lors qu'elle ne contient plus suffisamment d'argent électronique permettant de rembourser la station client U. Le nombre de pièces générées par la station serveur H peut dépendre éventuellement de la fréquence d'utilisation de cette station serveur H par la station client U. Ce nombre de pièces peut également être constant et déterminé une fois pour toute. On remarque qu'il est préférable de générer un grand nombre de pièces lors de l'étape de frappe de pièces E74 et de stocker celles-ci dans la table de pièces 26 pour une utilisation ultérieure, c'est-à-dire lorsque plusieurs fonctions exécutées par la station client U sont annulées par lui-même ou par une autre station client du réseau de communication. Les pièces générées ont chacune une longueur par exemple de 32 octets. L'indice de la pièce dans la suite de pièces générées peut être codé sur 16 bits, ce qui permet de générer 216 pièces. En revenant à la figure 6, la station serveur H met en oeuvre une étape de lecture E604 permettant de lire dans la table de pièces 26 l'indice de la dernière pièce utilisée. Pour une somme de remboursement S, et en supposant que chaque pièce W, correspond à une fraction unitaire de cette somme S, on prélève S pièces de la table de pièces 26. * Ici, la somme d'argent S remboursée pour l'annulation de la fonction f est inscrite directement dans la réponse envoyée à la station client U. En pratique, on inscrit dans la réponse la valeur (W, s, i + S). Bien entendu, à l'étape de remboursement, chaque montant de remboursement calculé M ou la somme de remboursement globale S pourraient être crédités dans un compte associé à la station client U, puis être utilisés pour rémunérer l'exécution de fonctions ultérieurement. Après cette étape d'inscription E605, une étape de mémorisation E606 permet de mémoriser le nouvel indice i + S correspondant à la dernière pièce utilisée dans la table de pièces 26 pour la station client U. Ainsi, la réponse A transmise par la station serveur H lors de l'étape d'envoi E607 contient la somme d'argent S correspondant à l'annulation de la fonction demandée. On vérifie ensuite dans une étape de test E608 s'il existe une autre ligne dans le tableau de remboursement R, c'est-à-dire une autre station client U à rembourser d'une somme d'argent S. Dans l'affirmative, on réitère l'ensemble des étapes E601 à E607 décrit précédemment. Lorsque toutes les lignes du tableau de remboursement R ont été traitées, la procédure de remboursement est terminée. Ainsi, un message de réponse A est à la fois envoyé à la première station client UA du réseau de communication ayant requis l'annulation d'une fonction et à une ou plusieurs autres stations clients du réseau de communication qui ont préalablement exécuté et payé la ou les fonctions à annuler. Bien entendu, lorsque la première station client UA requiert l'annulation d'une fonction dont elle a requis elle-même et payé l'exécution, elle reçoit à titre de remboursement le montant effectivement perçu lors de l'exécution de cette fonction auquel est déduit éventuellement un coût d'annulation CA. Parallèlement à la mise en oeuvre de ce procédé d'annulation d'opérations sur la station serveur H, un procédé de demande d'annulation d'une fonction à distance est mis en oeuvre sur la station client UA, tel qu'illustré à la figure 8. Ce procédé de demande d'annulation d'une fonction à distance comporte tout d'abord une étape de génération E801 d'une requête d'annulation d'une fonction à distance. Cette requête d'annulation inclut un paiement PA, qui peut utiliser le système de paiement Payword décrit précédemment. La requête d'annulation à distance d'une fonction sur un objet o est ensuite envoyée dans une étape d'envoi E802 par la station client U à destination de la station serveur H. Ensuite, une étape de réception E803 d'un résultat permet de réceptionner une réponse A envoyée par la station serveur H à l'issue du procédé d'annulation d'opérations tel que décrit précédemment en référence aux figures 3 et suivantes. Un test E804 permet de vérifier s'il existe une lettre de change dans la table 14 de la station client U correspondant à la station serveur H. La mémorisation d'une telle lettre de change sera décrite ultérieurement en référence à la figure 9. Dans la négative, une étape d'information E815 permet d'informer l'utilisateur de cette anomalie. Si cette lettre de change existe, une étape de test E805 permet de vérifier que la réponse comporte bien dans un champ spécifique une somme d'argent S correspondant à un remboursement. Comme décrit précédemment, lorsque la station client UA demande l'annulation d'une fonction dont elle a elle-même payé et requis l'exécution à distance, la somme à rembourser S correspond à la somme du paiement envoyée PA et du coût perçu CF par la station serveur pour l'exécution de la fonction, de laquelle est déduit un coût d'annulation CA. Si cette station client UA n'a pas requis elle-même l'exécution de la fonction à annuler, la somme à rembourser S ne comportera pas le montant perçu CF par la station serveur H pour l'exécution de la fonction. Si aucun remboursement n'est inclus dans la réponse A, la procédure de traitement de la réponse est également interrompue. Sinon, une étape d'extraction E806 est mise en oeuvre afin de lire le montant mémorisé, correspondant ici à une pièce Wi et à son indice i dans la chaîne de pièces générées au niveau de la station serveur H. A partir de la lecture de la lettre de change dans la table 14, on peut obtenir la valeur de la pièce racine Wo dans une étape de lecture E807. Une étape de validation E808 permet alors de vérifier l'authenticité de la pièce W,. En pratique, on applique sur cette pièce courante W, la fonction de hachage h de manière récursive, et ici i fois : h (h (... h (Wi))) La valeur ainsi obtenue est comparée à la valeur de la pièce racine Wo. On peut également, pour accélérer cette étape de validation E808, appliquer, de manière récursive, i-j fois la fonction de hachage h, c'est-à-dire un nombre de fois juste suffisant pour retrouver une pièce W,, d'indice j inférieur à l'indice courant i, et déjà envoyée par le serveur pour le remboursement de l'exécution d'une fonction à annuler. Si la valeur obtenue est différente, la procédure de traitement de la requête d'exécution de fonction est interrompue. La vérification du remboursement par la station client U est une opération simple, consistant à appliquer une fonction de hachage. En particulier, il n'est ni nécessaire de faire appel à un organisme bancaire pour la vérification, ni de mettre en oeuvre des procédés cryptographiques coûteux. Après validation des pièces reçues, on vérifie dans une étape de test E809 si la station client U ayant reçu le remboursement est également la station client ayant requis préalablement l'exécution de la fonction. En pratique, en référence à l'algorithme de la figure 3, on vérifie si la station client ayant requis l'annulation UA est également la station client Up ayant requis et payé l'exécution de la fonction. Dans l'affirmative, une étape d'obtention E810 du coût c associé à l'exécution de la fonction f appliquée à l'objet o est mise en oeuvre. Cette étape d'obtention E810 du coût est mise en oeuvre comme décrit ci-après en référence à la figure 9. Le coût d'exécution c peut être inclus directement dans la réponse A envoyée par la station serveur. Sinon, une procédure particulière peut être mise en oeuvre pour obtenir ce coût d'exécution, comme illustré à la figure 9. Cette procédure d'obtention du coût d'exécution c de la fonction f comporte tout d'abord un test E91 pour vérifier si l'interface associée à l'objet o est disponible sur la station client U. En pratique, on vérifie si une interface correspondante a déjà été mémorisée dans la mémoire cache 15 de la station client U. Dans la négative, une étape E92 est mise en oeuvre pour obtenir cette interface auprès de la station serveur H. La requête d'obtention d'une interface comprend l'adresse informatique de l'interface. Lorsque la station serveur H reçoit la requête d'obtention d'interface, la station serveur extrait de cette requête l'adresse informatique référençant l'interface demandée. La station serveur peut, à partir d'une table, retrouver l'interface demandée et la transmettre à la station client U, après éventuellement traduction de cette interface dans le langage de communication du réseau de communication. Comme décrit précédemment, cette interface comprend une ou plusieurs fonctions associées au code d'exécution de ces fonctions. Chaque fonction est en outre associée à un coût d'exécution de cette fonction. On donne ci-après un exemple d'une interface permettant de manipuler une image à distance. Cette interface comporte trois fonctions : -"ConvertToB & W" dont le prix est constant. Cette fonction permet de convertir une image en noir et blanc ; -"Rotate" dont le prix dépend de la taille de l'image et de l'angle de rotation. Le prix est exprimé sous forme d'une expression que la station client peut évaluer : cette fonction permet de changer l'orientation d'une image. -"Flip" dont le prix dépend de paramètres déterminés par la station serveur. Le client n'est pas capable d'effectuer lui-même le calcul du prix ; le prix est par exemple disponible à l'adresse informatique suivante : http ://oceania/web-obj/ctass/) rnage. xm) #ftip#price Cette fonction permet d'appliquer une symétrie à l'image. ://oceania/web-obi/class/lmage. xml/ > name="width"price="0. 01 FF"/ > name="height"price="0. 01 FF"/ > name="encoding"/ > currency name="FF"/ > function price (width, height, angle) { return width*height*angle ; } name="flip" > Après réception de l'interface, une étape de mémorisation E93 permet de mémoriser l'interface pour une utilisation ultérieure dans la mémoire cache 15 de la station client U. Une étape de lecture E94 permet de lire dans l'interface reçue le coût c associé à la fonction f que l'on souhaite annuler. On vérifie dans une étape de test E95 si le coût est une expression à calculer. Dans l'affirmative, une étape d'évaluation E96 permet d'évaluer le coût de la fonction à exécuter à partir de l'expression reçue. Tel est le cas par exemple pour la fonction rotation"rotate". Sinon, on vérifie dans une étape de test E97 si le coût de la fonction est fixe. Tel est le cas par exemple pour la transformation d'une image en noir et blanc. Sinon, une étape d'obtention E98 est mise en oeuvre pour demander le coût de la fonction à la station serveur. Tel est ici le cas pour la fonction symétrie"flip". On obtient ainsi, à l'issue de l'étape E810 de la figure 8, le coût c associé à la fonction f que l'on souhaite annuler. Ensuite, une étape de lecture E811 permet de lire l'indice j de la dernière pièce reçue, et une étape de test E812 permet de vérifier si le nombre de pièces reçues i-j est très différent du coût c de la fonction à annuler. En pratique, on vérifie à l'étape de test E812 l'inégalité suivante : i-j c où c est le coût associé à la fonction f, i est l'indice de la pièce courante, et j est l'indice de la dernière pièce reçue par la station client U. Si le remboursement inclus dans la réponse n'est pas suffisant, la procédure de traitement de cette réponse est interrompue et l'anomalie est signalée à l'utilisateur à l'étape d'information E815. Sinon, une étape de mémorisation E813 permet de mémoriser le nouvel indice i comme indice j de la dernière pièce reçue. Si à l'issue de l'étape de test E809, la station client UA ayant reçu le remboursement n'est pas la station client Up ayant payé et requis l'exécution de la fonction, l'étape de mémorisation E813 peut être directement mise en oeuvre. Alternativement, les étapes de vérification E810 à E812 peuvent également être mises en oeuvre par cette station client UA. Une étape d'ajout E814 permet ensuite de mémoriser la pièce prélevée W, associée à son indice i dans un porte-monnaie électronique de la station client U. Périodiquement, chaque station client U peut retransmettre à l'organisme bancaire les valeurs W, associées à chaque indice i, mémorisées dans le porte-monnaie électronique, afin d'en récupérer la valeur monétaire. Alternativement, à l'étape d'ajout E814, une carte pré-payée ou une carte informatique telle que divulguée dans les figures 4 et 8 du brevet américain US 5 937 395 peut être utilisée comme porte-monnaie électronique de la station client U. On va décrire à présent, en référence à la figure 10, la procédure de traitement d'une lettre de change reçue par une station client U lors de la réception d'un premier remboursement adressé par la station serveur H. Après réception de cette lettre de change, une étape d'obtention E101 permet à la station client U d'obtenir auprès d'un organisme de certification la clé publique de la banque PKb correspondant à la procédure de signature utilisée par la banque. Comme décrit précédemment, une étape de vérification E102 du certificat de banque C (PKe) peut être mise en oeuvre à partir de la clé publique de banque PKb afin de vérifier la signature. A l'issue d'une étape de test E103, si cette signature est non valide, la procédure est interrompue. Sinon, une étape de lecture E104 est mise en oeuvre afin de lire la clé publique de la station serveur PKe. Cette clé publique PKe permet de vérifier dans une étape E105 la signature de la lettre de change C (Wo) reçue par la station client. A l'issue d'une étape de test E106, si cette signature est non valide, la procédure est interrompue. Sinon, une étape de lecture E107 est mise en oeuvre afin de connaître l'identité de la station serveur H. Une étape de mémorisation E108 permet ensuite de mémoriser la lettre de change dans la table de lettre de change 14 de la station client U. En pratique, chaque identifiant de station serveur H est mémorisé en association avec le certificat d'authenticité ou lettre de change C (Wo), et plus précisément avec la valeur de la pièce racine Wo. Cette lettre de change permet ainsi à la station client U d'authentifier les pièces reçues de la station serveur H et de valider la somme de remboursement reçue S. Une fois cette étape exécutée, le remboursement est considéré comme acquis. Grâce à cette génération d'une monnaie électronique sur la station serveur H, ce dernier n'envoie pas au client ses propres pièces, ce qui ne peut être mis en oeuvre de manière fiable, mais utilise au contraire un jeu de pièces électroniques séparé comme décrit précédemment. Le mécanisme de remboursement décrit dans ce mode de réalisation est mis en oeuvre de manière symétrique au mécanisme mis en oeuvre pour rémunérer les fonctions exécutées sur la station serveur. Bien entendu, de nombreuses modifications peuvent être apportées à l'exemple de description décrit ci-dessus sans sortir du cadre de l'invention. Ainsi, dans l'exemple de réalisation décrit précédemment, un coût d'annulation est supporté à la fois par la station client UA ayant requis l'annulation de la fonction et la station client Up ayant requis préalablement l'exécution de la fonction. Bien entendu, le coût d'annulation pourrait n'être imputé qu'à la station client UA ayant requis l'annulation de la fonction. La station serveur pourrait aussi proposer de refaire des fonctions annulées. Dans ce cas, le coût pour exécuter de nouveau une fonction pourrait être égal soit : - au montant remboursé lors de l'annulation de la fonction ; - au coût initial d'exécution de la fonction ; ou - un coût différent, compris entre le montant remboursé lors de l'annulation et le coût initial d'exécution de telle sorte qu'une nouvelle exécution d'une fonction annulée coûterait moins cher que l'exécution initiale de la fonction. Cela peut se justifier dès lors que la station serveur a conservé en mémoire le résultat de l'exécution de la fonction après son annulation. REVENDICATIONS 1. Procédé d'annulation d'une fonction (f) exécutée par une première station client (Up) sur un objet informatique stocké sur une station serveur (H) d'un réseau de communication, l'exécution de la fonction (f) étant adaptée à manipuler ledit objet d'un état antérieur vers un état manipulé, caractérisé en ce qu'il comprend les étapes suivantes : réception (E1) d'une requête d'annulation de l'exécution d'une opération (f), émise par une station client (UA) du réseau de communication ; obtention (E12-E17) dudit état antérieur de l'objet manipulé ; et envoi (E27) d'une réponse à la première station client (Up) via le réseau de communication, ladite réponse comprenant une somme de monnaie électronique au plus égale à un coût d'exécution (c) associé à ladite fonction (f). 2. Procédé d'annulation conforme à la revendication 1, caractérisé en ce qu'il comprend une étape de génération (E603) d'une monnaie électronique sur ladite station serveur (H), associée à ladite première station client (Up). 3. Procédé d'annulation conforme à l'une des revendications 1 ou 2, caractérisé en ce qu'à l'étape d'envoi (E27), la somme de monnaie électronique est inférieure ou égale à un montant perçu (CF) par la station serveur (H) pour l'exécution de ladite fonction (F). 4. Procédé d'annulation conforme à la revendication 3, caractérisé en ce que la somme de monnaie électronique est strictement inférieure audit montant perçu (CF). 5. Procédé d'annulation conforme à l'une des revendications 1 à 4, caractérisé en ce qu'il comprend en outre une étape de calcul (E502-507) d'un coût d'annulation (C) associé à la requête d'annulation reçue ; et en ce que la somme de monnaie électronique est calculée après déduction dudit coût d'annulation (F). 6. Procédé d'annulation conforme à la revendication 5, caractérisé en ce que le coût d'annulation (C) est nul si le nombre de requêtes d'exécutions de fonctions annulées (m) émises par la station client (Up) est inférieur à une valeur de seuil préfixée (T). 7. Procédé d'annulation conforme à l'une des revendications 1 à 6, caractérisé en ce qu'il comprend les étapes suivantes : réception (E1) d'une requête d'annulation de l'exécution d'une fonction (f), émise par une deuxième station client (UA) du réseau de communication, ladite requête d'annulation comprenant une somme de monnaie électronique (PA) ; et envoi (E27) d'une deuxième réponse (CA) à la deuxième station client (UA) via le réseau de communication, ladite deuxième réponse comprenant une somme de monnaie électronique au plus égale à ladite somme de monnaie électronique (PA) incluse dans la requête d'annulation. 8. Procédé d'annulation conforme à la revendication 7, caractérisé en ce qu'il comprend une étape de génération (E603) d'une monnaie électronique sur ladite station serveur associée à ladite deuxième station client (UA). 9. Procédé d'annulation conforme à l'une des revendications 7 ou 8, caractérisé en ce qu'il comprend une étape de calcul (E6) d'un coût d'annulation (CA) associée à la requête d'annulation reçue de la deuxième station client (UA) du réseau de communication ; et en ce qu'à l'étape d'envoi (E27) de ladite deuxième réponse (A), la somme de monnaie électronique est calculée en déduisant ledit coût d'annulation (CA) de la somme de monnaie électronique (PA) incluse dans ladite requête d'annulation. 10. Procédé d'annulation conforme à l'une des revendications 1 à 9, caractérisé en ce qu'à l'étape d'obtention (E13-E15), une opération inverse de ladite fonction (f) est exécutée. 11. Procédé d'annulation conforme à l'une des revendications 1 à 9, caractérisé en ce qu'il est mis en oeuvre sur une liste de fonctions exécutées ultérieurement à une fonction (f) à annuler. 12. Dispositif d'annulation à distance d'une fonction (f) exécutée par une première station client (Up) sur un objet informatique stocké sur une station serveur (H) d'un réseau de communication, l'exécution de la fonction (f) étant adaptée à manipuler ledit objet d'un état antérieur vers un état manipulé, caractérisé en ce qu'il comprend : des moyens de réception (21) d'une requête d'annulation de l'exécution d'une fonction (f), émise par une station client (U) du réseau de communication ; des moyens d'obtention (22) dudit état antérieur de l'objet manipulé ; et des moyens d'envoi (27) d'une réponse à ladite première station client (U) via le réseau de communication, ladite réponse comprenant une somme de monnaie au plus égale à un coût d'exécution (c) associé à ladite fonction (f). 13. Dispositif d'annulation conforme à la revendication 12, caractérisé en ce qu'il comprend des moyens de génération (25,26) d'une monnaie électronique sur ladite station serveur (H), associée à ladite première station client (U). 14. Dispositif d'annulation conforme à l'une des revendications 12 ou 13, caractérisé en ce que lesdits moyens d'envoi (27) sont adaptés à envoyer une deuxième réponse à une deuxième station client (UA) via le réseau de communication, ladite deuxième réponse comprenant une somme de monnaie électronique au plus égale à une somme de monnaie électronique (PA) incluse dans une requête d'annulation de l'exécution de ladite fonction (f) émise par ladite deuxième station client (UA). 15. Dispositif d'annulation conforme à l'une des revendications 12 à 14, caractérisé en ce qu'il est incorporé dans : un microprocesseur (30) ; une mémoire morte (31) adaptée à mémoriser un programme pour annuler à distance des fonctions ; et une mémoire vive (32) comprenant des registres (23, 26, 28, 29) adaptés à mémoriser des variables modifiées lors de l'exécution dudit programme. 16. Station serveur d'un réseau de communication, caractérisé en ce qu'elle comprend des moyens adaptés à mettre en oeuvre le procédé d'annulation à distance d'une fonction conforme à l'une des revendications 1 à 11. 17. Réseau de communication, caractérisé en ce qu'il comprend un dispositif d'annulation à distance d'une opération conforme à l'une des revendications 12 à 15. 18. Réseau de communication, caractérisé en ce qu'il comprend des moyens adaptés à mettre en oeuvre le procédé d'annulation à distance d'une fonction conforme à l'une des revendications 1 à 11.