FR 2824403 A1 20021108 FR 0105936 A 20010503 de tout ou partie des variables. PROCEDE ET DISPOSITIF D'EXECUTION A DISTANCE D'UNE FONCTION DANS UN RESEAU DE COMMUNICATION La présente invention se rapporte à un procédé et à un dispositif d'exécution à distance d'une fonction dans un réseau de communication. Plus précisément, elle se rapporte à un procédé et à un dispositif d'exécution à distance d'une fonction sur une station serveur, mis en _uvre sur une station client. Corrélativement, elle se rapporte également à un procédé et à un dispositif d'exécution d'une fonction sur une station serveur, commandée à distance à partir d'une station client. Aujourd'hui, de plus en plus d'ordinateurs travaillent en réseau et utilisent les services fournis par d'autres ordinateurs appelés stations serveurs. Il n'est pas rare que, sur un réseau de communication, ces services fournis par ies stations serveurs soient rémunérés. Par ailleurs, il est courant sur un réseau de communication qu'une station client, connectée via le réseau à une ou plusieurs stations serveurs, commande l'exécution à distance d'une fonction sur l'une des stations serveurs. Chaque fonction correspond à une série d'instructions d'un prog ra m me info rm atiq ue mémorisé su r la station serve u r. La demande de brevet français de numéro de dépôt 00 12942 décrit un procédé d'exécution à distance d'une fonction dans un réseau de communication dans le cas o l'exécution d'une fonction est une opération payante. Pour cela, un système de paiement électronique appelé "PayWord", proposé par Rivest et Shamir, est utilisé. On indique à toutes fins utiles qu'une description de ce système peut être consultée à l'adresse Internet suivante: http://theory. Ics. mit.edu/rivesVRivestShamir-mpay. ps. Ainsi, quand une station client envoie une requête d'exécution de fonction à une station serveur, elle joint à cette requête une somme d'argent correspondant au prix de l'exécution de la fonction. Un inconvénient de ce procédé est qu'il ne garantit pas à l'acheteur d'obtenir le résultat de la fonction dont il a payé l'exécution. En particulier, en cas de problème technique tel qu'une coupure du réseau de communication, la réponse de la station serveur peut être perdue alors que ia station serveur a encaissé la somme d'argent transmise par la station client. D'autre part, la spécification RFC 1813 (NFS Version 3 Protocol Specification) écrite par Sun Microsystems, Inc. décrit un système de fichier distribué dans lequel un client peut réémettre une requête pour laquelle il n'a pas reçu de confirmation de traitement. Par ailleurs, un serveur conserve des traces des requêtes qu'il a traitées et qui ne doivent pas être répétées. Cependant, ce document ne concerne pas des appels de fonctions distantes. En outre, ce document ne met pas en _uvre de moyens de paiement. La présente invention a pour but de remédier aux inconvénients précités, en prenant en compte les problèmes de communication entre la station client et la station serveur susceptibles de survenir lors de l'exécution payante d'une fonction à distance. Dans ce but, selon un premier aspect, la présente invention propose un procédé d'exécution à distance d'une fonction d'une station serveur à partir d'une station client comprenant une étape d'envoi d'une requête d'exécution à distance d'une fonction prédéterminée, cette requête étant éventuellement accompagnée d'un paiement supérieur ou égal au coût de l'exécution de la fonction, remarquable en ce que si, lors de la réalisation d'un critère prédéterminé, la station client n'a pas reçu correctement la réponse à la requête, la station client réitère au moins une fois la requête auprès de la station serveur. Ainsi, lorsque la station client ne reçoit pas de réponse à la requête qu'elle a réalisée, elle réitère cette requête, soit sans renvoyer le paiement correspondant, soit en joignant à la réitération de la requête la même somme d'argent électronique que lors du premier envoi. En effet, une particularité de la monnaie électronique est qu'une somme d'argent peut être dupliquée à l'identique par un acheteur sans qu'il soit possible au vendeur de l'encaisser plusieurs fois. Selon une caractéristique particulière, le critère prédéterminé précité consiste en l'expiration d'une durée prédéterminée. L'utilisation d'un tel délai maximal d'attente permet de détecter la survenue d'éventuels problèmes de communication entre station client et station serveur. En variante, le critère prédéterminé peut consister en la rupture de la communication entre la station client et la station serveur. Ainsi, si la station client détecte que la connexion avec la station serveur est interrompue, elle peut commander la réitération de la requête. Dans un mode particulier de réalisation, lorsque la station client réitère la requête, elle renvoie uniquement la requête d'exécution de la fonction à la station serveur et ne renvoie pas le paiement. Cela simplifie la procébure et permet de limiter le risque d'erreur de paiement. En variante, lorsque la station client réitère la requête, elle renvoie à la fois la requête d'exécution de la fonction et le paiement à la station serveur. Ainsi, il suffit pour la station client d'envoyer exactement la même requête que précédemment, constituée de la requête d'exécution de la fonction et du paiement. Par ailleurs, comme on va le voir ci-après, le paiement peut servir à identifier la requête. Selon une caractéristique particulière, des identifiants sont associés de façon bijective aux requêtes, ce qui permet d'identifier chacune de ces dernières de façon unique et de différencier, par exemple, la réitération d'une req uête antérieure et l'envoi successif de deux req uêtes identiq ues. Les identifiants peuvent par exemple être les paiements associés aux requêtes. Dans un mode particulier de réalisation, la station client est adaptée à réitérer toute requête déjà envoyée à la station serveur. Cela permet à la station client d'émettre aisément n'importe quelle requête, ce qui augmente ses possibilités de choix. Dans un autre mode particulier de réalisation, la station client est adaptée à réitérer uniquement la dernière requête envoyée à la station serveur. Cela permet de réduire l'espace mémoire prévu dans ia station client. Selon une caractéristique particulière, si la requête n'a pu être traitée correctement et si la requête était accompagnée d'un paiement, la station client reçoit le remboursement du paiement en provenance de la station serveur (S). Cela permet de garantir à l'utilisateur qu'il ne sera pas débité s'il n'a pu obtenir la réponse à sa requête. Dans le même but que celui indiqué plus haut, selon un second aspect, la présente invention propose un procédé d'exécution d'une fonction sur une station serveur, commandée à distance à partir d'une station client, comprenant une étape de réception d'une requête d'exécution à distance d'une fonction prédéterminée, cette requête étant éventuellement accompagnée d'un paiement supérieur ou égal au coût d'exécution de ladite fonction, remarquable en ce qu'il comporte des étapes suivant lesquelles: - la station serveur détermine si la requête reçue est une nouvelle requête ou la réitération d'une requête précédente; et - si la requête reçue est la réitération d'une requête précédente: Ia station serveur détermine si un paiement valable associé à la requête a déjà été reçu; et À si c'est le cas, la station serveur traite la requête. Cela permet d'éviter d'avoir à accompagner d'un nouveau paiement la réitération d'une requête. Si la requête reçue est une nouvelle requête, la station serveur traite la requête. Selon une caractéristique particulière, pour déterminer si la requête reçue est une nouvelle requête ou la réitération d'une requête précédente, la station serveur compare la requête reçue avec au moins une requête reçue précédemment. Pour comparer la requête reçue avec au moins une requête reçue précédemment, la station serveur peut par exemple comparer des identifiants associés de façon bijective aux requêtes. Cela constitue un moyen simple et rapide pour identifier chaque requête de façon unique. Comme mentionné p l us ha ut, les identifiants peuvent par exemp le être les paiements associés aux requêtes. Selon une caractéristique particulière, si la requête reçue est une nouvelle requête et si le traitement de la requête ne se déroule pas correctement, la station serveur mémorise une erreur de traitement et la signale en retour dans un message de réponse à la station client. Ainsi, le client est averti de la survenue d'un problème et peut alors réitérer sa requête. Selon une caractéristique particulière, en cas d'erreur de traitement, la station serveur joint un remboursement au message de réponse à la station client. Cela permet à l'utilisateur de ne pas voir son paiement encaissé s'il n'obtient pas la réponse à sa requête. Selon une caractéristique particulière, si la requête reçue est la réitération d'une requête précédente et si la requête est accompagnée d'un paiement, plusieurs cas peuvent se présenter: - si la station serveur n'a pas mémorisé de paiement valable associé à la requête précédente, et si le paiement accompagnant la requête reçue est valable, la station serveur traite la requête reçue; - si la station serveur n'a pas mémorisé de paiement valable associé à la requête précédente, et si le paiement accompagnant la requête reçue n'est pas valable, la station serveur mémorise une erreur de paiement et la signale en retour à la station client; - si la station serveur a mémorisé un paiement valable associé à la requête précédente, et si le paiement reçu est identique au paiement associé à la requête précédente, la station serveur traite la requête reçue; et - si la station serveur a mémorisé un paiement valable associé à la requête précédente, et si le paiement reçu est différent du paiement associé à la requête précédente, la station serveur mémorise une erreur de paiement et la signale en retour à la station client. Cela permet d'éviter au client de payer deux fois pour une même requête. Se lo n u ne caractéristiq ue particu lière, si la req uête est accom pag née d'un paiement et si la station serveur ne peut transmettre à la station client la réponse à la requête, la station serveur n'encaisse pas ie paiement. Cela garantit à l'utilisateur de ne payer que pour les réponses obtenues correctement. Selon une caractéristique particulière, si la requête reçue est la réitération d'une requête précédente, pour traiter la requête: - si le résultat de la requête est déjà mémorisé dans la station serveur, la station serveur charge le résultat et le retourne à la station client; - sinon, la station serveur exécute la requête. Cela permet d'éviter au serveur d'exécuter à nouveau une requête qu'il a déjà traitée. Dans un mode particulier de réalisation, la station serveur est adaptée à accepter la réitération de toute requête déjà reçue en provenance de la station client. Dans un autre mode particulier de réalisation, la station serveur est adaptée à accepter uniquement la réitération de la dernière requête reçue en provenance de la station client, ce qui permet de réduire l'espace mémoire prévu dans la station serveur. Selon une caractéristique particulière, après réception de la requête d'exécution à distance d'une fonction prédéterminée, la station serveur vérifie q ue la fonctio n n 'est pas i n clu se da ns une l iste prédéterni i née de fonctions à réitération prohibée. Ainsi, on peut empêcher un fraudeur de réitérer une même requête plusieurs fois en ne payant que pour une seule requête, par exemple afin d'obtenir gratuitement les valeurs successives prises au cours du temps par une variable qui évolue, telle que le cours boursier d'une action, par exemple. Toujours dans le même but, la présente invention propose en outre, selon son premier aspect, un dispositif d'exécution à distance d'une fonction d'une station serveur à partir d'une station client comprenant un module d'envoi d'une requête d'exécution à distance d'une fonction prédéterminée, cette requête étant éventuellement accompagnée d'un paiement supérieur ou égal au coût de l'exécution de la fonction, remarquable en ce qu'il comporte en outre un module pour réitérer au moins une fois la requête auprès de la station serveur si, lors de la réalisation d'un critère prédéterminé, la station client n'a pas reçu correctement la réponse à la requête. Les caractéristiques particulières et avantages de ce dispositif étant similaires à ceux du procédé conforme au premier aspect de l'invention, ils ne sont pas rappelés ici. Ce dispositif peut être incorporé dans: - un microprocesseur; - une mémoire morte adaptée à mémoriser un programme pour exécuter à distance une fonction; et - une mémoire vive comprenant des registres adaptés à mémoriser des variables modifiées lors de l'exécution de ce programme. Toujours dans le même but, la présente invention propose en outre, selon son second aspect, un dispositif d'exécution d'une fonction sur une station serveur, commandée à distance à partir d'une station client, comprenant un module de réception d'une requête d'exécution à distance d'une fonction prédéterminée, cette requête étant éventuellement accompagnée d'un paiement supérieur ou égal au coût d'exécution de la fonction, remarquable en ce qu'il comporte: - un module pour déterminer si la requête reçue est une nouvelle requête ou la réitération d'une requête précédente; - un module de traitement de requêtes; - un module pour déterminer si un paiement valable associé à une requête a déjà été reçu, en cas de réitération d'une requête précédente. Les caractéristiques particulières et avantages de ce dispositif étant similaires à ceux du procédé conforme au second aspect de l'invention, ils ne sont pas rappelés ici. Ce dispositif peut être incorporé dans: - un microprocesseur; - une mémoire morte adaptée à mémoriser un programme pour exécuter une fonction commandée à distance; et - une mémoire vive comprenant des registres adaptés à mémoriser des variables modifiées lors de itexécution de ce programme. D'autres aspects et avantages de l'invention appara^tront à la lecture de la description détaillée qui suit d'un mode particulier de réalisation, donné à titre d'exemple non limitatif. La description se réfère aux dessins qui l'accompagnent, dans lesquels: - la figure 1 est un schéma bloc illustrant un ordinateur adapté à mettre en _uvre l'invention; - la figure 2 est un schéma bloc illustrant le contexte de l'invention; - la figure 3 est un schéma bloc illustrant un dispositif mettant en _uvre l'invention; - la figure 4a est un tableau permettant à une station client de mémoriser les requêtes qu'elle envoie; - la figure 4b est un tableau permettant à une station serveur de mémoriser les requêtes qu'elle reçoit; - la figure 5 est un organig ramme ill ustrant l'envoi d'une req uête par une station client; et - la figure 6 est un organigramme illustrant le traitement d'une requête par une station serveur. L'ensemble des moyens de l'invention peut être incorporé tant au niveau d'une station client qu'au niveau d'une station serveur dans un ordinateur 1 tel que représenté à la figure 1. Cet ordinateur 1 comprend de manière classique un microprocesseur , une mémoire morte 102 (en anglais "Read Only Memor/' ou ROM) pouvant mémoriser le procédé conforme à l'invention, et une mémoire vive 103 (en anglais "Random Access Memort' ou RAM) comportant différents registres pour la mise en _uvre de ce procédé. L'ordinateur 1 comporte notamment une carte réseau 107 pouvant être reliée à un réseau de communication 4 pour recevoir ou transférer des requêtes ou informations. En outre, I'ordinateur 1 comporte des moyens de stockage de documents, tels qu'un disque dur 104. L'ordinateur 1 est adapté à coopérer au moyen d'un lecteur de disque 105 avec des moyens de stockage amovibles 2 tels que des disques amovibles (disquettes ou disques compacts) et est adapté à coopérer au moyen d'un lecteur de carte 106 avec des cartes informatiques 3 (en anglais "PC cards"). Ces moyens de stockage fixes ou amovibles peuvent comporter le code du procédé conforme à l'invention qui, une fois lu par le microprocesseur , sera stocké par le disque dur 104. A titre de variante, le programme permettant au dispositif de mettre en _uvre itinvention pourra être stocké dans la mémoire morte 102. 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 4. De manière classique, I'ordinateur 1 est également relié par l'intermédiaire d'une carte graphique 108 à un écran 5 et à un support vidéo 6 permettant par exemple de servir d'interface avec un opérateur à l'aide d'un clavier 7 ou d'une souris 8 ou tout autre moyen. Le clavier 7 et la souris 8 communiquent avec l'ordinateur 1 via une carte d'entrées/sorties 109, laquelle peut également mettre l'ordinateur en relation avec une imprimante 10, un appareil photo 9 et tout autre appareil jugé utile. L'ordinateur 1 comporte également une carte audio 110 lui permettant de communiquer avec un support audio 11. L'unité centrale 100 va exécuter des instructions relatives à la mise en _uvre 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 102, sont transférés dans la mémoire vive 103 qui contiendra alors le code exécutable de l'invention ainsi que les variables nécessaires à la mise en _uvre de l'invention. Un bus de communication 101 permet la communication entre les différents sous-éléments compris dans l'ordinateur ou reliés à lui. La représentation du bus n'est pas limitative et notamment le microprocesseur est susceptible de communiquer des instructions à tout sous élément directement ou par l'intermédiaire d'un autre sous-élément. La figure 2 présente le contexte de l'invention. Deux stations ou ordinateurs clients C' et c2 envoient respectivement des requêtes 200 et 201 d'exécution d'une fonction à une station ou ordinateur serveur S. Ce serveur traite ces requêtes contre rémunération et retourne le résultat du traitement à la station client qui l'a demandé. La requête 200, envoyée par la station client C4, est composée de deux parties: le corps de la requête R4n, contenant un identifiant de la fonction appelée et des paramètres d'appel, et le paiement Pin pour l'exécution de cette fonction. La station client C' conserve dans un tableau Tc' les requêtes qu'elle envoie. La station serveur S conserve dans un tableau Ts les requêtes qu'elle reçoit ainsi que ies réponses A4n qu'elle fait à ces requêtes. La fiigure 3 illustre un dispositif mettant en _uvre l'invention. Ce dispositif est composé d'une station client Ci (à titre d'exemple nullement limitatif, C') qui envoie des requêtes d'exécution de fonctions à une station serveur S. La station client C' comporte un module 300 de création de requêtes, adapté à créer une requête Rn contenant un appel de fonction et à y ajouter une somme d'argent électronique Pn nécessaire à la rémunération de la station serveur S pour l'exécution de la fonction demandée. La somme d'argent électronique Pn peut être supérieure ou égale au coût d'exécution de la fonction. Le module 300 de création de requêtes est relié à une mémoire, illustrée sous la forme d'un tableau Tc', pour y mémoriser la requête Rn et le paiement associé Pn avant envoi vers la station serveur S. Le module 300 de création de requêtes est également relié à un module 301 d'envoi de requêtes, adapté à envoyer la requête Rn et le paiement Pn à la station serveur S. La station client C' comporte en outre un module 302 de réception, relié au module 301 d'envoi de requêtes et adapté à attendre de recevoir en provenance de la station serveur S la réponse An à la requête Rn. La durée de cette attente est déterminée par l'expiration d'un délai maximal prédéterminé. En variante, la station client C, peut, sans qu'un délai maximal d'attente soit défini, détecter une interruption de la communication avec la station serveur S (par exemple lors d'une rupture de connexion réscau). L'utilisation d'un délai maximal d'attente permet également de détecter la survenue d'éventuels problèmes de communication entre la station client C' et la station serveur S. L'expiration de ce délai sans qu'une réponse An ait été correctement reçue par la station client signifie que la transmission de la requête Rn ou de la réponse An ne s'est pas effectuée correctement. La station client Ci comporte également un module 303 de réexpédition de requêtes, relié au module 302 de réception et adapté à réitérer la requête Rn auprès de la station serveur S en cas d'expiration du délai maximal mentionné ci-dessus ou en cas de mauvaise réception de la réponse An. A cet effet, le module 303 de réexpédition de requêtes, qui est relié au tableau Tc', charge la requête Rn et le paiement associé Pn à partir du tableau Tci avant de les envoyer à nouveau à la station serveur S. Dans le mode de réalisation préféré de l'invention, la station client Ci ne peut réitérer que la dernière requête envoyée. Dans ce cas, le module 303 de réexpédition de requêtes charge la requête se trouvant a la dernière ligne du tableau Tc,. En variante, la station client C peut réitérer toute requête déjà envoyée. Pour cela, le module 300 de création de requêtes mémorise la ligne L du tableau Tci o sont insérés la requête Rn et le paiement Pn et le module 303 de réexpédition de requêtes charge la requête se trouvant à la ligne L du tableau Tci. Dans une autre variante de réalisation, en cas de réitération d'une requête auprès de la station serveur S. le module 303 de réexpédition de requêtes renvoie à la station serveur, non pas la requête Rn et le paiement associé Pn, mais uniquement la requête Rn. La station client C' comporte de plus un module 304 de mise à jour de paiement relié au module 303 de réexpédition de requêtes et à un porte monnaie électronique 305. Le porte-monnaie 305 est également relié au module 300 de création de requêtes. Le module 304 de mise à jour de paiement est adapté à décrémenter le montant mémorisé dans le porte-monnaie 305 de la valeur du paiement Pn chaque fois qu'une réponse An est reçue correctement par la station client. Le module 304 de mise à jour de paiement est aussi adapté à modifier le montant mémorisé dans le porte-monnaie 305 pour prendre en compte un remboursement faisant suite à une erreur d'exécution de la requête Rn, ou pour prendre en compte une erreur de paiement signalée par la station serveur S. La station serveur S illustrée sur la figure 3 comporte un module 310 de réception de requêtes, relié au moduie 301 d'envoi de requêtes et au module 303 de réexpédition de requêtes compris dans la station client C'. Le module 310 de réception de requêtes est adapté à recevoir une requête Rn et un paiement Pn associé, provenant d'une station client (ici C', à titre d'exemple nullement limitatif). La station serveur S comporte en outre un module 311 de comparaison, relié au module 310 de réception de requêtes. Le module 311 de comparaison est également relié à une mémoire, illustrée sous la forme d'un tableau Ts, o sont mémorisés les requêtes, paiements et réponses précédents, ainsi que l'identité de la station client à laquelle ces requêtes, paiements et réponses correspondent. Le module 311 de comparaison, à la réception d'une requête Rn et du paiement associé Pn en provenance de la station client C', est adapté à charger, à partir du tableau Ts, la dernière requête R' envoyée par la station client C' ainsi que le paiement associé P' et le résultat A' du traitement de cette requête, et à comparer la requête reçue Rn et la requête précédente R'. Cette comparaison peut être réalisée au moyen d'identifiants associés aux requêtes, chaque identifiant étant associé de façon bijective à une requête. Par exemple, l'identifiant pourra être un numéro de série associé à la requête. En variante, I'identifiant pourra être constitué par le paiement (en monnaie électronique) associé à la requête. En effet, chaque pièce de monnaie électronique a la propriété de posséder un numéro de série qui l'identifie de façon unique. Si la comparaison révèle que les requêtes Rn et R' sont différentes, cela signifie que la requête Rn est une nouvelle requête. Dans ce cas, la requête Rn est traitée par un module 312 de traitement, relié au module 311 de comparaison et au tableau Ts. Le module 312 de traitement mémorise le résultat de ce traitement dans le paramètre An et, si l'exécution de la requête s'est déroulée correctement, mémorise dans le tableau Ts le client (ici C4) ayant envoyé la requête Rn' la requête Rn, le paiement associé Pn et le résultat An de l'exécution. En cas d'erreur d'exécution, le module 312 de traitement mémorise cette erreur dans le paramètre An. Un module 313 d'envoi de réponses, relié au module 312 de traitement ainsi qu'au module 302 de réception compris dans la station client C4, envoie le résultat An à la station client C4. Si la comparaison révèle que les requêtes Rn et R' sont identiques, cela sign ifie que la req uête Rn correspond à la réitération de la requête précédente R'. Dans ce cas, le module 312 de traitement mémorise le précédent résultat de traitement A' de la requête dans le paramètre An. Si le paiement fourni Pn n'est pas valable ou bien s'il est différent du paiement précédent P', le module 312 de traitement mémorise dans An une erreur de paiement décrivant les causes de non-validité du paiement. Dans la variante de réalisation o, lors de la réitération de la requête Rn, seule la requête a été envoyée par la station client, sans le paiement associé Pn, le module 312 de traitement considère néanmoins le paiement comme valable. Dans tous les cas, la station serveur S retourne un résultat An à la station client Ci, qu'il s'agisse de la réponse à la requête Rn Ou d'une information d'erreur. La station serveur S comporte de plus un module 314 de prélèvement de paiement, relié au module 313 d'envoi de réponses, au module 312 de traitement et à un système de paiement 315. Le module 314 de prélèvement de paiement est adapté à créditer un compte, dans le système de paiement 315 de la station serveur, d'un montant égal au paiement Pn. si le traitement de la requête Rn s'est déroulé correctement. Le module 314 de prélèvement de paiement est aussi adapté à ne pas encaisser le paiement Pn fourni par la station client C' si la requête Rn n'a pu être traitée, par exemple si la station serveur S n'a pas pu transmettre la réponse An à la station client C'. Le module 314 de prélèvement de paiement est aussi adapté à encaisser le paiement Pn et à commander le module 312 de traitement de façon que ce dernier joigne un remboursement à la réponse, par exemple en cas d'erreur d'exécution de la requête. Cette caractéristique de l'invention permet de garantir à la station client C' qu'une requête qui n'a pu être exécutée ne lui sera pas facturée. Dans le mode de réalisation préféré de l'invention, la station serveur S accepte uniquement la répétition de la dernière requête envoyée par une station client. En variante, la station serveur S peut accepter toute requête déjà envoyée par une station client. Dans ce cas, à réception d'une requête Rn et du paiement associé Pn en provenance de la station client Ci, ie module 311 de comparaison est adapté à comparer la requête reçue Rn à toutes les requêtes précédemment reçues et mémorisées dans le tableau Ts. Si la requête reçue est identique à l'une des requêtes précédemment reçues R', le module 311 de comparaison compare le paiement Pn associé à la requête Rn au paiement P' associé à cette requête précédemment reçue R'. Comme le montre la figure 4a, le tableau Tc' permet à la station client C' de la figure 2 de mémoriser les requêtes qu'elle envoie. Ces requêtes sont mémorisées dans l'ordre dans lequel elles sont envoyées. Ainsi, la dernière requête envoyée est mémorisoe dans la dernière ligne du tableau. La colonne 401 du tableau mémorise le corps Rk des requêtes, qui décrit l'appel de la fonction à exécuter à distance. La colonne 402 mémorise le paiement Pk utilisé lors de l'envoi de la requête, sous la forme d'une représentation de la somme d'argent électronique envoyée à la station serveur. Comme le montre la figure 4b, le tableau Ts permet à la station serveur S de la figure 2 de mémoriser les requêtes qu'elle reçoit. Ces requêtes sont mémorisées dans l'ordre dans lequel elles sont reçues. Ainsi, la dernière requête reçue est mémorisoe dans la dernière ligne du tableau. Les colonnes 412 et 413 du tableau Ts sont respectivement similaires aux colonnes 401 et 402 du tableau Tc de la figure 4a et mémorisent respectivement les requêtes Rik reçues et les paiements Pik associés, l'indice i se référant à la station client dont est issue la requête. Le serveur pouvant en effet recevoir des requêtes provenant de différents clients, la colonne 411 du tableau Ts mémorise en regard de chaque requête Rik reçue le client Ci dont ceffe requête provient. Enfin, la colonne 414 du tableau Ts mémorise le résultat Aik de la requête lorsque celle-ci a été traitée. L'organigramme de la figure 5 illustre la génération d'une requête Rn par une station client Ci, son envoi vers une station serveur S et la réception de la réponse An. Lors d'une étape 500, la station client Ci crée une requête Rn contenant un appel de fonction. Puis lors d'une étape 501, la station client Ci ajoute à cette requête la somme d'argent électronique Pn nécessaire à la rémunération de la station serveur S pour l'exécution de la fonction demandée. Lors de l'étape suivante 502, la station client Ci mémorise la requête Rn et le paiement Pn dans le tableau Tci, avant de les envoyer à la station serveur S lors de l'étape suivante 503. L'étape 504 correspond à une affente de la réponse An à la requête Rn. Comme décrit plus haut en liaison avec la figure 3, cette affente est limitée par l'expiration d'un délai défini à l'avance. Le test 505 permet de vérifier si ce délai a expiré ou non. Si le délai a expiré sans qu'une réponse An ait été reçue (test 505 positif), la station client réitère la requête. Pour cela, elle charge la requête Rn et le paiement associé Pn à partir du tableau Tci à l'étape 507 avant de les envoyer à nouveau à la station serveur S (retour à l'étape 503). Si une réponse An a été reçue avant expiration du délai (test 505 négati0, la station client vérifie dans un test 506 si la réponse a été reçue correctement. Si ce n'est pas le cas (test 506 négatif), la station client réitère également la requête (étape 507 puis retour à l'étape 503). Si la réponse An a été correctement reçue (test 506 positi9, une étape 508 consiste ensuite à mettre à jour le porte-monnaie électronique de la station client. La réponse An peut être, non pas le résultat de l'exécution d'une fonction, mais une notification d'erreur. Dans ce cas, la mise à jour du porte monnaie électronique peut consister en un remboursement du paiement Pn, étant donné que la requête Rn n'a pu être traitée correctement. Elle peut aussi consister à corriger le contenu du porte-monnaie électronique si la station serveur S a signalé une erreur de paiement. Comme décrit plus haut en liaison avec la figure 3, dans le mode de réalisation préféré de l'invention, la station client Ci ne peut réitérer que la dernière requête envoyée. Dans ce cas, I'étape 507 consiste à charger la requête se trouvant à la dernière ligne du tableau Tci. En variante, la station client Ci peut réitérer toute requête déjà envoyée. Pour cela, à l'étape 502, la station client mémorise la ligne L du tableau Tci o la requête Rn et le paiement Pn ont été insérés. Puis, à l'étape 507, la station client charge la requête se trouvant à la ligne L du tableau Tci. Cette réalisation permet à l'utilisateur de démarrer la succession d'étapes directement en 507 en fournissant la ligne L du tableau Tci correspondant à la requête qu'il désire réitérer. Dans une autre variante de réalisation, il est possible, lors de la réitération d'une requête auprès de la station serveur S. de ne pas envoyer à nouveau le paiement associé Pn. Dans ce cas, à l'étape 507, seule la requête Rn est chargée et à l'étape 503, elle est envoyée à la station serveur S seule, sans le paiement associé Pn. L'organigramme de la figure 6 illustre la réception d'une requête Rn provenant d'une station client Ci par une station serveur S. son traitement et l'envoi d'une réponse An vers la station client Ci. Le traitement d'une requête par la station serveur S commence par la réception d'une requête Rn et de son paiement associé Pn provenant d'une station client Ci, lors d'une étape 600. Dans un mode particulier de réalisation, on peut mémoriser dans la station serveur S une liste prédéterminée de fonctions dites à réitération prohibée, c'est-à-dire dont on désire empêcher la réitération de façon gratuite par un utilisateur mal intentionné. Par exemple, on peut souhaiter empêcher qu'un fraudeur tente d'obtenir, en ne payant qu'une seule fois, la réponse à des requêtes identiques espacées dans le temps, visant par exemple à conna'^tre le cours boursier d'une action. Dans ce cas, il suffit d'inclure la fonction qui retourne le cours d'une action dans la liste des fonctions à réitération probibée. Dans ce mode particulièr de réalisation, lors de la réception d'une requête, la station serveur S vérifiera que la fonction appelée ne fait pas partie de la l iste d es fonctio ns à réitération p rob ibée. Comme le montre la figure 6, I'étape de réception 600 est suivie d'une étape 601, au cours de laquelle la station serveur charge, à partir du tableau Ts, la dernière requête R' réalisée par ce client Ci, ainsi que le paiement associé P' et le résultat A' du traitement de cette requête. Puis un test 602 consiste à comparer la requête reçue Rn et la requête précédente R'. Si ces deux requêtes sont différentes (test 602 négati0, cela signifie que Rn est une nouvelle requête. Dans ce cas, on vérifie la validité du paiement Pn envoyé avec la requête Rn au cours d'une étape 603. Cette étape n'est pas détaillée car elle ne fait pas l'objet de l'invention. Une façon de vérifier la validité du paiement lors de l'exécution d'une fonction à distance est décrite dans la demande de brevet français de numéro de dépôt 00 12942. Si le paiement est incorrect (test 603 négati0, la station serveur mémorise lors d'une étape 606 une erreur de paiement dans le paramètre de réponse An Si le paiement est correct (test 603 positi9, la station serveur S exécute effectivement la requête lors d'une étape 607 et mémorise son résultat dans le paramètre An. Si la requête reçue demande l'exécution d'une fonction à réitération prchibée, la station serveur S n'effectue aucune des étapes 601 et 602 et poursuit son traitement directement à l'étape 603. A la suite de l'étape d'exécution 607, la station serveur S vérifie lors d'un test 608 que l'exécution de la requête Rn s'est déroulée correctement. Si ce n'est pas le cas (test 608 négati9, une erreur d'exécution est mémorisée dans An à l'étape 609. Si l'exécution de la req uête s'est d érou lée co rrecteme nt (test 608 positi9, la station serveur S mémorise au cours d'une étape 610, dans le tableau Ts, le client Ci ayant envoyé la requête Rn, la requête Rn, le paiement * associé Pn et le résultat An de l'exécution. Si le test 602 est positif, c'est-à-dire que la requête reçue est identique à la requête précédente R', cela signifie que Rn correspond à une réitération de la requête précédente. Dans ce cas, au cours d'un test 604, la station serveur S vérifie que le paiement fourni Pn est bien identique au paiement précédent P'. Si c'est le cas (test 604 positif), au cours d'une étape 605, la station serveur S mémorise le précédent résultat de traitement A' de la requête dans An. Dans d'autres variantes, la station serveur S peut exécuter à nouveau la requête Rn, dans une première variante, lorsque le résultat A' de la requête précédente R' n'a pas été mémorisé ou, dans une deuxième variante, que ce résultat précédent A' ait été mémorisé ou non. Si le paiement fourni Pn est différent du paiement précédent P' lors du test 604 (test 604 négati9, la station serveur mémorise lors de l'étape 606 une erreur de paiement dans le paramètre de réponse An. Dans une variante de réalisation de l'invention, la station client Ci, lors de la réitération d'une requête Rn, n'envoie pas à nouveau le paiement Pn associé à cette requête Rn, mais la requête Rn seule. Dans cette variante, à l'étape 604, bien qu'aucun paiement ne soit associé à la requête Rn, le paiement est néanmoins considéré comme valable et l'exécution du procédé se poursuit à l'étape 605. Dans une autre variante, si le paiement précédent P' n'est pas valable ou s'il n'est pas mémorisé, la station serveur S vérifie la validité du paiement Pn associé à la requête Rn. Si ce paiement Pn est valable, la station serveur S le mémorise dans le tableau Ts en regard de la requête précédente R' puis l'exécution du procédé se poursuit à l'étape 605. Si ie paiement Pn n'est pas valable, la station serveur S mémorise une erreur de paiement, c'est-à-dire qu'elle passe à l'étape 606. Dans tous les cas, les étapes 605, 606, 609 et 610 décrites précédemment sont suivies d'une étape 611 au cours de iaquelle la station serveur S retourne à la station client Ci le résultat An, que ce soit le résultat du traitement de la requête ou une information d'erreur. ll est à noter que la station serveur S peut tenter de retourner le résultat An à la station client Ci plusieurs fois si elle rencontre des difficultés à transmettre ce résultat. Puis au cours d'un test 612, la station serveur S vérifie que le traitement de la req uête s'est déro u lé co rrectement. Si c'est le cas (test 612 positifl, le paiement Pn fourni par la station client Ci est crédité au compte du serveur à l'étape 613. Dans ie cas contraire (test 612 négatif), le système de paiement de la station serveur S est mis à jour à l'étape 614. Cette mise à jour peut consister à ne pas encaisser le paiement Pn fourni par la station client Ci, puisque la requête Rn n'a pu être traitée. Cette solution est d'ailleurs mise en ceuvre de préférence si la station serveur S n'a pu transmettre la réponse An à la station client Ci. L'encaissement du paiement Pn après l'envoi de la réponse An permet ainsi à la station serveur S de ne pas débiter la station client Ci si elle n'a pu lui transmettre la réponse An. Cette mise à jour peut aussi consister à encaisser le paiement Pn fourni par la station client Ci et à joindre à la réponse un remboursement. Cette solution est mise en _uvre de préférence dans le cas d'une erreur d'exécution de la requête. Elle permet de fournir à la station client Ci une garantie que la requête Rn' qui n'a pu être exécutée, ne lui sera pas facturée. Comme décrit plus haut en liaison avec la figure 3, dans le mode de réalisation préféré de l'invention, la station serveur S accepte uniquement la réitération de la dernière requête envoyée par une station client. En varia nte, la station serve u r S peut accepter la réité ration de toute requête déjà réalisée par une station client Ci. Pour cela, dans la succession d'étapes qui vient d'être décrite, seules les étapes 601, 602 et 603 sont modifiées. Aux étapes 601 et 602, la station serveur S compare la requête reçue Rn à toutes les requêtes précédemment reçues mémorisées dans le tableau Ts. Si la requête reçue est identique à l'une des requêtes précédemment reçues R', I'étape 603 consiste à comparer le paiement Pn associé à l a req uête Rn au pa ieme nt P' associé à cette req uête p récédem ment reçue R'. REVENDICATIONS 1. Procédé d'exécution à distance d'une fonction d'une station serveur (S) à partir d'une station client (Ci) comprenant une étape d'envoi (503) d'une requête (Rn) d'exécution à distance d'une fonction prédéterminée, ladite requête étant éventuellement accompagnée d'un paiement (Pn) supérieur ou égal au coût de l'exécution de ladite fonction, caractérisé en ce que si, lors de la réalisation d'un critère prédéterminé, ladite station client (Ci) n'a pas reçu correctement la réponse à lad ite req uête (Rn) ' la station client (Ci) réitère (507) au moins une fois la requête (Rn) auprès de la station serveur (S). 2. Procédé selon la revendication 1, caractérisé en ce que ledit critère prédéterminé consiste en l'expiration d'une durée prédéterminée. 3. Procédé selon la revendication 1, caractérisé en ce que ledit critère prédéterminé consiste en la rupture de la communication entre la station client (Ci) et la station serveur (S). 4. Procédé selon la revendication 1, 2 ou 3, caractérisé en ce que lorsque la station client (Ci) réitère ladite requête, elle renvoie uniquement la requête (Rn) d'exécution de la fonction à la station serveur (S) et ne renvoie pas le paiement (Pn). 5. Procédé selon la revendication 1, 2 ou 3, caractérisé en ce que lorsque la station client (Ci) réitère ladite requête, elle renvoie à la fois la requête (Rn) d'exécution de la fonction et le paiement (Pn) à la station serveur (S). 6. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que des identifiants sont associés de façon bijective aux requêtes. 7. Procédé selon la revendication précédente, caractérisé en ce que les identifiants sont les paiements associés aux requêtes. 8. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que la station client (Ci) est adaptée à réitérer toute requête déjà envoyée à la station serveur (S). 22 2824403 9. Procédé selon l'une quelconque des revendications 1 à 7, caractérisé en ce que la station client (Ci) est adaptée à réitérer uniquement la dernière requête envoyée à la station serveur (S). 10. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que si la requête (Rn) n'a pu être traitée correctement et si la requête (Rn) était accompagnce d'un paiement (Pn). Ia station client (Ci) reçoit le remboursement du paiement (Pn) en provenance de la station serveur (S). 11. Procédé d'exécution d'une fonction sur une station serveur (S), commandée à distance à partir d'une station client (Ci), comprenant une étape de réception (600) d'une requête (Rn) d'exécution à distance d'une fonction prédéterminée, ladite requête (Rn) étant éventuellement accompagnée d'un paiement (Pn) supérieur ou égal au coût d'exécution de ladite fonction, caractérisé en ce qu'il comporte des étapes suivant lesquelles: - ia station serveur (S) détermine (602) si la requête (Rn) reçue est une nouvelle requête ou la réitération d'une requête (R') précédente; et - si la req uête (Rn) reçue est la réitératio n d 'u ne req uête ( R') précédente: Ia station serveur (S) détermine si un paiement (P') valable associé à la requête (R') a déjà été reçu; et 20. si c'est le cas, la station serveur (S) traite la requête (Rn) 12. Procédé selon la revendication précédente, caractérisé en ce que si la requête (Rn) reçue est une nouvelle requête, la station serveur (S) traite la requête (Rn) 13. Procédé selon la revendication 11 ou 12, caractérisé en ce que, pour déterminer si la requête (Rn) reçue est une nouvelle requête ou la réitération d'une requête (R') précédente, la station serveur (S) compare la requête (Rn) reçue avec au moins une requête reçue précédemment. 14. Procédé selon la revendication précédente, caractérisé en ce que, pour comparer la requête (Rn) reçue avec au moins une requête reçue précédemment, la station serveur (S) compare des identifiants associés de façon bijective aux requêtes. 15. Procédé selon la revendication précédente, caractérisé en ce que les identifiants sont les paiements associés aux requêtes. 16. Procédé selon l'une quelconque des revendications 12 à 15, caractérisé en ce q ue si la req uête (Rn) reçue est u ne nouvelle req uête et si le traitement de la requête ne se déroule pas correctement, la station serveur (S) mémorise (609) une erreur de traitement et la signale en retour dans un message de réponse à la station client (Ci). 17. Procédé selon la revendication précédente, caractérisé en ce que, en cas d'erreur de traitement, la station serveur (S) joint un remboursement au message de réponse à la station client (Ci) 18. Procédé selon l'une quelconque des revendications 11 à 17, caractérisé en ce que si la requête (Rn) reçue est la réitération d'une requête (R') précédente et si la requête (Rn) est accompagnée d'un paiement (Pn), - si la station serveur (S) n'a pas mémorisé de paiement (P') valable associé à la requête (R') précédente, et si le paiement (Pn) accompagnant la requête (Rn) reçue est valable, la station serveur (S) traite la requête (Rn) reçue. 19. Procédé selon l'une quelconque des revendications 11 à 18, caractérisé en ce que si la req uête (Rn) reçue est la réitération d'une req uête (R') précédente et si la requête (Rn) est accompagnée d'un paiement (Pn), - si la station serveur (S) n'a pas mémorisé de paiement (P') valable associé à la requête (R') précédente, et si le paiement (Pn) accompagnant la requête (Rn) reçue n'est pas valable, la station serveur (S) rnémorise (606) une erreur de paiement et la signale en retour à la station client (Ci). 20. Procédé selon l'une quelconque des revendications 11 à 19, caractérisé en ce que si la requête (Rn) reçue est la réitération d'une requête (R') précédente et si la requête (Rn) est accompagnée d'un paiement (Pn), - si la station serveur (S) a mémorisé un paiement (P') valable associé à la requête (R') précédente, et si le paiement (Pn) reçu est identique au paiement (P') associé à la requête précédente, la station serveur (S) traite la requête (Rn) reçue. 21. Procédé selon l'une quelconque des revendications 11 à 20, caractérisé en ce que si la requête (Rn) reçue est la réitération d'une requête (R') précédente et si la requête (Rn) est accompagnée d'un paiement (Pn), - si la station serveur (S) a mémorisé un paiement (P') valable associé à la requête (R') précédente, et si le paiement (Pn) reçu est différent du paiement (P') associé à la requête (R') précédente, la station serveur (S) mémorise une erreur de paiement et la signale en retour à la station client (Ci). 22. Procédé selon l'une quelconque des revendications 11 à 21, caractérisé en ce q ue si la req uête (Rn) est accom pag née d' u n pa iement (Pn) et si la station serveur (S) ne peut transmettre à la station client (Ci) la réponse (An) à la requête (Rn), la station serveur (S) n'encaisse pas le paiement (Pn). 23. Procédé selon l'une quelconque des revendications 11 à 22, caractérisé en ce que si la req uête (Rn) reçue est la réitération d'une req uête (R') précédente, pour traiter la requête (Rn): - si le résultat (A') de la requête (R') est déjà mémorisé dans la station serveur (S), la station serveur (S) charge le résultat (A') et le retourne à la station client (Ci); - sinon, la station serveur (S) exécute la requête (Rn). 24. Procédé selon l'une quelconque des revendications 11 à 23, caractérisé en ce que la station serveur (S) est adaptée à accepter la réitération de toute requête déjà reçue en provenance de la station client (Ci). 25. Procédé selon l'une quelconque des revendications 11 à 23, caractérisé en ce que la station serveur (S) est adaptée à accepter uniquement la réitération de la dernière requête reçue en provenance de la station client (Ci). 26. Procédé selon l'une quelconque des revendications 11 à 25, caractérisé en ce qu'il comporte en outre une étape suivant laquelle, après réception de la requête (Rn) d'exécution à distance d'une fonction prédéterminée, la station serveur (S) vérifie que ladite fonction n'est pas incluse dans une liste prédéterminée de fonctions à réitération prohibée. 27. Dispositif d'exécution à distance d'une fonction d'une station serveur (S) à partir d'une station client (Ci) comprenant des moyens (301) 2824403 d'envoi d'une requête (Rn) d'exécution à distance d'une fonction prédéterminée, ladite requête étant éventuellement accompagnse d'un paiement (Pn) supérieur ou égal au coût de l'exécution de ladite fonction, caractérisé en ce qu'il comporte en outre des moyens (303) pour réitérer au moins une fois la requête (Rn) auprès de la station serveur (S) si, lors de la réalisation d'un critère prédéterminé, ladite station client (Ci) n'a pas reçu correctement la réponse à ladite requête (Rn). 28. Dispositif selon la revendication précédente, caractérisé en ce que ledit critère prédéterminé consiste en l'expiration d'une durée prédéterminée. 29. Dispositif selon la revendication 27, caractérisé en ce q ue led it critère prédéterminé consiste en la rupture de la communication entre la station client (Ci) et la station serveur (S). 30. Dispositif selon la revendication 27, 28 ou 29, caractérisé en ce que lesdits moyens (303) de réitération sont adaptés à renvoyer uniquement la requête (Rn) d'exécution de la fonction à la station serveur (S) et non le paiement (Pn) 31. Dispositif selon la revendication 27, 28 ou 29, caractérisé en ce que lesdits moyens (303) de réitération sont adaptés à renvoyer à la fois la requête (Rn) d'exécution de la fonction et le paiement (Pn) à la station serveur (S). 32. Dispositif selon l'une quelconque des revendications 27 à 31, caractérisé en ce que des identifiants sont associés de façon bijective aux requêtes. 33. Dispositif selon la revendication précédente, caractérisé en ce que les identifiants sont les paiements associés aux requêtes. 34. Dispositif selon l'une quelconque des revendications 27 à 33, caractérisé en ce que la station client (Ci) comporte des moyens adaptés à réitérer toute requête déjà envoyée à la station serveur (S). 35. Dispositif selon l'une quelconque des revendications 27 à 33, caractérisé en ce que la station client (Ci) comporte des moyens adaptés à réitérer uniquement la dernière requête envoyée à la station serveur (S). 36. Dispositif selon l'une quelconque des revendications 27 à 35, caractérisé en ce que la station client (Ci) comporte des moyens (305) adaptés à recevoir le remboursement du paiement (Pn) en provenance de la station serveur (S) si la req uête (Rn) n'a pu être traitée correctement et si la req uête (Rn) était accompagnée d'un paiement (Pn). 37. Dispositif selon l'une quelconque des revendications 27 à 36, caractérisé en ce qu'il est incorporé dans: - un microprocesseur (100); une mémoire morte (102) adaptée à mémoriser un programme pour exécuter à distance une fonction; et - une mémoire vive (103) comprenant des registres adaptés à mémoriser des variables mod ifiées lors de l'exécution dud it prog ramme. 38. Dispositif d'exécution d'une fonction sur une station serveur (S), commandée à distance à partir d'une station client (Ci), comprenant des moyens (310) de réception d'une requête (Rn) d'exécution à distance d'une fonction prédéterminée, ladite requête (Rn) étant éventuellement accompagnée d'un paiement (Pn) supérieur ou égal au coût d'exécution de ladite fonction, caractérisé en ce qu'il comporte: - des moyens (311) pour déterminer si la requête (Rn) reçue est une nouvelle requête ou la réitération d'une requête (R') précédente; - des moyens (312) de traitement de requêtes; - des moyens pour déterminer si un paiement (P') valable associé à une requête (R') a déjà été reçu, en cas de réitération d'une requête (R') précédente. 39. Dispositif selon ia revendication précédente, caractérisé en ce que les moyens (311) pour déterminer si la requête (Rn) reçue est une nouvelle requête ou la réitération d'une requête (R') précédente comportent des moyens de com pa raiso n de la req uête (Rn) reçue avec au moi ns u n e req uête reçue précédemment. 40. Dispositif selon la revendication précédente, caractérisé en ce que lesdits moyens de comparaison utilisent des identifiants associés de façon bijective aux requêtes. 41. Dispositif selon la revendication précédente, caractérisé en ce que les identifiants sont les paiements associés aux requêtes. 42. Dispositif selon l'une quelconque des revendications 38 à 41, caractérisé en ce qu'il comporte en outre des moyens pour mémoriser une erreur de traitement et la signaler en retour dans un message de réponse à la station client (Ci). 43. Dispositif selon la revendication précédente, caractérisé en ce qu'il comporte en outre des moyens pour joindre un remboursement au message de réponse à la station client (Ci), en cas d'erreur de traitement. 44. Dispositif selon l'une quelconque des revendications 38 à 43, caractérisé en ce qu'il comporte en outre des moyens pour mémoriser une erreur de paiement et la signaler en retour à la station client (Ci). 45. Dispositif selon l'une quelconque des revendications 38 à 44, caractérisé en ce que la station serveur (S) est adaptée à ne pas encaisser ie paiement (Pn) si la requête (Rn) est accompagnée d'un paiement (Pn) et si la station serveur (S) ne peut transmettre à la station client (Ci) la réponse (An) à la requête (Rn) 46. Dispositif selon l'une quelconque des revendications 38 à 45, caractérisé en ce que les moyens (312) de traitement de requêtes comportent: - des moyens pour charger le résultat (A') de la requête et le reto u rner à la station client (C i), si ia req uête (Rn) reçue est la réitératio n d 'u ne requête (R') précédente et si le résultat (A') de la requête (R') est déjà mémorisé dans la station serveur (S); et - des moyens pour exécuter la requête (Rn) si la requête (Rn) reçue est la réitération d'une requête (R') précédente et si le résultat (A') de la requête (R') n'est pas mémorisé dans la station serveur (S). 47. Dispositif selon l'une quelconque des revendications 38 à 46, caractérisé en ce que la station serveur (S) comporte des moyens adaptés à accepter la réitération de toute requête déjà reçue en provenance de la station client (Ci). 48. Dispositif selon l'une quelconque des revendications 38 à 46, caractérisé en ce que la station serveur (S) comporte des moyens adaptés à 28 2824403 accepter uniquement la réitération de la dernière requête reçue en provenance de la station client (Ci). 49. Dispositif selon l'une quelconque des revendications 38 à 48, caractérisé en ce qu'il comporte en outre des moyens pour vérifier, après réception de la requête (Rn) d'exécution à distance d'une fonction prédéterminée, que ladite fonction n'est pas incluse dans une liste prédéterminée de fonctions à réitération prohibée. 50. Dispositif d'exécution d'une fonction selon l'une quelconque des revendications 38 à 49, caractérisé en ce qu'il est incorporé dans: - un microprocesseur (100); - une mémoire morte (102) adaptée à mémoriser un programme pour exécuter une fonction commandée à distance; et - une mémoire vive (103) comprenant des registres adaptés à mémoriser des variables modifises lors de l'exécution dud it program me. 51. Station client (Ci) d'un réseau de communication, caractérisée en ce qu'elle comporte des moyens adaptés à mettre en ceuvre un procédé d'exécution à distance selon l'une quelconque des revendications 1 à 10. 52. Station serveur (S) d'un réseau de communication, caractérisée en ce qu'elle comporte des moyens adaptés à mettre en ceuvre un procédé d'exécution d'une fonction selon l'une quelconque des revendications 11 à 26. 53. Réseau de communication, caractérisé en ce qu'il comporte un dispositif d'exécution à distance selon l'une quelconque des revendications 27 à 37. 54. Réseau de communication, caractérisé en ce qu'il comporte un dispositif d'exécution d'une fonction selon l'une quelconque des revendications