FR2823399A1 - Procede de gestion d'acces securise a des ressources numeriques d'un serveur, et systeme associe - Google Patents

Abstract

L'invention concerne un procédé de gestion sécurisée de l'accès d'un utilisateur à une ressource numérique importable par l'intermédiaire d'un réseau sur un terminal de l'utilisateur, le procédé mettant en oeuvre une application permettant de réaliser une transaction pour accéder à la ressource numérique, ladite application pouvant être activée par une clef chiffrée d'activation (CLE) transmise à l'utilisateur sous forme chiffrée par un serveur (SDC) connecté au réseau, ladite clef chiffrée d'activation étant chiffrée à partir d'une clef de chiffrement (CP), caractérisé en ce que ladite clef chiffrée d'activation (CLE) est chiffrée également à partir de :. un paramètre (KEY_LIFE_TIME) de durée de vie de la clef chiffrée d'activation, et. un paramètre (DUREE_FONCTIONNEMENT) de durée de vie de l'application. L'invention concerne également un système pour mettre en oeuvre un tel procédé.

Description

<Desc/Clms Page number 1>

La présente invention concerne de manière générale la sécurisation de l'accès à des produits ou services numériques.

Plus précisément, l'invention concerne un procédé de gestion sécurisée de l'accès d'un utilisateur à un produit ou un service numérique susceptible d'être importé sur un terminal utilisé par l'utilisateur par l'intermédiaire d'un réseau, mettant en oeuvre une clef d'activation du produit ou du service numérique.

Et l'invention concerne également un système pour la mise en oeuvre d'un tel procédé.

On connaît déjà des procédé du type mentionné ci-dessus.

En particulier, il est connu de mettre à la disposition d'un utilisateur un programme d'installation d'une application, ainsi qu'une clef d'activation de l'application.

Le programme d'installation est destiné à être implanté sur un terminal tel qu'un ordinateur personnel. Ce programme d'installation doit permettre à l'utilisateur de mettre en service le produit ou le service numérique sur son terminal, grâce à l'application.

Pour que cette application soit opérationnelle sur le terminal, l'utilisateur doit renseigner le programme d'installation avec la clef d'activation qui lui a été fournie.

Un tel procédé permet dans une certaine mesure d'éviter que des utilisateurs fraudeurs puissent mettre en oeuvre l'application à partir d'une copie du programme d'installation, que le fraudeur se serait procuré illicitement.

Mais un tel procédé constitue une solution imparfaite, car les utilisateurs ont la possibilité de se communiquer entre eux les clefs d'activation.

Pour augmenter la sécurité du système, il est également connu de prévoir qu'une clef d'activation (ou un groupe de clefs d'activation donné) ne puisse être effective que jusqu'à une date d'échéance prédéterminée.

<Desc/Clms Page number 2>

On paramètre à cet effet le programme d'installation et l'application devant être mise en service par ce programme pour que l'application ne puisse fonctionner que jusqu'à la date d'échéance.

Cette possibilité est mise en oeuvre par exemple si l'on souhaite autoriser à un utilisateur un accès temporaire à l'application.

Ceci peut être le cas pour permettre à l'utilisateur de tester un produit ou service (l'utilisateur devra alors requérir une clef permanente payante après avoir testé gratuitement le produit ou service pendant une période limitée), ou encore pour gérer une relation d'abonnement (l'utilisateur doit régulièrement acheter une nouvelle clef pour pouvoir continuer à utiliser l'application).

Mais dans ce cas encore, il est possible à des fraudeurs de se communiquer des clefs d'activation et de mettre l'application en service.

De plus, le simple fait de prévoir une date d'échéance ne permet pas de gérer de manière souple et individualisée des relations d'abonnement : les utilisateurs débutant un abonnement en cours de période devront acheter une clef pour la période en cours, dont une partie s'est peut-être déjà écoulée.

A cet égard, comme on le verra l'invention trouve une application avantageuse dans la gestion de l'accès temporaire d'utilisateurs à des contenus numériques mémorisés sur un serveur d'un réseau, en autorisant un haut niveau de sécurité ainsi qu'une grande souplesse de mise en oeuvre.

Une telle application peut consister par exemple à gérer l'accès d'utilisateurs à un service permettant aux utilisateurs d'avoir un accès à des contenus tels que des vidéos ou des fichiers musicaux, pendant une durée déterminée (location de contenu numérique)
Evidement, le type de produit ou service numérique mentionné cidessus à titre d'exemple n'est aucunement limitatif ; l'invention s'applique ainsi à la gestion de l'accès à tout type de ressource numérique.

On connaît par ailleurs de nombreux systèmes dans lesquels la clef d'activation est transmise sous forme chiffrée par un serveur connecté à un

<Desc/Clms Page number 3>

réseau, à un ou plusieurs utilisateurs également connectés au même réseau.

Dans ce cas, les utilisateurs disposent de moyens de déchiffrement de la clef d'activation-par exemple une clef de chiffrement de base du serveur qui peut résider dans leur terminal.

Mais ici encore, le niveau de sécurité peut être insuffisant car la clef de chiffrement de base elle-même peut être recopiée et communiquée.

Un premier objet de l'invention est de proposer un procédé et un système permettant de s'affranchir des inconvénients mentionnés cidessus, et à permettre ainsi d'augmenter le niveau de sécurité de la gestion de l'accès d'utilisateurs à un produit ou un service numérique.

On précise en outre que dans le cas des procédés et systèmes connus de sécurisation de l'accès d'utilisateurs à un produit ou service numérique disponible par l'intermédiaire d'un réseau (typiquement par téléchargement), il est actuellement très difficile d'identifier les utilisateurs se connectant au système.

En effet, les utilisateurs peuvent se connecter en utilisant différentes machines et/ou différentes adresse de messagerie reconnues par le réseau.

L'exemple le plus courant est celui d'utilisateurs se connectant à un serveur de gestion d'accès à des contenus numériques par l'intermédiaire du réseau Internet : pour la session lors de laquelle l'utilisateur se connecte au serveur, il est très courant que l'adresse de l'utilisateur sur le réseau (adresse IP-Internet Protocol) soit attribuée uniquement pour la session par un serveur qui permet à l'utilisateur de se connecter au réseau Internet. Et l'adresse est généralement attribuée de manière aléatoire, par un système de distribution dit à barillet .

Dans ces conditions, il n'est généralement pas possible d'identifier un utilisateur lors de sa connection au serveur de gestion d'accès à des contenus numériques-il serait en effet nécessaire d'interroger le serveur qui permet à l'utilisateur de se connecter au réseau Internet, pour identifier ledit utilisateur.

<Desc/Clms Page number 4>

Or il serait avantageux de pouvoir identifier l'utilisateur, si possible en temps réel lors de sa connection au serveur de gestion d'accès à un contenu/produit/service numérique.

En effet, d'une part ceci permettrait d'identifier des utilisateurs répertoriés comme fraudeurs , afin de les traiter de manière spécifique (interdiction pure et simple de l'accès, par exemple).

Et d'autre part, ceci permettrait de personnaliser la gestion du service entre le système et l'utilisateur (émulation automatique d'une interface personnalisée, différenciation des propositions commerciales et/ou des promotions en fonction d'un profil de l'utilisateur, éventuellement adaptation personnalisée de la tarification,...).

Un deuxième objet de l'invention est donc de permettre en outre d'identifier les utilisateurs se connectant au système selon l'invention.

Afin d'atteindre ces buts, l'invention propose selon un premier aspect un procédé de gestion sécurisée de l'accès d'un utilisateur à un produit ou un service numérique susceptible d'être importé par l'intermédiaire d'un réseau sur un terminal utilisé par l'utilisateur, le procédé mettant en oeuvre une application permettant de réaliser une transaction pour accéder au produit ou au service numérique, ladite application pouvant être activée par une clef chiffrée d'activation d'application qui est transmise à l'utilisateur sous forme chiffrée par un serveur connecté au réseau, ladite clef chiffrée d'activation étant chiffrée à partir d'une clef de chiffrement de base, caractérisé en ce que ladite clef chiffrée d'activation d'application est chiffrée également à partir de : . un paramètre représentatif de la durée de vie de la clef chiffrée d'activation d'application correspondant à une durée pendant laquelle la clef chiffrée d'activation d'application pourra être utilisée pour activer l'application, et . un paramètre représentatif de la durée de vie de l'application correspondant à une durée pendant laquelle l'application restera active, une fois l'application activée par la clef chiffrée d'activation d'application.

<Desc/Clms Page number 5>

Des aspects préférés, mais non limitatifs du procédé selon l'invention sont les suivants : ledit paramètre représentatif de la durée de vie de la clef chiffrée d'activation d'application est défini de manière adaptée pour chaque transaction, ledit paramètre représentatif de la durée de vie de l'application est défini de manière adaptée pour chaque transaction, le procédé comprend la transmission à l'utilisateur d'un numéro de série associé à la transaction préalablement à la transmission à l'utilisateur de ladite clef chiffrée d'activation d'application, préalablement à la transmission d'un numéro de série l'utilisateur doit présenter une requête de numéro de série, qui comprend également une première information personnelle liée à l'utilisateur, suite à ladite requête de numéro de série le procédé comprend la création d'un numéro de série, et l'enregistrement de ce numéro de série dans une mémoire accessible par le réseau, en association avec ladite première information personnelle liée à l'utilisateur, ladite mémoire accessible par le réseau est une table de mémorisation temporaire, * te procédé comprend, dans le cas où un numéro de série a déjà été attribué à la transaction, la constitution automatique d'une requête de confirmation de numéro de série, à la place d'une requête de numéro de série, * te procédé comprend le gravage de l'application avec ledit numéro de série, . ledit gravage est réalisé dès que l'utilisateur renseigne un programme d'installation de ladite application avec ledit numéro de série, il comprend l'intégration à tous les messages ou requêtes qui sont envoyés par l'utilisateur suite audit gravage, dudit numéro de série gravé dans le message ou la requête, . préalablement à la transmission d'une clef chiffrée d'activation d'application l'utilisateur doit présenter une requête de clef d'activation

<Desc/Clms Page number 6>

qui comprend également une deuxième information personnelle liée à l'utilisateur, normalement identique à ladite première information personnelle liée à l'utilisateur, . le procédé comprend l'intégration automatique du numéro de série dans ladite requête de clef d'activation, . la clef chiffrée d'activation d'application n'est transmise à l'utilisateur que si une correspondance entre information personnelle liée à l'utilisateur et numéro de série telle qu'enregistrée dans une mémoire accessible par le réseau, est vérifiée par l'information personnelle liée à l'utilisateur et le numéro de série contenus dans la requête de clef d'activation, . préalablement à ma transmission de la clef chiffrée d'activation d'application le procédé comprend la confirmation du numéro de série, * ladite confirmation est réalisée par la création d'un enregistrement d'une table d'enregistrements permanents, et la suppression d'un enregistrement correspondant d'une table d'enregistrements à confirmer.

Selon un deuxième aspect, l'invention propose également un système de mise en oeuvre d'un procédé, caractérisé en ce que le système comprend : des moyens de communication avec l'utilisateur par l'intermédiaire du réseau, . un serveur relié au réseau pour générer la clef chiffrée d'activation d'application, des moyens de mémorisation d'un numéro de série en association avec une information personnelle de l'utilisateur.

Des aspects préférés, mais non limitatifs du système selon l'invention sont les suivants : . lesdits moyens de communication avec l'utilisateur comprennent une boîte de messagerie du réseau pour recevoir des messages électroniques de l'utilisateur, . lesdits moyens de communication avec l'utilisateur comprennent un serveur du réseau, relié au serveur de génération de clef chiffrée

<Desc/Clms Page number 7>

d'activation d'application et accessible par l'utilisateur, le dialogue entre l'utilisateur et le serveur étant supporté par un programme d'interface interactif du serveur auquel l'utilisateur a accès.

D'autres aspects, buts et avantages de l'invention apparaîtront mieux à la lecture de la description suivante de l'invention, donnée à titre d'exemple non limitatif en référence aux dessins annexés sur lesquels : 'tes figures 1 à 3 sont des représentations schématiques des principales étapes du procédé selon l'invention, dans un mode de réalisation de celle-ci, 'ta figure 4 est une représentation d'un exemple de réalisation d'une base de données mise en oeuvre dans l'invention.

<Desc/Clms Page number 8>

Début du déroulement du procédé :
En référence tout d'abord à la figure 1, on a représenté schématiquement les étapes permettant à un utilisateur de rentrer en contact avec un serveur afin d'obtenir l'accès à un produit ou à un service numérique.

En 101, l'utilisateur importe sur un terminal un logiciel correspondant au produit ou au service numérique désiré. Ce logiciel comporte un programme exécutable d'installation d'une application qui permettra à l'utilisateur d'accéder au produit ou au service.

Le terminal peut être tout type de terminal connu en soi, par exemple individuellement associé à l'utilisateur. Un terminal peut ainsi être un ordinateur personnel, un téléphone portable, un assistant numérique personnel...

Et on précise que le terme de terminal recouvre également les terminaux de type public, que l'utilisateur met en oeuvre à l'aide de moyens personnels : le terminal peut ainsi être un guichet électronique public que l'utilisateur met en oeuvre grâce à un support personnel contenant des moyens de mémorisation de données et/ou des moyens de traitement de l'information, ce support pouvant être par exemple une carte à puce.

Cette importation du logiciel sur le terminal peut s'effectuer en téléchargeant le logiciel d'un réseau auquel le terminal est connecté, ou encore par l'intermédiaire d'un support physique à insérer dans un lecteur du terminal, tel qu'un CD-ROM, ou tout autre mode de support physique de logiciel connu en soi.

L'application peut constituer elle-même le produit numérique auquel l'utilisateur désire avoir accès (applications pouvant être de tout type : contenu numérique vidéo et/ou audio, bureautique, applications personnelles, jeux...).

L'application peut également permettre à l'utilisateur d'accéder à un service ou à un produit numérique mémorisé sur un serveur d'un réseau auquel le terminal est connecté. L'application peut ainsi contenir des

<Desc/Clms Page number 9>

moyens permettant à l'utilisateur d'avoir accès à un service consistant à autorise l'accès de l'utilisateur à des fichiers numériques de type quelconque ; un tel service sera appelé par extension service numérique)).

Dans tous les cas de figure, l'invention permet de mettre en service l'application, que cette application représente effectivement le produit auquel l'utilisateur veut avoir accès, ou qu'elle lui permette d'accéder à un produit ou à un service enregistré sur un serveur d'un réseau auquel le terminal est connecté.

Dans tous les cas, le terminal doit pour la suite des opérations être connecté à un réseau auquel sont également connectés des éléments du système selon l'invention (en particulier les éléments BM, BM'et SDC décrits plus loin dans ce texte).

Ce réseau peut être un réseau public (World Wide Web par exemple), ou privé. On le désignera dans cette demande par le terme générique le réseau
Une fois le logiciel importé sur le terminal, le programme d'installation de l'application s'exécute automatiquement en 102 (éventuellement en requérant de l'utilisateur l'entrée d'une commande d'installation).

Le programme d'installation de l'application va alors s'exécuter ; et l'ensemble des étapes décrites ci-dessous se déroule en temps réel, en parallèle de l'exécution de ce programme qui vise à installer l'application sur le terminal.

A cet égard, on précise que l'invention va être décrite ci-dessous en détail dans un mode de réalisation qui correspond à une première variante de l'invention, dans laquelle le dialogue entre l'utilisateur et le système selon l'invention s'effectue grâce à des échanges de messages électroniques acheminés par le réseau.

On précise également que cette description détaillée n'est nullement limitative ; en particulier, l'invention peut également être mise en oeuvre en utilisant deux serveurs du réseau dont un premier serveur est directement

<Desc/Clms Page number 10>

accessible par l'utilisateur et joue le rôle de la BM décrite ci-dessous (ainsi que de la BM'), tandis que le deuxième serveur qui n'est pas directement accessible par l'utilisateur mais qui est relié au premier serveur par l'intermédiaire du réseau joue le rôle du SDC.

Dans cette deuxième variante de l'invention, les communications entre l'utilisateur et le système selon l'invention ne se font pas par l'intermédiaire de messages électroniques, mais par un dialogue interactif émulé par un programme d'interface du serveur auquel l'utilisateur a accès.

Dans ce dialogue, l'utilisateur devra valider ses choix, effectuer ses requêtes et renseigner les champs qui doivent être renseignés dans le programme d'interface dudit serveur accessible par l'utilisateur, le programme d'interface englobant alors le programme d'installation .

On précise toutefois que dans cette variante la première connection d'un utilisateur au système (pour une demande de numéro de série pour une référence produit, comme cela sera décrit) se fait de la même manière que dans la première variante, c'est à dire par l'envoi d'un message électronique M1 du terminal de l'utilisateur vers le système (ces entités seront décrites ci-après).

Dans cette deuxième variante, la suite des échanges entre l'utilisateur et le système (demandes de clés d'activation en particulier) se fait en mode interactif, grâce au programme d'interface mentionné cidessus.

Revenant à la description détaillée de la première variante de réalisation de l'invention, lors de cette installation de l'application, en 103 le programme d'installation indique à l'utilisateur (par exemple par l'édition d'un message sur un écran du terminal) qu'un numéro de série est nécessaire pour activer l'application, et que l'utilisateur doit s'enregistrer auprès du système selon l'invention pour disposer d'un tel numéro de série.

Pour permettre au programme de poursuivre l'installation de l'application, l'utilisateur doit alors renseigner le programme d'installation avec son adresse de messagerie, et valider sa demande de numéro de série (étape 104).

<Desc/Clms Page number 11>

Par adresse de messagerie , on entend une adresse de messagerie électronique propre à l'utilisateur, apte à être reconnue par les moyens d'acheminement de messages électroniques sur le réseau. Cette adresse de messagerie pourra typiquement être une adresse de messagerie Internet du type identifiant&commat;serveur. domaine .

On précise que cette adresse de messagerie n'est pas l'adresse IP du terminal de l'utilisateur.

Pour l'étape 104, le programme d'installation pourra éditer une fenêtre comportant un champ dans lequel l'utilisateur doit inscrire son adresse de messagerie, ainsi qu'un bouton sur lequel l'utilisateur doit cliquer pour valider le fait qu'il demande un numéro de série.

Suite à l'étape 104, le programme d'installation constitue automatiquement en 105 un premier message électronique M1 dont l'entête comporte : . l'adresse de messagerie que l'utilisateur a fournie, 'ta référence produit correspondant à l'application que l'utilisateur désire activer. La référence produit est préenregistrée dans le programme d'installation, ou a été renseignée par l'utilisateur qui a éventuellement pu choisir une référence produit parmi plusieurs proposées par le programme d'installation, . le sujet du message. Ce sujet est automatiquement constitué par le programme d'installation suite à la validation par l'utilisateur effectuée en 104. Il a un libellé prédéterminé REG correspondant à une demande de numéro de série.

Toutefois, dans le cas où l'utilisateur dispose déjà d'un numéro de série pour la référence produit en question et qu'il a lancé le programme d'installation par exemple pour demander une nouvelle clef d'activation (voir plus loin dans ce texte) car sa clef d'activation temporaire a expiré, le programme d'installation délecte le numéro de série gravé dans l'application (voir plus loin dans le texte pour le détail du gravage), et constitue automatiquement un libellé de sujet de message CONF

<Desc/Clms Page number 12>

correspondant à un libellé prédéterminé de demande de clef d'activation.

Le champ sujet du message constitué par le programme d'installation ne peut en tout état de cause qu'être égal à REG , ou à CONF .

Et on précise que le programme d'installation effectue au début de l'étape 104 un test pour déterminer si un numéro de série est déjà associé à l'application. Ce test est possible car comme on va le voir lors de la première demande d'une clef d'activation par l'utilisateur, le programme d'installation grave automatiquement le numéro de série dans l'application elle-même.

Ainsi, dans le cas où un numéro de série (différent de 0 ) est déjà gravé dans l'application, le sujet du message sera CONF -et dans le cas contraire il sera REF , le numéro de série si un numéro de série est déjà associé à l'application. Lors d'un premier accès par un nouvel utilisateur, aucun numéro de série n'est normalement associé à l'application que l'utilisateur désire activer, et le programme d'installation assigne alors par défaut la valeur 0 au numéro de série. Toutefois, il est possible- comme cela sera décrit plus loin-qu'un numéro de série soit déjà associé à la référence produit et à l'adresse de messagerie de l'utilisateur, et dans ce cas le numéro de série dont la valeur est différente de 0 est mémorisée dans le programme d'installation, qui renseigne alors automatiquement en 105 l'en-tête du message M1 avec ce numéro de série.

Le programme d'installation envoie en 105 le message M1 ainsi constitué à une boîte de messages du réseau que l'on notera BM par souci de simplification.

A ces fins, l'adresse de messagerie de la BM est préenregistrée dans le programme d'installation.

En 106, la BM reçoit le message M1 envoyé par le programme d'installation, et l'enregistre dans une mémoire qui lui est associée.

<Desc/Clms Page number 13>

Un serveur relié au réseau, que l'on nommera le serveur de distribution de clefs , et que l'on désignera dans ce texte par l'acronyme SDC par souci de simplification, scrute à intervalles réguliers la BM pour identifier les nouveaux messages reçus par la BM.

Pour effectuer cette scrutation, le SDC se connecte périodiquement à la BM par l'intermédiaire du réseau
Il est également possible de paramétrer le SDC pour que celui-ci soit connecté de manière permanente à la BM de manière à identifier en temps réel les nouveaux messages reçus par celle-ci.

Il est enfin possible de réaliser en outre la connexion du SDC à la BM sur requête d'un administrateur du système selon l'invention.

Une fois connecté, le SDC identifie tous les messages se trouvant dans la BM.

Ainsi, chaque nouveau message reçu par la BM est repéré par le SDC (étape 107).

Lors de l'étape suivante 108, le SDC importe le message M1 dans sa mémoire centrale
Plus précisément, M1 est mémorisé dans un espace de mémorisation temporaire accessible en lecture et en écriture par le SDC, que l'on désignera par le terme de base temporaire .

De préférence, la base temporaire est incluse dans la mémoire centrale du SDC.

La base temporaire comporte une table qui comprend une série d'enregistrement. Chaque enregistrement de cette table comporte les champs suivants : référence produit, . numéro de série. On précise que le système selon l'invention peut comme on va le voir utiliser des numéros de série considérés comme étant à confirmer , ou des numéros de série confirmés (ou permanents ). En ce qui concerne les enregistrements de la base temporaire, cependant, ce champ dédié aux numéros de série contient le numéro de série transmis par le message de l'utilisateur, que celui-ci

<Desc/Clms Page number 14>

soit ensuite considéré par le système comme un numéro de série à confirmer ou comme un numéro de série permanent, adresse de messagerie de l'utilisateur, sujet du message, . date d'émission du message. On précise que ce champ des enregistrements de la base temporaire n'est normalement pas exploité.

Et comme on le verra, le SDC est également associé à un espace de mémorisation permanent, que l'on désignera par le terme de base de service .

La base de service peut être physiquement intégrée au SDC, ou physiquement séparée du SDC et résider dans un support de mémorisation quelconque accessible par le SDC par l'intermédiaire du réseau.

La base de service est constituée de plusieurs structures, chaque structure étant constituée d'une série d'enregistrement dont les champs obéissent à un format propre à la structure.

Les structures sont liées par des relations hiérarchiques et parmi les structures de la base de service, une des structures est maître ? de certains autres, ce qui signifie que les enregistrements de ces autres structures de la base de service sont déterminés par un des champs des enregistrements de cette structure maître Ce champ correspond en l'occurrence à la référence produit.

On précise toutefois qu'une des structures de la base de service ne suit pas cette relation de dépendance vis-à-vis de la structure maître. Il s'agit de la structure d'historique des adresses de messagerie d'utilisateur, qui sera exposée plus en détail dans la suite de ce texte.

Les enregistrements de cette structure ne sont pas déterminés par un champ correspondant à la référence produit dans la structure maître de la base de service.

Ainsi cette structure d'historique des adresses de messagerie d'utilisateur constitue une structure autonome de la base de service.

<Desc/Clms Page number 15>

Dans un exemple préféré de réalisation de l'invention, la base de service pourra être réalisée sous la forme d'une base de données relationnelle incluant les structures évoquées ci-dessus.

Chaque structure est ainsi une table comportant une série d'enregistrements dont le format est propre à la structure. La base de service est constituée d'un premier ensemble de tables qui sont liées hiérarchiquement à la table maître dont elles dépendent, et d'une table supplémentaire qui correspond à l'historique des adresses de messagerie d'un utilisateur pour une référence produit, comme cela sera expliqué.

La figure 4 est une représentation de la base de service, qui montre . un premier ensemble formé de trois tables T1, T2, T3, dans lequel la table T1 constitue une table maître, . et une table supplémentaire T4 qui contient des informations sur les adresses de messagerie des utilisateurs qui ont été extraites par le SDC

dans la BM.

On va maintenant détailler en référence à la figure 4 les tables T1 à T4, ainsi que leurs principales dépendances.

La table T1 qui est la table maître correspond aux informations liées au produit ou au service numérique (représenté par la référence produit), ainsi qu'à la configuration générale du système.

Cette table T1 qui sur le schéma est nommée PRODUIT-CODIFICATION comprend les champs suivants : . PK~ID et REFERENCE qui sont deux champs représentatifs de la référence produit. REFERENCE contient la référence produit, alors que PK~ID est une traduction biunivoque de cette référence produit au format numérique, LIBELLE correspond au libellé du produit, < CLEF~PRIMAIRE correspond au paramètre CP dont le rôle sera décrit plus en détail dans la suite de texte et qui correspond à une clef de base de chiffrement de la clé chiffrée d'activation de l'application liée à la référence produit,

<Desc/Clms Page number 16>

. LAST-SERIAL-GENERATE correspond au dernier numéro de série ayant été généré par le système, . SERIAL-LONGITUDE qui représente le nombre maximum de caractères du numéro de série, . Les champs E~MAIL~REGISTRATION à REG~POP~APOP, sont des champs qui permettent l'accès du SDC à la lecture des messages de la
BM, Les champs REG~SMTP ~SERVER et CONFStvSMTPSERVER sont des paramètres permettant au SDC de se connecter à la BM en écriture, Les champs REGREPLYTO et CONF~REPLY~TO sont des champs qui permettent de paramétrer l'adressage des réponses de l'utilisateur à des messages que le système selon l'invention lui envoie.

# Le champ MODEL-BIENVENUE contient un message de bienvenue de confirmation d'enregistrement qui sera adressé à l'utilisateur en fin de processus.

La table T2, qui sur la figure 4 est nommée SERIE~INSTANTANEE , correspond à une table dont chacun des enregistrements contient un numéro de série qui a été généré par le système mais qui n'a pas encore été confirmé.

Un tel numéro de série est à ce stade désigné par le terme numéro de série à confirmer . il s'agit normalement des numéros de série auxquels aucune clef d'activation n'a encore été associée-alors que dans les enregistrements de la table T3, le numéro de série est associé à une clef d'activation.

Chaque enregistrement de la table T2 est rattaché à un enregistrement de la table T1, dont il dépend hiérarchiquement. Plus précisément, le champ de rattachement hiérarchique est le champ PK~ID de T1.

Les enregistrements de cette table T2 comprennent les champs suivants : . FKPRODUIT est une recopie du champ PK~ID,

<Desc/Clms Page number 17>

. E~MAIL~UTIL est l'adresse de messagerie de l'utilisateur telle qu'extraite du message M1, .NUMERO~SERIE correspond au numéro de série (qui sera généré par le SDC lors de l'étape 206 qui sera décrite plus loin dans ce texte), .DATE~EMISSION correspond à la date de génération dudit numéro de série par le SDC, 'tvMAIL~HEADER correspond à l'intégralité du message M1 que la BM a reçu de l'utilisateur et que le SDC a récupéré.

La table T3, nommée NUMERO~SERIE sur la figure 4, comporte des enregistrements dont les champs sont les suivants : . FKPRODUIT, 'PK~ID~SERIE est un identifiant généré de manière incrémentale par le système à partir de FK~PRODUIT pour identifier le couple (référence produit, numéro de série). En effet, le même numéro de série peut être attribué par le système à deux références produit différentes ; il est alors nécessaire de disposer d'un identifiant supplémentaire pour identifier sans ambiguïté l'enregistrement de la table T3, # NUMERO~SERIE correspond au numéro de série confirmé , après que le SDC ait réalisé l'étape 307 qui sera décrite plus loin dans ce texte, . NOMBRE~LICENCES correspond au paramètre NL du message M ou
M5 qui est comme on va l'expliquer utilisé pour transmettre la clef d'activation à l'utilisateur, . DUREEFONCTiONNEMENT correspond à la durée de validité de l'application, c'est-à-dire à la durée pendant laquelle l'application pourra être opérationnelle, une fois activée par la clé d'activation. Ce paramètre est un élément fondamental de l'invention. La durée de validité de l'application est en effet à distinguer d'une date d'échéance associée à une application, telle qu'évoquée dans l'introduction de cette demande.
La durée de validité de l'application permet de définir non pas une date d'échéance fixée d'avance, mais réellement une durée de vie de l'application à partir du moment où celle-ci aura été activée par la clef

<Desc/Clms Page number 18>

d'activation qui sera transmise à l'utilisateur par le SDC. Et comme on le verra selon un autre aspect important de l'invention, cette clef d'activation est elle-même associée à un intervalle de temps pendant lequel l'activation de l'application par l'utilisateur grâce à cette clef d'activation sera possible, # PREMIERE~EMISSION est un champ qui reprend de la table T2 le paramètre DATE~EMISSION. On précise à cet égard que lors de la confirmation d'un numéro de série et de la création d'un enregistrement dans la table T3, l'enregistrement correspondant est supprimé de la table T2, # DERNIERE~EMISSION correspond à la date de dernière émission d'un message M ou M5 à destination de l'utilisateur, pour le PK ! DSER ! E en question. On détaillera ci-dessous en référence à l'étape 308 l'élaboration et l'envoi d'un tel message M ou M5, qui transmet une clef d'activation d'application à l'utilisateur, # DATE~EXPIRATION correspond à une date prévisionnelle d'échéance calculée par le SDC, à partir des champs DERN ! EREEM ! SS) ON et
DUREE~FONCTIONNEMENT : DATE EXPIRATION
DERNIEREEMISSION + DUREE~FONCTIONNEMENT. Cette date prévisionnelle correspond en effet à la date à laquelle l'application cessera d'être active, si l'utilisateur a activé ladite application avec la clef qui lui a été transmise dès réception de celle-ci. Le paramètre
DATE-EXPIRATION est utilisé par le système selon l'invention pour signaler à l'utilisateur (par exemple grâce à un message électronique) qu'il a la possibilité de demander une nouvelle clef d'activation pour prolonger son accès à l'application,

. PREM) EREJv) A) L correspond au champ E~MAIL~UTIL repris de la table T2 lors de la destruction de l'enregistrement correspondant et de la génération d'un enregistrement avec un PK~ID~SERIE dans T3, 'DERN)ERE) v) A ! L correspond à la dernière adresse d'utilisateur reçue dans un message M4. L'élaboration et renvoi d'un tel message M4 sera expliqué en référence à l'étape 209, plus loin dans ce texte.

<Desc/Clms Page number 19>

Chaque enregistrement de la table T3 est, comme chaque enregistrement de la table T2, rattaché hiérarchiquement à un enregistrement de la table T1 par l'intermédiaire du champ PKJD de T1 qui est recopié dans le champ FK~PRODUIT de T3.

Chaque enregistrement de la table T3 correspond ainsi à un couple (référence produit, numéro de série) unique et désigne sans ambiguïté une transaction entre l'utilisateur et le système selon l'invention. A ces fins, l'identifiant PK ID SERIE décrit ci-dessus est créé.

On précise que le terme transaction englobe les échanges entre le système selon l'invention et un utilisateur donné, concernant une référence produit donnée.

Une transaction équivaut donc à un numéro de série, pour une référence produit donnée.

Comme on va l'expliquer ci-dessous, une transaction peut être réalisée en une seule fois (demande de numéro de série puis demande de clef d'activation et activation de l'application).

Il est également possible qu'une transaction unique se fasse en plusieurs temps, et que l'utilisateur ait changé d'adresse de messagerie entre les différentes étapes de la transaction (ceci pouvant également en particulier être le cas dans le cas d'un utilisateur fraudeur tentant d'obtenir une clef d'activation avec un numéro de série qu'il s'est fait communiquer par ailleurs).

La table T4 permet pour chaque PK~ID~SERIE (c'est-à-dire pour chaque transaction entre un utilisateur et le système), de mémoriser l'historique des différentes adresses de messagerie qui ont pu être utilisées par l'utilisateur pour ses échanges de la transaction avec le système selon l'invention.

Chaque enregistrement de la table T4 comporte ainsi les champs suivants : FFKID~SERIE, qui est une recopie du paramètre PK~ID~SERIE de la table T3,

<Desc/Clms Page number 20>

. DATE-EMISSION qui correspond à la date de génération de l'enregistrement de la table T4 par le SDC, 'KEYFIREWORK correspond à la clef d'activation chiffrée qui a été transmise à l'utilisateur avec le message M ou M5 correspondant à
PK~ID~SERIE, KEY-LIFE-TIME correspond à la durée de vie de cette clef d'activation.

Ce paramètre important du système selon l'invention correspond à la durée pendant laquelle ladite clef d'activation peut être mise en oeuvre dans le programme d'installation pour activer l'application, à partir du moment où le message M ou M5 a été envoyé à l'utilisateur, 'E~MAIL~STORY correspond à l'adresse de messagerie d'utilisateur à laquelle le message M ou M5 est envoyé. On précise que chaque enregistrement de la base T4 ne comporte qu'un E~MAIL~STORY, mais que pour un paramètre FK ! DSER ! E donné, on peut avoir dans la base T4 plusieurs enregistrements, chaque enregistrement pouvant correspondre à une adresse de messagerie différente de l'utilisateur, # BLACK~LISTED est un champ qui, s'il est renseigné, indique que l'adresse de messagerie E~MAIL~STORY doit être considérée comme faisant partie de la liste noire (dont le rôle sera exposé plus loin dans ce texte). Le champ BLACK~LISTED est ainsi éventuellement renseigné par une date qui est celle à laquelle le SDC a mis en liste noire l'adresse de messagerie E~MAIL~STORY.

Revenant au processus décrit en référence à la figure 1, on précise que lors d'une première connexion d'un utilisateur au système selon l'invention, aucun numéro de série n'est encore attribué.

Dans ce cas, le numéro de série se voit attribuer par défaut la valeur 0 par le programme d'installation.

En 109, le SDC lit dans la base temporaire de la mémoire centrale la référence produit
En 110, le SDC lit ensuite dans la base temporaire de la mémoire centrale le sujet du message, le numéro de série et l'adresse de messagerie de l'utilisateur.

<Desc/Clms Page number 21>

En 111, le SDC effectue un test pour déterminer si les deux conditions suivantes sont satisfaites : . le sujet du message correspond à une demande de numéro de série ( REG ), et . le numéro de série est égal à 0 (qui est comme on l'a dit la valeur assignée par défaut à une application n'ayant pas encore été activée).

Si les deux conditions sont satisfaites, il s'agit d'une première demande de numéro de série pour une application qui n'a effectivement pas été activée, et le SDC exécute l'étape 201 qui est la première étape décrite en référence à la figure 2 : Traitement d'une première demande de numéro de série.

Si une au moins des deux conditions n'est pas satisfaite, le SDC exécute l'étape 301 qui est la première étape décrite en référence à la figure 3 : Traitement d'une demande de clef d'activation.

On précise que les étapes décrites ci-dessus se réalisent de la même manière dans les deux variantes principales de réalisation de l'invention.

Par contre, en ce qui concerne les étapes suivantes qui seront décrites en référence aux figures 2 et 3, si la logique des enchaînements des étapes est bien conservée pour les deux variantes, comme on l'a dit dans la deuxième variante les échanges entre l'utilisateur et le système selon l'invention se fait non pas par l'intermédiaire de messages électroniques mais en direct grâce au programme d'interface interactif du serveur qui correspond à la BM et qui est le serveur auquel l'utilisateur a accès.

<Desc/Clms Page number 22>

Traitement d'une première demande de numéro de série :
En référence maintenant à la figure 2, dans le cas où les deux conditions testées à l'étape 111 sont satisfaites, cela signifie que pour la référence produit concernée l'utilisateur effectue bien une première connection, ou tout au moins ne dispose pas encore de clef d'activation.

Le système selon l'invention va donc exécuter les étapes nécessaires pour transmettre à l'utilisateur un numéro de série, et enregistrer l'utilisateur dans la base de service en association avec cette référence produit.

Pour cela, le SDC détermine en 201 si l'adresse de messagerie de l'utilisateur qui a été lue en 110 existe déjà dans la base de service en association avec la référence produit lue en 109.

En effet, il est possible que l'utilisateur soit déjà enregistré dans le système en association avec la référence produit et qu'il dispose donc d'un numéro de série, mais qu'il n'ait pas encore de clé d'activation.

Comme on va le voir, des moyens sont alors prévus pour rappeler à l'utilisateur son numéro de série.

Et il est également possible que l'utilisateur soit un fraudeur déjà identifié par le système et cherchant à se procurer un nouveau numéro de série.

Plus précisément, le SDC va dans un premier temps rechercher dans la base de service si ladite adresse de messagerie de l'utilisateur lue en 110 se trouve dans un des enregistrements des tables T2 ou T3 qui sont rattachées à un enregistrement de T1 dont le champ PREFERENCE correspond à la même référence produit que celle lue en 109.

Plus précisément encore, le SDC balaie en premier les enregistrements de T2 qui sont rattachés à cette référence produit, en recherchant ladite adresse de messagerie dans un champ E~MAIL~UTIL.

Si cette recherche est infructueuse, le SDC balaie ensuite les enregistrements de T3 rattachés à la même référence produit pour y localiser un champ PREMIER~E~MAIL contenant cette adresse de

<Desc/Clms Page number 23>

messagerie, puis en cas d'échec pour y rechercher un champ DERNIER E MAIL contenant ladite adresse
Dans le cas où cette recherche sur les tables T2 et T3 a été infructueuse, le SDC balaie ensuite les enregistrements de la table T4 qui sont rattachés à un PKJD~SERIE de T3 correspondant à la référence produit lue en 109, pour rechercher dans les champs E~MAIL~STORY de ces enregistrements l'adresse d'utilisateur lue en 110
Et on précise que lors de cette recherche dans les enregistrements de la base T4, si l'adresse de messagerie recherchée est localisée mais qu'elle est marquée comme appartenant à la liste noire, le SDC ignore l'adresse trouvée.

Le test indiqué lors de l'étape 202 consiste donc à déterminer si l'adresse de messagerie d'utilisateur lue en 110 existe dans la base de service en association avec la référence produit lue en 109 comme indiqué ci-dessus.

Si ce test est positif (l'adresse de messagerie de l'utilisateur telle que lue en 110 est déjà associée dans la base de service à la référence produit lue en 109), le SDC effectue en 203 un autre test, qui consiste à déterminer si l'adresse de messagerie de l'utilisateur est enregistrée en liste noire .

L'enregistrement d'une adresse en liste noire correspond comme indiqué ci-dessus au renseignement du champ BLACK-LISTED de l'enregistrement correspondant de T4.

Cette liste noire est mise à jour par le système selon l'invention pour identifier les adresses de messagerie de l'utilisateur que l'on désire traiter de manière spécifique (typiquement pour ne pas donner satisfaction aux requêtes d'un utilisateur fraudeur).

Si le test effectué en 203 indique que l'adresse de messagerie de l'utilisateur est enregistrée en liste noire, le processus se termine en 204, aucune action ultérieure n'étant effectuée par le SDC ni par aucun autre élément du système selon l'invention.

<Desc/Clms Page number 24>

Si maintenant le test effectué en 203 est négatif, ceci signifie que l'utilisateur dispose déjà d'un numéro de série (dont la valeur est différente de 0) pour cette référence produit.

Plus précisément, si le SDC a localisé l'adresse de messagerie dans un enregistrement de T2, il va retrouver dans le même enregistrement le numéro de série associé, enregistré dans le champ NUMEROSER) E.

Si l'adresse de messagerie a été localisée dans un enregistrement de T3, Il en est de même.

Si maintenant cette adresse de messagerie a été localisée dans le SDC dans un enregistrement de T4, cela signifie qu'un numéro de série correspondant est enregistré dans le champ NUMERO~SERIE de T3 auquel est rattaché ledit enregistrement de T4.

Le SDC localise ainsi dans la base de service le numéro de série enregistré en association avec l'adresse de messagerie de l'utilisateur et la référence produit, et renvoie à l'utilisateur un message électronique M2 rappelant à l'utilisateur son numéro de série.

L'envoi de ce message est symbolisé par l'étape 205 Cette étape est suivie de l'étape 208 qui sera décrite ci-dessous
Revenant au test effectué en 202, si maintenant le SDC ne localise pas l'adresse de messagerie électronique de l'utilisateur dans la base de service en association avec la référence produit concernée, il s'agit bien d'une première connection de l'utilisateur et le SDC réalise en 206 les opérations suivantes : génération d'un numéro de série, dont la valeur est différente de 0 , . création d'un nouvel enregistrement dans la table T2 de la base de service, contenant l'adresse de messagerie d'utilisateur lue en 110

(champ E~MAIL~UTIL), le numéro de série généré (champ NUMERO~SERIE), la date de création de l'enregistrement (champ DATE-EMISSION), l'identifiant correspondant à la référence produit lue en 109 (champ FK~PRODUIT).

Le SDC élabore ensuite en 207 un message électronique M3 adressé à l'utilisateur, et contenant le numéro de série généré en 206.

<Desc/Clms Page number 25>

Le message M3 est ainsi équivalent au message M2 évoqué ci-dessus.

Lors de la création et de l'envoi de ce message M2 ou M3, le SDC paramètre automatiquement à partir du champ REGREPLYTO de l'enregistrement de T1 auquel l'enregistrement de T2 ou de T3 contenant le numéro de série est rattaché, le champ réponse du message.

Ainsi, dans le cas où l'utilisateur recevant ce message M2 ou M3 désire répondre au message (en cliquant sur le bouton répondre de son logiciel de messagerie électronique), la réponse sera automatiquement adressée à une deuxième boîte de message, dont l'adresse est différente de celle de la BM et de celle du SDC, afin de ne pas engorger la boîte de messagerie de ces deux entités.

En pratique en effet, l'option répondre à est offerte à l'utilisateur pour poser des questions sur le numéro de série temporaire qui lui est attribué, ou sur tout autre aspect du fonctionnement du système-toutefois cette réponse n'est nullement nécessaire pour le fonctionnement du système.

Cette deuxième boîte de messagerie sera désignée dans ce texte par l'abréviation COM, car elle correspond en pratique à une adresse de boîte de messagerie commerciale , dont les messages peuvent être traités de manière personnalisée par des agents commerciaux dédiés à cette fonction pour répondre aux questions des clients.

L'utilisateur reçoit en 208 le message M2 envoyé en 205 ou M3 envoyé en 207. Il a alors la possibilité de renseigner le programme d'installation de l'application avec le numéro de série reçu, en réponse à la requête de ce programme d'installation, et de poursuivre l'installation de l'application.

Suite à l'étape 104 décrite ci-dessus, le programme d'installation est en effet toujours actif et génère pour l'étape 208 cette requête de numéro de série après avoir constitué et envoyé le message M1 en 104

<Desc/Clms Page number 26>

Les étapes décrites ci-dessus sont effectuées en temps réel. En pratique, des tests effectués par la Demanderesse ont montré qu'il ne s'écoulait que quelques minutes entre l'étape 101 et l'étape 208.

Et comme cela a été évoqué ci-dessus, si dans cette première variante de réalisation qui est décrite en détail, les échanges entre le système selon l'invention et l'utilisateur se font par l'intermédiaire de messages électroniques, il est également possible dans une deuxième variante de réalisation de l'invention que ces échanges se fassent directement par le biais d'un programme d'interface lancé à partir d'un serveur du réseau (correspondant schématiquement à la boîte BM) auquel l'utilisateur peut se connecter.

Toujours lors de l'étape 208, l'utilisateur ayant renseigné le programme d'installation de l'application avec le numéro de série, valide dans ce programme d'installation une demande de clef d'activation, par exemple en cliquant sur un bouton d'une fenêtre affichée à l'écran du terminal par le programme d'installation après que l'utilisateur ait renseigné ce programme avec le numéro de série.

Et dès que l'utilisateur a renseigné le programme d'installation avec le numéro de série qu'il a reçu du message M2 ou M3, le programme d'installation enregistre automatiquement en 208 ce numéro de série dans l'application.

Cet enregistrement est permanent (et sera ainsi désigné par le terme de gravage ), et ne pourra normalement plus être modifié (sauf dans le cas où il s'avérerait par la suite que l'utilisateur a renseigné par erreur en 208 le programme d'installation avec un numéro de série qui ne correspond pas à la clef d'activation qui sera ultérieurement fourni au programme d'installation).

Le gravage de l'application avec le numéro de série est un élément de sécurité supplémentaire de l'invention. Il permet de marquer pour la suite des opérations l'application, de sorte que les messages ultérieurs qui seront constitués automatiquement par le programme d'installation à destination du système selon l'invention comporteront :

<Desc/Clms Page number 27>

. ce numéro de série gravé qui est intégré automatiquement dans le message, sans que l'utilisateur puisse intervenir (et sans qu'il le sache), ainsi que l'adresse de messagerie de l'utilisateur, qui est elle renseignée par l'utilisateur, et la référence produit concernée.

De la sorte, tous les échanges ultérieurs entre l'utilisateur et le système seront identifiés par ce numéro de série gravé-qui devra comme on va le voir correspondre au numéro de série enregistré dans la base de service.

En effet, le numéro de série est enregistré dans la base de service en association avec une adresse de messagerie d'utilisateur (dans un enregistrement de T2, ou de T3) -ceci constitue un moyen d'authentification car comme on va le voir le SDC vérifie après réception des messages de l'utilisateur que la correspondance entre adresse de messagerie et numéro de série, telle qu'enregistrée dans la base de service, est vérifiée par l'adresse et le numéro de série contenus dans le message.

Et on précise que dans le cas de la deuxième variante de l'invention, ce numéro de série gravé n'est pas intégré dans les messages électroniques envoyés du terminal de l'utilisateur au système, mais il est de la même manière automatiquement associé aux requêtes qui seront adressées par l'utilisateur et au système, via le programme d'interface interactif.

Suite à cette demande de clef d'activation de l'utilisateur, le programme d'installation génère automatiquement en 209 un nouveau message électronique, M4, à destination de la BM, dont l'en-tête comprend : un sujet de message dont le libellé CONF est renseigné de manière automatique par le programme d'installation pour correspondre de manière prédéterminée à un libellé de demande de clef d'activation de l'application,

<Desc/Clms Page number 28>

. le numéro de série gravé que le programme d'installation récupère dans l'application et intègre automatiquement dans le message, 'ta référence produit concernée, . et l'adresse de messagerie électronique de l'utilisateur (fournie par l'utilisateur lors de l'étape 104).

Il est également possible selon une variante de l'invention que le destinataire de ce message soit une boîte de messagerie BM', différente de la boîte BM déjà décrite ci-dessus et également reliée au réseau et au même système de messagerie électronique que les autres éléments du système selon l'invention.

A cet effet, le programme d'installation de l'application pourra être paramétré à volonté.

Le SDC qui scrute comme on l'a dit à Intervalles réguliers la BM (et également la boîte BM'si une telle boîte supplémentaire différente de BM est mise en oeuvre), identifie alors en 210 le message M4 envoyé en 209, et le système répète alors les étapes 108 à 111 décrites ci-dessus.

Etant donné que dans ce cas le test qui sera effectué en 111 sera négatif (du fait que le sujet du message ne correspond pas à une demande REG de numéro de série, mais à une demande CONF de clef d'activation), l'étape suivant le test 111 sera l'étape 301, première étape qui va maintenant être décrite en référence à la figure 3.

<Desc/Clms Page number 29>

Traitement d'une demande de clef d'activation :
En référence donc à cette figure 3, le SDC analyse en 301 l'en-tête du message M1 ou M4 reçu de l'utilisateur (que ce soit dans la boîte BM, ou dans une boîte BM') et importé dans la base temporaire.

En 302, le SDC procède à un test, pour déterminer si les deux conditions suivantes sont satisfaites : . te sujet du message correspond à une demande CONF de clef d'activation, et . te numéro de série est différent de 0.

Si ce test est positif (les deux conditions sont satisfaites), le SDC effectue avant tout en 303 un autre test, consistant à déterminer si l'adresse de messagerie de l'utilisateur qui a été lue en 110 est enregistrée en liste noire.

Si tel est le cas, le processus se termine en 304 de la même manière qu'en 204.

Si l'adresse de messagerie de l'utilisateur n'est pas enregistrée en liste noire, le SDC regarde en 305 dans les enregistrements de la table T2 de la base de service si le numéro de série compris dans le message M1 ou M4 reçu de l'utilisateur figure dans cette table.

On rappelle que pour chaque enregistrement de cette table T2, le numéro de série enregistré correspond à un numéro de série à confirmer , ce qui signifie que ce numéro de série a déjà été généré par le système (et transmis à l'utilisateur), mais qu'il n'est pas encore associé à une clef d'activation.

En 306, le SDC effectue ensuite un test pour déterminer si les deux conditions suivantes sont remplies : le numéro de série qui était compris dans le message M1 ou M4 et qui a été lu en 110 est mémorisé dans un enregistrement de la table T2 qui est rattaché à la référence produit lue en 109 (c'est-à-dire un enregistrement de T2 qui est rattaché hiérarchiquement à un

<Desc/Clms Page number 30>

enregistrement de la table T1 dont le champ PK~ID correspond à la référence produit lue en 109), et l'adresse de messagerie de l'utilisateur telle que lue en 110 est également mémorisée dans le même enregistrement de T2.

Ce test est possible grâce au gravage du numéro de série dans l'application, puis à son intégration automatique dans le message M1 ou M4 par le programme d'installation.

Si le test est positif (les deux conditions sont remplies), il s'agit d'une première demande de clef d'activation par un utilisateur dûment enregistré dans le système.

Et dans ce cas le SDC crée en 307 un nouvel enregistrement de la table T3 qui se rattache à la référence produit lue en 109.

A ces fins, le SDC renseigne les champs suivants : . FKPRODUIT est recopié de l'enregistrement de T2, . PK~ID~SERIE est généré incrémentalement par le SDC de manière automatique, NUMERO SERIE est recopié de l'enregistrement de T2, NOMBRE LICENCE est renseigné par le SDC, éventuellement, à partir d'un fichier complémentaire qui peut contenir par exemple des informations sur la transaction. A titre d'exemple, ce champ peut contenir le nombre de licences que l'utilisateur désire acquérir sur le produit ou le service numérique. Par défaut, ce champ a une valeur égale à 1, . DUREE~FONCTIONNEMENT est renseigné par le SDC, également en fonction de la nature de la transaction entre l'utilisateur et le système selon l'invention. Ce paramètre définit la durée de vie de l'application une fois que celle-ci sera activée grâce à la clef d'activation qui sera fournie à l'utilisateur. Il est par exemple possible de définir par défaut une durée illimitée (correspondant à une vente du produit ou service numérique au lieu d'une location).

Il est également possible de paramétrer le programme d'installation pour offrir à l'utilisateur le choix entre différentes durées de vie de

<Desc/Clms Page number 31>

l'application, le choix effectué étant renseigné alors par le SDC dans ce champ, . PREMIER EMISSION est recopié du champ DATE-EMISSION de l'enregistrement de T2, . OERNIERE EMISSION est la date de création de ce nouvel enregistrement de T3, . DATE-EXPIRATION est comme on l'a expliqué ci-dessus calculé de manière automatique, . PREMIER~E~MAIL est recopié du champ E~MAIL~UTIL de l'enregistrement de T2, . DERNIEREEvMAIL est l'adresse lue en 110.

Suite à la création de cet enregistrement de T3, le SDC supprime l'enregistrement correspondant de T2.

En 308, le SDC procède à la génération d'une clef d'activation (cette étape étant détaillée ci-après), et à la préparation d'un message électronique M5 à destination de l'utilisateur pour lui envoyer la clef d'activation de l'application générée par le SDC.

On précise que la clef d'activation est élaborée de manière chiffrée et intégrée dans le message chiffré M5 dit message d'activation , par des moyens de chiffrement du SDC, comme cela sera expliqué en détail cidessous.

Ce message chiffré contenant la clef chiffrée d'activation de l'application peut également (dans la deuxième variante de réalisation de l'invention) être transmis à l'utilisateur par le biais du programme d'interface interactif exécuté par le serveur auquel l'utilisateur a accès.

On désignera ainsi de manière générale le message par la référence M, qu'il soit transmis sous la forme d'un message électronique M5 ou non. Les références M et M5 sont ainsi équivalentes dans ce texte.

Dans la première variante principale de l'invention, c'est l'utilisateur qui récupère lui-même la clef chiffrée d'activation dans le message, et qui l'introduit dans le programme d'installation-ce qui a pour effet d'activer l'application.

<Desc/Clms Page number 32>

Dans le deuxième variante principale de l'invention, il est possible de prévoir que cette activation est effectuée automatiquement par le programme d'installation qui récupère la clef chiffrée d'activation et active lui-même l'application.

Dans les deux cas, le programme d'installation va lors de l'activation de déchiffrer la clef chiffrée d'activation et en extraire les éléments ayant servi à son élaboration.

Ces éléments contiennent les paramètres en particulier temporels qui définissent les modalités de l'accès à l'application pour la transaction : durée de vie de la clef chiffrée d'activation : KEYUFE-TIME, et durée de vie de l'application elle-même une fois que celle-ci aura été activée : DUREE~FONCTIONNEMENT), ainsi que les dates DR et DE (voir explication ci-dessous).

Ces paramètres peuvent également comporter des informations complémentaires sur la transaction, (paramètre NL qui sera exposé plus loin à propos du chiffrement de la clef-ce paramètre peut contenir DUREE~FONCTIONNEMENT, mais également d'autres informations sur la transaction, des moyens de l'application et/ou du programme d'installation étant prévus pour prendre en compte ces informations).

Ainsi, après déchiffrement du message M le programme d'installation disposera non seulement de la clef chiffrée d'activation de la référence produit, qui est indispensable pour activer l'application, mais également des paramètres temporels de fonctionnement de cette clef.

Et les moyens du programme d'installation qui mettent en oeuvre cette clef prennent ainsi automatiquement en compte les contraintes temporelles associées aux deux durées de vie évoquées ci-dessus.

L'étape 309 lors de laquelle le message M5 est envoyé à l'utilisateur marque ensuite la fin de l'intervention du SDC dans le processus
Celui-ci se terminera par : le déchiffrement du message d'activation M par le programme d'installation,

<Desc/Clms Page number 33>

. l'extraction des paramètres CP, KEY-LIFE-TIME, DUREE~FONCTIONNEMENT, et des autres paramètres entrant dans le chiffrement du message M, et l'activation de l'application grâce à la clef CP.

Cette activation sera de préférence réalisée automatiquement par des moyens du programme d'installation sans que l'utilisateur ait accès à la clef de base CP.

Cependant, il est également possible dans une variante que ce soit l'utilisateur qui récupère la clef de base CP et qui l'introduise lui-même dans le programme d'installation, pour activer l'application.

Si maintenant une des deux conditions examinées lors du test effectué en 306 n'est pas remplie, il se peut que : * l'utilisateur soit régulièrement enregistré mais qu'il ne s'agisse pas d'une première demande de clef d'activation pour la référence produit en question, 'l'utilisateur ait changé d'adresse de messagerie depuis son enregistrement, * l'utilisateur soit en train de tenter de frauder, . le numéro de série ait subi une dégradation (cas à exclure en fonctionnement normal-toutefois ce cas est traité par le processus de manière à augmenter la fiabilité du système) Ces cas vont être détaillés ci-dessous.

Le SDC détermine d'abord en 310 si le numéro de série reçu de l'utilisateur dans le message M1 ou M4 est mémorisé dans un enregistrement T2 de la base de service Si c'est le cas, cela signifie que l'adresse de messagerie mémorisée dans un enregistrement de la table T2 de la base de service en association avec le numéro de série, est différente de l'adresse de messagerie qui a été lue lors de l'étape 110.

Cela signifie que l'utilisateur a bien reçu le numéro de série envoyé dans le message M2 ou M3, mais qu'il a utilisé une adresse de messagerie différente pour requérir une clef d'activation.

<Desc/Clms Page number 34>

La probabilité pour que cette situation se présente est faible (en particulier car l'ensemble du processus d'activation de l'application se déroule normalement en continu) ; toutefois, ce test permet de sécuriser encore le système.

Le SDC envoie alors en 311 un message électronique M6 aux deux adresses de messagerie dont il dispose (l'adresse de messagerie mémorisée dans la base de base de service en associant avec le numéro de série temporaire, et l'adresse de messagerie qui a été lue en 110).

Ce message M6 indique que deux adresses de messagerie sont susceptibles d'être associées au numéro de série et que par suite de ce manque d'identité entre les deux adresses aucune action ne sera entreprise plus avant.

Suite à l'envoi de ce message M6, l'utilisateur devra ressaisir son adresse de messagerie dans la fenêtre éditée lors de l'étape 104, et le processus pourra alors reprendre.

On précise que pour retourner à l'étape 104, l'utilisateur a la possibilité de naviguer entre les étapes de l'installation de l'application, en cliquant sur des boutons précédent et suivant des différentes fenêtres éditées par le programme d'installation.

Revenant au test effectué en 310, si ce test est négatif et que le numéro de série reçu dans le message M1 ou M4 n'est pas mémorisé dans un enregistrement de la table T2 de la base de service, le SDC effectue en 313 un test pour déterminer ce numéro de série est enregistré dans un enregistrement de la table T3 de la base de service.

Si ce test est positif, l'utilisateur est déjà enregistré pour cette référence produit dans la base de service, en association un numéro de série confirmé : une clé d'activation a donc déjà été demandée
Dans ce cas, le SDC effectue en 314 un test supplémentaire pour déterminer si l'adresse de messagerie de l'utilisateur telle que lue en 110 est identique à l'adresse de messagerie mémorisée dans ledit enregistrement de la table T3, en association avec ce numéro de série.

<Desc/Clms Page number 35>

Si tel est le cas cela signifie que l'utilisateur demande une nouvelle clef d'activation.

Le SDC procède alors à l'étape 308, en générant une clef d'activation et en constituant le message d'activation M5, puis à l'étape 309.

Si le test effectué en 314 est négatif, cela signifie que l'utilisateur a changé d'adresse de messagerie depuis sa dernière demande de clef d'activation.

Et dans ce cas, le SDC enregistre en 316 la nouvelle adresse de messagerie de l'utilisateur (telle que lue en 110) en association avec le numéro de série, dans un nouvel enregistrement de la table T4 de la base de service qui est rattaché hiérarchiquement à l'enregistrement de T3 dans lequel le numéro de série a été localisé (test en 313), par recopie du PKJD~SERIE de cet enregistrement de T3.

Suite à cette étape 316, il est possible selon une option de mise en oeuvre de l'invention de procéder en 317 à l'invalidation dans ledit enregistrement de la table T4 de la base de service de l'adresse de messagerie qui était précédemment enregistrée dans cette base de service en association avec le numéro de série, par enregistrement de la date courante en liste noire.

Il est également possible selon une autre option de mise en oeuvre de l'invention de faire envoyer par le SDC à l'ancienne adresse de messagerie de l'utilisateur qui est enregistrée dans le champ DERNIER~E~MAIL de l'enregistrement correspondant de la table T3 de la base de service, un message demandant à l'utilisateur de confirmer son changement d'adresse de messagerie.

Et dans ce cas, ce message est également envoyé à l'autre adresse d'utilisateur, qui figure dans le champ E~MAIL~STORY de l'enregistrement de la table T4 qui est rattaché à cet enregistrement de la table T3.

Le SDC reprend ensuite dans tous les cas le processus à l'étape 311 déjà décrite ci-dessus, ce qui permettra à l'utilisateur de renseigner le programme d'installation de l'application avec une clé d'activation

<Desc/Clms Page number 36>

Revenant au test effectué en 313, dans le cas où le numéro de série lu en 110 n'est pas enregistré dans un enregistrement de la table T3 la base de service, le SDC effectue en 318 un test pour déterminer si l'adresse de messagerie de l'utilisateur telle que lue en 110 est mémorisée dans un enregistrement de la base de service.

Cette recherche dans la base de service est effectuée dans un premier temps dans les enregistrements de la table T2 qui sont rattachés à la référence produit concernée, puis dans les enregistrements de la table T3, et enfin dans ceux de la table T4.

Si l'adresse est localisée dans la base de service, cela signifie qu'il existe un numéro de série associé, dans la base de service, à cette adresse de messagerie (par le biais d'un enregistrement de T2, ou de T3).

Et le SDC effectue dans ce cas un test en 319 pour déterminer si l'adresse de messagerie de l'utilisateur appartient à la liste noire.

Si tel est le cas, aucune opération n'est plus effectuée et le processus s'arrête en 320 de manière similaire à ce qui se passe en 204 ou en 304.

Dans le cas contraire où l'adresse de messagerie de l'utilisateur n'appartient pas à la liste noire, le SDC génère automatiquement en 321 un message électronique M7 à l'attention de cette adresse en y incluant le bon numéro de série, qui est effectivement associé à cette adresse dans la base de service.

Ce cas doit être exceptionnel ; il correspond à une dégradation du numéro de série lors de son gravage dans l'application, ou de sa transmission.

L'utilisateur ayant reçu le message M7 peut ainsi disposer du numéro de série qui est le sien, et requérir à nouveau une clef d'activation, en réitérant les étapes 208 et suivantes.

Dans le cas maintenant où le test effectué en 318 n'a pas permis d'identifier l'adresse de messagerie de l'utilisateur dans la base de service, on se trouve probablement dans un cas où l'utilisateur est un fraudeur et le

<Desc/Clms Page number 37>

SDC enregistre cette adresse de messagerie dans la liste noire. Cette mise à jour de la liste noire a lieu de lors de l'étape 322.

Revenant au test effectué en 302 lors de laquelle le SDC détermine si le sujet du message M1 ou M4 reçu par BM ou BM'correspond à une demande d'activation et si le numéro de série temporaire est différent de 0, dans le cas où une de ces deux conditions n'est pas remplie, le SDC va effectuer en 323 un test pour déterminer s'il a reçu du réseau un message d'erreur indiquant que l'adresse de messagerie de l'utilisateur n'a pas reçu le message comportant un numéro de série.

Dans le cas où un tel message d'erreur a été reçu par le SDC, le SDC extrait en 324 l'adresse de messagerie électronique qui a donné lieu à cet échec de transmission de message.

Le SDC effectue ensuite en 325 un test pour déterminer si cette adresse de messagerie est mémorisée dans un enregistrement de la table T2 de la base de service.

Si tel est le cas, le SDC marque en 326 cette adresse dans la base de service comme étant associée à une erreur. A cet effet, un nouvel enregistrement de la table T4 de la base de service sera créé, ladite adresse de messagerie étant enregistrée en liste noire par cet enregistrement de T4.

Cet enregistrement de l'adresse en liste noire pourra ensuite être reconnu par le SDC pour éviter d'utiliser à nouveau cette adresse de messagerie à destination de l'utilisateur.

Suite à l'étape 326, le SDC procède en 327 à la libération du numéro de série qui était enregistré dans le même enregistrement de la table T2 que cette adresse de messagerie de la base de service. Cette libération consiste à effacer de la base de service ledit numéro de série, de sorte que celui-ci pourra être réaffecté ultérieurement à une autre transaction.

Dans le cas maintenant où le test effectué en 325 n'a pas permis d'identifier dans la base de service l'adresse de messagerie ayant donné lieu à un échec de transmission de message, dans un enregistrement de

<Desc/Clms Page number 38>

T2, le SDC effectue en 328 un autre test pour déterminer si cette adresse de messagerie est mémorisée dans un enregistrement de la table T3.

Si tel est le cas, le SDC réalise l'étape 329 et marque l'adresse de messagerie en question, de la manière indiquée ci-dessus (mise en liste noire).

Dans le cas contraire, aucune action n'est plus entreprise par le système selon l'invention (étape de fin 330). Ceci est également le cas si le test effectué en 323 est négatif (étape de fin 330).

<Desc/Clms Page number 39>

Génération du message d'activation par le SDC :
Revenant maintenant aux étapes 308 et 309 lors desquelles une clef d'activation est élaborée pour être transmise à l'utilisateur en ayant fait la requête en 208, on va maintenant détailler les opérations réalisées pour créer et mettre en service cette clef d'activation.

La clef d'activation chiffrée est transmise dans un message que l'on a désigné par la référence générique M, et qui est dans l'exemple détaillé de la première variante de l'invention réalisé sous forme du message M5.

On précise que la clef d'activation est élaborée de manière chiffrée par des moyens de chiffrement du SDC, et déchiffrée par des moyens de déchiffrement correspondants du programme d'installation et/ou de l'application après transmission de cette clef au terminal de l'utilisateur.

Selon un exemple de mise en oeuvre de l'invention, cette clef d'activation est cryptée par le SDC de la manière qui va être décrite ciaprès.

La structure de la clef d'activation comprend 36 caractères dont 288 bits. Elle a la forme générale :

XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX.

Dans cet exemple, la clef d'activation est généré de manière cryptée par des moyens du SDC à partir des éléments suivants : . Numéro de série NS, . Clef interne du produit CP, correspondant à une clef de base de chiffrement qui est associée individuellement à chaque référence produit de manière prédéterminée dans le SDC. C'est cette clef qui est nécessaire au programme d'installation pour permettre l'accès à l'application, . Message NL contenant des informations particulières, intégrées sous forme cryptée dans le message d'activation qui sera transmis à l'utilisateur et fourni au programme d'installation de l'application, ce programme et/ou l'application étant aptes à lire ce message après déchiffrement.

<Desc/Clms Page number 40>

NL peut par exemple contenir des informations commerciales liées à un lot particulier d'applications que l'on veut distinguer (nombre de licences que l'on souhaite accorder à un même utilisateur pour que celui-ci utilise plusieurs exemplaires de l'application, et/ou version ou options particulières de l'application à activer.

Selon un aspect préféré de l'invention, NL peut également contenir des informations temporelles -en particulier, une période prédéfinie à partir de la date de référence pendant laquelle il sera possible d'activer l'application avec la clef NL contient ainsi typiquement le paramétrage DUREE FONCTIONNEMENT de la table T2 décrit ci-dessus.

Le paramètre DUREE~FONCTIONNEMENT est défini de manière adaptée par l'administrateur du système selon l'invention, pour chaque couple (référence produit, numéro de série) c'est à dire pour chaque transaction.

Il est possible que le programme d'installation propose à l'utilisateur de choisir pour une référence produit donnée une durée de vie de l'application parmi plusieurs proposées-une fois que l'utilisateur a choisi une durée, le processus tel que décrit ci-dessus se déroule pour cette transaction particulière, Validité (notée V dans cette partie du texte pour des raisons de concision), correspondant à la durée de la période pendant laquelle la clef autorise l'utilisation de l'application, cette durée étant déterminée à partir de l'activation de l'application par la clef. Ce paramètre est celui qui renseigne le champ KEYHLIFE-TIME de la table T3.

Ce paramètre est particulièrement important car il permet de générer des clefs d'activation qui auront une durée de vie prédéfinie à partir du moment où ces clefs seront utilisées pour activer l'application correspondante (ceci étant différent d'une simple date d'échéance comme mentionné en introduction de cette demande à propos de l'état de la technique connu),

<Desc/Clms Page number 41>

Ce paramètre est défini de manière adaptée par l'administrateur du système selon l'invention, pour chaque couple (référence produit, numéro de série) c'est à dire pour chaque transaction.

Sa valeur peut être déterminée en prenant en compte des objectifs de sécurité : en particulier, il est important que d'éventuels fraudeurs qui écouteraient la transmission entre le terminal de l'utilisateur et le système selon l'invention, et qui auraient accès au message M, n'aient pas le temps de déchiffrer la clef de base CP qui leur permettrait d'activer une copie illicite de l'application.

A cet égard, la durée KEY-LIFE-TIME doit être choisie suffisamment courte.

Il est également possible d'ajuster cette durée en fonction d'autres objectifs, par exemple pour permettre à l'utilisateur de réaliser d'autres opérations, Date de référence notée DR correspondant à une date de référence (qui constitue une origine des temps pour la gestion de la durée de vie de la clef et des aspects temporels de l'activation de l'application en général, . Date d'émission notée DE correspondant à la date de génération d'émission de la clef par le SDC.

Un exemple de format utilisé pour ces différents éléments est donné ci-après :

<tb>
<tb> Elément <SEP> Taille <SEP> Type <SEP> Valeur <SEP> possible
<tb> NS <SEP> 14 <SEP> Alphabétique <SEP> o-9, <SEP> A-Z, <SEP> a-z
<tb> CP <SEP> 14 <SEP> Alphabétique <SEP> 0 <SEP> # <SEP> 9, <SEP> A <SEP> # <SEP> Z, <SEP> a <SEP> # <SEP> z
<tb> NL <SEP> 3 <SEP> Numérique-99-999
<tb> V <SEP> 3 <SEP> Numérique <SEP> 001-je <SEP> 999
<tb> DR <SEP> 10 <SEP> Date <SEP> (JJ/MM/AAAA)
<tb> DE <SEP> 10 <SEP> Date <SEP> (JJ/MM/AAAA)
<tb>

<Desc/Clms Page number 42>

Algorithme de chiffrement de la clef d'activation : La clef CLE est composée de deux chaînes de caractères ED et SE, concaténées ensemble l'une après l'autre. La partie ED correspond plus particulièrement aux données chiffrées contenues dans la clef : CLE = ED & SE, & étant un opérateur de concaténation entre deux chaînes de caractères.

On précise que l'exemple très détaillé qui va être donné ci-dessous du chiffrement et du déchiffrement de la clef d'activation est donné à titre purement illustratif, et ne constitue en aucune manière une limitation de l'invention.

1.) Calcul de ED Le calcul de ED s'effectue à partir des éléments suivants : NS, CP, NL, V, DR, DE a. ) Chiffrement de NL (cas où NL contient une information de nombre de licences)
NL comporte trois composants, représentatifs de : C (centaines), D (dizaines), U (unités) qui correspondent à un nombre CDU. Le codage de chaque composant se fait comme suit :
C + 65 = N1-Soit n1 le caractère correspondant au code N1 considéré comme un code ASCII.

D + 65 = N2-Soit n2 le caractère correspondant au code N2 considéré comme un code ASCII.

U + 65 = N3-Soit n3 le caractère correspondant au code N3 considéré comme un code ASCII.

* NL est élaboré en concaténant les caractères n1, n2 et n3 : NL = n1 n2 n3 b. ) Chiffrement de DateJ
DateJ est un paramètre intermédiaire formé de six caractères numériques. Ce paramètre correspond à la période calculée en jours entre la date DE, exprimée en jour et la date de référence DR exprimée en jour : DateJ = DE-DR.

Soit DE-DR sous la forme J1 J2 J3 J4 J5 J6

<Desc/Clms Page number 43>

Chaque caractère J (i) de DE-DR est traité comme suit.

Si J (i) est un nombre impair, alors on détermine. J (i) + 65 = D (i), d (i) étant le caractère correspondant à D (i) considéré comme un code ASCII.

Si J (i) est un nombre pair alors : d (i) = caractère correspondant à J (i) considéré comme un code ASCII.

DateJ est formé par la concaténation des d (i) : DateJ= d1 d2 d3 d4 d5 d6 c. ) Décomposition de V (Validité) V comporte trois composants v1, v2 et v3 Soit V = v1 v2 v3
Le SDC constitue alors un paramètre ED1 qui servira de base à la constitution de ED ED1 = n1 & v1 & v2 & v3 & n3 & d1 & d2 & d3 & d4 & d5 & d6 & n2 d. ) Première transformation de ED1 en ED2
Le SDC applique ensuite une fonction Check Sum (OU Exclusif) sur ED1, pour constituer une valeur ED2 : ED2 = 0 XOR ED1
Soit CS1 = cs11 & cs12, le résuitat (2 positions) de la fonction Check Sum sur les composants de ED1, exprimé en format hexadécimal. On constitue ED2 de la manière suivante :

ED2 = cs11 & cs12 & n1 & v1 & v2 & v3 & n3 & d1 & d2 & d3 & d4 & d5 & d6 & n2 e. ) Deuxième transformation de ED2 en ED3
Le paramètre CP se compose dans cet exemple de 14 caractères : CP = cp1 cp2 cp3 cp4 cp5 cp6 cp7 cp8 cp9 cp10 cp11 cp12 cp13 cp14
Ici encore, le SDC applique une fonction XOR, entre les composants de ED2 et CP ED3 = ED2 XOR CP
Soit ED3 le nouveau résultat de la fonction XOR entre ED et CP

ED3 = ed1 & ed2 & ed3 & ed4 & ed5 & ed6 & ed7 & ed8 & ed9 & ed10 & ed & ed12 & ed13 & ed14.

<Desc/Clms Page number 44>

f.) Application d'un offset de 15 sur ED3-formation de ED4 On traite chaque caractère ED (i) (caractère en ième position dans ED3) de ED3 comme suit :
Si ED (i) est alphabétique alors le SDC élabore o (i) le caractère correspondant au code de O (i) considéré comme un code ASCII, O (i) étant égal à ED (i) + 15.

Si ED (i) est numérique alors : o (i) = ED (i)
Le SDC remplace les ED (i) par les o (i) et on obtient un nouveau ED, noté ED4. g. ) Troisième transformation de ED4 en ED5
Le SDC applique une fonction Check Sum (OU Exclusif) sur ED4 :
ED5 = 0 XOR ED5
Soit CS2 = cs21 & cs22 ! e résuttat (2 positions) en hexadécimal de la fonction Check Sum sur l'expression ED4.

ED5 = ed1 & ed2 & ed3 & ed4 & ed5 & ed6 & ed7 & ed8 & ed9 & ed10 & ed11 & ed12 & ed13 & ed14 & cs21 & cs22 (Ic ! ED5 comporte 16 composants)
Il.) Calcul de SE Les éléments permettant de calculer SE sont les suivants : NS, CP a. ) Obtention de SE1
Partant de CP et NS, le SDC va d'abord calculer un paramètre intermédiaire SE1 :

CP = cp1 cp2 cp3 cp4 cp5 cp6 cp7 cp8 cp9 cp10 cp11 cp12 cp13 cp14 NS = ns1 ns2 ns3 ns4 ns5 ns6 ns7 ns8 ns9 ns10 ns11 ns12 ns13 ns14
Le SDC applique une fonction XOR entre les composants de CP et NS : SE1 =CPXORNS
Soit SE1 le résultat de la fonction XOR entre CP et NS.

SE1 = se1 & se2 & se3 & se4 & se5 & se6 & se7 & se8 & se9 & se10 & se11 & se12 & se13 & se14 (Ici SE1 comporte 14 composants)

<Desc/Clms Page number 45>

b.) Transformation de SE1 en SE2 Le SDC applique une fonction Check Sum (OU Exclusif) sur SE1 SE2 = 0 XOR SE1
Soit CS3= cs31 & cs32 ! e résu ! tat (2 positions) en hexadécimal de la fonction Check Sum sur l'expression SE1.

SE2 = se1 & se2 & se3 & se4 & se5 & se6 & se7 & se8 & se9 &

se10 & se11 & se12 & se13 & se14 & cs31 & cs32 (Ici SE2 comporte 16 composants) 111.) Calcul de la CLE a. ) Obtention de CLE1 CLE1 = ED5 & SE2, est un paramètre intermédiaire élaboré par le SDC à partir de ED5 et SE2.

CLE1 = ed1 & ed2 & ed3 & ed4 & ed5 & ed6 & ed7 & ed8 & ed9 & ed10 &

ed11 & ed12 & ed13 & ed14 & cs21 & cs22 & se1 & se2 & se3 & se4 & se5 & se6 & se7 & se8 & se9 & se10 & se11 & se12 & se13 & se14 & cs31 & cs32 (CLE=32 composants) b. ) Première transformation de CLE1 en CLE2
Le SDC applique une fonction Check Sum (OU Exclusif) sur CLE1 : CLE2 = 0 XOR CLE1.

Soit CS4= cs41 & cs42 te résultat (2 positions) en hexadécimal de la fonction Check Sum sur l'expression CLE1.

CLE2 = ed1 & ed2 & ed3 & ed4 & ed5 & ed6 & ed7 & ed8 & ed9 & ed10 & ed11 & ed12 & ed13 & ed14 & cs21 & cs22 & se1 & se2 & se3 & se4 & se5 & se6 & se7 & se8 & se9 & se10 & se11 & se12 & se13 & se14 & cs31 & cs32 & cs41 & cs42 (Ici CLE2 comporte 34 composants) c. ) Deuxième transformation de la CLE : formation de CLE3 Le SDC traite chaque élément CLE2 (i) de CLE2 comme suit.

Le SDC élabore pour chaque composant CLE2 (i) de CLE3 le code

C (i) correspondant au code ASCII de CLE2 (i).
Le SDC convertit ensuite chaque code C (i) en binaire, pour former une nouvelle clef CLEB formée à partir des 34 caractères de CLE3.

<Desc/Clms Page number 46>

Soit CLEB la nouvelle chaîne binaire de 272 bits : CLEB= b1... b272 Le SDC compte le nombre (2 positions) de fronts montants sur la chaîne binaire, noté NBFM.

Le SDC convertit ensuite NBFM au format hexadécimal : NBFM = nbfm1 & nbfm2 d. ) Troisième transformation de la CLE-formation de CLE4
Le SDC élabore ensuite CLE4 : CLE = CLE & NBFM CLE4 = ed1 & ed2 & ed3 & ed4 & ed5 & ed6 & ed7 & ed8 & ed9 & ed10 &

ed11 & ed12 & ed13 & ed14 & cs21 & cs22 & se1 & se2 & se3 & se4 & se5 & se6 & se7 & se8 & se9 & se10 & se11 & se12 & se13 & se14 & cs31 & cs32 & cs41 & cs42 & nbfm1 & nbfm2 (Ici CLE4 comporte 36 composants) e. ) Dernière transformation de la CLE-formation de CLE
Enfin, le SDC décompose CLE4 par tranches de quatre caractères, et ajoute le caractère"-"entre chaque tranche : CLE = c1 & c2 & c3 & c4 & "-" & c5 & c6 & c7 & c8 & "-" & . & c36
La clef CLE ainsi constituée est celle qui est transmise à l'utilisateur
Comme on l'a dit, le programme d'installation de l'application et/ou l'application elle-même comportent des moyens de déchiffrement pour extraire de CLE les valeurs des paramètres de départ NS, CP, NL, V, DR, DE

<Desc/Clms Page number 47>

Algorithme de vérification de la clef d'activation : Après réception de la clef d'activation CLE qui est contenue dans le message M par le terminal de l'utilisateur, les opérations décrites cidessous sont effectuées par des moyens de déchiffrement du programme d'installation de l'application, ou de l'application elle-même
La clef reçue par le terminal de l'utilisateur est composée de 44 caractères, en incluant les caractères"-"ajoutés entre chaque tranche :
CLE = XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX 1.) Vérification de la clef logique a. ) Suppression des caractères"-"de CLE-obtention de
CLE4
Soit CLE4 = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Ici CLE4 comporte 36 composants, et correspond aux caractères suivants : CLE4 = ed1 & ed2 & ed3 & ed4 & ed5 & ed6 & ed7 & ed8 & ed9 & ed10 & ed11 & ed12 & ed13 & ed14 & cs21 & cs22 & se1 & se2 & se3 & se4 & se5

& se6 & se7 & se8 & se9 & se10 & se11 & se12 & se13 & se14 & cs31 & cs32 & cs41 & cs42 & nbfm1 & nbfm2 b.) Suppression des deux derniers caractères (nbfm1 et nbfm2) de CLE4 Soit NBFM = (nbfm1 & nbfm2)
On extrait de CLE4 le paramètre CLE3, par suppression de NBFM CLE3 = ed1 & ed2 & ed3 & ed4 & ed5 & ed6 & ed7 & ed8 & ed9 & ed10 &

ed11 & ed12 & ed13 & ed14 & cs21 & cs22 & se1 & se2 & se3 & se4 & se5 & se6 & se7 & se8 & se9 & se10 & se11 & se12 & se13 & se14 & cs31 & cs32 & cs41 & cs42
Par ailleurs, il est procédé à la conversion de NBFM en format décimal et à sa mémorisation dans une zone de mémoire du terminal (mémoire vive) du résultat de cette conversion, dans une variable notée VNBFM.

Chaque composant CLE3 (i) de CLE3 est ensuite traité comme suit :
On élabore C (i) qui correspond au code ASCII de CLE3 (i).

<Desc/Clms Page number 48>

Chaque code C (i) est ensuite converti en format binaire, de manière à former un paramètre de (34 caractères * 8 bits) = 272 bits, noté CLEB.

On compte ensuite le nombre (2 positions) de fronts montants sur la chaîne binaire, et on mémorise le résultat dans NBFM.

Première vérification
Les moyens de déchiffrement comparent VNBFM avec NBFM. Dans le cas où il y a égalité le processus de vérification de la clef se poursuit ; dans le cas le processus de vérification s'arrête et les moyens de déchiffrement concluent que la clef a été modifiée (c'est à dire qu'elle ne constitue pas une clef valide). c. ) Suppression du Check Sum CS4 (cs41 & cs42) de CLE2
Les moyens de déchiffrement suppriment ensuite CS4 = (cs41 & cs42) de CLE2, pour obtenir : CLE1 = ed1 & ed2 & ed3 & ed4 & ed5 & ed6 & ed7 & ed8 & ed9 & ed10 & ed11 & ed12 & ed13 & ed14 & cs21 & cs22 & se1 & se2 & se3 & se4 & se5

& se6 & se7 & se8 & se9 & se10 & se11 & se12 & se13 & se14 & cs31 & cs32-cette chaîne comprenant ainsi 32 caractères.

Par ailleurs, les moyens de déchiffrement appliquent une fonction Check Sum (OU Exclusif) sur CLE1 : Soit VCS4 le résultat (2 positions) en format hexadécimal de la fonction Check Sum sur l'expression CLE1.

Deuxième vérification
Les moyens de déchiffrement comparent ensuite VCS4 avec CS4s'il y a égalité la vérification se poursuit, sinon le processus de vérification s'arrête et les moyens de déchiffrement concluent que la clef a été modifiée. d. ) Extraction de ED et SE de la CLE
Les moyens de déchiffrement extraient de CLE les chaînes SE2 et ED5 : SE2 = se1 & se2 & se3 & se4 & se5 & se6 & se7 & se8 & se9 & se10 & se11 & se12 & se13 & se14 & cs31 & cs32 (Ici SE5 comporte 16 composants),

<Desc/Clms Page number 49>

ED5=ed1 & ed2 & ed3 & ed4 & ed5 & ed6 & ed7 & ed8 & ed9 & ed10 & ed11 & ed12 & ed13 & ed14 & cs21 & cs22 (Ici ED2 comporte 16 composants) e. ) Suppression du Check Sum CS3 (cs31 & cs32) de SE2
Soit CS3 = (cs31 & cs32)
Les moyens de déchiffrement suppriment les caractères de CS3 de SE2, pour obtenir une chaîne SE1 de 14 caractères : SE1 = & se2 & se3 & se4 & se5 & se6 & se7 & se8 & se9 & se10 & se11 & se12 & se13 & se14
Ces moyens appliquent ensuite une fonction Check Sum (OU Exclusif) sur SE1, pour obtenir VSE = 0 XOR SE1, VSE ayant un format hexadécimal (2 positions).

Troisième vérification
Les moyens de déchiffrement comparent ensuite VCS3 avec CS3en cas d'égalité la vérification se poursuit, sinon le processus de vérification s'arrête et les moyens de déchiffrement concluent que la clef a été modifiée. f. ) Obtention de NS
NS sera fourni par NS = CP XOR SE1.

CP = cp1 cp2 cp3 cp4 cp5 cp6 cp7 cp8 cp9 cp10 cp11 cp12 cp13 cp14.

SE = se1 se2 se3 se4 se5 se6 se7 se8 se9 se10 se11 se12 se13 se14.

Les moyens de déchiffrement appliquent une fonction XOR entre les composants de CP et SE1 (CP étant connu du programme d'installation car enregistré dans l'application, ou dans le programme en association avec la référence produit) : NS = CP XOR SE NS = ns1 ns2 ns3 ns4 ns5 ns6 ns7 ns8 ns9 ns10 ns11 ns12 ns13 ns14. g. ) Suppression du check Sum CS2 (cs21 & cs22) de ED5

<Desc/Clms Page number 50>

Soit CS2 = (cs21 & cs22). Les moyens de déchiffrement élaborent ED4, en supprimant les deux derniers caractères de ED5 : ED4=ed1 & ed2 & ed3 & ed4 & ed5 & ed6 & ed7 & ed8 & ed9 & ed10 & ed11 & ed12 & ed13 & ed14-chaîne à 14 caractères.

Une fonction Check Sum (OU Exclusif) est ensuite appliquée sur ED4 : VCS2 = 0 XOR ED4 Soit VCS2 le résultat (2 positions) en hexadécimal de cette fonction Check Sum sur l'expression ED4.

Quatrième vérification
Les moyens de déchiffrement comparent VSC2 avec CS2-en cas d'égalité la vérification se poursuit, sinon le processus de vérification s'arrête et les moyens de déchiffrement concluent que la clef a été modifiée. h. ) Application d'un offset de-15 sur ED4
Chaque caractère ED (i) de ED4 est traité comme suit Si ED (i) est alphabétique alors les moyens de déchiffrement élaborent o (i) le caractère correspondant au code O (i) considéré comme code ASCII. O (i) est obtenu par : ED (i) -15 = O (i).

Si ED (i) est numérique alors : o (i) = ED (i)
Les moyens de déchiffrement reconstituent ensuite ED3 en remplaçant les ED (i) par les o (i). i. ) Transformation de ED3
Les moyens de déchiffrement appliquent ensuite une fonction XOR entre les composants de ED3 et de CP.

ED2 = ED3 XOR CP ED2 & cs12 & n1 & v1 & v2 & v3 & n3 & d1 & d2 & d3 & d4 & d5 & d6 & n2. j. ) Suppression du Check Sum CS1 (cs11 & cs12) de ED2

Soit CS1 = (cs11 & cs12) Ici ED1 comporte 12 composants après la suppression de CS1 du début de ED2, qui est effectuée par les moyens de déchiffrement :

<Desc/Clms Page number 51>

ED1 = r1 & v1 & v2 & v3 & r3 & x1 & x2 & x3 & x4 & x5 & x6 & r2.

Les moyens de déchiffrement appliquent ensuite une fonction Check Sum (OU Exclusif) sur ED1 : Soit VCS1 le résultat (2 positions) en hexadécimal de la fonction Check Sum sur l'expression ED1 : VCS1 = 0 XOR ED1.

Cinquième vérification
Les moyens de déchiffrement comparent ensuite VSC1 avec CS1en cas d'égalité la vérification se poursuit, sinon le processus de vérification s'arrête et moyens de déchiffrement concluent que la clef a été modifiée. k. ) Obtention de V (durée de validité)
Les moyens de déchiffrement extraient de ED1 les trois composants deV-V=vl & v2 & v3.

1.) Obtention de NL (Le Message)

Les moyens de déchiffrement extraient de ED1 les trois composants n1, n2 et 3.

Le décodage de chaque composant se fait comme suit : Soit N1 le code ASCII correspondant au caractère ASCII n1.

On applique N1-65 = C, Soit N2 le code ASCII correspondant au caractère ASCII n2.

On applique N2-65 = D, Soit N3 le code ASCII correspondant au caractère ASCII n3.

On applique N3-65 = U.

Les moyens de déchiffrement reconstituent ainsi NL = CDU. m. ) Déchiffrement de DateJ pour l'obtention de la date DE
89+Les moyens de déchiffrement extraient de ED1 les six composants d1 à d6 de DateJ.

Ces moyens de déchiffrement ont également accès à la date de référence DR, qui est enregistrée dans le programme d'installation, au format DR = JJ/MM/AAAA
Les moyens de déchiffrement convertissent DR en nombre de jour et élaborent DE = DateJ + DR.

Puis ils convertissent DE au format date : soit DE = JJ/MM/AAAA

Claims (19)

1. REVENDICATIONS 1. Procédé de gestion sécurisée de l'accès d'un utilisateur à un produit ou un service numérique susceptible d'être importé par l'intermédiaire d'un réseau sur un terminal utilisé par l'utilisateur, le procédé mettant en oeuvre une application permettant de réaliser une transaction pour accéder au produit ou au service numérique, ladite application pouvant être activée par une clef chiffrée d'activation d'application (CLE) qui est transmise à l'utilisateur sous forme chiffrée par un serveur (SDC) connecté au réseau, ladite clef chiffrée d'activation étant chiffrée à partir d'une clef de chiffrement de base (CP), caractérisé en ce que ladite clef chiffrée d'activation d'application (CLE) est chiffrée également à partir de : * un paramètre (KEYLIFE~TIME) représentatif de la durée de vie de la clef chiffrée d'activation d'application correspondant à une durée pendant laquelle la clef chiffrée d'activation d'application pourra être utilisée pour activer l'application, et . un paramètre (DUREE~FONCTIONNEMENT) représentatif de la durée de vie de l'application correspondant à une durée pendant laquelle l'application restera active, une fois l'application activée par la clef chiffrée d'activation d'application.
2. 2. Procédé selon la revendication 1, caractérisé en ce que ledit paramètre (KEY LIFE-TIME) représentatif de la durée de vie de la clef chiffrée d'activation d'application est défini de manière adaptée pour chaque transaction.
3. 3. Procédé selon la revendication 1 ou 2, caractérisé en ce que ledit paramètre (DUREEFONCT) ONNEMENT) représentatif de la durée de vie de l'application est défini de manière adaptée pour chaque transaction.

   <Desc/Clms Page number 53>
4. 4. Procédé selon l'une ou l'autre des revendications précédentes, caractérisé en ce que le procédé comprend la transmission à l'utilisateur d'un numéro de série (NU) v) EROSER ! E) associé à la transaction préalablement à la transmission à l'utilisateur de ladite clef chiffrée d'activation d'application (CLE).
5. 5. Procédé selon la revendication 4, caractérisé en ce que préalablement à la transmission d'un numéro de série l'utilisateur doit présenter une requête de numéro de série, qui comprend également une première information personnelle liée à l'utilisateur (E~MAIL~UTIL).
6. 6. Procédé selon la revendication précédente, caractérisé en ce que suite à ladite requête de numéro de série le procédé comprend la création d'un numéro de série, et l'enregistrement de ce numéro de série dans une mémoire accessible par le réseau, en association avec ladite première information personnelle liée à l'utilisateur.
7. 7 Procédé selon la revendication précédente, caractérisé en ce que ladite mémoire accessible par le réseau est une table (T2) de mémorisation temporaire.
8. 8. Procédé selon l'une des revendications 5 à 7, caractérisé en ce que le procédé comprend, dans le cas où un numéro de série a déjà été attribué à la transaction, la constitution automatique d'une requête de confirmation de numéro de série, à la place d'une requête de numéro de série.
9. 9. Procédé selon l'une des revendications 5 à 8, caractérisé en ce que le procédé comprend le gravage de l'application avec ledit numéro de série.

   <Desc/Clms Page number 54>
10. 10. Procédé selon la revendication précédente, caractérisé en ce que ledit gravage est réalisé dès que l'utilisateur renseigne un programme d'installation de ladite application avec ledit numéro de série.
11. 11. Procédé selon la revendication 9 ou 10, caractérisé en ce qu'il comprend l'intégration à tous les messages ou requêtes qui sont envoyés par l'utilisateur suite audit gravage, dudit numéro de série gravé dans le message ou la requête.
12. 12. Procédé selon l'une des revendications 5 à 11, caractérisé en ce que préalablement à la transmission d'une clef chiffrée d'activation d'application (CLE) l'utilisateur doit présenter une requête de clef d'activation qui comprend également une deuxième information personnelle liée à l'utilisateur, normalement identique à ladite première information personnelle liée à l'utilisateur.
13. 13. Procédé selon la revendication précédente, caractérisé en ce que le procédé comprend l'intégration automatique du numéro de série dans ladite requête de clef d'activation.
14. 14. Procédé selon la revendication précédente, caractérisé en ce que la clef chiffrée d'activation d'application n'est transmise à l'utilisateur que si une correspondance entre information personnelle liée à l'utilisateur et numéro de série telle qu'enregistrée dans une mémoire accessible par le réseau, est vérifiée par l'information personnelle liée à l'utilisateur et le numéro de série contenus dans la requête de clef d'activation
15. 15. Procédé selon la revendication précédente, caractérisé en ce que préalablement à ma transmission de la clef chiffrée d'activation d'application le procédé comprend la confirmation du numéro de série.

    <Desc/Clms Page number 55>
16. 16. Procédé selon la revendication précédente, caractérisé en ce que ladite confirmation est réalisée par la création d'un enregistrement d'une table (T3) d'enregistrements permanents, et la suppression d'un enregistrement correspondant d'une table (T2) d'enregistrements à confirmer.
17. 17. Système de mise en oeuvre d'un procédé selon l'une des revendications précédentes, caractérisé en ce que le système comprend : . des moyens de communication avec l'utilisateur par l'intermédiaire du réseau, un serveur relié au réseau pour générer la clef chiffrée d'activation d'application, . des moyens (T2, T3) de mémorisation d'un numéro de série en association avec une information personnelle de l'utilisateur
18. 18. Système selon la revendication précédente, caractérisé en ce que lesdits moyens de communication avec l'utilisateur comprennent une boîte de messagerie du réseau pour recevoir des messages électroniques de l'utilisateur.
19. 19. Système selon la revendication 17, caractérisé en ce que lesdits moyens de communication avec l'utilisateur comprennent un serveur du réseau, relié au serveur de génération de clef chiffrée d'activation d'application et accessible par l'utilisateur, le dialogue entre l'utilisateur et le serveur étant supporté par un programme d'interface interactif du

    

    serveur auquel l'utilisateur a accès.