FR 2819959 A1 20020726 FR 0100821 A 20010122 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. De plus en plus, 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 ces opérations, chaque opération est facturée à la volée à la station client, c'est-à-dire au fur et à mesure de l'exécution de chaque opération. 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 Photoshop 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 à la station client. A cet effet, le procédé d'annulation visé par l'invention permet d'annuler une opération exécutée à distance sur une station serveur, les opérations étant associées respectivement à un coût d'exécution. Conformément à l'invention, ce procédé d'annulation comprend les étapes suivantes: - réception d'une demande d'annulation de l'exécution d'une opération, émise par une station client; - calcul d'un montant de remboursement inférieur ou égal au coût d'exécution associé à ladite opération; - annulation de l'exécution de ladite opération; et remboursement dudit montant de remboursement au profit de la station client. Le procédé d'annulation conforme à l'invention permet à l'utilisateur de la station client d'annuler une opération effectuée précédemment et d'être remboursé des frais engagés pour cette exécution. Ainsi, I'utilisateur peut être dédommagé des frais engagés pour l'exécution d'une fonction à distance lorsque celle-ci est annulée. Selon une caractéristique préférée de l'invention, à l'étape de calcul, le montant de remboursement est inférieur ou égal à un montant perçu par la station serveur pour l'exécution de ladite opération. Ainsi, le 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 l'opération. Selon une autre caractéristique avantageuse de l'invention, le montant de remboursement est strictement inférieur 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 opération, 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 demande d'annulation reçue, le montant de remboursement étant calculé 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, 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 station client et d'un montant global supérieur au montant de remboursement calculé, et l'étape de remboursement comprend une étape d'envoi à la station client d'une réponse incluant une somme de monnaie électronique égale au montant de remboursement. Ainsi, la station serveur génère sa propre monnaie électronique pour rembourser la station client. En effet, 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. Corrélativement, la présente invention concerne un dispositif d'annulation d'une opération exécutée à distance sur une station serveur, les opérations étant associées respectivement à un coût d'exécution. Ce dispositif d'annulation comprend: - des moyens de réception d'une demande d'annulation de l'exécution d'une opération émise par une station client; - des moyens de calcul d'un montant de remboursement inférieur ou égal au coût d'exécution associé à ladite opération; - des moyens d'annulation de l'exécution de ladite opération; et - des moyens de remboursement dudit montant de remboursement au profit de la station client. 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 à I'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 montant à rembourser utilisée à la figure 3; - la figure 5 est un algorithme détaillant la procédure d'obtention d'une somme d'argent utilisée à la figure 3; - la figure 6 est un algorithme illustrant un procédé d'annulation à distance d'une opération mise en oeuvre sur une station client; - la figure 7 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 6; et - la figure 8 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. 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, I'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 de demande 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. 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 la 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 l'objet informatique o. Elle comprend également des moyens de réception 21 d'une requête d'annulation de la 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 par la station serveur H pour I'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 de calcul 24 comprennent en outre des moyens 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 à la 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 à la figure 3. L'ensemble de ces moyens 10-14 et 20-27 peuvent être incorporés tant au niveau de la 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 , 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 une table de pièces et le montant perçu pour l'exécution de chaque fonction. Un bus de communication 40 permet la communication entre les différents sous-éléments de l'ordinateur ou lié à 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 demande d'annulation de l'exécution d'une opération. Cette demande d'annulation est émise par une station client U. 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. ... 25... 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. .. 5.. 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 o 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'obtention E2 est mise en oeuvre pour obtenir l'identité de la station client U, généralement incorporée dans la demande d'annulation de l'exécution d'une opération. Une étape d'extraction E3 permet également 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 E4 permet de vérifier si cette fonction f a déjà été exécutée sur la station serveur H suite à une requête d'exécution envoyée par la station client U. Dans la négative, la station serveur H envoie en retour à la station client U 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 initialise une somme à rembourser S à une valeur nulle dans une étape d'initialisation E5. Si cette fonction f n'est pas la dernière fonction exécutée sur la station serveur, une étape d'obtention E6 permet d'obtenir la liste des opérations exécutées après l'exécution de cette opération f à annuler. Les étapes suivantes permettent ensuite d'annuler pas à pas chacune des fonctions de cette liste, en parcourant la liste dans un sens chronologique décroissant jusqu'à la fonction f à annuler. Bien entendu, si la fonction f à annuler est la dernière fonction à exécuter, cette liste est restreinte à cette unique fonction f. Une étape de sélection E7 permet de sélectionner la dernière fonction exécutée dans cette liste. On vérifie dans une étape de test E8 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 elle- mê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 E9 puis on applique dans une étape E0IO cette fonction inverse à l'objet o à manipuler. Sinon, si la fonction n'est pas inversible, on obtient dans étape El 1 l'état précédent qui a été mémorisé lors de l'exécution de la fonction f. 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. 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. Une étape de lecture E13 permet de lire dans le moyen de stockage 23 le montant perçu Cp lors de l'exécution de la fonction. En effet, pour chaque opération, 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 Cp par la station serveur 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 Cp lors de l'exécution de cette fonction par la station serveur. Une étape de calcul E14 est ensuite mise en oeuvre de manière à calculer le montant de remboursement M. Ce montant de remboursement M est calculé à partir du montant perçu Cp lu à l'étape E13 et prend en compte éventuellement un coût d'annulation F. En effet, un remboursement complet, correspondant au montant effectivement perçu est plus intéressant pour l'utilisateur, mais risque de surcharger la station serveur. 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 des erreurs éventuelles de manipulation. La fonction d'annulation peut elle-même être payante à l'instar des autres fonctions exécutables à distance. On peut ainsi calculer un coût d'annulation F associé à chaque demande d'annulation reçue et calculer, dans l'étape E14, le montant à rembourser après déduction de ce coût d'annulation. Le montant de remboursement M sera ainsi strictement inférieur au montant effectivement perçu Cp lors de l'exécution de la fonction. 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 montant de remboursement peut être diminué à chaque nouvelle demande d'annulation reçue par la station serveur H et émise par la station client U. 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 montant à rembourser M va être décrite dans un exemple de réalisation en référence à la figure 4. Une étape d'obtention E80 permet d'obtenir l'identité de la station client U ayant envoyé une requête en annulation d'une fonction. Une étape de test E81 permet de vérifier si cette station client U est connue de la station serveur S. Dans la négative, une étape d'ajout E82 permet de mémoriser dans une table d'annulation 28 le nombre de demandes d'annulations n émises par chaque station client U. Ici, on initialise ce nombre d'annulation n à la valeur 0. Une étape de lecture E83 permet, à partir de la table d'annulation 28, de lire le nombre d'annulations n effectuées précédemment pour la station client U. Une étape d'obtention E84 est ensuite mise en oeuvre pour lire dans les moyens de stockage 23 le montant perçu Cp associé à l'exécution de la fonction f à annuler. Une étape de mise à jour E85 permet d'associer au montant à rembourser M la valeur ainsi obtenue du montant perçu Cp. On vérifie ensuite dans une étape de test E86 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 émises par la station client U reste inférieur à cette valeur de seuil T, une étape de mise à jour du nombre d'annulations E89 est mise en oeuvre pour mettre à jour la table d'annulation 28. Le montant à rembourser est alors égal ici au montant perçu Cp associé à la fonction f à annuler. Sinon, si à l'issue de l'étape de test E86, le nombre d'annulations n est supérieur ou égal à la valeur de seuil T, une étape de calcul E87 permet de calculer le coût d'annulation F pour cette fonction à annuler f. En pratique, ce coût d'annulation F représente un pourcentage du montant perçu Cp, et par exemple F égal 5 % de Cp. Une étape de calcul proprement dite E88 est ensuite mise en oeuvre pour calculer le montant à rembourser M. Ici, à titre d'exemple non limitatif, le montant de remboursement M est calculé par la formule suivante: (}I-T-1 A M =(CP-F) e- (D-, o D est une valeur prédéterminée, par exemple égale à 10, de telle sorte que lorsque le nombre d'annulations n est supérieur à cette valeur de seuil C, le montant de remboursement M est inférieur à la moitié du montant perçu Cp après déduction du coût d'annulation F. L'étape de mise à jour E89 permet ensuite de mettre à jour le nombre d'annulations n associé à la station client U dans la table d'annulation 28. On peut ainsi calculer, de manière dégressive, le montant de remboursement M pour chaque demande d'annulation d'une fonction émise par la station client U. En revenant à la figure 3, une étape de mise à jour de la somme à rembourser S est mise en oeuvre de telle sorte que S = S + M, o M correspond au montant à rembourser calculé à l'étape de calcul E14. La somme à rembourser ici correspond ainsi à la somme des montants de remboursement M calculés pour annuler chaque fonction f de la liste obtenue à l'étape d'obtention E6. On vérifie dans une étape de test E16 si la liste des fonctions à annuler est épuisée. Dans la négative, on sélectionne dans une étape de sélection E17 la fonction précédente dans cette liste et on réitère pour celle-ci I'ensemble des étapes E7 à E16 décrites précédemment. * Lorsque la liste des fonctions à annuler est épuisée à l'issue de l'étape de test E16, on génère une réponse R dans une étape de génération E18 à destination de la station client U. Une étape d'obtention E19 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 5. 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. Il est préférable pour la station serveur d'attendre la réception d'une première demande d'annulation par une station client U pour générer une chaîne de pièces électroniques pour cette même station client. En effet, certaines stations clients pourraient ne jamais effectuer de demande d'annulation. Cette procédure d'obtention d'une somme d'argent S va être décrite en détail en référence à la figure 5. Afin d'obtenir une 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 W, , 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 E40 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 E43. Soit le nombre aléatoire W,,n. On applique ensuite, dans une étape de frappe de pièce E44, de manière récursive, une fonction de hachage connue telle que: Wn_1 h (W.) 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 W,1 de retrouver le nombre précédent W,. On obtient ainsi une série de pièces W,, Wn,1,....W2, W1, W0. L'extrémité W0 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 I'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(W0) 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, I'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 W0, W1,...,-Wn,, générées, ces pièces sont mémorisées dans une étape de mémorisation E45 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 E46, 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, I'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 E46 d'une lettre de change, cette dernière est envoyée dans une étape d'envoi E47 à 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: I'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 W0 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 E40 la station client U est déjà connue, on vérifie dans une étape de test E41 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 E42 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 E43 à E47 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. 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 E44 et de stocker celles-ci dans la table de pièces 26 pour une utilisation ultérieure, c'est-à-dire lorsque l'on souhaite annuler à partir de la station client U plusieurs fonctions sur un ou plusieurs objets informatiques o. En revenant à la figure 3, la station serveur H met en oeuvre une étape de lecture E20 permettant de lire dans la table de pièces 26 I'indice de la dernière pièce utilisée. Pour une somme de remboursement S, et en supposant que chaque pièce Wi correspond à une fraction unitaire de cette somme S, on prélève S pièces de la table de pièces 26. Ici, et de manière nullement limitative, 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 E21, une étape de mémorisation E22 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 transmise par la station serveur H lors de l'étape d'envoi E23 contient la somme d'argent S correspondant à l'annulation de la fonction demandée. La fonction peut être ainsi annulée et remboursée au fur et à mesure. 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. Parallèlement à la mise en ceuvre 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 U, tel qu'illustré à la figure 6. Ce procédé de demande d'annulation d'une fonction à distance comporte tout d'abord une étape de génération E60 d'une requête d'annulation d'une fonction à distance. La requête d'annulation à distance d'une fonction sur un objet o est ensuite envoyée dans une étape d'envoi E61 par la station client U à destination de la station serveur H. Ensuite, une étape de réception E62 d'un résultat permet de réceptionner le résultat envoyé 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 à 5. Un test E63 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 8. Dans la négative, une étape d'information E73 permet d'informer l'utilisateur de cette anomalie. Si cette lettre de change existe, une étape de test E64 permet de vérifier que la réponse comporte bien dans un champ spécifique une somme d'argent S correspondant au remboursement de la fonction à annuler. Dans la négative, la procédure de traitement de la réponse est également interrompue. Sinon, une étape d'extraction E65 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 W0 dans une étape de lecture E66. Une étape de validation E67 permet alors de vérifier l'authenticité de la pièce Wi. En pratique, on applique sur cette pièce courante W1 la fonction de hachage h de manière récursive, et ici i fois: h (h(...h(WV))) 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 E67, 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 Wj, 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, une étape d'obtention E68 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 E68 du coût est mise en oeuvre comme décrit ci-après en référence à la figure 7. Le coût d'exécution c peut être inclus directement dans la réponse 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 7. Cette procédure d'obtention du coût d'exécution c de la fonction f comporte tout d'abord un test E31 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 E32 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-obi/class/l magqe.xml#flip#price Cette fonction permet d'appliquer une symétrie à l'image. function price (width, height, angle) { return width*height*angle; } Après réception de l'interface, une étape de mémorisation E33 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 E34 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 E35 si le coût est une expression à calculer. Dans l'affirmative, une étape d'évaluation E36 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 E37 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 E38 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 E68 de la figure 5, le coût c associé à la fonction f que l'on souhaite annuler. Ensuite, une étape de lecture E69 permet de lire l'indice j de la dernière pièce reçue, et une étape de test E70 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 E70 I'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 ia 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 E73. Sinon, une étape de mémorisation E71 permet de mémoriser le nouvel indice i comme indice j de la dernière pièce reçue. Une étape d'ajout E72 permet ensuite de mémoriser la pièce prélevée Wi 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 Wi associées à chaque indice i, mémorisées dans le porte-monnaie électronique, afin d'en récupérer la valeur monétaire. On va décrire à présent, en référence à la figure 8, la procédure de traitement d'une lettre de change reçue par la station client U lors de la première demande d'annulation d'une fonction exécutée sur la station serveur H. Après réception de cette lettre de change, une étape d'obtention E51 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 E52 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 E53, si cette signature est non valide, la procédure est interrompue. Sinon, une étape de lecture E54 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 E55 la signature de la lettre de change C(Wo) reçue par la station client. A l'issue d'une étape de test E56, si cette signature est non valide, la procédure est interrompue. Sinon, une étape de lecture E57 est mise en oeuvre afin de connaître l'identité de la station serveur H. Une étape de mémorisation E58 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 W0. 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 à l'étape de validation E67. 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. REVENDICATIONS 1. Procédé d'annulation à distance d'une fonction (f) exécutée sur un objet informatique stocké sur une station serveur (H) d'un réseau de communication, I'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 (El) 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; - obtention (E8-E12) dudit état antérieur de l'objet manipulé; et - envoi (E23) d'une réponse à la station client (U) 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, avant lesdites étapes d'obtention (E8-E12) et d'envoi (E23), une étape de test (E4) adaptée à vérifier si ladite fonction (f) à annuler a été préalablement exécutée sur la station serveur (H) à la suite de la réception d'une requête d'exécution de ladite fonction (f) émise par la station client (U). 3. Procédé d'annulation conforme à l'une des revendications 1 ou 2, caractérisé en ce qu'il comprend une étape de génération (E19) d'une monnaie électronique sur ladite station serveur (H), associée à ladite station client (U). 4. Procédé d'annulation conforme à l'une des revendications 1 à 3, caractérisé en ce qu'à l'étape d'envoi (E23), la somme de monnaie électronique est inférieure ou égale à un montant perçu (Cp) par la station serveur (H) pour l'exécution de ladite fonction (f). 5. Procédé d'annulation conforme à la revendication 4, caractérisé en ce que la somme de monnaie électronique est strictement inférieure audit montant perçu (Cp). 6. Procédé d'annulation conforme à l'une des revendications 1 à , caractérise en ce qu'il comprend en outre une étape de calcul (E87) d'un coût d'annulation (F) associé à la requête d'annulation reçue; et en ce que la FR 01 00821 Date:21/09/2001 somme de monnaie électronique est calculée après déduction dudit coût d'annulation (F). 7. Procédé d'annulation conforme à la revendication 6, caractérisé en ce que le coût d'annulation (F) est nul si le nombre de requêtes d'annulation (n) émises par la station client (U) est inférieur à une valeur de seuil préfixée (T). 8. Procédé d'annulation conforme à l'une des revendications 1 à 7, caractérisé en ce qu'à l'étape d'obtention (E9, E10), une opération inverse de ladite fonction (f) est exécutée. 9. Procédé d'annulation conforme à l'une des revendications 1 à 8, caractérisé en ce que l'étape d'obtention (E8-E12) est mise en oeuvre sur une liste de fonctions exécutées ultérieurement à ladite fonction (f) à annuler. 10. Dispositif d'annulation à distance d'une fonction (f) exécutée sur un objet informatique stocké sur une station serveur (H) d'un réseau de communication, I'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-25) dudit état antérieur de l'objet manipulé; et - des moyens d'envoi (27) d'une réponse à la 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). 11. Dispositif d'annulation conforme à la revendication 10, caractérisé en ce que les moyens d'obtention (22-25) sont adaptés à vérifier si ladite fonction (f) à annuler a été préalablement exécutée sur la station serveur (H) à la suite de la réception d'une requête d'exécution de ladite fonction (f) émise par la station client (U). 12. Dispositif d'annulation conforme à l'une des revendications 10 ou 11, caractérisé en ce qu'il comprend des moyens de génération (25, 26) FR 01 00821 Date: 21/09/2001 d'une monnaie électronique sur ladite station serveur (H), associée à ladite station client (U). 13. Dispositif d'annulation conforme à l'une des revendications 10 à 12, 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) adaptés à mémoriser des variables modifiées lors de l'exécution dudit programme. 14. 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 à 9. 15. 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 10 à 13. 16. 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 à la l'une des revendications 1 à 9. FR 01 00821 Date: 21/09/2001