FR2880703A1 - Procede d'identification d'utilisateur, de creation d'un document de partage et de service correspondant dans un systeme de partage d'un reseau pair a pair - Google Patents

Abstract

Procédé d'identification d'utilisateur dans un système de partage de données d'un réseau pair à pair. Le procédé permet d'attribuer un identifiant de seconde catégorie à un utilisateur non encore enregistré dans le système de partage afin de l'associer à un document de partage susceptible d'être partagé dans le système de partage. L'utilisateur ne peut accéder aux données du document de partage qu'après l'obtention d'un identifiant de première catégorie qui lui est attribué suite à son enregistrement au système. L'association identifiant de première catégorie et identifiant de seconde catégorie est sauvegardée dans le système de partage.

Description

La présente invention se rapporte au contrôle d'accès d'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.

La présente invention se rapporte plus précisément à un procédé d'identification d'utilisateurs pour un partage de données privées dans un réseau poste à poste et à un procédé de création de document numérique et de service de celui-ci dans un tel réseau.

Les réseaux poste à poste sont devenus une alternative aux réseaux client/serveur largement répandus à ce jour pour le partage de données sur Internet. 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 ou graphiques.

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

Dans le cadre de l'invention, les contenus numériques sont identifiés de manière unique. Ces contenus numériques peuvent être regroupés pour former des collections de contenus numériques. Ces collections sont elles-mêmes identifiées de manière unique.

Les données numériques sont par exemple, 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).

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 d'accès est associée aux contenus numériques et peut être par exemple insérée dans la collection contenant la liste de contenus numériques. Le système assure que, pour une collection donnée, seuls les utilisateurs référencés par la liste d'accès peuvent accéder aux contenus numériques.

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 la présente invention, ce serveur permanent permet l'enregistrement et l'authentification des utilisateurs afin d'assurer le contrôle 15 d'accès aux données partagées.

L'enregistrement puis l'authentification d'utilisateurs au serveur central est dans la plupart des cas nécessaire pour permettre l'accès aux données. Après enregistrement, l'utilisateur se voit attribuer un identifiant unique dans le système. Après quoi à chaque authentification, l'utilisateur obtient une clé d'authentification temporaire contenant son identifiant unique qui lui permettra d'accéder à la donnée. Se pose alors le problème de partager des données avec des utilisateurs non encore enregistrés, dont on ne connaît pas l'identifiant unique tout en garantissant un contrôle d'accès sur la donnée à partager.

Dans le brevet US 6 360 254, il est décrit une méthode permettant aux utilisateurs d'accéder de manière sécurisée à des ressources privées sans avoir besoin de s'enregistrer et de s'authentifier auprès d'un serveur central. Une adresse sous forme d'URL (de l'anglais Uniform Ressource Locator ) privée est associée à chaque ressource. Cette URL est constituée d'une chaîne de caractères fixée et d'un jeton ( token en anglais) unique. Cette URL est fournie par email (ou courriel) aux utilisateurs autorisés à accéder à la ressource par le serveur. Lors de l'accès à la ressource désignée par l'URL privée, un programme de validation de jeton est mis en oeuvre afin de vérifier que l'accès est valide. Ainsi, l'URL envoyée à l'utilisateur permet à celui ci d'accéder directement à la donnée. La possession de l'URL est donc suffisante pour accéder à la donnée. II n'y a pas d'étape d'authentification de l'utilisateur qui permet de vérifier que l'utilisateur qui accède à la donnée est bien celui qui a un droit d'accès. Ce système n'offre donc pas une sécurité de contrôle d'accès accrue.

D'autre part, à chaque donnée privée est associée une adresse (URL) unique. L'envoi de plusieurs données à plusieurs utilisateurs n'est donc pas aisé et nécessite une multiplication des URL. De même, si un utilisateur possède plusieurs adresses email, il lui sera attribué pour accéder à la même donnée, plusieurs URL. Cette multiplication d'URL alourdit le système et la gestion du serveur central.

De plus, cet envoi d'URL ne peut être initié dans le cas du document cité que par le serveur central.

D'autres systèmes comme celui décrit dans le brevet US 5 822518, permettent à un utilisateur d'accéder à deux systèmes client/serveur différents. Pour cela, l'utilisateur possède deux identifiants, un pour chaque système. Une conversion d'identifiant est effectuée automatiquement lorsque l'utilisateur désire accéder à une donnée appartenant au second système. Cependant, les identifiants ont été préalablement enregistrées dans chaque système avant de permettre un partage de données. Ainsi, avant de servir la donnée, chaque système vérifie si l'identifiant de l'utilisateur a été enregistré.

L'inconvénient d'une telle méthode est de dupliquer les identifiants utilisateurs pour une seule personne. Le système devient alors lourd à gérer. De plus, ce système nécessite un enregistrement préalable des utilisateurs des deux systèmes. La constitution de la liste des destinataires n'est donc pas flexible et n'est pas faite dynamiquement.

L'invention vise à pallier aux inconvénients de l'état de la technique en proposant une méthode plus flexible d'attribution d'identifiant à un utilisateur qui peut se gérer dynamiquement.

L'invention cherche à prévoir la possibilité de partager des données dans un système de partage avec des personnes non encore enregistrées dans le système tout en garantissant le contrôle d'accès aux données partagées.

L'invention tente de faciliter le partage de document pour l'initiateur lorsque celui-ci ne connaît pas toutes les caractéristiques des utilisateurs du réseau.

L'invention tente d'éviter la duplication des identifiants permettant l'accès aux données de partage pour un même utilisateur.

A cet effet, l'invention propose un procédé d'identification d'utilisateur dans un système de partage de données d'un réseau pair à pair. Le procédé étant tel qu'il permet d'attribuer un identifiant de seconde catégorie à un utilisateur non encore enregistré dans le système de partage afin de l'associer à un document de partage susceptible d'être partagé dans le système de partage, l'utilisateur ne pouvant accéder aux données du document de partage qu'après l'obtention d'un identifiant de première catégorie qui lui est attribué suite à son enregistrement au système, l'association identifiant de première catégorie et identifiant de seconde catégorie étant sauvegardé dans le système de partage.

Ainsi, le partage d'un document peut être initié sans la connaissance a priori de tous les utilisateurs du réseau. L'obtention d'un document de partage est cependant sécurisé par des droits d'accès associés et seul un enregistrement au système de partage permettra d'accéder au document.

Dans un mode de réalisation préféré, l'association identifiant de première catégorie et identifiant de seconde catégorie est sauvegardée provisoirement dans le système de partage.

Ainsi, le procédé d'identification prévu empêche la duplication des identifiants d'un seul utilisateur dans le réseau par l'aspect temporaire du second identifiant.

Selon un mode particulier de réalisation, l'attribution d'un identifiant de seconde catégorie à un utilisateur se fait suite à la réception d'au moins un attribut de l'utilisateur, l'association attribut de l'utilisateur et identifiant de seconde catégorie étant sauvegardée dans le système de partage.

L'association attribut de l'utilisateur et identifiant de seconde catégorie permettra ainsi de retrouver l'utilisateur et de communiquer avec lui.

Dans un mode préféré, le procédé est mis en oeuvre suite à une requête émanant d'un premier utilisateur, d'obtention d'un identifiant de première ou de seconde catégorie, à partir d'au moins un attribut d'un second utilisateur en vue de l'insertion de l'identifiant dans le document de partage.

L'association identifiant de l'utilisateur et document de partage se fait par l'insertion de ces identifiants de première ou de seconde catégorie dans le document de partage. Ainsi, le document de partage comporte lui même les droits d'accès associés.

Selon un mode de réalisation préféré, le procédé comporte les étapes de: vérification (502) de l'existence locale d'une association attribut du second utilisateur et identifiant de première catégorie, dans la négative, - création (503) d'un identifiant de seconde catégorie en fonction de l'attribut du second utilisateur; - enregistrement (504) de l'association attribut second utilisateur et identifiant de seconde catégorie; - envoi (505) de l'identifiant de seconde catégorie au premier utilisateur.

Le serveur d'authentification qui se charge d'enregistrer les utilisateurs du réseau de partage peut créer des identifiants de seconde catégorie pour des utilisateurs non encore enregistrés et qui ne sont pas encore reconnus comme tel auprès de lui afin de permettre d'initier un partage avec ces utilisateurs. Si l'attribut de l'utilisateur est déjà associé à un identifiant de première catégorie, il ne sera pas nécessaire d'en créer un deuxième pour éviter toute duplication d'identifiant.

Dans un mode préféré, le procédé comporte, suite à la réception d'une requête d'obtention de données d'un document de partage émanant d'un utilisateur via son attribut ou son identifiant de seconde catégorie, en outre les étapes suivantes: - mise en oeuvre d'un protocole d'enregistrement avec ledit utilisateur permettant l'échange de données d'authentification; - association d'un identifiant de première catégorie audit utilisateur après son enregistrement; - enregistrement de l'association attribut dudit utilisateur, données d'authentification dudit utilisateur, identifiant de seconde catégorie et identifiant de première catégorie.

Ainsi, l'identifiant de seconde catégorie est remplacé par un identifiant de première catégorie lorsque l'utilisateur correspondant s'est enregistré auprès du serveur d'authentification. Ceci permet donc de respecter les droits d'accès associés au document de partage et de sécuriser le partage.

Le procédé comporte de plus une étape de création d'une clé d'authentification à partir de l'identifiant de première catégorie, la clé d'authentification permettant l'accès aux données requises.

Ceci donne un niveau supplémentaire de contrôle d'accès.

Avantageusement, l'identifiant de seconde catégorie est calculé en fonction d'au moins un attribut utilisateur et peut être de type, adresse email en clair ou crypté et/ou numéro de téléphone en clair ou crypté et/ou numéro de série d'un appareil utilisé par l'utilisateur en clair ou crypté.

L'invention vise également un procédé de création d'un document de partage dans un système de partage, le document contenant des données de partage et une liste d'utilisateurs destinataires du partage, un utilisateur destinataire possédant au moins un attribut et pouvant posséder un identifiant de première catégorie dans le cas où il a été préalablement enregistré dans le système de partage. Le procédé est tel qu'il comporte les étapes suivantes: - vérification de la présence locale d'une association attribut des utilisateurs destinataires, identifiant de première catégorie de ces utilisateurs; - en cas de vérification positive, insertion des identifiants de première catégorie des utilisateurs destinataires dans le document de partage; pour les utilisateurs dont l'association attribut, identifiant de première catégorie n'est pas présente localement, - envoi à un serveur d'authentification du système de partage d'une requête d'obtention d'identifiants de première catégorie ou de seconde catégorie des utilisateurs via leurs attributs; - insertion des identifiants de première catégorie ou de seconde catégorie reçus en réponse à la requête, dans le document de partage; - envoi du document de partage aux utilisateurs destinataires de la liste.

Ainsi, le créateur du document de partage peut insérer dans son document les droits d'accès associés et peut initier le partage avec des utilisateurs non encore enregistrés dans le système ou avec des utilisateurs dont il ne connaît qu'un seul attribut.

Avantageusement, en cas d'obtention d'identifiants de seconde catégorie, l'association identifiant de seconde catégorie et attribut de l'utilisateur correspondant est sauvegardée localement, pour une utilisation ultérieure.

L'invention vise également un procédé de service d'une donnée d'un document de partage créé selon un procédé conforme au procédé de création d'un document de partage décrit précédemment. Ce procédé est tel que, suite à une requête d'obtention d'une donnée du document de partage provenant d'un utilisateur possédant un identifiant de première catégorie, il comporte les étapes suivantes: - obtention de l'identifiant de première catégorie à partir de la requête; - vérification de la présence de l'identifiant de première catégorie obtenu dans la liste d'utilisateurs destinataires du document de partage; - en cas de vérification négative, envoi d'une requête de mise en correspondance avec des identifiants de première catégorie, des identifiants de seconde catégorie présents dans la liste d'utilisateurs du document de partage, à un serveur d'authentification; - réception des identifiants de première catégorie correspondants et vérification de la correspondance d'au moins un identifiant de première catégorie reçu avec celui obtenu à partir de la requête; - en cas de vérification positive de la correspondance, service de la donnée.

Ainsi, le service de la donnée partagée est possible grâce aux associations des identifiants de première et seconde catégorie disponibles dans le réseau de partage. Le service de la donnée est donc fait de manière sécurisée avec l'identifiant de première catégorie obtenu après enregistrement au serveur central.

L'invention vise également un dispositif d'identification d'utilisateur dans un système de partage de données d'un réseau pair à pair, tel qu'il comporte des moyens d'attribution d'un identifiant de seconde catégorie à un utilisateur non encore enregistré dans le système de partage afin de l'associer à un document de partage susceptible d'être partagé dans le système de partage, des moyens d'attribution d'un identifiant de première catégorie suite à l'enregistrement au système de l'utilisateur, celui-ci ne pouvant accéder aux données du document de partage qu'après l'obtention de l'identifiant de première catégorie, des moyens d'enregistrement permettant de sauvegarder dans le système de partage, l'association identifiant de première catégorie et identifiant de seconde catégorie.

De même, l'invention propose un dispositif de création d'un document de partage dans un système de partage, le document contenant des données de partage et une liste d'utilisateurs destinataires du partage, un utilisateur destinataire possédant au moins un attribut et pouvant posséder un identifiant de première catégorie dans le cas où il a été préalablement enregistré dans le système de partage. Le dispositif est tel qu'il comporte: - des moyens de vérification de la présence locale d'une association attribut des utilisateurs destinataires, identifiant de première catégorie de ces utilisateurs; - des moyens d'insertion des identifiants de première catégorie des utilisateurs destinataires dans le document de partage; - des moyens d'envoi à un serveur d'authentification du système de partage d'une requête d'obtention d'identifiants de première catégorie ou de seconde catégorie des utilisateurs dont l'association attribut/identifiant de première catégorie n'est pas présente localement.; - des moyens d'insertion des identifiants de première catégorie ou de seconde catégorie reçus en réponse à la requête, dans le document de partage; - des moyens d'envoi du document de partage aux utilisateurs destinataires.de la liste.

L'invention vise un dispositif de service d'une donnée, tel qu'il comporte: - des moyens de réception d'une requête d'obtention d'une donnée du document de partage provenant d'un utilisateur possédant un identifiant de première catégorie; - des moyens d'obtention de l'identifiant de première catégorie à partir de la requête; - des moyens de vérification de la présence de l'identifiant de première catégorie obtenu dans la liste d'utilisateurs destinataires du document de partage; - des moyens d'envoi d'une requête de mise en correspondance avec des identifiants de première catégorie, des identifiants de seconde catégorie présents dans la liste d'utilisateurs du document de partage, à un serveur d'authentification; des moyens de réception des identifiants de première catégorie correspondants et des moyens de vérification de la correspondance d'au moins un identifiant de première catégorie reçu avec celui obtenu à partir de la requête; - des moyens de service de la donnée.

Ces dispositifs présentent les mêmes avantages que les procédés qu'ils mettent en oeuvre.

La présente invention vise aussi un moyen de stockage, éventuellement amovible partiellement ou totalement, lisible par un ordinateur ou un microprocesseur conservant des instructions d'un programme informatique, permettant la mise en oeuvre des procédés tels que ci-dessus.

La présente invention vise enfin un produit programme d'ordinateur pouvant être chargé dans un appareil programmable, comportant des séquences d'instructions pour mettre en oeuvre les procédés tels que ci- dessus, lorsque ce programme est chargé et exécuté par l'appareil programmable.

D'autres particularités et avantages de l'invention apparaîtront encore dans la description ci-après.

Aux dessins annexés, donnés à titre d'exemples non limitatifs: -la figure 1 représente schématiquement un réseau de communication adapté à mettre en oeuvre l'invention; - la figure 2 représente schématiquement un dispositif mettant en oeuvre l'invention - la figure 3 représente schématiquement une collection de contenu numérique utilisée pour l'invention; - la figure 4 représente un organigramme illustrant les étapes d'un procédé de création de document de partage conforme à l'invention; - la figure 5 représente un organigramme illustrant les étapes d'une première phase d'un procédé d'identification d'utilisateur conforme à l'invention; - la figure 6 représente un organigramme illustrant les étapes d'une deuxième phase d'un procédé d'identification d'utilisateur conforme à l'invention; et la figure 7 représente un organigramme illustrant les étapes d'un procédé de service de donnée conformément à l'invention.

On va décrire tout d'abord, en référence à la figure 1, un réseau distribué 1 d'échanges de données du type pair à pair . Un tel réseau 1 comporte un ensemble de terminaux 110, 120, 130, 140, 150, chaque terminal étant relié au réseau de communication 100 par des moyens de communication qui peuvent par exemple être de type DSL (de l'anglais Digital Subscriber Line ) haut débit, de type liaison sans fil WIFI (de l'anglais Wireless Fidelity , liaison téléphonique cellulaire GSM (de l'anglais Global System for Mobile communications ), etc.... Le réseau de communication 100 peut être de type Internet ou réseau local privé (LAN) par exemple.

Les terminaux peuvent être configurés de différentes façons. Certains peuvent par exemple comporter une application de partage pair à pair dédiée. C'est le cas par exemple des terminaux 110 (client A), 130 (client C) ou 140 (client D). On dit alors que ces terminaux forment entre eux un réseau pair à pair dédié au travers du réseau de communication 100 que l'on appellera par la suite réseau de partage ou système de partage. Certains terminaux peuvent ne pas avoir l'application pair à pair dédiée. C'est le cas par exemple du terminal 120 (client B).

L'application pair à pair des terminaux 110, 130, 140 comporte au moins un module serveur respectivement 113, 133, et 143 et un moyen de stockage ou cache respectivement 112, 132, et 142. Le module serveur (113, 133, 143) est chargé de répondre aux requêtes d'accès aux ressources. Ces requêtes peuvent provenir aussi bien d'applications distantes que d'applications présentes sur la même machine. Les requêtes peuvent être reçues selon un protocole propriétaire propre à l'application pair à pair ou peuvent être reçues selon le protocole HTTP (de l'anglais Hyper Text Transfer Protocol ) communément utilisé sur le réseau Internet.

Le moyen de stockage (112, 132, 142) contient les contenus numériques partagés sur le réseau pair à pair. L'application de partage dédiée peut également être complétée par une interface utilisateur de visualisation représentée ici respectivement en 111, 131, et 141 permettant à cet utilisateur de rechercher, d'accéder, de visualiser et de partager des contenus numériques sur le réseau pair à pair.

Ces terminaux sont susceptibles de mettre en oeuvre un procédé de création d'un document de partage conforme à l'invention et qui sera décrit plus en détail en référence à la figure 3.

Tous les terminaux, qu'ils soient munis ou non de l'application de partage dédiée, peuvent également utiliser des outils 114, 121 capables de visualiser des pages HTML pour accéder aux contenus numériques à l'aide du protocole de communication HTTP.

Le réseau pair à pair 1 comporte également au moins un serveur d'authentification 150 chargé d'enregistrer et d'authentifier les utilisateurs formant le réseau de partage. Celui-ci met en oeuvre un procédé d'identification d'utilisateur conformément à l'invention et qui sera décrit ultérieurement en référence à la figure 4 et à la figure 5.

Dans un souci de simplification, nous ne décrirons qu'un utilisateur ou client par terminal. Bien entendu, l'invention n'est pas limitée à ce cas de figure simple et est parfaitement applicable dans un contexte multi-utilisateurs.

En référence à la figure 2, on a représenté un dispositif apte à mettre en oeuvre les procédés de l'invention. Un tel appareil 200 peut représenter soit les terminaux 110, 130 ou 140, soit le serveur central 150. Ce dispositif 200 est par exemple un micro-ordinateur, une station de travail, un assistant personnel, un téléphone mobile ou plus généralement tout périphérique mobile capable de se connecter à un réseau de communication.

Cet appareil peut être connecté à différents périphériques tels que, par exemple une caméra numérique 211 (ou un scanner, ou tout autre moyen d'acquisition ou de stockage d'images) reliée à une carte d'entrée/sortie (non représentée) et fournissant à l'appareil des données multimédia.

L'appareil peut aussi être un appareil photo muni d'une interface de communication permettant de se connecter à un réseau.

L'appareil 200 comporte un bus de communication 201 auquel sont reliés: une unité centrale de traitement 202 (microprocesseur) (notée CPU sur la figure), - une mémoire morte 203 (ROM) pouvant comporter les programmes mis en oeuvre selon l'invention, - une mémoire vive (RAM) 204, qui après la mise sous tension contient le code exécutable des procédés suivant l'invention ainsi que des registres adaptés à enregistrer des variables et paramètres nécessaires à la mise en oeuvre de l'invention.

- un écran 205 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 206 ou de tout autre moyen tel qu'un dispositif de pointage, comme par exemple une souris 207, un crayon optique ou encore un écran tactile.

- une interface de communication 210 reliée à un réseau de communication 100, l'interface étant apte à transmettre et à recevoir des données.

Dans le cas de données audio, l'appareil comprend en outre une carte d'entrée/sortie (non représentée) reliée à un microphone 214. 15 Optionnellement, l'appareil peut disposer également: - d'un disque dur ou d'une mémoire de stockage (telle qu'une carte compact flash) 208 pouvant comporter les programmes selon l'invention ainsi que des données utilisées ou produites lors de la mise en oeuvre de l'invention.

- d'un lecteur de disquette (ou tout autre support de données amovible) 209 adapté à recevoir une disquette 212 et à y lire ou à y écrire des données traitées ou à traiter selon l'invention.

Le bus de communication 201 permet la communication et l'interopérabilité entre les différents éléments inclus dans l'appareil 200 ou relié à lui. La représentation du bus n'est pas limitative et, notamment, l'unité centrale est susceptible de communiquer des instructions à tout élément de l'appareil 200 directement ou par l'intermédiaire d'un autre élément de l'appareil 200.

Les disquettes 212 peuvent être remplacées par tout support d'information tel que, par exemple, un disque compact (CD-ROM) réinscriptible ou non, un 10 disque ZIP ou une carte mémoire. D'une manière générale, un moyen de stockage d'information, lisible par un micro-ordinateur ou par unmicroprocesseur, 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 ou des procédés selon l'invention.

Le code exécutable permettant à l'appareil la mise en oeuvre de l'invention peut se trouver indifféremment stocké en mémoire morte 203, sur le disque dur 208 ou sur un support numérique amovible tel que par exemple une disquette 212 telle que décrite précédemment. Selon une variante, le code exécutable des programmes pourra être reçu par l'intermédiaire du réseau de communication 100 via l'interface 210, pour être stocké dans un des moyens de stockage de l'appareil 200 avant d'être exécuté (tel que le disque dur 208 par exemple).

L'unité centrale 202 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 l'un des moyens 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 208 ou la mémoire morte 203, sont transférés dans la mémoire vive 204 (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.

II convient de noter que l'appareil 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 de données numériques. Cette collection ou encore document de partage est un ensemble de contenus de médias (image, vidéo, son) identifiés individuellement. Cette collection est susceptible d'être partagée dans le réseau distribué d'échanges de données 1 représenté en figure 1.

Par extension, une collection peut contenir des collections (appelées des sous-collections). Par la suite, dans le mode de réalisation préféré, le média utilisé est constitué d'images numériques.

Chaque collection ou document de partage est identifiée par un identifiant unique 302, créé sur la machine de l'utilisateur. Cet identifiant est assigné par l'application de partage dédiée sur un poste client même si le client n'est pas connectée sur le réseau. Une solution 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.

Une collection contient également un titre 301, l'identifiant de l'auteur de la collection 306 et une signature 307 permettant de vérifier que le contenu de la collection n'a pas été modifié et qu'elle a donc bien été créée par l'auteur. Cette signature peut être créée de plusieurs manières suivant le type de système: É Si chaque utilisateur possède une clé publique et une clé privée, la signature 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 hachage ( hash ) de la collection avec l'algorithme classique MD5 et l'encrypter avec la clé privée.

É On peut aussi utiliser le serveur central pour signer la collection: dans ce cas seul le serveur central a besoin d'avoir une paire de clés privée/publique. La signature est fabriquée sur le serveur central avec sa clé privée.

Pour valider une signature, un client 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 comparer la valeur obtenue avec son propre calcul du hash de la collection) ou bien il peut faire appel au serveur central pour valider la signature.

Une collection contient également une liste d'images numériques. Ces images ou données de partage sont de même 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 conservera l'identificateur original).

En pratique, une vignette a le même identifiant que l'image dont elle est issue. Afin de déterminer de manière unique un objet (image ou vignette), 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 la vignette est utile pour une visualisation simple).

Enfin la collection possède une liste d'accès. Au moment du partage, le créateur de la collection spécifie une liste d'utilisateurs destinataires c'est-à-dire une liste de personnes autorisées à accéder à la collection.

Si le destinataire est déjà enregistré dans le système de partage, la liste d'accès contiendra son identifiant unique (304) de partage encore appelé identifiant de première catégorie qui lui a été associé par le serveur d'authentification dans une étape préalable d'enregistrement d'utilisateur.

Dans le cas contraire la liste d'accès contiendra un identifiant de seconde catégorie (305) qui est de préférence temporaire. Nous verrons en référence à la figure 4 et à la figure 5 comment cet identifiant de seconde catégorie peut être déterminé.

En référence à la figure 4, on a représenté les étapes illustrant la création d'une collection telle que décrite précédemment, par un utilisateur tel que le client A, C ou D représenté en figure 1. Cet utilisateur fait partie du système de partage et est enregistré auprès du serveur central.

A l'étape 401, l'utilisateur, par exemple, le client A selon la figure 1, crée à l'aide de son interface graphique 111 une collection de contenus numériques (par exemple constituée d'un ensemble d'images numériques). La création d'une collection de contenus numériques 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 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.

Quand une nouvelle collection est créée, une liste d'accès est associée à la nouvelle collection. L'utilisateur doit choisir une liste de destinataires pour sa nouvelle collection.

Après avoir créé une collection de contenus numériques, l'utilisateur sélectionne donc à l'étape 402 à l'aide de son interface graphique une liste de destinataires. Cette liste de destinataires peut être choisie à partir d'une liste préenregistrée de contacts (par exemple à partir d'un carnet d'adresse) ou à partir d'une zone de saisie permettant à l'utilisateur de saisir l'identité d'un nouveau contact en entrant un attribut relatif à cet utilisateur tel que son adresse email.

Parmi les destinataires sélectionnés, certains ont déjà été enregistrés auprès du système de partage. Ces destinataires peuvent être par exemple, les clients C ou D selon la figure 1. Ceux-ci ont alors dans ce système de partage, un identifiant de première catégorie qui pourra leur permettre d'accéder à des données partagées qui leur sont destinées dans le système de partage.

A l'étape 403, le client vérifie si localement, il possède déjà les identifiants de première catégorie des destinataires de la liste (sauvegardés localement dans le carnet d'adresses par exemple). Si c'est le cas, le client insère à l'étape 406, les identifiants qu'il a trouvé localement dans la liste d'accès associée à la collection afin de spécifier les destinataires en question.

Dans la négative, et donc pour les destinataires dont l'identifiant de première catégorie n'est pas connu localement mais dont une caractéristique ou un attribut est connu, le client met en oeuvre l'étape 404.

Le client envoie une requête comportant l'attribut du destinataire (par exemple une adresse email) au serveur d'authentification 150 afin que celui-ci détermine s'il existe une correspondance entre l'attribut du destinataire et un identifiant de première catégorie qui aurait déjà été associé à cet utilisateur.

A l'étape 405, le serveur d'authentification retourne les identifiants de première catégorie des destinataires qui ont déjà été enregistrés auprès de lui et qui ont un compte d'utilisateur dans le système de partage et qui sont connus par l'attribut en question.

Pour les destinataires qui n'ont pas d'identifiants de première catégorie parce qu'ils n'ont pas été enregistrés dans le système de partage, par exemple, le client B de la figure 1, ou pour ceux pour lesquels l'association identifiant de première catégorie/attribut n'existe pas, le serveur d'authentification 150 calcule un identifiant de seconde catégorie qui est temporaire. Le serveur d'authentification conserve dans une mémoire locale, une correspondance entre cet identifiant de seconde catégorie et l'attribut (par exemple l'adresse email) du nouveau destinataire puis retourne l'identifiant de seconde catégorie au client A en réponse à sa requête.

Ainsi, à l'étape 405, le client reçoit des identifiants de première ou de seconde catégorie des destinataires qui n'avaient pas d'identifiants localement. Le client conserve alors localement, dans son carnet d'adresse ou dans un cache, les correspondances identifiants/attributs, résolues par le serveur d'authentification pour un usage ultérieur.

A l'étape 406, le client rajoute dans la liste d'accès de la collection les identifiants d'utilisateurs résolus par le serveur d'authentification. Ces identifiants peuvent donc être de première ou de seconde catégorie suivant que le destinataire ait été précédemment enregistré au système de partage ou non.

A l'étape 407, le client procède au partage de la collection ainsi créée.

Dans un mode préféré de réalisation, la collection est envoyée au serveur d'authentification pour validation. En réponse à cette requête, le serveur d'authentification valide la collection en créant une signature de la collection. La collection est conservée au niveau du serveur d'authentification dans un cache et la signature est ensuite retournée au client. Cette signature permettra au destinataire du partage de vérifier l'intégrité du fichier de collection.

Enfin à l'étape 408, le client envoie une notification à chacun des destinataires sous la forme par exemple, d'un email contenant la nouvelle collection ou une référence de la nouvelle collection sur le serveur d'authentification. Cette notification informe donc les destinataires qu'une nouvelle collection de données numériques est disponible dans le système de partage.

Plus spécifiquement, pour les destinataires ne possédant pas de compte utilisateur dans le système de partage, par exemple, le client B (en d'autres termes, ceux qui sont représentés par un identifiant de seconde catégorie dans la liste d'accès de la collection), la notification contiendra une URL (de l'anglais Uniform resource location ) pointant sur le serveur d'authentification et contenant l'identifiant de la collection 302 et optionnellement l'identifiant de seconde catégorie du destinataire. Par exemple l'URL pourrait avoir la forme suivante: http://<adresse_serveur_authentification> /getcollection?cuid =<IDdecollection>&recipient=< ID_du_destinataire>

_

dans laquelle getcollect ion est un mot clé indiquant qu'il s'agit d'une requête pour obtenir une collection identifiée par < ID_de_collection> et dont le destinataire est identifié par < ID_du_destinataire>.

Les communications entre le client et le serveur d'authentification peuvent par exemple être réalisées à l'aide de message en langage de balisage XML tel que SOAP, et transportées à l'aide du protocole de communication HTTP.

Suivant le niveau de confidentialité souhaité dans le système, l'identifiant de seconde catégorie peut être soit l'adresse email ellemême (en clair), soit le numéro de série d'un appareil utilisé par le destinataire (par exemple de son appareil photo numérique), soit un hash ou encore une valeur cryptée (à l'aide d'un algorithme de cryptage symétrique ou asymétrique) de l'adresse email de manière qu'elle ne soit pas compréhensible par un utilisateur du système de partage.

Dans une variante, l'attribut du destinataire peut être un numéro de téléphone portable ou une adresse de messagerie instantanée ou encore le numéro de série d'un appareil utilisé par le destinataire. La notification aux destinataires peut être faite par une notification par SMS (de l'anglais Short Message Service ), MMS (de l'anglais Multimedia Message Service ) ou un message instantanée.

En référence à la figure 5, on a illustré les premières étapes du procédé d'identification d'utilisateur mis en oeuvre dans le serveur d'authentification 150 représenté en figure 1.

Ce procédé comporte une première étape 501 de réception d'une requête émanant d'un premier utilisateur, le client A, correspondant à l'étape 404 de la figure 4. Cette requête comporte au moins un attribut d'un second utilisateur (client B) pour lequel le client A n'a pas d'identifiant de première catégorie.

L'étape 501 est suivie de l'étape 502 où le serveur d'authentification vérifie l'existence localement d'une association entre l'attribut du second utilisateur reçu et un identifiant de première catégorie correspondant à cet utilisateur. Si cette association existe, le serveur d'authentification envoie à l'étape 506, cet identifiant de première catégorie au client A qui a envoyé la requête.

Si cette association n'est pas présente localement, le serveur d'authentification détermine à l'étape 503, un identifiant de seconde catégorie basé sur l'attribut reçu. En pratique, cet identifiant de seconde catégorie est déterminé comme indiqué en référence à la figure 4, soit en prenant l'adresse email elle-même (en clair), soit en prenant le numéro de série d'un appareil utilisé par le destinataire (dans ce cas, l'attribut reçu est ce numéro), soit un hash ou encore une valeur cryptée (à l'aide d'un algorithme de cryptage symétrique ou asymétrique) de l'adresse email de manière qu'elle ne soit pas compréhensible par un utilisateur du système de partage.

L'association identifiant de seconde catégorie et attribut est alors 20 sauvegardée à l'étape 504, localement dans un espace mémoire du serveur d'authentification, en pratique dans un répertoire d'adresse.

L'identifiant de seconde catégorie et l'attribut sont alors envoyés, à l'étape 505 au client A qui a effectué la requête initiale afin que celui-ci puisse inclure un identifiant dans une liste d'accès associée à une collection.

En référence à la figure 6, on a illustré les étapes du procédé d'identification d'utilisateur selon l'invention suite à une requête d'obtention de donnée d'un utilisateur. Ces étapes sont effectuées sur le serveur d'authentification.

Lors du partage d'une collection, une notification (par exemple par email) a 30 été reçue par chaque destinataire comme décrit précédemment en référence à la figure 4, à l'étape 408.

L'utilisateur qui possède un identifiant de première catégorie et qui est défini par cet identifiant dans le document de partage, pourra obtenir une clé d'authentification avec son identifiant de première catégorie. Cette clé d'authentification obtenue via le serveur d'authentification, lui permettra d'accéder à la donnée de partage désirée en effectuant la requête d'obtention de cette donnée, soit au serveur, soit à un client du système de partage.

Pour un utilisateur qui est spécifié par un identifiant de seconde catégorie dans le document de partage, celui-ci utilise l'URL qu'il a reçu dans la notification provenant de l'initiateur du partage pour accéder à la collection par exemple à l'aide de son navigateur WEB.

A l'étape 601 de la figure 6, le serveur d'authentification reçoit une requête d'accès à une collection d'un utilisateur. Cette requête peut contenir soit l'identifiant de première ou seconde catégorie de l'utilisateur soit un attribut de celui-ci.

A l'étape 602, le serveur d'authentification obtient l'identifiant de la collection ou du document de partage demandé dans la requête et l'identifiant du destinataire directement par la requête ou en le retrouvant localement par correspondance avec l'attribut de cet utilisateur donné dans la requête. Cet identifiant peut être un identifiant de première catégorie ou un identifiant de seconde catégorie.

Le serveur vérifie donc à l'étape 603 si l'identifiant du destinataire est un identifiant de première catégorie. Dans la positive, l'étape 603 est suivie de l'étape 612 que nous décrirons ultérieurement.

Dans la négative, le serveur considère qu'il s'agit d'un identifiant de 25 seconde catégorie et poursuit à l'étape 604.

Le serveur d'authentification retourne au demandeur, en l'occurrence, le client B, une page HTML invitant celui ci à s'authentifier à l'aide de son nom de connexion ( login en anglais) et de son mot de passe s'il possède déjà un compte utilisateur. En effet, il se peut qu'un identifiant de seconde catégorie ait été attribué à un utilisateur déjà enregistré dans le cas où l'attribut que le créateur de collection a utilisé pour ce destinataire, n'est pas le même que celui qui est associé sur le serveur d'authentification à l'utilisateur en question.

Dans ce cas particulier, l'utilisateur a deux identifiants mais le serveur d'authentification va se rendre compte qu'il s'agit d'un utilisateur déjà enregistré grâce à son nom de connexion et son mot de passe.

A l'étape 605, l'utilisateur a fournit son nom de connexion ( login en anglais) et son mot de passe, le serveur peut alors vérifier que cet utilisateur a déjà été enregistré dans le système de partage. Il valide ces informations à l'étape 606. Si l'authentification est incorrecte, le serveur retourne une erreur au demandeur (étape 617).

Si l'utilisateur ne possède pas de compte, l'étape 605 est suivie de l'étape 10 607 dans laquelle un nouveau compte pourra être créé.

Le serveur retrouve dans son cache la correspondance entre l'identifiant de seconde catégorie et une adresse email ou un attribut utilisateur qui permet de communiquer avec lui puis il retourne au demandeur un formulaire d'enregistrement (page HTML) l'invitant à créer un nouveau compte. Le demandeur peut alors remplir son profil (information d'identité (par exemple: nom, prénom, âge, mot de passe...), d'adresses (par exemple: adresse postale, téléphone, email,...), de préférences (s'il souhaite que les informations ne soient pas utilisées à des fins de démarchage par exemple). Le serveur peut avoir préalablement rempli le champ du formulaire correspond à l'email à l'aide de la correspondance identifiant de seconde catégorie/email déduite de son cache.

A l'étape 608, le serveur reçoit en retour les informations d'enregistrement, crée un nouveau compte et lui assigne un identifiant de première catégorie pour l'utilisateur ainsi enregistré.

Suite aux étapes 608 ou 606 après bonne validation, le serveur d'authentification va chercher à associer au compte du demandeur créé à l'étape 608 ou identifié à l'étape 606, l'adresse email ou autre attribut. Pour cela il va lancer une procédure de validation par exemple de l'email (étape 609). Si la validation échoue il retourne une erreur au demandeur (étape 610) sinon il met à jour le compte utilisateur en y ajoutant l'adresse email (étape 611).

La validation de l'email consiste à envoyer un message par email au demandeur et à lui demander de renvoyer en retour une information présente dans l'email. Ainsi on peut vérifier que l'utilisateur n'utilise pas impunément l'email d'une autre personne et qu'il est joignable via cette adresse email.

Plusieurs techniques connues de l'homme du métier permettent de valider un email. Par exemple, l'email peut contenir une URL à usage unique sur laquelle l'utilisateur doit cliquer pour valider qu'il a bien reçu l'email. Dans un autre exemple, l'email peut contenir une information (un mot ou un numéro de validation) que l'utilisateur doit retranscrire dans une page WEB.

Une fois que l'email inconnu a été assigné à un compte utilisateur, à l'étape 615 le serveur génère une clé d'authentification. Le serveur utilise une clé privée pour fabriquer un jeton ( token en anglais) à partir de l'identifiant de première catégorie du demandeur, son adresse IP et une date de validité. Celui qui recevra un tel token pourra ainsi valider l'identité du demandeur en décodant le jeton à l'aide de la clé publique du serveur d'authentification et en contrôlant l'exactitude de l'adresse IP et de la date de validité.

A l'étape 616, le serveur d'authentification retourne la clé d'authentification au demandeur et lui sert le contenu numérique demandé s'il est présent sur le serveur ou redirige le demandeur avec la clé d'authentification sur un des serveurs pair à pair constituant le réseau de partage.

Si à l'étape 603 le serveur d'authentification a détecté que l'identifiant spécifié dans la requête du demandeur correspond à un identifiant de première catégorie, l'étape 612 est effectuée. Un formulaire (page HTML) d'authentification, invitant l'utilisateur à fournir son nom de connexion et son mot de passe lui est envoyé. Optionnellement, le compte utilisateur ayant déjà été identifié, le nom de connexion peut être pré-rempli.

A l'étape 614, le serveur valide les informations d'authentification reçues à l'étape 613. En cas d'échec, il retourne une erreur au demandeur (étape 617) sinon il effectue les étapes 615 et 616 précédemment décrites.

Le serveur d'authentification peut, afin de mettre à jour sa mémoire cache, envoyer une mise à jour d'une collection, une fois que les identifiants de seconde catégorie de cette collection sont tous résolus. Cette mise à jour consiste à remplacer les identifiants de seconde catégorie par les identifiants de première catégorie. Elle est envoyée aux destinataires spécifiés dans la collection. Ainsi, le serveur d'authentification peut supprimer de sa mémoire cache les associations liées aux identifiants de seconde catégorie de la collection mise à jour. Il ne conserve ainsi que les identifiants de première catégorie liés aux utilisateurs correspondants. Ainsi, l'identifiant de seconde catégorie a un caractère temporaire sur le réseau de partage. Ceci évite ainsi la duplication des identifiants pour un même utilisateur même si celui ci possède plusieurs attributs (par exemple, plusieurs emails).

La figure 7 à présent, illustre les étapes d'un procédé de service de donnée d'un document de partage créé par le procédé décrit en référence à la figure 4. Ce procédé de service est mis en oeuvre suite à une requête d'obtention de donnée de partage provenant d'un client (A, B, C ou D selon la figure 1) du réseau. Ce procédé peut être mis en oeuvre dans tout dispositif du système de partage, notamment les postes du réseau de partage 110, 130 ou 140 illustrés à la figure 1. Ce procédé peut également être mis en oeuvre dans le serveur d'authentification 150 illustré à la figure 1.

Ce procédé est mis en oeuvre lorsque celui qui émet la requête a reçu une clé d'authentification et donc un identifiant de première catégorie et est ainsi apte à effectuer une requête d'obtention de donnée du système de partage. Ainsi, ce procédé de service de donnée peut être effectué après la mise en oeuvre du procédé d'identification d'utilisateur conforme à l'invention.

A l'étape 701, le poste serveur reçoit une requête pour l'obtention d'un contenu numérique. Cette requête pour être valide doit comporter une clé d'authentification fournit par le serveur d'authentification (par exemple tel que décrit dans la figure 6 à l'étape 615).

A l'étape 702, le module serveur du poste vérifie la présence de la clé d'authentification dans la requête. Si une clé n'est pas présente dans la requête le module serveur retourne une erreur au demandeur à l'étape 709. Dans une variante, le module serveur retourne un ordre de redirection du demandeur vers le serveur d'authentification dans le but d'obtenir une clé d'authentification valide.

A l'étape 703, le module serveur récupère à partir de la requête la clé d'authentification et l'identifiant unique du contenu numérique recherché (par exemple, l'identifiant unique d'une collection).

Comme décrit précédemment la clé d'authentification est une représentation cryptée de l'identifiant de première catégorie du demandeur, de l'adresse IP courante du demandeur et d'une date de validité (ou d'expiration). A l'étape 704, le module serveur décrypte la clé d'authentification à l'aide de la clé publique du serveur d'authentification et obtient ainsi, l'identification de première catégorie du demandeur, son adresse IP et la date de validité.

A l'étape 705 il vérifie que la date de validité n'est pas expirée et que l'adresse IP du demandeur correspond bien à l'adresse IP présente dans la clé. On limite de cette manière les possibilités pour une personne malintentionnée de réutiliser une clé d'authentification à son profit. En cas d'erreur, l'erreur est retournée au demandeur à l'étape 709.

Avec l'identifiant de première catégorie du demandeur, le module serveur va vérifier la présence du contenu numérique demandé et va vérifier que le demandeur est bien autorisé à y accéder. Pour cela, il compare à l'étape 706 l'identifiant de première catégorie du demandeur avec chaque identifiant présent dans la liste d'accès associée au contenu numérique demandé.

A l'étape 707, si l'identifiant de première catégorie du demandeur est présent dans la liste d'accès, le contenu numérique est servi au demandeur à l'étape 708.

Dans le cas contraire, le module serveur vérifie à l'étape 710 s'il existe des identifiants de seconde catégorie dans la liste d'accès. S'il n'y en a pas, l'échec à l'étape 707 signifie que le demandeur n'est pas autorisé à accéder au contenu numérique et une erreur lui est retournée à l'étape 715.

Si à l'étape 710 il existe des identifiants de seconde catégorie dans la liste d'accès, le module serveur vérifie à l'étape 711, localement dans son cache, s'il n'existe pas une correspondance identifiant de seconde catégorie/identifiant de première catégorie pour cet utilisateur. S'il n'existe pas de correspondance il demande alors au serveur d'authentification de résoudre les identifiants de seconde catégorie que celui-ci a attribué conformément à l'étape 503 de la figure 5.

A l'étape 712, le module serveur reçoit la réponse du serveur d'authentification et sauvegarde localement les correspondances entre les identifiants de seconde catégorie et les identifiants de première catégorie d'utilisateurs reçues du serveur d'authentification. Lacorrespondance entre identifiants de seconde catégorie et identifiants de première catégorie peut être sauvegardée soit dans un cache dédié sur la machine, soit directement dans le fichier collection (par exemple en fin de fichier dans une partie non signée).

A l'étape 713, le module serveur vérifie si l'identifiant de première catégorie du demandeur correspond à un identifiant de première catégorie nouvellement reçu et associé à un identifiant de seconde catégorie présent dans la liste d'accès.

En l'absence de correspondance à l'étape 714 une erreur est retournée au demandeur à l'étape 715. Si à l'étape 714, la réponse est positive, le demandeur est autorisé à accéder au contenu numérique et celui-ci lui est servi à l'étape 708.

Lorsque le module serveur reçoit du serveur d'authentification, une mise à jour d'une collection, il peut mettre à jour son cache en supprimant les associations liées aux identifiants de seconde catégorie précédemment inclus dans la collection. Il n'effectue cette mise à jour locale que si ces identifiants de seconde catégorie ne sont pas présents dans d'autres collections localement., II ne conserve donc dans son carnet d'adresse que les identifiants de première catégorie correspondants. L'identifiant de seconde catégorie a ainsi un caractère provisoire dans le système de partage.

Claims (28)

REVENDICATIONS

1. Procédé d'identification d'utilisateur dans un système de partage de données d'un réseau pair à pair, caractérisé en ce qu'il est mis en oeuvre suite à une étape de réception d'une requête émanant d'un premier utilisateur, d'obtention d'un identifiant de première ou de seconde catégorie, à partir d'au moins un attribut d'un second utilisateur en vue de l'associer (406) à un document de partage susceptible d'être partagé dans le système de partage, le procédé comportant une étape d'attribution d'un identifiant de seconde catégorie (503) au second utilisateur non encore enregistré dans le système de partage, le second utilisateur ne pouvant accéder aux données du document de partage qu'après l'obtention d'un identifiant de première catégorie (616) qui lui est attribué suite à son enregistrement au système, l'association identifiant de première catégorie et identifiant de seconde catégorie étant alors sauvegardée dans le système de partage.

2. Procédé selon la revendication 1, caractérisé en ce que l'association identifiant de première catégorie et identifiant de seconde catégorie est sauvegardée provisoirement dans le système de partage.

3. Procédé selon la revendication 1 ou 2, caractérisé en ce que l'association attribut du second utilisateur et identifiant de seconde catégorie est sauvegardée dans le système de partage.

4. Procédé selon la revendication 3, caractérisé en ce que l'association attribut du second utilisateur et identifiant de seconde catégorie 25 est sauvegardée provisoirement dans le système de partage.

5. Procédé selon l'une des revendications 1 à 4, caractérisé en ce qu'il comporte les étapes de: - vérification (502) de l'existence locale d'une association attribut du second utilisateur et identifiant de première catégorie, dans la négative, - création (503) d'un identifiant de seconde catégorie en fonction de l'attribut du second utilisateur; enregistrement (504) de l'association attribut second utilisateur et identifiant de seconde catégorie; - envoi (505) de l'identifiant de seconde catégorie au premier utilisateur.

6. Procédé selon l'une des revendications 1 à 5, caractérisé en ce qu'il comporte, suite à la réception d'une requête d'obtention de données d'un document de partage émanant d'un utilisateur via son attribut ou son identifiant de seconde catégorie, en outre les étapes suivantes: - mise en oeuvre d'un protocole d'enregistrement avec ledit utilisateur permettant l'échange de données d'authentification; - association d'un identifiant de première catégorie audit utilisateur après son enregistrement; enregistrement de l'association attribut dudit utilisateur, données d'authentification dudit utilisateur, identifiant de seconde catégorie et identifiant de première catégorie.

7. Procédé selon la revendication 6, caractérisé en ce que suite à l'étape d'association d'un identifiant de première catégorie, le procédé comporte une étape de création d'une clé d'authentification à partir de l'identifiant de première catégorie, la clé d'authentification permettant l'accès aux données requises.

8. Procédé selon l'une des revendications 1 à 7, caractérisé en ce que au moins un attribut utilisateur est une caractéristique de l'utilisateur de type email, numéro de téléphone ou encore numéro de série d'un appareil utilisé par l'utilisateur.

9. Procédé selon la revendication 8, caractérisé en ce que l'identifiant de seconde catégorie est calculé en fonction d'au moins un attribut utilisateur et peut être de type, adresse email en clair ou crypté et/ou numéro de téléphone en clair ou crypté et/ou numéro de série d'un appareil utilisé par l'utilisateur en clair ou crypté.

10. Procédé de création d'un document de partage dans un système de partage, le document contenant des données de partage et une liste d'utilisateurs destinataires du partage, un utilisateur destinataire possédant au moins un attribut et pouvant posséder un identifiant de première catégorie dans le cas où il a été préalablement enregistré dans le système de partage, caractérisé en ce qu'il comporte les étapes suivantes: - vérification de la présence locale d'une association attribut des utilisateurs destinataires, identifiant de première catégorie de ces utilisateurs; - en cas de vérification positive, insertion des identifiants de première catégorie des utilisateurs destinataires dans le document de partage; pour les utilisateurs dont l'association attribut, identifiant de première catégorie n'est pas présente localement, - envoi à un serveur d'authentification du système de partage d'une requête d'obtention d'identifiants de première catégorie ou de seconde catégorie des utilisateurs via leurs attributs; - mise en oeuvre par le serveur d'authentification d'un procédé d'identification d'utilisateur conforme à l'une des revendications 1 à 9; - insertion des identifiants de première catégorie ou de seconde catégorie reçus en réponse à la requête, dans le document de partage; - envoi du document de partage aux utilisateurs destinataires de la liste.

11. Procédé selon la revendication 10, caractérisé en ce que en cas d'obtention d'identifiants de seconde catégorie, l'association identifiant de seconde catégorie et attribut de l'utilisateur correspondant est sauvegardée localement.

12. Procédé de service d'une donnée d'un document de partage créé selon un procédé conforme à l'une des revendications 10 à 11, caractérisé en ce que, suite à une requête d'obtention d'une donnée du document de partage provenant d'un utilisateur possédant un identifiant de première catégorie, il comporte les étapes suivantes: - obtention de l'identifiant de première catégorie à partir de la requête; - vérification de la présence de l'identifiant de première catégorie obtenu dans la liste d'utilisateurs destinataires du document de partage; - en cas de vérification négative, envoi d'une requête de mise en correspondance avec des identifiants de première catégorie, des identifiants de seconde catégorie présents dans la liste d'utilisateurs du document de partage, à un serveur d'authentification; - réception des identifiants de première catégorie correspondants et vérification de la correspondance d'au moins un identifiant de première catégorie reçu avec celui obtenu à partir de la requête; - en cas de vérification positive de la correspondance, service de la donnée.

13. Procédé selon la revendication 12, caractérisé en ce que l'utilisateur effectuant la requête d'obtention de donnée, s'est au préalable enregistré auprès du serveur d'authentification de façon à obtenir un identifiant de première catégorie à partir d'un identifiant de seconde catégorie qui lui avait été auparavant attribué.

14. Procédé selon la revendication 13, caractérisé en ce que suite à l'obtention d'un identifiant de première catégorie, l'utilisateur obtient une clé d'authentification calculée à partir de cet identifiant de première catégorie permettant l'obtention de la donnée requise.

15. Dispositif d'identification d'utilisateur dans un système de partage de données d'un réseau pair à pair, caractérisé en ce qu'il comporte: des moyens de réception d'une requête émanant d'un premier utilisateur, d'obtention d'un identifiant de première ou de seconde catégorie, à partir d'au moins un attribut d'un second utilisateur en vue de l'associer à un document de partage susceptible d'être partagé dans le système de partage, - des moyens d'attribution d'un identifiant de seconde catégorie au second utilisateur non encore enregistré dans le système de partage, - des moyens d'attribution d'un identifiant de première catégorie suite à l'enregistrement au système du second utilisateur, celui-ci ne pouvant accéder aux données du document de partage qu'après l'obtention de l'identifiant de première catégorie, et - des moyens d'enregistrement permettant de sauvegarder dans le système de partage, l'association identifiant de première catégorie et identifiant de seconde catégorie.

19. Dispositif selon la revendication 15, caractérisé en ce qu'il comporte en outre des moyens d'enregistrement permettant de sauvegarder dans le système de partage l'association attribut du second utilisateur et identifiant de seconde catégorie.

20. Dispositif selon la revendication 15 ou 16, caractérisé en ce qu'il comporte en outre: - des moyens de vérification de l'existence locale d'une association attribut du second utilisateur et identifiant de première catégorie, - des moyens de création d'un identifiant de seconde catégorie en fonction de l'attribut du second utilisateur; - des moyens d'enregistrement de l'association attribut second utilisateur et identifiant de seconde catégorie; - des moyens d'envoi (505) de l'identifiant de seconde catégorie au premier utilisateur.

18. Dispositif selon l'une des revendications 15 à 17, caractérisé en ce qu'il comporte en outre: - des moyens de réception d'une requête d'obtention de données d'un document de partage émanant d'un utilisateur via son attribut ou son identifiant de seconde catégorie; - des moyens de mise en oeuvre d'un protocole d'enregistrement avec ledit utilisateur permettant l'échange de données d'authentification; - des moyens d'association d'un identifiant de première catégorie audit utilisateur après son enregistrement; - des moyens d'enregistrement de l'association attribut dudit utilisateur, données d'authentification dudit utilisateur, identifiant de seconde catégorie et identifiant de première catégorie, seul l'identifiant de première catégorie permettant audit utilisateur d'accéder aux données requises.

19. Dispositif selon la revendication 18, caractérisé en ce qu'il comporte en outre des moyens de création d'une clé d'authentification à partir de l'identifiant de première catégorie, la clé d'authentification permettant l'accès aux données requises.

20. Dispositif selon l'une des revendications 15 à 19, caractérisé en ce que un attribut utilisateur est une caractéristique de l'utilisateur de type email, numéro de téléphone ou encore numéro de série d'un appareil utilisé par l'utilisateur.

21. Dispositif selon la revendication 20, caractérisé en ce qu'il comporte des moyens de calcul de l'identifiant de seconde catégorie en fonction d'au moins un attribut utilisateur.

22. Dispositif de création d'un document de partage dans un système de partage, le document contenant des données de partage et une liste d'utilisateurs destinataires du partage, un utilisateur destinataire possédant au moins un attribut et pouvant posséder un identifiant de première catégorie dans le cas où il a été préalablement enregistré dans le système de partage, caractérisé en ce qu'il comporte: - des moyens de vérification de la présence locale d'une association attribut des utilisateurs destinataires, identifiant de première catégorie de ces utilisateurs; - des moyens d'insertion des identifiants de première catégorie des utilisateurs destinataires dans le document de partage; des moyens d'envoi à un serveur d'authentification du système de partage d'une requête d'obtention d'identifiants de première catégorie ou de seconde catégorie des utilisateurs dont l'association attribut/identifiant de première catégorie n'est pas présente localement, le serveur d'authentification comprenant un dispositif d'identification d'utilisateur conforme à l'une des revendications 15 à 21; - des moyens d'insertion des identifiants de première catégorie ou de 15 seconde catégorie reçus en réponse à la requête, dans le document de partage; - des moyens d'envoi du document de partage aux utilisateurs destinataires. de la liste.

23. Dispositif selon la revendication 22, caractérisé en ce qu'il comporte des moyens de sauvegarde locale de l'association identifiant de seconde catégorie et attribut de l'utilisateur correspondant, en cas d'obtention d'identifiants de seconde catégorie.

24. Dispositif de service d'une donnée d'un document de partage créé par un dispositif conforme à l'une des revendications 22 à 23, caractérisé en ce qu'il comporte: - des moyens de réception d'une requête d'obtention d'une donnée du document de partage provenant d'un utilisateur possédant un identifiant de première catégorie; - des moyens d'obtention de l'identifiant de première catégorie à partir de la requête; - des moyens de vérification de la présence de l'identifiant de première catégorie obtenu dans la liste d'utilisateurs destinataires du document de partage; - des moyens d'envoi d'une requête de mise en correspondance avec des identifiants de première catégorie, des identifiants de seconde catégorie présents dans la liste d'utilisateurs du document de partage, à un serveur d'authentification; - des moyens de réception des identifiants de première catégorie correspondants et des moyens de vérification de la correspondance d'au moins un identifiant de première catégorie reçu avec celui obtenu à partir de la requête; - des moyens de service de la donnée.

25. Réseau de communication de type pair à pair, caractérisé en ce qu'il comporte au moins un dispositif d'identification d'utilisateur conforme à l'une des revendications 15 à 21, au moins un dispositif de création d'un document de partage conforme à l'une des revendications 22 à 23 et au moins un dispositif de service d'un document de partage conforme à la revendication 24.

26. Moyen de stockage d'informations lisible par un ordinateur ou un microprocesseur conservant des instructions d'un programme informatique, caractérisé en ce qu'il permet la mise en oeuvre d'un procédé d'identification d'utilisateur selon l'une quelconque des revendications 1 à 9 ou d'un procédé de création d'un document de partage selon l'une quelconque des revendications 10 à 11 ou d'un procédé de service d'une donnée selon l'une quelconque des revendications 12 à 14.

27. Moyen de stockage d'informations amovible, partiellement ou totalement, lisible par un ordinateur ou un microprocesseur conservant des instructions d'un programme informatique, caractérisé en ce qu'il permet la mise en oeuvre d'un procédé d'identification d'utilisateur selon l'une quelconque des revendications 1 à 9 ou d'un procédé de création d'un document de partage selon l'une quelconque des revendications 10 à 11 ou d'un procédé de service d'une donnée selon l'une quelconque des

revendications 12 à 14.

28. Produit programme d'ordinateur pouvant être chargé dans un appareil programmable, caractérisé en ce qu'il comporte des séquences d'instruction pour mettre en oeuvre un procédé d'identification d'utilisateur selon l'une quelconque des revendications 1 à 9 ou un procédé de création d'un document de partage selon l'une quelconque des revendications 10 à 11 ou un procédé de service d'une donnée selon l'une quelconque des revendications 12 à 14, lorsque ce programme est chargé et exécuté par l'appareil programmable.