FR2815148A1 - Procede d'execution d'operations sur une station serveur - Google Patents
Procede d'execution d'operations sur une station serveur Download PDFInfo
- Publication number
- FR2815148A1 FR2815148A1 FR0012941A FR0012941A FR2815148A1 FR 2815148 A1 FR2815148 A1 FR 2815148A1 FR 0012941 A FR0012941 A FR 0012941A FR 0012941 A FR0012941 A FR 0012941A FR 2815148 A1 FR2815148 A1 FR 2815148A1
- Authority
- FR
- France
- Prior art keywords
- execution
- station
- server
- activity
- operations
- 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.)
- Granted
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07F—COIN-FREED OR LIKE APPARATUS
- G07F17/00—Coin-freed apparatus for hiring articles; Coin-freed facilities or services
- G07F17/0014—Coin-freed apparatus for hiring articles; Coin-freed facilities or services for vending, access and use of specific services not covered anywhere else in G07F17/00
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07F—COIN-FREED OR LIKE APPARATUS
- G07F17/00—Coin-freed apparatus for hiring articles; Coin-freed facilities or services
- G07F17/16—Coin-freed apparatus for hiring articles; Coin-freed facilities or services for devices exhibiting advertisements, announcements, pictures or the like
Landscapes
- Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
Un procédé d'exécution d'opérations sur une station serveur, les opérations étant associées à un coût d'exécution (c), comprend les étapes de réception (E1) d'une requête d'exécution d'une opération envoyée par une station client; de mise à jour (E3-E6) d'une valeur représentative d'une activité (V) de la station client sur la station serveur; de comparaison (E7) de cette valeur (V) avec une valeur seuil prédéterminée (T); de rémunération de la station serveur par un montant égal au coût d'exécution (c) de l'opération si et seulement si la valeur représentative d'une activité (V) atteint la valeur seuil (T); et d'exécution (E8) de l'opération prédéterminée.Utilisation pour créer une phase initiale gratuite pour chaque station client utilisant une station serveur exécutant des opérations payantes.
Description
<Desc/Clms Page number 1>
La présente invention concerne un procédé d'exécution d'opérations sur une station serveur d'un réseau de communication.
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, utilisent 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, ou bien encore la fourniture d'un document par la station serveur.
Généralement, sur un réseau de communication, ces services fournis par les stations serveurs sont rémunérés et facturés à la station client.
Cependant, il peut être intéressant pour chaque station serveur de fournir des services à titre gracieux pendant une phase initiale lors de laquelle l'utilisateur peut essayer les services fournis par la station serveur.
Par ailleurs, il peut être intéressant pour certaines stations serveurs de fonctionner sur la base d'un forfait prépayé par chaque station client et audelà duquel les services fournis par la station client sont facturés.
On connaît des systèmes dans lesquels la station serveur fournit à une station client intéressée un mot de passe, valable généralement pendant une durée de temps limitée et permettant à la station client d'utiliser les services de la station serveur gratuitement.
Cependant, ce type de système oblige l'utilisateur à effectuer un certain nombre de démarches afin d'obtenir un mot de passe. Ces démarches limitent le nombre de stations serveurs auquel une station client peut s'adresser sur le réseau de communication.
<Desc/Clms Page number 2>
En outre, ce mot de passe valable pendant une durée de temps limitée peut ne pas permettre à l'utilisateur d'essayer suffisamment les services fournis par la station serveur, si l'utilisateur n'utilise pas ou peu la station serveur.
La présente invention a pour but de résoudre les inconvénients précités et de proposer un procédé d'exécution d'opérations sur une station serveur qui procure une phase initiale d'utilisation adaptée à chaque station client.
A cet effet, la présente invention vise un procédé d'exécution d'opérations 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'exécution comprend les étapes suivantes : - réception d'une requête d'exécution d'une opération prédéterminée envoyée par une station client ; - mise à jour d'une valeur représentative d'une activité de ladite station client sur la station serveur ; - comparaison de ladite valeur représentative d'une activité avec une valeur seuil prédéterminée ; - rémunération de la station serveur par un montant égal au coût d'exécution de ladite opération si et seulement si ladite valeur représentative d'une activité atteint la valeur seuil prédéterminée ; et - exécution de ladite opération prédéterminée.
Ainsi, des opérations peuvent être exécutées par la station serveur, sans être rémunérées, dès réception d'une requête d'exécution envoyée par une station client, sans requérir de cette station client d'opérations supplémentaires que le simple envoi d'une requête d'exécution d'une opération prédéterminée.
En outre, la période pendant laquelle les opérations sont exécutées gratuitement sur la station serveur est définie à partir d'une valeur représentative de l'activité de chaque station client sur la station serveur, cette
<Desc/Clms Page number 3>
valeur étant mise à jour à chaque réception d'une nouvelle requête d'exécution d'une opération sur la station serveur.
La valeur seuil prédéterminée peut correspondre à une phase initiale d'utilisation gratuite des services fournis par la station serveur, à titre publicitaire par exemple, ou bien à un forfait déjà payé par la station client.
Une telle phase initiale gratuite est parfaitement bien adaptée à chaque utilisateur, quelle que soit leur fréquence d'utilisation de la station serveur.
Selon une caractéristique préférée de l'invention, la valeur représentative d'une activité d'une station client est la somme des coûts d'exécution associés respectivement à des opérations exécutées sur la station serveur en réponse à la réception de requêtes d'exécution de ces opérations, envoyées par la station client.
Ainsi, la valeur représentative de l'activité de la station client correspond à la somme dépensée virtuellement sur la station serveur.
Au-delà d'une certaine valeur, correspondant à une somme d'argent prédéterminée, la station serveur est rémunérée par un montant égal au coût d'exécution de chaque opération exécutée.
Cette valeur représentative d'une activité, fondée sur les coûts d'exécution des différentes opérations exécutables par la station serveur, est particulièrement bien adaptée lorsque les opérations fournies par la station serveur peuvent avoir des coûts très différents les unes des autres.
Selon une autre caractéristique de l'invention, la valeur représentative d'une activité d'une station client est égale au nombre d'opérations exécutées sur la station serveur en réponse à la réception de requête d'exécution de ces opérations, envoyées par la station client.
La valeur représentative de l'activité est alors déterminée en fonction du nombre d'invocations de la station serveur par la station client.
Selon une autre caractéristique préférée de l'invention, à l'issue de l'étape de comparaison, si la valeur représentative d'une activité atteint la valeur seuil prédéterminée, le procédé d'exécution d'opérations comprend une
<Desc/Clms Page number 4>
étape d'envoi à la station client d'une requête incluant le coût d'exécution de ladite opération prédéterminée.
Cette requête envoyée par la station serveur permet d'indiquer à la station client que les opérations ultérieures réalisées sur la station serveur sont payantes.
Selon une caractéristique avantageuse de l'invention, l'étape d'exécution n'est mise en oeuvre qu'après réception par la station serveur d'une requête incluant une somme d'argent au moins égale au coût d'exécution associé à ladite opération prédéterminée.
La station serveur peut ainsi être rémunérée au fur et à mesure de l'exécution des opérations demandées par une station client.
Il n'est pas nécessaire pour la station serveur d'ouvrir un compte client et de gérer celui-ci.
Corrélativement, la présente invention concerne un dispositif d'exécution d'opérations sur une station serveur, les opérations étant associées respectivement à un coût d'exécution.
Ce dispositif d'exécution d'opérations comprend : - des moyens de réception d'une requête d'exécution d'une opération prédéterminée envoyée par une station client ; - des moyens de mise à jour d'une valeur représentative d'une activité de ladite station client sur la station serveur ; - des moyens de comparaison de ladite valeur représentative d'une activité avec une valeur seuil prédéterminée ; - des moyens de rémunération de la station serveur adaptés à prélever un montant égal au coût d'exécution de ladite opération si et seulement si ladite valeur représentative d'une activité atteint la valeur seuil prédéterminée ; et - des moyens d'exécution de ladite opération prédéterminée.
Ce dispositif d'exécution d'opérations, incorporé dans une station serveur, présente des caractéristiques et avantages analogues à ceux décrits
<Desc/Clms Page number 5>
précédemment pour le procédé d'exécution d'opérations sur une station serveur.
La présente invention concerne également une station serveur adaptée à mettre en oeuvre) le procédé d'exécution d'opérations conforme à l'invention.
Elle concerne aussi un ordinateur et un réseau de communication adaptés à mettre en oeuvre le procédé d'exécution d'opérations 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'exécution d'opérations selon 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'exécution d'opérations conforme à l'invention ; - la figure 2 est un schéma bloc illustrant un ordinateur adapté à mettre en oeuvre l'invention ; - la figure 3A est un algorithme illustrant le procédé d'exécution d'opérations conforme à un premier mode de réalisation de l'invention ; - la figure 3B est un algorithme illustrant le procédé d'exécution d'opérations conforme à un deuxième mode de réalisation de l'invention ; - la figure 4 est un algorithme illustrant un procédé d'exécution à distance d'une opération mise en oeuvre sur une station client ; - la figure 5 est un algorithme détaillant la procédure d'obtention d'un coût d'exécution d'une fonction utilisée à la figure 4 ;
<Desc/Clms Page number 6>
- la figure 6 est un algorithme détaillant la procédure d'obtention d'une somme d'argent utilisée à la figure 4 ; et - les figures 7 et 8 sont des algorithmes illustrant le procédé d'exécution d'une opération payante sur une station serveur.
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'exécution d'opérations 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 fonction directement sur la station serveur H.
Chaque fonction correspond à une série d'instructions d'un programme informatique.
Bien entendu, la station client U pourrait également demander d'autres services à la station serveur H, par exemple la fourniture d'un document.
Par exemple, et de manière nullement limitative, la station serveur peut héberger des images numériques, et un utilisateur peut, à travers la station client U, effectuer des opérations sur l'une des images de la station serveur H.
Les opérations peuvent être la conversion d'une image en noir et blanc, la rotation de l'image ou une symétrie par rapport à un axe horizontal ou vertical de l'image.
Lors d'une exécution à distance d'une telle opération, l'image sera constamment stockée sur la station serveur H et ne transitera pas sur le réseau de communication. La station client se contentera d'émettre une requête d'exécution à distance de l'opération à destination de la station serveur.
<Desc/Clms Page number 7>
On va considérer dans la suite de la description, un système distribué orienté-objet (en anglais"distributed object system"). Un objet informatique est un élément comprenant des données, également appelées attributs, et des fonctions (en anglais"functions"ou"methods") utilisant éventuellement des paramètres ("input arguments"en anglais). Dans un tel système, les fonctions peuvent être appelées ou invoquées (en anglais "invoked") pour manipuler les données de l'objet.
L'ensemble des fonctions applicables à un objet et des attributs constitue son interface.
En pratique, la station client U comporte des moyens d'exécution d'un programme 10.
Ce programme comporte une série d'instructions dont une ou plusieurs demandent l'exécution d'une fonction distante f sur un objet o stocké sur la station serveur H.
Pour mettre en oeuvre cette exécution à distance d'une opération, la station client U comporte des moyens d'envoi 15 d'une requête d'exécution d'une fonction f.
En outre, afin de pouvoir rémunérer la station serveur H lorsque l'exécution d'une fonction est payante, la station client U comporte des moyens d'obtention 11 d'un coût d'exécution associé à la fonction f.
Ici, ces moyens d'obtention 11 d'un coût permettent d'obtenir l'interface de l'objet o et d'extraire de cette interface le coût de la fonction f.
La station client comporte également une mémoire cache 12 dans laquelle peuvent être mémorisés les coûts d'exécution d'une ou plusieurs fonctions.
La station client comporte en outre des moyens d'obtention 13 d'une somme d'argent S.
Ces moyens d'obtention 13 coopèrent avec des moyens de stockage de pièces 14 de manière à prélever un nombre de pièces suffisant, et au moins égal au coût d'exécution associé à la fonction à exécuter.
<Desc/Clms Page number 8>
L'obtention d'une somme d'argent S et la génération des pièces de monnaie seront expliquées ultérieurement notamment en référence à la figure 6.
Enfin, la station client comprend des moyens d'envoi 16 du paiement associé à une fonction lorsque l'exécution de celle-ci est payante.
Corrélativement, la station serveur H comprend des moyens de réception 21 permettant de réceptionner le paiement éventuel et la requête d'exécution à distance de la fonction f sur l'objet o.
Des moyens de lecture 22 du coût associé à la fonction f permettent d'obtenir le coût d'exécution à partir de l'interface mémorisée dans une mémoire d'interfaces 23.
Dans cette mémoire d'interfaces 23, les différentes interfaces des objets informatiques de la station serveur H sont mémorisées, incluant pour chaque fonction exécutable le coût associé.
Des moyens de comparaison et de prélèvement 24 permettent de valider le paiement reçu, de le comparer au coût de la fonction à exécuter et de prélever une somme au moins égale au coût d'exécution associé à la fonction f.
La validation de l'argent électronique reçue peut être réalisée au moyen d'un certificat d'authenticité (ou lettre de change) mémorisé dans une table 25.
Des moyens d'exécution 26 de la fonction f sur l'objet o sont également incorporés dans la station serveur H.
Conformément à l'invention, la station serveur H comprend également des moyens de calcul 27 d'une valeur représentative de l'activité d'une station client sur la station serveur H.
Des moyens de comparaison 28 permettent en outre de comparer cette valeur représentative d'une activité avec une valeur seuil prédéterminée.
Le fonctionnement de ces moyens de calcul 27 et de comparaison 28, permettant de gérer une phase initiale pendant laquelle la station serveur H fournit gratuitement des services à une station client U, sera expliqué ultérieurement en référence aux figures 3A et 3B.
<Desc/Clms Page number 9>
L'ensemble de ces moyens 10-16 et 21-28 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 30, une mémoire morte 31 (Read Only Memory ou ROM) et une mémoire vive 32 (Random Access Memory ou RAM) comportant différents registres pour la mise en oeuvre du procédé conforme à l'invention.
L'ordinateur comporte notamment une interface de communication 39 pouvant être reliée à un réseau de communication 3 pour recevoir ou transférer des requêtes ou informations.
En outre, l'ordinateur comporte des moyens de stockage de documents, tel qu'un disque dur 36, où 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 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
<Desc/Clms Page number 10>
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 pour stocker notamment la mémoire cache 12 et la table de pièces 14.
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 la valeur représentative d'une activité d'une station client, les différentes interfaces, un porte-monnaie électronique pour stocker le paiement prélevé et une table de lettres de change permettant de mémoriser des lettres de change pour valider la somme d'argent reçue.
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 pour l'intermédiaire d'un autre sous-élément.
On va décrire à présent en référence aux figures 3A et 3B, le procédé d'exécution d'opérations tel qu'il est mis en oeuvre sur la station serveur H du réseau de communication, et selon deux modes de réalisation de l'invention.
Le procédé d'exécution d'une opération comporte tout d'abord une étape de réception E1 d'une requête d'exécution d'une opération envoyée par la station client U.
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 requête d'exécution.
Conformément à l'invention, on met ensuite à jour une valeur représentative d'une activité V de cette station client U sur la station serveur H.
Dans ce mode de réalisation, cette valeur représentative d'une activité V correspond à la somme des coûts d'exécution c associés respectivement à chaque opération exécutée sur la station serveur en réponse à des requêtes envoyées par la station client U.
<Desc/Clms Page number 11>
On cumule ainsi l'ensemble des coûts d'exécution associés aux opérations exécutées à la demande de la station client U sur la station serveur H.
Pour cela, à l'étape de mise à jour de la valeur représentative d'une activité V, on ajoute à cette valeur le coût d'exécution c associé à l'opération courante à exécuter.
En pratique, une étape de lecture E3 permet de connaître la valeur représentative de l'activité V mémorisée sur un compte associé à la station client U.
Dans le système orienté-objet décrit ici, une étape d'obtention E4 est mise en oeuvre pour obtenir l'interface associée à l'objet informatique o sur lequel doit être exécutée la fonction requise f.
Une étape d'obtention E5 permet, à partir de la lecture de cette interface, d'obtenir le coût d'exécution c associé à la fonction f.
La mise à jour proprement dite de la valeur représentative de l'activité V de la station client est réalisée dans une étape d'ajout E6 dans laquelle :
V=V+c
Une étape de comparaison E7 permet de comparer la valeur représentative de l'activité V à une valeur seuil prédéterminée T.
V=V+c
Une étape de comparaison E7 permet de comparer la valeur représentative de l'activité V à une valeur seuil prédéterminée T.
Ici, cette valeur seuil prédéterminée correspond à une somme monétaire préfixée T par la station serveur. Cette somme monétaire T peut correspondre à un forfait payé antérieurement par la station client. Dans ce type de fonctionnement, les opérations réalisées par la station serveur ne doivent être facturées qu'à l'épuisement du forfait.
La somme monétaire T peut également correspondre à une offre d'essai gratuite des services fournis par la station serveur.
Si la valeur représentative de l'activité V n'atteint pas cette valeur seuil prédéterminée T, c'est-à-dire ici si la valeur représentative de l'activité V est strictement inférieure à la valeur seuil prédéterminée T, une étape
<Desc/Clms Page number 12>
d'exécution 8 est mise en oeuvre sur la station serveur pour exécuter la fonction f.
Une étape de mémorisation E9 permet de mémoriser la valeur représentative d'une activité V mise à jour pour une utilisation ultérieure dans le compte associé à la station client U.
De manière classique, après l'exécution de la fonction f, une étape de test E10 permet de vérifier si un résultat a été fourni à l'issue de l'exécution de cette fonction.
Dans l'affirmative, une étape d'envoi EU permet de transmettre ce résultat à la station client U.
Si à l'issue de l'étape de comparaison E7, la valeur représentative d'une activité V atteint la valeur seuil prédéterminée T, c'est-à-dire que cette valeur représentative d'une activité V est ici supérieure ou égale à la valeur seuil prédéterminée T, une étape d'envoi E12 permet d'envoyer à la station client U une requête signalant que l'exécution de la fonction f ne peut être réalisée gratuitement et doit être facturée à la station client.
En pratique, dans l'exemple de réalisation décrit ici, lors de cette étape d'envoi E12, la requête inclut le coût d'exécution c de cette fonction à exécuter.
Le traitement de cette requête par la station client et l'exécution de cette fonction f avec rémunération de la station serveur H sera décrit ultérieurement notamment en référence aux figures 4 et suivantes.
La figure 3B illustre un second mode de réalisation du procédé d'exécution d'opérations conforme à l'invention.
Dans ce mode de réalisation, la valeur représentative de l'activité de la station client U sur la station serveur H est égale au nombre d'opérations exécutées sur cette station serveur H en réponse à différentes requêtes d'exécutions envoyées par la station client U.
Comme précédemment, le procédé d'exécution d'opérations comprend une étape de réception E1 d'une requête d'exécution d'une fonction f.
<Desc/Clms Page number 13>
Une étape d'obtention E2 permet également d'obtenir l'identité du client à partir d'informations incorporées dans la requête d'exécution reçue.
Une étape de lecture E3 permet de connaître la valeur représentative d'une activité V telle que mémorisée dans un compte associé à la station client U.
L'étape de mise à jour E6 consiste alors à augmenter cette valeur représentative d'une activité V d'une unité : V=V+ 1
Une étape de comparaison E7 est alors mise en oeuvre comme précédemment afin de comparer la valeur représentative d'une activité V à une valeur seuil prédéterminée T.
Une étape de comparaison E7 est alors mise en oeuvre comme précédemment afin de comparer la valeur représentative d'une activité V à une valeur seuil prédéterminée T.
Ici, cette valeur seuil prédéterminée T correspond à un nombre d'invocations de fonctions sur la station serveur par une station client U, nombre T au-delà duquel les fonctions ultérieures sont payantes.
A titre d'exemple non limitatif, cette valeur seuil prédéterminée T peut être égale à 10.
Les étapes E8 à E12 de ce procédé d'exécution d'opérations sont identiques ensuite à celles décrites précédemment en référence à la figure 3A.
Grâce à ce procédé d'exécution d'opérations, on peut facilement mettre en oeuvre une phase initiale gratuite sur une station serveur H dont les services sont rémunérés.
La station serveur H peut bien entendu permettre à la station client de consulter à tout moment l'état de son compte et la valeur V.
Parallèlement à la mise en oeuvre de ce procédé d'exécution d'opérations sur la station serveur H, un procédé d'exécution d'une fonction à distance est mis en oeuvre sur la station client U telle qu'illustrée à la figure 4.
Ce procédé d'exécution d'une fonction à distance comporte tout d'abord une étape de génération E20 d'une requête d'exécution d'une fonction à distance.
On rappelle ici que chaque objet informatique o est écrit dans un langage de programmation utilisé par l'application informatique propre à
<Desc/Clms Page number 14>
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.
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++.
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.
<Desc/Clms Page number 15>
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.
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.
Ce champ contient la liste des fonctions ou opérations associées à l'objet informatique supportant cette interface.
< functions > < function > ... < /function > < /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 : 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.
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 > < /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.
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.
<Desc/Clms Page number 16>
En revenant à la figure 4, la requête d'exécution à distance d'une fonction sur un objet o est ensuite envoyée dans une étape d'envoi E21 par la station client U à destination de la station serveur H.
Ensuite, une étape de réception E22 d'un résultat permet de réceptionner le résultat envoyé par la station serveur H à l'issue du procédé d'exécution d'opérations tel que décrit précédemment en référence aux figures 3A et 3B.
Un test E23 permet de vérifier si une requête signalant que l'exécution de la fonction f est payante sur la station serveur H est reçue.
Dans la négative, la procédure d'exécution de la fonction distance f est terminée.
Sinon, pour obtenir l'exécution de la fonction f sur la station serveur H, la station client U doit envoyer une somme d'argent au moins égale au coût d'exécution de cette fonction f.
Une étape E24 permet d'obtenir le coût d'exécution c associé à la fonction f.
Ce coût d'exécution c peut être inclus directement dans la requête envoyée à l'étape d'envoi E12 par la station serveur comme décrit précédemment aux figures 3A et 3B.
Sinon, une procédure particulière peut être mise en oeuvre pour obtenir ce coût d'exécution, comme illustré à la figure 5.
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 12 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.
<Desc/Clms Page number 17>
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.
Alternativement, cette interface peut être déjà transmise par la station serveur H dans la requête envoyée à l'étape d'envoi E12, lorsque la valeur seuil prédéterminée T est atteinte.
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/lmaqe. xml#flip#price
Cette fonction permet d'appliquer une symétrie à l'image.
Cette fonction permet d'appliquer une symétrie à l'image.
< interface name="lmage" href=http ://oceania/web-obi/class/lmage. xml/ > < attributes >
<Desc/Clms Page number 18>
< 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 12 de la station client.
<Desc/Clms Page number 19>
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 exécuter.
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".
le coût de la fonction à la station serveur. Tel est ici le cas pour la fonction symétrie "flip".
Lorsque le coût c associé à la fonction f que l'on souhaite exécuter à distance est connu, on met en oeuvre une procédure d'obtention E25 d'une somme d'argent S au moins supérieure au coût de la fonction à exécuter.
Cette procédure d'obtention d'une somme d'argent S va être décrite en détail en référence à la figure 6.
Afin d'obtenir une somme d'argent S, il est nécessaire de générer une monnaie électronique sur la station client U permettant de créer une suite de pièces qui peuvent ensuite être dépensées sur le réseau de communication.
On utilise à titre d'exemple, pour générer cette monnaie électronique, un système dit PayWord proposé par Rivest et Shamir.
Une description de ce système peut être consultée à l'adresse Internet http ://theory. lcs. mit. edu/-rivest/RivestShamir-mpay. ps.
Ce système consiste de manière générale, à partir d'un nombre aléatoire Wn, de générer une suite de nombres à l'aide d'une fonction de hachage (en anglais Hash function).
Ce système PayWord présente l'avantage d'être fiable et de ne pas requérir l'approbation d'un organisme tiers (banque, notaire, etc. ) pour valider chaque paiement individuel.
<Desc/Clms Page number 20>
En pratique, on vérifie dans une étape de test E40 si la station serveur H est connue de la station client U. Dans la négative, la station client tire un nombre au hasard dans une étape de tirage aléatoire E43. Soit le nombre aléatoire Wn.
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 (Wn)
Cette fonction de hachage h a la particularité de ne pas être réversible de telle sorte qu'il est impossible, à partir d'un nombre Wn - 1 de retrouver le nombre précédent Wn.
Cette fonction de hachage h a la particularité de ne pas être réversible de telle sorte qu'il est impossible, à partir d'un nombre Wn - 1 de retrouver le nombre précédent Wn.
On obtient ainsi une série de pièces Wn, Wni,... W2, Wi, Wo.
L'extrémité Wo de la chaîne de nombres ainsi obtenue est appelée pièce racine (en anglais Root Coin) et permet de vérifier l'authenticité des différentes pièces.
Ce système PayWord permet avantageusement de vérifier l'authenticité des pièces par simple application de la fonction de hachage.
Lors de la génération d'une telle monnaie électronique, il est nécessaire que la station client U obtienne un certificat d'une banque afin de prouver son identité aux vendeurs ultérieurs.
Deux certificats sont utilisés : - un certificat de banque C (Pke), émis par une banque en réponse à une requête de la station client ; et - une lettre de change C (Wo) générée directement par la station client.
Le certificat de banque C (PKe) est une assurance pour chaque vendeur que la banque honorera toute demande de rédemption de pièces authentiques. La lettre de change C (WO) est une assurance pour chaque vendeur que les pièces produites par la station client sont bien authentiques et seront honorées par la banque.
En pratique, la station client envoie à un organisme bancaire le numéro de sa carte de crédit ainsi que sa clé publique Pke.
<Desc/Clms Page number 21>
L'organisme bancaire retourne un certificat de banque C (PKe) qui contient l'identité de l'organisme bancaire, l'identité de la station client et la clé publique de la station client PKe. Ce certificat comporte en outre une signature électronique authentifiant les informations qu'il contient, cette signature étant réalisée par la banque à l'aide de sa clé privée SKb.
Une fois les différentes pièces Wo, Wu,.... Wn générées, ces pièces sont mémorisées dans une étape de mémorisation E45 dans la table des pièces 14 telle qu'illustrée à la figure 1 en association avec un identifiant de la station serveur H 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 14.
En outre, à partir du certificat de banque C (PKe) obtenu de la banque, la station client U génère dans une étape de création de lettre de change E46, un certificat ou lettre de change à destination de la station serveur H.
Chaque lettre de change contient le certificat de banque C (PKe) précédemment reçu, l'identité du serveur H 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 client à 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 serveur H.
Les lettres de change et les pièces sont spécifiques à un serveur donné.
En définitive, la station serveur H reçoit par l'intermédiaire du certificat C (PKe) les informations suivantes : l'identité de l'organisme bancaire,
de la station client, la clé publique de la station client PK,, et la pièce racine Wo.
de la station client, la clé publique de la station client PK,, et la pièce racine Wo.
On rappelle que la clé publique de la station client 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).
<Desc/Clms Page number 22>
Par ailleurs, on rappelle que la pièce Wo est contenue dans la lettre de change de la station client 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 serveur est capable de vérifier qu'il est bien en possession d'une pièce racine Wo émise par un client, 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 le serveur H est déjà connu, on vérifie dans une étape de test E41 si la table de pièces 14 contient suffisamment de pièces utilisables sur cette station serveur H pour exécuter une fonction à distance.
Dans la négative, une étape de suppression E42 permet d'effacer les pièces restantes dans la table de pièces 14 et on met en oeuvre les étapes décrites précédemment E43 à E47 pour générer de nouvelles pièces utilisables sur la station serveur H.
Ainsi, la table de pièces 14 est remplie automatiquement dès lors qu'elle ne contient plus suffisamment d'argent électronique.
Le nombre de pièces n générées par la station client U peut dépendre éventuellement de la fréquence d'utilisation de la station serveur H.
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 14 pour une utilisation ultérieure, c'est-à-dire lorsque l'on souhaite exécuter à distance à partir de la station client U plusieurs fonctions sur un même objet informatique o.
En revenant à la figure 4, la station client U met en oeuvre une étape de lecture E26 permettant de lire dans la table de pièces 14 l'indice de la dernière pièce utilisée.
<Desc/Clms Page number 23>
Pour un coût c de la fonction f, et en supposant que chaque pièce W, correspond à une fraction unitaire du coût c, on prélève c pièces de la table de pièces 14.
Ici, et de manière nullement limitative, la somme d'argent nécessaire à l'exécution de la fonction est inscrite directement dans la requête d'exécution à distance de l'opération prédéterminée.
En pratique, on inscrit dans la requête d'exécution à distance la valeur (W, , i+c).
Après cette étape d'inscription E27, une étape de mémorisation E28 permet de mémoriser le nouvel indice i + c correspondant à la dernière pièce utilisée dans la table de pièces 14 pour le serveur H.
Ainsi, la requête d'exécution à distance transmise par la station client U lors de l'étape d'envoi E29 contient la somme d'argent nécessaire à l'exécution de la fonction demandée sur la station serveur H.
La fonction peut être ainsi exécutée et payée au fur et à mesure.
Grâce au système de micro-paiement décrit précédemment, les pièces n'occupent qu'un espace mémoire réduit dans la requête d'exécution à distance d'une fonction.
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 2 pièces.
On va décrire à présent, en référence aux figures 7 et 8, le procédé d'exécution d'une opération sur la station serveur, cette opération ayant été commandée à distance par la station client U, après la phase initiale gratuite telle que décrite en référence aux figures 3A et 3B.
Avant de réaliser toute fonction payante sur la station serveur H, il est nécessaire pour la station serveur H de mémoriser au préalable la lettre de change reçue par le serveur H à l'issue de l'étape d'envoi E47.
Cette procédure de traitement d'une lettre de change est illustrée à la figure 7.
<Desc/Clms Page number 24>
Une étape d'obtention E51 permet à la station serveur H 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 client 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 le routeur.
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 client U.
Une étape de mémorisation E58 permet ensuite de mémoriser la lettre de change dans la table de lettre de change 25 de la station serveur H.
En pratique, chaque identifiant de station client U est mémorisé en association avec le certificat d'authenticité ou lettre de change C (Wo), et plus précisément avec la valeur de la pièce racine Wo.
On va décrire à présent, en référence à la figure 8, la procédure d'exécution payante d'une fonction sur la station serveur H.
Une étape de réception E61 permet de réceptionner la requête d'exécution à distance envoyée par la station client U.
Une étape de test E62 permet de vérifier si il existe une lettre de change dans la table des lettres de change 25 de la station serveur H correspondant à la station client U. Dans la négative, la requête d'exécution à distance d'une fonction est rejetée et la transmission sur le réseau est interrompue.
<Desc/Clms Page number 25>
Sinon, une étape de test E63 permet de vérifier que la requête comporte bien dans un champ spécifique une somme d'argent S correspondant au paiement de la fonction à exécuter.
Dans la négative, la procédure de traitement de la requête d'exécution à distance est également interrompue.
Sinon, une étape d'extraction E64 est mise en oeuvre afin de lire le montant mémorisé correspondant ici à une pièce W, et son indice i dans la chaîne de pièces générées au niveau de la station client U.
A partir de la lecture de la lettre de change dans la table 25, on peut obtenir la valeur de la pièce racine Wo dans une étape de lecture E65.
Une étape de validation E66 permet alors de vérifier l'authenticité de la pièce W,.
En pratique, on applique sur cette pièce courante W, la fonction de hachage h de manière récursive, et ici i fois : h (h (... h (W.)))
La valeur ainsi obtenue est comparée à la valeur de la pièce racine Wo.
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 E66, appliquer, de manière récursive, i-j fois la fonction de hachage h, c'est-à-dire un nombre de fois juste suffisant pour retrouver une pièce W,, d'indice j inférieur à l'indice courant i, et déjà prélevée par le serveur pour le paiement de l'exécution d'une fonction.
Si la valeur obtenue est différente, la procédure de traitement de la requête d'exécution de fonction est interrompue.
La station serveur H conserve ainsi un débit important, proche de celui d'un même système sans paiement.
En effet, la vérification du paiement par la station serveur H 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.
<Desc/Clms Page number 26>
Ceci est important dans un système qui peut, dans certain cas, avoir à réaliser plusieurs milliers d'opérations à distance par seconde.
Après validation des pièces reçues, une étape de lecture E67 est mise en oeuvre pour obtenir l'interface de l'objet o à manipuler.
A partir de la lecture de cette interface stockée sur la station serveur, on obtient dans une étape d'obtention E68, le coût c associé à l'exécution de cette fonction f appliquée à l'objet o.
Cette étape d'obtention E68 du coût est mise en oeuvre comme décrit précédemment. En pratique, soit le coût d'exécution c est fixe et lu directement dans l'interface, soit le coût d'exécution est le résultat d'une expression à calculer.
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 est suffisant pour payer le coût c de la fonction à exécuter.
En pratique, on vérifie à l'étape de test E70 l'égalité suivante :
c=i-j c = 1 1 où c est le coût associé à la fonction f, i est l'indice de la pièce courante, et j est l'indice de la dernière pièce reçue par la station serveur H.
c=i-j c = 1 1 où c est le coût associé à la fonction f, i est l'indice de la pièce courante, et j est l'indice de la dernière pièce reçue par la station serveur H.
Bien entendu, on pourrait seulement vérifier que le coût c est inférieur ou égal à i-j.
Si le paiement inclus dans la requête d'exécution d'une fonction à distance n'est pas suffisant, la procédure de traitement de cette requête est interrompue.
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 W, associée à son indice i dans un porte-monnaie électronique de la station serveur H.
Ensuite, de manière classique, une étape d'exécution E73 permet d'exécuter la fonction demandée sur l'objet o.
<Desc/Clms Page number 27>
Une étape de test E74 permet de vérifier si il existe un résultat à l'issue de l'exécution de cette fonction.
Dans l'affirmative, une étape d'envoi E75 est adaptée à retourner le résultat à la station client U.
Périodiquement, chaque station serveur H peut retransmettre à l'organisme bancaire les valeurs W, associées à chaque indice i, mémorisées dans le porte-monnaie électronique, afin d'en récupérer la valeur monétaire.
Bien entendu, de nombreuses modifications peuvent être apportées à l'exemple de réalisation décrit si dessus sans sortir du cadre de l'invention.
En particulier, le système PayWord n'est qu'un exemple parmi d'autres de monnaie électronique pouvant être générées sur la station client U et dépensée ensuite sur la station serveur H d'un réseau de communication.
En outre, le langage perfectionné XML utilisé ici peut être remplacé par d'autres systèmes connus tels que CORBA, DCOM ou JAVA/RMI.
Par ailleurs, après la phase initiale gratuite du procédé d'exécution d'opérations sur la station serveur H, les opérations effectuées par la station client peuvent être facturées avec un protocole de macro-paiement traditionnel.
Dans ce dernier cas, la station serveur ouvre un compte client et facture les opérations effectuées par le client au bout d'un temps prédéterminé, par exemple tous les mois.
D'autres part, bien que les exemples de réalisation décrivent une valeur représentative d'une activité V qui est incrémentée d'une unité ou de la valeur du coût d'exécution c d'une fonction à chaque invocation d'une fonction par la station client sur la station serveur H, le procédé d'exécution d'opérations pourrait également être mis en oeuvre inversement en soustrayant d'une valeur initiale préfixée le coût d'exécution de chaque fonction ou une unité pour chaque invocation d'une fonction.
Le solde du compte peut ensuite être comparé à la valeur 0 en deçà de laquelle l'exécution des opérations sur la station serveur devient payante.
Claims (15)
1. Procédé d'exécution d'opérations sur une station serveur, les opérations étant associées respectivement à un coût d'exécution (c), caractérisé en ce qu'il comprend les étapes suivantes : - réception (E1) d'une requête d'exécution d'une opération prédéterminée envoyée par une station client (U) ; - mise à jour (E3-E6) d'une valeur représentative d'une activité (V) de ladite station client (U) sur la station serveur (H) ; - comparaison (E7) de ladite valeur représentative d'une activité (V) avec une valeur seuil prédéterminée (T) ; - rémunération (E72) de la station serveur (H) par un montant égal au coût d'exécution (c) de ladite opération si et seulement si ladite valeur représentative d'une activité (V) atteint la valeur seuil prédéterminée (T) ; et - exécution (E8, E73) de ladite opération prédéterminée.
2. Procédé d'exécution d'opérations conforme à la revendication 1, caractérisé en ce que ladite valeur représentative d'une activité (V) d'une station client (U) est la somme des coûts d'exécution (c) associés respectivement à des opérations exécutées sur la station serveur (H) en réponse à la réception de requêtes d'exécution desdites opérations envoyées par ladite station client (H).
3. Procédé d'exécution d'opérations conforme à la revendication 2, caractérisé en ce qu'à l'étape de mise à jour (E3-E6) d'une valeur représentative d'une activité (V), on ajoute à ladite valeur (V) le coût d'exécution (c) associé à ladite opération à exécuter.
4. Procédé d'exécution d'opérations conforme à la revendication 1, caractérisé en ce que ladite valeur représentative d'une activité (V) d'une station client (U) est égale au nombre d'opérations exécutées sur la station serveur (H) en réponse à la réception de requêtes d'exécution desdites opérations envoyées par ladite station client (U).
<Desc/Clms Page number 29>
5. Procédé d'exécution d'opérations conforme à l'une des revendications 1 à 4, caractérisé en ce qu'à l'issue de l'étape de comparaison (E7), si ladite valeur représentative d'une activité (V) atteint la valeur seuil prédéterminée (T), le procédé d'exécution d'opérations comprend une étape d'envoi (E12) à la station client (U) d'une requête incluant le coût d'exécution (c) de ladite opération prédéterminée.
6. Procédé d'exécution d'opérations conforme à la revendication 5, caractérisé en ce que l'étape d'exécution (E73) n'est mise en oeuvre qu'après réception (E61) par ladite station serveur (H) d'une requête incluant une somme d'argent au moins égale au coût d'exécution (c) associé à ladite opération prédéterminée.
7. Procédé d'exécution d'opérations conforme à l'une des revendications 1 à 6, mis en oeuvre pour exécuter une fonction (f) sur un objet informatique (o) de la station serveur (H), caractérisé en ce qu'il comprend les étapes suivantes : - obtention (E4) d'une interface associée à l'objet informatique (o) ; - obtention (E5) du coût d'exécution (c) associé à ladite fonction (f) à partir de l'interface dudit objet informatique (o).
8. Dispositif d'exécution d'opérations sur une station serveur, lesdites opérations étant associées respectivement à un coût d'exécution (c), caractérisé en ce qu'il comprend : - des moyens de réception (21) d'une requête d'exécution d'une opération prédéterminée envoyée par une station client (U) ; - des moyens de mise à jour (27) d'une valeur représentative d'une activité (V) de ladite station client (U) sur la station serveur (H) ; - des moyens de comparaison (28) de ladite valeur représentative d'une activité (V) avec une valeur seuil prédéterminée (T) ; - des moyens de rémunération (24) de la station serveur (H) adaptés à prélever un montant égal au coût d'exécution (c) de ladite opération si et seulement si ladite valeur représentative d'une activité (V) atteint la valeur seuil prédéterminée (T) ; et
<Desc/Clms Page number 30>
- des moyens d'exécution (26) de ladite opération prédéterminée.
9. Dispositif d'exécution d'opérations conforme à la revendication 8, caractérisé en ce qu'il comprend des moyens d'ajout (27) à la valeur représentative d'une activité (V) du coût d'exécution (c) associé à ladite opération prédéterminée à exécuter.
10. Dispositif d'exécution d'opérations conforme à l'une des revendications 8 ou 9, caractérisé en ce qu'il comprend des moyens d'envoi (23) à la station client (U) d'une requête incluant le coût d'exécution (c) de ladite opération prédéterminée.
11. Dispositif d'exécution d'opérations conforme à l'une des revendications 8 à 10, adapté à exécuter une fonction (f) sur un objet informatique (o) de la station serveur (H), caractérisé en ce qu'il comprend : - des moyens d'obtention (22) d'une interface associée à l'objet informatique (o) ; et - des moyens d'obtention (22) du coût d'exécution (c) associé à ladite fonction à partir de l'interface dudit objet informatique (o).
12. Dispositif d'exécution d'opérations conforme à l'une des revendications 8 à 11, caractérisé en ce qu'il est incorporé dans : - un microprocesseur (30) ; - une mémoire morte (31) adaptée à mémoriser un programme pour exécuter des opérations ; et - une mémoire vive (32) comprenant des registres adaptés à mémoriser des variables modifiées lors de l'exécution dudit programme.
13. Station serveur d'un réseau de communication, caractérisée en ce qu'elle comprend des moyens adaptés à mettre en oeuvre le procédé d'exécution d'opérations conforme à l'une des revendications 1 à 7.
14. Réseau de communication, caractérisé en ce qu'il comprend un dispositif d'exécution d'opérations conforme à l'une des revendications 8 à 12.
15. Réseau de communication, caractérisé en ce qu'il comprend des moyens adaptés à mettre en oeuvre le procédé d'exécution d'opérations conforme à l'une des revendications 1 à 7.
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0012941A FR2815148B1 (fr) | 2000-10-10 | 2000-10-10 | Procede d'execution d'operations sur une station serveur |
| US09/971,960 US7240024B2 (en) | 2000-10-10 | 2001-10-09 | Method for remote execution of a function in a communication network |
| JP2001312913A JP3703419B2 (ja) | 2000-10-10 | 2001-10-10 | クライアントステーションからサーバステーションの機能をリモート実行するための方法、クライアントステーション、及びコンピュータプログラム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0012941A FR2815148B1 (fr) | 2000-10-10 | 2000-10-10 | Procede d'execution d'operations sur une station serveur |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR2815148A1 true FR2815148A1 (fr) | 2002-04-12 |
| FR2815148B1 FR2815148B1 (fr) | 2003-09-05 |
Family
ID=8855176
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR0012941A Expired - Fee Related FR2815148B1 (fr) | 2000-10-10 | 2000-10-10 | Procede d'execution d'operations sur une station serveur |
Country Status (1)
| Country | Link |
|---|---|
| FR (1) | FR2815148B1 (fr) |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO1996015505A2 (fr) * | 1994-11-08 | 1996-05-23 | Vermeer Technologies, Inc. | Outil de developpement de services en ligne a fonctions d'etablissement de taxation |
| US5838906A (en) * | 1994-10-17 | 1998-11-17 | The Regents Of The University Of California | Distributed hypermedia method for automatically invoking external application providing interaction and display of embedded objects within a hypermedia document |
-
2000
- 2000-10-10 FR FR0012941A patent/FR2815148B1/fr not_active Expired - Fee Related
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5838906A (en) * | 1994-10-17 | 1998-11-17 | The Regents Of The University Of California | Distributed hypermedia method for automatically invoking external application providing interaction and display of embedded objects within a hypermedia document |
| WO1996015505A2 (fr) * | 1994-11-08 | 1996-05-23 | Vermeer Technologies, Inc. | Outil de developpement de services en ligne a fonctions d'etablissement de taxation |
Also Published As
| Publication number | Publication date |
|---|---|
| FR2815148B1 (fr) | 2003-09-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP0814441B1 (fr) | Procédé de prise en compte d'une demande d'utilisation d'une carte prépayée virtuelle permettant la réutilisation de son numéro de série | |
| EP1412926B8 (fr) | Procede de gestion d'achat de contenus numeriques diffuses et moyens de telechargement de tels contenus | |
| EP1107203A2 (fr) | Procédé de transmission d'information et serveur le mettant en oeuvre | |
| WO1997033404A1 (fr) | Procede et systeme de facturation pour reseaux de transmission de donnees | |
| EP1459479A2 (fr) | Systeme cryptographique de signature de groupe | |
| FR2760876A1 (fr) | Systeme de paiement electronique securise et procede de mise en oeuvre | |
| EP1299838A1 (fr) | Systeme et procede de gestion de transactions de micropaiement, terminal de client et equipement de marchand correspondants | |
| WO2006009716A2 (fr) | Procédés et appareils pour la validation de transactions dans des réseaux | |
| FR2819959A1 (fr) | Procede d'annulation d'une operation executee a distance sur une station serveur | |
| EP1164529A1 (fr) | Système et procédé de couponnage électronique | |
| EP0731580B1 (fr) | Procédé de paiement dans une application télématique et dispositif de mise en oeuvre de ce procédé | |
| CA2999731A1 (fr) | Procede de traitement de donnees par un terminal de paiement, terminal de paiement et programme correspondant | |
| FR2815148A1 (fr) | Procede d'execution d'operations sur une station serveur | |
| FR2750273A1 (fr) | Procede de rechargement de cartes prepayees virtuelles | |
| FR2815206A1 (fr) | Procede d'execution a distance d'une fonction dans un reseau de communication | |
| FR2811452A1 (fr) | Systeme et procede de gestion de transaction de micropaiement, dispositifs client, marchand et intermediaire financier | |
| EP1779340B1 (fr) | Systeme de paiement par suite de jetons | |
| WO2022269179A1 (fr) | Procede et dispositif de paiement par chaines de blocs | |
| FR2819960A1 (fr) | Procede d'annulation d'une operation executee a distance sur une station serveur | |
| FR2892875A1 (fr) | Procede de securisation des paiements par decoupage des montants | |
| WO2018229089A1 (fr) | Procédé de gestion d'identifiants de fidélité, procédé de traitement de données de fidélité, serveur, dispositif de transaction et programmes correspondants | |
| FR2830644A1 (fr) | Procede d'ordonnancement et d'execution de fonctions dans un reseau de communication | |
| FR2750275A1 (fr) | Procede de gestion dans un systeme telematique distribue et systeme de mise en oeuvre de ce procede | |
| FR2828043A1 (fr) | Procede et dispositif de configuration et d'utilisation d'une unite fonctionnelle dont l'utilisation est soumise a une condition de paiement dans un reseau de communication | |
| EP2515269A1 (fr) | Procédé améliore d'accès a un contenu multimédia |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| ST | Notification of lapse |
Effective date: 20140630 |