FR2864283A1 - Procede et dispositif de controle d'acces a un document partage dans une reseau de communication poste a poste - Google Patents

Abstract

Le procédé d'accès comprend les étapes suivantes :i) recevoir une requête émanant d'un utilisateur pour accéder à au moins un document numérique, ladite requête comprenant un identifiant (303) désignant le document numérique et un identifiant (304) désignant ledit utilisateur ;ii) rechercher localement au moins une collection (C1) contenant l'identifiant (303) du document et l'identifiant (304) de l'utilisateur, chaque collection (C1, C2) étant stockée localement en réponse à une vérification positive à l'égard d'au moins une condition d'acceptation de servir le document selon au moins un droit d'accès lié à la collection ; etiii) en cas de recherche positive, servir ledit document (303) correspondant audit utilisateur (304) ainsi désigné.

Description

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

partagé dans un réseau de communication du 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 part 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 à partir 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 textes numériques ou analogues.

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

Cela signifie que les données numériques reçues par un client peuvent être servies à d'autres utilisateurs par le serveur de ce 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 sous-dimensionnements (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, des dispositifs clients (et par conséquent des dispositifs serveurs) se connectent ou 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.

Il en résulte que l'accès au contenu 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.

Pour remédier à ces inconvénients, une solution connue consiste à utiliser un serveur central qui garantit un minimum de qualité de service. On parle alors de réseaux poste à poste hybrides.

De manière connue, partager une donnée numérique à travers un réseau de communication poste à poste hybride consiste à la succession des 25 étapes suivantes: - sélectionner le document à partager; - associer un identifiant unique permettant de retrouver la localisation du document dans le réseau; - calculer une vignette à partir de la donnée originale; mettre à jour une table d'index au niveau du serveur central en associant un identifiant du document partagé à un (ou plusieurs) poste(s), chacun de ces postes étant serveur pour ce document.

Cette succession d'étapes connues est utilisée dans la plupart des réseaux poste à poste pour partager un document avec une communauté d'utilisateurs, c'est à dire que quiconque peut accéder à ce document partagé du moment que cette personne connaît l'identifiant. On parle alors de partage public.

A l'opposé, on peut partager un document avec un groupe d'amis et restreindre l'accès de ce document à ce groupe d'amis. On parle alors de partage à accès restreint (partage privé).

Dans ce cas, le partage privé d'un document nécessite deux étapes supplémentaires: - sélection des destinataires; et - notification envoyée à chacun de ces destinataires de manière à les informer qu'un nouveau document est susceptible d'être partagé.

En pratique, la présente invention trouve une application préférée mais non limitative dans un réseau de communication distribué hybride à partage restreint.

A la différence des systèmes client/serveur classiques, la donnée partagée dans un réseau poste à poste est disponible sur plusieurs serveurs, ce qui augmente le risque d'opérations malveillantes à l'égard de l'accès à cette donnée ainsi partagée.

II est donc nécessaire de mettre en place un contrôle d'accès adapté au partage de cette donnée sur chaque serveur.

En pratique, chaque serveur est une machine appartenant à un utilisateur qui doit pouvoir totalement contrôler ce qui se passe sur sa machine.

Par exemple, un utilisateur doit pouvoir vérifier ce qui est stocké localement. Il doit pouvoir aussi restreindre l'accès à une donnée sur sa machine ou au contraire la partager avec d'autres utilisateurs.

La mise en place d'un tel mécanisme de contrôle d'accès restreint le nombre de serveurs qui acceptent de servir une donnée à un utilisateur, ce qui 30 est contraire au principal avantage du système poste à poste où une donnée très recherchée peut être servie par de nombreux serveurs.

Le Demandeur s'est posé le problème de fournir un contrôle d'accès adapté au partage d'un document dans un réseau poste à poste qui ne diminue pas de manière trop importante le nombre de serveurs disponibles pour un utilisateur tout en étant relativement efficace, peu onéreux et simple à mettre en place.

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

Elle porte sur un procédé d'accès à un document numérique dans un réseau de communication, en particulier du type poste à poste, apte à échanger des données sous forme de collections, une collection comprenant au moins un identifiant désignant un document numérique et au moins un identifiant désignant un utilisateur ayant le droit d'accéder aux documents de cette collection, ledit procédé étant mis en oeuvre dans un poste.

Selon une définition générale de l'invention, le procédé comprend les étapes suivantes: i) recevoir une requête émanant d'un utilisateur pour accéder à au moins un document numérique, ladite requête comprenant un identifiant désignant le document numérique et un identifiant désignant ledit utilisateur; ii) rechercher localement au moins une collection contenant l'identifiant du document et l'identifiant de l'utilisateur, chaque collection étant stockée localement en réponse à une vérification positive à l'égard d'au moins une condition d'acceptation de servir le document selon au moins un droit d'accès lié à la collection; et iii) en cas de recherche positive, servir ledit document correspondant audit utilisateur ainsi désigné.

Un tel procédé de contrôle d'accès a l'avantage d'être relativement efficace, peu onéreux, et simple à mettre en place, par rapport à des solutions consistant par exemple à mémoriser sur le serveur central tous les droits d'accès à chaque document.

De plus, le procédé selon l'invention confère à l'utilisateur la possibilité de contrôler l'accès à sa machine.

Selon une réalisation, le procédé comporte, en cas de recherche négative à l'issue de l'étape ii) l'étape suivante: iii) obtenir au moins une collection contenant ledit identifiant du document ainsi que l'identifiant de l'utilisateur et stocker localement ladite collection ainsi obtenue si la condition d'acceptation de servir est validée.

En pratique, le procédé comprend en outre une étape il) de vérification de l'identité de l'émetteur de la requête d'accès, établie à l'aide d'une fonction d'authentification choisie.

De plus, il est également pratique d'associer à la requête pour accéder à un document numérique un identifiant de collection comprenant l'identifiant du document demandé. Ceci permettra d'accélérer la vérification locale de l'acceptation de service.

Selon une autre réalisation, l'étape i) est précédée par les étapes suivantes: a) créer chaque collection en désignant chaque document numérique à partager par un identifiant et en attribuant à chaque utilisateur destinataire un droit d'accès formé par un identifiant dudit utilisateur destinataire; b) former une notification contenant ladite collection ainsi créée; et c) envoyer ladite notification ainsi formée à destination d'au moins un utilisateur destinataire.

En pratique, la réception d'une notification est suivie d'une étape d'authentification de chaque collection ainsi reçue selon une fonction d'authentification choisie.

En cas d'authentification négative de la collection, il est prévu de détruire la collection ainsi reçue.

En cas d'authentification positive de la collection, il est prévu de vérifier le droit d'accès associé à la condition d'acceptation de servir le document et en cas de vérification positive de stocker localement ladite collection ainsi reçue.

Selon une autre réalisation, en cas de droit d'accès invalide, le procédé comprend en outre les étapes suivantes pour chaque document de la collection: 1) chercher localement la présence d'une autre collection contenant au moins l'identifiant d'un document appartenant à la collection ainsi reçue, 2) en présence d'une autre collection contenant au moins l'identifiant d'un document appartenant à la collection ainsi reçue, vérifier la validité du droit d'accès associé à la condition d'acceptation de servir le document de ladite autre collection; et 3) en cas de validité dudit droit d'accès, stocker localement la collection ainsi reçue.

En pratique, en cas d'échec de l'étape 3), le procédé comprend en outre une visualisation de la collection et en cas de validation manuelle de la collection, le stockage local de ladite collection.

Selon un autre aspect de l'invention, le document numérique appartient au groupe formé par des images ou photographies fixes, séquences vidéo, fichiers informatiques d'application bureautique ou analogue.

Par exemple, le droit d'accès lié à la collection est relatif à l'auteur de la collection et à l'appartenance dudit auteur à une liste choisie d'utilisateurs dits amis, le droit d'accès étant valide lorsque l'auteur de la collection appartient à une telle liste d'amis.

La présente invention a également pour objet un dispositif d'accès à un document numérique dans un réseau de communication, en particulier du type poste à poste, apte à échanger des données sous forme de collections, une collection comprenant au moins un identifiant désignant un document numérique et au moins un identifiant désignant un utilisateur ayant le droit d'accéder aux documents de cette collection, ledit dispositif étant incorporé dans un poste.

Selon une autre caractéristique importante de l'invention le dispositif 25 d'accès comprend: - des moyens pour recevoir une requête émanant d'un utilisateur pour accéder à au moins un document numérique, ladite requête comprenant un identifiant désignant le document numérique et un identifiant désignant ledit utilisateur; - des moyens pour rechercher localement au moins une collection contenant l'identifiant du document et l'identifiant de l'utilisateur, chaque collection étant stockée localement en réponse à une vérification positive à l'égard d'au moins une condition d'acceptation de servir le document selon au moins un droit d'accès lié à la collection; et - des moyens pour servir, en cas de recherche positive, ledit document correspondant audit utilisateur ainsi désigné.

La présente invention a également pour objet un système d'accès à un document numérique, dans un réseau de communication, en particulier de type poste à poste, caractérisé en ce qu'il comporte un dispositif d'accès incorporant le dispositif mentionné ci-avant.

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 mentionné ci-avant, 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 mentionné ci-avant, 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 des dessins dans lesquels: la figure 1 représente schématiquement un réseau distribué 25 d'échange de données poste à poste; - la figure 2 représente schématiquement un appareil mettant en oeuvre le procédé d'accès selon l'invention; - la figure 3 représente schématiquement une collection; - la figure 4 illustre la visualisation d'une collection dans une interface graphique; - la figure 5 représente schématiquement les données mémorisées chez un poste client selon l'invention; - la figure 6 illustre schématiquement les étapes de la création d'une collection selon l'invention; - la figure 7 illustre schématiquement les étapes de la réception et d'acceptation d'une collection selon l'invention; - la figure 8 illustre schématiquement les étapes d'une requête d'accès à une image selon l'invention; - la figure 9 illustre un partage simple selon l'invention; - la figure 10 illustre un envoi à plusieurs destinataires selon l'invention; - la figure 11 illustre un envoi de plusieurs collections selon l'invention; - la figure 12 illustre un scénario de renvoi d'images reçues à d'autres destinataires selon l'invention; et - la figure 13 illustre un scénario d'autorisation d'accès de type amis d'amis selon l'invention.

En référence à la figure 1, on a représenté de manière schématique un réseau distribué d'échanges de données 1 du type pair à pair . Un tel réseau 1 comporte un ensemble de terminaux 2, chaque terminal 2 étant relié au réseau 3 (Internet) et ayant des moyens de communication. Chaque terminal 2 peut être par exemple un dispositif tel que décrit à la figure 2, et comporte en particulier: une mémoire de stockage volatile (cache) 4, un serveur de fichiers 5 et une interface homme/machine 6 qui permet la communication des requêtes 7 de l'utilisateur et des réponses 8 auxdites requêtes 7. Les terminaux 2 peuvent communiquer directement par l'intermédiaire du réseau global 3. De manière optionnelle, on peut disposer d'un serveur central 10, auquel sont connectés tous les terminaux 2 du réseau de distribution, qui est connecté en permanence et qui stocke un ensemble de données sur le système d'échange terminal à terminal: information de présence de chacun des terminaux identifiés comme faisant partie du réseau, éventuellement informations sur les contenus (e.g. les images) qui se trouvent stockées localement sur chaque poste. Le serveur central 10 peut servir aussi à authentifier les utilisateurs qui se connectent.

En référence à la figure 2, on a représenté un dispositif d'accès 200 apte à mettre en oeuvre l'invention. Un tel appareil 200 est par exemple un micro-ordinateur, une station de travail, un assistant numérique, un appareil photo ou un téléphone portable. L'appareil 200 est connecté à 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) reliée à 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", "Prog 1 " et "Prog2" ; - 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 15 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'utilisateur 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; et - 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.

Dans le cas de données audio, l'appareil comprend en outre une 25 carte d'entrée/sortie (non représentée) reliée à un microphone 222. L 'appareil peut disposer optionnellement: - d'un disque dur 212 pouvant comporter les programmes "Prog", "Prog1" et "Prog2" précités, - d'un lecteur de disquette 214 adapté à recevoir une disquette 216 30 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 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 pourra ê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 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 pourront être chargés dans un des moyens de stockage de l'appareil 200 avant d'être exécutés.

L'unité centrale 203 va commander et diriger 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 contiendra 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.

Il 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, on a représenté une collection 300 comportant un ensemble de contenu de médias (image, vidéo, son) avec des metadonnées. Par extension, une collection peut contenir des collections (appelées des sous-collections). Dans le mode de réalisation préféré, le média utilisé est constitué d'images numériques.

A titre d'exemple, une collection 300 comporte: - d'une part un en-tête 300H comportant un titre 301, un identifiant 302 de la collection, un identifiant de l'auteur de la collection 305 et une signature 306; et d'autre part, un corps 300B comportant une liste d'identifiants 303 des images numériques de cette collection et une liste d'identifiants d'utilisateurs 304.

Chaque objet correspondant à une image numérique ou à une collection est identifié par un identifiant unique 302, créé sur la machine de l'utilisateur. Cet identifiant est assigné par l'application cliente, même si non connectée sur le réseau.

Une solution connue consiste à produire localement des nombres uniques aléatoires. Des outils bien connus de l'homme de l'art permettent de générer des identifiants avec une infime probabilité de duplication.

De même, des images sont définies par un identifiant unique 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 conserve l'identifiant d'origine).

En pratique, une imagette a le même identifiant qu'une image. Afin de déterminer de manière unique un objet (image ou imagette), l'identifiant 303 doit être associé à un "typage" ou version 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 unique 304 fourni par le serveur central 10 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 un logiciel applicatif de partage poste à poste, l'utilisateur acheteur enregistre son logiciel et établit avec le serveur central 10 un compte qui identifie cet utilisateur. Ce compte identifié par l'identifiant ID 304, sert à la fois pour une connexion du client par le logiciel standard ou par un navigateur Internet.

La création d'une collection par un utilisateur n'est pas le propos de la présente invention. Il 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 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 et d'utilisateurs. En pratique, on peut par exemple utiliser le format de description de données XML. 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 collection contient aussi l'identifiant 305 de l'auteur de la collection et une signature 306 permettant de vérifier que la collection a bien été créée par l'auteur 305. Cette signature 306 peut être créée de plusieurs manières suivant le type de système.

Par exemple, si chaque utilisateur possède une clé publique et une clé privée, la signature 306 peut être fabriquée de manière classique sur la machine de l'auteur avec sa clé privée. On peut par exemple calculer un résumé de la collection avec un algorithme classique de signature du type hash , par exemple l'algorithme MD5 , et l'encrypter avec la clé privée.

Selon un autre exemple, on peut utiliser le serveur central 10 pour signer la collection: dans ce cas seul le serveur central 10 a besoin d'avoir une clé. La signature est fabriquée sur le serveur central 10 avec sa clé.

En pratique, pour valider une signature 306, un client peut disposer de la clé publique correspondant à la clé qui a servi à signer la collection. Dans ce cas, il peut décrypter la signature 306 et comparer la valeur obtenue avec son propre calcul du hachage (hash) de la collection. En variante, il peut faire appel au serveur central 10 pour valider la signature.

En référence à la figure 4, on a représenté la visualisation d'un fichier collection 300 par un utilisateur dans une interface graphique. Par analogie avec un courrier électronique, l'auteur 305 est affiché dans un champ P1 from et les destinataires dans des champs P2 to . Le nom affiché n'est pas forcément l'identifiant unique 305, ce peut être un nom d'affichage associé à l'enregistrement. Un nom d'affichage peut être par exemple une adresse email de l'utilisateur. Le titre 301 de la collection est également affiché en correspondance au champ P3. Pour chaque image incluse dans la collection 300, une imagette T est affichée. En cliquant sur l'imagette T l'utilisateur peut afficher l'image complète.

Tous les éléments composant le fichier collection ne sont pas affichés: certains éléments ne sont utilisés que pour s'assurer de la cohérence de la collection: la signature de la collection, ou l'identifiant de collection.

En référence à la figure 5, on a représenté l'ensemble des données mémorisées dans la mémoire de stockage (disque dur 212) d'un poste client.

Un client ou utilisateur stocke des images et des collections dans le système de fichier. Les fichiers d'images et de collection doivent pouvoir être retrouvés à partir de l'identifiant 302 ou 303 correspondant, il est donc prévu une table 212A associant l'identifiant unique 302 ou 303 dans le réseau au nom du fichier NF local. Un enregistrement dans la table des fichiers 212A est créé lorsqu'un fichier est reçu du réseau et sauvegardé localement. La table 212A contient en outre une information V relative à la version du fichier.

Une deuxième table 212B est prévue pour contenir un carnet d'adresses. Un tel carnet d'adresses permet de mémoriser l'ensemble des personnes du système connues par le client. Un enregistrement dans la table 212B contient un indicateur 12 correspondant à l'identifiant unique 304 de la personne connue, un indicateur Il correspondant au nom d'affichage, un indicateur 14 correspondant à la clé publique (si elle existe), et un indicateur 13 pour indiquer si ce contact est un ami. Dans le contexte de cette invention, un ami est un utilisateur du système qui a un rôle privilégié dans la définition des droits d'accès aux données, comme expliqué plus loin en référence aux figures 7et8.

Une troisième table 212C permet de mémoriser pour chaque image désignée par un identifiant 303 la liste des collections désignées par un identifiant 302 contenant ladite image.

En référence à la figure 6, on a représenté les étapes illustrant la création d'une collection (E600).

Lors de l'étape E601, les en-têtes 300H de la collection sont créés:l'utilisateur rentre un titre 301, l'identifiant de l'auteur 305, et la date de création. Un nouvel identifiant 302 de collection est créé.

L'utilisateur sélectionne ensuite une liste d'images (étape E602). Il peut s'agir d'images se trouvant dans des collections ou des images nouvelles de l'utilisateur.

Pour chaque image, le client obtient un identifiant 303 (étape E603). 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 de chaque image est ajouté à la nouvelle collection (étape E604).

L'utilisateur donne ensuite des destinataires (étape E605). II peut sélectionner des personnes dans le carnet d'adresses 212B (étape E606) ou entrer de nouveaux noms (étape E608). S'il a sélectionné un nom dans le carnet d'adresses 212B l'identifiant de l'utilisateur est connu et est ajouté à la liste des destinataires de la collection.

Si l'utilisateur rentre un nouveau nom, le système interroge alors le serveur central 10 pour obtenir des informations sur le destinataire (étape E607). Si le destinataire est une personne enregistrée dans le système, le serveur central 10 lui a attribué un identifiant 304 qui peut alors être renvoyé au client avec toutes les informations associées: nom I1, clé publique 14. Le client peut alors ajouter le nom dans le carnet d'adresses 212B. Le système demande à l'utilisateur si le destinataire est un ami. Le nouvel identifiant d'utilisateur 304 peut ensuite être ajouté à la liste des destinataires de la collection.

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

Après avoir créé la liste des images et la liste des destinataires, il est possible de calculer une signature (étape E610). La signature peut être calculée par un système classique de signature à clé publique dans lequel on calcule une empreinte des données à signer (l'auteur, la liste des images et la liste des destinataires) par un algorithme tel que MD5 puis dans lequel on chiffre cette empreinte avec la clé privée de l'auteur par une fonction d'authentification de type RSA par exemple. Dans une variante, la signature peut être calculée par le serveur central. La collection est alors envoyée au serveur central qui authentifie la personne ayant envoyé la collection et calcule une signature. La signature est ensuite renvoyée à l'auteur de la collection.

Le fichier collection peut alors être mémorisé (étape E611). Cette étape E611 consiste à sauvegarder la nouvelle collection dans un fichier.

L'identifiant et le nom de fichier sont sauvegardés dans la table des fichiers 212A. La table des images 212C est mise à jour pour chaque image incluse dans la collection: l'identifiant 302 de la collection est associé à l'identifiant 303 de chaque image. Pour les nouvelles images, la table des fichiers 212A est mise à jour avec le chemin de l'image d'origine, l'identifiant 303 de l'image et la version V. Enfin un message est envoyé à chaque destinataire pour l'informer de la nouvelle collection (étape E612).

En référence à la figure 7, on a représenté les étapes de la réception d'une nouvelle collection Cl (étape E700) par un utilisateur 304.

En premier lieu, lors de l'étape E701, il est prévu d'établir une fonction d'authentification à l'égard de la collection ainsi reçue.

Par exemple, la signature (306) associée à la collection est vérifiée. Pour cela le système lit l'identité 305 de l'auteur de la collection. Si cet auteur est dans le carnet d'adresses 212B on peut y obtenir sa clé publique 14. Sinon la clé publique est demandée au serveur central 10. Cette clé est utilisée pour valider la signature (306) associée à la collection de la manière suivante: la signature est décryptée et comparée à l'empreinte de la collection reçue, si ces deux données sont identiques la signature associée à la collection est validée. En variante la collection Cl peut être envoyée au serveur central 10 pour qu'il valide la signature. Une autre variante consiste à utiliser la clé publique du serveur central 10 pour valider la signature.

Si la signature (306) associée à la collection est invalide la collection Cl est refusée et n'est pas mémorisée (étape E702).

Si la signature (306) associée à la collection est valide, le système vérifie si l'auteur de la collection désigné par son identifiant 305 est un ami (étape E703). En d'autres termes, le système vérifie si l'auteur désigné par son identifiant 305 appartient au carnet d'adresses 212B avec un indicateur 13 correspondant au critère ami valide. En cas de critère 13 valide, la collection Cl peut être acceptée et le fichier collection mémorisé (étape E704).

Si l'auteur désigné par l'identifiant 305 n'est pas un ami (critère 13 non valide), le procédé peut continuer le mécanisme de contrôle d'accès en vérifiant si l'auteur de la collection Cl désigné par l'identifiant 305 est autorisé à accéder à toutes les images de la collection Cl selon au moins une collection C2 déjà acceptée localement (étape E705).

Pour cela, le procédé vérifie pour chaque image désignée par son identifiant 303 de la collection Cl s'il existe au moins une collection C2 locale, qui contient l'image correspondante et qui autorise l'auteur désigné par l'identifiant 305 (étape E706), c'est-à-dire soit l'auteur 305 est l'auteur de la collection C2, soit l'auteur 305 fait partie de la liste des destinataires de la collection C2 (étape E707).

Si le résultat de l'étape E707 est positif pour chaque image de la collection Cl, alors la collection Cl peut être acceptée et mémorisée (étape E704).

Si la collection Cl n'est pas encore acceptée, le système vérifie (étape E708) si l'utilisateur local 304 se trouve dans la liste des destinataires de la collection C2. Si ce n'est pas le cas la collection Cl est refusée (étape E702). Un tel test est notamment utile pour vérifier si l'utilisateur est apte à obtenir une représentation graphique pour que l'utilisateur puisse valider la collection Cl.

Si l'utilisateur fait partie de la liste des destinataires, le système demande (étape E709) alors à l'utilisateur de valider manuellement la collection Cl. La collection Cl est présentée graphiquement à l'utilisateur qui peut l'accepter ou la refuser.

S'il la refuse, la collection est détruite. S'il l'accepte le système peut demander (étape E710) si l'auteur désigné par son identifiant 305 doit être ajouté dans le carnet d'adresses 212B et si c'est un ami (indicateur 13 à l'état valide), puis la collection est mémorisée.

La sauvegarde de la collection Cl met à jour les tables 212A, 212B 20 et 212C associées de la même manière que dans le cas de la création d'une nouvelle collection telle que décrite en référence à la figure 6.

L'utilisateur peut à tout moment demander à visualiser une collection mémorisée. Dans ce cas une représentation graphique de la collection lui est présentée. Une vignette est présentée pour chaque image de la collection. Si la vignette n'est pas disponible localement, le système la recherche dans le réseau. Par exemple le client peut envoyer des demandes d'accès à l'image aux clients connus. Si l'un des clients accepte de servir la donnée telle que décrite en référence à la figure 8, la nouvelle donnée est mémorisée dans un fichier local, les tables 212A, 212B et 212C sont alors mises à jour: le nouveau fichier est mis dans la table des fichiers 212A avec l'identifiant 303 de l'image et la version V. Si ensuite l'utilisateur demande à visualiser la version d'origine d'une donnée de la collection, si cette donnée n'est pas disponible localement alors la donnée est recherchée dans le réseau et si elle est trouvée elle est téléchargée et mémorisée: les tables 212a à 212C sont mises à jour ce qui permettra de servir cette donnée si un autre client la demande.

En référence à la figure 8, on a décrit les étapes de la réception d'une demande de servir une image désignée selon son identifiant 303 (étape E800).

Lors de l'étape E801, le procédé teste la validité de l'identité de l'émetteur de la requête. L'identité de l'émetteur peut être mise dans la requête mais il est préférable de vérifier la validité de cette identité. Une solution consiste à utiliser la clé publique de l'émetteur (qui peut être obtenue sur le serveur central) pour encoder une requête envoyée à l'émetteur. Si celui-ci est capable de la décoder, cela montre qu'il possède la clé privée et qu'il a donc bien la bonne identité.

Une autre variante consiste pour l'émetteur à demander un jeton auprès du serveur central 10. Celui-ci vérifie son identité en lui demandant un mot de passe. Il peut ensuite lui donner un jeton créé avec la clé privée du serveur central 10 qui encode l'identité de l'émetteur. Celui qui reçoit la requête peut ainsi valider l'identité en décodant le jeton ce qui ne nécessite que la clé publique du serveur central.

Lors de l'étape E802, on vérifie si l'image désignée par son identifiant 303 est connue en utilisant la table des fichiers 212A. Si l'image n'est pas connue la demande est refusée (étape E803).

Ensuite le système utilise la table des images 212C pour obtenir la liste des collections contenant l'image demandée (étape E804). Pour chaque collection contenant l'image désignée, on vérifie si l'émetteur de la demande se trouve dans liste des destinataires de la collection (étape E805). Si c'est le cas l'image est envoyée au demandeur (étape E806).

En variante, un identifiant 302 de collection peut être inclus dans la demande d'image pour accélérer la recherche d'une collection contenant à la fois l'image et l'identité du demandeur. Cette collection serait testée en premier avant toutes les autres collections contenant l'image.

Si aucune collection connue localement n'autorise le demandeur à obtenir l'image, on lui demande alors d'envoyer la collection Cl qui lui a permis de trouver l'image désignée par l'identifiant 303 (étape E807). Lorsque l'on reçoit cette nouvelle collection Cl, on valide la collection Cl en utilisant une partie de l'algorithme décrite en référence à la figure 7. On vérifie d'abord la signature de la collection Cl. Si la signature n'est pas valide, la demande est refusée (étape E803).

Puis on vérifie si l'image désignée par l'identifiant 303 fait partie de la liste des images de la collection Cl et si le demandeur fait partie de la liste des destinataires (étape E809).

Enfin on extrait l'identité de l'auteur (identifiant 305) de la collection Cl (étape E810). Si l'auteur (identifiant 305) est un ami (étape E811), la collection Cl est acceptée (étape E812), elle est mémorisée et l'image peut être servie (étape E806).

Si l'auteur n'est pas un ami (indicateur 13 à l'état non valide), on vérifie (étape E813) s'il existe une collection C2 connue localement et déjà acceptée contenant l'image désignée par l'identifiant 303 et autorisant à obtenir l'image ainsi désignée. En pratique, l'autorisation est accordée si l'utilisateur désigné par l'identifiant 305 est destinataire de la collection C2 ou bien l'auteur de la collection C2 (étape E814).

Si une telle collection C2 existe (autorisation accordée selon l'étape E814) , le procédé autorise l'envoi de l'image ainsi désignée 303, mais la collection C2 n'est pas mémorisée car elle pourrait contenir des autorisations pour d'autres images que l'image qui pourraient être invalides.

En variante on pourrait vérifier que l'auteur de C2 est autorisé à accéder à toutes les images de C2 selon les collections acceptées localement et pas seulement à l'image désignée par l'identifiant 303. Dans ce cas la collection Cl peut être acceptée localement.

Si aucune collection locale C2 n'autorise l'auteur de la collection Cl à obtenir l'image 303, la requête est refusée (étape E803).

En référence à la figure 9, on a représenté le scénario normal de partage d'une collection Cl.

Un utilisateur A (identifiant 304) crée une collection Cl (identifiant 302) et met l'utilisateur B comme destinataire. Suivant les étapes décrites en référence à la figure 6, le fichier collection Cl est créé, mémorisé localement dans les tables 212A à 212C et envoyé à l'utilisateur B. L'utilisateur B peut alors demander à visualiser une image de la collection Cl. Pour cela, l'utilisateur B envoie une demande pour l'image désignée selon un identifiant 303 à l'utilisateur A. En suivant les étapes décrites en référence à la figure 8, l'utilisateur A va accepter de servir l'image car l'utilisateur B fait partie d'une collection connue qui lui donne le droit de recevoir l'image ainsi désignée par l'identifiant 303.

L'image 303 est donc envoyée à l'utilisateur B. En référence à la figure 10, on a représenté le scénario d'envoi d'une collection avec plusieurs destinataires.

Un utilisateur A crée une collection Cl et met les utilisateurs B et C comme destinataires. Suivant les étapes décrites en référence à la figure 6, le fichier collection est créé, mémorisé localement dans les tables 212A à 212C et envoyé aux utilisateurs B et C. Dans ce scénario l'utilisateur B valide la collection Cl et visualise une image désignée par un identifiant 303. L'image 303 est donc téléchargée et mémorisée sur le poste de l'utilisateur B. Ensuite l'utilisateur A se déconnecte du réseau.

L'utilisateur C demande alors à accéder à l'image 303. S'il envoie la demande à l'utilisateur B, l'utilisateur B va constater qu'il possède une collection autorisant l'utilisateur C à accéder à l'image 303. Il va donc servir l'image 303 à la place de l'auteur de la collection Cl.

En référence à la figure 11, on a représenté le scénario d'envoi de plusieurs collections.

Un utilisateur A crée une collection Cl et met l'utilisateur B comme destinataire. Suivant les étapes décrites en référence à la figure 6, le fichier collection est créé, mémorisé localement dans les tables 212a à 212C et envoyé à l'utilisateur B. Dans ce scénario l'utilisateur B valide la collection Cl et visualise une image désignée par un identifiant 303. L'image ainsi désignée est donc téléchargée et mémorisée sur le poste de l'utilisateur B. L'utilisateur A crée ensuite une collection C2 contenant la même image (même identifiant 303) que la collection Cl et met l'utilisateur C comme destinataire. Suivant les étapes décrites en référence à la figure 6, le fichier collection est créé, mémorisé localement (dans les tables 212A à 212C) et envoyé à l'utilisateur C. Ensuite l'utilisateur A se déconnecte du réseau L'utilisateur C demande alors à accéder à l'image portant l'identifiant 303. S'il envoie la demande à l'utilisateur B, l'utilisateur B va constater qu'il ne possède pas de collection autorisant l'utilisateur C à accéder à l'image 303. Il lui demande donc la collection qui l'autorise à obtenir l'image 303. L'utilisateur C envoie donc la collection C2.

L'utilisateur B applique alors les étapes décrites en référence à la figure 8 pour valider la collection C2. La collection C2 est validée car l'auteur de C2 (l'utilisateur A) est aussi l'auteur de la collection Cl qui a déjà été acceptée et qui contient les mêmes images.

L'utilisateur B va constater qu'il possède une collection autorisant l'utilisateur C à accéder à l'image 303. Il va donc servir l'image 303 à la place de l'auteur A de la collection Cl.

En référence à la figure 12, on a représenté le scénario de renvoi d'images reçues à d'autres destinataires.

Un utilisateur A crée une collection Cl et met l'utilisateur B comme destinataire. Suivant les étapes décrites en référence à la figure 6, le fichier collection est créé, mémorisé localement (dans les tables 212A à 212C) et envoyé à l'utilisateur B. Dans ce scénario l'utilisateur B valide la collection et visualise une image désignée par son identifiant 303. L'image ainsi désignée est donc téléchargée et mémorisée sur le poste de l'utilisateur B. L'utilisateur B décide alors de repartager l'image 303 avec un autre destinataire. Il crée une collection C2 contenant la même image (même identifiant 303) que la collection Cl et met l'utilisateur C comme destinataire. Suivant les étapes décrites en référence à la figure 6, le fichier collection est créé, mémorisé localement (dans les tables 212A à 212C) et envoyé à l'utilisateur C. L'utilisateur B se déconnecte ensuite.

L'utilisateur C demande alors à accéder à l'image 303. S'il envoie la demande à l'utilisateur A, l'utilisateur A va constater qu'il ne possède pas de collection autorisant l'utilisateur C à accéder à l'image 303. Il lui demande donc la collection qui l'autorise à obtenir l'image 303. L'utilisateur C envoie donc la collection C2.

L'utilisateur A applique alors les étapes décrites en référence à la figure 8 pour valider la collection C2. On suppose que l'utilisateur B n'est pas 15 un ami de l'utilisateur A, la collection C2 n'est pas validée.

Cependant l'utilisateur A peut vérifier que l'utilisateur B (l'auteur de la collection C2) est autorisé à accéder à l'image 303, car il possède une collection mémorisée Cl qui donne à l'utilisateur B le droit d'accéder à l'image 303. Il accepte donc de servir l'image 303 à la place de l'utilisateur B, même si la collection C2 n'est pas mémorisée.

En référence à la figure 13, on a représenté le scénario d'autorisation d'accès à des amis d'amis.

Un utilisateur A crée une collection Cl et met l'utilisateur C comme destinataire. Suivant les étapes décrites en référence à la figure 6, le fichier collection est créé, mémorisé localement (dans les tables 212A à 212C) et envoyé à l'utilisateur C. L'utilisateur A se déconnecte ensuite.

Dans ce scénario un utilisateur B est connecté et possède l'image 303 et l'utilisateur B a pour ami l'utilisateur A. L'utilisateur C valide la collection et demande alors à accéder à l'image 303. S'il envoie la demande à l'utilisateur B, l'utilisateur B va constater qu'il ne possède pas de collection autorisant l'utilisateur C à accéder à l'image 303. lI lui demande donc la collection qui l'autorise à obtenir l'image 303. L'utilisateur C envoie donc la collection Cl.

Cette collection est alors acceptée car l'auteur de la collection Cl est l'utilisateur A qui est un ami de l'utilisateur B. L'utilisateur B va constater qu'il possède une collection autorisant l'utilisateur C à accéder à l'image 303. Il va donc servir l'image 303 à la place de l'auteur de la collection.

Claims (17)

REVENDICATIONS,

1. Procédé d'accès à un document numérique dans un réseau de communication, en particulier du type poste à poste, apte à échanger des données sous forme de collections (Cl, C2), une collection (Cl) comprenant au moins un identifiant (303) désignant un document numérique et au moins un identifiant (304) désignant un utilisateur ayant le droit d'accéder aux documents de cette collection (Cl), ledit procédé étant mis en oeuvre dans un poste, caractérisé en ce que le procédé comprend les étapes suivantes: i) recevoir une requête émanant d'un utilisateur pour accéder à au moins un document numérique, ladite requête comprenant un identifiant (303) désignant le document numérique et un identifiant (304) désignant ledit utilisateur; ii) rechercher localement au moins une collection (Cl) contenant l'identifiant (303) du document et l'identifiant (304) de l'utilisateur, chaque collection (Cl, C2) étant stockée localement en réponse à une vérification positive à l'égard d'au moins une condition d'acceptation de servir le document selon au moins un droit d'accès (13) lié à la collection; et iii) en cas de recherche positive, servir ledit document (303) correspondant audit utilisateur (304) ainsi désigné.

2. Procédé selon la revendication 1, caractérisé en ce qu'il comporte, en cas de recherche négative à l'issue de l'étape ii) l'étape suivante: iii) obtenir au moins une collection (Cl, C2) contenant ledit identifiant (303) du document ainsi que l'identifiant (304) de l'utilisateur et stocker localement ladite collection ainsi obtenue si la condition d'acceptation (13) de servir est validée.

3. Procédé selon la revendication 1 ou la revendication 2, caractérisé en ce qu'il comprend en outre une étape il) de vérification de l'identité de l'émetteur de la requête d'accès, établie à l'aide d'une fonction d'authentification choisie.

4. Procédé selon la revendication 1, caractérisé en ce que ladite requête pour accéder à un document numérique comprend en outre l'identifiant d'une collection contenant l'identifiant du document numérique demandé.

5. Procédé selon l'une quelconque des précédentes revendications, caractérisé en ce que l'étape i) est précédée par les étapes suivantes: a) créer chaque collection (Cl, C2) en désignant chaque document numérique à partager par un identifiant (303) et en attribuant à chaque utilisateur (304) destinataire un droit d'accès (13) formé par un identifiant (304) dudit utilisateur destinataire; b) former une notification contenant ladite collection ainsi créée; et c) envoyer ladite notification ainsi formée à destination d'au moins un utilisateur destinataire (304).

6. Procédé selon la revendication 5, caractérisé en ce que la réception d'une notification est suivie d'une étape d'authentification de chaque collection (Cl, C2) ainsi reçue selon une fonction d'authentification (306) choisie.

7. Procédé selon la revendication 6, caractérisé en ce qu'en cas d'authentification négative (306) de la collection (Cl, C2), il est prévu de détruire la collection (Cl, C2) ainsi reçue.

8. Procédé selon la revendication 6, caractérisé en ce qu'en cas d'authentification (306) positive de la collection, il est prévu de vérifier le droit d'accès (13) associé à la condition d'acceptation de servir le document et en cas de vérification positive de stocker localement ladite collection ainsi reçue.

9. Procédé selon la revendication 8, caractérisé en ce qu'en cas de droit d'accès invalide, le procédé comprend en outre les étapes suivantes pour chaque document (303) de la collection (C1, C2) : 1) chercher localement la présence d'une autre collection (C2) contenant au moins l'identifiant (303) d'un document appartenant à la collection ainsi reçue, 2) en présence d'une autre collection (C2) contenant au moins l'identifiant (303) d'un document appartenant à la collection ainsi reçue, vérifier la validité du droit d'accès (13) associé à la condition d'acceptation de servir le document de ladite autre collection; et 3) en cas de validité dudit droit d'accès (13), stocker localement la collection ainsi reçue.

10. Procédé selon la revendication 9, caractérisé en ce que en cas d'échec de l'étape 3), le procédé comprend en outre une visualisation de la collection et en cas de validation manuelle de la collection, un stockage local de ladite collection.

11. Procédé selon l'une quelconque des précédentes revendications, caractérisé en ce que le document numérique appartient au groupe formé par des images ou photographies fixes, séquences vidéo, fichiers informatiques d'application bureautique ou analogue.

12. Procédé selon l'une quelconque des précédentes revendications, caractérisé en ce que le droit d'accès (13) lié à la collection (Cl) est relatif à l'auteur (305) de la collection et à l'appartenance dudit auteur (305) à une liste choisie d'utilisateurs dits amis, le droit d'accès (13) étant valide lorsque l'auteur de la collection (305) appartient à une telle liste d'amis.

13. Dispositif d'accès à un document numérique dans un réseau de communication, en particulier du type poste à poste, apte à échanger des données sous forme de collections (Cl, C2), une collection (Cl) comprenant au moins un identifiant (303) désignant un document numérique et au moins un identifiant (304) désignant un utilisateur ayant le droit d'accéder aux documents de cette collection, ledit dispositif étant incorporé dans un poste, caractérisé en ce que le dispositif d'accès comprend: - des moyens pour recevoir une requête émanant d'un utilisateur pour accéder à au moins un document numérique, ladite requête comprenant un identifiant (303) désignant le document numérique et un identifiant (304) désignant ledit utilisateur; - des moyens pour rechercher localement au moins une collection (Cl) contenant l'identifiant (303) du document et l'identifiant (304) de l'utilisateur, chaque collection (Cl, C2) étant stockée localement en réponse à une vérification positive à l'égard d'au moins une condition d'acceptation de servir le document selon au moins un droit d'accès (13) lié à la collection; et - des moyens pour servir, en cas de recherche positive, ledit document (303) correspondant audit utilisateur (304) ainsi désigné.

14. Dispositif selon la revendication 13, caractérisé en ce que le document numérique appartient au groupe formé par des images ou photographies fixes, séquences vidéo, fichiers informatiques d'application bureautique ou analogue.

15. Système d'accès à un document numérique, dans un réseau de communication, en particulier de type poste à poste, caractérisé en ce qu'il comporte un dispositif d'accès incorporant le dispositif selon l'une quelconque

des revendications 13 à 14.

16. 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 selon l'une quelconque des revendications 1 à 11, lorsque ce programme est chargé et exécuté par un système informatique.

17. 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 selon l'une quelconque des revendications 1 à 11, lorsque ce programme est chargé et exécuté par un système informatique.