FR2819959A1 - Procede d'annulation d'une operation executee a distance sur une station serveur - Google Patents
Procede d'annulation d'une operation executee a distance sur une station serveur Download PDFInfo
- Publication number
- FR2819959A1 FR2819959A1 FR0100821A FR0100821A FR2819959A1 FR 2819959 A1 FR2819959 A1 FR 2819959A1 FR 0100821 A FR0100821 A FR 0100821A FR 0100821 A FR0100821 A FR 0100821A FR 2819959 A1 FR2819959 A1 FR 2819959A1
- Authority
- FR
- France
- Prior art keywords
- function
- cancellation
- station
- execution
- client station
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/04—Billing or invoicing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
- G06Q20/102—Bill distribution or payments
Landscapes
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Finance (AREA)
- Development Economics (AREA)
- Physics & Mathematics (AREA)
- Strategic Management (AREA)
- Economics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Marketing (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
- Computer And Data Communications (AREA)
- Information Transfer Between Computers (AREA)
Abstract
Un procédéd'annulation d'une opération exécutée à distancesur une station serveur, les opérations étant associéesrespectivement à un coût d'exécution (c), comprend lesétapes suivantes :- réception (E1) d'une demande d'annulationde l'exécution d'une opération (f), émise par une stationclient (U);- calcul (E14) d'un montant de remboursement (M) inférieurou égal au coût d'exécution (c) associé àladite opération (f); - annulation (E8-E12) de l'exécutionde ladite opération (f); et - remboursement (E18-E23) duditmontant de remboursement (M). Utilisation notamment pourl'annulation d'opérations réalisées lors de la manipulationà distance d'une image numérique.
Description
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. <interfaces> <interface>...</interface> </interfaces> 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.
<functions> <function>...</function> 25... </functions> 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.
<arguments> <arg>..</arg> 5.. </arguments> 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.
<interface name="lmage" href=http://oceania/web-obi/class/Image.xml /> <attributes> <int name="width" price="0.01 FF" /> <int name="height" price="0.01 FF" /> <string name="encoding" /> </attributes> <functions> <function name="convertToB&W" price="0.5 FF"> </function> <function name="rotate"> <arguments> <int name="angle" /> </arguments> <price> <currency name="FF" /> <value language="JavaScript"> function price (width, height, angle) { return width*height*angle; } </value> </price> </function> <function name="flip"> <price> <currency name="FF" /> <value /> </price> </function> </functions> </interface> 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.
Claims (16)
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
Priority Applications (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0100821A FR2819959A1 (fr) | 2001-01-22 | 2001-01-22 | Procede d'annulation d'une operation executee a distance sur une station serveur |
| FR0200399A FR2819960B1 (fr) | 2001-01-22 | 2002-01-14 | Procede d'annulation d'une operation executee a distance sur une station serveur |
| US10/051,022 US7441015B2 (en) | 2001-01-22 | 2002-01-22 | Method of undoing an operation remotely executed on a server station |
| JP2002012881A JP2002329152A (ja) | 2001-01-22 | 2002-01-22 | サーバステーションで遠隔的に実行された操作の取消方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0100821A FR2819959A1 (fr) | 2001-01-22 | 2001-01-22 | Procede d'annulation d'une operation executee a distance sur une station serveur |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| FR2819959A1 true FR2819959A1 (fr) | 2002-07-26 |
Family
ID=8859090
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR0100821A Pending FR2819959A1 (fr) | 2001-01-22 | 2001-01-22 | Procede d'annulation d'une operation executee a distance sur une station serveur |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US7441015B2 (fr) |
| JP (1) | JP2002329152A (fr) |
| FR (1) | FR2819959A1 (fr) |
Families Citing this family (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2841998B1 (fr) * | 2002-07-04 | 2004-10-22 | Canon Kk | Procede d'execution sur une station d'un reseau de communication d'un programme informatique represente dans un langage de balisage |
| US7818718B2 (en) * | 2003-09-30 | 2010-10-19 | Sap Ag | Undoing user actions in a client program |
| JP4515462B2 (ja) * | 2004-11-12 | 2010-07-28 | 株式会社ジャストシステム | データ処理装置およびデータ処理方法 |
| KR100750999B1 (ko) | 2004-12-20 | 2007-08-22 | 삼성전자주식회사 | 휴대단말기의 통화/메시지 관련 이벤트 처리 장치 및 방법 |
| US7472126B2 (en) * | 2005-09-02 | 2008-12-30 | International Business Machines Corporation | Remotely updating a status of a data record to cancel a workstation deployment |
| US8874477B2 (en) | 2005-10-04 | 2014-10-28 | Steven Mark Hoffberg | Multifactorial optimization system and method |
| US20080005359A1 (en) * | 2006-06-30 | 2008-01-03 | Khosravi Hormuzd M | Method and apparatus for OS independent platform based network access control |
| TW200919203A (en) | 2007-07-11 | 2009-05-01 | Ibm | Method, system and program product for assigning a responder to a requester in a collaborative environment |
| US8850418B2 (en) * | 2010-10-25 | 2014-09-30 | Sap Ag | System and method for business function reversibility |
| US8935670B2 (en) * | 2010-10-25 | 2015-01-13 | Sap Se | System and method for business function reversibility |
| WO2014169331A1 (fr) | 2013-04-19 | 2014-10-23 | National Ict Australia Limited | Vérification d'annulabilité d'un système informatique commandé par api |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5537526A (en) * | 1993-11-12 | 1996-07-16 | Taugent, Inc. | Method and apparatus for processing a display document utilizing a system level document framework |
| US5557518A (en) * | 1994-04-28 | 1996-09-17 | Citibank, N.A. | Trusted agents for open electronic commerce |
Family Cites Families (17)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5453601A (en) * | 1991-11-15 | 1995-09-26 | Citibank, N.A. | Electronic-monetary system |
| US5659747A (en) | 1993-04-22 | 1997-08-19 | Microsoft Corporation | Multiple level undo/redo mechanism |
| JPH07220120A (ja) * | 1994-02-02 | 1995-08-18 | Matsushita Electric Ind Co Ltd | 図形処理装置 |
| JP3614480B2 (ja) * | 1994-11-18 | 2005-01-26 | 株式会社日立製作所 | 電子チケット販売・払戻システム及びその販売・払戻方法 |
| US6771981B1 (en) * | 2000-08-02 | 2004-08-03 | Nokia Mobile Phones Ltd. | Electronic device cover with embedded radio frequency (RF) transponder and methods of using same |
| US6151643A (en) * | 1996-06-07 | 2000-11-21 | Networks Associates, Inc. | Automatic updating of diverse software products on multiple client computer systems by downloading scanning application to client computer and generating software list on client computer |
| JPH1040462A (ja) | 1996-07-25 | 1998-02-13 | Nippon Denki Joho Service Kk | 予約販売システム |
| US6113492A (en) * | 1997-06-30 | 2000-09-05 | Walker Digital, Llc | Gaming device for operating in a reverse payout mode and a method of operating same |
| JP3919041B2 (ja) * | 1997-02-06 | 2007-05-23 | 富士通株式会社 | 決済システム |
| US6085168A (en) | 1997-02-06 | 2000-07-04 | Fujitsu Limited | Electronic commerce settlement system |
| US6192378B1 (en) * | 1998-05-13 | 2001-02-20 | International Business Machines Corporation | Method and apparatus for combining undo and redo contexts in a distributed access environment |
| US6275832B1 (en) * | 1998-09-21 | 2001-08-14 | International Business Machines Corporation | Providing transaction undo without logging |
| US6111575A (en) | 1998-09-24 | 2000-08-29 | International Business Machines Corporation | Graphical undo/redo manager and method |
| JP2000115163A (ja) | 1998-09-29 | 2000-04-21 | Sony Corp | 情報配信方法 |
| US6473740B2 (en) * | 1998-11-29 | 2002-10-29 | Qpass, Inc. | Electronic commerce using a transaction network |
| US6648906B2 (en) * | 2000-04-06 | 2003-11-18 | Innercool Therapies, Inc. | Method and apparatus for regulating patient temperature by irrigating the bladder with a fluid |
| US20040027593A1 (en) * | 2001-10-12 | 2004-02-12 | David Wilkins | Techniques for resolution independent rendering of images |
-
2001
- 2001-01-22 FR FR0100821A patent/FR2819959A1/fr active Pending
-
2002
- 2002-01-22 US US10/051,022 patent/US7441015B2/en not_active Expired - Fee Related
- 2002-01-22 JP JP2002012881A patent/JP2002329152A/ja active Pending
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5537526A (en) * | 1993-11-12 | 1996-07-16 | Taugent, Inc. | Method and apparatus for processing a display document utilizing a system level document framework |
| US5557518A (en) * | 1994-04-28 | 1996-09-17 | Citibank, N.A. | Trusted agents for open electronic commerce |
Non-Patent Citations (1)
| Title |
|---|
| ASIT DAN, FRANCIS PARR: "An Object implementation of Network Centric Business Service Applications (NCBSAs): Conversational Service Transactions, Service Monitor and an Application Style", JEFF SUTHERLAND'S OBJECT TECHNOLOGY WEB SITE, 12 January 1999 (1999-01-12), XP002184918, Retrieved from the Internet <URL:http://jeffsutherland.org/oopsla97/dan.html> [retrieved on 20011204] * |
Also Published As
| Publication number | Publication date |
|---|---|
| US20020138595A1 (en) | 2002-09-26 |
| US7441015B2 (en) | 2008-10-21 |
| JP2002329152A (ja) | 2002-11-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP3862958A1 (fr) | Procédés et systèmes pour le transfert efficace d'entités sur une chaîne de blocs | |
| US8738457B2 (en) | Methods of facilitating merchant transactions using a computerized system including a set of titles | |
| Koblitz et al. | Cryptocash, cryptocurrencies, and cryptocontracts | |
| EP1050025A2 (fr) | Procede de transmission d'information et serveur le mettant en oeuvre | |
| EP3420518A1 (fr) | Procédés et systèmes de transfert efficace d'entités sur un registre distribué poste à poste au moyen d'une chaîne de blocs | |
| US20010034705A1 (en) | Payment-based systems for internet music | |
| US20060036447A1 (en) | Methods of facilitating contact management using a computerized system including a set of titles | |
| EP0865010A1 (fr) | Systéme de paiement électronique sécurisé et procédé de mise en oeuvre | |
| KR20150029761A (ko) | 마이크로 지불을 위한 컴퓨터로 구현된 방법, 컴퓨터 시스템, 장치 및 머신 판독 가능한 매체 | |
| FR2819959A1 (fr) | Procede d'annulation d'une operation executee a distance sur une station serveur | |
| EP1299838A1 (fr) | Systeme et procede de gestion de transactions de micropaiement, terminal de client et equipement de marchand correspondants | |
| EP3195224A1 (fr) | Procédés et dispositifs de gestion de transactions composites | |
| US20080288371A1 (en) | Internet based method and process for facilitating the presentation, sale, purchase, development and management of creative ideas concepts and content | |
| EP0731580B1 (fr) | Procédé de paiement dans une application télématique et dispositif de mise en oeuvre de ce procédé | |
| JP2005352786A (ja) | 電子チケット販売方法、電子チケット販売・譲渡方法、サーバ装置、クライアント装置、プログラム及び記録媒体 | |
| AU2004208331A2 (en) | Micropayment processing method and system | |
| FR2815148A1 (fr) | Procede d'execution d'operations sur une station serveur | |
| FR2819960A1 (fr) | Procede d'annulation d'une operation executee a distance sur une station serveur | |
| US7110965B1 (en) | Method and system for data repository | |
| FR3104760A1 (fr) | Procede, serveur et systeme d’authentification de transaction utilisant deux canaux de communication | |
| FR2815206A1 (fr) | Procede d'execution a distance d'une fonction dans un reseau de communication | |
| WO2002005226A1 (fr) | Systeme et procede de gestion de transaction de micropaiement dispositifs client, marchand et intermediaire financier | |
| EP2172896A1 (fr) | Méthode de gestion d'une valeur dans un dispositif à prépaiement | |
| FR2830644A1 (fr) | Procede d'ordonnancement et d'execution de fonctions dans un reseau de communication | |
| Kazi et al. | NiftyPlace: An NFT Marketplace Using Blockchain |