FR2828043A1 - 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 - Google Patents

Abstract

Procédé de configuration d'une unité fonctionnelle dans un terminal connecté à un premier réseau communication, l'utilisation de l'unité fonctionnelle provoquant l'exécution sur le premier réseau d'au moins une fonction sur un objet informatique. L'unité fonctionnelle est configurée conformément à des informations de configuration contenues dans une mémoire de configuration du terminal. Ce procédé est remarquable en ce qu'il comporte, lorsque au moins une fonction est associée à un coût d'exécution, les étapes suivantes :- obtention (E81) d'une interface de l'objet informatique;- extraction (E81) de l'interface d'une première information relative au coût d'exécution de la fonction; - création (E83) dans la mémoire de configuration, à partir de la première information extraite de l'interface, d'une seconde information caractéristique d'un mode de détermination du coût d'exécution de la fonction.

Description

<Desc/Clms Page number 1>

L'invention a trait de manière générale aux réseaux de communication dans lesquels l'utilisation ou l'exécution de fonctionnalités fournies par des noeuds de réseau sont soumises à des conditions de paiement.

L'invention concerne plus particulièrement un procédé de configuration d'une unité fonctionnelle dans un terminal connecté à un réseau de communication, l'utilisation de l'unité fonctionnelle provoquant l'exécution sur le réseau d'au moins une fonction sur un objet informatique.

L'invention concerne encore un procédé d'exécution d'une fonction payante à partir d'un terminal dans un réseau de communication, le terminal comportant au moins une unité fonctionnelle configurée selon l'invention.

L'invention concerne aussi un procédé de fourniture d'informations de configuration, ces informations étant sauvegardées par un noeud contrôleur dans le réseau de communication, et concernant des unités fonctionnelles incorporées dans une pluralité de terminaux connectés au réseau, les informations ayant été obtenues par un procédé de configuration conforme à l'invention.

L'invention concerne également des dispositifs aptes à mettre en oeuvre les procédés précités.

L'invention s'applique particulièrement à un réseau de communication dont l'architecture est basée sur le standard IEEE 1394.

<Desc/Clms Page number 2>

Le standard IEEE 1394 définit une technologie de bus série à haute vitesse destiné à interconnecter des produits d'électronique grand public et des systèmes informatiques, tels que par exemple des télévisions numériques, des ordinateurs personnels, des magnétoscopes numériques, des caméscopes numériques, des imprimantes, des télécopieurs, etc. Le standard IEEE 1394 (parfois désigné par firewire) définit par ailleurs des modes de communication isochrone et asynchrone pour le transfert de données, ce qui le rend idéalement adapté aux applications multimédia.

De manière classique dans un tel système de communication, les unités fonctionnelles des dispositifs (encore appelés terminaux) connectées au bus peuvent être répertoriées par un terminal appelé classiquement "contrôleur". Dans ce but, le contrôleur lit une mémoire, dite"de configuration", incorporée dans chacun des équipements connectés au bus. Selon les spécifications définies par l'organisation connue sous le nom de"1394 Trade Association" (TA), cette opération est appelée "protocole de découverte et d'énumération" (en anglais, discovery and enumeration protocol).

L'opération d'énumération n'est effectuée qu'après une procédure d'initialisation du bus. Celle-ci est déclenchée lors de l'apparition d'un signal Bus~Reset sur le bus. Un tel signal peut apparaître pour plusieurs raisons telles que, par exemple, à la suite d'une erreur lors d'une requête générée par une application, suite à la connexion d'un nouveau dispositif sur le bus, ou, inversement, à la suite de la déconnexion d'un dispositif présent sur le bus.

D'autre part, dans les systèmes de communication actuels, par exemple dans le réseau Internet, de plus en plus d'ordinateurs travaillent en réseau et utilisent les services fournis par d'autres ordinateurs appelés souvent "serveurs" ou "stations serveurs". Il n'est pas rare que, sur un tel réseau de communication, les services fournis par les stations serveurs soient rémunérés.

De manière classique, une station serveur donnée peut, pour être rémunérée, ouvrir un compte client associé à une station client du réseau. L'ensemble des opérations effectuées par la station client sur la station serveur est mémorisé et facturé régulièrement, par exemple tous les mois.

<Desc/Clms Page number 3>

Un tel système oblige à ouvrir et gérer un compte client sur chaque station serveur du réseau. En outre, ce type de paiement est une contrainte sur un réseau de communication dans lequel il est souhaitable que chaque utilisateur, à partir d'une station client, puisse utiliser différents serveurs du réseau.

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 exécutée à distance correspond généralement à un ensemble d'instructions d'un programme informatique mémorisé sur la station serveur.

Dans ce contexte, il est souhaitable dans un réseau de type IEEE 1394, de disposer d'un système de paiement permettant de pouvoir soumettre une opération d'utilisation ou d'exécution de fonctions utilisables via une unité fonctionnelle incorporée dans un noeud du réseau, à des conditions de paiement, un tel système de paiement devant procurer une grande flexibilité pour la rémunération de cette opération.

En bref, le but de la présente invention est de proposer un système de configuration d'une unité fonctionnelle accessible depuis un réseau de communication, en particulier basé sur un bus série IEEE1394, qui permette de pouvoir soumettre à des conditions de paiement l'utilisation de cette unité fonctionnelle.

A cet effet, la présente invention concerne, selon un premier aspect, un procédé de configuration d'une unité fonctionnelle dans un terminal connecté à un premier réseau de communication. L'utilisation de l'unité fonctionnelle provoquant l'exécution sur le premier réseau d'au moins une fonction sur un objet informatique. L'unité fonctionnelle est configurée conformément à des informations de configuration contenues dans une mémoire de configuration du terminal.

Conformément à l'invention ce procédé est remarquable en ce qu'il comporte, lorsqu'au moins une fonction est associée à un coût d'exécution, les étapes suivantes :

<Desc/Clms Page number 4>

- obtention d'une interface de l'objet informatique ; - extraction de l'interface d'une première information relative au coût d'exécution de la fonction ; - création dans la mémoire de configuration, à partir de la première information extraite de l'interface, d'une seconde information caractéristique d'un mode de détermination du coût d'exécution de la fonction.

Ainsi lorsque la fonction est exécutée depuis le terminal, le coût d'exécution de la fonction est automatiquement calculé.

Selon une caractéristique particulière de l'invention, le premier réseau de communication est un réseau ayant une architecture basée sur au moins un bus série IEEE 1394.

L'invention permet ainsi de définir un système de paiement automatique relatif à l'exécution de fonctions dans un réseau de type IEEE1394.

Selon une autre caractéristique particulière de l'invention, l'étape de création d'une seconde information, est suivie d'une étape de réinitialisation (bus reset) du premier réseau.

De cette façon un terminal particulier ("contrôleur") peut lire la mémoire de configuration du terminal selon le protocole de découverte et d'énumération IEEE1394.

Selon une caractéristique particulière d'implémentation, la seconde information est codée dans un ou plusieurs champs de données prédéfinis dans la mémoire de configuration selon un format utilisant un jeu de clés étendues.

Par ailleurs, selon une autre caractéristique de l'invention, le coût d'exécution d'une fonction, dont le mode de détermination est défini par la seconde information, peut être codé selon un jeu de clés étendues, de sorte qu'il peut être : - fixe ; ou, - déterminé par un serveur d'objets informatiques sur le réseau, sur requête dudit terminal ; ou,

<Desc/Clms Page number 5>

- calculé en fonction d'un ou plusieurs paramètres prédéfinis, chaque paramètre étant représentatif d'une caractéristique de l'objet informatique auquel s'applique la fonction, ou d'une caractéristique de la fonction, ou d'une caractéristique d'utilisation de l'unité fonctionnelle.

Ainsi, le système de fonctions payantes selon l'invention est très souple et peut s'adapter au type d'échange payant d'informations propre au commerce électronique qui se développe actuellement dans des réseaux tels que Internet.

Selon un mode de réalisation préféré de l'invention, le terminal considéré est relié à un second réseau de communication et l'objet informatique auquel s'applique la fonction est hébergé par une station serveur sur ce second réseau, qui peut être, en particulier, Internet.

Corrélativement, selon un deuxième aspect, la présente invention concerne un procédé d'exécution d'une fonction payante à partir d'un terminal dans un réseau de communication, le terminal comportant au moins une unité fonctionnelle configurée selon un procédé de configuration tel que brièvement défini ci-dessus. Ce procédé d'exécution est remarquable en ce qu'il comporte les étapes suivantes : - extraction, de la mémoire de configuration de l'unité fonctionnelle, d'une seconde information caractéristique d'un mode de détermination du coût d'exécution de la fonction ; - détermination du coût d'exécution de la fonction ; - exécution de la fonction.

Selon un troisième aspect, la présente invention concerne un procédé de fourniture d'informations de configuration, ces informations étant sauvegardées par un noeud contrôleur dans un réseau de communication. Les informations de configuration considérées concernent des unités fonctionnelles incorporées dans une pluralité de terminaux connectés au réseau, et ont été obtenues par un procédé de configuration tel que succinctement exposé plus haut.

<Desc/Clms Page number 6>

Conformément à l'invention, ce procédé de fournitures d'informations comporte les étapes suivantes, mises en oeuvre pour chacun des terminaux : - extraction, de la mémoire du noeud contrôleur, des informations de configuration du terminal ; - création d'une première fenêtre sur un écran de visualisation, dans laquelle sont affichées des informations générales relatives au terminal considéré, permettant notamment à un utilisateur d'identifier le terminal ainsi que la ou les unités fonctionnelles incorporées dans celui-ci ; - création dans cette première fenêtre d'autant de premières icônes distinctes qu'il y a d'unités fonctionnelles dans le terminal, les informations spécifiques relatives à une unité fonctionnelle particulière étant accessibles à l'utilisateur en sélectionnant l'icône correspondante au moyen d'un dispositif de sélection adapté ; - pour chaque unité fonctionnelle, détermination si l'utilisation de l'unité fonctionnelle permet d'exécuter au moins une fonction présentant un caractère payant ; - pour chaque unité fonctionnelle déterminée comme pouvant permettre l'exécution d'au moins une fonction payante, création d'une icône additionnelle affichée à proximité de la première icône correspondante, l'icône additionnelle étant indicative du caractère payant d'au moins une fonction exécutable par l'intermédiaire de l'unité fonctionnelle, les informations relatives au coût d'exécution de cette (ces) fonction (s) étant accessibles à l'utilisateur par la sélection de l'icône additionnelle correspondante au moyen d'un dispositif de sélection adapté.

Grâce à un tel procédé, mise en oeuvre dans une interface utilisateur appropriée, un utilisateur du terminal peut être facilement et efficacement renseigné sur l'ensemble des unités fonctionnelles du réseau et en particulier celles dont l'utilisation présente un caractère payant.

L'invention vise également un dispositif, tel qu'un système informatique, connecté à un réseau de communication, ce dispositif comportant

<Desc/Clms Page number 7>

des moyens adaptés à la mise en oeuvre de tout ou partie de la pluralité de procédés tels que brièvement définis plus haut. L'invention vise aussi un réseau de communication comportant au moins un tel dispositif.

La présente invention concerne encore un programme d'ordinateur apte à mettre en oeuvre tout ou partie de la pluralité des procédés brièvement décrits supra, lorsque le programme est chargé et exécuté dans un système d'ordinateur incorporé ou constituant un terminal connecté à un réseau de communication.

L'invention vise aussi un support d'informations, tel que par exemple, une disquette ou un compact disque (CD) contenant un tel programme d'ordinateur.

Les avantages de ce dispositif, programme d'ordinateur, et de ce support d'informations, sont identiques à ceux des divers procédés en conformité avec l'invention, tels que brièvement exposés supra.

D'autres particularités et avantages de l'invention apparaîtront encore dans la description ci-après d'un mode de réalisation, faite en référence aux dessins annexés, donnés à titre d'exemples de réalisation non limitatifs, dans lesquels : - la FIG. 1 est un schéma blocs représentant un réseau de communication, composé d'un réseau bâti au dessus d'un bus série IEEE1394 connecté au réseau Internet, dans lequel on peut implémenter l'invention ; - la FIG. 2 est un schéma blocs représentant l'architecture interne d'un noeud, connecté au système de la FIG. 2, dans lequel on peut mettre en oeuvre l'invention ; - la FIG. 3 représente une structure de données classique de la mémoire de configuration incorporée dans un noeud tel que représenté à la FIG. 2 ; - la FIG. 4, composée des FIGs. 4A-4D, illustre la manière dont la mémoire de configuration représentée à la FIG. 3, peut être organisée à partir de l'utilisation de clés dites "étendues" ;

<Desc/Clms Page number 8>

- la FIG. 5 illustre la définition d'un nouveau jeu de clés étendues grâce auquel on peut déclarer le caractère payant d'une fonction fournie par une unité fonctionnelle dans un noeud connecté sur le bus ; - la FIG. 6 est un organigramme illustrant les traitements exécutés, après initialisation du bus IEEE1394, par un noeud contrôleur pour lire et analyser les mémoires de configuration incorporées dans les équipements connectés sur le bus ; - la FIG. 7 est un schéma bloc illustrant un exemple de système de paiement pour l'exécution à distance d'une fonction, qui peut être mis en oeuvre dans un réseau IEEE 1394 dans lequel les unités fonctionnelles sont configurées selon l'invention ; - la FIG. 8 illustre le processus de configuration d'une unité fonctionnelle permettant l'exécution d'une fonction ayant un caractère payant ; - la FIG. 9 détaille l'étape de chargement de l'interface d'une fonction ayant un caractère payant, mise en oeuvre lors de l'exécution du processus de configuration illustré à la FIG. 8 ; - la FIG. 10 illustre le processus mis en oeuvre dans un terminal d'un réseau IEEE 1394 pour exécuter une fonction ayant un caractère payant ; - la FIG. 11 illustre le processus mis en oeuvre dans une station client pour évaluer le coût d'exécution d'une fonction exécutable à distance ; - la FIG. 12 illustre le processus mise en oeuvre dans une station client pour exécuter à distance une fonction ; - la FIG. 13 détaille l'opération d'obtention d'une somme d'argent effectuée lors de l'exécution du processus représenté à la FIG. 12. ; - les FIGs. 14 et 15 illustrent les traitements exécutés dans une station serveur lors de l'exécution d'une fonction ; - la FIG. 16 illustre un procédé de génération et d'affichage d'informations de configuration concernant un ensemble de noeuds connectés à un réseau IEEE1394.

La FIG. 1 est un schéma blocs représentant un exemple de réseau de communication dans lequel on peut implémenter l'invention. Le réseau représenté à la FIG. 1, est composé d'équipements ou noeuds

<Desc/Clms Page number 9>

connectés sur un bus série IEEE1394, formant un "réseau IEEE1394". Ce réseau IEEE1394 est par ailleurs connecté à Internet.

Dans cet exemple, on retrouve successivement, connectés au bus IEEE1394, un récepteur satellite 1, un récepteur de télévision numérique 2, un lecteur de disques vidéo numériques (DVD) 3, un ordinateur personnel (PC) 4 connecté à Internet par l'intermédiaire d'un modem 10 et comportant un lecteur de carte mémoire 11, un caméscope numérique (DVCR) 5 et une imprimante 6.

Chacun de ces dispositifs constitue un noeud pour ce réseau IEEE1394. Dans cet exemple, l'ordinateur personnel (PC) 4 et/ou la télévision numérique 2 peuvent assurer le rôle de noeud contrôleur.

Une station serveur 12, par exemple un serveur d'images numériques, est connecté à l'Internet et peut donc être accessible par l'ordinateur personnel 4.

Le bus IEEE 1394, représenté ici par des connecteurs 8 et des câbles 9, est basé sur le standard IEEE1394-1995 et son supplément IEEE1394a-2000.

Par ailleurs, chacun de ces noeuds inclut une mémoire de configuration compatible avec les standards IEEE1212 et IEEE1394a-2000.

En bref, le standard IEEE1394 décrit un bus série haute vitesse à bas coût incluant : - une couche physique pour différents média physiques ; - un mécanisme d'accès au bus ; - un mécanisme d'allocation automatique d'adresses ; - deux modes de communication isochrone et asynchrone ; - des fonctions de contrôle du bus.

Le standard IEEE1212 décrit quant à lui une architecture de registres de contrôle et d'état pour un bus, incluant : - un système d'adressage ; - un jeu de messages minimum ; - un jeu de registres de contrôle et d'état ; - la structure d'une mémoire de configuration avec un jeu de clés.

<Desc/Clms Page number 10>

On pourra se reporter aux spécifications de ces standards pour obtenir de plus amples détails.

En liaison avec la FIG. 2, on va décrire maintenant l'architecture interne d'un noeud IEEE1394 tel que représenté à la FIG. 1, dans lequel on peut mettre en oeuvre l'invention selon un mode préféré de réalisation.

L'architecture du noeud est de type système informatique bâti autour d'un processeur.

Comme représenté à la FIG. 2, un noeud IEEE1394 (20) comporte un processeur 204 chargé d'exécuter les instructions des programmes stockés dans une mémoire non volatile ROM 203 et notamment le ou les programmes nécessaires à la mise en oeuvre de l'invention. Les données nécessaires (c'est- à-dire les"variables") au processeur 204 pour l'exécution des programmes, sont stockées dans une mémoire volatile RAM 208.

Le noeud 20 comporte un module 207 contenant une ou plusieurs unités fonctionnelles. Par exemple, le PC 4 (Fig. 1) comporte une unité fonctionnelle de communication communément appelée modem (10) et une unité fonctionnelle de stockage d'informations (disque dur).

Un espace mémoire, constituant la mémoire de configuration du noeud, est associé au module 207. La mémoire de configuration contient les informations caractéristiques liées à la configuration de ou des unités fonctionnelles contenues dans le module fonctionnel 207. Il est à noter qu'un dispositif 20 peut comporter plusieurs modules 207.

La mémoire de configuration du noeud ainsi qu'une sauvegarde de celle-ci, est aménagée dans un composant mémoire 206 de type non volatile et réinscriptible, par exemple une mémoire FLASH. Cependant, selon une variante d'implémentation, la mémoire de configuration peut utiliser la mémoire FLASH 206 ainsi que la mémoire ROM 203. Dans ce cas la mémoire ROM contient les informations de configuration qui sont figées (c.-à-d., fixes, statiques) tandis que la mémoire FLASH contient les informations susceptibles de changer (c.-à-d., dynamiques).

Un bus interne local 209 relie entre eux les différents éléments du noeud 20 et assure ainsi leur interopérabilité.

<Desc/Clms Page number 11>

Le noeud 20 comporte également une interface utilisateur 205 pouvant comprendre, par exemple, un écran, un clavier, une souris, un lecteur de carte mémoire, des diodes électroluminescentes (LED) ou des boutons.

L'interface utilisateur 205 permet à un utilisateur d'entrer des commandes qui seront transmises au processeur (CPU) 204 par l'intermédiaire du bus local 209, avant d'être interprétées par celui-ci.

Le noeud 20 comporte également une horloge temps réelle 210 lui permettant de maintenir une date système (date/heure/minute/seconde).

En outre, le noeud 20 comporte une interface de communication 202 basée sur le standard IEEE1394-1995 et son supplément IEEE1394a- 2000. Cette interface permet l'échange de données entre le module fonctionnel 207 du noeud considéré et un module similaire d'un autre noeud connecté sur le bus. Finalement, le noeud 20 est connecté à un bus série IEEE1394 (9) au moyen de connecteurs 8.

La FIG. 3 représente la structure de données classique de la mémoire de configuration incorporée dans un noeud tel que représenté à la FIG. 2.

La structure de la mémoire de configuration exposée ici, en liaison avec la FIG. 3, est compatible avec les standards IEEE1212 et IEEE1394a- 2000.

Comme représenté à la FIG. 3, la mémoire de configuration comprend notamment une sous-partie 31 appelée "Bus Information Block", BIB, (bloc d'information de bus) ; une sous-partie 32 appelée"Roof Directory" (répertoire racine) ; une ou plusieurs sous-parties appelées "Unit Directory" (répertoire d'unité) optionnelles ; enfin une zone 34 relative à des informations spécifiques au constructeur (Other vendor dependent information).

La sous-partie Bus~lnfo~Block (BIB) 31 contient des informations qui précisent les caractéristiques du bus de communication, ici de type IEEE 1394. Les différents champs s'y rapportant sont définis en section 8.3. 2.5. 4 du standard IEEE1394-1995 et en section 8.3. 2.5 du supplément IEEE1394. a- 2000.

<Desc/Clms Page number 12>

Il est à noter que parmi ces champs, le champ "generation" (en gras sur la figure) est utilisé pour indiquer un changement dans la mémoire de configuration. A cet effet, la donnée qu'il contient est incrémentée à chaque modification de la mémoire de configuration, cependant sans pouvoir reprendre une valeur déjà utilisée au cours des 60 secondes précédentes.

La sous-partie Root Directory (32) contient des informations générales (par exemple le fabricant) sur le terminal correspondant à la mémoire de configuration considérée, ainsi que des pointeurs, par exemple dans le champ"undirectory~offsef (en gras sur la figure), pointant sur des informations plus détaillées.

Pour obtenir plus d'informations sur les différents champs pouvant être utilisés dans cette sous-partie, on pourra se rapporter à la section 7.6 du standard IEEE1212.

Par ailleurs, d'autres documents viennent compléter les définitions

générales contenues dans les spécifications des standards IEEE1212 et IEEE1394a-2000. Ainsi, on pourra se reporter au document"Configuration ROM/b/'/4\//C dewces . O", en date du 15 mars 2000, publié par l'association "1394 Trade Association" (TA), et au document"The HAVI Architecture version 0.8", en date du 11 mai 1998, publié par le consortium HAVI. Dans ces document, il est défini des règles supplémentaires pour l'interopérabilité des équipements répondant à leurs spécifications respectives.

Conformément au standard IEEE1212, les informations contenues dans les sous-parties Root Directory (32) et Unit Directory (34) de la mémoire de configuration illustrée ici sont structurées grâce à l'utilisation de clés. Une clé est un indicateur de la donnée qui la suit, le couple {clé, donnée} formant ainsi un "tout" compréhensible, par exemple par un dispositif contrôleur extérieur.

Chaque clé est identifiée dans la mémoire de configuration par un identifiant.

Ainsi dans la sous-partie Root Directory représentée à la FIG. 3, l'identifiant'03' (en hexadécimal, c.-à-d.,"0000 0011"en binaire sur 8 bits) identifie la clé correspondant au module fabricant (module~vendor~id). Le champ qui suit les 8 bits correspondant à l'identifiant de la clé contient les données correspondant au module fabricant.

<Desc/Clms Page number 13>

De même, dans la sous-partie unit-directory 33 de la mémoire de configuration, les clés ayant pour identifiant, respectivement, '12'et'13' (en hexadécimal) précèdent, respectivement, la donnée définissant le type d'unité fonctionnelle (champ unit~spec~id), et celle définissant la version du code logiciel correspondant à cette unité fonctionnelle (champ unit-software~version).

Comme cela sera détaillé dans la suite de l'exposé, selon le mode préféré de réalisation de l'invention décrit ici, on utilisera principalement le champ"generation"de la partie BIB 31 de la mémoire de configuration ainsi qu'un jeu spécifique de clés dites"étendues"défini dans la sous-partie "UnijDirectory" (33) de la mémoire de configuration.

La FIG. 4, composée des figures 4A-4D, illustre la manière dont est structurée une mémoire de configuration telle que représentée à la FIG. 3, en liaison avec l'utilisation de"clés étendues"telles que définies dans la nouvelle révision du standard IEEE1212 (section 7.5. 2).

La FIG. 4A reprend le format d'une sous-partie d'une mémoire de configuration relatif à l'utilisation de clés, tel que décrit précédemment en relation avec la FIG. 3. Comme représenté à la Fig. 4A, un tel sous-ensemble de la mémoire (par ex., la sous-partie unit-directory), comporte d'abord un champ"/eng"contenant une information correspondant à la taille du sousensemble considéré, suivi d'un champ"crc" (Cyclic Redundancy Checks) contenant une information relative à la détection d'erreurs. Ensuite, la souspartie considérée comporte des "couples" {clé, donnée} successifs (champs key et data), chaque couple représentant une"ligne"de la sous-partie considérée.

Par exemple, une clé"fabricant" (vendor en anglais) sera suivie du nom du fabricant sous forme textuelle ou codé, selon la définition de la clé.

Dans la nouvelle révision du standard IEEE1212 section 7.5. 2, on définit le concept de "clé étendue" (extended key). Selon ce concept, il est possible de définir un jeu de clés étendues associé à une entité particulière.

Chaque jeu de clés étendues utilise plusieurs"lignes"ou couples {clé, donnée} classiques d'une sous-partie de la mémoire de configuration, tels que définis plus haut.

<Desc/Clms Page number 14>

Chaque jeu de clés étendues comporte d'abord, en utilisant un premier couple {clé, donnée} classique, une information indiquant que l'information qui suit identifie un jeu de clés, suivi d'un identificateur de l'organisation ou du fabricant responsable du jeu de clés considéré. Ce jeu de clés est valide uniquement pour le sous-ensemble considéré (par exemple un

"Unit Directon "L/nD/recfo/y") tant qu'un autre jeu de clés n'est pas choisi.

Dans un couple {clé, donnée} classique suivant en mémoire, on identifie d'abord que l'information qui suit identifie une clé étendue particulière, puis on donne l'identificateur de la clé. Enfin, dans un troisième couple {clé, donnée}, on identifie d'abord que la donnée qui va suivre est la valeur donnée à la clé étendue identifiée dans le couple {clé, donnée} précédent, puis on fournit cette valeur. Il y a autant de "troisième couple" {clé, donnée} que de clés étendues dans le jeu considéré.

Les FIGs. 4B-4D illustrent le format d'un jeu de clés étendues comportant une seule clé. Ainsi, dans cet exemple, le jeu de clés étendues utilise 3 couples {clé, donnée} successifs.

A la FIG. 4B, le champ clé contenant la valeur'1 C'en hexadécimal ('00011100'en binaire) indique que le champ donnée qui suit (champ Extended Key Specifier ID) identifie un jeu de clés étendues.

A la FIG. 4C, le champ clé contient la valeur'1 D'en hexadécimal indiquant que le champ donnée qui suit (champ Extended~key~ID), identifie une clé étendue particulière du jeu (dans cet exemple, cette clé étendue est unique).

Enfin, à la FIG. 4D, le champ clé comprend une première partie "type" indiquant la localisation dans la mémoire du champ donnée qui suit (type ='00'en binaire, signifie que le champ donnée est contigu). Le champ clé comprend une seconde partie, valant'1 E'en hexadécimal sur 6 bits ('01 1110' en binaire), indiquant que le champ donnée qui suit (champ value), contient la valeur associée à la clé étendue identifiée dans le champ Extended key ID qui précède.

La FIG. 5, illustre la définition d'un nouveau jeu de clés étendues grâce auquel on peut déclarer le caractère payant d'une fonction exécutable via

<Desc/Clms Page number 15>

une unité fonctionnelle incorporée dans un noeud connecté sur un bus série de type IEEE 1394.

Ce jeu de clés étendues utilise, dans une mémoire de configuration, le format décrit précédemment en relation avec les figures 4A-4D.

Par ailleurs, ce jeu de clés permet conformément à l'invention de spécifier la procédure à mettre en oeuvre pour calculer le coût associé à l'utilisation de l'unité fonctionnelle (c. -à-d., le coût lié à l'exécution de ou des fonctions associées à l'utilisation de l'unité fonctionnelle considérée) et par conséquent de déterminer ce coût.

Le tableau de la FIG. 5 résume un jeu de clés étendues pouvant être utilisé conformément à l'invention pour spécifier les coûts liés à l'utilisation d'une unité fonctionnelle.

La colonne du tableau référencée par l'étiquette "Extended~Key ~'D" correspond au champ du même nom représenté à la FIG.

4C. Dans cette colonne, chaque ligne du tableau identifie de manière unique une clé étendue particulière du jeu. La colonne du milieu référencée par l'étiquette "Nom" fournit le nom attribué à la clé identifiée par la donnée correspondante de la colonne de gauche. Enfin, la colonne de droite référencée par l'étiquette"Utilisation de l'entrée Extended Key ID", spécifie le mode de détermination du prix lié à l'utilisation de la clé.

Ainsi, à la première ligne de la colonne de gauche du tableau, une première clé est identifiée par l'identifiant :"0160" ('00'en hexadécimal), et est nommée (colonne du milieu) "CoûLFixe". Selon la définition à la colonne de droite du tableau, cette clé permet de spécifier un prix fixe lié à l'utilisation de l'unité fonctionnelle considérée, c'est-à-dire, relatif à l'exécution de ou des fonctions programmées appelées lors de l'utilisation de l'unité fonctionnelle.

De même, à la seconde ligne du tableau, une seconde clé identifiée par l'identifiant "116016" ('0001 0000'en binaire) est nommée "Coût Serveur", et indique que le coût associé à l'utilisation de l'unité fonctionnelle peut être obtenu par interrogation d'un serveur.

Selon la troisième ligne du tableau, une troisième clé identifiée par "216exp16", où "exp16" désigne un champ dont la valeur (hexadécimale) est

<Desc/Clms Page number 16>

indicative d'un mode prédéterminé de calcul du prix lié à l'utilisation de l'unité fonctionnelle. Cette clé est nommée"CoutFxpressionSimple" (cf. colonne "Nom") et permet donc de spécifier un coût associé à l'utilisation de l'unité fonctionnelle, qui est calculé selon la valeur du champ "exp16".

Le champ"expe"peut prendre la valeur 0 auquel cas elle n'est pas significative, et les valeurs 1,2, 3,4 ou 5 auquel cas le coût est fonction d'une durée d'exécution ou d'une quantité d'information échangée entre le client et le serveur.

Selon un mode de réalisation donné ici à titre d'exemple, on donne ci-dessous l'interprétation du champ "exp16" en fonction de certaines valeurs prédéterminées. Les valeurs données ci-dessous sont des valeurs décimales qui sont codées en hexadécimal dans le champ"Extended~Key~ID" de la clé étendue considérée (FIG. 4C). exp ='0' : valeur non significative. exp ='1'. prix calculé par seconde d'utilisation. exp ='2' : prix calculé par minute d'utilisation. exp ='3'prix calculé par jour d'utilisation. exp ='4'prix calculé par quantité prédéterminée d'informations transmises au serveur. exp ='5'prix calculé par quantité prédéterminée d'informations reçues par le serveur.

La valeur nominale de ce prix en fonction du paramètre correspondant (seconde, minute, jour d'utilisation, etc. ) est codée dans le champ "value" de la clé étendue considérée (cf. FIG. 4D).

Enfin, selon la quatrième ligne du tableau, une dernière clé identifiée par "316016" est nommée "Coût~Expression~Complexe". Cette clé permet de combiner des clés du type "Coût~Expression~Simple" afin de décrire une expression dite"complexe"du prix, mettant en oeuvre plusieurs expressions simples définies selon les clés de type "Coû ExpressionSimple" considérées.

Dans ce cas, le champ "value" (tel que défini en FIG. 4D) qui suivra a clé "Cout~Expression~Complexe" considérée indique le nombre de

<Desc/Clms Page number 17>

clés de type"CoûtExpression~Simple" qui suivent dans la mémoire de configuration, et qui seront prises en compte pour définir le mode de calcul du coût d'utilisation de l'unité fonctionnelle correspondante.

En référence à la FIG. 6, on va décrire les traitements exécutés par un noeud contrôleur, après initialisation du bus IEEE1394, pour lire et analyser les mémoires de configuration incorporées dans les équipements connectés sur le bus (discovery and enumeration protocol).

Lors de chaque initialisation du bus (Bus Reset), le contrôleur archive dans sa mémoire locale la liste des noeuds (terminaux) présents (c.-àd., connectés) sur le bus. Cette liste contient, pour chaque noeud, un identificateur du noeud et son adresse logique. La liste peut être stockée en mémoire non-volatile (par ex. mémoire FLASH 206, FIG. 2) ou bien en mémoire RAM (208). Dans ce dernier cas, la liste est recopiée en mémoire non volatile avant un arrêt du contrôleur.

Ensuite, comme illustré à l'étape E601, pour chaque équipement dont l'adresse est présente dans la liste de terminaux précitée, le contrôleur effectue, au travers du bus IEEE1394, une demande de lecture du sousensemble "Bus Information Block" (BIB) de la mémoire de configuration de l'équipement considéré.

Puis on passe au test de l'étape E602 à laquelle le contrôleur attend une réponse à sa demande de lecture. Lorsque le contrôleur reçoit une réponse à sa demande de lecture-c.-à-d., un paquet est envoyé par le noeud considéré contenant l'information BIB de ce noeud-on passe à l'étape E603 dans laquelle le contrôleur vérifie s'il a déjà archivé la mémoire de configuration de cet équipement. Cela est réalisé en vérifiant dans le sous-ensemble "Bus Information Block'que pour le couple node-vendor et et chip~ID (cf. FIG. 3, 31) considéré, le champ generation associé n'a pas changé depuis la précédente lecture du sous-ensemble "Bus Information Block" relatif à ce noeud.

Dans la négative, on passe au test E607 pour vérifier s'il existe un autre équipement connecté au bus dont le sous-ensemble "Bus Information

<Desc/Clms Page number 18>

Block"n'a pas encore été lu. Dans la négative, cette procédure se termine ; dans le cas contraire, on revient à l'étape E601 précédemment décrite.

Dans l'affirmative au test E603, c'est-à-dire lorsque la mémoire de configuration du noeud considéré a changé ou, s'il s'agit de la première lecture du sous-ensemble "Bus Information Block" (ce qui est détecté par un couple nodevendor/D et chip~1D inconnu), on passe à l'étape E604.

A l'étape E604, le contrôleur commence par archiver (c.-à-d. mémoriser) le sous-ensemble BIB reçu, puis il effectue l'opération proprement dite de lecture de la mémoire de configuration du noeud considéré. Pour cela, le contrôleur effectue, au travers du bus IEEE1394, une demande de lecture de la partie de la mémoire de configuration associée au sous-ensemble"BIB" préalablement archivé, il s'agit en particulier du sous-ensemble"LMDirectory' (cf. FIG. 3,33) de la mémoire de configuration.

On passe alors à l'étape de test E605, dans laquelle le contrôleur attend une réponse à cette demande. Lorsque la réponse à la demande de lecture est reçue par le contrôleur, celui-ci, à l'étape E606, archive en mémoire la copie de la mémoire de configuration contenue dans la réponse en provenance de l'équipement considéré.

Ensuite, on effectue l'étape de test E607, dans laquelle on vérifie s'il existe un autre équipement connecté au bus dont le sous-ensemble "Bus Information Block'n'a pas encore été lu, c'est-à-dire si la liste susmentionnée des noeuds connectés au bus n'a pas encore été entièrement parcourue. Si c'est le cas, on passe à nouveau à l'étape E601 et le processus recommence tel que décrit précédemment. Au contraire, si tous les noeuds connectés au bus ont été testés, la procédure se termine là.

La FIG. 7 est un schéma bloc illustrant un exemple de système de paiement pour l'exécution à distance d'une fonction, qui peut être mis en oeuvre dans un réseau IEEE1394 dans lequel des unités fonctionnelles sont configurées selon 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

<Desc/Clms Page number 19>

différents ordinateurs du réseau peuvent être tour à tour station client U ou station serveur H.

Dans le réseau de communication représenté à la FIG. 1, à titre d'exemple, la station client U peut être l'ordinateur personnel (PC) 4, alors que la station serveur H peut être le serveur 12.

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.

Par exemple, la station serveur peut héberger des images numériques, et un utilisateur peut, à travers la station client U, effectuer des opérations sur l'une des images de la station serveur H.

Les opérations peuvent être la conversion d'une image en noir et blanc, la rotation de l'image ou une symétrie par rapport à un axe horizontal ou vertical de l'image.

Lors d'une exécution à distance d'une telle opération, l'image sera constamment stockée sur la station serveur H et ne transitera pas sur le réseau de communication. La station client se contentera d'émettre une requête d'exécution à distance de l'opération à destination de la station serveur.

On va considérer dans la suite de la description, un système distribué orienté-objet (en anglais"distributed object system"). Un objet informatique est un élément comprenant des données, également appelées attributs, et des fonctions (en anglais"functions"ou"methods") utilisant éventuellement des paramètres ("input arguments"en anglais). Dans un tel système, les fonctions peuvent être appelées ou invoquées (en anglais "invoked') pour manipuler les données de l'objet.

L'ensemble des fonctions applicables à un objet et des attributs constitue son interface.

Dans le cadre du présent exposé, dans un but de simplification de l'expression, lorsque l'on traitera de la partie de l'interface de l'objet qui concerne une fonction particulière appliquée à cet objet, on utilisera le terme "interface de la fonction".

<Desc/Clms Page number 20>

Selon le mode de réalisation décrit ici, de tels objets informatiques, par ex. des images numériques, sont fournis par le serveur 12 (Fig. 1), et les fonctions appliquées à ces objets sont accessibles aux noeuds du réseau IEEE1394 via l'ordinateur (PC) 4. Dans ce but, les autres noeuds du réseau IEEE1394 pourront exécuter ces fonctions en utilisant à distance, sur le bus IEEE1394, l'unité fonctionnelle de l'ordinateur (PC) 4, selon une procédure classique IEEE1394.

En pratique, la station client U, 70, comporte des moyens d'exécution d'un programme 710.

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, 80.

On notera ici que dans le mode de réalisation choisi et décrit ici, la station client U (par ex. le PC 4 de la Fig. 1) exécute à distance une fonction sur un objet stocké sur le serveur (par ex. le serveur 12, Fig. 1). Cependant, on peut prévoir que le code de la fonction et l'objet auquel elle s'applique soient directement stockés sur la station client (Fig. 1, PC 4) ; la station client U (par ex. le PC 4, Fig. 1) faisant alors office de serveur vis-à-vis des autres terminaux connectés sur le bus IEEE1394.

De retour à la FIG. 7, pour mettre en oeuvre cette exécution à distance d'une fonction, la station client U (70) comporte des moyens d'obtention 711 d'un coût d'exécution associé à la fonction f.

Ici, ces moyens d'obtention 711 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 712 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 713 d'une somme d'argent S.

Ces moyens d'obtention 713 coopèrent avec des moyens de stockage de pièces 714 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 21>

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 aux FIGs. 11 à 13.

Enfin, la station client comprend des moyens d'envoi 715 d'une requête d'exécution à distance de la fonction f sur un objet o et du paiement associé à cette fonction.

Corrélativement, la station serveur H (80) comprend des moyens de réception 821 permettant de réceptionner le paiement et la requête d'exécution à distance de la fonction f sur l'objet o.

Des moyens de lecture 822 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 823.

Dans cette mémoire d'interfaces 823, 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 824 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çu peut être réalisée au moyen d'un certificat d'authenticité (ou lettre de change) mémorisé dans une table 825.

Des moyens d'exécution 826 de la fonction f sur l'objet o sont également incorporés dans la station serveur H.

Dans un noeud IEEE1394 tel que représenté à la FIG. 2, L'ensemble des moyens 710-715 relatifs à une station client (70) sont des composants logiciels qui sont mémorisés, selon un mode de réalisation préféré, dans une mémoire ROM (203). Ils pourront toutefois être recopiés en mémoire RAM (208) pour être exécutés par le processeur CPU (204).

En ce qui concerne les moyens 821-826 relatifs à une station serveur (80), dans un noeud IEEE1394 (FIG. 2), ceux-ci sont également des composants logiciels. Dans un mode préféré de réalisation, les moyens 821,

<Desc/Clms Page number 22>

822,824 et 826 sont mémorisés en mémoire ROM (203). Ils pourront toutefois être recopiés en mémoire RAM (208) pour être exécutés par le processeur CPU (204). Les"lettres de changes"825 ainsi que les interfaces 823 sont de préférence mémorisées en mémoire RAM (208). Toutefois, ces éléments (823, 825) peuvent être également mémorisés sur un moyen de stockage d'informations tel qu'un disque dur.

On va décrire à présent en référence aux FIGs. 8 à 12, les procédés de configuration d'une unité fonctionnelle permettant l'exécution d'une fonction ayant un caractère payant, et d'exécution à distance de cette fonction, à partir d'une station client dans un réseau de communication de type IEEE1394.

On souhaite exécuter à titre d'exemple une fonction distante associée à un objet informatique o de la station serveur H.

Chaque objet informatique o étant créé dans un langage de programmation utilisé par l'application informatique propre à l'ordinateur qui héberge l'objet, il est nécessaire d'utiliser un langage de communication commun au réseau de communication afin de partager les objets informatiques.

Sur le réseau Internet on peut utiliser un langage de communication tel que le langage XML ("eXfendec/Marp Langage"en anglais) pour permettre la communication entre la station client et la station serveur.

L'utilisation de ce langage de communication pour représenter des objets informatiques sur le réseau et accéder à leurs fonctions est décrit en détail dans la demande de brevet européen No. 00 401 754.7 déposée au nom de Canon Research Centre France S. A.

Nous rappelons ci-après la description des différents champs de données qu'il est nécessaire de traduire dans le langage de communication du réseau pour permettre d'invoquer à distance des fonctions sur des objets o.

Champ : interfaces
Ce champ permet d'envoyer plusieurs interfaces à des applications distantes.

< interfaces >

<Desc/Clms Page number 23>

< interface > ... < /interface > < /interfaces >
Champ : interface
Ce champ correspond au concept générique d'une classe d'objet, comme défini dans les langages JAVA ou C++.

Une interface décrit les opérations ou fonctions qui sont supportées par un objet informatique o.

Ces fonctions utilisent généralement des paramètres et fournissent éventuellement un résultat.

Une interface décrit également les attributs ou champ de données que tous les objets supportant cette interface contiennent lorsqu'ils sont traduits dans le langage de communication.

Une interface peut également contenir une référence à d'autres interfaces, soit qu'elle s'étende à ces autres interfaces ou fournisse seulement un raccourci (en anglais "short ham !') pour utiliser ces autres interfaces. L'objet supporte alors toutes ces autres interfaces référencées.

Champ : attribut
Ce champ comporte la liste des attributs qu'un objet supportant l'interface contient lorsqu'il est traduit dans le langage de communication.

Champ : functions
Ce champ contient la liste des fonctions associées à l'objet informatique supportant cette interface.

< functions > < function > ... < /function > < /functions >
Champ : function
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

<Desc/Clms Page number 24>

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.

Le champ fonction permet ainsi d'invoquer une fonction sur un objet distant. On doit spécifier l'objet cible 0 et les paramètres de la fonction comme décrit précédemment.

En liaison avec la FIG. 8, on va d'abord décrire le processus de configuration d'une unité fonctionnelle incorporée dans un noeud IEEE1394, afin de pouvoir exécuter une fonction appliquée à un objet dont l'interface est fournie par une station serveur (cette interface est ici également appelée "interface de la fonction").

Dans une première étape E81, on charge dans le terminal considéré l'interface de la fonction (associée à un objet informatique) à exécuter afin de connaître le mode de paiement associé à cette fonction. Cette opération est décrite en détails plus bas en liaison avec la FIG. 9.

Ensuite, on passe à l'étape E83, au cours de laquelle la mémoire de configuration du terminal considéré est mise à jour conformément au standards IEEE1212 et IEEE1394a 2000, avec les informations recueillies lors de l'étape précédente (E81) en utilisant les clés étendues telles que définies plus haut en liaison avec la FIG. 5. Cette mise à jour de la mémoire de configuration du terminal, consiste à créer un nouveau descripteur (unit directory) d'unité fonctionnelle en mémoire de configuration à partir de l'interface chargée correspondant à la fonction distante à exécuter.

Après avoir mis à jour la mémoire de configuration du terminal, on passe à l'étape E85 au cours de laquelle on génère une demande de réinitialisation du BUS (Bus Reset). L'apparition du signal de BUS RESET sur le

<Desc/Clms Page number 25>

bus provoquera la relecture de la mémoire de configuration modifiée, par les noeuds contrôleurs présents sur le réseau IEEE1394.

La FIG. 9 détaille l'étape (E81) de chargement de l'interface d'une fonction ayant un caractère payant, mise en oeuvre lors de l'exécution du processus de configuration de l'unité fonctionnelle, illustré à la FIG. 8.

Comme représenté en FIG. 9, le processus de chargement de l'interface de la fonction à exécuter sur une station client U (FIG. 7,70) comporte tout d'abord une étape de test E811 dans laquelle on vérifie que 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 712 de la station client U.

Dans l'affirmative, c'est-à-dire lorsque l'interface correspondante est connue, la procédure de configuration se termine.

Dans la négative, à l'étape suivante, E813, on exécute un processus en vue de l'obtention de l'interface de la fonction, auprès de la station serveur (H) via le réseau. Dans un premier temps une requête d'obtention de l'interface comprenant l'adresse informatique de l'interface est envoyée au serveur (H).

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 alors, à partir d'une table, retrouver l'interface demandée et la transmettre à la station client U, après éventuellement une traduction de cette interface dans le langage de communication propre au réseau de communication considéré (langage XML dans le mode de réalisation décrit).

Comme décrit précédemment, cette interface comprend une ou plusieurs fonctions associées au code d'exécution de ces fonctions.

Conformément à l'invention, 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.

<Desc/Clms Page number 26>

Cette interface comporte trois fonctions : - I1ConvertToB & W" dont le prix est constant. Cette fonction permet de convertir une image en noir et blanc.

-"Rotate" dont te 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 ://ocean ia/web-obj/class/l mage. xml&num;fl i p&num;price
Cette fonction permet d'appliquer une symétrie à l'image.

< interface name="lmage"

href=http ://oceania/web-obi/class/lmaqe. xml/ > < attributes > < int name="width"price="0. 01 FF"/ > < int name="height"price="0. 01 FF"/ > < string name="encoding"/ > < /attributes > < functions > < function name=lconvertToB & W" price=110. 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 ;

<Desc/Clms Page number 27>

} < /value > < /price > < /function > < function name="flip" > < price > < currency name="FF"/ > < value/ > < /price > < /function > < /functions > < /interface >
Après réception (E813) de l'interface, une étape de mémorisation E815 permet de mémoriser l'interface pour une utilisation ultérieure dans la mémoire cache 712 de la station client.

Une étape de lecture E816 permet de lire dans l'interface reçue l'information de coût c associé à la fonction f que l'on souhaite exécuter.

Ensuite (étape E83, Fig. 8), à partir de l'interface de l'objet considéré, on met à jour la mémoire de configuration de la station client avec l'information de coût extraite de l'interface de l'objet. Ainsi, pour la fonction

"ConvertToB & W", il s'agit d'une clé étendue du type "Coût Fixe" ; pour la fonction "Flip", il s'agit d'une clé étendue du type "Coût ~Serveur'. Enfin pour la fonction"Rotate", il s'agit d'une clé étendue du type "Coût~Expression~Complexe". Cette dernière clé fait référence à trois clés de type"CoûtExpression~Simp/e" puisque le coût d'exécution (price) de la fonction fait appel à trois paramètres distincts :"function price (width, height, angle) ", c. -à-d. la largeur de l'image (width), sa hauteur (height), son angle de rotation (angle).

En liaison avec la FIG. 10 on va maintenant décrire la procédure mise en oeuvre dans un terminal conforme au standard IEEE1394a pour exécuter une fonction présentant un caractère payant. Cette procédure fait suite

<Desc/Clms Page number 28>

aux processus de configuration d'une unité fonctionnelle, et de chargement de l'interface de la fonction, décrits en liaison avec les figures 8 et 9.

Le terminal IEEE1394 considéré peut être un terminal dont une unité fonctionnelle a été configurée selon le processus décrit en liaison avec les FIGs. 8 et 9, par exemple l'ordinateur 4 de la FIG. 1, ou bien un autre terminal sur le bus IEEE1394. Dans ce dernier cas, ce terminal utilise à distance l'unité fonctionnelle du noeud configurée conformément à l'invention. Dans les deux cas, le processus décrit en liaison avec la FIG. 10, est exécuté dans le terminal hébergeant cette unité fonctionnelle. Dans le mode de réalisation illustré à la FIG. 1, il s'agit de l'ordinateur (PC) 4, qui assure par ailleurs le rôle de station client (U) vis-à-vis de la station serveur (H) 12.

En premier lieu, dans une étape E101, on récupère les informations concernant l'interface de cette fonction en analysant la mémoire de configuration locale du terminal client (U) ; l'interface ayant été chargée préalablement, comme décrit plus haut en liaison avec la FIG. 9.

Ensuite, à l'étape E103, on évalue le coût de l'exécution de la fonction. La procédure d'évaluation du coût sera détaillée plus loin en liaison avec la FIG. 11.

Le résultat de cette évaluation étant retourné, on demande, lors du test E105, à un utilisateur humain du terminal client (U) de confirmer la demande d'exécution de la fonction afin d'autoriser le paiement.

Dans la négative, la procédure s'arrête et la fonction requise n'est pas exécutée.

Dans l'affirmative, la procédure continue par l'exécution de la fonction requise (étape E107). Le processus d'exécution de la fonction sera détaillé plus bas en liaison avec la FIG. 12.

En liaison avec la FIG. 11, on va à présent décrire le processus mis en oeuvre dans une station client pour évaluer le coût d'exécution d'une fonction exécutable à distance (FIG. 10, E103).

Comme représenté à la FIG. 11, le processus d'évaluation du coût de la fonction débute par une étape de test E110 dans laquelle on détermine si le coût est une"expression"à calculer, c.-à-d. si le mode de calcul de coût

<Desc/Clms Page number 29>

utilise une clé étendue de type"CoûtExpressionSimpie"ou bien "CoûtExpression~Complexe".

Dans l'affirmative, à l'étape E114, on évalue le coût selon la clé étendue correspondante. Tel est le cas par exemple pour la fonction rotation "rotate".

Dans le cas contraire, on passe à l'étape E112 dans laquelle on

détermine si le coût de la fonction est fixe, c.-à-d. si la clé étendue correspondante est de type"CoûtFixe". Si c'est le cas on applique le coût fixe codé dans la clé"Coût~Fixe"considérée. Tel est le cas par exemple pour la transformation d'une image en noir et blanc.

Dans le cas contraire, il s'agit alors d'un coût déterminé par le serveur (c. -à-d., la clé considérée est de type "coût~serveur"), on passe alors à l'étape E116 dans laquelle une requête à destination du serveur est émise pour obtenir le coût déterminé par celui-ci. Tel est par exemple le cas pour la fonction symétrie "flip".

En liaison avec la FIG. 12, on va maintenant détaillé le processus mis en oeuvre dans une station client pour exécuter à distance une fonction f ayant un caractère payant (détail de l'étape E107, FIG. 10). Comme mentionné précédemment, la station client considérée est par exemple un terminal client U conforme au standard IEEE1394a.

Comme représenté à la FIG. 12, le processus d'exécution commence par l'étape E120 dans laquelle on exécute une procédure d'obtention d'une somme d'argent électronique S supérieure ou égale au coût de la fonction à exécuter (ce coût ayant été préalablement calculé lors du processus d'évaluation décrit ci-dessus en liaison avec la FIG. 11). Cette procédure d'obtention d'une somme d'argent sera détaillée plus loin en liaison avec la FIG. 13.

La station client U génère ensuite dans une étape E121 une requête d'exécution à distance de la fonction f sur un objet informatique o.

Dans le mode de réalisation décrit ici, 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.

<Desc/Clms Page number 30>

Dans ce but, à l'étape E122, on lit dans la table de pièces 714, l'indice de la dernière pièce utilisée.

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 714. Puis, on inscrit (E123) dans la requête d'exécution à distance la valeur (W1+c, i+c).

A l'étape qui suit, E124, on mémorise le nouvel indice i + c correspondant à la dernière pièce utilisée dans la table de pièces 714 pour le serveur H (80).

Ainsi, la requête d'exécution à distance transmise par la station client U (70) lors de l'étape d'envoi qui suit, E125, contient la somme d'argent nécessaire à l'exécution de la fonction demandée sur la station serveur H (80).

Eventuellement, une étape de réception E126 permet de recevoir le résultat de l'exécution de la fonction f sur l'objet o et de retransmettre ce résultat conformément au souhait de l'initiateur de cette requête d'exécution. De cette façon, la fonction peut être exécutée et payée au fur et à mesure de son utilisation. Dans l'exemple donné ici, relatif à la manipulation d'une image numérique, l'utilisateur de la station client U n'est pas obligé d'acheter au préalable un logiciel de traitement d'images. Au contraire, l'utilisateur ne paiera que les fonctions réellement utilisées pour manipuler une image.

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 216 pièces.

Ainsi, certaines fonctions relativement rapides et faciles à exécuter (par exemple la conversion en noir et blanc d'une image de 16 pixels de côté) seront moins coûteuses qu'une opération nettement plus longue et plus complexe (par exemple la rotation de 35 degrés d'une image de 2 048 pixels de côté). La conversion en noir et blanc sera par exemple facturée 1 centime par la station serveur H, tandis que la rotation sera facturée 1 franc.

<Desc/Clms Page number 31>

En liaison maintenant avec la FIG. 13, on va détailler l'étape d'obtention (E120) d'une somme d'argent, effectuée lors de l'exécution du processus d'exécution d'un fonction illustré à la FIG. 12. En d'autres termes, on va décrite un système de génération de monnaie électronique.

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, le système connu sous le nom PayWord, et proposé par Rivest et Shamir.

Une description de ce système peut être consultée à l'adresse Internet http ://theory. lcs. mit. edu/-rivest/RivestShamir-mpay. ps.

Ce système consiste de manière générale, à partir d'un nombre aléatoire Wn, de générer une suite de nombres à l'aide d'une fonction de hachage (en anglais Hash function).

Ce système PayWord présente l'avantage d'être fiable et de ne pas requérir l'approbation d'un organisme tiers (banque, notaire, etc. ) pour valider chaque paiement individuel.

En pratique, on vérifie dans une étape de test E1201 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 E1204. Soit le nombre aléatoire Wn.

On applique ensuite, dans une étape de frappe de pièce E1205, 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.

On obtient ainsi une série de pièces Wn, Won-1,... Ws, Wi, Wn.

L'extrémité Wo de la chaîne de nombres ainsi obtenue est appelée pièce racine (en anglais Roof Coin) et permet de vérifier l'authenticité des différentes pièces.

<Desc/Clms Page number 32>

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 (who) 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.

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, W1,..., Wn générées, ces pièces sont mémorisées dans une étape de mémorisation E1206 dans la table des pièces 714 telle qu'illustrée à la FIG. 7 en association avec un identifiant du 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 714.

En outre, à partir du certificat de banque C (PKe) obtenu de la banque, la station client U génère lors d'une étape de création de lettre de change E1207, un certificat ou lettre de change à destination de la station serveur H.

<Desc/Clms Page number 33>

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 (E1207) d'une lettre de change, cette dernière est envoyée, lors de l'étape E1208 à 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 PKe, 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).

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.

De retour à la FIG. 13, si à l'issue de l'étape de test E1201 le serveur H est déjà connu, on détermine à l'étape E1202 si la table de pièces 714 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 E1203 permet d'effacer les pièces restantes dans la table de pièces 714 et on exécute les

<Desc/Clms Page number 34>

étapes E 1204-1208 décrites précédemment pour générer de nouvelles pièces utilisables sur la station serveur H.

Ainsi, la table de pièces 714 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 E1205 et de stocker celles-ci dans la table de pièces 714 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.

On va décrire à présent, en liaison avec les FIGs. 14 et 15, les traitements exécutés dans une station serveur lors de l'exécution à distance, par une station client, d'une fonction résidant sur le serveur. 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 à l'issue de l'étape E1208 (FIG. 13). La procédure de traitement d'une lettre de change est illustrée à la FIG. 14 ci-après décrite.

Comme représenté à la FIG. 14, la procédure de traitement d'une lettre de change commence par une étape d'obtention (E140) par la station serveur H, auprès d'un organisme de certification, de la clé publique de la banque PKb correspondant à la procédure de signature utilisée par la banque.

Comme mentionné précédemment, une étape de vérification E141 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.

Puis à l'issue de l'étape de test E142, si cette signature est non valide, la procédure est interrompue.

Sinon, si la signature est valide, lors de l'étape E143 qui suit, la clé publique de la station client PKe est lue. Cette clé publique PKe, une fois lue,

<Desc/Clms Page number 35>

permet alors de vérifier, à l'étape E144, la signature de la lettre de change C (who) reçue par le serveur.

Puis on détermine à l'étape E145, si la signature est valide ou non. Si la signature n'est pas valide, la procédure est interrompue.

Sinon, à l'étape E146, on procède à la lecture de l'identité de la station client U (70).

Enfin, lors de l'étape E147, on mémorise la lettre de change dans la table de lettre de change 825 de la station serveur H (80).

En pratique, chaque identifiant de la 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 FIG. 15, le processus de traitement par la station serveur H (80) de la requête d'exécution d'une fonction (f) envoyée par la station client U (70). Le processus de traitement commence par une étape E1501 de réception de la requête d'exécution à distance envoyée par la station client U.

Une étape de test E1502 permet ensuite de vérifier s'il existe une lettre de change dans la table des lettres de change 825 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.

Sinon, une étape de test E1503 permet alors 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 E1504 est effectuée afin de lire le montant mémorisé correspondant ici à une pièce Wj 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 825, on peut obtenir la valeur de la pièce racine Wo dans une étape de lecture E1505.

<Desc/Clms Page number 36>

Une étape de validation E1506 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 (W1)))
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 E1506, appliquer, de manière récursive, i-j fois la fonction de hachage h, c'est-à-dire un nombre de fois juste suffisant pour retrouver une pièce Wj, d'indice j inférieur à l'indice courant i, et déjà 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. 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 (E1506,"oui"), une étape de lecture E1507 est effectuée pour obtenir l'interface de l'objet o à manipuler.

A l'étape suivante, E1508, à partir de la lecture de cette interface stockée sur la station serveur H, on obtient le coût c associé à l'exécution de cette fonction f appliquée à l'objet o. Cette étape d'obtention du coût (E1508) est réalisée comme décrit précédemment en liaison avec la FIG. 11.

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.

<Desc/Clms Page number 37>

Ensuite, une étape de lecture E1509 permet de lire l'indice j de la dernière pièce reçue, et une étape de test E1510 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 E1510 l'égalité suivante : c = i-j 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 éga ! à 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 E1511 permet de mémoriser le nouvel indice i comme indice j de la dernière pièce reçue.

Une étape d'ajout E1512 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 E1513 permet d'exécuter la fonction demandée sur l'objet o.

Une étape de test E1514 permet alors de vérifier s'il existe un résultat à l'issue de l'exécution de cette fonction.

Dans l'affirmative, une étape d'envoi E1515 permet de retourner le résultat à la station client U.

Ainsi, les fonctions étant payées au fur et à mesure de leur exécution, il n'est pas nécessaire pour la station serveur d'ouvrir un compte pour chaque 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.

On peut ainsi exécuter à distance des fonctions rémunérées sur différents objets d'un réseau de communication, sans retarder leur exécution.

<Desc/Clms Page number 38>

On notera ici que le système PayWord n'est qu'un exemple parmi d'autres de monnaie électronique pouvant être générée sur la station client U et dépensée ensuite sur la station serveur H du réseau de communication (réseau IEEE 1394). D'autre part, le langage perfectionné XML utilisé ici peut être remplacé par d'autres systèmes connus tels que CORBA, DCOM ou JAVA/RMI.

Enfin, le procédé d'exécution de fonctions à distance décrit ici peut s'appliquer à des systèmes informatiques autres qu'un système distribué orienté-objet.

En liaison avec la FIG. 16, on va à présent décrire un procédé pour fournir à un utilisateur des informations de configuration d'unités fonctionnelles configurées selon l'invention ; ces unités fonctionnelles étant réparties sur un ensemble de noeuds connectés à un réseau de communication tel que, par exemple, celui représenté et décrit en liaison avec la FIG. 1.

Ce procédé est mis en oeuvre par un noeud contrôleur pour fournir à un utilisateur des informations relatives aux unités fonctionnelles des noeuds supervisés par le contrôleur. A cet effet, le contrôleur utilise une interface utilisateur (portant la référence 205 à la FIG. 2), de type interface graphique, comportant par exemple un écran de visualisation. L'interface utilisateur peut ainsi présenter les informations sous une forme textuelle ou graphique avec utilisation ou non du multi-fenêtrage. Dans le mode de réalisation préféré de l'invention, l'interface graphique utilise le multi-fenêtrage.

Comme représenté à la FIG. 16, le processus d'affichage commence par une étape E160, dans laquelle le contrôleur lit les informations de configuration relatives aux différents noeuds, qui ont été préalablement archivées dans sa mémoire, selon la procédure décrite plus haut, en liaison avec la FIG. 6.

A l'étape suivante, E161, les informations générales concernant un premier terminal sont extraites et affichées à l'écran. A cet effet, une nouvelle fenêtre graphique est créée à l'écran dans laquelle sont affichées les informations générales relatives à ce terminal, permettant notamment à l'utilisateur d'identifier le terminal considéré, et comportant par ex. la liste des unités fonctionnelles incorporées dans le terminal.

<Desc/Clms Page number 39>

A l'étape suivante (E162), on procède à l'affichage des informations concernant une première unité fonctionnelle. A cet effet, une icône est affichée, et les informations détaillées concernant cette unité fonctionnelle (par. ex., port d'entrée, port de sortie, nom, fabricant, performance...) sont accessibles par l'utilisateur, en cliquant par ex. sur l'icône avec une souris ou un autre dispositif de pointage.

L'étape qui suit, E163, est une étape de test, dans laquelle on détermine si cette unité fonctionnelle permet d'exécuter au moins une fonction présentant un caractère payant. Dans la négative, on passe à l'étape suivante (E164).

Inversement, si c'est le cas, une icône additionnelle (représentant par ex. des pièces de monnaie) indiquant ce caractère payant, est affichée (étape E165) sur l'écran, à proximité de l'icône relative à l'unité fonctionnelle considérée. L'utilisateur pourra alors consulter les informations relatives au caractère payant de ou des fonctions exécutables via l'unité considérée, par ex. en cliquant sur l'icône additionnelle.

On passe ensuite à l'étape E164 dans laquelle on détermine s'il existe une autre unité fonctionnelle, concernant le terminal considéré, à afficher.

Si c'est le cas, on retourne à l'étape E162 et le processus recommence comme décrit précédemment.

Dans le cas contraire, on passe à l'étape E166 dans laquelle on détermine s'il existe un autre terminal pour lequel des informations de configuration archivées n'ont pas encore été affichées. Dans l'affirmative, on retourne à l'étape E161 et le processus recommence comme décrit précédemment. Dans la négative, le processus d'affichage est terminé.

Bien entendu, de nombreuses modifications peuvent être apportées aux modes de réalisation décrits ci-dessus sans sortir du cadre de l'invention. En particulier, bien que les modes de réalisation décrits ici s'appliquent au standard IEEE 1394, l'invention s'applique de manière générale à tout autre standard de bus série, dont le mode de communication d'informations est similaire à celui spécifié dans le cadre du standard IEEE 1212.

Claims (18)

1. REVENDICATIONS 1. Procédé de configuration d'une unité fonctionnelle dans un terminal connecté à un premier réseau communication, l'utilisation de ladite unité fonctionnelle provoquant l'exécution sur ledit premier réseau d'au moins une fonction sur un objet informatique, ladite unité fonctionnelle étant configurée conformément à des informations de configuration contenues dans une mémoire de configuration dudit terminal, ledit procédé étant caractérisé en ce qu'il comporte, lorsque ladite au moins une fonction est associée à un coût d'exécution, les étapes suivantes : - obtention (E81, E811-E815) d'une interface dudit objet informatique ; - extraction (E81, E816), de ladite interface, d'une première information relative au coût d'exécution de ladite fonction ; - création (E83) dans ladite mémoire de configuration, à partir de ladite première information extraite de ladite interface, d'une seconde information caractéristique d'un mode de détermination du coût d'exécution de ladite fonction.
2. 2. Procédé selon la revendication 1, caractérisé en ce que l'étape de création d'une seconde information, est suivie d'une étape (E85) de réinitialisation (bus reset) dudit premier réseau.
3. 3 Procédé selon la revendication 1 ou 2, caractérisé en ce que la seconde information est codée dans un ou plusieurs champs de données prédéfinis dans la mémoire de configuration selon un format utilisant un jeu de clés étendues.
4. 4. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que le coût d'exécution d'une fonction, dont le

   <Desc/Clms Page number 41>

   mode de détermination est défini par ladite seconde information, peut être codé selon un jeu de clés étendues, de sorte qu'il peut être : - fixe ; ou, - déterminé par un serveur d'objets informatiques sur le réseau, sur requête dudit terminal ; ou, - calculé en fonction d'un ou plusieurs paramètres prédéfinis, chaque paramètre étant représentatif d'une caractéristique de l'objet informatique auquel s'applique la fonction, ou d'une caractéristique de la fonction, ou d'une caractéristique d'utilisation de l'unité fonctionnelle.
5. 5. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que ledit terminal est relié à un second réseau de communication et l'objet informatique auquel s'applique ladite fonction est hébergé par une station serveur sur ledit second réseau.
6. 6. Procédé selon la revendication 5, caractérisé en ce que l'étape (E81) d'obtention d'une interface dudit objet informatique comprend les sous-étapes suivantes : - détermination (E811) si l'interface est déjà mémorisée dans ledit terminal ; - dans la négative, obtention (E813) de l'interface de ladite station serveur et mémorisation (E815) de l'interface dans ledit terminal.
7. 7. Procédé selon la revendication 5 ou 6, caractérisé en ce que ledit second réseau est le réseau Internet.
8. 8. Procédé selon la revendication 7, caractérisé en ce que l'interface dudit objet informatique est exprimé dans un langage de type XML.
9. 9. Procédé selon l'une quelconque des revendications précédentes caractérisé en ce que ledit premier réseau de communication est un réseau ayant une architecture basée sur au moins un bus série IEEE 1394.

   <Desc/Clms Page number 42>
10. 10. Procédé d'exécution d'une fonction payante à partir d'un terminal dans un réseau de communication, ledit terminal comportant au moins unité fonctionnelle configurée selon un procédé de configuration conforme à l'une quelconque des revendications 1 à 9, ledit procédé d'exécution comportant les étapes suivantes : - extraction (E1 01), de la mémoire de configuration de ladite unité fonctionnelle, d'une seconde information caractéristique d'un mode de détermination du coût d'exécution de ladite fonction ; - détermination (E103) du coût d'exécution de ladite fonction ; - exécution (E107) de la fonction.
11. 11. Procédé de fourniture d'informations de configuration, lesdites informations étant sauvegardées par un noeud contrôleur dans un réseau de communication, lesdites informations de configuration concernant des unités fonctionnelles incorporées dans une pluralité de terminaux connectés audit réseau, lesdites informations ayant été obtenues par un procédé de configuration conforme à l'une quelconque des revendications 1 à 9, ledit procédé de fourniture d'informations comportant les étapes suivantes, mises en oeuvre pour chacun des terminaux : - extraction (E160), de la mémoire dudit noeud contrôleur, des informations de configuration du terminal ; - création (E161) d'une première fenêtre sur un écran de visualisation, dans laquelle sont affichées des informations générales relatives audit terminal, permettant notamment à un utilisateur d'identifier le terminal considéré ainsi que la ou les unités fonctionnelles incorporées dans celui-ci ; - création (E162) dans ladite première fenêtre d'autant de premières icônes distinctes qu'il y a d'unités fonctionnelles dans ledit terminal, les informations spécifiques relatives à une unité fonctionnelle particulière étant accessibles à l'utilisateur en sélectionnant l'icône correspondante au moyen d'un dispositif de sélection adapté ;

    <Desc/Clms Page number 43>

    - pour chaque unité fonctionnelle, détermination (E163) si l'utilisation de l'unité fonctionnelle permet d'exécuter au moins une fonction présentant un caractère payant ; - pour chaque unité fonctionnelle déterminée comme pouvant permettre l'exécution d'au moins une fonction payante, création (E165) d'une icône additionnelle affichée à proximité de la première icône correspondante, ladite icône additionnelle étant indicative du caractère payant d'au moins une fonction exécutable par l'intermédiaire de l'unité fonctionnelle, les informations relatives au coût d'exécution de ladite au moins une fonction étant accessibles à l'utilisateur par la sélection de l'icône additionnelle correspondante au moyen d'un dispositif de sélection adapté.
12. 12. Dispositif de configuration d'une unité fonctionnelle dans un terminal connecté à un réseau communication, l'utilisation de ladite unité fonctionnelle provoquant l'exécution sur le réseau d'au moins une fonction sur un objet informatique, caractérisé en ce qu'il comporte des moyens adaptés à la mise en oeuvre d'un procédé de configuration selon l'une quelconque des revendications 1 à 9.
13. 13. Dispositif d'exécution d'une fonction payante à partir d'un terminal dans un réseau de communication, ledit terminal comportant au moins unité fonctionnelle configurée selon un procédé de configuration conforme à l'une quelconque des revendications 1 à 9, ledit dispositif d'exécution comportant : - des moyens d'extraction de la mémoire de configuration de ladite unité fonctionnelle, d'une seconde information caractéristique d'un mode de détermination du coût d'exécution de ladite fonction ; - des moyens de détermination du coût d'exécution de ladite fonction ; - des moyens d'exécution de la fonction.

    <Desc/Clms Page number 44>
14. 14. Dispositif de fourniture d'informations de configuration, lesdites informations étant sauvegardées par un noeud contrôleur dans un réseau de communication, ledit dispositif étant caractérisé en ce qu'il comporte des moyens adaptés à la mise en oeuvre d'un procédé de fourniture d'informations de configuration selon la revendication 11.
15. 15. Système informatique (20) connecté à un réseau de communication, ledit système informatique comportant : - un processeur (204) pour exécuter des instructions de programme ; - une mémoire de type ROM (203) adaptée à mémoriser des instructions de programme dont l'exécution par ledit processeur (204) permet la mise en oeuvre d'un procédé de configuration d'une unité fonctionnelle selon l'une quelconque des revendications 1 à 9, et/ou d'un procédé d'exécution d'une fonction payante selon la revendication 10, et/ou d'un procédé de fourniture d'informations de configuration selon la revendication 11 ; - au moins une unité fonctionnelle (207) ; - une mémoire (206) de type non volatile et réinscriptible, adaptée à mémoriser des informations de configuration de ladite au moins une unité fonctionnelle (207) ; - une mémoire de type RAM (208) pour mémoriser les variables d'exécution desdites instructions de programme dont l'exécution par ledit processeur (204) permet la mise en oeuvre d'un procédé de configuration d'une unité fonctionnelle selon l'une quelconque des revendications 1 à 9, et/ou d'un procédé d'exécution d'une fonction payante selon la revendication 10, et/ou d'un procédé de fourniture d'informations de configuration selon la revendication 11 ; - des moyens (205) d'interface utilisateur adaptés notamment à la mise en oeuvre d'un procédé de fourniture d'informations de configuration selon la revendication 11.

    <Desc/Clms Page number 45>
16. 16. Réseau de communication comportant au moins un système informatique selon la revendication 15.
17. 17. Programme d'ordinateur, caractérisé en ce qu'il comporte des instructions de programme adaptées à mettre en oeuvre un procédé de configuration d'une unité fonctionnelle selon l'une quelconque des revendications 1 à 9, et/ou un procédé d'exécution d'une fonction payante selon la revendication 10, et/ou un procédé de fourniture d'informations de configuration selon la revendication 11, lorsque ledit programme est chargé et exécuté dans un système informatique.
18. 18. Support d'informations pouvant être lu par un ordinateur, caractérisé en qu'il contient un programme d'ordinateur selon la revendication 17.