FR2868896A1 - Procede et dispositif de controle d'acces a un document numerique partage dans un reseau de communication de type poste a poste - Google Patents

Abstract

Le procédé de contrôle d'accès à une collection de données numériques créée par un poste client est mis en oeuvre sur un poste serveur central (110) dans un réseau de communication de type poste à poste hybride, et comprend les étapes suivantes :E601) recevoir en provenance du poste client (100), une requête de validation d'une collection désignée par un identifiant-collection (302) et comprenant, pour chaque donnée appartenant à la collection, un identifiant-donnée (303) désignant ladite donnée et au moins une représentation (305) choisie de ladite donnée ;E602) pour chaque identifiant-donnée (303) ainsi reçu, obtenir localement une représentation (305) de la donnée associée à ladite collection ; etE603) comparer la représentation (305) ainsi reçue avec la représentation locale et, en cas de comparaison positive, valider ladite donnée numérique à partager.

Description

La présente invention se rapporte au contrôle d'accès à un document

partagé dans un réseau de communication de type poste à poste ou distribué, communément appelé à topologie pair à pair ou peer to peer en anglo-saxon.

Depuis ces dernières années, les réseaux poste à poste sont devenus une alternative aux réseaux client/serveur largement répandus jusqu'à ce jour. En effet, de par leur architecture distribuée, les réseaux poste à poste permettent de partager un nombre important de données numériques entre un grand nombre d'utilisateurs, sans pour autant nécessiter une infrastructure coûteuse.

En pratique, dans un réseau poste à poste, chaque poste joue le rôle de client et de serveur. Ainsi, chaque poste peut demander une donnée ou un document numérique de n'importe quel autre poste du réseau et l'échange de données peut se faire directement d'un poste à un autre.

Par la suite, le terme document ou donnée numérique s'applique à la fois à des images ou des vidéos numériques, ou encore à des fichiers texte numériques ou analogues.

Ainsi, dans un échange de données poste à poste, chaque poste peut être à la fois client et serveur.

Cela signifie que les données numériques reçues par un poste client peuvent ensuite être servies à d'autres utilisateurs par ledit poste client.

Les données numériques accédées par de nombreuses personnes peuvent donc être répliquées sur plusieurs machines et servies par davantage de serveurs.

Le système s'adapte donc tout seul à la demande et les coûts de communication et de stockage sont répartis entre tous les serveurs.

Au contraire, dans un système classique client/serveur, les données sont servies par un seul serveur ou par un ensemble de machines fixé à l'avance.

La capacité de ces serveurs classiques doit être dimensionnée à l'avance, ce qui conduit soit à des surdimensionnements (le coût du serveur est alors trop élevé) soit à des sousdimensionnements (les données ne sont pas servies suffisamment rapidement).

Un autre avantage du système poste à poste est que les données numériques sont servies directement à partir des machines des utilisateurs.

La place de stockage peut donc être considérée en pratique comme illimitée.

Cependant les réseaux poste à poste sont instables. En effet, les dispositifs clients (et par conséquent les dispositifs serveurs) se connectent et se déconnectent périodiquement sur le réseau, rendant ainsi la présence des données très aléatoire. De plus, les adresses des dispositifs clients et/ou serveurs sont imprédictibles et susceptibles d'être différentes à chaque connexion.

II en résulte que l'accès aux contenus dans un réseau de communication de type poste à poste constitue encore une difficulté importante, car la latence pour l'obtention de la donnée n'est plus simplement due au temps nécessaire pour la récupération des données comme dans la topologie client/serveur conventionnelle, mais aussi dans le temps de recherche d'un dispositif serveur disposant de cette donnée. Suivant la topologie du réseau poste à poste concerné, cette phase de recherche peut être non négligeable.

Dans le cadre de l'invention, on se place plus précisément dans le contexte d'un système de communication échangeant des données numériques au moyen de conteneurs numériques de ces données.

Par exemple, les données numériques sont des photographies/images numériques pouvant être représentées en format de stockage hiérarchique de multiples représentations (en termes de résolution et de taille mémoire).

Un conteneur numérique de telles données est par exemple une collection de photographies numériques, c'est-à-dire un conteneur de références vers ces images dont diverses sous parties ou représentations peuvent se retrouver sur différentes machines du réseau.

La plupart des systèmes d'échange de données poste à poste sont destinés à l'échange de données publiques: tout le monde peut accéder à une donnée partagée.

La présente invention s'intéresse préférentiellement à un contexte particulier où les données échangées sont personnelles: il s'agit par exemple d'images ou de vidéos qu'une personne désire partager avec ses amis ou sa famille, c'est-à-dire un nombre restreint d'utilisateurs. Les données ne sont alors pas publiques.

Dans ce contexte, il.est nécessaire d'avoir un système pour restreindre l'accès aux données. Une liste de documents et une liste d'accès associée sont groupées dans la collection. Lors d'un partage, la collection est envoyée à tous les destinataires. Chacun décide d'accepter ou non la collection. Si le destinataire accepte la collection, celle-ci vient compléter la liste d'accès locale de la machine cliente pour chacun des documents contenus. De même pour le créateur de la collection, la nouvelle collection complète les listes d'accès locales.

Le contrôle d'accès aux données depuis les machines clientes repose sur la confiance d'une personne qui partage une donnée personnelle envers un destinataire qui a reçu cette donnée: le serveur du destinataire doit s'acquitter des accès à sa machine et de la validité des demandes en respectant les restrictions proposées par le créateur de la donnée. Cependant, le destinataire peut appliquer une limitation d'accès différente aux données qu'il a reçues.

Un système poste à poste dit hybride a la particularité de comprendre un serveur permanent (appelé encore serveur central) qui peut servir à l'enregistrement des utilisateurs, à la gestion de la connexion des machines clientes de ces utilisateurs.

Dans le but d'accroître la disponibilité des données numériques sur le réseau poste à poste et ainsi favoriser la qualité de service de diffusion, le serveur central peut aussi stocker localement et temporairement des versions limitées de données numériques personnelles.

Le Demandeur s'est posé le problème de fournir un contrôle d'accès ainsi qu'un contrôle du partage et de la diffusion des documents personnels sur le serveur central d'un réseau poste à poste hybride.

La présente invention apporte justement une solution à ce problème.

Elle vise notamment un contrôle d'accès applicable à un serveur permanent (central) de stockage d'un réseau poste à poste hybride et indépendant d'un utilisateur particulier.

Ainsi, elle porte sur un procédé de contrôle d'accès à une collection de données numériques créée par un poste client, le procédé étant mis en oeuvre sur un poste serveur central dans un réseau de communication de type poste à poste hybride.

Selon une définition générale de l'invention, le procédé comprend les étapes suivantes: E601) recevoir en provenance du poste client, une requête de validation d'une collection désignée par un identifiantcollection et comprenant, pour chaque donnée appartenant à la collection, un identifiant-donnée désignant ladite donnée et au moins une représentation choisie de ladite donnée; E602) pour chaque identifiantdonnée ainsi reçu, obtenir localement une représentation de la donnée associée à ladite collection; et E603) comparer la représentation ainsi reçue avec la représentation locale et, en cas de comparaison positive, valider ladite donnée numérique à partager.

Un tel procédé selon l'invention permet ainsi de s'assurer que le poste client émetteur de la requête de validation possède bien toutes les données numériques de la collection à partager sur sa machine et donc qu'il possède bien l'accès à ces données numériques.

Selon une réalisation de l'invention, l'étape E603) de validation est suivie d'une étape E804) de calcul de signature de ladite collection de données numériques, en cas de validation positive de chacune des données numériques appartenant à la collection.

En pratique, l'étape E804) de calcul de la signature de la collection est suivie d'une étape E807) d'envoi de cette signature au poste client.

Ainsi le poste client pourra facilement prouver ultérieurement à tout autre poste client du réseau que la collection qu'il partage est valide.

Selon une autre réalisation, chaque collection de données numériques est stockée localement en réponse à une validation positive de chaque donnée numérique à partager à l'issue de l'étape E603).

De cette manière, le serveur central ne stocke que des collections valides qui peuvent être partagées dans le réseau P2P selon le contrôle des droits d'accès mis en place.

Selon encore une autre réalisation, l'étape E602) d'obtention de la représentation de la donnée associée à la collection comporte les étapes suivantes: a) rechercher localement une version de ladite donnée numérique; b) en cas de recherche positive, obtenir une signature de ladite version de ladite donnée numérique; et c) calculer par une fonction non inversible la représentation de ladite donnée numérique à partir de la signature et de l'identifiant-collection de ladite collection.

En cas de recherche locale négative à l'issue de l'étape a), le procédé comprend en outre l'étape E607) consistant à rechercher une version de la donnée numérique identifiée par un identifiant-donnée sur le réseau, et l'étape E707) consistant à stocker localement ladite version ainsi obtenue depuis un poste client.

Ainsi, le serveur central est assuré de stocker localement des versions des données numériques référencées par les collections en cours de validation. De plus, grâce aux étapes b) et c), le serveur central peut vérifier la présence sur le poste client émetteur de la requête de validation et l'intégrité des versions des données référencées par la collection.

En pratique, le procédé comprend en outre une étape de vérification de l'identité du poste client émetteur de la requête de validation, établie à l'aide d'une fonction d'authentification choisie.

Selon une caractéristique de l'invention, en cas de comparaison négative à l'étape E603), il est prévu les étapes suivantes: 1) vérifier si au moins une représentation choisie de ladite donnée est sous la forme d'un identifiant-collection supplémentaire désignant une collection supplémentaire; 2) obtenir la collection supplémentaire désignée par ledit identifiant- collection supplémentaire, contenant au moins une représentation de ladite donnée numérique désignée par ledit identifiant-donnée; 3) vérifier si ladite collection supplémentaire contient un identifiant- poste client correspondant au poste client émetteur de la requête de validation; et 4) en cas de vérification positive, valider ladite donnée numérique à partager.

En outre, en cas de vérification positive à l'issue de l'étape 3), il est prévu l'étape consistant à obtenir une représentation de ladite donnée associée à ladite collection et l'étape consistant à insérer la représentation de la donnée ainsi obtenue dans la collection.

Selon une caractéristique importante de l'invention, le procédé comprend en outre, préalablement à l'étape E601), les étapes suivantes relatives à la création d'une collection de données numériques sur un poste client destinée à être validée par un poste serveur dans un réseau de communication de type poste à poste hybride: E501) générer un identifiantcollection unique désignant la collection de données numériques à valider et insérer ledit identifiant-collection dans l'en-tête de la collection; E503) obtenir un identifiant-donnée unique pour chaque donnée numérique à référencer dans la collection; E504) obtenir une signature d'une représentation d'au moins une donnée numérique; et E505) insérer dans la collection l'identifiant-donnée et la représentation de chaque donnée numérique associée.

En cas d'obtention négative à l'issue de l'étape E504), il est prévu de rechercher un identifiant-collection correspondant à une collection contenant l'identifiant-donnée et l'identifiant-poste client émetteur de la requête de validation, et substituer la représentation de ladite donnée numérique par l'identifiant-collection ainsi trouvé.

Le document collection destiné à être validé par le serveur central est ainsi créé selon un procédé compatible avec les étapes de validation selon l'invention mises en oeuvre par le serveur central et évoquées ci- dessus.

Selon une autre réalisation, le procédé de contrôle d'accès comprend en outre un procédé de contrôle d'intégrité d'une donnée numérique faisant partie d'une collection de données numériques créée par un poste client distant par un procédé mentionné ci-avant, le procédé de contrôle d'intégrité étant mis en oeuvre sur un autre poste client, dans un réseau de communication de type poste à poste hybride, caractérisé en ce qu'il comprend les étapes suivantes: i) recevoir ladite collection désignée par l'identifiant-collection et comprenant, pour chaque donnée appartenant à la collection, un identifiant-donnée désignant ladite donnée et au moins une représentation choisie de ladite donnée; ii) vérifier la signature de la collection et, en cas de vérification positive; iii) demander au moins une donnée numérique a un poste serveur distant préalablement cherché sur le réseau, à partir des identifiant-donnée et identifiant-collection; iv) recevoir en provenance du poste serveur distant ladite donnée numérique; v) obtenir localement la représentation de la donnée associée à ladite collection, à partir de la donnée numérique reçue et de l'identifiantcollection; vi) comparer ladite représentation obtenue localement avec celle présente dans ladite collection; et vii) en cas de comparaison positive, stocker localement la donnée numérique reçue.

La présente invention a également pour objet un dispositif de contrôle d'accès à une collection de données numériques créée par un poste client appartenant à un réseau de communication de type poste à poste hybride.

Selon une caractéristique importante du dispositif de contrôle d'accès, ledit dispositif comprend: - des moyens pour recevoir, en provenance du poste client, une requête de validation d'une collection désignée par un identifiant-collection et comprenant, pour chaque donnée appartenant à la collection, un identifiant-donnée désignant ladite donnée et au moins une représentation choisie de ladite donnée; - pour chaque identifiant-donnée ainsi reçu, des moyens pour obtenir localement une représentation de la donnée associée à ladite collection; et - des moyens de traitement aptes à comparer la représentation ainsi reçue avec la représentation locale et, en cas de comparaison positive, à valider ladite donnée numérique à partager.

La présente invention a également pour objet un support d'informations lisible par un système informatique, éventuellement totalement ou partiellement amovible, notamment CD-ROM ou support magnétique, tel un disque dur ou une disquette, ou support transmissible, tel un signal électrique ou optique, caractérisé en ce qu'il comporte des instructions d'un programme d'ordinateur permettant la mise en oeuvre d'un procédé de traitement du type décrit ci-dessus, lorsque ce programme est chargé et exécuté par un système informatique.

La présente invention a enfin pour objet un programme d'ordinateur stocké sur un support d'informations, ledit programme comportant des instructions permettant la mise en oeuvre d'un procédé de traitement du type décrit ci-dessus, lorsque ce programme est chargé et exécuté par un système informatique.

D'autres caractéristiques et avantages de l'invention apparaîtront à la lumière de la description détaillée ci-après et des dessins dans lesquels: - la figure 1 représente un dispositif de mise en oeuvre de l'invention; la figure 2 représente schématiquement un dispositif d'un appareil mettant en oeuvre l'invention; - la figure 3 décrit schématiquement une collection; - la figure 4 représente schématiquement un organigramme illustrant le partage d'une collection; - la figure 5 illustre la création d'une collection par le client selon l'invention; - la figure 6 illustre les étapes de réception d'une collection à valider par le serveur central selon l'invention; - la figure 7 illustre les étapes de réception de fichier image par le serveur central selon l'invention; - la figure 8 représente schématiquement les étapes relatives à la réception d'une requête de signature d'une collection par le serveur central selon l'invention; - la figure 9 illustre les étapes relatives à une demande d'accès à une image par un client sur le serveur central selon l'invention; - la figure 10 représente schématiquement une architecture logicielle complète pour le serveur central selon l'invention; et - la figure 11 est un organigramme illustrant le contrôle d'intégrité d'une collection par le client selon l'invention.

La présente invention s'applique à tout document numérique mono ou multi résolution. La description qui suit décrit le procédé de l'invention en s'appuyant sur l'exemple de données multi résolution, mais ceci n'est proposé que dans un souci d'optimisation des ressources qui n'est pas directement relatif à l'invention: en effet, le droit d'accès à un document ou à une sous partie d'un document est géré de la même manière. La description est basée sur un exemple de système optimal où le serveur central ne conserve que des versions basse résolution (faible taille mémoire) des données numériques.

Il est tout à fait envisageable d'utiliser cette invention avec des fichiers numériques divers tels que: - des images numériques fixes dont la représentation basse résolution est une imagette ("thumbnail" en anglais), - de la vidéo (le début d'un flux vidéo peut par exemple représenter

une description minimale de la vidéo complète),

- des fichiers informatiques d'application bureautique (bien souvent, les premiers octets de ces fichiers permettent de connaître le type d'application logicielle requise pour les lire, et ainsi l'utilisateur destinataire du partage peut choisir ceux des fichiers qu'il est apte à visualiser).

Dans un mode privilégié, les données multi résolutions partagées par l'invention sont des images/photographies numériques.

Le système, dont la figure 1 donne une vue d'ensemble, est composé de plusieurs entités connectées en réseau. Le réseau 120 tel que l'Internet permet des communications d'architecture de clients/serveur où chaque poste client 100 accède périodiquement à un poste serveur central 110. Des connexions pair à pair parmi les postes client 100 des utilisateurs sont également effectués pour échanger les données à partager, et ceci indépendamment du serveur. Les utilisateurs se connectent sur le réseau avec des procédés différents: par exemple des modems à haut débit de type DSL, à bas débit, ou câble, mais aussi depuis des postes de téléphonie mobile par exemple de type GSM. Le réseau 120 peut tout aussi bien être un réseau local (LAN) privé. Le serveur central 110 peut aussi être composé de plusieurs serveurs couplés entre eux et accessibles à partir d'une seule adresse réseau.

Les terminaux ou postes client 100 peuvent communiquer directement ou par l'intermédiaire du serveur central 110. Chaque serveur 110 peut par exemple être un dispositif tel que décrit à la figure 2, et comporte en particulier: un dispositif de stockage de données volatiles 160 (on parle de mémoire cache, qui peut contenir des données à durée de vie longue telles que des images, mais aussi des données plus volatiles telles que des listes d'adresses), et une interface homme machine qui permet l'interaction avec un administrateur de ce serveur.

Les terminaux 100 peuvent également être un dispositif tel que décrit à la figure 2, mais aussi un assistant numérique ou un appareil photo ou un téléphone portable. Ces appareils 100 peuvent être connectés à différents périphériques tels que, par exemple une caméra numérique 201 (ou un scanner ou tout moyen d'acquisition ou de stockage d'image) fournissant des données multimédia.

Les appareils informatiques (serveur central) 110 peuvent exécuter une application (logiciel informatique 130) englobant les algorithmes de l'invention. Chaque serveur 110 comprend une interface de visualisation 140 (qui peut correspondre à un navigateur Internet) couplée à un serveur Web 150. Le serveur Web 150 est un serveur classique (tel que Apache ou Microsoft IIS) exécutant des modules logiciels 130 propres à l'invention. Selon une autre possibilité, les logiciel 130 et serveur 150 sont une seule entité. Le serveur central 110 est aussi composé d'un dispositif de stockage tel que un disque dur 160 sur lequel seront stockées les données à conserver temporairement (en particulier les imagettes relatives aux photos numériques à partager), et d'une base de données 180 contenant des identifiants uniques des différentes entités du système global (en particulier les identifiants des utilisateurs, des images).

Le dispositif matériel relatif au serveur central 110 est détaillé en figure 2.

Un appareil mettant en oeuvre l'invention est par exemple un microordinateur 200 ou une station de travail. Cet appareil est connecté à différents périphériques tels que, par exemple tout moyen de stockage d'image reliés à une carte graphique et fournissant à l'appareil des données multimédia.

L'appareil 200 comporte un bus de communication 202 auquel sont reliés: une unité centrale de traitement 203 (microprocesseur), - une mémoire morte 204, pouvant comporter les programmes "Prog" supportant l'invention, - une mémoire vive 206 (mémoire cache), comportant des registres adaptés à enregistrer des variables et paramètres créés et modifiés au cours de l'exécution des programmes précités.

- un écran 208 permettant de visualiser des données et/ou de servir d'interface graphique avec l'administrateur réseau qui pourra interagir avec les programmes selon l'invention, à l'aide d'un clavier 210 ou de tout autre moyen tel qu'un dispositif de pointage, comme par exemple une souris 211 ou un crayon optique, - une interface de communication 218 reliée à un réseau de communication distribué 220, par exemple le réseau Internet, l'interface étant apte à transmettre et à recevoir des données.

L 'appareil peut disposer optionnellement - d'un disque dur 212 pouvant comporter les programmes "Prog" précités, - d'un lecteur de disquette 214 adapté à recevoir une disquette 216 et à y lire ou à y écrire des données traitées ou à traiter selon l'invention, Le bus de communication permet la communication et l'interopérabilité entre les différents éléments inclus dans le micro-ordinateur 200 ou reliés à lui. La représentation du bus n'est pas limitative et, notamment, l'unité centrale est susceptible de communiquer des instructions à tout élément du micro-ordinateur 200 directement ou par l'intermédiaire d'un autre élément du micro-ordinateur 200.

Le code exécutable de chaque programme permettant à l'appareil programmable de mettre en oeuvre les processus selon l'invention, peut être stocké, par exemple, dans le disque dur 212 ou en mémoire morte 204.

Selon une variante, la disquette 216, peut contenir des données ainsi que le code exécutable des programmes précités qui, une fois lu par l'appareil 200, sera stocké dans le disque dur 212.

En seconde variante, le code exécutable des programmes peut être reçu par l'intermédiaire du réseau de communication 220, via l'interface 218, pour être stocké de façon identique à celle décrite précédemment.

Les disquettes 216 peuvent être remplacées par tout support d'information tel que, par exemple, un disque compact (CD-ROM) ou une carte mémoire. De manière générale, un moyen de stockage d'information, lisible par un ordinateur ou par un microprocesseur, intégré ou non à l'appareil, éventuellement amovible, est adapté à mémoriser un ou plusieurs programmes dont l'exécution permet la mise en oeuvre du procédé selon l'invention.

De manière plus générale, le ou les programmes peuvent être chargés dans un des moyens de stockage de l'appareil 200 avant d'être exécutés.

L'unité centrale 203 commande et dirige l'exécution des instructions ou portions de code logiciel du ou des programmes selon l'invention, instructions qui sont stockées dans le disque dur 212 ou dans la mémoire morte 204 ou bien dans les autres éléments de stockage précités. Lors de la mise sous tension, le ou les programmes qui sont stockés dans une mémoire non volatile, par exemple le disque dur 212 ou la mémoire morte 204, sont transférés dans la mémoire vive 206 (RAM) qui contient alors le code exécutable du ou des programmes selon l'invention, ainsi que des registres pour mémoriser les variables et paramètres nécessaires à la mise en oeuvre de l'invention.

II convient de noter que l'appareil de communication comportant le dispositif selon l'invention peut également être un appareil programmé.

Cet appareil contient alors le code du ou des programmes informatiques par exemple figé dans un circuit intégré à application spécifique (ASIC).

En référence à la figure 3, une collection 300 (liste des identifiants des images à partager) est un ensemble de références sur des contenus de médias (image, vidéo, son), avec des meta-données. Par extension, une collection peut contenir des collections (appelées des sous-collections).

Dans la description qui va suivre, on se place dans le cas du partage d'une collection d'images numériques par un système d'archivage dans un réseau de type pair à pair .

Dans ce contexte on appellera - imagette : la version basse résolution d'une image numérique 30 ( thumbnail en anglais) ; et - image : la version haute résolution de cette image numérique.

II est bien entendu que l'invention ne se limite pas à seulement deux résolutions.

Ainsi, par la suite, on nommera comme image multi-résolution aussi bien des images numériques de format multi-résolution (tel que le format JPEG2000 par exemple), que des images numériques mono-résolution (par exemple le format jpeg) : dans ce second cas, la notion de multirésolution est supportée par la construction de fichiers indépendants correspondant à des résolutions différentes obtenues à partir d'un même fichier image haute résolution.

Chaque objet correspondant à une image numérique est identifié par un identifiant-donnée 303, créé sur la machine de l'utilisateur. Cet identifiant-donnée 303 est assigné par l'application cliente même si elle n'est pas connectée sur le réseau. Une solution consiste à produire localement des nombres aléatoires. Optionnellement, ces identifiantsdonnée peuvent être uniques afin de faciliter les recherches sur le réseau. Des outils bien connus de l'homme de l'art permettent de générer des identifiants-donnée avec une infime probabilité de duplication.

Des images seront de même définies par un identifiant-donnée 303 par l'application du client dès qu'une nouvelle image est ajoutée à une collection (si l'image est copiée depuis une collection existante, elle conservera l'identifiant-donnée original). Cependant, une imagette a le même identifiant-donnée qu'une image. Afin de déterminer de manière précise un objet (image ou imagette), l'identifiant-donnée 303 doit être associé à un typage de donnée: la plupart du temps, ce typage est implicite selon les requêtes envoyées sur le réseau (en cas de téléchargement, l'image est demandée alors que l'imagette est utile pour une visualisation simple).

Chaque utilisateur a aussi un identifiant-utilisateur unique 304 fournipar le serveur central pendant le procédé d'enregistrement de l'utilisateur. Cette propriété est utile pour réduire au minimum le risque d'enregistrements multiples pour le même utilisateur. Dans le mode de réalisation préféré, en achetant le logiciel client, l'acheteur enregistre son logiciel et établit avec le serveur central un compte qui identifie cet utilisateur. Ce compte identifié par l'identifiant- utilisateur 304, sert à la fois pour une connexion du client par le logiciel standard ou par un navigateur Internet.

Dans le mode de réalisation préféré décrit ici, une collection 300 comporte: - d'une part, un en-tête 300H, comportant un titre de collection 301, un identifiant-collection 302 de la collection et un identifiant-utilisateur 304 correspondant à l'auteur de la collection. Une signature 306 permettant de vérifier que la collection a bien été créée par l'auteur 304 et a été validée par le serveur central 110 conformément au procédé de l'invention peut être ajoutée.

La signature 306 est fabriquée sur le serveur central 110 avec la propre clé de chiffrement privée dudit serveur central. Pour valider une signature 306, le client 100 peut soit disposer de la clé publique correspondant à la clé privée qui a servi à signer la collection (dans ce cas il peut décrypter la signature et compare la valeur obtenue avec son propre calcul de signature de la collection) ou bien il peut faire appel au serveur central 110 pour valider la signature 206. La création de la signature 304 sera décrite ultérieurement. D'autres métadonnées peuvent être ajoutées telles que la date de création...

- d'autre part, un corps 300B, comportant une liste d'identifiants-donnée 303 des objets numériques de cette collection. A chaque identifiantdonnée 303 est associé une représentation 305 unique (par exemple appelée ici hash) pour la collection courante 300 calculée selon un procédé décrit plus loin en référence à la figure 5. Il n'y a pas de représentation 305 pour une sous-collection ayant un identifiant- collection 302. La collection contient aussi une liste de distribution (liste d'utilisateurs identifiés par les identifiants-utilisateur 304 autorisés à visualiser la collection).

La création d'une collection sans droit d'accès par un utilisateur n'est pas le propos de l'invention. II existe des procédés bien connus de l'état de l'art qui ont trait aux images et à leur association à des conteneurs d'images. Par exemple, l'utilisateur peut copier une image depuis l'interface graphique du système d'exploitation de son ordinateur et la déposer dans l'interface graphique 140 du logiciel informatique mettant en oeuvre l'invention. L'utilisateur peut structurer ses images, collections et sous-collections de manière à finalement enregistrer chaque collection 300 créée sous forme d'une liste d'identifiants d'images, de sous-collections. Chaque collection peut éventuellement comprendre une ou plusieurs meta-données de faible taille mémoire, par exemple une imagette représentative de la totalité de la collection.

Une représentation physique d'une collection peut par exemple consister en un codage en langage XML: <?xml version="1.0" encoding="utf-8"?> <COLLECTION COLLECTION ID-'12c946lec-Odf2-7b4a-9ffO-d17cdca229a7"> 10 <COLLECTION METADATA> _ <TITLE VALUE="my collection"/> <CREATOR UID="a782e3f6-8fb5-9646-abc5-5cac76c099c4"/> <ACCESS RESTRICTED="TRUE"> <RECIPIENT UID="5bca700e-3320-3f49-9d79-efe702336366"/> <RECIPIENT EMAILHASH="narre@company.com"/> </ACCESS> <SUGNATURE VALUE=""/> <COLLECTION METADATA> <IMG CONTENT ID="fO92cefa-ad7f-0a43-9266-c60c7a4lb621">

_

<METADATA> <CAPTION VALUE="my_first_image.jpg"/> <HASH VALUE=""/> </METADATA> </IMG> </COLLECTION> La figure 4 présente le scénario de partage d'une collection entre une application cliente exécutée sur une machine 100 et les algorithmes de l'invention exécutés sur le serveur central 110.

Un utilisateur crée une collection Cl avec des destinataires (étape E410 décrite en référence à la figure 5). Cette collection Cl est ensuite envoyée au serveur central 110 dans un message 401. Ce message est par exemple formaté en langage de balisage XML tel que SOAP, et transporté par le protocole de communication HTTP dans une requête de type POST.

En réponse à cette requête de validation 401, le serveur central 110 valide la collection conformément à l'étape E420 dont les sous étapes sont décrites en référence à la figure 6. Le cas échéant, le serveur central recherche les imagettes qu'il lui manque localement.

Une suite de messages 402 s'en suit afin d'envoyer sur le serveur central 110 les imagettes demandées (étape E425). Ces messages sont par exemple des messages HTTP PUT. Chaque message comporte une référence 302 à la collection Cl, l'identifiant-donnée 303 de l'imagette et l'imagette elle-même.

L'étape de réception des fichiers imagettes (étape E430) consiste à valider I es données reçues (figure 7).

En pratique, il s'agit de vérifier les droits d'accès pour chaque fichier reçu et de les stocker dans le cache local.

Lorsque toutes les imagettes ont été transmises par le poste client 100, celui-ci peut alors demander qu'on lui crée une signature 306 pour la collection Cl (étape E435). Le message 403 (du même type que 401) sert alors de support de communication pour obtenir la signature 306 depuis le serveur central 110. Le poste client 100 peut ainsi mettre à jour le champ signature 306 de la collection Cl et envoyer la collection Cl aux destinataires inscrits dans les champs d'identifiants-utilisateur 304 de la collection Cl. Une alternative consiste pour le poste client 100 à envoyer une simple notification aux destinataires indiquant que la collection Cl est maintenant disponible aussi sur le serveur central.

L'étape E440 relative à la vérification de la présence de tous les fichiers images dans le cache local et à la création et envoi de la signature de la collection, et exécutée par le serveur 110 est décrite en référence à la figure 8.

La figure 5 montre les étapes de la création d'une collection Cl.

Dans une première étape E501, les entêtes de la collection sont créés: l'utilisateur rentre un titre, l'identifiant 304 de l'auteur, la date de création sont remplis. Un nouvel identifiant de collection 302 est créé.

L'utilisateur sélectionne ensuite une liste d'images. II peut s'agir 25 d'images se trouvant dans des collections déjà partagées ou des images nouvelles de l'utilisateur (étape E502).

Pour chaque image (étape E504), le client obtient (étape E503) un identifiant-donnée 303: il peut s'agir de l'identifiant de l'image dans la collection où elle a été sélectionnée ou d'un nouvel identifiant s'il s'agit d'une nouvelle image. Un nouvel identifiant peut être créé en prenant par exemple un nombre aléatoire avec une taille suffisante pour avoir une très faible probabilité d'obtenir plusieurs fois le même identifiant.

L'identifiant-donnée 303 de chaque image est ajouté à la nouvelle collection.

Pour chaque image, on doit créer une représentation 305 unique pour la collection courante. Deux types de représentation 305 sont envisagés, en fonction de la possibilité d'obtenir localement ou pas une version de l'image courante.

Dans le cas où une version de l'image traitée est présente localement, on peut tout d'abord créer une représentation sous la forme d'une signature d'une version de l'image. Il est préférable d'utiliser une version de faible taille de l'image afin de conserver des performances acceptables lors du traitement. Par exemple, la signature est un checksum de l'imagette ou une signature obtenue par un algorithme de hachage connu dans l'état de l'art (e.g. MD5) appliqué sur l'imagette. L'important est que cette signature soit créée à partir d'une donnée physique de l'image que seul un possesseur de cette image peut obtenir (e.g. l'identifiantdonnée 303 n'est pas suffisant car des utilisateurs mal intentionnés pourraient inventer des identifiants d'images sans disposer de ces images afin de les récupérer frauduleusement).

Ensuite, à partir du résultat précédent associé à l'identifiantcollection 302 de la collection 300 courante, on calcule une seconde signature par un algorithme de hachage connu de l'état de l'art (e.g. MD5) .

Cette seconde signature est la représentation 305 qui est unique pour une image dans une collection, car elle dépend à la fois d'une signature d'une version de l'image et de l'identifiant-collection. On évite ainsi la copie par des pirates des éléments 305 dans de nouvelles collections leur accordant tous les droits d'accès: ces éléments 305 sont uniquement valides dans une seule collection. De plus, l'utilisation d'une fonction de hachage qui est non-inversible ne permet pas à un éventuel pirate de retrouver la signature d'une version de l'image même en connaissance de la représentation 305 et de l'identifiant-collection 302.

Cette représentation 305 servira au serveur central 110 pour vérifier les droits d'accès du partageur à échanger les images concernées, mais aussi par la suite, pour tout système client pair, à vérifier que les imagettes que ledit système pair reçoit sont valides (voir figure 11 plus loin).

En variante, on peut créer et ajouter dans la collection une représentation 305 distincte pour chaque résolution de l'image: en effet, suivant le type d'image utilisé, l'imagette n'est pas forcément une représentation unique que l'on peut obtenir à partir de n'importe quelle résolution de l'image, et alors seule peut être contrôlée l'authenticité de l'imagette et de la version d'image à partir de laquelle l'imagette a été créée. Dans ce cas, afin d'éviter de télécharger plusieurs résolutions d'une même image, le serveur central peut décider de se limiter (comme décrit par la suite) à valider le contenu d'une collection en regard d'une seule représentation 305 (par exemple celle issue de l'imagette créée avec la version haute résolution de l'image): on fait confiance au partageur pour le bon déroulement du calcul des autres représentations 305 insérées dans la collection.

Dans le cas où aucune représentation de l'image à partager n'est présente localement, il est possible de remplacer la représentation 305 de la collection par un identifiant-collection 302 d'une autre collection, appelée encore collection supplémentaire, qui atteste du droit d'accès de la personne à utiliser l'image. En effet, il peut y avoir certains cas où le poste client 100 ne dispose pas localement des images qu'il est autorisé à voir: - le poste client 100 a été notifié de la disponibilité d'une collection, mais ne l'a pas forcément complètement visualisée: toutes les imagettes n'ont pas encore été chargées, - la nouvelle collection a été créée à partir d'un ancienne collection 25 en mode déconnecté du réseau: pas d'imagette présente, - il peut y avoir eu effacement du cache local des images de la machine 100...

L'identifiant-donnée 303 et la représentation 305 obtenus par l'une ou l'autre des méthodes décrites ci-dessus sont alors ajoutés à la collection 30 conformément à l'étape E505.

L'utilisateur donne ensuite des destinataires (étape E506) : il peut sélectionner des personnes dans son carnet d'adresse ou entrer de nouveaux noms. S'il a sélectionné un nom dans le carnet d'adresse l'identifiant-utilisateur 304 de l'utilisateur est connu et est ajouté à la liste des destinataires de la collection (étape E507).

Si l'utilisateur rentre un nouveau nom, le système interroge alors le serveur central pour obtenir des informations sur le destinataire. Si le destinataire est une personne enregistrée dans le système, le serveur central lui a attribué un identificateur 304 qui peut alors être renvoyé au poste client 100 avec toutes les informations associées. Le poste client 100 peut alors ajouter le nom dans le carnet d'adresse. Le nouvel identifiant-utilisateur 304 peut ensuite être ajouté à la liste des destinataires de la collection.

Si le nom n'est pas connu sur le serveur central, il ne peut pas être choisi comme destinataire.

Conformément à l'étape E508, la collection ainsi créée est envoyée au serveur central 110. Cette collection est appelée collection temporaire car elle pourra être modifiée par la suite, notamment en y incluant la signature donnée par le serveur après validation, et éventuellement les représentations 305 calculées à partir des versions des imagettes qui font défaut à la machine cliente au moment du partage (voir figure 8).

En référence à la figure 6, on a décrit le fonctionnement du logiciel 130 exécuté sur le serveur central 110, lorsqu'un poste client 100 requiert un partage de collection 300 et envoie ladite collection au serveur central (étape E601) pour validation.

En pratique, la requête de validation comprend, pour chaque donnée appartenant à la collection 302, un identifiant-donnée 303 désignant ladite donnée et au moins une représentation 305 choisie de ladite donnée.

Par exemple, la connexion au serveur central est soumise à une authentification de l'utilisateur (paramètre jeton d'identification ou user_token ) afin de s'assurer de la légalité de la procédure de partage. Cette authentification peut se faire aussi bien par un client Web (connexion sécurisée par SSL) que par un client possédant l'application logicielle pair à pair (messages SOAP sécurisés): à partir d'une paire {nom_d'_utilisateur, mot_de_passe}, le serveur central authentifie la personne et envoie en réponse un ticket ( token en anglais) comportant une date limite de validité et attestant de l'identité de cette personne. Ce ticket peut être envoyé sous la forme d'un message ou cookie pour une connexion Web et/ou dans une réponse de type SOAP à l'application logicielle d'un pair.

En analysant la collection reçue (étape E602), le serveur central 110 est capable de connaître quelles sont les nouvelles images à partir de son cache de données 160. Le serveur central 110 mettra en oeuvre l'une des méthode de validation des données référencées dans la collection en fonction, d'une part, de la présence des imagettes référencées dans la collection dans son cache 160 et d'autre part selon le type de représentation 305 associé à chaque imagette.

Si une imagette référencée dans la collection par son identifiant-donnée 303 est présente dans le cache 160, il s'agit d'une image destinée à être partagée à nouveau par l'utilisateur: les droits d'accès peuvent donc être vérifiés. On distingue alors deux cas de figure selon le type de représentation 305.

Cas 1 a: la représentation 305 associée à l'identifiant donnée est une signature. Dans ce cas, une reconstruction de la représentation 305 à partir de l'imagette 303 présente dans le cache 160 du serveur central 110 et l'identifiant de la collection 302 est effectuée pour chaque identifiant-donnée 303, en appliquant les mêmes étapes que le client lors de la création de la collection, décrites ci-dessus en référence à la figures. Cette représentation 305 est comparée avec la représentation 305 inscrite dans la collection reçue. Un résultat de comparaison positive valide le fait que l'utilisateur possède toutes les images connues présentes sur sa machine 100 (et donc le fait qu'il possède l'accès à ces images).

- Cas 1 b: pour certaines images de la collection, la représentation 305 choisie est un identifiant-collection 302 d'une autre collection, appelée encore collection supplémentaire, qui atteste du droit d'accès de la personne à utiliser l'image.

Dans ce cas, le serveur 110 valide les droits d'accès à partir de la collection connue (collection supplémentaire) et met alors localement à jour la nouvelle collection en re-créant une représentation 305 représentative d'une signature MD5 (même algorithme que le client, décrit en référence à la figure 5) ou en récupérant la signature de l'imagette préalablement conservée afin de ne pas la calculer de multiples fois (voir ci-après cas 2a).

Si des imagettes référencées par l'identifiant-donnée 303 dans la collection ne sont pas présentes dans le cache 160, le système doit vérifier si les images sont nouvelles. Pour ceci, le serveur conserve la liste des identifiants d'images 303 qu'il a reçue en provenance des clients: ceci permet d'éviter qu'un même identifiant-donnée 303 soit utilisé pour plusieurs images de manière involontaire (les identifiantsdonnée sont créés aléatoirement par les clients) ou de manière frauduleuse (une personne cherche à remplacer une image ancienne qui a expiré du cache 160 du serveur central). Cette liste d'identifiants- donnée 303 utilisés dans le réseau peut être enregistrée dans une table de la base de donnée 180, mais aussi bien dans une zone de la mémoire 160 du serveur (cette zone pourra être architecturée de façon à optimiser les recherches des identifiants). On peut à nouveau distinguer deux cas: Cas 2a: si des identifiants-donnée 303 sont trouvés dans cette liste, le cas 1 b précédent s'applique. En option, la liste des identifiants-donnée 303 peut conserver aussi le résultat de l'opération effectuée sur l'imagette (checksum ou hachage MD5), au quel cas, le cas la peut s'appliquer après calcul de la signature appliqué sur la signature de l'imagette connue localement associée à l'identifiant-collection spécifique à la collection en cours de validation. . Cas 2b: si des identifiants-donnée 303 ne sont pas trouvés dans cette liste, les images correspondantes sont considérées comme nouvelles et la validation complète de la collection interviendra une fois que le serveur central aura reçu l'ensemble des imagettes référencées par la collection (étape E440, détaillée en référence à la figure 8). Cette validation complète comprendra l'ensemble des calculs nécessaires pour obtenir la représentation 305 associée à chaque imagette et la comparaison du résultat avec la représentation 305 stockée dans la collection reçue.

En cas de vérification positive à l'égard de la validité de la collection (étape E603), le procédé passe à l'étape E604, sinon un message d'erreur est envoyé (étape E608).

Conformément à l'étape E604, la collection reçue (éventuellement mise à jour avec les représentations 305 calculées par le serveur central) ainsi validée est conservée dans une zone temporaire du cache 160 afin d'être signée (validation complète) quand toutes les imagettes sont reçues et validées.

Le poste client est ensuite informé de la procédure à suivre pour conclure la validation de la collection: soit télécharger les imagettes manquantes localement (étape E607) à l'issue d'une étape de vérification indiquant des images dans la collection qui ne sont pas dans le cache local (étape E605, cas 2b ci-dessus), soit directement demander une signature de la collection si toutes les imagettes sont déjà présentes dans le cache (étape E606).

En référence à la figure 7, on a décrit le fonctionnement du logiciel 130 exécuté sur le serveur central 110, lorsqu'un poste client 100 envoie un fichier image suite à un partage de collection 300.

L'utilisateur relatif à la machine cliente 100 est authentifié (le 20 paramètre user token de la requête est contrôlé en terme de contenu et de date d'expiration) (étape E702).

En cas d'authentification négative, le procédé recommence avec une nouvelle tentative d'authentification (étape E709).

La collection concernée est localisée dans la zone temporaire du 25 cache 160 (étape E704).

Si l'image est déjà présente, on ne la remplace pas et la procédure s'achève (étape E708).

Sinon, il y a vérification que l'auteur de la collection 304 est bien celui qui envoie l'image (étape E706).

L'image reçue (en l'occurrence une imagette pour les besoins du partage) est enregistrée dans le cache 160 (étape E707).

En référence à la figure 8, on a décrit le fonctionnement du logiciel 130 exécuté sur le serveur central 110, lorsqu'un poste client 100 demande la validation de la collection 300 partagée (étape E801).

Une condition nécessaire est que toutes les imagettes soient présentes dans le cache 160 du serveur central (étape E802).

Dans la négative, un message d'erreur indique qu'il manque des fichiers (étape E808) et on peut retourner à l'étape E607 pour demander les images manquantes.

Si la validation n'avait pas été terminée à l'étape E420 correspondant à la figure 6, le test de validation (calcul de la représentation 305 à partir de l'imagette et de l'identifiant-collection) est reconduit (étape E803) pour les images reçues à l'étape E430. En variante, ce test de validation est directement effectué pour chaque image par l'algorithme décrit en référence à la figure 7 lorsqu'une version d'image est téléchargée sur le serveur, afin de supprimer aussitôt toute image reçue qui serait corrompue.

Après avoir validé la collection (vérification de la liste des images et la liste des destinataires), il convient de calculer une signature 306 pour la collection (étape E804). La signature 306 peut être calculée par un système classique de signature à clé publique: on calcule une empreinte des données à signer (l'auteur, la liste des images 303 et des représentations 305, et la liste des destinataires 304) par un algorithme tel que MD5 puis cette empreinte est encryptée avec la clé privée du serveur central par RSA.

La signature 306 ainsi calculée est insérée dans la collection (étape E805).

La collection ainsi obtenue et validée est définitive, et peut être alors déplacée dans une zone permanente du cache 160 du serveur central 110 (étape E806).

La signature (et éventuellement les mises à jour effectuées dans la collection) est alors renvoyée à l'auteur de la collection (étape E807).

Tous les systèmes postes 100 sont aptes à demander la clé publique du serveur central afin de contrôler les collections qu'ils ont reçu.

Ainsi, avec cette clé, les postes clients 100 obtiennent l'empreinte certifiée de la collection et peuvent la comparer avec une empreinte créée à partir de la collection reçue: si la comparaison est identique, la collection est authentifiée.

De même, les postes clients 100 peuvent ensuite authentifier les images qu'ils recevront à partir de la collection. Les différentes versions des images sont fixées et il est très aisé d'obtenir une imagette à partir d'une version de l'image. Cette imagette correspondant à une image reçue par le réseau peut être utilisée, conjointement avec l'identifiantcollection 302, dans le même algorithme que celui du partage afin de calculer la représentation de type 305, laquelle devrait être identique à la valeur 305 inscrite dans la collection.

En référence à la figure 9, on a décrit les étapes lors de la réception d'une demande de servir une image identifiée par l'identifiant-donnée 303 appartenant à la collection 302 (étape E901).

La première étape consiste à valider l'identité de l'émetteur de la requête (étape E902), exprimée par un jeton d'identification de l'utilisateur ( user_token ).

Un identifiant-collection 302 de collection est inclus dans la demande d'image.

Si le jeton d'identification est non valide, le procédé recommence une autre tentative d'authentification (étape E907).

Si le jeton est valide (étape E902), le procédé passe à l'étape E903. Lors de l'étape E903, on obtient l'identifiant-utilisateur 304 à partir du jeton.

Puis on vérifie si l'image ayant l'identifiant-donnée 303 fait partie de la liste des images de la collection et si le demandeur 304 fait partie de la liste des destinataires (étape E904).

Si la collection locale 302 n'autorise pas le demandeur 304 à obtenir l'image, la requête est refusée (étape E906).

Dans l'affirmative, la requête d'accès à l'image 303 est autorisée (étape E905).

En référence à la figure 10, on a décrit un exemple d'architecture du logiciel 130 basé au dessus d'un serveur Web.

L'architecture proposée a pour but d'offrir un serveur central 110 le plus léger possible, afin de limiter son coût d'exploitation.

La base de données 180 contient les informations nécessaires à la gestion des utilisateurs et de leurs profils (un utilisateur a enregistré au moins une application logicielle cliente depuis un poste client 100). Elle contient également les données plus dynamiques relatives à la connectivité des pairs: un client peut obtenir les informations de connexion (adresse IP, port, accès à travers firewall ou pare-feu) d'un autre client identifié par une identifiant unique. La base de donnée ne contient aucune indication de la localisation des données sur le réseau: cette gestion est considérée comme totalement distribuée sur le réseau et ne fait pas partie de l'invention.

La mémoire cache 160 contient les collections partagées et des versions des images associées. De préférence, seules les imagettes et une version intermédiaire de faible résolution sont disponibles sur le serveur. Une politique de gestion de cache simple est implémentée de telle façon que la durée de vie des collections est bien plus importante que celle des imagettes, qui est elle même supérieure à celle des moyennes résolutions. Par exemple, une collection peut être conservée plusieurs mois ou années, les imagettes plusieurs mois et les versions intermédiaires quelques semaines. A un même niveau de résolution d'image, une politique peut être appliquée afin de comptabiliser le nombre d'accès à une image et de conserver plus longuement les images fortement demandées. De plus, le serveur central (ainsi que les pairs) peuvent servir les images pour des utilisateurs ne disposant pas de machine cliente 100 mais de simples navigateurs Web: de tels accès ne favorisent pas la réplication des données sur le réseau pair à pair et peuvent être considérés dans la politique de cache.

Le serveur central 110 est le premier point d'entrée des pairs sur le réseau. Une fois un pair connecté, les communications peuvent s'effectuer en poste à poste avec d'autres pairs connectés. Le serveur central sera le plus souvent interrogé par la suite pour des demandes d'informations de connectivité des machines et pour la validation du partage de collection. Le téléchargement d'images depuis ce serveur 110 pour une nouvelle collection va décroître au fur et à mesure de la réplication des données sur les pairs.

La structuration du logiciel 130 se décompose en plusieurs modules 10A à 10E: - un module d'authentification 10A est responsable d'enregistrer les utilisateurs pour utiliser le réseau pair à pair et aussi de fournir une clé d'authentification à chaque fois qu'un utilisateur enregistré se connecte sur le réseau. Chaque utilisateur a un identifiant-client 304 unique.

- un module 10B spécialisé dans les accès "web-services" (e.g. requêtes SOAP au dessus de HTTP) est le point d'entrée privilégié pour les communications internes au réseau pair à pair. C'est ce module qui prend en charge les algorithmes des figures 6 et 8. Des accès à la base de données sont requis pour mettre à jour les tables de connexion des pairs, renseigner des pairs sur la présence des pairs amis...

- les modules 10C et 10D offrent un accès Web pour les images, et peuvent créer dynamiquement des pages html pour les clients ne disposant que de simples navigateurs Internet à la place de systèmes clients 100.

- le module 10E est en charge d'authentifier les utilisateurs qui effectuent des requêtes en dehors des connexions sécurisées SSL. Par exemple, un cookie peut être utilisé pour transporter un jetond'identification d'un utilisateur.

Le module 10D fournit l'accès aux collections et aux images du cache 160 pour les machines clientes 100 et pour des accès à partir de navigateurs Web. Il supporte les algorithmes des figures 7 et 9. Dans le souci d'améliorer les performances en temps de réaction du service des images, ce module 10D ne contient aucune liaison avec la base de donnée, mais interagit directement avec les données du disque dur, ce pour quoi est optimisé un serveur Web.

Le module 10C complète le précédent en cas de problème (e.g. une image est manquante), et permet de résoudre les résolutions des localisations des images à partir des collections présentes dans le cache et des informations de présence des machines dans la base de donnée.

Le principe d'authentification des utilisateurs est le suivant: L'émetteur demande un jeton auprès du serveur central à travers une connexion sécurisée SSL par le module 10A. Celui-ci vérifie son identité en lui demandant un mot de passe. II peut ensuite lui donner un jeton créé avec la clé privée du serveur central qui encode l'identité 304 de l'émetteur. Le jeton sert à tout serveur sur le réseau (100 ou 110) qui reçoit une requête pour ainsi valider l'identité en décodant le jeton grâce à la clé publique du serveur central.

Ce jeton peut être construit comme ceci: Signature [clé privée du central serveur] ( user_id 304, adresse IP, date) L'adresse IP correspond à l'adresse visible sur le réseau de la machine sur lequel l'utilisateur se connecte.

La date est une limitation de la durée de vie de ce jeton.

En référence à la figure 11, on a décrit les étapes effectuées par un poste client 100 du réseau pair à pair à l'issue du partage d'une collection d'images, validée par le serveur central.

Le poste client 100 disposant de l'application pair à pair a reçu une notification de la présence d'une nouvelle collection qui lui est destinée. Cette notification peut être réalisée à partir d'un système de messagerie interne au réseau pair à pair, ou externe tel que messagerie électronique de type email. Suite à cette notification, le poste client 100 reçoit la collection partagée ou connaît une localisation sur le réseau (par exemple le serveur central) où récupérer cette collection (étape E101).

A la réception de la collection, le poste client doit vérifier la validité de cette collection grâce au champ 306 de la collection, qui a été décrypté avec la clé publique du serveur central (étape E102).

Si la validation est correcte, la collection est conservée et l'utilisateur peut alors choisir des images à visualiser. Pour chaque image sélectionnée par l'utilisateur (étape E103), une recherche sur le réseau peut être effectuée par des moyens connus de l'état de l'art (étape E104). A la réception de toute version d'une image, le poste client doit vérifier l'intégrité des données reçues depuis un poste serveur quelconque du réseau et sans doute inconnu du poste client 100 (étape E105).

Pour cela, le poste client 100 met en application les algorithmes présentés à la figure 5 pour calculer la représentation 305 à partir de l'image 5 reçue du réseau et de l'identifiant 302 de la collection courante.

En pratique, la représentation 305 est calculée à partir de l'identifiantcollection 302 et de l'identifiant-donnée 303 de l'image ainsi reçus (étape E106).

Selon l'étape E107, si cette première représentation 305 ainsi calculée est identique à une seconde représentation 305 présente dans la collection courante d'identification-collection 302, alors l'image reçue est reconnue comme authentique. Dans ce cas, elle est conservée localement (étape E108). Sinon, le poste client essaie de chercher d'autres postes serveurs du réseau proposant des versions non modifiées de l'image désirée.

Claims (15)

REVENDICATIONS

1. Procédé de contrôle d'accès à une collection de données numériques créée par un poste client, ledit procédé étant mis en oeuvre sur un poste serveur central (110) dans un réseau de communication de type poste à poste hybride, caractérisé en ce qu'il comprend les étapes suivantes: E601) recevoir en provenance du poste client (100), une requête de validation d'une collection désignée par un identifiant-collection (302) et comprenant, pour chaque donnée appartenant à la collection, un identifiant-donnée (303) désignant ladite donnée et au moins une représentation (305) choisie de ladite donnée; E602) pour chaque identifiant-donnée (303) ainsi reçu, obtenir localement une représentation (305) de la donnée associée à ladite collection; et E603) comparer la représentation (305) ainsi reçue avec la représentation locale et, en cas de comparaison positive, valider ladite donnée numérique à partager.

2. Procédé selon la revendication 1, caractérisé en ce que l'étape E603) de validation est suivie d'une étape E804) de calcul de signature (306) de ladite collection de données numériques, en cas de validation positive de chacune des données numériques appartenant à la collection.

3. Procédé selon la revendication 1 ou la revendication 2, caractérisé en ce que l'étape E804) de calcul de la signature (306) de la collection est suivie d'une étape E807) d'envoi de cette signature au poste client (100).

4. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce qu'il comporte en outre une étape E604) de stockage local de chaque collection de données numériques en réponse à une validation positive de chaque donnée numérique à partager à l'issue de l'étape E603).

5. Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce que l'étape E602) d'obtention de la représentation de la donnée associée à la collection comporte les étapes suivantes: a) rechercher localement une version de ladite donnée numérique 303; b) en cas de recherche locale positive, obtenir une signature (306) de ladite version de ladite donnée numérique; et c) calculer par une fonction non inversible la représentation (305) de ladite donnée numérique à partir de la signature (306) et de l'identifiant-collection (302) de ladite collection.

6. Procédé selon la revendication 5, caractérisé en ce qu'en cas de recherche locale négative à l'issue de l'étape a), le procédé comprend en outre les étapes suivantes: E607) rechercher une version de la donnée numérique identifiée par un identifiant-donnée (303) sur le réseau; et E707) stocker localement ladite version ainsi obtenue depuis un poste client (100).

7. Procédé selon l'une quelconque des revendications 1 à 6, caractérisé en ce qu'il comprend en outre une étape de vérification de l'identité (304) du poste client émetteur de la requête de validation, établie à l'aide d'une fonction d'authentification choisie.

8. Procédé selon la revendication 1, caractérisé en ce qu'en cas de comparaison négative à l'étape E603), il est prévu les étapes suivantes: 1) vérifier si au moins une représentation (305) choisie de ladite donnée est sous la forme d'un identifiant-collection supplémentaire (302) désignant une collection supplémentaire; 2) obtenir la collection supplémentaire désignée par ledit identifiant- collection supplémentaire (302), contenant au moins une représentation (305) de ladite donnée numérique désignée par ledit identifiant-donnée (303) ; 3) vérifier si ladite collection supplémentaire contient un identifiant- poste client (304) correspondant au poste client émetteur de la requête de validation; et 4) en cas de vérification positive, valider ladite donnée numérique à partager.

9. Procédé selon la revendication 8, caractérisé en ce qu'en cas de vérification positive à l'issue de l'étape 3), il est prévu une étape consistant à obtenir une représentation (305) de ladite donnée associée à ladite collection (302) et une étape consistant à insérer la représentation (305) de la donnée ainsi obtenue dans la collection (302).

10. Procédé selon l'une quelconque des revendications 1 à 9, caractérisé en ce qu'il comprend en outre, préalablement à l'étape E601), les étapes suivantes relatives à la création d'une collection de données numériques sur un poste client destinée à être validée par un poste serveur dans un réseau de communication de type poste à poste hybride: E501) générer un identifiant-collection (302) unique désignant la collection de données numériques à valider et insérer ledit identifiant-collection (302) dans l'en-tête de la collection; E503) obtenir un identifiant-donnée (303) unique pour chaque 25 donnée numérique à référencer dans la collection; E504) obtenir une signature (306) d'une représentation (305) d'au moins une donnée numérique (303) ; et E505) insérer dans la collection l'identifiant-donnée (303) et la représentation (305) de chaque donnée numérique associée.

11. Procédé selon la revendication 10, caractérisé en ce qu'en cas d'obtention négative à l'issue de l'étape E504), il est prévu de rechercher un identifiant-collection (302) correspondant à une collection contenant l'identifiant-donnée (303) et l'identifiant-poste client (304) émetteur de la requête de validation, et substituer la représentation (305) de ladite donnée numérique par l'identifiant-collection (302) ainsi trouvé.

12. Dispositif de contrôle d'accès à une collection de données numériques créée par un poste client (100) appartenant à un réseau de communication de type poste à poste hybride, caractérisé en ce que ledit dispositif comprend: - des moyens pour recevoir, en provenance du poste client (100), une requête de validation d'une collection désignée par un identifiantcollection (302) et comprenant, pour chaque donnée appartenant à la collection, un identifiant-donnée (303) désignant ladite donnée et au moins une représentation (305) choisie de ladite donnée; - pour chaque identifiant-donnée (303) ainsi reçu, des moyens pour obtenir localement une représentation (305) de la donnée associée à ladite collection; et des moyens de traitement aptes à comparer la représentation (305) ainsi reçue avec la représentation (305) locale et, en cas de comparaison 20 positive, à valider ladite donnée numérique à partager.

13. Dispositif selon la revendication 12, caractérisé en ce que les moyens de traitement sont aptes à mettre en oeuvre les étapes du procédé selon les revendications 1 à 11.

14. Support d'informations lisible par un système informatique, éventuellement totalement ou partiellement amovible, notamment CD-ROM ou support magnétique, tel un disque dur ou une disquette, ou support transmissible, tel un signal électrique ou optique, caractérisé en ce qu'il comporte des instructions d'un programme d'ordinateur permettant la mise en oeuvre d'un procédé selon les revendications 1 à 11, lorsque ce programme est chargé et exécuté par un système informatique.

15. Programme d'ordinateur stocké sur un support d'informations, ledit programme comportant des instructions permettant la mise en oeuvre d'un procédé selon les revendications 1 à 11, lorsque ce programme est chargé et exécuté par un système informatique.