FR3027434A1 - Procede d'identification unique d'articles et de gestion de cette identification multi operateurs - Google Patents

Abstract

La présente invention concerne un procédé de gestion d'articles comprenant une étape de production d'une pluralité de supports matériels comportant chacun un code unique, et d'enregistrement dans une base de données les codes uniques associés à chacun desdits supports matériel, à distribuer des séries de supports à des premiers opérateur O1 et à enregistrer dans la dite base de données les identifiants desdits opérateurs en relation avec les codes uniques des supports qui leurs sont attribués caractérisé en ce que lesdites codes uniques et les enregistrements correspondants dans la base de données présentent une structure de type URLi / C1 / C2 / C3 / C4 / C5 où C1 est codé en moins de 4 octets et correspond à un identifiant de structure de l'algorithme de décodage, C2 est codé en moins de 8 octets et correspond à l'identifiant de l'opérateur Oi, C 3 est codé en moins de 8 octets et correspond à un identifiant de nomenclature d'articles déterminée par l'opérateur Oi, C4 est codé en plus de 512 octets et correspond à l'identifiant de chaque article, C5 est codé en moins de 4 octets et correspond au code d'autocontrôle dudit code.

Description

- 1 - Procédé d'identification unique d'articles et de gestion de cette identification multi opérateurs.

Domaine de l'invention Le domaine de l'invention est celui de l'apposition d'un code unique multi fonctions et multi opérateurs sur un article afin de l'identifier de façon unique et de permettre de définir des règles de réponse à une lecture du code, règles devant être contextualisées par les caractéristiques de l'action de lecture. L'ensemble de ces règles et identifications étant totalement paramétrables et accessibles pour les opérateurs intervenant dans le cycle de vie de l'objet. Les systèmes d'identification existant peuvent être réparties en deux catégories : - des systèmes dont la structuration du code est directement accessible mais son décodage nécessite l'existence d'une application spécifique sur le lecteur et ne permet que l'identification du produit et - des systèmes dont la structuration permet un accès direct à l'information via une URL comprise dans le code. Etat de la technique On connaît dans l'état de la technique le principe général de l'identification et de la traçabilité d'un produit par l'utilisation d'un code unique, apposé sous la forme d'un code graphique tel qu'un QRCode ou une forme numérique, telle qu'une étiquette RFID ou NFC. A titre d'exemple, on connaît la demande de brevet internationale W02014122321 décrivant un procédé de - 2 - réalisation d'une étiquette seule ou intégrée sur un support imprimable comportant au moins un identifiant et au moins un authentifiant dans lequel procédé ledit identifiant est imprimé sur ladite étiquette ou ledit support imprimable, incorporant ledit au moins un authentifiant et constituant tout ou partie de l'étiquette ou du support imprimable, par un dispositif d'impression, ledit procédé étant caractérisé en ce qu'il comporte : - une étape de génération d'un identifiant unique; - une étape d'impression de l'identifiant unique sur l'étiquette ou le support imprimable incorporant l'authentifiant, cet identifiant unique étant généré sans relation avec un produit auquel l'étiquette ou le support imprimable est ou sera destiné.

Le dispositif d'impression est référencé dans un système centralisé pour lequel système centralisé il est autorisé à générer et à imprimer des séries d'identifiants uniques, par exemple par un enregistrement préalable dudit dispositif d'impression auprès dudit système centralisé et l'attribution audit dispositif d'impression d'un code origine unique, code origine que ledit dispositif d'impression incorpore aux identifiants uniques qu'il génère. Inconvénients des solutions de l'art antérieur Les solutions de l'art antérieur ne permettent pas 25 une distribution des supports à une pluralité d'opérateurs indépendants, marquant de façon unitaire et unique des produits susceptibles d'être distribués dans des mêmes lieux. Elles ne permettent pas non plus de regrouper les ressources informatiques tout en permettant à des opérateurs 30 indépendants d'administrer leur organisation, tout en préservant une exploitation par des lecteurs universels. - 3 - Solution apportée par l'invention Afin de répondre à ces inconvénients, l'invention concerne selon son acception la plus générale un procédé de gestion d'articles comprenant une étape de production d'une pluralité de supports matériels comportant chacun un code unique, et d'enregistrement dans une base de données les codes uniques associés à chacun desdits supports matériel, à distribuer des séries de supports à des premiers opérateurs 01 et à enregistrer dans la dite base de données les identifiants desdits opérateurs en relation avec les codes uniques des supports qui leurs sont attribués caractérisé en ce que lesdites codes uniques et les enregistrements correspondants dans la base de données présentent une structure de type URLi / C1 / C2 / C3 / C4 / C5 OÙ C1 est codé en moins de 4 octets et correspond à un identifiant de structure de l'algorithme de décodage, C2 est codé en moins de 8 octets et correspond à l'identifiant de l'opérateur 01, C3 est codé en moins de 8 octets et correspond à un identifiant de nomenclature d'articles déterminée par l'opérateur 01, C4 est codé en plus de 512 octets et correspond à l'identifiant de chaque article, C5 est codé en moins de 4 octets et correspond au code d'autocontrôle dudit code. Le procédé comportant des étapes d'attribution à chaque opérateur Oi d'une base de données BDDi et des ressources informatiques dédiées Ri et des étapes de configuration de l'espace d'enregistrements des codes C31 et C41 , des nomenclatures associés et le cas échéant des attributs associés, ainsi que des règles de consultation et de modification des enregistrements par des utilisateurs tiers, Le procédé comportant en outre des étapes de lecture des supports par un lecteur comportant des moyens de connection à l'url ou d'exploitation local et de comparaison à un sous-ensemble de la base de données BDDi périodiquement synchronisée. - 4 - Avantageusement, le procédé de gestion d'articles selon la revendication principale caractérisé en ce que lesdites règles sont enregistrées dans un moteur de règles comprenant des fonctionnalités de déclenchement en fonction de l'identifiant du lecteur, ou de la localisation du lecteur, ou d'une donnée temporelle, ou d'une information enregistrée dans la base de données BDDi ou d'une information provenant d'un événement externe. Selon une variante avantageuse, lesdites données 10 temporelles sont la date système du lecteur local et/ou la date système du serveur, ainsi qu'une données temporelle enregistrée dans la basse de données BDDi. Selon une variante, lesdites données temporelles sont calculées en fonction d'un événement lié au cycle de vie 15 de l'article identifié par le support matériel. Selon un mode de réalisation particulier, ledit moteur de règle active conditionnellement une action du serveur. Selon un autre mode de réalisation, chacun codes 20 est unique pour l'ensemble des combinaisons. De préférence, la partie C2 / C3 / C4 / C5 du code est chiffrée. Description détaillée d'un exemple non limitatif de l'invention 25 L'invention sera mieux comprise à la lecture de la description d'un exemple de réalisation non limitatif, se référent aux dessins annexés où : - la figure 1 représente une vue schématique de la structure du code - 5 - - la figure 2 représente un schéma de principe du fonctionnement de la plateforme. L'invention vise à apporter une solution au problème de publication d'information contextuelle sur un 5 produit ne comportant pas de mécanisme informatique embarqué pour répondre à ce type de sollicitation. Le cycle de vie d'un article pouvant faire intervenir plusieurs opérateurs différents intervenant sur chaque étape du dit cycle de vie (conception, fabrication, 10 packaging, logistique, distribution, utilisation, recyclage) l'identification doit être capable de répondre aux différents besoins des opérateurs via ce code unique. Chaque opérateur doit pouvoir accéder, partager et modifier les informations relatives aux produits tout en 15 assurant une cohérence globale au niveau du produit. La codification unique apposée sur le produit doit donc faire le lien entre le produit et ses informations statiques, l'opérateur en charge de la gestion de ces informations au moment de la demande, les données 20 contextuelles de la demande et des informations extérieures pouvant être liées à la demande. Les systèmes de codification existant permettent une identification unique d'un produit mais ne répondent pas à la problématique de la gestion de différents opérateurs 25 intervenant durant la vie du produit ni de la réponse dynamique et contextuelle d'une lecture du code. - 6 - L'invention vient compléter le principe des système de codification dont la structuration permet un accès direct à l'information via une URL comprise dans le code en y incluant les fonctions suivantes : - Gestion multi opérateurs - Système d'encryptions du code - Support de différents algorithmes de codification pour répondre au besoin - Ajout d'un URL globale partagée par tous les codes - Gestion dans une base de données unique des informations de décodage des codes - Centralisation des données sur les produits - Ajout de règles de routage contextuelles pour la réponse à la lecture d'un code. - Application de filtre de sélection de la règle en fonction de données interne ou externe à la base de données de l'opérateur. - Paramétrage des actions en réponse à ces dites-règles Système de codification Le système de codification est basé sur la génération d'un code unique associé à un identifiant d'algorithme et une url. Le code et l'algorithme permet d'identifier de façon unique la combinaison opérateur et article.

Le système de codification doit pouvoir s'adapter à tous types d'articles et être totalement portable d'une industrie à une autre. Il ne fait qu'identifier d'un objet (réel ou virtuel) unique (SKU). De ce fait la structure du code ne doit pas être déterministe sur la catégorie des objets sous-jacents. Les différents algorithmes proposés permettent : - 7 - - De répondre à une classification hiérarchique des articles par gamme/famille/.. cette classification est gérée dans la base de données, - De gérer plusieurs milliards d'article unique. - De crypter le code via un algorithme générant une suite aléatoire de chiffres - Le code doit inclure un numéro de série incrémental Un code est composé de 5 parties : - Cl : identification de l'algorithme. La structure de codification doit permettent de supporter plusieurs algorithme dépendant du contexte de l'opérateur. - C2 : l'identifiant de l'opérateur. Ce code identifiant est utilisé pour router la demande vers la base de données d'information spécifique à l'opérateur. Ce code peut être optionnel, dans ce cas, la sélection de l'opérateur doit se faire via le code C4. La base de données de routage maintient une table de correspondance pour la recherche de l'opérateur spécifié. Cette possibilité permet de répondre au besoin de codification sur les articles dont la multitude d'opérateur potentiel ne permet pas de dédié l'article à un seul opérateur. Chaque code C2 est unique par opérateur. Un opérateur peut disposer d'un grand nombre de code lui appartenant. Ces codes peuvent être basés sur tous les types d'algorithmes existant sans aucune restriction. C2 peut supporter jusqu'à 2 milliards d'opérateurs. - C3 permet d'identifier la gamme de l'article. C3 est optionnel. Il est utilisé pour dédier le code à une classification spécifique de l'opérateur. Ce code permet aussi d'assurer une identification de gamme sans identification unitaire associé. - C4 est le code série de l'article unique. C'est un code incrémentale qui est unique pour chaque article dans la - 8 - gamme, ou pour la société. Le critère d'unicité dépend de l'algorithme associé. - C5 : il s'agit d'un code de vérification. Il permet de s'assurer par un calcul de CRC que le code lu est correctement décrypté. Les codes C2, C3 et C4 sont des codes numériques correspondant à des identifiants interne de la base de données opérateurs DBBi. En fonction du paramétrage opérateur, ces codes permettent d'identifier de façon unique une gamme, un produit ou une unité produit (SKU). Les codes ainsi composés sont ensuite cryptés pour leur assurer un premier niveau de sécurité et une compression pour ramener la taille du code à moins de 25 octets. La combinaison de ses 5 codes permet de créer une 15 structure d'identification pouvant gérer jusqu'à 1016 combinaisons uniques L'algorithme de cryptage doit pouvoir être décodé sans nécessité d'accéder à des informations externes ni de structure complexe d'authentification. Il doit permette de 20 générer une suite d'apparence aléatoire. Pour cela il est basé sur un algorithme à deux passes. La première effectue un premier niveau de cryptage en se basant sur une clé fixe. La première passe permet aussi de définir la clé de cryptage pour la deuxième passe. Cette clé est dynamique et change en 25 fonction de la valeur du code. En sortie de première passe le code est constitué de 2 zones : - Dl sur 512 octets, qui représente les codes initiaux agrégés et passé à un premier filtre de type xor en 30 utilisant les clés associées. -9 - - D2 représente la clé de cryptage pour la deuxième passe. Cette clé est le résultat d'une combinaison de bits du code Dl. Chaque algorithme défini par le code Cl dispose de 5 ses propres clés internes de cryptage. En sortie de la deuxième passe le code est structure de la façon suivante : - K1 : sur 512 octets, il s'agit du code crypté en alphanumérique simple. 10 - K2 : la clé de vérification de lecture basée sur un algorithme de checksum du code Ki. Exemple de Code : - Code avec C2 et C4: http://tr12.ee?r=37548610872FDA Ce code 15 correspond à une société dont l'identifiant est 7 (C2) et à un produit dont l'identifiant est 3004 (C4). - Code avec C2 et C3. http://tr12.eu?a=19620F3B61 Ce code correspond à une société dont l'identifiant est 7 (C2) et à une gamme dont l'identifiant est 1 (C3). 20 - Code avec C2, C3 et C4 : http://tr12.eu?t=5040081068C ce code correspond à la même société et à la même gamme mais avec un identifiant de produit à 256564 (C4) Dans les 3 exemples, le code C, de vérification est représenté par les 2 derniers digits. 25 L'algorithme de cryptage doit être indépendant de la structure de marquage du code sur l'article (QR code, DataMatrix, RFID, NFC, ...). - 10 - Il doit pouvoir aussi supporter des standards de codification tels que ceux définis par GS1. Le code crypté ainsi généré peut être représenté par une structure de lettre et de chiffre. Le code étant utilisé comme partie d'une URL, il ne comporte que des données alphanumériques simples (Lettre et Chiffre) en majuscule. Le zéro et la lettre 0 ont la même signification. Pour le marquage RFID ou NFC l'algorithme transforme ce code alpha numérique en données binaires.

En cas d'existence sur un même article d'un code optique et d'un code radio, les données Cl à C5 codées doivent être similaires. L'algorithme doit permettre de limiter la taille maximum du code crypté à 88 bits pour permette son utilisation 15 sur une puce RFID. L'algorithme doit être bijectif, c'est-à-dire qu'il doit pouvoir être utilisé dans les deux sens de la structure de code vers le code crypté et du code crypté vers la structure de code. 20 Chaque algorithme dispose de ces propres clés de cryptage. Chaque clé est unique par algorithme. La taille d'une clé est de 15 à 255 caractères. Le décodage du code ne doit pas nécessité une puissance CPU importante et doit pouvoir être décodé en moins 25 de 100ms sur un CPU mobile de fréquence de 1 Ghtz. La lecture et le décodage du code doivent pouvoir être faite soit sur le périphérique soit sur le serveur applicatif dans le cloud.

Le décodage sur le périphérique doit permettre un travail en mode déconnecté du réseau. Ce mode peut permettre via un sous ensemble de la base opérateur de faire le lien entre le code et le type d'article associé ainsi que son numéro d'identification unique. Le même décodage doit aussi pouvoir être réalisé sur le serveur et doit retourner les mêmes informations. Les algorithmes sont indépendants des bases opérateurs. Cependant, la solution permet à un opérateur de 10 choisir son algorithme en fonction du niveau demandé de sécurité/confidentialité. Principe de lecture d'un code La lecture d'un code est basée sur le processus suivant 15 - Lecture du code avec le lecteur approprié, pour les codes optiques, cela peut être une douchette filaire ou non, un pda, une tablette, un smartphone ou tout autre équipement disposant d'une caméra et de l'algorithme de lecture du code optique (Qrcode, pdf 14, datamatrix, ...). La 20 structure du code ne limite pas l'utilisation d'un algorithme d'impression du code en forme 2D. Pour les codes radio, il peut s'agir d'une structure fixe de lecture de code (RFID ou NFC) tel qu'un portique ou d'un « tunnel rfid » ou d'un lecteur portable type pda ou 25 smartphone. - Validation du code lu (K1) avec la clé K2. En cas de non validation, un message d'erreur est retourné pour permettre au lecteur de relire le code optique ou radio. - Application de l'algorithme adéquat (en fonction du code 30 Cl) pour récupérer les codes C2 à C4 - 12 - - Recherche dans la base de routage centralisée des informations relatives à l'opérateur identifié par le code C2. Si le code C2 est non existant, le code C4 est alors utilisé pour valider l'affectation d'un range de code C4 à un opérateur. - Sélection de la base de données « opérateur » et recherche des informations associées à l'article. La recherche des informations associées à un article est paramétrable en fonction du contexte de la 10 lecture. Les paramètres suivant sont associés à chaque lecture - Identifiant du code : il s'agit de la combinaison des codes C2, C3 et C4. - Horodatage : en heure locale l'indicateur temporel de l'événement. Le moteur doit pouvoir transcrire 15 l'horodatage en Temps universel, ou le conserver en temps local - Identifiant du lecteur. Si le lecteur est déjà identifié soit par un mécanisme d'authentification sur l'application cible ou par un identifiant unique 20 accessible (type imsi) le code d'identification sera transmis lors de la lecture, sinon la lecture sera réputé anonyme - Identification de l'utilisateur. Dans le cas d'un lecteur déjà connu, l'utilisateur a la possibilité de 25 s'identifier via une nom/mot de passe. Il reçoit un token de connexion. Ce token est ensuite réutilisé pour permettre l'identification ultérieure d'une demande connexion. - Positionnement du lecteur, dans le cas d'un périphérique 30 disposant d'information de géo localisation, et dans l'hypothèse où l'utilisateur l'accepte, les données de géo localisation sont transmises avec la lecture. Dans le - 13 - cas contraire, les informations de connexion au réseau internet, information publique sont transmises. Le type de lecteur, chaque lecteur envoie une information d'identification de son type (smartphone, tablette, lecteur industriel, ....). Cette information est retournée avec la lecture. Ces six paramètres sont utilisés par le moteur de règle pour contextualiser la lecture. Ils ne sont pas tous obligatoires. Dans ce cas chaque paramètre dispose d'une valeur par défaut. Les paramètres « identifiant du code, lieu et date » reste contextuels à la lecture. La plateforme dispose d'une base de référence des points d'accès IP permettant de définir pour une adresse IP, le pays du scan, la région, ou la ville. Lors de la lecture d'un code la base de données de géolocalisation est utilisée pour définir les informations géographiques nécessaires à la sélection des règles. La figure 2 représente un schéma de principe du fonctionnement de la plateforme.

Le moteur de règle fonctionne en deux passes. La première consiste à sélectionner la règle correspondant au contexte de lecture, la deuxième à appliquer la règle associée pour définir l'action de réponse à cette lecture.

Exemple de lecture d'un code. A partir d'un smartphone, un consommateur lit le code suivant : http://tr12.eu/?r=37548610872FDA. - 14 - Le moteur décode le code et trouve qu'il s'agit de l'opérateur C2 ayant l'identifiant 7 et pour l'article unitaire ayant l'identifiant 3004. Via l'adresse IP, le moteur sait que la lecture a 5 lieu en France dans une région proche de Marseille. Le consommateur n'est pas identifié, il s'agit d'une lecture anonyme à partir d'un smartphone. Le moteur de règle sélectionne la où les règles correspondant aux critères suivants pour l'opérateur C2 : 10 - Lecture anonyme depuis un smartphone dans la région de Marseille (France) le 30 septembre 2014 à 20h35. - Plusieurs règles peuvent s'appliquer. Le moteur passe donc sur les critères de la passe 2. Le produit est un champagne Brut, année 2011, il a été vendu au caviste 15 « XXX ». - L'action associé à cette lecture est router la demande sur le site de « XXX » en passant en paramètre le nom du magasin le plus proche. - Le site de « XXX » (hors environnement du moteur) peut 20 donc directement guider le consommateur pour venir dans le magasin le plus proche pour y retrouver des promotions. - Une autre action permet d'envoyer une information dans une application interne gérer par l'opérateur C2 pour 25 l'informer d'un scan de ses produits dans la région de Marseille. L'opérateur C2 peut donc analyser les différents accès à ces produits et mieux répartir ses stocks locaux. 30 - 15 - Une règle se caractérise donc par les trois attributs suivants - Une priorité - Une sélection contextuelle liée à la lecture - Une sélection des codes par recherche dans une liste paramétrable - Un ou plusieurs actions associées à cette règle Dès qu'une règle peut s'appliquer, la ou les actions sont déclenchées, et le moteur de règles stoppe la 10 recherche de règle. Paramétrage d'une règle Le paramétrage d'une règle se fait via un assistant qui guide l'utilisateur dans la définition de sa règle. Il se fait en 3 étapes : 15 - Sélection des critères contextuels - Sélection des objets métiers associés à la règle - Sélection des valeurs d'attributs - Définition des actions de réponse à la règle La gestion de l'application de la règle en fonction 20 du cycle de vie du produit sous-jacent s'effectue via la sélection de l'objet « produit » et des attributs associés. La définition de la règles est stockes en base de données dans trois messages XML (critères contextuels, critères métiers, actions). 25 - 16 - Message Contexte -<contextes> -<conteee> <nom> <nom> <type> type> <operateur> < opera teur> - <values> <value:, c- value> <value', value> <values> <contexte> <contextes> Message Objets -<objets> -<objet> -<attribles> - <attribut> <nom> < 'nom> <tYPe> <type> <operateur> < operatenr> - <values> <value> <value> <value> < value> < values: < attribut> < attributs> - <relation> <avant> <avant> <apres> < apres> relatim - <objet> <objets> Les conditions sont du type opérateur simple (= = , >,< ,<=, >=), opérateur de chaîne (contient, sous-chaine...), opérateur d'ensemble (inclus ou non, intersection, union), opérateur date (jour, jours du mois, jour de semaine, opérateur booléen (ou, non, et) mais aussi des opérateurs avancés du type (à plus de X km de, Lors de l'enregistrement de la règle, celle-ci est pré-processée pour optimiser son stockage mémoire et son exécution. Le résultat « binaire » est stocké en base de données.

Le langage utilisé pour pré-processer les règles est basé sur le principe d'une lecture séquentielle des conditions. Dès la première condition trouvée qui ne - 17 - correspond pas aux critères demandés, le moteur passe à la règle suivante. Les règles sont définies dans une liste ordonnée en fonction de leur priorité. Chaque règle est associée à un contexte opérateur 5 et ne peut s'appliquer qu'aux codes définis pour cet opérateur. Les règles sont stockées dans les bases de données DDBide chaque opérateur. Sélection d'une règle La sélection d'une règle se passe en deux temps, 10 une fois une règle trouvée correspondant aux critères les actions sont déclenchées et le moteur stoppe son analyse. La phase une consiste à choisir les règles éligibles en fonction des données contextuelles. Le moteur doit charger en mémoire l'ensemble des 15 critères de sélection associés aux règles existantes par client. De ce fait, la première passe ne nécessite pas d'accès aux bases de données ou à des données externes et peut donc s'exécuter sans accès disque et façon optimisée. Les critères sont évalués dans l'ordre suivant (par 20 ordre de rapidité d'exécution): - Identification du périphérique ou de l'utilisateur (identifiant unique ou catégorie) - Temporel : entre deux dates, un jour de semaine, un jour du mois, ... 25 - Localisation : pays, région Dès que les trois critères sont validés, le moteur passe à la deuxième passe. Si l'un des critères n'est pas correct, la règle n'est pas sélectionnée et la règle suivante en fonction des priorités est analysée. - 18 - La deuxième passe consiste à analyser en fonction du code lu qui identifie de façon unique l'article. Ce code unique est utilisé pour récupérer les valeurs des attributs des objets précisés dans la règle.

En fonction des objets métiers sélectionnés, le moteur de règle va lire les données dans la base BDDi pour récupérer les valeurs des attributs et validé si les critères de sélection sont valides. Les objets métiers peuvent être de trois types : - Interne. Il s'agit d'information issue du système d'information client via une interface comme par exemple, un ordre de fabrication, un bon de livraison. La plateforme peut associé via la pose de capteur sur la ligne de fabrication des codes unitaires à un ordre de fabrication, un bon de livraison, .... - Liste : Le principe d'une liste est défini par la combinaison d'un ou plusieurs intervalles de code. Un intervalle peut contenir de 1 à n code. Il est caractérisé par sa valeur minimale et sa valeur maximale.

La liste est créée via l'utilisation de périphérique de lecture des codes de type douchette sur les articles. Un intervalle est caractérisé par une date de validité. La définition des listes est stockée dans la base de données de l'opérateur. Les listes peuvent se superposer, dans ce cas le choix de la liste se fait soit par la date de validité soit par la priorité de l'intervalle. - Externe : dans ce cas, il s'agit d'information en provenance de système externe à la solution et à l'opérateur. Le principe est de pouvoir récupérer des données non liées au système d'information pour mieux paramétrer l'action. Par exemple, aller interroger une base de données météorologique ou événementielle pour configurer la réponse à la lecture du code. - 19 - La sélection d'une règle se base sur un principe de liste. Une liste peut être soit prédéfinie, soit construite dynamique à la lecture du code. Gestion des listes.

Les listes peuvent rapidement prendre du volume et leur gestion peut devenir complexe. Pour faciliter le stockage et la gestion un algorithme de gestion des listes assure leur gestion : Si une liste contient plusieurs intervalles, les informations sur les extrémités des intervalles sont stockes par une combinaison de bitmap et de valeurs extrêmes. La taille des bitmap s'adapte aux besoins de regroupement des codes. Le moteur de règle dispose d'une interface de 15 paramétrage permettant de définir ces différentes listes. Les listes peuvent assurer la gestion hiérarchique des codes telle que l'association produit/carton/palette. Dans ce cas chaque objet conteneur contient un ou plusieurs bitmap permettant de définir les codes contenus.

20 Gestion des actions. Une fois les critères de sélection validée, le moteur doit déclencher l'action de réponse à la lecture du code. Pour cela, il existe plusieurs types d'action : - Affichage d'une page interne à l'application. Ce cas 25 existe si l'application de lecture est gérée par la plateforme. Dans ce cas, la règle route la demande sur une page en associant le code lu - Affichage d'une page Web externe. Dans ce cas la plateforme construit l'url externe en y associant les - 20 - paramètres. La liste des paramètres, correspondant à des valeurs d'attribut d'objet est totalement paramétrable. De même l'URL est paramétrable en fonction de l'article lu. - Appel d'un programme externe. Cela peut se faire soit via l'appel d'un WebService ou via un connecteur local installé sur le serveur distant. Cet appel permet d'exécuter une fonction du SI de l'opérateur.

Claims (7)

1. REVENDICATIONS1 - Procédé de gestion d'articles comprenant une étape de production d'une pluralité de supports matériels comportant chacun un code unique, et d'enregistrement dans une base de données les codes uniques associés à chacun desdits supports matériel, à distribuer des séries de supports à des premiers opérateurs 01 et à enregistrer dans la dite base de données les identifiants desdits opérateurs en relation avec les codes uniques des supports qui leurs sont attribués caractérisé en ce que lesdites codes uniques et les enregistrements correspondants dans la base de données présentent une structure de type URLi / C1 / C2 / C3 / C4 / C5 OÙ C1 est codé en moins de 4 octets et correspond à un identifiant de structure de l'algorithme de décodage, C2 est codé en moins de 8 octets et correspond à l'identifiant de l'opérateur 01, C3 est codé en moins de 8 octets et correspond à un identifiant de nomenclature d'articles déterminée par l'opérateur 01, C4 est codé en plus de 512 octets et correspond à l'identifiant de chaque article, C5 est codé en moins de 4 octets et correspond au code d'autocontrôle dudit code, le procédé comportant des étapes d'attribution à chaque opérateur Oi d'une base de données BDDi et des ressources informatiques dédiées Ri et des étapes de configuration de l'espace d'enregistrements des codes C31 et C41 , des nomenclatures associés et le cas échéant des attributs associés, ainsi que des règles de consultation et de modification des enregistrements par des utilisateurs tiers, le procédé comportant en outre des étapes de 30 lecture des supports par un lecteur comportant des moyens de connection à l'url ou d'exploitation local et de comparaison à- 22 - un sous-ensemble de la base de données BDDi périodiquement synchronisée.
2. 2 - Procédé de gestion d'articles selon la revendication principale caractérisé en ce que lesdites règles sont enregistrées dans un moteur de règles comprenant des fonctionnalités de déclenchement en fonction de l'identifiant du lecteur, ou de la localisation du lecteur, ou d'une donnée temporelle, ou d'une information enregistrée dans la base de données BDDi ou d'une information provenant d'un événement externe.
3. 3 - Procédé de gestion d'articles selon la revendication précédente caractérisé en ce que lesdites données temporelles sont la date système du lecteur local et/ou la date système du serveur, ainsi qu'une données temporelle enregistrée dans la basse de données BDDi.
4. 4 Procédé de gestion d'articles selon la revendication 2 caractérisé en ce que lesdites données temporelles sont calculées en fonction d'un événement lié au cycle de vie de l'article identifié par le support matériel.
5. 5 - Procédé de gestion d'articles selon la revendication 2 caractérisé en ce que ledit moteur de règle active conditionnellement une action du serveur.
6. 6 - Procédé de gestion d'articles selon la revendication 1 caractérisé en ce que chacun codes est unique 25 pour l'ensemble des combinaisons.
7. 7 Procédé de gestion d'articles selon la revendication 1 caractérisé en ce que la partie C2 / C3 / C4 / C5 du code est chiffrée.