FR 2972090 A1 20120831 FR 1252266 A 20120313 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 à 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 séparément soit en tant plateforme qui permet à télécharger et d'utiliser les De nombreux modèles ont distribuer les contenus utilisateur soit que partie d'une l'utilisateur de contenus. été imaginés pour numériques. Dans certains cas, certains contenus peuvent être 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 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 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. 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 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é, 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. 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. Cependant, une fois que l'utilisateur passe en 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 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 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 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 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ù 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 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 utilisateur avec une seconde image exempte 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é. 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 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/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 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 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 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 à disposition un procédé de gestion des droits 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 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 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 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 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 à 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. BRÈVE DESCRIPTION DES DESSINS Pour les besoins de l'explication, plusieurs modes de réalisation sont exposés sur les Figures suivantes. 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 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 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. 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 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 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 un système informatique avec lequel certains modes de réalisation sont mis en oeuvre. DESCRIPTION DÉTAILLÉEE DE L'INVENTION Dans la description suivante, de nombreux détails sont exposés pour les besoins de l'explication. Cependant, un homme du métier 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 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 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 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é. 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 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 2972090 s 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 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 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 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 à 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 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 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 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 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 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 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 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 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 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 contenus distribue des contenus d'une manière 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 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 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 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 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, 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 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 contenus. Par exemple, dans certains modes de réalisation, l'ensemble de serveurs DRM 110 applique simplement la distribution de contenus à des dispositifs utilisateurs autorisés sans aucun objectif financier. 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 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 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. 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 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 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 telle qu'une connexion USB (Universal Serial Bus), IEEE 1394, infrarouge, sans fil, ou toute autre connexion quelconque connue dans la technique. De nombreux modèles ont été imaginés pour distribuer des 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 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 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 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 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 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 utilisateur souhaite utiliser les contenus. 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 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 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 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 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 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 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é. 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 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 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 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 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 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 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 cycle de vie sur le dispositif utilisateur. 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 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. 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 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 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 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 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é d 'abonnement 300 de certains modes de 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 pourrait souhaiter écouter une piste musicale, regarder un film, lire un article, regarder une image, jouer à un jeu, etc. À l'étape 310, le traitement utilise l'horloge du dispositif utilisateur pour contrôler si l'abonnement a ou non expiré. Si l'abonnement a expiré sur la base de l'horloge utilisateur, il est demandé à l'utilisateur (à l'étape 315) de passer en mode en ligne et de renouveler l'abonnement. Sinon, le traitement utilise (à l'étape 320) un essai 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 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 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 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 effectué en même temps que l'utilisateur utilise 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. 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. 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 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 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 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 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 d 'évolution naturelle. L'essai d'évolution ls 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 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é 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 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, 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 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 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 (par exemple, une taille moyenne totale de 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 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 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 comportement connu ou prévisible et sauvegardent leurs attributs (ou des 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 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 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 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 que des fichiers, des dossiers, des répertoires, 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 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 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 dispositif utilisateur et les affectent à différentes populations. Les populations dans le dispositif utilisateur sont analogues aux populations humaines. Certaines populations humaines, par exemple, des tribus vivant dans des zones reculées, changent très lentement. Dans une certaine période de temps, vont et viennent dans ces ne comptent que très peu 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 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 moyenne, et de population à évolution rapide. Un très peu de personnes tributs et ces tribus de naissances et de 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 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 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 (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 é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 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 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 écoulé indiqué par le dispositif utilisateur. 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 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 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, 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 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 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 é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 constituer une petite population qui est 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 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 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 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. 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 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 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 heuristiques et d'évolution avaient prévu 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 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 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 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 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 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é 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". Cependant, tel que représenté dans l'exemple, 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 dispositif utilisateur qui indique que le dernier instantané a été pris le 03/04/2006 à 20:56 h peut ne pas avoir été correct. Tel que cela a été représenté à l'étape 325 sur la Figure 3, il sera demandé à l'utilisateur de passer en mode en ligne et synchroniser son abonnement. Tel que décrit ci-dessus, dans certains modes de réalisation, l'image CFI peut également contenir des statistiques pour tout ou partie 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 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) 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 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 utilisateurs individuels peuvent être surveillés. Tel que représenté, les deux instantanés 535 et 540 montrent que la taille totale de cette 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 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 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 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 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, 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 détermine que la taille d'une population 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 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 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 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. 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 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 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 l'essai d'évolution peuvent avoir une s 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 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 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 plusieurs populations pour chaque type d'environnement de dispositif utilisateur. En cours d'exécution, le traitement d'analyse du qui de de cycle de vie sélectionne les populations sont identifiées pour le type particulier dispositif utilisateur. Dans certains modes les membres des populations avant que chaque instantané ne d'autres modes de réalisation, réalisation, sélectionnés pris. Dans membres des populations fréquemment. Tel que représenté,le traitement identifie sont soit les sont sélectionnés moins initialement (à l'étape 605) une population à évolution rapide sur le dispositif utilisateur. Le traitement obtient (à l'étape 610) des 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 date de dernier accès, l'absence ou la présence 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 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 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 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 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 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, 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 membres de population et ajoute les informations à 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 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 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 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 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 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 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 modes de réalisation établissent un drapeau 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é. 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 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 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 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 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 à 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. Ensuite, le traitement active (à l'étape 715) 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. À 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. 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 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 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, 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 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 accomplis sur différents groupes d'entités dans 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 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 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, répertoires, etc.) d'un ensemble d'entités . n I wi *Ai (A) i=1 où n est le nom d'attributs de l'ensemble 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 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 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 illustrer le concept de différents essais 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 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 à é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, 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 é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 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 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 population à é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é. Sinon, le traitement contrôle (à l'étape 830) si les 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é. 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 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 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 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 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 circuit qui supportent une communication parmi 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 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 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 à 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 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 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 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 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 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 toute combinaison quelconque de ces trois éléments. Par exemple, les diverses unités de mémoire peuvent contenir 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 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 à 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 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 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, le bus 905 couple également un ordinateur 900 à 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 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 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 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 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 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 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, une population d'entités dans un dispositif 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 ê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. 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 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 ci-dessus, 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 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. 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, certains systèmes d'exploitation peuvent 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 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 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 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 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, 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. REVENDICATIONS1. Méthode pour s'assurer de la validité d'une protection par gestion des droits numériques (DRM) sur un dispositif, la méthode consistant à : recevoir une demande d'accès à un contenu stocké sur le dispositif, le contenu étant protégé par un abonnement limité dans le temps ; lorsque l'abonnement n'est pas arrivé à expiration sur la base d'une horloge du dispositif, identifier un premier ensemble d'attributs d'une pluralité d'entités du dispositif ; comparer le premier ensemble d'attributs de la pluralité d'entités du dispositif avec un deuxième ensemble d'attributs stocké des entités du dispositif à un moment antérieur dans le temps afin d'identifier les différences entre le premier ensemble d'attributs actuel et le deuxième ensemble d'attributs antérieur ; déterminer si les différences entre les premier et deuxième ensembles d'attributs sont telles qu'attendues sur la base d'une quantité de temps allant du moment antérieur au moment actuel de l'horloge du dispositif, dans laquelle des différences différentes sont attendues pour des attributs différents ; et lorsque les différences sont telles qu'attendues, permettre l'accès au contenu protégé. 2. Méthode selon la revendication 1, dans laquelle une pluralité desdits attributs sont des valeurs associées aux entités du dispositif, dans laquelle la comparaison des ensembles d'attributs consiste à comparer lesdites valeurs. 3. Méthode selon la revendication 1, dans laquelle une pluralité desdits attributs sont des statistiques associées à la pluralité d'entités du dispositif, dans laquelle la comparaison des premier et deuxième ensembles d'attributs consiste à comparer les statistiques. 4. Méthode selon la revendication 1, dans laquelle les attributs comprennent au moins un attribut associé à un composant matériel du dispositif. 5. Méthode selon la revendication 1, dans laquelle le premier ensemble d'attributs comprend une première image exempte d'éléments en conflit des entités, dans laquelle le deuxième ensemble d'attributs comprend une seconde image exempte d'éléments en conflit des entités. 6. Méthode selon la revendication 5, dans laquelle chaque image exempte d'éléments en conflit comprend une population d'entités à évolution rapide dans le dispositif et une population d'entités à évolution lente du dispositif, dans laquelle on s'attend à ce que la différence entre les attributs des entités à évolution lente soit inférieure à la différence entre les attributs des entités à évolution rapide. 7. Méthode selon la revendication 5, dans laquelle chaque image exempte d'éléments en conflit comprend une population d'entités à croissance lente dans le dispositif, une population d'entités à croissance rapide dans le dispositif, et une population d'entités à croissance moyenne dans le dispositif. 8. Méthode pour s'assurer de la validité d'une protection par gestion des droits numériques (DRM) sur un dispositif, la méthode consistant à : générer une première image exempte d'éléments en conflit pour au moins deux populations d'entités d'un dispositif à un premier moment, la première image exempte d'éléments en conflit comprenant une pluralité d'attributs d'entités, les entités comprenant au moins deux populations d'entités dont les attributs changent au fil du temps à des vitesses différentes ; stocker la première image exempte d'éléments en conflit ; générer une seconde image exempte d'éléments en conflit pour lesdites populations d'entités du dispositif à un second moment, la seconde image exempte d'éléments en conflit comprenant une seconde pluralité d'attributs des entités, les images exemptes d'éléments en conflit étant générées de telle sorte que la première image exempte d'éléments en conflit ne soit jamais la même que la seconde image exempte d'éléments en conflit; et sur la base d'une comparaison des première et seconde images exempte d'éléments en conflit générées, déterminer si le dispositif a été manipulé pour obtenir l'accès au contenu multimédia protégé sur le dispositif. 9. Méthode selon la revendication 8, dans laquelle les populations d'entités sont choisies pour les images exempte d'éléments en conflit basées sur des vitesses attendues d'évolution des entités. 10. Méthode selon la revendication 8 , d a n s laquelle le dispositif n'effectue la comparaison et la détermination qu'après avoir tenté de s'assurer de la validité de l'abonnement limité dans le temps par connexion à une source fiable sur un réseau. 11. Méthode selon la revendication 10, dans laquelle le dispositif est incapable de se connecter à la source fiable. 12. Méthode pour s'assurer de la validité d'un abonnement à gestion des droits numériques (DRM) pour accéder à un contenu stocké sur un dispositif, le procédé consistant à : identifier un premier ensemble d'attributs du dispositif que l'on s'attend à voir changer à une première vitesse au fil du temps et un deuxième ensemble d'attributs du dispositif que l'on s'attend à voir changer à une seconde vitesse au fil du temps, la seconde vitesse étant différente de la première vitesse ; mesurer les premier et deuxième ensembles d'attributs du dispositif à un premier moment ; mesurer les premier et deuxième ensembles d'attributs du dispositif à un deuxième moment ultérieur dans le temps au premier moment ; déterminer si (i) une différence des mesures du premier ensemble d'attributs est en corrélation avec la première vitesse attendue et si (ii) une différence des mesures du deuxième ensemble d'attributs est en corrélation avec la seconde vitesse attendue ;sur la base des déterminations, identifier si un utilisateur a tenté d'accéder au contenu stocké sur le dispositif en contournant l'abonnement DRM. 13. Méthode selon la revendication 12, dans laquelle le fait d'identifier si un utilisateur a tenté d'accéder au contenu stocké sur le dispositif en contournant l'abonnement DRM consiste à identifier si l'utilisateur a modifié une horloge sur le dispositif afin d'accéder au contenu une fois l'abonnement écoulé. 14. Méthode selon la revendication 12, d a n s laquelle le fait d'identifier si un utilisateur a tenté d'accéder au contenu stocké sur le dispositif en contournant l'abonnement DRM consiste à identifier si l'utilisateur a modifié un répertoire sur le dispositif. 15. Méthode selon la revendication 12, dans laquelle le fait d'identifier si un utilisateur a tenté d'accéder au contenu stocké sur le dispositif en contournant l'abonnement DRM consiste à identifier si l'utilisateur a modifié un fichier sur le dispositif. 16. Support lisible par ordinateur non transitoire stockant un programme de gestion des droits numériques (DRM) comprenant des ensembles d'instructions qui lorsqu'elles sont exécutées par un processeur entraînent l'exécution par le processeur des opérations consistant à : déterminer si une source fiable externe de temps est disponible ; lorsque la source fiable externe de temps est disponible, utiliser la source fiable externe de temps pour déterminer si un abonnement limité dans le tempspour accéder au contenu protégé sur le dispositif a expiré ; lorsque la source fiable externe de temps n'est pas disponible et qu'une horloge du dispositif indique que l'abonnement pour accéder au contenu sur le dispositif n'a pas expiré : identifier un premier ensemble d'attributs d'une pluralité d'entités du dispositif ; identifier les différences entre le premier ensemble d'attributs et un deuxième ensemble d'attributs de la pluralité d'entités du dispositif à un moment antérieur dans le temps ; lorsque les différences entre les premier et deuxième ensembles d'attributs sont telles qu'attendues sur la base d'une quantité de temps allant du moment antérieur au moment actuel de l'horloge du dispositif, permettre l'accès au contenu protégé ; et lorsque les différences ne sont pas telles qu'attendues sur la base de la quantité de temps, demander au dispositif de synchroniser l'abonnement avec un serveur externe afin d'accéder au contenu protégé. 17. Support lisible par ordinateur non transitoire selon la revendication 16, comprenant en outre un ensemble d'instructions pour déterminer si un utilisateur du dispositif a manipulé le dispositif afin de contourner l'abonnement. 18. Support lisible par ordinateur non transitoire selon la revendication 16, dans lequel les attributs comprennent l'absence et la présence d'au moins une entité dans le dispositif. 19. Méthode selon la revendication 16, dans laquelle les attributs comprennent au moins l'un de la taille, de la date de création, de la dernière date de modification, de la dernière date d'accès, de l'absence et de la présence de fichiers et de répertoires du dispositif. 20. Méthode de gestion des droits numériques (DRM) destinée à déterminer si un dispositif a été manipulé, la méthode consistant à : à un premier moment, recevoir une première demande d'accès à un contenu protégé par un abonnement limité dans le temps sur le dispositif ; comparer, au premier moment, un premier ensemble d'attributs d'une pluralité d'entités du dispositif au premier moment à un deuxième ensemble d'attributs stocké de la pluralité d'entités du dispositif à un deuxième moment, le deuxième moment étant antérieur dans le temps au premier moment ; n'accorder l'accès au contenu au premier moment que lorsque des différences entre les attributs comparés sont telles qu'attendues pour les attributs particuliers ; à un troisième moment ultérieur dans le temps au premier moment, recevoir une seconde demande d'accès au contenu ; comparer, au troisième moment, un troisième ensemble d'attributs de la pluralité d'entités du dispositif au troisième moment au premier ensemble d'attributs au premier moment ; et n'accorder l'accès au contenu au troisième moment que lorsque des différences entre les attributscomparés sont telles qu'attendues pour les attributs particuliers. 21. Méthode selon la revendication 20, dans laquelle les vitesses attendues sont basées sur l'analyse antérieure des entités pour un environnement de dispositif particulier. 22. Méthode selon la revendication 20, dans laquelle les comparaisons ne sont effectuées que lorsque le dispositif est incapable de se connecter à une source fiable pour vérifier l'abonnement.