Brevet FR2907623A1 — publié le 20080425

DOMAINE DE L'INVENTION La présente invention concerne des systèmes de gestion des droits numériques et en particulier la détermination de la validité d'un abonnement pour l'utilisation de contenus numériques. ARRIÈRE-PLAN DE L'INVENTION La protection des contenus numériques transférés entre des ordinateurs est de nos jours d'une importance capitale pour de nombreuses entreprises. Les entreprises tentent de sécuriser cette protection en mettant en oeuvre une certaine forme de traitement de gestion des droits numériques (DRM). Le terme DRM se réfère a une gamme de techniques utilisées pour contrôler l'accès à des contenus protégés par droit d'auteur et appliquer les termes et les conditions sur la base desquels les contenus numériques sont rendus disponibles aux utilisateurs. Les contenus numériques peuvent être des logiciels, des musiques, des vidéos, des actualités, des jeux, des images, ou tout autre contenu quelconque distribué sous forme numérique. Les parties de logiciel destinées à mettre en oeuvre le procédé DRM peuvent s'exécuter sur un serveur fiable ou contrôlé par le fournisseur de contenus tandis que d'autres parties du logiciel peuvent être chargées dans l'ordinateur utilisateur soit séparément soit en tant que partie d'une plateforme qui permet à l'utilisateur de télécharger et d'utiliser les contenus. De nombreux modèles ont été imaginés pour distribuer les contenus numériques. Dans certains cas, certains contenus peuvent être 2907623 2 obtenus gratuitement ou faire l'objet d'une acquisition de licence gratuite. Dans ces cas là, le traitement DRM applique simplement la distribution de contenus à des ordinateurs 5 autorisés sans qu'aucun objectif financier ne soit pris en compte. Dans d'autres cas, on utilise un modèle de téléchargement à la carte où un utilisateur paie un tarif à la session pour télécharger un contenu particulier. En 10 fonction des termes d'utilisation, l'utilisateur se voit accorder une utilisation limitée, une utilisation pour une certaine période de temps, ou une utilisation pour un certain nombre de téléchargements. 15 Dans d'autres cas encore, un modèle d 'abonnement est utilisé lorsque l'on requiert de l'utilisateur qu'il paie un tarif d 'abonnement périodique. Dans ces cas là, tant que l'abonnement est à jour, l'utilisateur peut 20 télécharger un nombre convenu (parfois illimité) de fichiers de contenus. L'utilisateur peut également utiliser les contenus (par exemple, écouter une piste musicale téléchargée, regarder un film téléchargé, jouer à un jeu téléchargé, 25 etc.) tant que l'abonnement est à jour. Donc, afin de protéger les droits du fournisseur de contenus, le traitement DRM doit être capable de déterminer la validité d'un abonnement lorsqu'un utilisateur souhaite utiliser les contenus. 30 Tant que l'utilisateur est en ligne, le traitement DRM peut contrôler la validité de l'abonnement en comparant l'heure et la date d 'expiration de l'abonnement avec l'heure et la date obtenues auprès d'une source fiable. 35 Cependant, une fois que l'utilisateur passe en 2907623 3 mode hors ligne, la tâche consistant à s'assurer de la validité de l'abonnement devient plus difficile. Lorsque l'utilisateur est en mode hors ligne, le procédé DRM doit reposer sur la 5 source habituellement non fiable indiquant l'heure sur le dispositif de l'utilisateur. Dans de nombreux environnements d'exploitation, tels que Mac OS X d'Apple ou Windows de Microsoft, un utilisateur peut facilement 10 changer l'horloge système du dispositif utilisateur. Par exemple, afin de mettre en défaut un système DRM qui repose uniquement sur l'horloge système du dispositif utilisateur, l'utilisateur peut acheter un abonnement pour 15 une durée limitée, télécharger des contenus, et continuer à utiliser les contenus téléchargés hors ligne en changeant l'horloge système pour la ramener à une date et une heure auxquelles l'abonnement est toujours valide. Donc, on a 20 toujours besoin, dans la technique, de déterminer si un abonnement d'un utilisateur est ou non toujours valide sans que cela ne repose que sur l'horloge du dispositif utilisateur, en particulier dans des environnements où 25 l'utilisateur n'est pas toujours connecté à un dispositif d'application DRM. RÉSUMÉ DE L'INVENTION Certains modes de réalisation mettent à disposition un procédé destiné à déterminer si 30 un abonnement pour l'utilisation de contenus numériques sur un dispositif utilisateur a ou non expiré. Le procédé compare une première image exempte d'éléments en conflit d'un premier ensemble d'entités dans le dispositif 35 utilisateur avec une seconde image exempte 2907623 4 d 'éléments en conflit pour un second ensemble d 'entités dans le dispositif utilisateur à un second moment. Sur la base de la comparaison, le procédé détermine si l'abonnement a ou non 5 expiré. Dans certains modes de réalisation, chaque image exempte d'éléments en conflit comporte une population d'entités à croissance lente dans le dispositif utilisateur, une population d'entités 10 à croissance rapide dans le dispositif utilisateur, et une population d'entités à croissance moyenne dans le dispositif utilisateur. Dans d 'autres modes de réalisation, chaque image exempte d'éléments en conflit comporte 15 différents types de populations et/ou un nombre plus important ou moindre de type de populations. Dans certains modes de réalisation, la comparaison des images exemptes d'élément en 20 conflit comprend l'étape consistant à comparer un ensemble d'attributs d'un ensemble d'entités dans le dispositif utilisateur avec un ensemble de paramètres fonctionnels acceptables. Dans certains modes de réalisation, la comparaison 25 comprend les étapes de calcul et de comparaison de statistiques calculées pour un ensemble d 'attributs d'un ensemble d'entités dans le dispositif utilisateur. Certains modes de réalisation calculent au moins partiellement les 30 statistiques au moment de la génération des images exemptes d'éléments en conflit et/ou au moment de la comparaison des images exemptes d 'éléments en conflit. Certains modes de réalisation mettent à 35 disposition un procédé de gestion des droits 2907623 5 numériques (DRM) qui compare les informations pour un premier ensemble d'attributs du dispositif utilisateur à un premier moment avec des informations d'un second ensemble 5 d'attributs à un second moment. Sur la base de la comparaison, le procédé détermine si l'environnement du dispositif utilisateur (par exemple, l'horloge, les fichiers, les répertoires, etc. du dispositif utilisateur) a 10 ou non été manipulé pour contourner une protection DRM afin d'accéder à un ensemble de contenus sur le dispositif utilisateur. Certains modes de réalisation mettent à disposition un procédé de distribution de 15 contenus numériques. Le procédé distribue des contenus sur la base d'un abonnement et utilise un algorithme d'évolution pour déterminer si un abonnement pour l'utilisation de contenus numériques a ou non expiré. Le procédé détermine 20 si une population d'entités liée à un dispositif utilisateur a ou non évolué par rapport à une population précédemment échantillonnée. Dans certains modes de réalisation, le procédé sélectionne les entités et leurs attributs à 25 partir d'une population habituelle sur la base de leurs aptitudes, et modifie les entités sélectionnées afin de former une nouvelle population pour évaluer une évolution de la prochaine génération desdites entités. 30 BRÈVE DESCRIPTION DES DESSINS Pour les besoins de l'explication, plusieurs modes de réalisation sont exposés sur les Figures suivantes. 2907623 6 La Figure 1 illustre un système de distribution de contenus numériques de certains modes de réalisation. La Figure 2 illustre un traitement de 5 renouvellement d'abonnement de certains modes de réalisation. La Figure 3 illustre un traitement de contrôle de validité d'abonnement avec l'analyse du cycle de vie dans certains modes de 10 réalisation. La Figure 4 illustre de manière conceptuelle une image exempte d'éléments en conflit qui est un instantané de plusieurs populations de fichiers. 15 La Figure 5 illustre des exemples de deux images exemptes d'éléments en conflit générées à deux moments différents. La Figure 6 illustre un traitement de construction de l'image exempte d'éléments en 20 conflit au cours de l'essai d'évolution naturelle dans certains modes de réalisation. La Figure 7 illustre un traitement utilisé dans certains modes de réalisation pour déterminer si l'essai d'évolution naturelle est 25 requis. La Figure 8 illustre différents essais accomplis au cours de l'essai d'évolution naturelle dans certains modes de réalisation. La Figure 9 illustre de manière conceptuelle 30 un système informatique avec lequel certains modes de réalisation sont mis en oeuvre. 2907623 7 DESCRIPTION DÉTAILLÉEE DE L'INVENTION Dans la description suivante, de nombreux détails sont exposes pour les besoins de l'explication. Cependant, un homme du métier 5 constatera que l'invention peut être mise en pratique sans utiliser ces détails spécifiques. Dans d'autre cas, des structures et dispositifs bien connus sont représentés sous la forme de schémas de principe afin de ne pas embrouiller 10 la description de l'invention avec des détails inutiles. Certains modes de réalisation mettent à disposition un procédé destiné à déterminer si un abonnement pour l'utilisation de contenus 15 numériques sur un dispositif utilisateur a ou non expiré. Le procédé compare une première image exempte d'éléments en conflit d'un premier ensemble d'entités dans le dispositif utilisateur avec une seconde image exempte 20 d'éléments en conflit pour un second ensemble d'entités dans le dispositif utilisateur à un second moment. Sur la base de la comparaison, le procédé détermine si l'abonnement a ou non expiré. 25 Dans certains modes de réalisation, chaque image exempte d'éléments en conflit comporte une population d'entités à croissance lente dans le dispositif utilisateur, une population d'entités à croissance rapide dans le dispositif 30 utilisateur, et une population d'entités à croissance moyenne dans le dispositif utilisateur. Dans d'autres modes de réalisation, chaque image exempte d'éléments en conflit comporte différents types de populations et un 2907623 8 nombre plus important ou moindre de types de populations. Dans certains modes de réalisation, la comparaison de l'image exempte d'éléments en 5 conflit comprend l'étape consistant à comparer un ensemble d'attributs d'un ensemble d'entités dans le dispositif utilisateur avec un ensemble de paramètres fonctionnels acceptables. Dans certains modes de réalisation, la comparaison 10 comprend les étapes de calcul et de comparaison de statistiques calculées pour un ensemble d'attributs d'un ensemble d'entités dans le dispositif utilisateur. Certains modes de réalisation calculent au moins partiellement les 15 statistiques au moment de la génération des images exemptes d'éléments en conflit et/ou au moment de la comparaison des images exemptes d'éléments en conflit. Certains modes de réalisation mettent à 20 disposition un procédé de gestion des droits numériques (DRM) qui compare des informations pour un premier ensemble d'attributs du dispositif utilisateur à un premier moment avec des informations d'un second ensemble 25 d'attributs à un second moment. Sur la base de la comparaison, le procédé détermine si l'environnement du dispositif utilisateur (par exemple, l'horloge, les fichiers, les répertoires, etc. du dispositif utilisateur) a 30 ou non été manipulé pour contourner une protection DRM afin d'accéder à un ensemble de contenus sur le dispositif utilisateur. Certains modes de réalisation mettent à disposition un procédé de distribution de 35 contenus numériques. Le procédé distribue des 2907623 9 contenus sur la base d'un abonnement et utilise un algorithme d'évolution pour déterminer si un abonnement pour l'utilisation de contenus numériques a ou non expiré. Le procédé détermine 5 si une population d'entités liées à un dispositif utilisateur a ou non évolué par rapport à une population précédemment échantillonnée. Dans certains modes de réalisation, le procédé sélectionne les entités 10 et leurs attributs à partir d'une population actuelle sur la base de leur aptitude, et modifie les entités sélectionnées afin de former une nouvelle population pour évaluer une évolution de la prochaine génération desdites 15 entités. Plusieurs modes de réalisation plus détaillés de l'invention sont décrits dans les sections ci-dessous. La section I met à disposition une vue d'ensemble du système de 20 distribution de contenus de certains modes de réalisation. Cette discussion est suivie d'une discussion sur un modèle d'abonnement utilisé par certains modes de réalisation dans une section II. Ensuite, une section III décrit une 25 analyse du cycle de vie que certains modes de réalisation utilisent pour mettre à l'essai la validité d'un abonnement utilisateur. Enfin, une section IV décrit un système informatique utilisé par certains modes de réalisation de 30 cette invention. 1. VUE D'ENSEMBLE La Figure 1 illustre un système de distribution de contenus 100 de certains modes de réalisation. Ce système de distribution de 35 contenus distribue des contenus d'une manière 2907623 10 qui protège les droits numériques (c'est-à-dire, qui garantit l'utilisation légale) des contenus. Tel que représenté sur la Figure 1, le système de distribution de contenus 100 comporte un 5 ensemble de serveurs DRM 110 et un dispositif utilisateur de réception de contenus 115. Bien qu'un seul dispositif utilisateur 115 soit représenté sur la Figure 1, le système de distribution de contenus 100 peut servir à de 10 nombreux dispositifs utilisateurs. La Figure 1 illustre le dispositif utilisateur 115 sous la forme d'un ordinateur portable. Cependant, le dispositif utilisateur 115 peut être un ordinateur de bureau, un assistant numérique 15 personnel (PDA), un lecteur audio, un lecteur vidéo, ou tout autre dispositif utilisateur quelconque capable de recevoir les contenus en ligne. Le dispositif utilisateur 115 se connecte à l'ensemble de serveurs DRM 110 par 20 l'intermédiaire d'un réseau informatique 120, tel qu'un réseau local d'entreprise, un réseau étendu, un réseau des réseaux (par exemple, l'Internet), etc. Par l'intermédiaire de la connexion réseau, 25 le dispositif utilisateur 115 communique avec l'ensemble de serveurs DRM 110 pour acheter, acquérir une licence, mettre à jour, ou sinon obtenir des contenus dans certains modes de réalisation. Par conséquent, bien que dans 30 certains modes de réalisation l'ensemble de serveurs DRM 110 vende ou accorde des licences aux dispositifs utilisateurs pour contenus, cet ensemble, dans d'autres modes de réalisation, ne vend pas ou n'accorde pas de licence pour les 35 contenus. Par exemple, dans certains modes de 2907623 11 réalisation, l'ensemble de serveurs DRM 110 applique simplement la distribution de contenus à des dispositifs utilisateurs autorisés sans aucun objectif financier. 5 Dans certains modes de réalisation, l'ensemble de serveurs DRM 110 comporte un serveur de capture de contenus qui met les contenus cryptés à disposition d'un dispositif utilisateur 115 par l'intermédiaire du réseau 10 120, après qu'un autre serveur dans l'ensemble de serveurs DRM 110 a déterminé que le dispositif utilisateur 115 peut obtenir des contenus. Dans certains modes de réalisation, le système 100 utilise de multiples serveurs de 15 capture pour mettre en mémoire cache des contenus à divers emplacements sur le réseau, afin d'améliorer la vitesse et l'efficacité du téléchargement de contenus d'un bout à l'autre du réseau. 20 Dans certains modes de réalisation, les contenus téléchargés peuvent être copiés depuis le dispositif utilisateur 115 jusque dans un ou plusieurs autres dispositifs utilisateurs. Par exemple, la Figure 1 illustre l'autre dispositif 25 utilisateur sous la forme d'un lecteur multimédia portable 125. Le lecteur multimédia portable peut être tout dispositif quelconque capable d'utiliser les contenus téléchargés. Par exemple, le lecteur portable pourrait être un 30 lecteur de musique, un lecteur vidéo, une console de jeu, un appareil photographique, etc. Dans certains modes de réalisation, le lecteur multimédia portable peut être connecté au dispositif utilisateur 115 via une connexion 35 telle qu'une connexion USB (Universal Serial 2907623 12 5 Bus), IEEE 1394, autre connexion technique. De nombreux distribuer des infrarouge, sans fil, ou toute quelconque connue dans la modèles ont été imaginés pour contenus numériques. Dans certains cas, certains contenus peuvent être obtenus gratuitement ou leur licence peut être acquise gratuitement. Dans ces exemples, le serveur DRM 110 applique simplement la 10 distribution de contenus à des ordinateurs autorisés sans qu'aucun objectif financier ne soit pris en compte. Dans d'autres cas, on utilise un modèle de téléchargement à la carte où un utilisateur paie un tarif à la session 15 pour télécharger un contenu particulier. En fonction des termes d'utilisation, l'utilisateur se voie accorder une utilisation limitée, une utilisation pour une certaine période de temps, ou une utilisation pour un certain nombre de 20 téléchargements. Dans d'autres cas encore, un modèle d'abonnement est utilisé lorsque l'on requiert de l'utilisateur qu'il paie un tarif d'abonnement périodique. Dans ces cas là, tant 25 que l'abonnement est à jour, l'utilisateur peut télécharger un nombre convenu (parfois illimité) de fichiers de contenus. L'utilisateur peut également utiliser les contenus (par exemple, écouter une piste musicale téléchargée, regarder 30 un film téléchargé, jouer à un jeu téléchargé, etc.) tant que l'abonnement est à jour. Donc, afin de protéger les droits du fournisseur de contenus, le traitement DRM doit être capable de déterminer la validité de l'abonnement lorsqu'un 35 utilisateur souhaite utiliser les contenus. 2907623 13 Tant que l'utilisateur est en ligne, l'ensemble de serveurs DRM 110 de certains modes de réalisation peut contrôler la validité de l'abonnement en comparant l'heure et/ou la date 5 d'expiration de l'abonnement avec l'heure et/ou la date obtenue auprès d'une source fiable. Cependant, une fois que l'utilisateur passe en mode hors ligne, la tâche consistant à s'assurer de la validité de l'abonnement repose sur 10 l'analyse du cycle de vie de certains modes de réalisation. Certains modes de réalisation reposent sur l'analyse du cycle de vie pour déterminer la validité d'un abonnement d'utilisateur même lorsque le dispositif 15 utilisateur 115 est connecté à l'ensemble de serveurs DRM 110 directement ou par l'intermédiaire d'un autre dispositif utilisateur. II. MODÈLE D'ABONNEMENT 20 A. Renouvellement d'abonnement Tel que décrit ci-dessus, un modèle d'abonnement est utilisé dans certains systèmes de distribution de contenus. Afin que le propriétaire des contenus soit équitablement 25 dédommagé, un traitement destiné à garantir la validité de l'abonnement est requis. La Figure 2 illustre de manière conceptuelle un traitement de renouvellement d'abonnement de certains modes de réalisation. Tel que représenté sur la Figure 30 2, une fois que l'utilisateur est passé en mode hors ligne (à l'étape 205), le traitement détermine (à l'étape 210) si l'utilisateur possède ou non un abonnement et si son abonnement a ou non expiré. 2907623 14 Si l'utilisateur a un abonnement valide, le traitement passe à l'étape 220 qui est décrite ci-dessous. D'autre part, si l'utilisateur n'a pas un abonnement valide, le traitement guide 5 l'utilisateur (à l'étape 215) pour qu'il achète ou renouvelle un abonnement pour une certaine période de temps. Ensuite (à l'étape 220), le traitement met à jour les informations d'abonnement de l'utilisateur sur le dispositif 10 utilisateur 115. À ce stade, les informations d'abonnement sur le dispositif utilisateur 115 sont synchronisées avec les informations sur le serveur DRM 110. Tant que l'utilisateur a un abonnement valide, l'utilisateur peut 15 télécharger (à l'étape 225) le nombre convenu de contenus dans le dispositif utilisateur 115. Pendant que l'utilisateur est en ligne, certains modes de réalisation vérifient la validité de l'abonnement au moyen d'une source fiable 20 indiquant l'heure. Une fois que l'utilisateur est passé en mode hors ligne (à l'étape 230), le module DRM s'exécutant sur le dispositif utilisateur utilise cependant l'analyse du cycle de vie de certains modes de réalisation pour 25 s'assurer que l'abonnement pour l'utilisation des contenus numérique n'a pas expiré. B. Contrôle de validité d'abonnement avec analyse du cycle de vie Afin de déterminer si l'heure indiquée par 30 le dispositif utilisateur a ou non été falsifiée ou si l'environnement utilisateur a ou non été manipulée de manière malveillante, certains modes de réalisation mettent en oeuvre une technique destinée à accomplir une analyse du 35 cycle de vie sur le dispositif utilisateur. 2907623 15 L'analyse du cycle de vie peut être accomplie aussi bien sur un dispositif utilisateur (par exemple, le dispositif utilisateur 115) qui se connecte directement à l'ensemble de serveurs 5 DRM par l'intermédiaire du réseau que sur un dispositif utilisateur (par exemple, le dispositif utilisateur 125) qui se connecte à l'ensemble de serveurs DRM par l'intermédiaire d'autres dispositifs utilisateurs. 10 L'analyse du cycle de vie est accomplie sur un dispositif utilisateur au moyen du dispositif utilisateur. Pour accomplir l'analyse du cycle de vie, plusieurs groupes de fichiers, de dossiers, de répertoires, de volumes, ou de 15 toutes autres entités de dispositifs utilisateurs avec des comportements connus ou prévisibles sont sélectionnés et analysés. Périodiquement, un instantané de certains attributs de ces entités (par exemple, la date 20 du dernier accès d'un fichier, la date de création d'un fichier, la taille d'un dossier, etc.) est pris et sauvegardé. Certains modes de réalisation calculent les statistiques pour certains des attributs et sauvegardent ces 25 calculs. L'évolution de ces populations, par exemple des changements dans les attributs ainsi que l'absence ou la présence de certains fichiers ou répertoires, est ensuite analysée pour déterminer si les changements observés 30 entre deux instantanés sont en rapport avec le temps écoulé indiqué par l'horloge système du dispositif utilisateur. La Figure 3 illustre de manière conceptuelle le traitement de contrôle de validité 35 d'abonnement 300 de certains modes de 2907623 16 réalisation. À l'étape 305, le traitement détermine que l'utilisateur souhaite utiliser un contenu téléchargé sur la base du modèle d'abonnement. Par exemple, l'utilisateur 5 pourrait souhaiter écouter une piste musicale, regarder un film, lire un article, regarder une image, jouer à un jeu, etc. À l'étape 310, le traitement utilisateur non expiré. utilise l'horloge du dispositif pour contrôler si l'abonnement a ou Si l'abonnement a expiré sur la base 10 de l'horloge l'utilisateur utilisateur, il est demandé à (à l'étape 315) de passer en mode en ligne et de renouveler l'abonnement. Sinon, le traitement utilise (à l'étape 320) un essai 15 d'évolution naturelle pour déterminer si l'horloge du dispositif utilisateur peut avoir été modifiée ou si l'environnement du dispositif utilisateur a été manipulé. Les détails de l'essai d'évolution naturelle sont décrits dans 20 les sections suivantes. Si l'essai d'évolution détermine (à l'étape 320) que l'environnement du dispositif utilisateur a été manipulé ou que l'horloge du dispositif utilisateur n'est pas fiable (et 25 donc, que l'abonnement pourrait avoir expiré), il est demandé à l'utilisateur (à l'étape 325) de passer en mode en ligne et de synchroniser l'abonnement avec l'ensemble de serveurs DRM 110. Sinon, si à l'étape 330 l'essai d'évolution 30 détermine une évolution normale, l'utilisateur est autorisé à utiliser les contenus téléchargés qui ont été obtenus par l'intermédiaire de l'abonnement de l'utilisateur. Dans certains modes de réalisation, l'essai d'évolution est 35 effectué en même temps que l'utilisateur utilise 2907623 17 les contenus. Dans ces modes de réalisation (non représentés), il est demandé à l'utilisateur d'effectuer une synchronisation après utilisation du contenu actuel par l'utilisateur. 5 Dans d'autres modes de réalisation, on empêche l'utilisateur d'utiliser les contenus téléchargés jusqu'à ce que l'utilisateur ait pu effectuer une synchronisation avec le serveur DRM 110. 10 Dans les discussions suivantes, l'analyse du cycle de vie est décrite au moyen de plusieurs exemples. Cependant, un homme du métier constaterait que l'invention peut être mise en pratique sans utilisation de ces détails 15 spécifiques. Par exemple, l'analyse du cycle de vie peut être accomplie sur tout dispositif utilisateur quelconque (tel que des ordinateurs personnels, des lecteurs de musique, des lecteurs vidéo, des assistants numériques 20 personnels, des appareils photographiques, etc.) qui est capable d'exécuter un logiciel pour accomplir l'analyse du cycle de vie et qui comporte un ensemble de fichiers ou d'autres entités dont les attributs peuvent faire l'objet 25 d'une acquisition pour effectuer l'analyse. De même, l'analyse du cycle de vie n'est pas limitée aux attributs et aux catégories de fichiers représentés dans les exemples et peut être mise en pratique au moyen d'autres 30 attributs et d'autres entités de dispositifs utilisateurs pour effectuer l'analyse. III. ESSAI D'ÉVOLUTION NATURELLE Dans certains modes de réalisation, l'analyse du cycle de vie comporte un essai 35 d'évolution naturelle. L'essai d'évolution 2907623 18 naturelle est accompli par comparaison de l'instantané actuel des attributs d'une population avec un instantané précédant des attributs de la population pour déterminer si 5 les changements sont acceptables. L'essai d 'évolution naturelle garantit également que le reste de l'environnement utilisateur n'a pas été modifié pour tromper l'analyse du cycle de vie. Sur la base de la comparaison de l'instantané 10 actuel avec l'instantané précédent, l'essai d 'évolution naturelle détermine si l'environnement du dispositif utilisateur a ou non été manipulé pour contourner une protection DRM afin d'accéder à des contenus sur le 15 dispositif utilisateur. Tel que décrit ultérieurement ci-dessous, les populations et leurs attributs à surveiller sont sélectionnés de façon à ce qu'aucun des deux instantanés ne puisse être le même. Donc, 20 chaque instantané génère une image exempte d 'éléments en conflit (CFI) pour les populations sélectionnées. Certains modes de réalisation sauvegardent certains attributs des populations sélectionnées dans l'image CFI. Certains modes 25 de réalisation calculent des statistiques de certains attributs de différentes populations et sauvegardent les statistiques dans l'image CFI. Dans certains modes de réalisation, l'image CFI contient une combinaison d'attributs individuels 30 de certains membres de population (par exemple, certains attributs de fichiers, répertoires, volumes, etc. particuliers qui ont un comportement connu) ainsi que des statistiques de portions de populations dans leur ensemble 35 (par exemple, une taille moyenne totale de 2907623 19 l'ensemble des fichiers dans une certaine population). Dans certains modes de réalisation, l'image CFI contient également des informations de noms et/ou d'emplacements pour identifier 5 chaque population et ses membres. A. L'image Exempte d'Éléments en Conflit (CFI) 1. Sélection des populations et des attributs Certains modes de réalisation prennent des instantanés de certaines populations de 10 fichiers, dossiers, répertoires, volumes, ou de toutes autres entités quelconques d'un matériel ou d'un logiciel du dispositif utilisateur ayant un comportementconnu ou prévisible et sauvegardent leurs attributs (ou des 15 statistiques de ces attributs) dans une image exempte d'éléments en conflits (CFI). Dans certains modes de réalisation, chaque instantané crée une image CFI séparée. La sélection de ces populations (pour 20 générer l'image CFI) dépend du dispositif utilisateur particulier. Certains modes de réalisation effectuent la sélection sur la base de l'environnement du dispositif utilisateur, par exemple, le système d'exploitation 25 particulier qui s'exécute sur le dispositif utilisateur, des applications s'exécutant sur le dispositif utilisateur, ainsi que la configuration matérielle du dispositif utilisateur. Au cours de la phase de 30 développement du logiciel qui met en oeuvre l'analyse du cycle de vie, la structure, le type, les attributs, et les comportements de chaque population sont soigneusement analysés pour déterminer un ensemble d'entités (telles 35 que des fichiers, des dossiers, des répertoires, 2907623 20 des volumes, des profils matériels, etc.) avec un comportement prévisible. On peut utiliser des méthodes heuristiques et par essais et erreurs, ainsi qu'une étude des 5 documents de description et des guides de développement du système pour identifier un ensemble d'entités du dispositif et leurs attributs spécifiques à utiliser dans l'analyse du cycle de vie. Certains modes de réalisation 10 identifient différents groupes d'entités avec un comportement similaire et créent une population à partir de ces groupes. Par exemple, certains modes de réalisation identifient des entités à évolution lente, moyenne, et rapide dans un 15 dispositif utilisateur et les affectent à différentes populations. Les populations dans le dispositif utilisateur sont analogues aux populations humaines. Certaines populations humaines, par 20 exemple, des tribus vivant dans des zones reculées, changent très lentement. Dans une certaine période de temps, très peu de personnes vont et viennent dans ces tributs et ces tribus ne comptent que très peu de naissances et de 25 décès. D'autre part, dans des zones métropolitaines de grande taille, les gens vont et viennent à tout moment et le nombre de naissances et de décès est assez important. Il existe cependant d'autres villes ou localités 30 présentant des évolutions modérées. Par conséquent, certains modes de réalisation analysent trois types de population pour créer un instantané de population à évolution lente, de population à évolution 35 moyenne, et de population à évolution rapide. Un 2907623 21 homme du métier constatera que les populations d 'entités dans un dispositif utilisateur n'ont pas besoin d'être limitées aux trois populations mentionnées dans l'exemple ci-dessus, puisque 5 des niveaux additionnels ou moindres de granularité peuvent être utilisés. Certains des exemples donnés ci-dessous utilisent cependant les trois catégories de populations à évolution lente, moyenne et rapide dans un but de 10 simplicité. L'essai d'évolution naturelle de certains modes de réalisation met en oeuvre un algorithme génétique qui détermine si une population d 'entités liées au dispositif utilisateur 15 (c'est-à-dire, des entités dans le dispositif utilisateur ou des entités dans l'environnement du dispositif utilisateur, par exemple, des entités dans un réseau local d'entreprise connecté au dispositif utilisateur) a ou non 20 évolué par rapport à une population précédemment échantillonnée. Des algorithmes génétiques constituent une classe particulière d 'algorithmes d'évolution qui utilisent des techniques inspirées de la théorie de 25 l'évolution de Darwin telles que l'hérédité, la mutation, la sélection naturelle, et le brassage génétique. L'essai d'évolution naturelle de ces modes de réalisation commence avec une certaine 30 population. L'évolution commence à partir du premier ensemble d'entités dans la population et évolue de génération en génération. Dans chaque génération, on évalue la population entière pour déterminer si l'évolution reflète le temps 35 écoulé indiqué par le dispositif utilisateur. 2907623 22 Dans ces modes de réalisation, des entités et leurs attributs sont sélectionnés à partir de la population actuelle sur la base de leurs aptitudes, modifiés (c'est-à-dire, soumis à une 5 mutation ou un brassage génétique) afin de former une nouvelle population pour évaluer l'évolution de la prochaine génération. La Figure 4 illustre de manière conceptuelle une image CFI 400 qui comporte un instantané de 10 trois types de populations 405 à 415 dans un dispositif utilisateur. Par comparaison avec les tribus humaines, ces populations peuvent être à évolution lente, à évolution rapide, ou quelque part entre ces deux évolutions. Par exemple, 15 dans certains systèmes d'exploitation, les fichiers et répertoires systèmes constituent une population importante. Bien que la population puisse comporter de nombreux membres, la population est statique à l'exception des dates 20 de dernier accès des membres de la population. L'utilisateur peut fréquemment utiliser les entités systèmes mais ne peut que rarement les mettre à niveau ou les mettre à jour. D'autre part, les fichiers et répertoires 25 utilisateurs peuvent constituer une population importante à évolution rapide. Un utilisateur peut quotidiennement naviguer sur Internet et ajouter des fichiers de témoin ("cookies") et télécharger des fichiers. L'utilisateur peut 30 éditer, modifier, créer, et effacer des fichiers et des répertoires dans la zone utilisateur. Un autre exemple de population peut être un groupe d'applications. Dans certains modes de réalisation, les fichiers applications peuvent 35 constituer une petite population qui est 2907623 23 principalement statique. Un homme du métier constatera que des fichiers et répertoires systèmes, utilisateurs et applications sont juste des exemples des entités ayant un 5 comportement connu ou prévisible. Une fois que des populations différentes et leurs attributs pertinents sont déterminés, des méthodes heuristiques et par essais et erreurs seront utilisées pour déterminer une fréquence 10 correcte avec laquelle des instantanés des populations et de leurs attributs seront pris. Les instantanés seront pris à cette fréquence pour identifier des changements prévus dans un dispositif utilisateur. Par exemple, la Figure 5 15 illustre un exemple de deux instantanés 505 et 510 d'un système pris approximativement à deux jours d'intervalle. Sur cette Figure, les nombres sont hypothétiques et sont utilisés uniquement à titre d'exemple. 20 Tel que représenté sur la Figure 5, le fichier "WindowUpdate.log" situé dans le dossier "C:/WINDOWS" se trouve sur les deux images CFI (instantanés) 505 et 510. Les deux instantanés 515 et 520 de ce fichier montrent que la taille 25 de ce fichier a augmenté de 1 650 kilo-octets (Ko) à 1 860 Ko dans l'intervalle de temps au cours duquel les deux instantanés ont été pris. Tel que cela est représenté, les attributs "date de modification" et "date d'accès" ont également 30 changé tandis que l'attribut "date de création" n'a pas changé. Le fait de savoir si les deux instantanés de ce fichier passeront ou non avec succès l'essai d'évolution dépend de la façon dont les méthodes 35 heuristiques et d'évolution avaient prévu 2907623 24 l'évolution de ce fichier dans l'intervalle de temps entre les deux instantanés. Sur la base des informations heuristiques, par essais et par erreurs, dans différents documents systèmes et 5 fabricants, l'essai d'évolution aurait un seuil de changement prédéterminé pour différents attributs de ce fichier. Par exemple, supposons que sur la base des expérimentations l'analyse du cycle de vie a 10 déterminé que la taille de ce fichier spécifique (qui est un fichier journal du système) changera d'au moins 10 kilo octets (Ko) par jour et qu'il fera l'objet d'un accès et d'une modification au moins une fois par jour. La date de création du 15 fichier ne changera cependant pas. Dans ces hypothèses, ce fichier spécifique passera avec succès l'essai d'évolution. On ne détecte rien d'imprévu, en ce qui concerne ce fichier, au cours de la période d'approximativement deux 20 jours indiquée par l'horloge du dispositif utilisateur. D'autre part, si l'analyse du cycle de vie avait déterminé que la taille du fichier devrait changer d'environ 150 Ko par jour, le fichier ne passera pas avec succès l'essai 25 d'évolution. Le fichier Acrobat.exe représenté sur la Figure 5 constitue un autre exemple de fichier pour lequel on prend deux instantanés 525 et 530. Tel que représenté, ce fichier est situé 30 dans le dossier "C:\ProgramFiles\Adobe\Acrobat 5.0". Supposons qu'il s'agisse d'un fichier application et que l'essai d'évolution ne prévoit pas un changement le concernant à l'exception de l'attribut "Date d'accès". 35 Cependant, tel que représenté dans l'exemple, 2907623 25 l'attribut "Date d'accès" de l'instantané pris le 03/04/2006 à 20:56 h montre une date de dernier accès au 05/04/2006 à 17:48 h. Ceci indiquera à l'essai d'évolution que l'horloge du 5 dispositif utilisateur qui indique que le dernier instantané a été pris le 03/04/2006 à 20:56 h peut ne pas avoir cela a été représenté à Figure 3, il sera 10 passer en mode en abonnement. Tel que décrit modes de réalisation, contenir des statistiques pour tout ou partie 15 des différentes populations. L'exemple conceptuel représenté sur la Figure 5 se compose des deux instantanés 535 et 540 pris pour un groupe de dossiers qui contiennent des fichiers de témoin pour différents utilisateurs. Dans 20 certains systèmes d'exploitation, plusieurs utilisateurs peuvent avoir accès à un dispositif utilisateur particulier et chaque utilisateur peut se voir attribuer sa propre zone de l'espace mémoire (par exemple, un disque dur) 25 pour recevoir des fichiers de témoin téléchargés vers le disque dur pendant que l'utilisateur navigue sur Internet. Dans l'exemple représenté sur les instantanés 535 et 540, l'image CFI concerne des statistiques sur bon nombre ou 30 l'ensemble des dossiers du disque dur qui contiennent des fichiers de témoin utilisateur. Dans d'autres modes de réalisation, non représentés, des dossiers individuels contenus dans des fichiers de témoin pour des demandé à ligne et été correct. l'étape 325 Tel que sur la l'utilisateur de synchroniser son ci-dessus, dans certains l'image CFI peut également 2907623 26 utilisateurs individuels peuvent être surveillés. Tel que représenté, les deux instantanés 535 et 540 montrent que la taille totale de cette 5 population a augmenté de 147 618 octets à 168 618 octets entre les deux instantanés. De même, le nombre d'objets dans la population est passé de 99 à 120. L'exemple montre également que la date de création la plus ancienne, la date de la 10 dernière modification, et la date du dernier accès de la population sont également surveillées. Tel que représenté, les attributs "Date de dernière modification" et "Date de dernier accès" ont changé entre les instantanés 15 tandis que l'attribut "Date de création" la plus ancienne n'a pas changé. Que les deux instantanés 535 et 540 passent ou non avec succès l'essai d'évolution dépend de la façon dont la méthode heuristique d'analyse 20 du cycle de vie prévoyait l'évolution de cette population au cours du temps écoulé de deux jours, une heure et 24 minutes que l'horloge du dispositif utilisateur montre entre les deux instantanés. Tel que représenté, le premier 25 instantané a été pris le 01/04/2006 à 19:32 h et le second instantané a été pris le 03/04/2006 à 20:56 h. Sur la base des informations heuristiques et par essais et erreurs dans différents documents systèmes et fabricants, 30 l'essai d'évolution aurait un seuil de changement prédéterminé pour différents attributs de cette population. Par exemple, supposons que sur la base des expérimentations, l'analyse du cycle de vie 35 détermine que la taille d'une population 2907623 27 spécifique qui contient des fichiers de témoin changerait d'au moins 5 Ko par jour mais sans dépasser 20 Ko par jour. De même, supposons que l'analyse du cycle de vie prévoit qu'il y aura 5 au moins 5 fichiers de témoin par jour, on modifiera et/ou on accèdera à la population au moins une fois par jour et la date de création la plus ancienne ne changera pas. Dans ces hypothèses, les deux instantanés 535 et 540 10 passerait avec succès l'essai d'évolution. On ne détecte rien d'imprévu dans cette population au cours de la période indiquée par l'horloge du dispositif utilisateur. D'autre part, si la méthode heuristique d'analyse du cycle de vie 15 avait déterminé que la taille de la population changerait d'au moins 15 Ko par jour, ou qu'il y aurait au moins 20 objets par jours ajoutés à la population, la population n'aurait pas passé avec succès l'essai d'évolution. 20 Les exemples ci-dessus ont été donnés au moyen d'un système d'exploitation Microsoft Windows XP Professional . Un homme du métier constaterait que d'autres systèmes d'exploitation peuvent avoir une structure 25 différente de fichiers et de dossiers, une nomenclature différente pour leur structure de fichier, peuvent avoir d'autres attributs qui peuvent être surveillés, etc. De surcroît, les instantanés peuvent être pris périodiquement 30 et/ou sur la base de certains évènements (par exemple, dès qu'un utilisateur essaie d'accéder à un contenu téléchargé ou dès qu'un utilisateur a accédé à un nombre prédéterminé de contenus téléchargés). De même, les seuils utilisés par 35 l'essai d'évolution peuvent avoir une 2907623 28 granularité différente d'un jour ou même d'une certaine période de temps. Les seuils peuvent être basés sur une fréquence d'accès à des contenus téléchargés ou tout autres critères 5 acceptables quelconques déterminés par des méthodes par essais et erreurs, heuristiques, etc. 2. Construction de l'image CFI La Figure 6 illustre un traitement 600 10 destiné à construire une image exempte d'éléments en conflit dans certains modes de réalisation. Au cours de la phase de développement du logiciel d'analyse du cycle de vie, certains modes de réalisation identifient 15 plusieurs populations pour chaque type d'environnement de dispositif utilisateur. En cours d'exécution, le traitement d'analyse du cycle de vie sélectionne les populations qui sont identifiées pour le type particulier de 20 dispositif utilisateur. Dans certains modes de réalisation, les membres des populations sont sélectionnés avant que chaque instantané ne soit pris. Dans d'autres modes de réalisation, les membres des populations sont sélectionnés moins 25 fréquemment. Tel que représenté, le traitement identifie initialement (à l'étape 605) une population à évolution rapide sur le dispositif utilisateur. Le traitement obtient (à l'étape 610) des 30 informations auprès du dispositif utilisateur sur les attributs des membres des populations. Tel qu'indiqué ci-dessus, des exemples de certains attributs sont la taille, la date de création, la date de dernière modification, la 35 date de dernier accès, l'absence ou la présence 2907623 29 de certains fichiers ou répertoires, etc. Dans certains modes de réalisation, les attributs sélectionnés de l'environnement dans lequel le dispositif utilisateur fonctionne sont également 5 inclus dans l'image CFI. Un homme du métier constaterait que d'autres attributs peuvent également être utilisés sans s'écarter de l'enseignement de l'invention. Le traitement sauvegarde ensuite (à l'étape 610) les 10 informations dans l'image CFI. Les informations sauvegardées peuvent être les valeurs actuelles des attributs sélectionnés de fichiers ou dossiers particuliers ou d'autres entités. Les informations sauvegardées peuvent également se 15 présenter sous la forme de statistiques calculées pour certains membres de la population. Par exemple, les statistiques peuvent comprendre un écart moyen, un écart maximum, un écart minimum, un écart moyen 20 absolu, un écart type, ou toute autre statistique quelconque calculée pour une partie ou l'ensemble des membres de la population. De manière similaire, le traitement identifie (à l'étape 615) une population 25 d'entités de dispositif à évolution moyenne. À l'étape 620, le traitement obtient des informations auprès du dispositif utilisateur sur les attributs de membres de la population et les ajoute à l'image CFI. De manière similaire, 30 le traitement identifie (à l'étape 625) une population d'entités de dispositif à évolution lente. Le traitement obtient ensuite des informations (à l'étape 630) auprès du dispositif utilisateur sur les attributs de 35 membres de population et ajoute les informations 2907623 30 à l'image CFI. Bien que le traitement 600 soit représenté comme identifiant et collectant des informations pour trois types de population, l'essai d'évolution n'est ni limité à trois 5 populations ni limité à la seule sélection de population sur la base de la rapidité de leur évolution. Donc, le traitement 600 peut identifier plusieurs populations sur la base de critères déterminés au cours du développement de 10 la phase d'évolution pour le dispositif utilisateur particulier et peut utiliser ces populations pour générer l'image CFI. B. Détermination du Fait de Savoir si l'Essai d'Évolution est Requis 15 Dans certains modes de réalisation, l'essai d 'évolution n'est pas accompli chaque fois qu'un utilisateur accède à des contenus téléchargés. Différents modes de réalisation utilisent différents critères pour déterminer si l'essai 20 d'évolution a ou non besoin d'être accompli. Par exemple, certains modes de réalisation peuvent accomplir l'essai d'évolution une fois sur plusieurs accès utilisateurs à tout contenu quelconque, une fois sur plusieurs accès 25 utilisateurs à un contenu particulier, aléatoirement, ou selon d'autres critères quelconques déterminés au cours du développement de l'essai d'évolution. Certains modes de réalisation peuvent utiliser une combinaison de 30 plusieurs critères pour déterminer si l'essai d 'évolution doit ou non être accompli. De même, tel que décrit ci-dessous, une fois que l'essai d 'évolution a déterminé que l'utilisateur a besoin de synchroniser l'abonnement, certains 35 modes de réalisation établissent un drapeau 2907623 31 interne qui empêche l'utilisateur d'accéder aux contenus sans qu'aucun essai d'évolution supplémentaire quelconque ne soit accompli jusqu'à ce que l'abonnement soit synchronisé. 5 La Figure 7 illustre un traitement 700 que certains modes de réalisation utilisent pour déterminer si l'essai d'évolution doit ou non être accompli. Le traitement est activé lorsqu'il peut être nécessaire d'accomplir 10 l'essai d'évolution. Par exemple, on se réfère à la Figure 3 sur laquelle le traitement 700 de certains modes de réalisation peut être activé avant que l'opération 320 ne soit accomplie. Donc, dans ces modes de réalisation, l'opération 15 320 (et l'opération 325 si nécessaire) seront uniquement accomplies si le traitement 700 détermine que l'essai d'évolution doit être accompli. Tel que représenté sur la Figure 7, le 20 traitement détermine (à l'étape 705) si les critères pour accomplir l'essai d'évolution ont ou non été satisfaits. Par exemple, si dans un mode de réalisation particulier, l'essai d'évolution est accompli tous les 10 accès 25 utilisateurs aux contenus qui requièrent un abonnement, le traitement contrôle si l'utilisateur a ou non déjà accédé aux contenus au moins dix fois. Si les critères ne sont pas satisfaits, le traitement à l'étape 710 met à 30 jour les critères, par exemple, incrémente un compteur interne, et sort. Sinon, le traitement construit (à l'étape 707) une image CFI en prenant un instantané des populations qui sont identifiées pour l'essai d'évolution naturelle. 35 Ensuite, le traitement active (à l'étape 715) 2907623 32 l'essai d'évolution naturelle. Des détails de l'essai d'évolution ne sont pas ici représentés mais sont représentés ailleurs dans ce mémoire descriptif. 5 À l'étape 720, le traitement contrôle si l'essai d'évolution naturelle indique ou non que l'évolution est acceptable. Si la réponse est oui, le traitement réinitialise (à l'étape 725) les critères pour accomplir l'essai d'évolution. 10 Le traitement sort ensuite. Sinon, le traitement établit (à l'étape 730) un drapeau interne pour empêcher l'utilisateur d'utiliser les contenus qui requièrent un abonnement pour y accéder. Ce drapeau interne est réinitialisé une fois que 15 l'utilisateur a synchronisé l'abonnement. Le traitement sort ensuite. C. Type d'Essais Accomplis Certains modes de réalisation accomplissent plusieurs essais au cours de l'essai 20 d'évolution. Certains modes de réalisation accomplissent des essais individuels ainsi que globaux. Des essais individuels comprennent l'étape consistant à contrôler l'évolution des attributs des entités individuelles (fichiers, 25 dossiers, volumes, etc.) qui ont un comportement prévisible. Si l'un quelconque (ou un certain nombre) de ces essais échouent, l'essai d'évolution échouerait dans son ensemble. Les essais globaux comprennent l'étape 30 consistant à contrôler les statistiques pour de nombreuses entités dans une population. Un exemple d'essai global a été décrit ci-dessus en référence aux instantanés 535 et 540 sur la Figure 5. Plusieurs essais globaux peuvent être 35 accomplis sur différents groupes d'entités dans 2907623 33 une population. Si l'un quelconque (ou un certain nombre) de ces essais échouent, l'essai d 'évolution échouerait dans son ensemble. Certains modes de réalisation accomplissent un 5 essai d'évolution global pour un ensemble d 'entités par comparaison d'un calcul pondéré (par exemple, une somme pondérée) des changements dans un ensemble d'attributs de l'ensemble d'entités avec un seuil pour 10 déterminer si l'ensemble d'entités passe ou non avec succès l'essai d'évolution global. Par exemple, l'équation (A) suivante représente une somme pondérée des changements dans l'ensemble de n attributs (taille des fichiers, 15 répertoires, etc.) d'un ensemble d'entités . L Z=i* AZ (A) où n est le nom d'attributs de l'ensemble 20 d'entités, Di est la quantité de l'ième attribut modifié et Wi est le coefficient de pondération donné à la modification de l'ième attribut. Cette somme pondérée est ensuite comparée à un seuil prédéterminé. Pour certains essais 25 globaux, on peut utiliser deux seuils pour comparer les changements à une plage avec un seuil inférieur et supérieur acceptable. La Figure 8 illustre de manière conceptuelle un traitement 800 qui accomplit plusieurs essais 30 différents au cours d'un épisode d'essai d 'évolution. Bien que l'exemple de la Figure 8 soit représenté avec trois populations, l'essai d 'évolution peut être accompli avec tout nombre quelconque de populations. De même, pour mieux 35 illustrer le concept de différents essais 2907623 34 accomplis, la Figure 8 représente uniquement les opérations qui déterminent si chaque groupe d'essai a ou non été réussi. Les autres détails des essais d'évolution, tels que les opérations 5 destinées à accomplir les essais ne sont pas représentés pour les besoins de la simplification. À l'étape 805, le traitement contrôle si les essais individuels pour la population à 10 évolution rapide ont ou non été passés avec succès. Si ces essais échouent, le traitement passe à l'étape 840 pour indiquer que l'essai a échoué. Le traitement passe ensuite à l'étape 845 qui est davantage décrite ci-dessous. Sinon, 15 le traitement contrôle (à l'étape 810) si les essais globaux pour les populations à évolution rapide ont ou non été passés avec succès. Si ces essais échouent, le traitement passe à l'étape 840 pour indiquer que l'essai d'évolution a 20 échoué. Sinon, le traitement contrôle (à l'étape 815) si tous les essais individuels pour la population à évolution moyenne ont ou non été passés avec succès. Si ces essais échouent, le 25 traitement passe à l'étape 840 pour indiquer que l'essai d'évolution a échoué. Sinon, le traitement contrôle (à l'étape 820) si les essais globaux pour les populations à évolution moyenne ont ou non été passés avec succès. Si 30 ces essais échouent, le traitement passe à l'étape 840 pour indiquer que l'essai d'évolution a échoué. Sinon, à l'étape 825, le traitement contrôle si tous les essais individuels pour la 35 population à évolution lente ont ou non été 2907623 35 passés avec succès. Si ces essais échouent, le traitement passe à l'étape 840 pour indiquer que l'essai d'évolution a échoué. Sinon, le traitement contrôle (à l'étape 830) si les 5 essais globaux pour les populations à évolution lente ont ou non été passés avec succès. Si ces essais échouent, le traitement passe à l'étape 840 pour indiquer que l'essai d'évolution a échoué. 10 Enfin, si tous les essais ont été passés avec succès, le traitement passe à l'étape 835 pour indiquer que l'essai d'évolution a été passé avec succès. Le traitement sauvegarde (à l'étape 845) l'image CFI actuelle à utiliser en 15 tant qu'ancien instantané lorsque l'essai d'évolution est ensuite accompli. Le traitement sort ensuite. Bien que l'exemple sur la Figure 8 montre qu'on accomplit aussi bien des essais individuels que des essais globaux pour chaque 20 population, dans certains modes de réalisation, pour certaines populations, les essais peuvent être limités soit à des essais individuels soit à des essais globaux. IV. SYSTÈME INFORMATIQUE 25 La Figure 9 illustre de manière conceptuelle un système informatique avec lequel certains modes de réalisation de l'invention sont mis en oeuvre. Le système informatique 900 comporte un bus 905, un processeur 910, une mémoire système 30 915, une mémoire morte 920, un dispositif de stockage permanent 925, des dispositifs d'entrée 930, et des dispositifs de sortie 935. Le bus 905 représente collectivement tous les bus système, périphériques, et du jeu de 35 circuit qui supportent une communication parmi 2907623 36 des dispositifs internes du système informatique 900. Par exemple, le bus 905 connecte de manière communicante le processeur 910 avec la mémoire morte 920, la mémoire système 915, et le 5 dispositif de stockage permanent 925. À partir de ces diverses unités de mémoire, le processeur 910 récupère des instructions à exécuter et des données à traiter afin d'exécuter les traitements de l'invention. La 10 mémoire morte (ROM) 920 stocke des données et des instructions statiques dont le processeur 910 et d'autres modules du système informatique ont besoin. Le dispositif de stockage permanent 925, d'autre part, est un dispositif de mémoire 15 à double accès. Ce dispositif est une unité de mémoire non volatile qui stocke des instructions et des données même lorsque le système informatique 900 est hors tension. Certains modes de réalisation de l'invention utilisent un 20 dispositif de stockage de masse (tel qu'un dispositif magnétique ou optique et son lecteur de disque correspondant) comme dispositif de stockage permanent 925. D'autres modes de réalisation utilisent un dispositif de stockage 25 amovible (tel qu'une disquette ou un disque zip , et son lecteur de disque correspondant) comme dispositif de stockage permanent. Comme le dispositif de stockage permanent 925, la mémoire système 915 est un dispositif de 30 mémoire à double accès. Cependant, à la différence du dispositif de stockage 925, la mémoire système est une mémoire à double accès volatile, telle qu'une mémoire vive. La mémoire système stocke certaines des instructions et 2907623 37 données dont le processeur a besoin au moment de l'exécution. Les instructions et/ou données nécessaires pour accomplir des traitements de certains modes 5 de réalisation sont stockées dans la mémoire système 915, le dispositif de stockage permanent 925, la mémoire morte 920, ou toutecombinaison quelconque de ces trois éléments. Par exemple, les diverses unités de mémoire peuvent contenir 10 des instructions pour le traitement d'objets multimédia conformément à certains modes de réalisation. À partir de ces diverses unités de mémoire, le processeur 910 récupère les instructions à exécuter et des données à traiter 15 afin d'exécuter le traitement de certains modes de réalisation. Le bus 905 se connecte également aux dispositifs d'entrée et de sortie 930 et 935. Les dispositifs d'entrée permettent à 20 l'utilisateur de communiquer les informations et de sélectionner des ordres à envoyer au système informatique. Les dispositifs d'entrée 930 comportent des claviers alphanumériques et des touches de déplacement du curseur. Les 25 dispositifs de sortie 935 affichent des images générées par le système informatique. Par exemple, ces dispositifs affichent les dispositions de conception de circuit intégré (CI). Les dispositifs de sortie comprennent des 30 imprimantes et des dispositifs d'affichage, tels que des dispositifs d'affichage cathodiques (CRI) ou des dispositifs d'affichage à cristaux liquides (LCD). Enfin, tel que représenté sur la Figure 9, 35 le bus 905 couple également un ordinateur 900 à 2907623 38 un réseau 965 par l'intermédiaire d'un adaptateur réseau (non représenté). De cette manière, l'ordinateur peut faire partie d'un réseau d'ordinateurs (tel qu'un réseau local 5 d'entreprise ("LAN"), un réseau étendu ("WAN"), ou un réseau Intranet) ou un réseau des réseaux (tel que l'Internet). On peut utiliser l'un quelconque ou l'ensemble des composants du système informatique 900 conjointement avec 10 l'invention. Cependant, un homme du métier constatera que d'autres configurations système quelconques peuvent également être utilisées conjointement avec l'invention. Bien que l'on ait décrit l'invention en se 15 référant à de nombreux détails spécifiques, un homme du métier constatera que l'invention peut être réalisée sous d'autres formes spécifiques sans s'éloigner de l'esprit de l'invention. Par exemple, l'analyse du cycle de vie peut être 20 accomplie sur tout dispositif utilisateur quelconque (tel que des ordinateurs personnels, des lecteurs de musique, des lecteurs vidéo, des assistants numériques personnels, des appareils photographiques, etc.) capable d'exécuter un 25 logiciel pour accomplir l'analyse du cycle de vie et comportant un ensemble de fichiers ou d'autres entités dont les attributs peuvent être acquis pour effectuer l'essai. De même, l'analyse du cycle de vie n'est pas limitée aux 30 catégories d'attributs et de fichiers représentés dans les exemples ci-dessous et peut être mise en pratique au moyen d'autres attributs et d'autres entités de dispositif utilisateur pour effectuer l'essai. Par exemple, 35 une population d'entités dans un dispositif 2907623 39 utilisateur n'a pas besoin d'être limitée aux trois populations mentionnées dans certains des exemples ci-dessus, puisque des niveaux de granularité additionnels ou moindres peuvent 5 être utilisés. À d'autres endroits, divers changements peuvent être apportés et les équivalents peuvent remplacer des éléments décrits sans s'éloigner de la véritable portée de la présente invention. 10 Par exemple, les fichiers et répertoires systèmes, utilisateurs, et applications ont été représentés en tant qu'exemple des entités ayant un comportement connu ou prévisible. De nombreuses entités et populations peuvent être 15 identifiées pour une utilisation dans l'essai d'évolution. Par exemple, dans certains modes de réalisation, le profil matériel du dispositif utilisateur est également utilisé pour l'analyse du cycle de vie. Bien que dans les exemples cidessus, on ait utilisé des entités locales du dispositif utilisateur pour l'analyse du cycle de vie, dans certains modes de réalisation, des entités dans l'environnement du dispositif utilisateur, y compris un réseau local 25 d'entreprise (LAN) ou un réseau LAN sans fil (WLAN) sont également prises en compte. De même, l'essai d'évolution peut être mis en oeuvre dans des dispositifs utilisateurs exécutant différents systèmes d'exploitation. 30 Ces systèmes d'exploitation peuvent avoir une structure différente de fichiers et de dossiers, une nomenclature différente pour leur structure de fichier, peuvent avoir d'autres attributs qui peuvent être surveillés, etc. Par exemple, 35 certains systèmes d'exploitation peuvent 2907623 utiliser les termes répertoires et sous-répertoires tandis que d'autres utilisent les termes dossiers et sous-dossiers. De même, le système informatique représenté sur la Figure 9 5 est juste un exemple des nombreuses configurations matérielles différentes qu'un dispositif utilisateur peut avoir. Par exemple, un lecteur multimédia portable peut avoir une configuration matérielle différente de celle 10 représentée sur la Figure 9. De surcroît, les instantanés peuvent être pris périodiquement et/ou sur la base de certains évènements, par exemple, dès qu'un utilisateur essaie d'accéder à un contenu 15 téléchargé ou dès qu'un utilisateur a accédé à un certain nombre prédéterminé de contenus téléchargés. De même, l'essai d'évolution peut ne pas être accompli à des intervalles de temps fixes. À la place, l'accomplissement de l'essai 20 d'évolution peut se faire sur la base de la fréquence d'accès aux contenus qui requièrent un abonnement ou sur la base de tout autre critère acceptable quelconque déterminé par des méthodes par essais et erreurs, heuristiques, etc. Ainsi, 25 un homme du métier comprendra que l'invention n'est pas limitée aux détails illustrés précédemment, mais doit plutôt être définie selon les revendications annexées. REVENDICATIONS 1. Procédé comprenant les étapes consistant a) identifier un environnement de 5 dispositif particulier dans lequel on accèdera à une pluralité de contenus ; b) identifier un ensemble d'entités sur l'environnement de dispositif particulier qui ont des attributs avec des comportements 10 prévisibles ; et c) définir un procédé de gestion des droits numériques (DRM) à utiliser au cours d'une exécution d'un dispositif comprenant l'environnement de dispositif particulier, le 15 procédé DRM déterminant si les changements des attributs de chaque entité sont ou non tels qu'attendus. 2. Procédé selon la revendication 1, dans lequel l'environnement de dispositif particulier 20 comprend un ensemble de fichiers sur le dispositif. 3. Procédé selon la revendication 1, dans lequel l'environnement de dispositif particulier comprend un ensemble de répertoires sur le 25 dispositif. 4. Procédé selon la revendication 1, dans lequel l'environnement de dispositif particulier comprend un logiciel de système d'exploitation. 5. Procédé selon la revendication 1, dans 30 lequel l'environnement de dispositif particulier comprend un réseau auquel se connectera le dispositif. 6. Procédé selon la revendication 1, dans lequel l'environnement de dispositif particulier à 2907623 42 comprend une configuration matérielle du dispositif. 7. Procédé selon la revendication 1, dans lequel les attributs avec des comportements prévisibles sont déterminés par essais et erreurs. 8. Procédé selon la revendication 1, dans lequel les attributs avec des comportements prévisibles sont déterminés au moyen d'une méthode heuristique. 9. Procédé selon la revendication 1, dans lequel les attributs avec des comportements prévisibles sont déterminés par l'étude de documents systèmes de l'environnement de dispositif particulier. 10. Procédé selon la revendication 1, dans lequel le dispositif comprenant l'environnement de dispositif particulier est un ordinateur. 11. Procédé selon la revendication 1, dans lequel le dispositif comprenant l'environnement de dispositif particulier est un lecteur portable. 12. Support lisible par un ordinateur stockant un programme à exécuter, le programme comprenant des ensembles d'instructions destinés à a) analyser des attributs d'un ensemble d'entités sur un dispositif à différents moments lorsqu'une source de temps fiable n'est pas disponible ; et b) permettre l'accès aux supports numériques lorsque les attributs ont changé dans les seuils attendus. 13. Support lisible par un ordinateur selon 35 la revendication 12, dans lequel le programme 2907623 43 comprend en outre un ensemble d'instructions destiné à exiger du dispositif qu'il se synchronise à un abonnement pour utiliser les supports numériques par connexion communicante à 5 un ordinateur distant ayant une source de temps fiable. 14. Support lisible par un ordinateur selon la revendication 12, dans lequel le programme comprend en outre un ensemble d'instructions 10 destiné à estimer un temps écoulé entre différents moments par analyse des changements dans lesdits attributs.