SCIT/P 8/99 Rev.1 ANNEXE 5

ANNEXE 5 NORME CONCERNANT LE DÉPÔT, LE TRAITEMENT ET LE STOCKAGE ÉLECTRONIQUES DES DEMANDES INTERNATIONALES EN VERTU DU TRAITÉ DE COOPÉRATION EN MATIÈRE DE BREVETS (PCT) ET LA GESTION DES DOSSIERS ÉLECTRONIQUES RELATIFS À CES DEMANDES Annexe F, Version 3.1 Résumé Le présent document contient une présentation du PROJET de norme applicable au dépôt, au traitement et au stockage électroniues des demandes internationales et à la gestion des pièces correspondantes, conformément aux instructions administratives pertinentes et en vertu de la règle 89bis du PCT. Il contient les principes techniues fondamentaux et certains principes juridiues ui doivent être adoptés pour le dépôt électroniue et renvoie à des Appendices techniues pour le détail des applications spécifiues. La présente version renvoie aux Appendices I et II à savoir la Norme techniue trilatérale pour l échange en ligne de documents de propriété intellectuelle dans un environnement ICP. Il pourra être établi d autres appendices pour traiter de l échange de documents sur disue ou en l absence d ICP. Table des matières 1 DÉFINITIONS... 2 2 CONDITIONS EXIGÉES DU DÉPOSANT EN CE QUI CONCERNE LE DÉPÔT ÉLECTRONIQUE DE DEMANDES INTERNATIONALES... 2 2.1 ENVOI...3 2.2 SÉCURITÉ...4 2.3 CONDITIONS DE FORME APPLICABLES AUX DOCUMENTS...6 3 CONDITIONS EXIGÉES DES OFFICES ET DES ADMINISTRATIONS... 6 3.1 EXEMPLAIRE ORIGINAL...6 3.2 ÉCHANGE DE PIÈCES...6 3.3 INTÉGRITÉ DE LA TRANSMISSION...7 3.4 ACCUSÉ DE RÉCEPTION DE LA COMMUNICATION...7 3.5 INTÉGRITÉ DU STOCKAGE...7 3.6 GESTION DES DOSSIERS ÉLECTRONIQUES...7 4 OPTIONS POUR LES OFFICES RÉCEPTEURS... 11 4.1 CONTEXTE...11 4.2 CATÉGORIES D OPTIONS (EN VERTU DU PROJET D INSTRUCTION 701.C))...12 APPENDICE 1 NORME TECHNIQUE TRILATÉRALE POUR L'ÉCHANGE EN LIGNE DE DOCUMENTS DE PROPRIÉTÉ INTELLECTUELLE DANS UN ENVIRONNEMENT ICP... 14 APPENDICE 2 DTD SELON LE XML POUR L'ÉCHANGE DE DOCUMENTS DE PROPRIÉTÉ INTELLECTUELLE... 89 n:\orgipis\shared\williams\scit\projects\p8\an5_f.doc

Annexe 5, page 2 1 Définitions Aux fins de l Annexe F, l expression : a) signature électroniue s entend de données figurant dans un message, apposées sur un message ou associées d une manière logiue à un message, sous forme électroniue, et de toute méthode utilisée en relation avec un message susceptible de permettre de s assurer de l identité du titulaire de la signature et d indiuer ue ce dernier certifie les renseignements ui figurent dans le message; b) signature électroniue sécurisée s entend d une signature électroniue au sujet de lauelle il peut être prouvé, grâce à l utilisation d une procédure de sécurité, u elle i) appartient au seul titulaire de la signature dans le contexte dans leuel elle a été utilisée; ii) a été créée et apposée sur le message par le titulaire de la signature ou avec des moyens dont seul le titulaire de la signature a la maîtrise, et par nulle autre personne; iii) a été créée et est liée au message d une façon telle u elle permet de garantir ue l intégrité du message a été préservée; Une des applications de cette notion est la signature numériue créée grâce à l utilisation d un certificat produit par une infrastructure à clé publiue et d une clé privée correspondante. c) message électroniue s entend de l information produite, envoyée, reçue ou conservée par des moyens électroniues, optiues ou analogues; d) vérification de l intégrité du document s entend du mécanisme par leuel l intégrité d un document peut être vérifiée tant au cours de sa transmission et de son stockage u à un stade ultérieur. La signature numériue peut être utilisée à cette fin; e) titulaire de la signature s entend de la personne par ui, ou au nom de ui, une signature électroniue sécurisée peut être créée et apposée sur un message électroniue; f) autorité de certification s entend de la personne physiue ou morale ui, dans le cadre de ses activités, fournit des services d identification utilisés à l appui des signatures électroniues sécurisées. g) certificat s entend d un message électroniue ou de toute autre pièce émise par une autorité de certification et ui a pour objet de confirmer l identité d une personne physiue ou morale ui détient un dispositif donné de signature. 2 Conditions exigées du déposant en ce ui concerne le dépôt électroniue de demandes internationales La présente annexe contient un ensemble de pratiues recommandées en ce ui concerne l envoi de documents électroniues dans le cadre du PCT, fondées sur les applications techniues définies dans les Appendices techniues.

Annexe 5, page 3 2.1 Envoi L information échangée au cours d une transaction est scindée en plusieurs pauets de données. Chaue phase de l échange correspond au transfert d un pauet de données entre le déposant et l office récepteur. Toutes les transactions devront comporter les uatre pauets suivants : Demande de ticket Ticket Documents de propriété intellectuelle Certificat de confirmation. Quelle ue soit la procédure concernée, le pauet documents de propriété intellectuelle contiendra, dans tous les cas, les données effectivement établies par le déposant (nouvelle demande, paiement de taxe, revendications de remplacement, etc.) S agissant spécifiuement du dépôt en ligne selon le PCT, le mécanisme du ticket fonctionne comme suit : Étapes d une session électroniue Déposant Envoi d une demande de ticket avec empreinte du message (première partie de la transmission) Office récepteur Attribution d une date de dépôt provisoire Envoi du ticket comportant l accusé de réception et la date de dépôt provisoire Envoi du pauet contenant le reste des données relatives à la nouvelle demande Envoi du certificat de confirmation Vérification de l identité des empreintes du message Une session électroniue est ouverte entre le déposant et l office récepteur aux fins du dépôt d une demande internationale de brevet. Au début de cette session, un code correspondant à l empreinte du message, dérivée de manière univoue de l ensemble des fichiers ui constituent les éléments nécessaires de la demande internationale, est transmis à l office. Le codage est tel ue la moindre modification apportée à l un de ces fichiers entraîne une modification de l empreinte. Dès réception de cette empreinte, et dans le cadre de la session, l office envoie au déposant un accusé de réception comportant la date de réception de l empreinte du message. Le déposant poursuit alors la session et transmet l intégralité du jeu de fichiers ui constituent la demande internationale.

Annexe 5, page 4 Dès réception du jeu complet des fichiers, les pièces constitutives de la demande sont traitées de façon à restituer l empreinte du message. Celle-ci est comparée à l empreinte initiale, celle ui a été envoyée en début de session. Si les deux empreintes correspondent, un accusé de réception est envoyé au déposant. Si elles ne correspondent pas, le déposant en est informé. La session peut alors prendre fin. Ce mécanisme d envoi est particulièrement adapté au dépôt en ligne de fichiers de taille normale. Dans ce cas, la transmission du jeu complet des fichiers des pièces constitutives de la demande devrait pouvoir s effectuer en une seule session. En revanche, ce mécanisme ne devrait pas être utilisé pour le dépôt en ligne de fichiers exceptionnellement volumineux. L Appendice I contient des précisions concernant la taille acceptable pour les fichiers destinés à être envoyés en ligne. Les détails techniues concernant la mise en œuvre de ce mécanisme figurent à l Appendice I. 2.2 Sécurité Il est nécessaire de veiller à la sécurité lors de la réception, du stockage et du traitement des pièces électroniues relatives à un brevet pour préserver les ualités suivantes de ces pièces : Authenticité Intégrité Confidentialité Non-répudiation On entend par authenticité d une pièce électroniue le fait pour cette pièce de contenir effectivement ce u elle est censée contenir et d exprimer l objectif poursuivi par la partie ui l a signée. Le test de l authenticité est un critère de recevabilité des plus critiues et l un de ceux ui risuent de présenter le plus de difficultés : la notion est en effet définie de façon assez générale et l authenticité est généralement établie sur la foi d un témoignage (celui par exemple de l organisme ui gère les pièces). La condition de l authentification ou de l identification comme préalable à la recevabilité est remplie lorsue des preuves suffisantes permettent de démontrer ue les éléments avancés correspondent aux affirmations de la personne ui les avance. Cette condition suppose ue le dossier, outre u il doit avoir été créé, reçu, enregistré et stocké de façon précise et fiable, ait été : créé, traité et/ou communiué par une partie identifiable et contrôlable à des fins déterminées, reçu ou créé et stocké à un moment déterminé. La condition de confidentialité consiste à veiller à ce ue l information concernant le contenu ou l existence d une demande internationale ne soit pas divulguée ou révélée à des personnes non autorisées. La protection de la confidentialité des dossiers relatifs à des demandes internationales de brevets est obligatoire en vertu des articles 30 et 38 du PCT. Sauf reuête ou autorisation du déposant, la confidentialité doit être préservée jusu à la publication internationale de la demande, le cas échéant. [Insérer le texte de l OMPI]. Il n est possible de faire valoir un brevet en justice ue si les dossiers de brevet sont recevables en tant ue preuves des droits du titulaire de brevet. Il est donc essentiel u ils soient créés dans les formes et protégés tant u ils sont en instance et ultérieurement afin d être

Annexe 5, page 5 suffisamment crédibles aux fins de l établissement des droits du titulaire du brevet. L objectif principal d un environnement propice au commerce électroniue est de veiller à ce ue les dossiers présentent ces ualités. De plus, le PCT et les législations nationales exigent ue la confidentialité des renseignements ui figurent dans les demandes de brevet soit protégée par tous les offices et par tous les systèmes ui traitent ces fichiers. 2.2.1 Authenticité - Signatures électroniues Dans le droit des brevets, nous nous fions habituellement à la signature ui figure sur un document pour établir son authenticité, c est-à-dire confirmer u un document est bien ce u il prétend être, ue son auteur est bien la personne censée en être l auteur et ue le document exprime bien la volonté de l auteur. Dans les documents électroniues, les signatures électroniues ont la même finalité. Une signature électroniue exprime la volonté de la partie ui a apposé la signature de donner son identité et d approuver le contenu du document aux fins indiuées dans ce document. La signature peut être une signature électroniue simple, telle u une série de caractères choisis par l auteur pour décliner son identité et pour indiuer sa volonté de signer ce document précis, ou une signature électroniue sécurisée associée au document. Dans ce cas, l intention d utiliser la signature électroniue sécurisée est mentionnée dans le document. Les formats recevables pour les signatures électroniues sont définis à l Appendice I. 2.2.2 Intégrité Vérification de l intégrité du document On entend par respect de l intégrité le fait de veiller à la cohérence des données notamment en évitant (et en décelant) l altération ou la destruction non autorisées de données. La préservation de l intégrité des dossiers de brevet est essentielle à la protection des droits de propriété intellectuelle et de la valeur des actifs de l inventeur. En conséuence, des contrôles doivent être mis en place pour assurer la préservation de l intégrité, de l authenticité et de la fiabilité des dossiers de l office de propriété intellectuelle au fil du temps. Cet objectif peut être atteint grâce à une gestion des pièces électroniues ui vise à les protéger de toute perte, de tout déplacement ou de toute modification ou destruction non autorisées. Et il importe d autant plus de prévoir des contrôles pour protéger et préserver de manière adéuate les pièces électroniues ue les preuves de falsification risuent de ne pas être aussi faciles à établir pour des pièces électroniues ue pour des pièces sur papier. 2.2.3 Confidentialité - Chiffrement Tous les systèmes de réception, de production, de stockage, de traitement et de transmission de pièces électroniues seront dotés dans toute la mesure raisonnable de dispositifs permettant de préserver la confidentialité des pièces électroniues. Toutes les applications protégeront les métadonnées relatives aux pièces électroniues de la demande internationale. La confidentialité de la connexion entre le déposant et un office récepteur, ou entre un office récepteur ou une administration et le Bureau international, sera protégée grâce au chiffrement de la transmission. 2.2.4 Non-répudiation Cette notion permet à l expéditeur de données de disposer de preuves solides et fondées du fait ue les données ont bien été transmises (avec la collaboration du destinataire) et au destinataire de bénéficier de preuves solides et fondées concernant l identité de l expéditeur, preuves suffisantes pour éviter u il soit possible de nier de manière crédible avoir envoyé ou reçu les données. Cette notion recouvre aussi la possibilité pour un tiers de vérifier l intégrité et l origine des données.

Annexe 5, page 6 2.3 Conditions de forme applicables aux documents Outre u ils doivent satisfaire aux conditions énoncées dans le PCT en ce ui concerne leur contenu, les documents échangés par voie électroniue doivent répondre aux spécifications techniues énoncées à l Appendice I. Chaue office récepteur peut choisir d accepter des documents dans des formats autres ue ceux ui sont mentionnés à l Appendice I mais, s il laisse au déposant cette possibilité, il doit l inviter à envoyer à nouveau la demande dans un format directement utilisable avant tout échange avec une administration ou le Bureau international. Lorsu un nouvel envoi de ce type a lieu, les documents déposés initialement doivent être à nouveau transmis avec les documents ui font l objet de ce nouvel envoi. 3 Conditions exigées des offices et des administrations La présente section contient un ensemble uniforme de conditions de procédure (il ne s agit plus de simples recommandations) ue les offices récepteurs, les administrations chargées de la recherche internationale, les administrations chargées de l examen préliminaire international et le Bureau international seront tenus de respecter en ce ui concerne les dépôts électroniues. L objet de la présente section est de fixer des procédures précises de gestion des pièces par toutes les parties concernées, ui garantiront l authenticité, la confidentialité, l intégrité et la non-répudiation des pièces électroniues et grâce auxuelles ces pièces pourront être présumées authentiues en cas de nécessité. Les systèmes de gestion automatisée des pièces utilisés par les offices du PCT, uels u ils soient, doivent être conçus pour préserver la confidentialité, l intégrité et l authenticité de tous les documents et pièces envoyés et produits sous forme électroniue. L accès aux systèmes automatisés de gestion et de transmission des pièces doit être restreint aux seules parties autorisées et il faut prévoir une piste de contrôle ui permette de savoir uand et par ui les pièces ont été consultées. 3.1 Exemplaire original L office récepteur transmettra au Bureau international, dans le délai prescrit en vertu du règlement d exécution du PCT, les données électroniues relatives à la nouvelle demande u il a reçue du déposant. Si le document est reçu dans un format conforme aux dispositions de l Appendice I de l Annexe F, les données chiffrées seront transmises. Si l office récepteur a accepté un dépôt dans un format différent de celui ui est prescrit aux Appendices I et II de l Annexe F, il invitera le déposant à lui envoyer à nouveau les données reçues dans un des formats acceptés, définis à l Appendice I de l Annexe F, et il enverra aussi ces données ayant fait l objet d un nouvel envoi au Bureau international. L exemplaire original se composera à la fois du document tel u il a été initialement présenté et du document présenté dans le format conforme à la norme. Les signatures électroniues sécurisées reuises, le cas échéant, pour le document ayant fait l objet d un nouvel envoi seront fournies par le déposant. Toute signature électroniue sera reproduite telle uelle dans le nouveau document. 3.2 Échange de pièces La "chaîne des dépositaires" et la trace de toutes les modifications doivent être conservées par chaue organisme dépositaire PCT ui reçoit, stocke, traite ou transmet des pièces électroniues liées à une demande internationale déposée sous forme électroniue. Il doit être possible de déterminer pour chaue modification apportée à une pièce électroniue si elle est

Annexe 5, page 7 due à une exigence de l office ou à une instruction du déposant, expressément donnée dans un document prévu à cet effet. Aux divers stades de la procédure PCT où un office récepteur, une administration ou le Bureau international doit transmettre les pièces de la procédure à un autre office récepteur, à une autre administration ou au Bureau international, il convient non seulement de transmettre les pièces électroniues, mais aussi de réaliser une copie électroniue du dossier et de l adresser au Bureau international afin de l intégrer à l exemplaire original permanent. (Cela permettra de conserver en lieu sûr une copie de sauvegarde du dossier dans l état où il se trouvait aux moments clés de la procédure). Les offices récepteurs, les administrations et le Bureau international ne sont pas tenus de transmettre des copies des pièces du dossier après chaue modification. 3.3 Intégrité de la transmission La transmission électroniue du dossier comprend à la fois la transmission des documents relatifs aux demandes internationales et celle des métadonnées concernant ces documents. Les fichiers multiples associés à un dossier et leurs métadonnées doivent être regroupés dans un fichier d archive aux fins d une transmission uniue. Une vérification de l intégrité du fichier d archive permettra de s assurer de l intégrité de la transmission. 3.4 Accusé de réception de la communication Le mécanisme d envoi devra permettre de savoir grâce à une fonction intégrée de délivrance d accusés de réception si la transmission a abouti. En outre, afin de garantir l intégrité, la confidentialité, la non-répudiation et l authenticité des pièces électroniues, le résultat de la validation initiale de ces pièces fera l objet d une déclaration expresse de l office récepteur et cette déclaration sera communiuée à l office expéditeur et inscrite dans le dossier électroniue. Dans les cas où la validation initiale ne serait pas possible, cette déclaration permettra d informer l office expéditeur de l existence d un problème. 3.5 Intégrité du stockage Tant les supports de stockage ue la méthode d enregistrement des pièces électroniues seront choisis en vue de garantir l intégrité du dossier électroniue au cours de son stockage dans tous les bureaux, offices ou administrations pendant toute la durée de vie des renseignements relatifs aux brevets. L intégrité du stockage désigne plus précisément la lisibilité permanente des renseignements au fil du temps, compte tenu de l évolution des techniues et de la dégradation des supports. Le mécanisme de stockage sera choisi afin d éviter de devoir réenregistrer ces renseignements à un moment ou un autre de leur durée utile. 3.6 Gestion des dossiers électroniues Les normes techniues sont spécifiues et précises, compte tenu du fait ue les signaux produits par les ordinateurs doivent être exactement les mêmes ue ceux ue les éuipements de réception s attendent à recevoir. Les normes juridiues, elles, traitent plutôt de la ualité ue l on souhaite obtenir, cette recherche de ualité pouvant être satisfaite par l utilisation d un certain nombre de techniues différentes. Ainsi de multiples mécanismes physiues, électriues ou de codage peuvent assurer la sécurité des pièces. Les différents offices du PCT peuvent satisfaire de diverses façons aux normes juridiues énoncées dans la présente annexe. Les variations de coût de ces méthodes selon la région du monde concernée peuvent amener tel office à choisir de protéger l authenticité des pièces u il

Annexe 5, page 8 gère en utilisant, par exemple, une IPC ou des numéros d identification personnels, alors ue tel autre optera aux mêmes fins pour des techniues très différentes. Pour permettre aux titulaires de brevets découlant de demandes internationales d établir la validité de leurs droits de propriété intellectuelle, il faut ue les pièces électroniues soient recevables devant tout tribunal de tout État partie au PCT. Tous les offices ui participent à l échange de documents électroniues doivent se conformer aux prescriptions définies dans le supplément 5 de l Appendice I. Afin de garantir ue ces prescriptions seront respectées, ou pourrait prévoir ue la gestion des dossiers électroniues mise en place par un office fasse régulièrement l objet de vérifications extérieures dont les résultats seraient publiés par le Bureau international. 3.6.1 Définition des normes en matière de gestion des pièces électroniue On trouvera ci-dessous les normes, suivies chacune d un commentaire. Le commentaire vise à aider, à donner des indications et à expliuer, mais seule la norme est obligatoire. S1. Tous les documents déposés sous forme électroniue doivent pouvoir être imprimés sur papier et transférés sur un support d archivage sans perte de contenu ni altération matérielle. S2. Les renseignements recueillis à chaue fois par les systèmes automatisés au sujet des pièces électroniues, souvent appelés métadonnées, doivent être considérés comme faisant partie desdites pièces et doivent être conservés par les systèmes automatisés. Commentaire : Selon la définition utilisée en archivistiue et selon ce ui est généralement considéré comme la meilleure pratiue dans le domaine de la gestion des pièces électroniues, un dossier complet se compose de trois éléments fondamentaux : 1) le contenu, 2) la structure et 3) le contexte. Contenu Le contenu se compose des données proprement dites résultant d une transaction réalisée dans le cours normal des affaires, comme dans le cadre d un processus de réception ou de création. Ainsi, le dépôt d une demande de brevet comporte le formulaire de demande ui contient plusieurs rubriues et une signature. Structure La structure se compose généralement de deux parties : la structure logiue et la structure physiue. La structure logiue d une pièce se compose de ses parties identifiables, telles ue le titre, le nom du déposant et celui du ou des inventeurs, la date et la signature ui figurent sur la demande de brevet. Ces parties peuvent être soit identifiables par l ordinateur, comme les métadonnées, soit identifiables par l être humain, comme lorsu elles s affichent sur un écran ou sont imprimées, soit les deux. La structure physiue a trait au format de la pièce : elle comprend la police de caractères, l espacement, les marges, le logo et le codage du fichier, ui donnent des informations pour le traitement (l affichage) ou le transfert de la pièce tout au long de la période de conservation. Contexte Le contexte donne la signification de la pièce, c est-à-dire le uoi et le pouruoi de la transaction pour lauelle la pièce a été créée ou reçue. Le contexte peut être implicite dans le contenu et la structure de la pièce, comme par exemple pour une demande de brevet ou d enregistrement de marue ui contient un numéro de formulaire ou une description et un bloc signature ui indiue la volonté précise du signataire. L une des principales conditions de la recevabilité d une preuve devant un tribunal est ue le système ui reçoit ou ui crée la pièce stocke une représentation exacte de cette pièce. Plus élevé sera le nombre d éléments de la pièce enregistrés, soit dans la pièce elle-même, soit en tant ue métadonnées, plus la pièce aura de

Annexe 5, page 9 chances d être considérée comme fiable et complète. Plus une pièce sera complète, plus elle sera fiable aux fins de recevabilité et de tout autre examen contradictoire ultérieur. Il est recommandé d enregistrer et de stocker l ensemble du contenu, de la structure et du contexte des pièces électroniues. L ensemble de la pièce électroniue devrait pouvoir être accessible et devrait pouvoir être présenté sur écran ou imprimé sans perte ni altération de contenu ou de structure pendant toute la période de conservation. Si le document électroniue a été produit d abord sur papier ou à partir d un document sur papier, il convient de conserver la présentation de la version papier, du moins dans l exemplaire archivé du document reçu. Si le document envoyé n existe ue sous la forme d une chaîne de texte, seule cette version doit être archivée. Si les renseignements reçus ne sont ue des données bibliographiues, il convient de conserver le contexte de ces données. Par exemple, si le déposant a répondu à des uestions sur un formulaire, ue ce soit sur papier ou sur une page Web, il faut au minimum saisir le libellé des uestions en regard des renseignements donnés. Ainsi, lorsue nous saisissons l information 1997 donnée par le déposant, il convient de saisir aussi au moins la uestion à lauelle cette information répond, à savoir À uelle date votre invention a-t-elle été réalisée?. L idéal serait de pouvoir recréer l écran sur leuel le déposant a dû saisir sa réponse. S3. Les documents électroniues doivent être envoyés dans un format de fichier électroniue défini par l office, et les copies d archive doivent être conservées dans le format électroniue dans leuel elles ont été envoyées. Des copies de travail des documents envoyés peuvent être établies par conversion en d autres formats. S4. Tous les dépôts électroniues doivent faire l objet d un accusé de réception adressé à l expéditeur pour indiuer ue l office a bien reçu le document. L accusé de réception doit comporter l identité de l office, la date et l heure de la réception du document (ui seront la date et l heure officielles de réception par l office), ainsi u un numéro de référence ou un numéro de demande attribué par l office, le cas échéant. Commentaire : En plus d adresser un accusé de réception du document à l expéditeur (ui donne seulement acte de la réception du document envoyé), l office peut aussi souhaiter communiuer le résultat du contrôle de l intégrité du document (par exemple sous la forme d une somme de contrôle), grâce auuel le déposant peut avoir l assurance ue le document envoyé a été reçu correctement par l office. La validation du document est facultative, mais elle est recommandée lorsue l on utilise des méthodes de signature électroniue sécurisée car la validation de document est une procédure habituelle dans le cadre de la mise en œuvre des techniues de signature numériue. L office doit faire savoir uels algorithmes de compression de documents il prend en charge. S5. Tout office ui accepte le dépôt électroniue doit aussi permettre l envoi de documents sur papier. Ces documents sur papier peuvent être scannés de façon à faciliter la création d un fichier électroniue uniue. Commentaire : Même si l envoi direct de documents électroniues est préférable pour la saisie de documents sous forme électroniue, les offices devront toujours prendre en charge des envois de documents sur papier dans le cadre d un système global de gestion de dossiers électroniues. Afin de faciliter la création de fichiers électroniues uniues, il sera nécessaire de convertir les documents présentés sur papier en fichiers électroniues. Un document sur papier peut, en règle générale, être scanné sans perte de contenu ni modifications de forme. Les spécifications techniues agréées sont énumérées à l Appendice I. Pour u il soit possible d effectuer des recherches dans le texte de documents numérisés, les images doivent être converties en texte au moyen de la reconnaissance optiue de caractère (ROC). Il convient de noter, cependant, ue la conversion d un document scanné en texte au moyen de la ROC est susceptible de produire des erreurs importantes dans le texte converti. La ROC est acceptable si l office souhaite créer un texte à usage interne dans leuel effectuer des recherches, mais non pour créer des dossiers officiels accessibles au public ou pour conserver des copies d archive. L image (ou le document original) correspondant au texte créé par ROC doit être conservée dans les archives. La création d un fichier électroniue uniue est encouragée, mais la numérisation des documents envoyés autrement ue sous une forme électroniue n est pas obligatoire. Les offices peuvent choisir de conserver

Annexe 5, page 10 (certains ou l ensemble) des documents envoyés sur papier séparément des documents présentés sous forme électroniue. S6. Un mécanisme doit être prévu afin de garantir l authenticité et l intégrité du document déposé sous forme électroniue. Cela suppose la possibilité de vérifier l identité de l expéditeur (le déposant ou son mandataire), ainsi ue la possibilité de vérifier u un document n a pas été modifié sans autorisation depuis son dépôt. S7. Tout système de dépôt électroniue doit prévoir des mécanismes de sauvegarde et de restauration pour protéger les dépôts électroniues contre ses propres défaillances. S8. Les dossiers électroniues doivent être conservés et accessibles à long terme. Commentaire : Le principe fondamental ui sous-tend la gestion des dossiers électroniues est d en prévoir l accès et la conservation à long terme, c est-à-dire sur l ensemble de leur durée de vie. Garantir l accès à long terme suppose ue chaue fichier ou pièce électroniue puisse être récupéré et se prêter à des recherches et u il puisse être affiché sur écran ou imprimé sans perte de contenu ni de structure. Les conditions de conservation exigent ue l intégrité du dossier électroniue et des pièces y relatives soit préservée sur l ensemble de la durée de vie, uelle ue soit l évolution des techniues de communication et indépendamment de l obsolescence des systèmes. Partant, les solutions choisies en matière de gestion des dossiers électroniues ne doivent pas être axées sur un support, un système ou un environnement donnés. Les pièces doivent pouvoir être exploitées au moyen des techniues les plus modernes dans l état où elles ont été installées, sans perte de contenu ni de structure. S9. L absence de virus doit être vérifiée dans tous les fichiers électroniues avant leur traitement. S10. L accès aux ordinateurs utilisés pour le dépôt électroniue ne doit pas mettre en péril la sécurité des autres réseaux et applications de l office. Commentaire : Le public ne doit pas avoir accès aux réseaux ou ordinateurs internes d un office sur lesuels celui-ci réalise ses opérations. Une façon d isoler les sites Web ui peuvent être utilisés pour le dépôt électroniue est d utiliser un pare-feu. D autres méthodes de sécurisation de réseau peuvent être associées au pare-feu afin d améliorer encore la sécurité. De même, des mesures de sécurité devraient être prises en ce ui concerne les autres applications relatives au dépôt électroniue. S11. Les systèmes de gestion des pièces électroniues doivent prévoir des mécanismes d assurance et de contrôle de la ualité des documents envoyés. Commentaire : Il incombe à l office d assurer la fiabilité des données relatives à la gestion du dossier de la demande. La façon dont un office choisit de veiller à cette fiabilité est une décision ui relève de la direction de l office en uestion. Les systèmes de dépôt électroniue devraient permettre aux offices de vérifier les documents présentés et de valider la fiabilité des données relatives à la gestion du dossier de la demande avant d accepter et d enregistrer un dépôt électroniue. Ces fonctions doivent pouvoir être prises en charge à la fois par le système de dépôt électroniue et par les autres systèmes automatisés de l office récepteur. S12. Les systèmes de gestion des dossiers électroniues doivent mettre en œuvre une piste de contrôle gardant trace de toutes les adjonctions ou modifications apportées aux pièces électroniues et y consigner les renseignements concernant la réception et la production de chaue pièce et toute modification apportée à une pièce. Commentaire : La piste de contrôle donne l historiue global du fichier ou de la pièce électroniue. Du point de vue de la gestion des dossiers et d un point de vue juridiue, elle retrace la chaîne des dépositaires en indiuant l auteur et la nature de chaue acte ou fait maruant lié à un fichier ou à une pièce électroniue, ainsi ue le moment où cet acte ou ce fait maruant a eu lieu. Par fait maruant, on peut entendre par exemple la création, la réception, le traitement, la consultation, l acheminement, la

Annexe 5, page 11 diffusion, la reproduction, le reformatage, le transfert ou la destruction d un fichier électroniue relatif à un brevet ou à une marue. D un point de vue juridiue, la piste de contrôle peut aussi être utilisée pour prouver, aux fins de recevabilité devant un tribunal, ue l authenticité d une pièce a été préservée c est-à-dire ue l intégrité du contenu, de la structure et du contexte n a pas été altérée et ue ladite pièce n a pas fait l objet d un emploi abusif et n a pas été malencontreusement détruite. S13. Si l accès à des données confidentielles par des moyens électroniues est permis, il doit être sécurisé et réservé à un public autorisé. Des mesures doivent être prises pour protéger ces fichiers contre toute altération. Lorsu un déposant, un mandataire ou des membres autorisés du public ont accès à des fichiers par des moyens électroniues, des renseignements doivent être consignés sur l identité de la partie concernée, la date (et éventuellement l heure) de la transaction et tout envoi de documents. Ces renseignements doivent rester confidentiels. S14. Dans la mesure prévue par le PCT, le public doit pouvoir avoir accès aux demandes internationales publiées conservées par les offices. Commentaire : Les fichiers publiés et les bordereaux des offices sont des dossiers publics lorsue le PCT le prévoit. Quelle ue soit la procédure de dépôt électroniue adoptée, il est recommandé de prévoir ue le public puisse avoir accès de manière adéuate à ces informations en dehors de l office. Si un office choisit de numériser les documents présentés sur papier et de les associer aux documents déposés sous forme électroniue dans un fichier électroniue uniue, le public doit pouvoir disposer d un accès électroniue à tous les documents ui se trouvent dans le fichier électroniue, u ils aient ou non été envoyés à l origine sous forme électroniue. La présente norme n a cependant pas pour objet d exiger la conversion généralisée de tous les dépôts non électroniues si l office décide de ne pas conserver de fichiers électroniues uniues pour tous les dépôts u il gère. 4 Options pour les offices récepteurs 4.1 Contexte Selon le projet de révision envisagé, les Instructions administratives du PCT comporteront une instruction 701.c) prévoyant ce ui suit : chaue office récepteur notifie au Bureau international i) la ou les formes électroniues et les moyens électroniues acceptables pour le dépôt des demandes internationales u il accepte; ii) les conditions u il exige pour le dépôt électroniue et les méthodes électroniues de communication u il accepte; iii) les conditions, règles et procédures applicables à la réception électroniue, y compris les heures de fonctionnement, les options en ce ui concerne les accusés de réception et les procédures standard d accusé de réception électroniue, les modalités d assistance, les moyens électroniues et les logiciels reuis et d autres uestions administratives portant sur le dépôt électroniue de demandes internationales et de documents y relatifs; iv) tout changement apporté à la ou aux formes électroniue(s) acceptée(s) mentionnée(s) au sous-alinéa i) la date d effet d une modification apportée à une forme électroniue acceptée par un office récepteur est fixée à deux mois à compter de la date à lauelle la notification de cette modification est publiée dans la gazette; v) les procédures u il est recommandé au déposant de suivre lorsu une autre solution ue le dépôt électroniue doit être adoptée si les systèmes électroniues de l office récepteur sont indisponibles pour cause de dysfonctionnement ou d opérations de

Annexe 5, page 12 maintenance programmées en de tels cas d indisponibilité, l office récepteur prend toutes les mesures raisonnables pour informer les déposants. 4.2 Catégories d options (en vertu du projet d instruction 701.c)) : Il y a deux catégories de renseignements ue l office récepteur est tenu de notifier au Bureau international : i) le choix de l office récepteur parmi les diverses options (limitées) concernant certaines uestions; et ii) la simple notification concernant d autres uestions d information. En vertu de l instruction 701.c), les offices récepteurs n auront à leur disposition ue les options suivantes, parmi lesuelles ils sont tenus de choisir : 1--la ou les formes électroniues et les moyens électroniues acceptables par l office récepteur aux fins du dépôt de demandes internationales : Formes électroniues (c est-à-dire la forme matérielle du support contenant les données électroniues) a) fichier électroniue (les formats à utiliser pour les fichiers sont indiués à l Appendice I de l Annexe F) b) sur support physiue [Les formats à utiliser pour les fichiers sont définis à l Appendice III) i) disuette de 3,5 pouces, de préférence produite avec PCT-EASY (l entièreté de la demande sous forme électroniue) ii) CD-ROM ou CD-R/DVD-ROM ou DVD-R iii) disuette à haute densité (par exemple IOMEGA Zip, Super disk, etc.)] Moyens électroniues (c est-à-dire les méthodes d envoi ou de transmission) a) Transfert de fichiers électroniues (les mécanismes à utiliser sont indiués à l Appendice I de l Annexe F) [b) Internet, par l intermédiaire d un navigateur (avec ou sans chiffrement) c) courrier électroniue i) la demande proprement dite figurant dans le message ii) la demande proprement dite sous forme de pièces jointes (dans un des formats acceptés)] 2--les conditions exigées par l office récepteur pour le dépôt électroniue et méthodes électroniues de communications acceptées par l office récepteur; a) mode de communication pratiué par l office récepteur-- i) envoi direct des avis et documents au déposant par l office récepteur/l administration, à l adresse électroniue fournie [ii) système de la boîte aux lettres : le déposant doit ouvrir une session dans le système géré par l administration pour obtenir les messages et notifications ui lui sont destinés]

Annexe 5, page 13 3--les conditions, règles et procédures applicables à la réception électroniue, y compris les heures de fonctionnement, les options en ce ui concerne les accusés de réception et les procédures standard d accusé de réception électroniue, les modalités d assistance, les moyens électroniues et les logiciels reuis et d autres uestions administratives portant sur le dépôt électroniue de demandes internationales et de documents y relatifs; a) En lieu et place du mécanisme d accusé de réception par défaut du Certificat de confirmation, type d accusé de réception des demandes présentées sous forme électroniue u un office récepteur peut délivrer sur demande à un déposant :-- i) électroniue (par exemple un avis envoyé par l office récepteur à l adresse électroniue fournie [ou à une boîte aux lettres électroniue interne]) ii) sur papier (courrier électroniue, télécopie, etc.) b) horaires : i) ouvert 24h/24 aux fins du dépôt électroniue? ii) horaires restreints? 4--les procédures [recommandées] [, le cas échéant,] ue les déposants doivent suivre lorsu une autre solution ue le dépôt électroniue doit être adoptée si les systèmes électroniues de l office sont indisponibles pour cause de dysfonctionnement ou d opérations de maintenance programmées en de tels cas d indisponibilité, l office récepteur [est tenu de] [devrait] prendre toutes les mesures raisonnables pour informer les déposants. a) Pour les événements ue l on peut raisonnablement prévoir, la description des mécanismes mis en place aux fins du respect de la norme S7 de gestion des dossiers électroniues (ERM Standard S7) i) Page d accueil de l office récepteur sur l Internet ii) Adresse électroniue iii) Télécopieur [L appendice I suit]

Annexe 5, page 14 APPENDICE I NORME TECHNIQUE TRILATÉRALE POUR L ÉCHANGE EN LIGNE DE DOCUMENTS DE PROPRIÉTÉ INTELLECTUELLE DANS UN ENVIRONNEMENT ICP 1 GÉNÉRALITÉS... 15 2 PORTÉE... 15 3 SÉCURITÉ... 15 3.1 INFRASTRUCTURE À CLÉ PUBLIQUE...16 3.2 CERTIFICATS...... 17 3.3 AUTORITÉS DE CERTIFICATION... 18 3.4 ADMINISTRATION DE LA CERTIFICATION... 18 3.5 CERTIFICATION CROISÉE... 21 3.6 SIGNATURES NUMÉRIQUES... 22 3.7 SERVICES D ANNUAIRE... 22 3.8 ALGORITHMES DE CHIFFREMENT... 22 3.9 CHIFFREMENT DE DONNÉES... 22 3.10 DES ALGORITHMES À SENS UNIQUE POUR UN COMPACTAGE DE HAUTE SÉCURITÉ... 23 3.11 MÉCANISMES DE SÉCURITÉ ET DE PAIEMENT... 23 3.12 RÉCAPITULATIF DES MÉCANISMES DE SÉCURITÉ... 23 4 MÉCANISMES DE SIGNATURE... 23 4.1 SIGNATURE ÉLECTRONIQUE SIMPLE... 24 4.2 SIGNATURE ÉLECTRONIQUE À SÉCURITÉ RENFORCÉE... 24 5 ASSEMBLAGE DES DOCUMENTS... 24 5.1 PRÉPARATION DES DOCUMENTS... 24 5.2 COMPACTAGE DES DOCUMENTS... 25 5.3 SIGNATURE DES DOCUMENTS COMPACTÉS... 25 5.4 ASSEMBLAGE DES DOCUMENTS COMPACTÉS ET SIGNÉS... 26 6 ENVOI... 27 6.1 PROTOCOLE DE TRANSMISSION... 28 7 TYPES D ÉCHANGE DE DOCUMENTS... 29 8 MISE EN ŒUVRE DES RENVOIS... 29 SUPPLÉMENT 1. PRESCRIPTIONS RELATIVES AU FORMAT DES DOCUMENTS... 30 SUPPLÉMENT 2. SPÉCIFICATION DE COMPACTAGE (WRAPPING) (SDIF VERSION 2)... 32 SUPPLÉMENT 3 FORMATS D ENVELOPPE PKCS#7... 34 SUPPLÉMENT 4. MÉCANISME DU TICKET... 39 SUPPLÉMENT 5. AIDE-MÉMOIRE DES CONDITIONS À RESPECTER AUX FINS DE LA GESTION DES PIÈCES ÉLECTRONIQUES... 45 SUPPLÉMENT 6. SIGLES... 88 n:\orgipis\shared\williams\scit\projects\p8\an5f_ap1.doc

Annexe 5, page 15 1 Généralités Ce document expose les exigences techniues du dépôt en ligne dans un environnement d infrastructures à clé publiue (environnement ICP). Il s agit d une norme ui devrait à terme s appliuer à tous les types d échange de documents de propriété intellectuelle, dont ceux ui s inscrivent dans la procédure PCT mais aussi dans des procédures autres ue celles des brevets, notamment l enregistrement de marues. Lorsu une partie de texte figure entre crochets [], cela signale une exigence dont l incorporation ultérieure à la norme est recommandée. La présente norme énonce l ensemble maximum de mesures u un office de propriété intellectuelle peut exiger d un déposant. Les offices de la coopération trilatérale l ont adoptée pour expérimentation du dépôt en ligne et pour leurs tests d interopérabilité. 2 Portée La présente spécification permet l utilisation pour tous les types de documents de propriété intellectuelle (brevets, marues, modèles d utilité, etc.) des mêmes mécanismes de communication électroniue entre les déposants, les offices récepteurs, les administrations et le Bureau international, tant pour les procédures selon le PCT ue pour les procédures nationales. La mise en œuvre techniue, pour les différents types d échange, repose sur les éléments suivants : Sécurité et ICP Signatures électroniues Assemblage de documents Envoi 3 Sécurité Cette partie traite des exigences concernant 1. la sécurité des documents électroniues ui sont transmis via des réseaux de communication dans le cadre de transactions électroniues menées avec les offices de propriété intellectuelle, et 2. la sécurité des documents électroniues détenus par les offices de propriété intellectuelle compte tenu des pratiues de gestion des dossiers électroniues. Sont en particulier traités les mécanismes nécessaires pour protéger de l intrusion les systèmes informatiues des offices de propriété intellectuelle. Une fois les exigences identifiées, cette partie précise les normes techniues à appliuer pour la mise en œuvre de systèmes destinés à les satisfaire. L impératif de sécurité dans l échange et le stockage de documents électroniues de propriété intellectuelle découle des traités et des lois ui prévoient la protection du contenu de ces documents contre toute divulgation intempestive, et de la nécessité d asseoir la validité, la recevabilité et le poids des documents électroniues de propriété intellectuelle dans les procédures légales. Dans cette optiue, les systèmes d automatisation des offices de propriété

Annexe 5, page 16 intellectuelle et de dépôt électroniue doivent préserver de manière fiable la confidentialité et l intégrité des documents électroniues de propriété intellectuelle; ils doivent en outre comporter des dispositifs permettant d identifier l expéditeur et de vérifier la non-répudiation. On trouvera ci-après une définition succincte de ces éléments. 3.1 Infrastructure à clé publiue Les techniues de cryptographie à clé publiue fondent pour l essentiel les méthodes acceptées et les standards ui se sont imposés pour assurer les ualités recherchées dans le commerce électroniue par l Internet. Dans la cryptographie à clé publiue, on crée des paires de clés. Ces paires de clés ont la propriété ue chaue clé d une paire peut être utilisée pour déchiffrer des données ue l on a chiffrées en utilisant l autre clé. Les utilisateurs d un système cryptographiue à clé publiue rendent publiue l une des clés de leur paire (c est la clé publiue) et gardent l autre secrète (c est la clé privée). La cryptographie à clé publiue est complétée par l utilisation de fonctions de hachage à sens uniue, d un haut niveau de sécurité, pour établir l intégrité des documents électroniues. Les deux technologies sont employées pour créer des signatures numériues. Pour la fabrication d une signature numériue, on passe le message par une fonction de hachage à sens uniue offrant un niveau élevé de sécurité et le résultat, appelé empreinte du message, est chiffré au moyen de la clé privée. Des certificats numériues ont été conçus pour lier l identité d une partie et sa clé publiue. Un certificat numériue est un message compact ui comporte l identité de son titulaire, la clé publiue du titulaire et un moyen de vérification indépendante de la fiabilité du certificat. Un certificat numériue peut être délivré soit par l une des parties à la transaction de commerce électroniue après vérification de l identité de l autre partie, soit par un tiers de confiance. Dans le cas d un tiers, les deux parties à la transaction s en remettent aux politiues et aux pratiues utilisées par ce tiers pour établir une identité. Enfin, un certificat numériue doit pouvoir être annulé lorsu il n est plus valable, sans uoi il ne serait d aucune utilité. Peuvent notamment entraîner l annulation d un certificat les circonstances suivantes : compromission de la clé privée associée à la clé publiue figurant sur le certificat, modification de l adresse ou d autres éléments d identité, découverte d une erreur dans le certificat, changement d affiliation (d employeur par exemple) du titulaire ou dépassement de la date d expiration du certificat. Assurer une complète sécurité à grande échelle exige une multiplicité de certificats numériues. Un organisme tel u un office de propriété intellectuelle ui désire mener avec ses clients sur l Internet des transactions de commerce électroniue bidirectionnelles protégées par des dispositifs de confidentialité, d intégrité, d authentification et de non-répudiation doit pouvoir reconnaître un certificat numériue pour chacun de ses clients. Les politiues et les procédures, plus la suite de systèmes et de logiciels ue supposent la délivrance, l annulation, la recherche et la gestion de certificats numériues en nombres importants constituent ce ue l on appelle une infrastructure à clé publiue (ICP).

Annexe 5, page 17 Éléments d une ICP Autorité d enregistrement (RA) Autorité de certification (CA) Administration des certificats Service d annuaire Énoncé des politiues et des pratiues de certification dialogue avec les parties ui demandent un certificat pour établir leur identité délivre des certificats sur la base des demandes u elle reçoit de la RA gère les renouvellements de certificat et les annulations à expiration ou pour autre motif, diffuse une liste d annulation (CRL), valide les certificats, valide les signatures numériues, fournit l interface utilisateur (API) pour les applications logicielles tient à jour la base de données des certificats et recherche les certificats pour les utilisateurs consigne par écrit les pratiues opérationnelles et les règles de fonctionnement de l ICP 3.2 Certificats Tout certificat numériue utilisé pour l échange de documents de propriété intellectuelle doit suivre la recommandation X.509 de l Union internationale des télécommunications (UIT), version 3, en ce ui concerne le format des certificats. Voir la Recommandation X.509 (08/97) intitulée Technologies de l information Interconnexion des systèmes ouverts L annuaire : Cadre d authentification. Les demandes de certificat numériue doivent être établies conformément à la norme PKCS #10. Voir : RSA Laboratories, PKCS #10 Certification Reuest Syntax Standard Ver. 1 (norme de syntaxe pour les demandes de certificat, version 1) Un certificat peut être délivré sous les formes suivantes : Sur carte à microprocesseur Sur disuette En ligne On utilisera pour l interfonctionnement de systèmes dotés d une infrastructure à clé publiue (ICP) des certificats établis selon la version 3 de la recommandation X.509 et des listes d annulation (CRL) établies selon la version 2 de la recommandation X.509. La mise en œuvre de systèmes ICP s effectuera conformément aux recommandations établies par le groupe de travail sur l interopérabilité des infrastructures à clé publiue (PKIX) de l Internet Engineering Task Force (IETF), exposées dans l appel à commentaires RFC 2459 de l IETF. Des projets de spécifications sont proposés par l Institut d informatiue de l Université de Californie du Sud à l adresse ftp://ftp.isi.edu/internet-drafts/. Voir les documents suivants :

Annexe 5, page 18 Nom du fichier de projet Internet draft-ietf-pkix-ipki3cmp draft-ietf-pkix-crmf draft-ietf-pkix-ipki-part4 draft-ietf-pkix-ipki-part1 draft-ietf-pkix-ldapv2-schema Titre de la spécification Infrastructure à clé publiue X.509 pour l Internet Protocoles de gestion de certificats Format du message de demande de certificat Infrastructure à clé publiue X.509 pour l Internet Cadre de politiue et de pratiues de certification Infrastructure à clé publiue X.509 pour l Internet Profil du certificat et de la liste d annulation (CRL) Infrastructure à clé publiue X.509 pour l Internet Schéma LDAP version 2 Dans la pratiue, on utilisera des paires de clés et des certificats numériues distincts aux fins d authentification et de confidentialité. Les clés d authentification seront la propriété du client de l office de propriété intellectuelle, et la clé privée de la paire de clés d authentification ne devra jamais uitter la garde de ce client. Un office de propriété intellectuelle peut décider d offrir un service de récupération de clés pour la paire de clés de sécurité lorsue la législation nationale le permet. 3.3 Autorités de certification Les autorités de certification (CA) sont chargées de veiller à l exactitude des certificats électroniues ui prouvent u une partie est bien ui elle prétend être. Elles peuvent être nombreuses. Les certificats seront délivrés sur décision de chaue autorité de certification conformément à la loi nationale. [Le Bureau international tient une liste d autorités de certification pour la communauté internationale de la propriété intellectuelle. Les offices choisissent sur cette liste les autorités dont ils accepteront les validations de certificats. Le Bureau international peut aussi agir en ualité de CA.] Chaue office de propriété intellectuelle s abonnera aux listes d annulation (CRL) correspondant à toutes les autorités de certification u il accepte. Chaue fois u un certificat sera utilisé aux fins d identification, l office de propriété intellectuelle consultera ces listes d annulation pour s assurer ue le certificat n a pas été annulé. 3.4 Administration de la certification Le processus de délivrance, de gestion et d annulation des certificats se décompose en huit parties, ui constituent ce ue l on peut appeler le cycle de vie du certificat. Les grandes étapes en sont les suivantes : Demande de certificat Validation de la demande de certificat Création, émission et distribution des certificats Acceptation du certificat par l abonné Utilisation du certificat

Expiration et renouvellement du certificat Annulation du certificat Récupération de clés. SCIT/P 8/99 Rev.1 Annexe 5, page 19 À chacun de ces processus correspond un ensemble de politiues et de procédures à suivre, ui sont garantes de la fiabilité de l environnement assuré grâce à l ICP. Les trois premières phases visent à s assurer ue le certificat est bien délivré à la bonne personne. Les uatrième et cinuième phases concernent l utilisation ui est faite du certificat par le titulaire de celui-ci (appelé abonné). Les trois dernières phases concernent la fin du cycle de vie du certificat, lorsue celui-ci vient à expiration naturellement, à moins u il ne soit annulé et remplacé par un nouveau certificat. 3.4.1 Demande de certificat C est par cette phase ue s engage la communication entre l abonné et l autorité de certification et donc ue débute le cycle de vie du certificat. Le personnel d un office de propriété intellectuelle n a pas à remplir de demande de certificat. Le statut d employé constituera en effet la preuve reuise de l identité de la personne et la dispensera d avoir besoin d un tel certificat. Toute autre personne devrait normalement remplir et soumettre une demande de certificat donnant des informations détaillées, dont le nom de l abonné, l organisation et le type de certificat. La forme écrite pourra être exigée dans un premier temps; toutefois, les améliorations ui seront apportées dans l avenir aux infrastructures à clé publiue permettront la formulation de demandes de certificat en ligne. Tout demandeur extérieur sera tenu de remplir un agrément d abonné énonçant ses obligations en ce ui concerne l utilisation du certificat ui lui est délivré. 3.4.2 Validation de la demande de certificat L autorité d enregistrement (RA) est chargée d authentifier l identité du souscripteur du certificat et de confirmer l exactitude de l information communiuée, y compris en ce ui concerne la nécessité du certificat. Après validation de l information contenue dans les demandes de certificat, l autorité d enregistrement autorise la création de certificats par l autorité de certification (CA) pour l abonné. L autorité de certification valide l autorisation émanant de l autorité d enregistrement, ceci afin d assurer ue l autorisation a été émise par une autorité d enregistrement habilitée et u elle contient toutes les informations reuises. L autorité de certification fournit alors à l abonné les informations nécessaires à l aboutissement du processus de délivrance du certificat. La fonction consistant à établir la preuve de l identité peut être déléguée à une autorité locale d enregistrement à vocation administrative ou commerciale. La validation du certificat est étroitement liée à la demande de certificat. 3.4.3 Création, émission et distribution des certificats L abonné utilise le logiciel client ICP pour accomplir une série d étapes dont l aboutissement est la création de paires de clés et la production, l émission et la distribution de certificats de clé publiue. Deux paires de clés (soit uatre clés) sont créées dans ce processus : une paire de clés de chiffrement et une paire de clés de signature. La paire de clés de chiffrement se compose de la clé publiue (pour le chiffrement) et de la clé privée (pour le déchiffrement). Une fois créée, la clé publiue de chiffrement est automatiuement envoyée à la plate-forme de l autorité de certification, où elle est inscrite sur un certificat de clé publiue et signée par l autorité de certification. La paire de clés de signature se compose d une clé privée (pour la signature) et d une clé publiue (pour la vérification). La clé publiue de vérification est automatiuement envoyée à l autorité de certification, où elle est inscrite sur un certificat de clé publiue et signée par l autorité de certification. S il est prévu un système de récupération de clés, une copie de la clé privée de déchiffrement y est conservée pour pouvoir être utilisée en cas d indisponibilité de l original de cette clé. L autorité de certification envoie le certificat de clé

Annexe 5, page 20 publiue de chiffrement au service d annuaire (dépositaire de certificats) approprié et retourne le certificat de clé publiue de vérification au logiciel client ICP de l abonné. 3.4.4 Acceptation du certificat par l abonné L abonné extérieur peut indiuer son acceptation de certificat par différents moyens, notamment en donnant son accord par écrit, en utilisant le certificat pour envoyer un message signé à l autorité d enregistrement pour accuser réception du certificat, ou encore en utilisant le certificat pour établir une session de communication cryptée. 3.4.5 Utilisation du certificat L abonné va chiffrer les objets (fichiers, formulaires, documents, messages électroniues, etc.) pour le destinataire prévu en utilisant la clé publiue de chiffrement du destinataire, obtenue d après le certificat de clé publiue de chiffrement de celui-ci; seul le destinataire prévu peut déchiffrer l objet, au moyen de sa clé privée de déchiffrement. L abonné signe numériuement les objets au moyen de sa clé privée. Les parties intéressées, ui doivent être en confiance, peuvent vérifier la signature d un abonné et l intégrité de l objet signé en obtenant la clé publiue de vérification du signataire ui figure sur le certificat de clé publiue de vérification de celui-ci, leuel est fourni avec l objet signé, et en l utilisant pour vérifier la signature numériue. Dans l un et l autre cas, c est le logiciel client ICP de la partie en uête de certitude ui obtient le certificat de clé publiue et la liste d annulation en cours. Le logiciel client CP vérifie alors la signature de l autorité de certification sur le certificat et s assure, en consultant la liste d annulation, ue le certificat n a pas été annulé; pour contrôler une signature numériue, il s assure en outre ue le certificat de vérification de signature était valide au moment où la signature numériue a été exécutée. Pour effectuer ces opérations, l utilisateur n a u à choisir une option en cliuant sur une icône ou dans un menu déroulant. Ce processus sera automatisé. 3.4.6 Expiration et renouvellement du certificat Chaue certificat a une durée de vie déterminée, à l issue de lauelle il vient à expiration et doit être renouvelé. Cette durée limitée a pour but d éviter la vulnérabilité aux attaues : uelu un ui disposerait d un grand nombre de messages signés ou chiffrés au moyen de la même clé pourrait en effet chercher à casser cette clé, ce ui demande du temps. Normalement, un certificat d abonné interne sera automatiuement renouvelé avant expiration, avec production de nouvelles paires de clés et délivrance d un nouveau certificat. Un abonné extérieur pourra, lui, être tenu de demander le renouvellement. Le logiciel de l abonné extérieur notifie à l utilisateur final l imminence de l expiration. Lors de la mise à jour d une paire de clés, celle-ci est remplacée par une nouvelle paire de clés et un nouveau certificat de clé publiue est créé. Si un certificat d abonné doit être mis à jour pour tout motif autre ue son expiration en temps normal, l intervention de l abonné et celle de l autorité d enregistrement seront nécessaires. Des modifications à apporter aux données d identification de l abonné, une politiue exigeant confirmation périodiue des renseignements concernant l abonné, ou une suspicion d usage abusif ou de compromission de clé pourront notamment motiver une mise à jour. 3.4.7 Annulation du certificat Un certificat d abonné peut être annulé pour plusieurs motifs. La procédure d annulation du certificat peut être engagée par l abonné, par l autorité d enregistrement ou l autorité locale d enregistrement, ou par la direction de l office de propriété intellectuelle habilité. Tout abonné doit aviser l autorité d enregistrement ou autorité locale d enregistrement compétente des circonstances suivantes : 1) il n a plus besoin du certificat (par exemple en cas de cessation

Annexe 5, page 21 d emploi ou de changement de fonctions), 2) il a appris ou il suspecte une compromission de sa clé privée, ou 3) il a changé de nom. En l absence de demande formulée par l abonné, l autorité d enregistrement ou autorité locale d enregistrement compétente est tenue de demander l annulation d un certificat d abonné pour l un ou l autre des motifs ci-dessus. L autorité d enregistrement ou autorité locale d enregistrement compétente doit aussi engager la procédure d annulation d un certificat d abonné en cas de violation substantielle de l agrément d abonné. 3.4.8 Récupération de clés Un abonné doit pouvoir récupérer des données u il a chiffrées ou ui ont été chiffrées pour lui même en cas d indisponibilité de sa clé privée de déchiffrement. Cette clé peut être indisponible pour une multiplicité de raisons : incapacité d accéder à la clé mise en mémoire (oubli du mot de passe, etc.), corruption de la clé mise en mémoire, défaillance du support de mémoire ou encore vol de la clé ou du support de mémoire. Une organisation doit pouvoir récupérer ses données ui ont été chiffrées par un abonné lorsue celui-ci ne peut pas ou ne veut pas déchiffrer les données en uestion (par mauvaise volonté, incapacité, indisponibilité, etc...). L infrastructure à clé publiue d un office de propriété intellectuelle pourra permettre la récupération des clés de déchiffrement des abonnés internes et externes. Il faudra pour cela obtenir et garder dans une mémoire sécurisée une copie des clés privées de déchiffrement de chaue utilisateur afin de permettre la récupération licite de données chiffrées. La récupération de clés ne s appliue pas aux clés de signature de l abonné. Les clés de signature privées de l abonné ne sont pas récupérables étant donné u il faut une certitude de non-répudiation. Le mécanisme ui la garantit est le suivant : l abonné produit sa paire de clés de signature sur son propre système et transmet uniuement sa clé publiue de vérification à l autorité de certification lors de la procédure d enregistrement. La clé de signature privée doit rester sous le contrôle exclusif de l abonné pour u il n y ait aucune possibilité d usurpation d identité. Les considérations ui suivent concernent donc uniuement la récupération de clés de chiffrement. Il s agit d une fonction hautement sensible de l infrastructure à clé publiue, puisu elle touche au caractère confidentiel des communications et des fichiers, ui, dans une procédure de demande de brevet par exemple, peut être garanti par la loi. La récupération de clés pour les abonnés extérieurs peut exclusivement être engagée par l abonné lui-même, une autorité d enregistrement ou une autorité locale d enregistrement, selon des procédures établies pour la récupération de clés et en concertation avec l autorité d enregistrement. En ce ui concerne les abonnés internes, une autorité d enregistrement ou autorité locale d enregistrement n engagera la récupération de clés u après autorisation de la direction de l office de propriété intellectuelle habilité. Cette autorisation pourra résulter soit d une demande formulée par l abonné interne, soit d un besoin de la direction d accéder à des données chiffrées par l abonné. 3.5 Certification croisée Les offices de la coopération trilatérale ont indiué u ils maintiendront leurs propres autorités de certification. Il y aura donc probablement plusieurs maîtres-certificats en usage pour l échange de documents de propriété intellectuelle. La méthode de la certification croisée permet de réduire considérablement la nécessité de distribuer des maîtres-certificats dans l ensemble du système, ce ui aboutit à en simplifier la gestion.

Annexe 5, page 22 Lorsue deux communautés d utilisateurs ont chacune une autorité de certification, un processus dit de certification croisée peut être employé de façon à ce ue les utilisateurs d une communauté puissent se fier au certificat de clé publiue des utilisateurs de l autre communauté, et vice-versa. Pour ce faire, chacune des deux autorités de certification émet un certificat pour la clé publiue de l autre. Le logiciel client ICP de l utilisateur peut traiter ces certificats pour déterminer la fiabilité du certificat de clé publiue d un utilisateur d une autre communauté. Il est important de s assurer ue les politiues de certification de chaue communauté d utilisateurs sont d un niveau de fiabilité éuivalent. Les doutes ou les problèmes liés à l acceptation mutuelle des politiues entre offices vont constituer un plus grand défi à relever ue les uestions techniues concernant la fourniture de certificats croisés. Pour le moment, jusu à ce u une politiue de certification type puisse être acceptée par les différents offices de propriété intellectuelle, la certification croisée s effectuera au cas par cas, après examen jugé satisfaisant de la politiue de certification de chaue partie par l autre. En outre, l office pourra demander à une tierce autorité de certification, ui reste pour l instant à déterminer, d attester le respect des procédures décrites, ui auront été rendues publiues; cette attestation elle aussi serait rendue publiue. 3.6 Signatures numériues Les signatures numériues utilisées pour signer des documents électroniues aux fins de l échange de documents de propriété intellectuelle devront respecter le format et la pratiue spécifiées dans la norme PKCS #7 de RSA Laboratories relative à la syntaxe du message cryptographiue, intitulée Cryptographic Message Syntax Standard, version 1.5, en ce ui concerne la définition du contenu du type Signed Data (données signées). La construction de ces signatures nécessite un certificat. Il s agit d un certificat selon la norme X.509 version 3, signé par une autorité de certification (CA) agréée. 3.7 Services d annuaire Tous les offices participant à l échange électroniue de documents doivent s abonner aux CRL (listes d annulation) décrites ci-dessus et doivent les utiliser lors du décodage d un pauet PKCS#7. Les systèmes ICP devront stocker les informations du certificat dans une structure d annuaire conforme à la recommandation X.500 de l UIT. Ces systèmes comprendront, pour la publication et l extraction de certificats numériues d utilisateurs, une interface externe conforme au protocole simplifié d accès à l annuaire Lightweight Directory Access Protocol (LDAP). Voir l appel à commentaire RFC 1777 (mars 1995) du Groupe de travail de l ITEF sur les réseaux. 3.8 Algorithmes de chiffrement En fonction des besoins, on pourra utiliser aussi bien des algorithmes symétriues (à clé secrète) ue des algorithmes asymétriues (à clé publiue). Un algorithme ui serait interdit en vertu de la loi nationale d un pays ne pourra pas être utilisé pour l échange de documents de propriété intellectuelle provenant de ce pays. Les algorithmes mis en œuvre dans un matériel ou un logiciel ne devront pas être employés d une manière contraire aux restrictions à l exportation imposées par le pays d origine pour les matériels ou les logiciels considérés. Tout algorithme employé entre offices de propriété intellectuelle devra être communiué aux deux parties. 3.9 Chiffrement de données Les données d un document électroniue ui font l objet d un chiffrement destiné à en assurer la confidentialité aux fins de l échange de documents de propriété intellectuelle devront

Annexe 5, page 23 respecter le format et la pratiue spécifiés dans la partie consacrée à la définition du contenu du type Signed and Enveloped Data (données signées et enveloppées) figurant dans la version 1.5 de la norme PKCS #7 de RSA Laboratories relative à la syntaxe du message cryptographiue. 3.10 Des algorithmes à sens uniue pour un compactage de haute sécurité À la chaîne de caractères du message est appliué un algorithme de compression à haut niveau de sécurité ui crée une empreinte du message. On utilisera à cet effet l algorithme de hachage à sens uniue SHA-1. 3.11 Mécanismes de sécurité et de paiement La sécurité u offre le système ICP en ce ui concerne la confidentialité des données doit aussi être jugée suffisante pour protéger la confidentialité des informations relatives aux cartes de crédit ui sont transmises en ligne pour le paiement de taxes ou autres frais. 3.12 Récapitulatif des mécanismes de sécurité Le tableau ci-après montre comment, dans un environnement ICP, différents composants techniues prennent en charge la confidentialité, l intégrité, l authenticité et la non-répudiation : Confidentialité Intégrité Authenticité Nonrépudiation Autorité de certification X X Certificats numériues X X X Administration de la certification X X X Certification croisée X X X Type données signées PKCS#7 X X X Services d annuaire X X Algorithmes de chiffrement X Type données signées et enveloppées PKCS#7 X Algorithme de compression (empreinte du message) X Énoncés de politiues ICP X X X 4 Mécanismes de signature La fonction d une signature dans le monde électroniue consiste à identifier une personne donnée comme étant la source d un message électroniue. Elle indiue aussi l approbation par cette personne de l information contenue dans le message électroniue. Aux fins du présent document, il existe deux mécanismes de signature : La signature électroniue simple La signature électroniue à sécurité renforcée Cette signature, ui se compose du nom complet du signataire ainsi ue des lieu et date de signature, est incorporée au document sous forme de données balisées XML (voir l appendice II pour les DTD en XML). Les données balisées XML indiuent, selon le cas, si l utilisateur

Annexe 5, page 24 souhaite appliuer au message électroniue sa signature électroniue à sécurité renforcée ou sa signature électroniue simple. 4.1 Signature électroniue simple Pour indiuer l intention humaine d accomplir une action donnée, la norme comporte les spécifications d une signature électroniue simple. Cette signature peut revêtir l une des formes suivantes : une chaîne de caractères particulière entrée par l utilisateur une image reproduisant en fac-similé la signature manuscrite La signature électroniue simple est encodée dans la structure Correspondant du document XML comme indiué ci-après : <!ELEMENT electronic-signature (date-signed, place-signed, ((signature-mark,signature-file?) (signature-file,signature-mark?) use-digital-signature)) > Une signature électroniue simple dans un document XML peut être complétée par l adjonction aux documents enveloppés d une signature numériue du mandataire du signataire. 4.2 Signature électroniue à sécurité renforcée Il s agit d un type données signées PKCS#7, produit à partir du message électroniue par l action du signataire ui utilise sa clé d authentification privée pour chiffrer l empreinte du message (signature numériue). Le type données signées PKCS#7 comporte une copie du certificat numériue délivré au signataire par une autorité de certification reconnue. 5 Assemblage des documents On utilise le mécanisme d assemblage de documents pour combiner en un seul et même objet binaire à la fois les renseignements sur ce ui est transmis et le contenu de la transmission; on appliue ensuite les signatures numériues et le chiffrement appropriés. 5.1 Préparation des documents Dans chaue échange de documents de propriété intellectuelle, il y a un document principal XML, ui peut renvoyer expressément à d autres documents, le cas échéant par des liens hypertexte. Ces documents forment un tout logiue avec le document principal auuel ils sont incorporés par renvoi (nouvelle demande de brevet par exemple). En outre, un échange de documents peut inclure d autres pièces jointes (désignation de l inventeur, paiement de taxes, etc.). Le document principal XML doit se conformer à l une des DTD spécifiées dans l appendice II. Les documents auxuels il renvoie (entités externes) sont généralement des images incrustées, des tableaux, des dessins ou d autres documents composés; ils peuvent être codés en XML, PDF, TIFF ou JPEG. Voir le supplément 1 pour plus de précisions.

Annexe 5, page 25 Les pièces jointes sont des documents distincts, mais en rapport, ui peuvent être codés en XML, PDF ou format image. Voir le supplément 1 pour plus de précisions. Document principal XML Documents auxuels renvoie le document principal XML XML,PDF TIFF,JPEG Autres pièces jointes XML,PDF TIFF,JPEG 5.2 Compactage des documents Le document principal, les documents auxuels il renvoie expressément et les autres pièces jointes, le cas échéant, sont compactés un seul bloc de données. Ce bloc de données, dit documents compactés, est créé par application du standard de compression ZIP. Le déposant doit utiliser un logiciel d archivage et de compression en format ZIP pour grouper les fichiers des documents ui constituent la demande électroniue. Le logiciel employé pour créer le fichier ZIP doit être conforme aux spécifications du format ZIP, publiées dans le descriptif du logiciel PKZIP de PKWARE. Les offices nationaux, l OMPI et tout tiers ui commercialise ou met en œuvre un logiciel de dépôt sont tenus de vérifier ue tout logiciel ZIP employé correspond à ce standard. Le supplément 2 décrit les spécifications ZIP de manière détaillée. Document principal Documents auxuels renvoie le document principal Autres pièces jointes Compactage Doc princ. Ref. PJ Documents compactés ZIP Voir le supplément 1 pour toute précision concernant les types de format de documents autorisés. 5.3 Signature des documents compactés Afin de lier l expéditeur du pauet aux documents électroniues compactés, une signature numériue est ajoutée pour créer l article documents compactés et signés. L adjonction de cette signature a pour objet d identifier le déposant et de permettre au destinataire de détecter toute altération non autorisée en cours de transmission. Les spécifications PKCS#7 sont appliuées pour la production d un type données signées pour la signature. Des informations plus détaillées sur les spécifications PKCS#7 figurent dans le supplément 3.

Annexe 5, page 26 Doc. demande Ref. Ref. PJ type données signées PKCS#7 Documents compactés Signature X.509 Documents compactés et signés 5.4 Assemblage des documents compactés et signés Le lot de données ui est effectivement transmis dans l échange entre le déposant et l office récepteur est appelé pauet. Le pauet contient plusieurs articles, variables selon le type de pauet. On y trouve : Un objet en-tête Un article documents constitué des documents compactés et signés Des données de transmission telles ue le ticket. Dans l en-tête sont indiués le type de pauet, le nom de fichier de l article documents, etc. Cet élément est toujours présent dans le pauet. L objet en-tête est écrit en XML, conformément à la DTD exposée à l appendice II. On crée un pauet destiné à transiter par un réseau en faisant de ces articles multiples un seul bloc de données. La marche à suivre pour créer le pauet est la suivante : Création d un pauet compacté par compression ZIP des différents articles Création d un pauet signé et chiffré pour la transmission sur le réseau, avec chiffrement selon le type données signées et enveloppées PKCS#7. La signature a pour objet d assurer la combinaison et le contenu de chaue article, et de permettre au destinataire de pouvoir détecter toute altération non autorisée intervenue en cours de transmission. Le chiffrement vise à éviter l interception illicite des données en cours de communication. La signature numériue pour les documents compactés de la demande peut être produite soit par le déposant, soit par son mandataire. La personne ui engage la transmission produit la signature numériue pour aboutir au type données signées et enveloppées.

Annexe 5, page 27 renvois Objet En-tête Documents compactés et signés Données de trans mission (ticket p.ex.) Compactage ZIP Objet En-tête Documents compactés et signés donn. trans. type données signées et enveloppées PKCS#7 Clé de chiffr. Pauet compacté Sign. num. X.509. Pauet signé et chiffré Lorsue l office de propriété intellectuelle reçoit le pauet, il en ouvre les différents articles et détermine le rôle de chacun d après les indications ui figurent dans l en-tête. 6 Envoi Comme on l a vu ci-dessus, l information échangée au cours d une transaction circule par pauets. Chaue phase de l échange correspond à la transmission d un pauet de données entre le déposant et l office de propriété intellectuelle. Pour toute transaction, il y aura les uatre pauets suivants : Demande de ticket Ticket Pauet documents de propriété intellectuelle Certificat de confirmation. Quelle ue soit la procédure concernée, le pauet documents de propriété intellectuelle contiendra dans tous les cas les données effectivement établies par le déposant (nouvelle demande, paiement de taxe, revendications de remplacement, etc.). Le Mécanisme du ticket fonctionne comme suit :

Déposant SCIT/P 8/99 Rev.1 Annexe 5, page 28 Étapes d une session électroniue Envoi d une demande de ticket avec empreinte du message (première partie de la transmission) Office de propriété intellectuelle Attribution d une date de dépôt provisoire Envoi du ticket comportant l accusé de réception et la date de dépôt provisoire Envoi du pauet documents de propriété intellectuelle Envoi du certificat de confirmation Vérification de l identité des empreintes, vérification de l absence de virus Une session électroniue est ouverte entre le déposant et l office de propriété intellectuelle. Au début de cette session, une empreinte du message, dérivée de manière univoue des fichiers compactés, est transmise à l office. Le codage est tel ue la moindre modification apportée à l un de ces fichiers se traduit par une modification de l empreinte. Dès réception de cette empreinte du message, et dans le cadre de la session, l office envoie au déposant un accusé de réception comportant la date de réception de l empreinte, lauelle s appliuera aux documents ui seront envoyés ultérieurement dans leur intégralité. Le déposant poursuit alors la session et transmet le jeu complet des fichiers ui constituent le pauet documents de propriété intellectuelle. À réception du jeu complet des fichiers, les documents font l objet d un contrôle antivirus et sont traités de manière à restituer leur empreinte univoue. Celle-ci est comparée à l empreinte initiale du message, celle ui a été envoyée en début de session. Si les deux empreintes correspondent, un accusé de réception est envoyé au déposant. Si elles ne correspondent pas, le déposant en est informé. La session peut alors prendre fin. Le supplément 4 donne toutes les précisions voulues sur le flux de communication dans un système avec ticket. En cas de problème dans les communications ou dans la comparaison des empreintes de message, le certificat de confirmation renseigne sur le problème détecté. 6.1 Protocole de transmission Afin d accroître la probabilité de validation, une couche protocole de transport fiable doit être utilisée pour tous les transferts entre offices. Ce protocole sert à garantir ue toutes les données à transmettre ont été correctement transférées entre les applications logicielles

Annexe 5, page 29 d expédition et de réception et correctement réassemblées. Aux fins de la présente norme, on utilisera pour transmettre le pauet le protocole FTP ou le protocole HTTP. La sécurité de transmission assurée par le chiffrement du type données signées et enveloppées PKCS #7 sera normalement suffisant mais, si un office de propriété intellectuelle l estime nécessaire, il peut opter pour un chiffrement au niveau de la voie d accès du type SSL ou IP Sec, ui rendra la transmission encore plus sûre. 7 Types d échange de documents La présente norme relative à l échange de documents est applicable aux procédures ci-après : Procédures nationales liées aux brevets Dépôt en ligne de nouvelles demandes de brevet [Communications de procédure entre le déposant et un office de propriété intellectuelle] Procédures PCT Dépôt en ligne de nouvelles demandes PCT [Communications de procédure entre le déposant et l office récepteur ou le Bureau international Envoi de l office récepteur au Bureau international (exemplaire original) Envoi de l office récepteur à l'administration chargée de la recherche internationale (copie de recherche) Envoi du Bureau international à l'administration chargée de la recherche internationale Envoi du Bureau international à l'administration chargée de l examen préliminaire international] Procédures non brevet [Demandes d enregistrement de marues Communication de procédure entre le déposant et un office de propriété intellectuelle] 8 Mise en œuvre des renvois Dans le cadre de l élaboration de la présente norme, les offices de la coopération trilatérale ont préparé deux modalités de renvoi (toutes deux en JAVA et C++ sous Windows NT), ui permettent à d autres concepteurs de réutiliser et d étendre le code source initial fourni pour concevoir des implémentations spécifiues pour tel client ou telle procédure. Les implémentations de renvoi couvrent les domaines suivants : ZIP PKCS#7 Assemblage Transmission selon le principe du ticket, avec renvoi d un certificat de confirmation. Elles sont disponibles en code source et en code objet. En outre, des jeux de données-tests standard sont à disposition pour vérifier les implémentations de tiers.

Annexe 5, page 30 Supplément 1. Prescriptions relatives au format des documents Les offices de la coopération trilatérale et l OMPI sont attachés au principe de la mise en place d un environnement fondé sur des standards ouverts pour l échange électroniue de documents de propriété intellectuelle. Ceci a une conséuence notable : la norme applicable à l envoi de documents électroniues recommandera de préférence des standards ouverts et ne préconisera pas l utilisation de formats exclusifs de fournisseurs pour l échange de documents électroniues. Il s agit notamment, en adoptant cette ligne de conduite, d éviter aux offices d avoir à conserver les exemplaires authentiues de dépôts électroniues dans des versions particulières de formats exclusifs sur lesuels ils n ont aucun contrôle. Les systèmes exclusifs de traitement de texte communément employés présentent l avantage d assembler les documents en un fichier uniue tel ue.doc ou.wps. Les formats de traitement de texte exclusifs.doc,.wps, etc. combinent texte, instructions de traitement, informations de mise en page, infographie par uadrillage, dessin en mode vectoriel, tableaux et autres types de données en un fichier uniue de traitement de texte. Les offices de la coopération trilatérale ont opté pour des systèmes ouverts de préférence aux fichiers de traitement de texte : on y utilisera pour les documents électroniue le langage XML (extensible Markup Language) en cours de développement pour permettre la communication de données structurées sur Web. Un document XML, comme une page Web HTML, comprend un fichier texte codé caractère par caractère et, le cas échéant, un ou plusieurs fichiers supplémentaires pouvant contenir soit encore du texte, soit des données binaires telles u images et dessins. En XML, un document électroniue de demande de brevet consistera normalement en une collection de fichiers. Il pourra, par exemple, comprendre un fichier textuel pour chaue pièce de procédure envoyée au titre de la demande, plus un fichier textuel pour le mémoire descriptif de l invention, accompagné de multiple fichiers graphiues (un pour chaue dessin figurant dans le mémoire descriptif). L approche XML libère les offices de l obligation d investir dans des formats de traitement de texte exclusifs, mais la simplicité du fichier uniue u offrait le traitement de texte est perdue. 1.1 Images Les images en fac-similé à utiliser dans l échange de documents de propriété intellectuelle doivent répondre aux prescriptions suivantes : Format o TIFF V6.0 avec compression de groupe 4, monobande, codage Intel ou o JPEG 200, 300 ou 400 dpi Taille maximum : A4 ou format commercial 1.2 PDF Les documents PDF à utiliser dans l échange de documents électroniues doivent répondre aux prescriptions suivantes : Compatibilité Acrobat V3 Texte non comprimé pour faciliter la recherche Texte non crypté Pas de signature numériue Pas d objets incorporés en OLE Toutes polices de caractères incorporées, standard PS17 ou construites à partir des polices Adobe MM.

Annexe 5, page 31 1.3 XML Tous les documents XML doivent se conformer à l une des DTD spécifiées dans l appendice II. Le jeu de caractères utilisé pour tous les documents XML doit être soit Unicode UCS-2 (ISO/IEC 10646:193) codé UTF8, soit JIS-X0208 codé ISO-2022-JP. (Pour les demandes PCT, sont aussi acceptables les caractères chinois GB2312 et les caractères coréens KSC 5601).

Annexe 5, page 32 Supplément 2. Spécification de compactage (Wrapping) (SDIF Version 2) Le format de compression publié dans le descriptif du logiciel PKZIP de PKWARE et par Info-ZIP convient pour l échange de documents de propriété intellectuelle. Plusieurs fabricants proposent différents logiciels couramment disponibles dans le commerce et des applications permettant de créer des fichiers comprimés. L utilisation du format ZIP présente le double avantage de l archivage et de la compression. 2.1 Compactage des documents constitutifs de la demande Facilité d emploi et normes ouvertes sont les conditions recherchées pour la compression et l assemblage d un document électroniue comportant plusieurs fichiers en un objet électroniue uniue aux fins du transit entre le déposant et l office de brevet. Le fait ue ce soit le déposant ui crée ce fichier uniue simplifie grandement le traitement des documents par l office de propriété intellectuelle, ui n a pas à rechercher la trace de la bonne transmission ou réception de chaue fichier. Le fichier uniue signifie aussi ue l on peut calculer une signature numériue pour le fichier de demande et l utiliser pour assurer l intégrité des données de l entièreté de la demande. 2.2 Archivage et compression La création de fichiers d archive est une méthode ui a été adoptée dans les environnements PC, UNIX et MacIntosh. Une archive est une collection de fichiers informatiues ui ont été mis en pauets à des fins de sauvegarde, pour être transportés ailleurs, pour être stockés hors de l ordinateur de façon à dégager de l espace mémoire sur le disue dur, ou pour conservation à long terme. Une archive peut comporter une simple liste de fichiers, ou des fichiers organisés selon une structure de répertoire ou de catalogue (selon la manière dont le programme considéré prend en charge l archivage). La compression consiste à réduire le volume des données pour économiser de l espace mémoire ou du temps de transmission. Pour la transmission de données, la compression peut s effectuer soit sur le seul contenu, soit sur la totalité de l unité de transmission (y compris les données d en-tête) : cela dépend de plusieurs facteurs. La compression du contenu peut consister simplement à supprimer tous les espaces entre caractères, à insérer un caractère de répétition uniue pour indiuer une chaîne de caractères ui se répètent, ou à remplacer par des chaînes binaires plus courtes les caractères ui reviennent fréuemment. Ce type de compression peut réduire un fichier textuel de 50% par rapport à sa taille initiale. La compression est effectuée par un programme ui appliue une formule ou algorithme pour déterminer comment comprimer ou décomprimer les données. L archivage et la compression tels u ils sont définis ci-dessus présentent des caractéristiues souhaitables pour le dépôt électroniue de documents de brevet comportant des fichiers multiples. Une bonne techniue d archivage produira un fichier uniue ui comprendra tous les fichiers constitutifs d une demande électroniue, plus un répertoire maître de ces fichiers donnant sur eux les informations suivantes : type, taille, date et lieu de dernière modification et code de détection d erreurs CRC. Grâce à la compression des données correspondant au contenu de la demande, la transaction en ligne prendra moins de temps et il y aura moins de risue d erreurs de transmission. 2.3 Utilisation de fichiers comprimés Le format ZIP est un standard ouvert très répandu ui combine l archivage et la compression des fichiers de données. Sa fonction d archivage permet à l utilisateur de rassembler tous les

Annexe 5, page 33 fichiers en un répertoire ZIP uniue. Tous les fichiers ue contient ce répertoire et les informations u il donne à leur sujet sont comprimés en un objet électroniue uniue ui se prête au processus de la signature électroniue. Les algorithmes de compression utilisés du standard ZIP ne produisent aucune perte, de sorte ue l utilisateur peut avoir l assurance ue le fichier décomprimé (le résultat de la décompression) est identiue à l original. Les techniues de compression u utilise le standard ZIP réalisent la plus grande réduction de taille (supérieure à 50%) sur les fichiers textuels, mais des réductions de l ordre de 10 à 20% peuvent être obtenues en ce ui concerne les fichiers images. La fonction de détection d erreurs du format ZIP (fondée sur l utilisation d un code CRC de 32 bits) donne une assurance supplémentaire d intégrité des données. 2.4 Du bon usage de la compression Devront être comprimés les fichiers correspondant à toutes les parties du document identifiées par ailleurs dans la présente spécification. Tous les fichiers externes auxuels renvoie le mémoire descriptif de l invention doivent être inclus dans l envoi en fichier ZIP. Les noms de fichiers figurant dans le répertoire central du fichier ZIP doivent respecter les spécifications du système d opération applicable données par ailleurs dans la présente spécification. 2.4.1 Structure du répertoire Tous les fichiers ZIP doivent avoir une structure de répertoire plate. Lorsu une collection de fichiers doit être intégrée dans un fichier ZIP, il faut la compacter en un fichier ZIP uniue ui sera incorporé à plat. 2.4.2 Algorithmes de compression Le standard ZIP donne au logiciel de compression le choix parmi un certain nombre d algorithmes de compression. La méthode de compression par défaut sera la déflation avec l option compression normale. Les logiciels de décompression traitent ce format sans la moindre difficulté. La méthode de compression par rétrécissement ne sera pas employée parce u elle fait appel à un algorithme de compression LZW (Lempel-Ziv-Welch) ui est protégé par un brevet détenu par la Société UNISYS. 2.5 PKZIP Application Note (Descriptif du logiciel PKZIP ) Le format ZIP a été à l origine mis au point par Phil Katz, puis incorporé dans le logiciel PKZIP pour DOS, disponible en logiciel partagé. PKWARE, la société de Phil Katz, vend des versions commerciales de logiciels ZIP pour de nombreuses plates-formes. Phil Katz a publié les spécifications du format ZIP et en a ainsi fait un standard ouvert. Le code source en langage de programmation C pour les fonctions de compression et de décompression a été à l origine publié par un groupe de concepteurs de logiciels indépendants; il figure sur le site Web d Info-ZIP à l adresse http://www.cdrom.com/pub/infozip/. Info-ZIP affiche aussi le standard ZIP sur son site Web. Il ne s agit pas à proprement parler d une norme internationale, mais l information mise à disposition sur le format ZIP a permis à plusieurs autres fournisseurs d élaborer des produits ui mettent en œuvre des fonctions de décompression sur des plates-formes informatiues très diverses. Un bon degré d interfonctionnement est obtenu entre les produits de ces fournisseurs. La plupart des fournisseurs de produits tiers proposent des logiciels ui sont conçus pour interopérer avec les logiciels PKWARE. Il est prudent de demander au déposant d utiliser pour préparer les fichiers à transmettre un logiciel ui s annonce compatible avec PKZIP et PKUNZIP. Sont actuellement disponibles sur le marché des produits WINZip, DynaZip, NetZip, Info-Zip et autres ui répondent à cette exigence. Le standard PKZIP fait l objet d un descriptif (révisé le 08/01/1998) ui se trouve sur la page Web PKWARE http://www.pkware.com/appnote.html.

Annexe 5, page 34 Supplément 3 Formats d enveloppe PKCS#7 Le présent document énonce les spécifications fondamentales de l enveloppe numériue aux fins de l échange de documents de propriété intellectuelle. Les préalables sont exposés ci-après. 3.1 Portée Dans le présent document est définie la structure de l enveloppe numériue pour la couche de transport et la couche de traitement du corps des données. Les fonctions attendues de l enveloppe numériue sont les suivantes : Signature numériue des données utilisateur (pour authentification ou détection d une altération illicite des données) Chiffrement des données utilisateur. Ne sont PAS traitées dans le présent supplément : La structure des données utilisateur ui vont être chiffrées ou auxuelles vont être apposées une signature numériue. Ne sont par exemple pas traitées la méthode de compactage, la logiue de formatage des documents, etc.. La méthodologie de description des informations supplémentaires utilisées pour le traitement des données dans chaue office national des brevets. Il ne s agit pas d informations essentielles pour le déposant et pour l office récepteur. 3.2 Définitions PKCS#7 La spécification de syntaxe du message cryptographiue selon le standard PKCS#7, telle ue définie dans Internet Draft <drafthoffman-pkcs-crypt-msg-03.txt> Version 1.5 X.509 La norme de certification numériue X.509, telle ue définie dans la Identificateur d objet pour sha-1 Identificateur d objet pour le chiffrement RSA recommandation X.509 de l UIT (06/97). L identificateur d objet ue nous adoptons pour sha-1 est défini dans les protocoles d interconnexion OIW, partie 12. La définition est la suivante : Sha-1 OBJECT IDENTIFIER ::= {iso (1) identifiedorganization(3) oiw(14) secsig(3) algorithm(2) 26} L identificateur d objet pour le chiffrement RSA est défini dans le standard de chiffrement RSA PKCS#1. La définition est la suivante : Pkcs-1 OBJECT IDENTIFIER ::= iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) 1} RsaEncryption OBJECT IDENTIFIER ::={pkcs-1 1}

Annexe 5, page 35 Enveloppe numériue de certification Cette enveloppe sert à la détection d une éventuelle altération des données d utilisateur. Elle contient les données utilisateur, la signature numériue et le certificat numériue du signataire. (A1) Données signées <premier niveau> Enveloppe numériue de signature PKCS#7 Données assemblées (A2) (A2) Info contenu Info contenu (Données (Données utilisateur) utilisatuer) (A3) Infos signataire (signature numériue) (A4) certificats (X.509) Enveloppe numériue de transmission Cette enveloppe, utilisée pour la transmission de données, sert à la fois au chiffrement et à la détection d altérations. En ce ui concerne cette enveloppe, la signature numériue est employée non pas à des fins de certification, mais pour déceler une éventuelle altération des données sur le réseau, c est pouruoi elle ne fait pas partie intégrante des données en gestion. (B1) Données signées et enveloppées <premier niveau> (Enveloppe numériue de transmission PKCS#7) Données chiffrées assemblées (B3) Infos destinataire (clé cryptée) (B2) Info contenu chiffré (Données utilisateur, chiffrées) (A3) Infos signataire (signature numériue) (A4) Certificats (X.509)

Annexe 5, page 36 3.3 Règles communes applicables aux enveloppes numériues pour l échange de documents de propriété intellectuelle Toutes les données des enveloppes numériues doivent être codées selon les règles DER. La règle de codage DER aide le programme d application à analyser les données de l enveloppe numériue selon une règle uniue. 3.3.1 Enveloppe numériue de signature Cette enveloppe numériue est du type SignedData PKCS#7. Règles de production de l enveloppe numériue PKCS#7 aux fins de certification Tableau A1 SignedData (données signées), premier niveau N. Nom d article Article PKCS#7 Contenu 1 Version Version Mettre la valeur entière 1 2 Jeu d identificateurs DigestAlgorithms d algorithme 2.1 Identificateur d algorithme 3 Information relative au contenu AlgorithmIdentifier ContentInfo Mettre UN SEUL jeu d identificateurs d algorithme {sha-1} 1 Mettre une information relative au contenu (voir le tableau A2) 4 Certificats Certificates Mettre un élément Certificates (voir le tableau A4) 5 Listes d annulation 6 Information relative au signataire Crls SignerInfos Vide (ne rien mettre) Mettre un élément SignerInfos (voir le tableau A3) Tableau A2 contentinfo (information relative au contenu), premier niveau N Nom d article Article PKCS#7 Contenu 1 Type de contenu ContentType Mettre un identificateur d objet {pkcs-7 1} 2 Contenu Content Mettre les données utilisateur (binaires) Tableau A3 signerinfos (informations relatives au signataire), premier niveau N Nom d article Article PKCS#7 Contenu 1 Version Version Mettre la valeur entière 1 2 Émetteur et numéro d ordre 3 Jeu d algorithmes de compression IssuerAndSerialNumber DigestAlgorithm Émetteur du certificat et numéro d ordre de celui-ci selon la spécification X.509 (concernant le certificat du signataire) 1 sha-1 OBJECT IDENTIFIER ::={iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 26 }

3.1 Identificateur d algorithme SCIT/P 8/99 Rev.1 Annexe 5, page 37 AlgorithmIdentifier Mettre UN SEUL jeu d identificateurs d algorithme {sha-1} pour la production d une empreinte de signature numériue Vide (ne rien mettre) 4 Attributs authentifiés AuthenticatedAttributes 5 Algorithme de DigestEncryptionAlgoritm Mettre l identificateur d objet chiffrement de {pkcs-1 1} (rsaencryption 2 ) l empreinte 6 Empreinte chiffrée EncryptedDigest Empreinte des données du message; le contenu est chiffré au moyen de la clé privée du signataire 7 Attributs non authentifiés UnauthenticatedAttributes Tableau A4 certificates (certificats), premier niveau N Nom d article Article PKCS#7 Contenu 1 Jeu de certificats ExtendedCertificatesAndCerti ficates 1.1 Le certificat X.509 Certificate (défini dans la spécification X.509) Vide (ne rien mettre) 4.3.2 Précisions concernant l enveloppe numériue de transmission Mettre UN SEUL jeu de données de certificat X.509 Cette enveloppe numériue est du type SignedAndEnvelopedData PKCS#7. Règles de production de l enveloppe numériue de transmission PKCS#7 Tableau B1 SignedAndEnvelopedData (données signées et enveloppées), premier niveau N Nom d article Article PKCS#7 Contenu 1 Version Version Mettre la valeur entière 1 2 Informations relatives au destinataire 2 Jeu d identificateurs d algorithme 2.1 Identificateur d algorithme 3 Informations relatives au contenu chiffré RecipientInfos DigestAlgorithms AlgorithmIdentifier EncryptedContentInfo Mettre UN SEUL jeu d éléments RecipientInfo (voir le tableau B3) Mettre UN SEUL jeu d identificateurs d algorithme {sha-1} Mettre un élément contenu chiffré (voir le tableau B2) 4 Certificats Certificates Mettre un élément Certificates (voir le tableau A4) 2 rsaencryption OBJECT IDENTIFIER ::={pkcs-1 1}

5 Listes d annulation 6 Informations relatives au signataires Crls SignerInfos SCIT/P 8/99 Rev.1 Annexe 5, page 38 Vide (ne rien mettre) Mettre un élément SignerInfos (voir le tableau A3) Tableau B2 EncryptedContentInfo (information relative au contenu chiffré), premier niveau N Nom d article Article PKCS#7 Contenu 1 Type de contenu ContentType Mettre l identificateur d objet {pkcs-7 1} 2 Algorithmes de chiffrement du contenu ContentEncryptionAlgorithm Identificateur d OBJET de l algorithme de chiffrement du contenu (système testé par l Office japonais des brevets : DES en CBC) 3 Contenu chiffré EncryptedContent Données utilisateur chiffrées Tableau B3 recipientinfo (information relative au destinataire), premier niveau N Nom d article Article PKCS#7 Contenu 1 Version Version Mettre la valeur entière 1 2 Émetteur et numéro d ordre 3 Algorithme de surchiffrement IssuerAndSerialNumber KeyEncryptionAlgorithm Émetteur et numéro d ordre du certificat comportant la clé publiue pour le cryptage de la clé de chiffrement des données utilisateur Identificateur d OBJET de l algorithme de cryptage de la clé de chiffrement des données utilisateur (système testé par l Office japonais des brevets : RSA1024) 4 Clé cryptée EncryptedKey Clé cryptée pour le déchiffrement des données utilisateur

Annexe 5, page 39 Supplément 4. Mécanisme du ticket Le présent supplément décrit le format des données correspondant à chaue phase de mise en œuvre du mécanisme du ticket. La communication par ticket s effectue entre le déposant et l office de propriété industrielle selon le protocole suivant. Déposant Protocole d une session électroniue Envoi d une demande de ticket avec empreinte du message (première partie de la transmission) Office de propriété intellectuelle Attribution d une date de dépôt provisoire Envoi du ticket comportant l accusé de réception et la date de dépôt provisoire Envoi du pauet documents de propriété intellectuelle Envoi du certificat de confirmation Vérification de l identité des empreintes du message Figure 1.Protocole du ticket Les modalités de chaue étape du système du ticket sont décrites ci-après. 4.1 Demande de ticket La demande de ticket est le premier pauet ui est envoyé à l office récepteur. L intérêt de cet envoi est de prémunir le déposant contre le préjudice d incidents pouvant survenir en ce ui concerne les mesures de récupération ou la vitesse de transmission en cas de défaillance de la ligne pendant l envoi d une demande, lorsue les données correspondant aux documents constitutifs de la demande forment un article volumineux. La demande de ticket comporte Une empreinte du message, créé par un algorithme de compression après compactage des documents par ZIP, Des données bibliographiues et Un objet en-tête indiuant ue le pauet correspondant est une demande de ticket. La demande de ticket est créée par compactage de ces trois articles en un fichier ZIP, leuel est incorporé à un pauet de type Signed And Enveloped Data PKCS#7. Ce pauet doit être vérifié par le client avant envoi. Si la moindre erreur est décelée, l utilisateur en est informé et l envoi est annulé. Des précisions sur les données de l objet en-tête figurent à l appendice II. Le supplément 3 donne des informations sur le standard PKCS#7.

Annexe 5, page 40 Application Document document principal Documents External de renvoi Document et pièces jointes Sub-parts Compactage ZIP Doc. demande Renvois PJ Documents constitutifs de la demande, compactés fonction de hachage Assemblage en Signed Data PKCS#7 Empreinte du message Vérification Empreinte du message Décodage Documents constitutifs de la demande, compactés Signature numériue X.509 Article documents constitutifs de la demande Demande de ticket Figure 2. Schéma de l empreinte du message Déposant Office de propriété intellectuelle La demande de ticket comprend les articles suivants : Entête Bibliographie Empreinte du message, créee à partir des documents compactés La bibliographie et l empreinte du message sont sauvegardées pour être renvoyées avec le ticket. Documents cmpactés Message Digest Bibliographie Bibliographie Objet en-tête Object En-tête Bibliographie Empreinte du message Empreinte du message Campactage ZIP et assemblage en Signed And Developed Data PKCS#7. Désassemblage et décompactage Article demande de ticket Signataire Signataire Article demande de ticket X.509 X.509 Figure 3. La demande de ticket

Annexe 5, page 41 4.2 Réponse par ticket Le ticket envoyé en réponse comprend un objet d en-tête, un article données du ticket et des données bibliographiues. L objet d en-tête indiue ue le pauet correspondant est la réponse par ticket. L article données du ticket est créé selon le type Signed Data (données signées) PKCS#7 par compactage du ticket ui comprend le numéro de réception de la demande de ticket, la date d émission du ticket et sa date d expiration, ainsi ue l empreinte de message reçue dans la demande de ticket par ZIP. Les données bibliographiues sont jointes pour lier expressément le ticket à la demande de ticket. Le ticket est créé par assemblage en Signed And Enveloped Data (données signées et enveloppées) PKCS#7, après compactage des articles par ZIP. L article données du ticket contenu dans la réponse pourra figurer dans la nouvelle demande. Des précisions sur l objet d en-tête figurent à l appendice II. Le supplément 3 donne des informations sur le standard PKCS#7.

Annexe 5, page 42 Ticket Déposant Le déposant conserve les données du ticket reçu pour les joindre à la nouvelle demande lors de son envoi à l office récepteur. Office de propriété intellectuelle Création de l article données du ticket par compactage avec l en-tête comportant le numéro de réception du ticket, la date d émission et la date d expiration, puis assemblage en type Signed Data. Création d une demande de ticket comportant en-tête, données du ticket et bibliographie Objet En-tête Ticket Empreinte du message Désassemblage du type Signed Data PKCS#7 et décompactage Données du ticket Sauvegarde SignatureOR X.509 Article Données du ticket Article Données du ticket Bibliographie Bibliographie Objet En-tête Ticket Empreinte du message Compactage ZIP et assemblage en type Signed Data PKCS#7. Données du ticket Signature office PI X.509 Bibliographie Article Données du ticket Désassemblage et décompactage Compactage ZIP et assemblage l en type Signed And Enveloped Data PKCS#7. Article ticket Signataire Signataire Article ticket X.509 X.509 Figure 4. Le ticket 4.3 Document de propriété intellectuelle L article documents de propriété intellectuelle est créé par assemblage des documents compactés en type Signed Data (données signées) PKCS#7. Les documents auront été préalablement compactés selon le standard ZIP. L article documents de propriété intellectuelle comporte un objet d en-tête ui indiue le contenu du pauet correspondant ainsi ue l article données du ticket reçu dans la réponse par ticket. Un document de propriété intellectuelle est créé sous forme d enveloppe du type Signed And Enveloped Data (données signées et enveloppées) PKCS#7, après compactage des articles correspondants par ZIP. L empreinte du message, dérivée de l article données du ticket décompacté, est comparée à l empreinte du message des documents compactés de l article document de propriété intellectuelle. Des précisions sur l objet d en-tête figurent à l appendice II. Le supplément 3 donne des informations sur le standard PKCS#7.

Annexe 5, page 43 Documents de propriété intellectuelle Déposant Office de propriété intellectuelle Documents compactés Compactage ZIP et assemblage en Signed Data PKCS#7. Documents constitutifs de la demande, compactés Désassemblage du type Signed Data PKCS#7 et décompactage documents compactés Signature de l expéditeur X.509 Article données du ticket Documents Signature de l expéditeur compactés X.509 Décodage Empreinte du message Vérification Empreinte du message Objet En-tête Article Documents Article Données du ticket Objet En-tête Article Documents Article données du ticket Décompactage Compactage ZIP et assemblage en Signed And Developed Data PKCS#7. Désassemblage et décompactage Données documents de propriété intellectuelle Signataire Signataire Données documents de X.509 propriété intellectuelle X.509 Figure 5. La nouvelle demande 4.4 Certificat de confirmation Le certificat de confirmation comporte un article données du certificat, un objet d en-tête indiuant ue le pauet correspondant est un certificat de confirmation et, à titre facultatif, l article documents constitutifs de la demande reçu avec la nouvelle demande. Le certificat de confirmation est créé par compactage et assemblage de ces articles en un type Signed And Enveloped Data (données signées et enveloppées) PKCS#7. Toute procédure de demande se conclut par un certificat de confirmation.

Annexe 5, page 44 Certificat de confirmation Déposant Office récepteur Certificat Certificat désassemblage du type Signed Data PKCS#7. Signature office PI Certificat X.509 Données du certificat Certificat Signature office PI X.509 Données du certificat Assemblage en Signed Data PKCS#7. objet en-tête Données certificat Données Documents PI Vérification Données Documents PI objet en-tête Données certificat Données Documents PI Désassemblage et. Compactage ZIP et assemblage en Signed and Enveloped Data Données Confirmation Signataire Données Signataire X.509 Confirmation X.509 Figure 6. Le certificat de confirmation Le certificat de confirmation sert à informer le déposant de la réception de la demande; il doit contenir une version XML de cette information. Il peut contenir une version des données formatée en PDF, TIFF ou JPEG. Ces fichiers sont combinés en un fichier ZIP uniue et signés au moyen du certificat numériue de l office de propriété intellectuelle.

Annexe 5, page 45 Supplément 5: Aide-mémoire des conditions à respecter aux fins de la gestion des pièces électroniues 5.1 OBJET... 46 5.2 VUE D ENSEMBLE... 46 5.3 DÉFINITIONS... 49 5.3.1 Pièces... 49 5.3.2 Pièce électroniue... 51 5.3.3 Pièce fondamentale... 51 5.3.4 Pièce complète... 51 5.3.5 Conservation des pièces... 52 5.3.6 Durée d utilisation... 53 5.4 RÈGLES À RESPECTER... 54 5.4.1 Acuisition des pièces... 55 5.4.2 Métadonnées... 58 5.4.3 Gestion des dossiers... 65 5.4.4 Préservation de l intégrité... 66 5.4.5 Protection du caractère confidentiel... 67 5.4.6 Contrôles d accès et authentification... 68 5.4.7 Recherche, extraction et reproduction... 68 5.4.8 Piste de contrôle... 70 5.4.9 Copie de sauvegarde et récupération... 72 5.4.10 Conservation des dossiers et des pièces... 73 5.4.11 Migration... 77 5.4.12 Transfert aux archives... 79 5.4.13 Pièces en attente de classement... 79 5.5 PRINCIPES DIRECTEURS APPLICABLES AUX MÉTADONNÉES... 80 5.5.1 Métadonnées de type reformatage...80 5.5.2 Métadonnées de type copie... 82 5.5.3 Métadonnées de type transfert... 85

Annexe 5, page 46 5.1 OBJET Le présent aide-mémoire des principes applicables à la gestion des pièces électroniues a pour objet de recenser et de définir les règles dont les offices de propriété intellectuelle doivent tenir compte lorsu ils mettent au point et exploitent des systèmes informatiues aux fins de la gestion des dossiers et pièces électroniues de propriété intellectuelle. 5.2 VUE D ENSEMBLE Le plan stratégiue concernant les techniues de l information du Comité permanent des techniues de l information (SCIT) propose une certaine conception du XXI e siècle. La vocation du SCIT est de s attacher à mettre en place une architecture mondiale des techniues de l information reliant les offices de propriété intellectuelle des États membres de l OMPI, les offices régionaux de propriété intellectuelle et le Bureau international aux fins de générer, communiuer et diffuser l information relative aux droits de propriété intellectuelle, en œuvrant pour la protection des savoirs et des droits de propriété intellectuelle dans l optiue de l économie mondialisée du XXI e siècle et en veillant à une répartition mondiale des tâches. Ce plan décrit les grandes lignes stratégiues ui permettront d améliorer la gestion des techniues de l information et de relier entre eux les offices de propriété intellectuelle grâce à la mise en place d une architecture mondiale de ces techniues. Il existe des raisons juridiues et techniues pour ue tous les aspects de la gestion des dossiers électroniues de propriété intellectuelle (politiues, pratiues, procédures, processus, principes et solutions) par les offices de propriété intellectuelle soient examinés avant la mise en place de cette architecture mondiale. Les offices de propriété intellectuelle doivent être à même de gérer de manière adéuate toutes les pièces, y compris les pièces électroniues. Les offices de propriété intellectuelle doivent veiller à ce ue l intégrité de toutes les pièces soit préservée pendant toute la durée de leur conservation et ue le caractère confidentiel de ces pièces soit protégé, selon ue de besoin. Les dossiers et pièces électroniues nécessitant un accès facile et une mise à jour peuvent être conservés indéfiniment. Les techniues de l information constituant un domaine en mutation rapide, il sera certainement nécessaire de transférer, à plusieurs reprises, les pièces électroniues de

Annexe 5, page 47 propriété intellectuelle sur de nouveaux supports de stockage et de nouveaux matériels et logiciels au cours de la durée de conservation prescrite. Les offices de propriété intellectuelle doivent gérer de manière adéuate toutes les pièces, y compris les pièces électroniues, durant la durée de conservation prescrite. Les dossiers et pièces de propriété intellectuelle peuvent faire l objet d une communication préalable dans le cadre d une procédure judiciaire et doivent, par conséuent, aussi être recevables auprès des tribunaux, dans le cadre de recours ou de conflits. La gestion des pièces consiste à administrer le matériel d information ui doit être préservé en raison de son importance. Les pièces doivent être conservées car elles constituent des preuves de politiues ou de transaction officielles ou u elles contiennent des informations utiles à long terme. La gestion des pièces doit être assurée durant tout le cycle de vie de celles-ci, c est-à-dire depuis leur création jusu à leur destruction en passant par leur mise à jour et leur utilisation. La gestion des pièces impliue bien plus ue la simple conservation de pièces électroniues des offices de propriété intellectuelle. Il convient en effet de s assurer ue la saisie et le stockage des pièces électroniues (ou sur support papier) reçues ou créées par un office de propriété intellectuelle donné ont été effectués de manière précise et fiable. Il faut à cet effet utiliser les métadonnées et les formats de fichier ui permettront d accéder aux dossiers, ou de transférer ceux-ci, pendant toute la durée de leur conservation. Leur intégrité doit être préservée et leur caractère confidentiel protégé à compter du moment où ils ont été reçus ou créés et jusu à la fin de la durée de conservation. Maintenir l intégrité et le caractère confidentiel des pièces électroniues de propriété intellectuelle est essentiel à la protection des droits de propriété intellectuelle et de la valeur des actifs commerciaux de l inventeur. À cette fin, il convient de veiller à ce ue des copies électroniues précises et fiables des pièces soient effectuées et protégées contre toute perte, modification, annulation ou destruction prématurée durant tout leur cycle de vie. La gestion de l information incorporée dans des pièces électroniues présente de nombreuses similitudes avec la gestion traditionnelle des données numériues dans les systèmes informatiues. Elle comporte toutefois certaines spécificités : accès à long terme (décennies), conservation à long terme des pièces (et, dans de nombreux cas, indéfiniment), utilisation de nouveaux moyens de stockage, transfert vers de nouveaux matériels, logiciels ou applications, et utilisation de métadonnées uniues aux fins d une gestion des pièces électroniues reposant sur un accès et une conservation à long terme.

Annexe 5, page 48 Compte tenu des projets et programmes de la communauté de la propriété intellectuelle, ui sont axés sur le dépôt, le traitement et la gestion électroniues des demandes, il est impératif de définir les politiues, pratiues, procédures et systèmes informatiues ui permettront d assurer, dans ce nouveau contexte, une gestion efficace des pièces électroniues ui seront reçues, créées, stockées, conservées, reproduites, diffusées ou auxuelles il sera possible d accéder. Aujourd hui, les différents systèmes judiciaires reconnaissent le rôle prépondérant des pièces (copies ou duplicatas) créées, stockées ou reproduites par la voie électroniue. Il est difficile de prouver ue des pièces produites en tant ue preuves sont authentiues et u elles ont été créées de manière précise et fiable dans le cadre d activités ordinaires. Il est plus facile de prouver la fiabilité de pièces électroniues lorsue des procédures adéuates de gestion de celles-ci sont appliuées dans le cadre de ces activités. Le test de l authenticité est un critère de recevabilité des plus critiues et l un de ceux ui risue de présenter le plus de difficultés : la notion est en effet définie de façon assez générale et l authenticité est généralement établie sur la foi d un témoignage. Les pièces électroniues doivent être créées, reçues, incorporées et stockées avec précision et fiabilité. En outre, elles doivent être créées, soumises à transaction ou communiuées par une partie identifiable et pouvant faire l objet d une vérification, reçues ou créées et stockées à un moment précis, et mises à jour sous la forme sous lauelle elles ont été incorporées ou soumises à transaction et protégées de toute modification ou destruction non autorisée (c est-à-dire ue l intégrité de la pièce est préservée).

Annexe 5, page 49 5.3 DÉFINITIONS Il est important de définir le terme pièce et de savoir ce ue l on entend par pièce officielle (d un office de propriété intellectuelle), lauelle est destinée à être versée au dossier électroniue et gérée pendant toute sa durée de conservation. Dans ce contexte, il est aussi intéressant de définir les termes fichier de travail, pièce non officielle et pièce fondamentale. 5.3.1 Pièces Documents d information est un terme collectif regroupant les pièces officielles et les pièces non officielles, dont le contenu a été enregistré sur un support, uelles ue soient la nature de ce support, la méthode d enregistrement et les conditions de l enregistrement. Ces documents peuvent devenir des pièces lorsu ils ont été créés ou reçus par un office de propriété intellectuelle dans le cadre d une transaction commerciale et u il est nécessaire de les conserver car ils constituent une preuve de politiues ou d activités officielles ou ue l information u ils contiennent présente une valeur à long terme. Les fichiers de travail constituent aussi des documents d information u il peut être utile de conserver. Ces fichiers, ui peuvent comprendre, entre autres, des avant-projets ou des brouillons, doivent être conservés à des fins de documentation lorsue ils ont circulé parmi des employés (autres ue leur auteur) de l office de propriété intellectuelle concerné ou u ils ont été mis à la disposition de ceux-ci à des fins officielles (pour approbation, observations, suite à donner, suivi) ou en vue d informer le personnel de cet office sur les activités de celui-ci; ils contiennent des informations uniues, telles ue des annotations ou des observations de fond, ui contribuent à mieux faire comprendre la formulation et l application, par l office concerné, de politiues, décisions ou mesures fondamentales ainsi ue la définition et l attribution de responsabilités. Il convient d opérer une distinction entre documents officiels et documents non officiels. Il est difficile de ualifier de pièces la plupart des documents d information générés ou reçus par un office de propriété intellectuelle lorsue celui-ci a défini, et mis à jour régulièrement, des règles d enregistrement de documents couvrant tous les supports et toutes les activités à tous les niveaux et dans tous les lieux. Certains types de documents ne peuvent pas être considérés comme des exemplaires originaux et sont, par conséuent, des pièces non officielles. L exemple typiue d une pièce non officielle est la copie supplémentaire d un document conservé à des fins de référence uniuement. Autre exemple : les

Annexe 5, page 50 stocks de publications et les documents produits. Les documents non officiels ne présentent pas vraiment d intérêt à long terme du point de vue informatif. 5.3.1.1 Exemplaire original Dans cet aide-mémoire, toute pièce stockée et gérée en tant ue preuve d activités ou d événements en rapport avec un dossier de propriété intellectuelle, u elle soit sur support papier ou électroniue, est appelée exemplaire original. Elle doit satisfaire aux conditions suivantes : elle doit avoir été créée ou reçue dans le cadre d une transaction de l office de propriété intellectuelle concerné, elle doit être conservée ou considérée comme devant être conservée par cet office car elle constitue une preuve (d une forme d organisation, de fonctions, de politiues, de décisions, de procédures, d une exploitation ou d autres activités) ou parce u elle présente à long terme un intérêt du point de vue informatif. Une copie supplémentaire d une pièce constitue un document non officiel. En substance, tout document, sur support papier ou électroniue, remis par un déposant à un office de propriété intellectuelle, en rapport avec un dossier de propriété intellectuelle, est un exemplaire original car, d une part, il prouve la réalisation d une transaction par l office en uestion et ue, d autre part, il représente ce ue le déposant considérerait comme étant un exemplaire original au moment de sa remise à l office. Tout document créé par un office de propriété intellectuelle, dont la version définitive a été arrêtée et communiuée à un déposant ou versée à un dossier de l office en uestion, constitue une pièce. Tout fichier de travail ui a circulé parmi des employés (autres ue son auteur) d un office de propriété intellectuelle, ou ui a été mis à la disposition de ceux-ci, à des fins officielles, et ui contient des informations uniues permettant de mieux comprendre des politiues, décisions, mesures ou responsabilités fondamentales, est considéré comme un exemplaire original et doit être versé au dossier électroniue de propriété intellectuelle concerné. Cette définition suppose toutefois ue les fichiers de travail créés et conservés par un seul employé de l office, c est-à-dire des fichiers n ayant pas circulé au sein de l office à des fins officielles, ne constituent pas des exemplaires originaux.

Annexe 5, page 51 5.3.2 Pièce électroniue Le terme pièce électroniue doit être défini par rapport au terme général pièce, étant entendu ue la pièce électroniue se présente sous une forme numériue ue seul un ordinateur peut traiter. La pièce numériue se compose de chiffres, de graphiues ou de texte, ui sont enregistrés sur un support pouvant être lu par ordinateur et forment un tout correspondant à la définition de la pièce. Il s agit donc, entre autres, de supports magnétiues, tels ue des bandes ou des disues, et de disues optiues. Sauf stipulation contraire, ces critères s appliuent à tous les systèmes d enregistrement électroniue, u il s agisse de micro-ordinateurs, de mini-ordinateurs ou d ordinateurs centraux, indépendamment du support sur leuel l information est stockée et de la configuration adoptée (configuration réseau ou configuration autonome). 5.3.3 Pièce fondamentale En substance, tous les dossiers de propriété intellectuelle, y compris les annotations, liens et métadonnées connexes, sont des pièces fondamentales. Il convient donc de réaliser une copie de sauvegarde de tous les dossiers électroniues, avec les métadonnées, pour pouvoir faire face à toute catastrophe. Les pièces fondamentales, ui jouent un rôle essentiel dans la conservation des droits et la préservation des intérêts des offices de propriété intellectuelle, sont aussi indispensables aux personnes ayant des relations d affaires avec ces offices. Ces pièces doivent donc être protégées et les lieux de stockage se trouver dans les centres d exploitation d urgence ou à proximité de ceux-ci. 5.3.4 Pièce complète Une pièce est réputée complète lorsu elle comprend les trois éléments fondamentaux suivants : le contenu, la structure et le contexte. Le contenu comprend les données résultant d une transaction ayant eu lieu dans le cadre d une activité normale, par exemple après réception d une demande de brevet. Ainsi, une pièce a l effet de transmettre une demande de brevet comprend différents champs de données se rapportant à des éléments particuliers du formulaire plus une signature. La structure comprend, en général, deux parties : la structure logiue et la structure physiue. La structure logiue se compose des parties identifiables de la pièce, telles ue le titre, l adresse du déposant, la date et la signature figurant sur un formulaire de demande de brevet. Ces parties

Annexe 5, page 52 peuvent être identifiées à la fois par l ordinateur (dans les métadonnées) et par l être humain (sous la forme graphiue) à l écran ou à l impression. La structure physiue concerne la présentation de la pièce, c est-à-dire, entre autres, la police de caractères, l espacement, les marges, le logotype et le codage ou format du fichier, ui contient des informations aux fins du traitement ( rendu ) ou du transfert de la pièce pendant la durée de conservation. Le contexte concerne la signification de la pièce, autrement dit la raison d être et le contenu de la transaction commerciale dans le cadre de lauelle la pièce a été créée ou reçue. Le contexte peut être implicite, c est-à-dire u il peut découler du contenu et de la structure de la pièce : c est notamment le cas d un formulaire de demande de brevet, ui contient un numéro de formulaire, ou locution, et un groupe signature ui indiue l intention du signataire. Le contexte peut aussi comprendre l environnement général dans leuel la pièce est stockée et gérée (par exemple, le dossier de propriété intellectuelle auuel se rapporte la pièce ou le service d archives où est classé le dossier). Pour pouvoir être admise en tant ue preuve dans une procédure judiciaire, la pièce doit avoir été reçue ou créée par un système ui en a conservé une représentation précise. Pour u une pièce soit considérée comme précise, par conséuent, fiable, il faut u on dispose de renseignements aussi complets ue possible sur nombre de ses éléments. Plus une pièce semble être complète, plus elle a de chances d être considérée comme authentiue (c est-à-dire ayant le sens u elle prétend avoir) et plus elle aura d importance en tant ue preuve. Une pièce peut comprendre un ou plusieurs fichiers (c est le cas de la pièce composée, ui comprend un fichier texte et un fichier graphiue), le contenu, la structure et le contexte de chaue fichier pouvant être identifiés séparément soit en tant ue partie de la pièce, soit en tant ue métadonnée relative à la pièce et aux fichiers. Le dossier électroniue se compose d une ou de plusieurs pièces, étant entendu ue le contenu, la structure et le contexte de chacune de ces pièces peuvent être identifiés séparément. 5.3.5 Conservation des pièces La durée de conservation des pièces varie en fonction de l état du dossier (p. ex. : le brevet a-t-il été délivré ou abandonné?) et de la date à lauelle la demande a été déposée. La durée de conservation de toute pièce est fixée en fonction de critères commerciaux ou juridiues ou de sa valeur historiue. En d autres mots, la pièce en uestion est-elle nécessaire à certaines transactions? Dans l affirmative, elle doit être conservée aussi longtemps ue cette nécessité existe. Lorsue la pièce a une valeur juridiue ou historiue, le calcul de sa durée de conservation appelle moins de uestions et laisse moins de place à l intuition.

Annexe 5, page 53 Parmi les documents à conserver pour des raisons commerciales figurent ceux ui concernent un système automatisé : ils doivent donc être conservés jusu à ce ue celui-ci ne soit plus utilisé. Un traité est un document ui doit être conservé pour des raisons juridiues. Les fichiers du chef d un office de propriété intellectuelle, ui attestent l histoire et l évolution de cet office, doivent être conservés pour des raisons historiues. 5.3.5.1 Conservation des dossiers Aux fins de l établissement du calendrier de conservation des pièces, chaue dossier de propriété intellectuelle u il soit électroniue ou non est, une fois complet, assorti d une durée de conservation uniue. Par conséuent, toutes les pièces électroniues se trouvant dans le dossier peuvent être gérées et conservées indépendamment. 5.3.5.2 Conservation d un seul exemplaire original À des fins d exploitation et à des fins juridiues, il convient de ne conserver u un seul exemplaire original, plus une copie de sauvegarde, de toute pièce ou fichier électroniue. Du point de vue de l exploitation, ne conserver u un seul exemplaire original d un dossier électroniue permet d éviter, d une part, tout risue de confusion uant au document ui constitue le document officiel et, d autre part, d avoir à disposition une copie ui n est pas à jour. Cela signifie ue les copies ui ne sont conservées u à titre de référence doivent être supprimées dès ue cela est possible. Les fichiers de travail doivent soit être versés au dossier électroniue, soit être supprimés dans les meilleurs délais. Du point de vue juridiue, et plus précisément de la communication de documents, toutes les pièces ayant un rapport avec une assignation à comparaître (dans le cas d une ou de plusieurs demandes de brevet) peuvent faire l objet d une divulgation et doivent être communiuées sur demande. Par conséuent, les copies ou fichiers de travail de référence ui n ont pas été supprimés peuvent être divulgués et doivent, sur demande, être communiués. 5.3.6 Durée d utilisation Les dossiers électroniues de propriété intellectuelle sont gérés en deux phases, logiues et progressives.

Annexe 5, page 54 1) Instruction en cours et utilisation : il s agit de la période où la demande de brevet est en instance. À ce stade, le dossier et toutes les pièces électroniues sont gérés par le système informatiue et par le système d acheminement du travail dont dépendent le dépôt, la révision, l examen et les procédures de délivrance, d enregistrement ou d abandon. 2) Mise à jour et utilisation : il s agit de la période ui suit la délivrance d un titre de propriété intellectuelle ou l abandon d une demande de titre. Lorsue les documents sont sur papier, cette période commence au moment où le dossier est transféré à l employé chargé de le conserver avant archivage. C est aussi durant cette phase ue la durée de la conservation du dossier est fixée. Pendant la seconde phase, des pièces électroniues peuvent être versées aux dossiers (p. ex. : cessions) et certaines métadonnées peuvent être ajoutées ou mises à jour (p. ex. : adresse du déposant ou de l inventeur). C est aussi durant cette phase ue peuvent se produire des événements en rapport avec une migration des données ou la durée de conservation : renouvellement des supports, transfert vers d autres matériels, logiciels ou applications, transfert aux archives et destruction des pièces à la fin de la durée de conservation. Dans certains cas exceptionnels, le dossier électroniue peut être utilisé de manière plus active, notamment dans le cadre d un réexamen de la demande, d un recours ou d une procédure pour atteinte. 5.4 RÈGLES À RESPECTER La présente section expose et définit les règles à respecter aux fins de la gestion des pièces électroniues pendant tout le cycle de vie du dossier de propriété intellectuelle. Elle porte sur les éléments suivants : acuisition des pièces piste de contrôle métadonnées copie de sauvegarde et récupération gestion des fichiers conservation des dossiers et des pièces préservation de l intégrité migration protection du caractère confidentiel transfert aux archives contrôles d accès et authentification pièces en attente de classement recherche, extraction et reproduction

Annexe 5, page 55 5.4.1 Acuisition des pièces La saisie par les systèmes informatiues des offices de propriété intellectuelle s appliue à tous les documents d information remplissant les critères reuis pour constituer un exemplaire original, y compris aux pièces reçues ou créées par la voie électroniue et à celles ui, reçues sur papier ou microfilm, ont été mises sur support électroniue. Si l on veut obtenir une pièce électroniue précise et complète, c est-à-dire une pièce dont le contenu, la structure et le contexte ont été préservés, il est impératif ue le processus d acuisition se déroule dans des conditions optimales. 5.4.1.1 Saisie de pièces électroniues complètes Il faut ue la pièce électroniue soit complète pour pouvoir a) disposer d une copie fiable de tous les éléments de la pièce ui ont été saisis et b) procéder à son traitement et à son transfert à long terme. Il convient de procéder comme suit : Fournir, aux fins de la saisie, toutes les pièces électroniues reçues ou créées remplissant les conditions prévues pour constituer un exemplaire original et verser ces pièces à un dossier électroniue de propriété intellectuelle. Ces pièces peuvent comprendre : des documents remis par le déposant; des mesures prises par un examinateur de l office concerné; des communications entre l examinateur et le déposant, y compris par courrier électroniue; des fichiers de travail ui doivent être conservés; d autres documents d information ui doivent être conservés. Faire en sorte ue l acte de verser un document d information en matière de propriété intellectuelle, en tant u exemplaire uniue, à un dossier constitue un acte distinct, conscient et vérifiable. Saisir le contenu, la structure et le contexte de chaue pièce. Saisir les pièces complémentaires et les additifs comme des pièces distinctes de telle sorte ue celles-ci ne modifient pas la pièce à lauelle elles sont liées. Lier de manière logiue la pièce supplémentaire ou l additif à l exemplaire original concerné. Saisir les métadonnées ui sont liées au dossier et aux pièces électroniues et ui jouent un rôle dans la recherche, l extraction, le routage, le caractère confidentiel, le transfert et la conservation (voir le paragraphe 4.2 relatif aux métadonnées). Élaborer des normes sur les formats de fichier aux fins de la réception, de la création et du stockage des pièces ui peuvent faire l objet d un traitement ou d un transfert pendant toute la durée de leur conservation. En cas de saisie de la même pièce sous différentes présentations (même contenu mais format de fichier différent (MS Word ou présentation XML)), le contenu, la structure et le contexte doivent être identiues.

Annexe 5, page 56 5.4.1.2 Saisie des liens renvoyant à des notes ou des annotations Il convient de procéder comme suit : Saisir les notes et les annotations comme des suites logiues de la pièce et veiller à ce u elles n en modifient ni le contenu, ni la structure. Permettre aux utilisateurs de placer des notes ou des annotations sur le document aux endroits intéressants. Mémoriser l emplacement de l annotation de la même manière u un signet. Faire en sorte ue la pièce électroniue puisse être affichée à l écran ou reproduite à tout moment sans les notes, ni les annotations. 5.4.1.3 Saisie des hyperliens Il convient de procéder comme suit : Saisir les hyperliens d une pièce électroniue ui renvoient à une autre partie de la même pièce. Saisir les hyperliens d une pièce électroniue ui renvoient à d autres pièces électroniues du même dossier. Faire en sorte u aucun hyperlien ne puisse être établi avec des pièces électroniues ne faisant pas partie du dossier concerné à moins u une méthode ait été mise au point pour actualiser les hyperliens lorsue le lieu de stockage change ou u une modification est apportée à la pièce ou à l hyperlien. 5.4.1.4 Fichiers de travail Les fichiers de travail ui doivent être conservés en tant u exemplaire originaux doivent être saisis. Ceux ui contiennent des avant-projets ou des brouillons, ou d autres documents similaires, devraient être conservés à titre de documentation lorsue ils ont circulé parmi des employés (autres ue leur auteur) d un office de propriété intellectuelle, ou ils ont été mis à la disposition de ceux-ci, à des fins officielles (pour approbation, observations, suite à donner, suivi) ou en vue d informer le personnel de cet office sur les activités de celui-ci; ils contiennent des informations uniues, telles ue des annotations ou des observations de fond, ui permettent de mieux comprendre la formulation et l application, par l office concerné, de politiues, décisions ou mesures fondamentales ainsi ue la définition et l attribution de responsabilités. Les fichiers de travail électroniues sont gérés indépendamment du dossier jusu à ce u ils constituent des exemplaires originaux ui sont alors versés au dossier et gérés à ce titre. Il convient de procéder comme suit : Élaborer une procédure permettant de faire d un fichier de travail un exemplaire original. Recourir au contrôle de la version pour saisir et suivre l historiue de la création des fichiers de travail et lier les nouvelles pièces aux pièces précédentes.

Annexe 5, page 57 5.4.1.5 Conversion des pièces sur support papier en pièces électroniues Lorsue des documents d information sur support papier doivent être convertis en documents électroniues, il convient de suivre certaines règles afin ue ces documents soient saisis avec précision dans leur intégralité. Pour ue la procédure soit fiable, il convient de procéder comme suit : S assurer ue la résolution utilisée aux fins de la saisie de l image est suffisamment élevée pour fournir une copie de l original ui soit lisible, utilisable et reproductible. S assurer, à l aide d un contrôle de la ualité strict, ue les pièces ont été saisies avec précision dans leur intégralité. Soumettre régulièrement les scanners à des contrôles afin de vérifier u ils fonctionnent conformément aux directives du fabricant et u ils fournissent le niveau de ualité voulu. Prévoir une procédure permettant de scanner à nouveau les documents ui, après vérification, ne sont pas de la ualité voulue ou apposer sur les documents, avant le scannage, la mention pas de meilleur exemplaire. Repérer le numéro de lot des documents saisis et des documents sur papier afin de localiser ceux ui parmi eux ne sont pas de la ualité voulue. 5.4.1.6 Contrôle de la ualité Le contrôle de la ualité doit faire partie intégrante de la procédure de saisie des pièces, ue celles-ci aient été scannées ou acuises automatiuement par la voie électroniue. Il convient de respecter les règles suivantes : Dans le cas de la procédure de saisie, procéder à un contrôle de la ualité sur un échantillon de pièces électroniues, ue celles-ci aient été scannées ou acuises par la voie électroniue. La taille de l échantillon dépendra a) de la ualité des documents source, ui sera plus élevée pour les documents scannés et moins élevée pour ceux ui ont été acuis par la voie électroniue et b) du taux d erreurs observé pendant le contrôle de la ualité. La périodicité de prélèvement d échantillons doit être fonction du taux d erreurs observé par échantillon durant la procédure de contrôle de la ualité. Pour les pièces saisies d après support papier, le contrôle de la ualité doit permettre de s assurer ue les informations tirées du document original sont précises, complètes et lisibles. Lorsu une machine de lecture optiue des caractères est utilisée pour convertir des documents scannés en documents lisibles par ordinateur, le texte ainsi converti doit être soumis à un contrôle de la ualité méticuleux. Pour les pièces d origine électroniue, le nombre d échantillons sera inférieur à celui ui est prévu pour les pièces saisies d après support papier sous réserve ue les échantillons antérieurs se soient révélés suffisamment précis et complets.

Annexe 5, page 58 5.4.1.7 Assurance de la ualité Outre le contrôle de la ualité, l office de propriété intellectuelle concerné doit mettre en place une assurance de la ualité afin de s assurer ue toutes les pièces ont été saisies de manière précise et fiable. Le nombre d échantillons est, en général, inférieur à celui ui est prévu pour le contrôle de la ualité, à moins ue le niveau de la ualité des pièces saisies justifie une augmentation de ce nombre. Il convient de procéder comme suit : Appliuer régulièrement les principes de l assurance de la ualité finale pour s assurer ue toutes les pièces et les métadonnées connexes ont été saisies avec précision et de manière fiable. Faire en sorte ue ce soit l office concerné ui mette en œuvre la ualité finale, notamment lorsu un tiers a été chargé, par contrat, de procéder à la saisie des pièces et au contrôle de la ualité. 5.4.1.8 Vérifications Des membres du personnel de l office de propriété intellectuelle concerné devraient régulièrement vérifier la procédure de saisie des documents afin de s assurer ue tous les principes directeurs et règles sont appliués et ue l office a acuis des pièces et des métadonnées connexes ui sont à la fois précises et fiables. Procéder régulièrement à une vérification de tous les éléments faisant partie de la procédure de saisie des documents et adapter en conséuence les procédures de balayage ainsi ue de contrôle et d assurance de la ualité. 5.4.2 Métadonnées Les métadonnées relatives aux pièces peuvent être définies comme étant des données décrivant des objets de données, c est-à-dire des données décrivant le schéma ou la structure d éléments de données, le lien entre ces éléments de données, et d autres caractéristiues des données de pièces électroniues. Pendant longtemps, le terme métadonnée a servi à décrire l information permettant de rechercher et d extraire des documents imprimés (sur papier ou sur microfilm) ou électroniues. Les métadonnées comprennent d autres informations, notamment sur les formats de fichier et les sources de création ui doivent être acuis et conservés aux fins d une gestion efficace des pièces électroniues. 5.4.2.1 Gestion des métadonnées Les pièces relatives à des demandes de titre de propriété intellectuelle sont gérées dans le cadre de dossiers sur support papier ou électroniues. Les métadonnées permettant d avoir accès aux pièces électroniues, ou de procéder à une vérification ou à un transfert de celles-ci, doivent aussi être gérées

Annexe 5, page 59 dans le cadre du dossier. Il est recommandé d intégrer ces métadonnées au dossier électroniue ou de les encapsuler dans celui-ci. 5.4.2.1.1 Conservation des métadonnées Les principes de gestion des dossiers et pièces électroniues à conserver s appliuent aussi aux métadonnées connexes. L un des principes fondamentaux à respecter pour pouvoir avoir accès aux métadonnées et conserver celles-ci à long terme est de prévoir la même durée de conservation pour les métadonnées ue pour le dossier et les pièces électroniues. Cela suppose ue toutes les métadonnées liés aux dossiers et aux pièces soit conservées avec précision dans leur intégralité grâce à des renouvellements de support, des transferts vers de nouveaux matériels, logiciels ou applications et des transferts aux archives. 5.4.2.1.2 Types de métadonnées Il est recommandé d opter pour les types de métadonnées ci-après ainsi ue de définir, acuérir et conserver des éléments de métadonnées dans les domaines suivants : Types Dossier et Pièces de dossier : on classe dans cette catégorie les métadonnées nécessaires au stockage, à la recherche et à l extraction, à l accès aux documents et pièces confidentiels et au suivi. Type historiue de l utilisation (voir le paragraphe 4.8 sur la piste de contrôle) : ce type de métadonnées permet d obtenir une piste de contrôle des événements et opérations (p. ex. : accès à des dossiers électroniues de propriété intellectuelle ou migration de ceux-ci) aux fins suivantes : a) établissement de la fiabilité des dossiers et pièces électroniues de propriété intellectuelle; b) établissement de l authenticité des pièces à des fins de recevabilité comme preuves; et c) recherche des événements prouvant ue l intégrité a été préservée ou ue le caractère confidentiel a été respecté. Types Copie, Reformatage et Transfert : ces types de métadonnées permettent d obtenir des informations sur la copie ou le reformatage de dossiers électroniues en vue d un renouvellement des supports, d un transfert vers de nouveaux matériels, logiciels ou systèmes informatiues ou d un transfert aux archives. Ces types de métadonnées ne permettent pas de définir comment chaue élément de métadonnée doit être saisi. Toutefois, il repose sur le principe ue de nombreux éléments de métadonnée, tels ue ceux des types Dossier ou Pièces de dossier, peuvent être acuis automatiuement à partir des systèmes informatiues de l office de propriété intellectuelle concerné. Bon nombre d autres éléments de métadonnée, tels ue les dates d accès, peuvent être obtenus automatiuement à partir du système informatiue ou, en dernier lieu, par entrée manuelle des données.

Annexe 5, page 60 5.4.2.1.3 Encapsulation dans les dossiers Il est recommandé, afin de faciliter les transferts et les migrations, d encapsuler toutes les informations sur les métadonnées dans le dossier électroniue de propriété intellectuelle. En procédant de la sorte, on obtient un objet numériue uniue, ui contient les éléments permettant d accéder au dossier et de suivre l évolution de celui-ci. L encapsulation facilite aussi le recensement des données ui feront l objet d une migration en cas de renouvellement des supports ou du transfert des dossiers. L encapsulation peut être logiue ou physiue. Encapsulation logiue : relie toutes les pièces, annotations, notes et types de métadonnées contenus dans un dossier pour en faire un objet numériue uniue logiue. Toutefois, les pièces et métadonnées ayant trait à un dossier peuvent se trouver sur différents serveurs de stockage ou dans différents volumes d un même support. Si l encapsulation logiue constitue la méthode la plus souple de stockage, il n en reste pas moins u elle crée un environnement de gestion complexe et, partant, augmente les risues de perte ou d altération des données lors d un renouvellement des supports ou d un transfert de dossiers. Encapsulation physiue : dans ce cas, toutes les informations relatives à un dossier électroniue particulier, c est-à-dire les pièces, les annotations et notes connexes, les métadonnées, les liens entre dossiers ou pièces et les liens au sein d un même dossier ou d une même pièce, constituent un objet physiue ou une entité uniue localisé dans un même volume du support. L encapsulation physiue, ui fournit l environnement le plus simple possible aux fins du renouvellement des supports et du transfert de dossiers, pose uelues problèmes en ce ui concerne les ressources à mettre en œuvre pour maintenir les métadonnées encapsulées dans le dossier et le temps à consacrer à cette tâche. 5.4.2.2 Métadonnées de types Dossier et Pièces de dossier Les métadonnées ont pour objet, entre autres, de permettre au personnel autorisé d extraire les pièces électroniues facilement et efficacement. Certaines métadonnées sont appelées données de type. Les métadonnées de types Dossier et Pièces de dossier comprennent les informations suivantes : identificateur uniue pour chaue dossier et chaue pièce du dossier concerné; sujet ou titre du dossier ou de la pièce; auteur ou origine de la pièce; raison pour lauelle la pièce a été créée, date à lauelle elle a été créée et mode de création; exactitude des données de base; modularité de la source; phase du traitement; historiue de l utilisation; ualité et étendue ou portée des ressources. Les règles ci-après s appliuent à la saisie et à la gestion des métadonnées aux fins de l extraction de pièces électroniues :

Annexe 5, page 61 Attribuer à chaue dossier électroniue et à chaue pièce de dossier au moins un identificateur de métadonnée uniue ui les différencie des autres dossiers ou pièces électroniues. Encapsuler les métadonnées de types Dossier et Pièces de dossier dans le dossier électroniue aux fins d une gestion efficace de la conservation et des migrations (voir ci-dessous). Utiliser les systèmes informatiues de l office concerné comme première source de métadonnées de types Dossier et Pièces de dossier. Utiliser les systèmes informatiues de l office concerné pour la recherche et l extraction de dossiers et pièces électroniues. Établir un lien entre les bases de données de l office concerné et les dossiers électroniues. Définir une procédure permettant de n extraire u un certain type de pièces dans un même dossier électroniue. Faire en sorte ue les pièces sur support papier et autres documents non électroniues soient assimilés à traiter un type de pièces de dossier afin ue leur recherche demeure simple, c est-à-dire u il soit possible en une seule fois de recenser toutes les pièces disponibles, uel ue soit leur support ou leur lieu de stockage. Utiliser les métadonnées de type Dossier pour indiuer le caractère confidentiel de certaines pièces auxuelles ne pourront pas accéder les utilisateurs non autorisés. Si possible, indexer automatiuement toutes les pièces reçues ou créées conformément à un système de dépôt des dossiers électroniues ui sera mis au point, au sein de l office de propriété intellectuelle concerné, sur la base des métadonnées de types Dossier et Pièces de dossier. Aux fins de la recherche groupée, autoriser la recherche par champs communs de métadonnées prédéterminées (numéro de la demande, sujet, date, auteur, type de pièce ou numéro du formulaire et code de disposition). N autoriser aucune modification des métadonnées d un dossier électroniue ou des métadonnées encapsulées dans un dossier électroniue à moins ue ces métadonnées ne contiennent des erreurs à corriger. Si des corrections doivent être apportées aux métadonnées (à la suite d erreurs s étant produites pendant la saisie automatiue ou manuelle des données), laisser uniuement les membres du personnel autorisés accéder aux programmes de modification ou aux outils permettant de corriger des métadonnées. Toute modification doit être répercutée dans les métadonnées de type Historiue de l utilisation, sous la forme d une piste de contrôle. 5.4.2.2.1 Métadonnées de type Dossier Les recommandations relatives aux métadonnées de types Dossier et Pièces de dossier ont pour fondement les principes appliués au dépôt, à la recherche et à la destruction des pièces électroniues de propriété intellectuelle. Les éléments de données comprenant les métadonnées de type Dossier traitent les informations clés sur le dossier comme une entité logiue à lauelle il est possible d accéder et ui peut faire l objet d une conservation à long terme. Ces éléments de données ne peuvent plus être modifiés une fois u ils ont été enregistrés dans le dossier. Il ne peut y avoir modification après autorisation des

Annexe 5, page 62 métadonnées de type Dossier ue lorsue celui-ci est mis à jour (correction d une erreur), u un titre de propriété intellectuelle a été délivré, enregistré ou abandonné (cession de droits ou réexamen), ue le lieu de stockage change ou ue les dates d accès sont transférées depuis chaue pièce. EXEMPLE DE MÉTADONNÉES DE TYPE DOSSIER Identificateur uniue Type de fichier - Brevet Sujet du fichier Déposant* (peut être modifié à la suite d un changement d avocat ou d agent) Inventeur(s)* (peut être modifié à la suite d une cession) Date de dépôt Date de fermeture (marue le début de la période de conservation autorisée) Code relatif à la situation juridiue de la demande (en instance, titre publié ou titre enregistré, demande abandonnée) Représentation - Binaire - ASCII - UNICODE Cryptage du dossier (facultatif, selon ue de besoin) - Nom de l algorithme utilisé - Nom du logiciel et numéro de la version utilisés Formats utilisés - Texte - Image - Mixte (texte + image) - Base de données Formats de fichier utilisés - TIFF (V6.0 avec compression de groupe 4, monoruban, en codage Intel, 200, 300 ou 400 dpi, taille maximale A4 ou format commercial) - JPEG - PDF (compatible Acrobat version 3, texte non comprimé, texte non crypté, pas d objets incorporés en OLE, toutes polices de caractères, spécification PS 17 ou construite à partir des polices de caractères ADOBE NM) 1 1 Le format PDF peut être utilisé lorsu il permet un archivage à long terme par l office de propriété intellectuelle concerné.

Annexe 5, page 63 - XML (jeu de caractères Unicode UCS-2 (ISO/IEC 10646 :193) codé UTF-8 ou JIS-X0208 codé ISO-2022-JP; pour demandes PCT, caractères chinois GB2312 ou coréens KSC 5601 aussi acceptés) - SGML - Autres (p. ex. : unités de travail complexes) Taille du dossier - Longueur d article logiue - Nombre d articles logiues* - Nombre d articles physiues* - Nombre d octets* - Nombre total de pièces* Authentification du dossier (si nécessaire) - Contrôle de redondance cycliue (CRC) - Valeur de hachage Mise à jour après la mise en instance de la demande - Cession - Réexamen - Changement d adresse - Etc. Liste de dates d accès ou d événements* - Date de l accès ou de l événement - Type d accès ou d événement - Identification de l utilisateur consultant la liste d accès ou d événements Emplacement du dossier* - Instruction en cours et utilisation - Mise à jour et utilisation - Archives Emplacement des pièces sur support papier ou sur microfilm en rapport avec le dossier Destruction* - Code d instruction - Date d action *Indiue ue la mise à jour de la métadonnée correspondante est autorisée 5.4.2.2.2 Métadonnée de type Pièces de dossier Les éléments de données comprenant les métadonnées de type Pièces de dossier traitent les informations clés sur chaue pièce comme une entité logiue pouvant être utilisée individuellement ou collectivement aux fins de la gestion des pièces. Ainsi, l identificateur uniue de pièce permet

Annexe 5, page 64 d accéder directement à la pièce et l élément date de l accès ou de l événement contient toutes les occurrences d accès à la pièce en uestion ou d opérations en rapport avec cette pièce. Une date particulière peut figurer dans les métadonnées de type Historiue de l utilisation et indiuer si l accès correspond à une mise à jour, un reformatage, une copie ou un transfert. Aucun de ces éléments de données ne peut être modifié une fois ue la pièce est devenue partie intégrante du dossier. Il ne peut y avoir modification des métadonnées de type Pièces de dossier u aux fins de l adjonction d une date. Un astérisue ( * ) permet de signaler cette possibilité. EXEMPLE DE MÉTADONNÉES DE TYPE PIÈCES DE DOSSIER Identificateur uniue de dossier Identificateur uniue de pièce (p. ex. : numéro d ordre) Descripteur de pièce (numéro de formulaire, indication codée alphabétiue) Date de réception ou de création Nom du destinataire Sujet Organisme émetteur Auteur Niveau de sécurité (demande en instance, titre délivré) Représentation - Binaire - ASCII - UNICODE Cryptage du dossier (facultatif, selon ue de besoin) - Nom de l algorithme utilisé - Nom du logiciel et numéro de la version utilisés Formats utilisés - Texte - Image - Mixte (texte + image) - Base de données Formats de fichier utilisés - IFF (V6.0 avec compression de groupe 4, monoruban, en codage Intel, 200, 300 ou 400 dpi, taille maximale A4 ou format commercial) - JPEG

Annexe 5, page 65 - PDF (compatible Acrobat version 3, texte non comprimé, texte non crypté, pas de signature numériue, pas d objets incorporés en OLE, toutes polices de caractères, spécification PS 17 ou construite à partir des polices de caractères ADOBE NM) 2 - XML (jeu de caractères Unicode UCS-2 (ISO/IEC 10646 :193) codé UTF-8 ou JIS-X0208 codé ISO-2022-JP; pour demandes PCT, caractères chinois GB2312 ou coréens KSC 5601 aussi acceptés) - SGML - Autres (p. ex. : unités de travail complexes) Taille de la pièce en octets Authentification du dossier (si nécessaire) - Contrôle de redondance cycliue (CRC) - Valeur de hachage Dates d accès ou d événements* - Date de l accès ou de l événement - Type d accès ou d événement - Identification de l utilisateur consultant la liste d accès ou d événements *Indiue ue des mises à jour sont autorisées 5.4.3 Gestion des dossiers Le système de gestion des dossiers doit permettre de protéger l intégrité physiue et référentielle des données et pièces électroniues ainsi ue des métadonnées connexes pendant tout leur cycle de vie. Il doit empêcher u une pièce électroniue et ses métadonnées puissent être écrasées par réécriture ou effacées par inadvertance. Le système doit aussi permettre d accéder aux dossiers, pièces électroniues et métadonnées pendant toute la durée de leur conservation, uel ue soit le mode de stockage (numériue, sur papier ou sur microfilm). Il convient de respecter les règles suivantes : Le système de gestion des fichiers doit empêcher ue les dossiers ou pièces électroniues et les métadonnées connexes soient écrasées par réécriture ou effacées par inadvertance. Grâce au contrôle d accès, seuls l employé chargé de la gestion des pièces ou toute personne ayant des fonctions éuivalentes peuvent détruire des pièces électroniues et des métadonnées connexes. À des fins d accès, il convient de créer un lien uniue ou de mettre en place un pointeur entre les systèmes informatiues de recherche et de suivi de l office concerné, le répertoire de gestion des fichiers ou les métadonnées relatives à cette gestion et le lieu de stockage des dossiers ou pièces électroniues. 2 Le format PDF peut être utilisé lorsu il permet un archivage à long terme par l office de propriété intellectuelle concerné.

Annexe 5, page 66 Aux fins de la réalisation de la copie de sauvegarde des dossiers et pièces électroniues et des métadonnées connexes, il convient d établir un lien ou de mettre en place un pointeur entre les systèmes informatiues de recherche et de suivi, le répertoire de gestion des fichiers ou les types de métadonnées et le lieu de stockage des dossiers et pièces électroniues et des métadonnées connexes. Il convient de saisir les métadonnées permettant de localiser une pièce d un dossier, ui sont présentées de manière matérielle ou sur support matériel (p. ex. : disue compact ROM). En ce ui concerne la gestion des supports de stockage, voir le paragraphe 4.11.2 sur la gestion des supports. 5.4.4 Préservation de l intégrité On entend par respect de l intégrité le fait de veiller à la cohérence des données notamment en évitant (et en décelant) la modification ou la destruction non autorisées de données. La préservation de l intégrité des pièces de propriété intellectuelle est essentielle à la protection des droits de propriété intellectuelle et de la valeur des actifs de l auteur de l invention. En conséuence, des contrôles doivent être mis en place pour assurer la préservation de l intégrité, de l authenticité et de la fiabilité des dossiers de l office de propriété intellectuelle au fil du temps. Cet objectif peut être atteint grâce à une gestion des pièces électroniues ui vise à les protéger de toute perte, de tout déplacement ou de toute modification ou destruction non autorisée. Et il importe d autant plus de prévoir des contrôles pour protéger et préserver de manière adéuate les pièces électroniues ue les preuves de falsification risuent de ne pas être aussi faciles à établir pour les pièces électroniues ue pour des pièces sur papier. 5.4.4.1 Protection contre des modifications Il convient de respecter les règles suivantes : L accès aux dossiers et pièces électroniues devrait être fondé sur le principe du moindre privilège, c est-à-dire défini selon le rôle ou les fonctions de la personne concernée. Aucune modification du contenu, de la structure ou du contexte d une pièce versée à un dossier électroniue ne doit être possible. L intégrité de chaue pièce doit être préservée pendant toute la durée de conservation du dossier. Les annotations et additifs concernant un dossier ou une pièce électroniue doivent aussi être protégés de toute modification ou perte et traités comme des données séparées mais liées de manière logiue à la pièce de telle sorte ue celle-ci puisse être affichée à l écran ou reproduite sous la forme sous lauelle elle a été stockée. Aucune modification des métadonnées associées à un dossier ou une pièce électroniue, ou encapsulées dans ce dossier ou dans cette pièce, ne doit être possible sauf lorsue ces métadonnées contiennent des erreurs ui doivent être corrigées. Lorsue des métadonnées doivent être corrigées (à la suite, par exemple, d erreurs introduites au cours de l acuisition automatiue ou manuelle des données), l accès aux programmes de

Annexe 5, page 67 modification et aux outils de correction, et l utilisation de ces programmes et outils, doit être limité et placé sous le contrôle de membres du personnel autorisés expressément à les utiliser. Ces corrections doivent figurer dans une piste de contrôle incorporée dans les métadonnées de type Historiue de l utilisation. Lorsu une pièce électroniue est créée sur la base d une autre pièce électroniue, elle doit être versée au dossier électroniue et assortie de nouvelles métadonnées de type Pièces de dossier. Les contrôles de la version (p. ex. : procédures de vérification ou d enregistrement) doivent permettre de s assurer ue la pièce électroniue originale n a pas été modifiée. L accès aux programmes ou fonctions servant à détruire les dossiers ou pièces électroniues à la fin de la période de conservation autorisée (y compris les pièces complémentaires, les annotations et les métadonnées) devrait être limité aux personnes spécialement désignées par le fonctionnaire chargé de la sécurité des systèmes informatiues ou tout employé ayant des fonctions éuivalentes et à certaines fonctions système. 5.4.4.2 Validation de l intégrité Il convient de respecter les règles suivantes : Toute pièce électroniue doit comporter certains attributs (p. ex. : contrôle de redondance cycliue (CRC) ou haché de signature numériue), permettant de valider l intégrité de la pièce au moment de sa réception ou de sa création et à chaue accès, et de détecter toute tentative de modification ou toute modification de la pièce. Toute validation d intégrité doit être enregistrée dans les métadonnées de type Historiue de l utilisation. 5.4.5 Protection du caractère confidentiel En donnant à un document le caractère confidentiel, on s assure ue l information u il contient ne sera ni divulguée, ni révélée à une personne non autorisée. On range dans cette catégorie de documents les pièces électroniues concernant des demandes de brevet en instance ou des brevets abandonnés et leurs métadonnées, sauf lorsue le brevet abandonné est désigné dans un brevet délivré. Le caractère confidentiel ne s appliue pas aux pièces concernant les marues. Il est essentiel de maintenir le caractère confidentiel des dossiers ou pièces relatifs à des demandes de brevet en instance ou des brevets abandonnés car l information ui y figure ne doit pas être divulguée et constitue un actif de propriété intellectuelle important pour le titulaire. Les règles ci-après visent uniuement à protéger le caractère confidentiel des dossiers et pièces concernant des demandes de brevet en instance ou des brevets abandonnés : Utiliser le cryptage pour protéger le caractère confidentiel des pièces électroniues et des métadonnées connexes lors de leur transmission. Protéger le caractère confidentiel des pièces électroniues au cours de la révision, du préexamen, de l examen et des étapes de la publication ainsi ue celui des brevets abandonnés dont le dossier est conservé, et s assurer ue le contenu de ces pièces et dossiers n est pas divulgué ou révélé à des

Annexe 5, page 68 personnes non autorisées. Indiuer dans un champ de métadonnée ue le dossier électroniue a un caractère confidentiel. Restreindre l accès aux pièces confidentielles sur la base du principe du moindre privilège, c est-à-dire selon les fonctions ou le rôle de la personne concernée. Empêcher tout accès non autorisé aux supports autonomes contenant des pièces à caractère confidentiel. 5.4.6 Contrôles d accès et authentification Les contrôles d accès (identification) et l authentification (validation de l identité) jouent un rôle fondamental dans la protection du caractère confidentiel et la préservation de l intégrité des dossiers et pièces électroniues. Ils visent à empêcher tout affichage à l écran, modification ou destruction non autorisé et, en général, toute exécution non autorisée de commandes. Les contrôles d accès doivent être fondés sur le principe du moindre privilège, les utilisateurs ne pouvant accéder u aux dossiers et pièces électroniues, et aux annotations et métadonnées connexes, dont ils ont véritablement besoin dans l exercice de leurs fonctions ou pour s acuitter de leurs tâches. Les contrôles permettent de limiter l accès à des dossiers ou pièces électroniues, aux opérations ou événements en relation avec des dossiers électroniues ainsi u aux ressources informatiues liées à la migration ou à l épuration. Il convient de procéder comme suit : Mettre en place des contrôles d accès et un système d authentification, sous la forme par exemple de paire de clés publiues ou privées, permettant d identifier l expéditeur, l auteur ou l utilisateur de la pièce. Identifier chaue utilisateur au moment où il entre dans le système informatiue ui reçoit, crée, traite, met à jour ou gère les dossiers et pièces électroniues de l office concerné. Prévoir, par le biais des contrôles et procédures d accès, une limitation de l accès, aux dossiers et pièces électroniues sur la base du principe du moindre privilège, c est-à-dire selon les fonctions ou le rôle de l utilisateur, ainsi u aux ressources informatiues relatives à l état du dossier. Limiter strictement l accès aux systèmes informatiues, aux fonctions informatiues ou aux ressources informatiues permettant de modifier les métadonnées, de créer de nouvelles versions du même document ou d épurer (supprimer) les dossiers électroniues et les métadonnées connexes. Utiliser une piste de contrôle pour récapituler tous les événements concernant l accès aux pièces, y compris les tentatives d accès non autorisé. 5.4.7 Recherche, extraction et reproduction 5.4.7.1 Recherche et extraction Il doit être possible, après autorisation, d effectuer une recherche dans tous les dossiers et pièces, u ils soient stockés sur un support en ligne, uasi en ligne ou autonome.

Annexe 5, page 69 Les options de recherche doivent comprendre la recherche d un dossier particulier dans les métadonnées; la recherche d une pièce donnée dans un dossier. D autres types de recherche doivent être possible : l appariement d expressions (p. ex. : animal et animaux); la recherche booléenne (p. ex. : eau ET H 2 O); les expressions du langage relationnel SQL (p. ex. : comme, contient). 5.4.7.2 Enregistrement des résultats de la recherche Les utilisateurs doivent pouvoir enregistrer les résultats de la recherche (p. ex. : établissement de la liste de tous les documents de propriété intellectuelle ui ont été examinés lors d un processus de recherche s inscrivant dans le cadre de l examen d une demande de titre de propriété intellectuelle). Les utilisateurs doivent pouvoir enregistrer temporairement puis extraire les résultats de la recherche jusu à ce ue la tâche confiée ait été menée à bien ou ue l événement soit terminé. 5.4.7.3 Affichage à l écran et impression de la pièce, de l index et des annotations Chaue pièce doit, pendant tout son cycle de vie, pouvoir faire l objet d une copie lisible par l homme (affichage à l écran ou copie papier). Les options concernant l affichage à l écran et l impression doivent comprendre l une des combinaisons suivantes : affichage ou impression de la pièce; affichage ou impression des annotations; affichage ou impression des métadonnées du dossier ou de la pièce du dossier. Les notes et les annotations doivent être distinctes de la pièce. Il doit être possible d imprimer et d afficher la pièce avec les annotations ui y figurent, avec les annotations ui ont été effectuées après l impression de la pièce ou sans les annotations. Il convient de prévoir des fonctions de zoom avant et de zoom arrière pour les textes et les graphiues difficiles à lire. 5.4.7.4 Accès par le déposant Lorsu il est possible d accéder aux dossiers et pièces électroniues et aux métadonnées, des mesures doivent être prises pour ue les déposants n accèdent u aux documents u ils sont autorisés à consulter. L intégrité du dossier et des pièces électroniues ainsi ue des métadonnées doit être préservée tout comme le caractère confidentiel des demandes de brevet en instance. Il convient de respecter les règles suivantes : Le déposant doit pouvoir être identifié, de préférence au moyen d un certificat ou d une clé publiue. Le déposant ne doit pas pouvoir avoir accès à des dossiers, pièces ou métadonnées autres ue ceux u il est autorisé à consulter.

Annexe 5, page 70 L accès par un déposant doit être systématiuement enregistré dans les métadonnées de type Historiue de l utilisation sous la forme d une piste de contrôle. 5.4.8 Piste de contrôle La piste de contrôle, ou journal des événements, est une chaîne des dépositaires ui indiue l auteur et la nature de chaue acte ou événement ainsi ue le moment où cet acte ou cet événement a eu lieu. Par événement, on peut entendre la création, la réception, le traitement, la consultation, la diffusion, la migration, le transfert ou la destruction d un dossier électroniue de propriété intellectuelle. La piste de contrôle enregistre les métadonnées attestant des intentions manifestées et du résultat des actes effectués en rapport avec des dossiers ou pièces électroniues. Elle constitue un élément de preuve (contrôlée par un ordinateur et non par l homme) ue les politiues et procédures ont été suivies et ue l intégrité et le caractère confidentiel de l information ont été respectés. D un point de vue juridiue, la piste de contrôle peut aussi être utilisée pour prouver, aux fins de recevabilité devant un tribunal, ue l authenticité d une pièce a été préservée. Il est recommandé ue l information sur la consultation et des événements en rapport avec des dossiers de propriété intellectuelle provenant d une piste de contrôle soient étayés par les métadonnées de type Historiue de l utilisation. 5.4.8.1 Métadonnée de type Historiue de l utilisation Ainsi u il est indiué dans le paragraphe 4.2.1.2 sur les types de métadonnées, il est recommandé de créer, pour chaue dossier de propriété intellectuelle, des métadonnées de type Historiue de l utilisation, et de les encapsuler dans le dossier électroniue en tant ue piste de contrôle des accès au dossier et des événements concernant celui-ci. Les métadonnées de type Historiue de l utilisation enregistrent les accès et les événements (tels ue les transferts de dossiers électroniues). Elles permettent ainsi a) d établir la fiabilité des dossiers et pièces électroniues de propriété intellectuelle, b) de définir la mesure dans lauelle le test d authentification est recevable en tant ue preuve, notamment lors d appels, et c) de rechercher les événements prouvant ue l intégrité a été préservée, ue le caractère confidentiel a été protégé, ue les procédures du système ont été suivies et ue la gestion des pièces électroniues a été effectuée de manière fiable. Il est recommandé d introduire les métadonnées de type Historiue de l utilisation suivantes : EXEMPLE DE MÉTADONNÉES DE TYPE HISTORIQUE DE L UTILISATION Identificateur uniue de dossier Date de l événement ou de l opération (niveau reproductible) Dates d accès (niveau reproductible) Reformatage (niveau reproductible)

Annexe 5, page 71 - Date - Numéro d itération du reformatage - Taille logiue de la pièce - Nombre logiue de pièces - Nombre d octets - CRC (le cas échéant) - Valeur de hachage (le cas échéant) Copie (niveau reproductible) - Date - Numéro d itération de la copie - Nombre de pièces logiues - Nombre d octets - CRC (le cas échéant) - Valeur de hachage (le cas échéant) Transfert (niveau reproductible) - Date - Numéro d itération du transfert - Nombre logiue de pièces - Nombre d octets - CRC (le cas échéant) - Valeur de hachage (le cas échéant) Épuration ou suppression (facultatif) - Date - Autorisation 5.4.8.2 Création et mise à jour de métadonnées de type Historiue de l utilisation Il convient de procéder comme suit : Insérer une métadonnée de type Historiue de l utilisation au moment où la demande de titre de propriété intellectuelle est déposée et conserver l événement dépôt dans le type Historiue de l utilisation. Enregistrer l accès au dossier électroniue dans les métadonnées de type Historiue de l utilisation.

Annexe 5, page 72 Conserver dans les métadonnées de type Historiue de l utilisation chaue événement concernant la réception, la création, la mise à jour, la destruction de documents ou la constitution de documents concernant l instruction ou la mise à jour d un dossier de propriété intellectuelle. Conserver chaue événement relatif à une copie, un reformatage ou un transfert dans les métadonnées de type Historiue de l utilisation. Enregistrer l acte de suppression et la date à lauelle celui-ci a eu lieu dans les métadonnées de type Historiue de l utilisation lorsue, à la fin d une période de conservation, des dossiers sont éliminés. Conserver dans les métadonnées les événements relatifs à un transfert de dossiers, au nombre de dossiers transférés et à la date à lauelle ces dossiers ont été transférés aux archives. 5.4.8.3 Liens avec d autres systèmes informatiues de recherche ou d enregistrement d événements Établir des liens avec les systèmes informatiues de recherche de l office concerné en vue d extraire ou de saisir des informations relatives à des événements de mise à jour (p. ex. : une nouvelle cession d un brevet). 5.4.9 Copie de sauvegarde et récupération Les dossiers de propriété intellectuelle sont considérés comme des documents fondamentaux, c est-à-dire u ils permettent de reconstituer les activités d un office de propriété intellectuelle au cas où une catastrophe endommagerait les dossiers électroniues primaires. Pour ue cette information fondamentale soit sauvegardée et puisse être mise à disposition, des politiues particulières doivent être définies et des procédures spéciales mises en œuvre. Il faut faire une copie de sauvegarde de tous les dossiers électroniues et des métadonnées connexes dans le cadre d un plan de secours. Il en va de même de tous les systèmes informatiues et logiciels d exploitation servant à gérer des dossiers électroniues. Il convient de procéder comme suit : Mettre au point des politiues et procédures de secours automatisées applicables aux dossiers électroniues, aux métadonnées, aux systèmes informatiues connexes et aux logiciels d exploitation. Faire une copie de sauvegarde de tous les dossiers et pièces électroniues et des métadonnées connexes. Faire une copie de sauvegarde de tous les logiciels d exploitation et systèmes informatiues ui traitent et tiennent à jour des dossiers ou pièces électroniues et des métadonnées connexes. Stocker toutes les copies de sauvegarde dans un lieu distinct de celui où se trouvent les documents primaires.

Annexe 5, page 73 Procéder à un étiuetage électroniue ou manuel (si besoin est) des copies de sauvegarde pour pouvoir localiser celles-ci rapidement. Élaborer des procédures et mettre en place des fonctions automatiues ou manuelles, selon ue de besoin, permettant de récupérer dans leur intégralité les dossiers et pièces électroniues et les métadonnées connexes à la suite d une catastrophe. Tenir à jour les métadonnées ou le répertoire de fichiers contenant les données nécessaires pour accéder à la fois à l original et à la copie de chaue dossier ou pièce électroniue ainsi ue de toute pièce sur support papier. Gérer de manière systématiue la conservation des copies de sauvegarde et des documents originaux, y compris la destruction des dossiers et pièces électroniues et des métadonnées connexes. Mettre les copies de sauvegarde en sûreté et à l abri, entre autres, des risues suivants : a) risues usuels (feu, eau, moisissure, rongeurs ou insectes), b) risues d origine humaine (vol, perte accidentelle, sabotage ou espionnage commercial), c) catastrophes (feu, inondation, tremblement de terre, tempête ou explosion) et d) utilisation, divulgation ou destruction non autorisées. 5.4.10 Conservation des dossiers et des pièces Les offices de propriété intellectuelle doivent faire en sorte ue les dossiers et pièces électroniues soient conservés aussi longtemps ue nécessaire. Les procédures de conservation doivent comprendre un calendrier de destruction de toutes les pièces électroniues et des documents et des tableaux connexes. L information figurant dans les pièces électroniues doit être recensée le plus tôt possible, c est-à-dire avant l expiration d un délai d un an à compter de la mise en œuvre du système. Des dispositions doivent être prises aux fins du transfert d une copie des pièces électroniues et des documents et tableaux annexes aux archives. Il convient aussi de définir des procédures de recopiage et de reformatage à appliuer régulièrement et des procédures d exécution des opérations nécessaires à la conservation et à l utilisation des pièces électroniues pendant tout leur cycle de vie. Le maintien de l intégrité des pièces de propriété intellectuelle joue un rôle fondamental dans la protection des droits de propriété intellectuelle et de la valeur des actifs commerciaux de l inventeur. Des contrôles et des bilans doivent donc être effectués aux fins de la préservation, au fil du temps, de l intégrité, de l authenticité et de la fiabilité des pièces détenues par l office. À cet effet, il convient de protéger les pièces électroniues de toute perte, modification, déplacement ou destruction prématurée. Étant donné u il est plus difficile de prouver u il y a eu altération d une pièce électroniue ue d une pièce sur support papier, il est particulièrement important ue des contrôles soient effectués aux fins de la protection et de la préservation adéuates des pièces. 5.4.10.1 Conservation des dossiers Aux fins de l établissement du calendrier de conservation des dossiers, le dossier électroniue de propriété intellectuelle, une fois complet, est considéré comme formant une entité uniue et est, par conséuent, assorti d une durée de conservation uniue.

Annexe 5, page 74 5.4.10.2 Durée de conservation Ainsi u il est indiué au paragraphe 3.5 relatif à la conservation des pièces, la durée de conservation varie en fonction de l état du dossier (p. ex. : le brevet a-t-il été délivré ou abandonné?) et de la date à lauelle la demande a été déposée. La durée de conservation de toute pièce est fixée en fonction de critères commerciaux ou juridiues ou de sa valeur historiue. En d autres mots, la pièce en uestion est-elle nécessaire à certaines transactions? Dans l affirmative, elle doit être conservée aussi longtemps ue cette nécessité existe. Lorsue la pièce a une valeur juridiue ou historiue, le calcul de sa durée de conservation appelle moins de uestions et laisse moins de place à l intuition. 5.4.10.3 Établissement du calendrier de conservation des dossiers et des pièces La durée de conservation des dossiers et pièces de propriété intellectuelle, sous forme électroniue ou sur support papier, est guidée par l événement. Ainsi, le processus de conservation ne peut pas commencer avant ue la demande de brevet ait été instruite, c est-à-dire u un brevet ait été délivré ou abandonné. La durée de conservation varie aussi selon ue le brevet a été délivré ou ue la demande a été abandonnée. On trouvera ci-après des propositions de durée de conservation. Dossiers de brevets contenant des pièces relatives à l instruction de la demande et à la délivrance d un brevet : les fichiers contiennent l original de la demande, les dessins et tous les documents concernant l instruction de la demande et les mesures ultérieures prises par l office de propriété intellectuelle concerné sont conservés. Sont rangés dans cette catégorie les fichiers concernant les brevets redélivrés; les dossiers de brevet clos (brevet délivré) sélectionnés par le directeur de l office sont conservés indéfiniment et transférés aux archives après 40 ans; tous les autres dossiers de brevet clos (brevet délivré) sont détruits 40 ans après leur classement. Demandes de brevet abandonnées (aucun brevet délivré) : il y a abandon lorsue le déposant omet de payer des taxes ou de soumettre les documents reuis par l examinateur dans les délais prescrits, ue les revendications ne peuvent

Annexe 5, page 75 déboucher sur la délivrance d un brevet, ue l invention revendiuée a déjà été brevetée ou u un tiers a déposé une demande de brevet pour la même invention et peut prouver u il a conçu celle-ci à une date antérieure; les demandes ui sont mentionnées dans une autre demande doivent être conservées jusu à ce ue le dossier de brevet où elles sont citées est détruit; les demandes de brevet abandonnées sont détruites 23 ans après leur classement. 5.4.10.4 Détermination de la durée de conservation Les règles permettant de déterminer la durée de conservation des dossiers et pièces de propriété intellectuelle et des métadonnées connexes sont relativement simples. L événement ui marue le début de la durée de conservation (p. ex. : délivrance d un brevet) et ui est saisi par le système informatiue doit figurer dans le champ destruction des métadonnées de type Dossier. Il convient de respecter les règles suivantes : L événement ui marue le début de la durée de conservation et ui est saisi par le système informatiue détermine automatiuement la valeur des attributs code d instruction et date d action du champ destruction ui figure dans les métadonnées de type Dossier avec l information appropriée sur la conservation. -- le code d instruction concerne une action telle u une destruction, un transfert ou un maintien. -- la date d action est la date à lauelle l ordre doit être exécuté. Les attributs du champ destruction ne doivent pouvoir être modifiés ue par les membres du personnel autorisés par l employé chargé de la gestion des pièces ou par une personne ayant des fonctions éuivalentes et doivent figurer dans les métadonnées de type Historiue de l utilisation de chaue dossier. Il doit être possible, sous le contrôle de l employé chargé de la gestion des pièces ou d une personne ayant des fonctions éuivalentes, d effectuer des mises à jour ciblées et groupées des attributs du champ destruction, notamment lorsue les durées de conservation sont modifiées. Ainsi, lorsue c est après 30 ans et non plus 40 ue les pièces concernant les brevets délivrés doivent être transférées aux archives, la date d action prévue pour le transfert doit être modifiée dans tous les dossiers concernés. 5.4.10.5 Pièces à conserver Tous les documents reçus ou créés par un office de propriété intellectuelle ainsi ue les fichiers de travail indispensables doivent être stockés et leur intégrité préservée pendant toute la durée de leur conservation. Seuls un exemplaire original et une copie de sauvegarde de chaue dossier et de chaue pièce électroniues, y compris les métadonnées connexes, doivent être conservés.

Annexe 5, page 76 Le contenu et la structure de la pièce doivent être préservés de telle sorte u ils puissent être affichés ou imprimés par l homme pendant tout leur cycle de vie. Le contexte (c est-à-dire les circonstances dans lesuelles la pièce a été créée et stockée) doit être préservé pendant toute la durée de conservation. Le format choisi doit permettre d accéder à la pièce pendant toute sa durée de conservation (opter pour un format de fichier correspondant à une norme de l industrie ou à une norme admise de facto). 5.4.10.6 Destruction Les offices de propriété intellectuelle doivent conserver les documents d archive et détruire rapidement ou retirer les documents ui ne constituent pas des archives (documents temporaires). La procédure à suivre pour détruire les dossiers et pièces électroniues, les métadonnées connexes et les copies de sauvegarde sont résumées ci-dessous : Les membres du personnel autorisés doivent pouvoir accéder aux dossiers à détruire et afficher ceux-ci à l écran, à l aide du champ destruction figurant dans les métadonnées de type Dossier. Une liste électroniue ou sur support papier des dossiers dont le code d instruction et la date d action indiuent une destruction en cours doit être produite à des fins d approbation soit automatiuement sur la base de critères prédéterminés, soit manuellement par les membres du personnel autorisés. Les opérations de destruction doivent être approuvées par la voie électroniue, soit à l aide de listes de dossiers et pièces à détruire, soit par intervention manuelle des membres du personnel autorisés par l employé chargé de la gestion des pièces ou par toute autre personne ayant des fonctions éuivalentes. L opération de destruction des dossiers et des pièces doit être confirmée avant son commencement. Le processus de destruction des dossiers doit être amorcé par la voie électroniue, en utilisant soit un système informatiue, soit un programme de services conçu à cet effet. Il convient d incorporer une piste de contrôle des destructions (extraction et sauvegarde), pour une période à déterminer, dans les métadonnées de type Historiue de l utilisation ui contiennent, pour chaue dossier, des informations sur les opérations de destruction. La destruction d un dossier comprend la destruction de l ensemble du dossier, de toutes les métadonnées connexes et de la copie de sauvegarde. La destruction comprend la destruction physiue (réécriture avec des caractères inintelligibles ou destruction d un support) de toute l information figurant dans le dossier et non uniuement la suppression logiue des métadonnées et des pointeurs. Il convient d effectuer un échantillonnage de toutes les tentatives d accès à des dossiers détruits afin de s assurer ue l opération de destruction a été menée à bien. Lorsu il existe un hyperlien entre un dossier ou une pièce et un autre dossier (p. ex. : dossier relatif à un brevet abandonné mentionné dans un brevet ui a été délivré), le dossier relatif au brevet abandonné ne peut être supprimé u à la date prévue dans le dossier où il est mentionné.

Annexe 5, page 77 5.4.10.6.1 Destruction des fichiers de travail Les fichiers de travail font l objet d une gestion distincte de celle des dossiers électroniues. Toutefois, il y a lieu de les détruire le plus tôt possible. Ils doivent être détruits lorsue l instruction de la demande de brevet est finie (le brevet a été délivré et enregistré ou la demande a été abandonnée), voire antérieurement lorsu ils n ont aucune valeur de référence et ue leur conservation n a pas été ordonnée. Il convient de procéder comme suit : Une procédure de destruction des fichiers de travail à ne pas conserver doit être définie à l intention des utilisateurs autorisés. La destruction comprendra la destruction physiue (par réécriture ou destruction d un support) de toute l information figurant dans le fichier et non uniuement la suppression logiue des pointeurs. La destruction des fichiers de travail ne doit pas figurer dans la piste de contrôle incorporée dans les métadonnées de type Historiue de l utilisation. 5.4.11 Migration Les dossiers électroniues de propriété intellectuelle doivent demeurer accessibles et transférables uelle ue soit l évolution des techniues de l information. Le contenu, la structure et le contexte des pièces électroniues doivent pouvoir être affichés, imprimés ou reproduits d une autre manière, conformément à l original, pendant tout leur cycle de vie. 5.4.11.1 Copie, reformatage et transfert Il ne fait aucun doute ue les techniues vont évoluer à un rythme ui nécessitera de nombreuses migrations des dossiers et pièces électroniues de propriété intellectuelle pendant leur durée de conservation. Il s agira, entre autres, de copier et de reformater les dossiers sur de nouveaux supports ou de les transférer vers de nouveaux systèmes informatiues, matériels ou logiciels. Il convient de procéder comme suit : Élaborer une stratégie et un plan et y affecter des fonds pour le copiage, le reformatage et le transfert de dossiers électroniues dans les délais prévus, toute interruption du cycle de migration pouvant rendre les dossiers ou pièces électroniues inaccessibles.

Annexe 5, page 78 Préserver le contenu, la structure et le contexte des documents lors de la copie, du reformatage ou du transfert. Selon ue de besoin, copier et reformater les dossiers électroniues au moment où ils sont transférés d un système informatiue, logiciel ou matériel à un autre. Selon ue de besoin, reformater les dossiers électroniues lorsue de nouveaux outils ou supports de stockage sont utilisés. Lorsue le document primaire ou la copie de sauvegarde se trouve sur bande magnétiue, analyser chaue année un échantillon statistiue de toutes les bobines de bande en vue de détecter toute perte de données, d établir l origine de cette perte et d y remédier. Lorsue le document primaire ou la copie de sauvegarde se trouve sur bande magnétiue, copier les dossiers électroniues lorsue l échantillon statistiue annuel des bobines de bande a mis en évidence 10 ou plus de 10 erreurs temporaires ou de lecture. Lorsue le document primaire ou la copie de sauvegarde se trouve sur bande magnétiue, effectuer une copie des dossiers électroniues tous les 10 ans. Lorsue le logiciel utilisé est actualisé, u un nouveau système de gestion des fichiers est installé ou ue le système en place est actualisé, transférer les dossiers électroniues de propriété intellectuelle. Appliuer une procédure stricte de contrôle de la ualité, ui peut comprendre des comparaisons bit-octet, des comparaisons entre les valeurs de hachage et des contrôles de redondance cycliue (CRC), en vue d assurer la fiabilité et l intégrité des dossiers de brevet électroniues reformatés, copiés ou transférés. Consigner toutes les opérations exécutées lors du reformatage, de la copie ou du transfert de dossiers électroniues de propriété intellectuelle et incorporer cette information dans les métadonnées de type Historiue de l utilisation de chaue dossier. Dans le cadre du plan de secours, effectuer deux copies de tout dossier électroniue de propriété intellectuelle au moment du reformatage, de la copie ou du transfert et stocker l une d entre elles dans un lieu séparé. 5.4.11.2 Gestion des supports Il convient de suivre les instructions du fabricant en ce ui concerne le cycle de vie du support avant écriture et la durée d archivage après écriture, et de procéder comme suit : Suivre les instructions du fabricant en ce ui concerne la conservation du support avant écriture et après écriture. La période avant écriture s entend de la période comprise entre la date de fabrication du support et la date à lauelle il n est plus recommandé de procéder à l inscription initiale de l information sur le support. La durée d archivage après écriture s entend de la période comprise entre la date de fabrication du support et la date à lauelle le contenu du support doit être copié sur une nouvelle unité. Stocker le support dans un endroit où la régulation de la température et de l humidité est conforme aux instructions du fabricant. Effectuer régulièrement des contrôles du taux de correction des erreurs de lecture même lorsue le support est stocké dans un endroit où la régulation de la température et de l humidité est conforme aux instructions du fabricant. Lorsue le taux de correction des erreurs de lecture se situe au niveau du seuil de tolérance ou est supérieur à ce seuil ou ue la durée d archivage après écriture arrive à son terme, copier les données numériues sur un nouveau support. Cette pratiue de copier l information contenue dans un support

Annexe 5, page 79 avant ue celui-ci ne soit plus utilisable est une techniue de conservation efficace dans la mesure où cette information est encore lisible. 5.4.12 Transfert aux archives Les offices de propriété intellectuelle doivent définir des politiues et des procédures afin ue les dossiers et pièces électroniues soient conservés aussi longtemps ue nécessaire. Il convient de procéder comme suit : Ne transférer définitivement aux archives ue les dossiers et pièces électroniues sélectionnés, ainsi ue les métadonnées connexes, comme le prévoit le code d instruction et le code d action des métadonnées de type Dossier. Créer tous les formulaires reuis aux fins du transfert des pièces. S assurer ue les dossiers et pièces sont transférés dans un format de fichier et sur un type de support appropriés à l archivage définitif. Vérifier la ualité des pièces et des métadonnées connexes à transférer. Mettre à jour les métadonnées de type Transfert afin d avoir une piste de contrôle détaillée des pièces ui ont été transférées à titre définitif aux archives. 5.4.13 Pièces en attente de classement Lorsu une action en justice, un contrôle ou une enuête est imminent ou prévisible, les pièces doivent être mises en attente de classement (c est-à-dire u elles ne doivent pas être supprimées). Il convient de respecter les règles suivantes : Les pièces ui doivent être mises en attente de classement doivent être recensées. Les métadonnées de ces pièces doivent être maruées, la raison de cette mise en attente doit être indiuée et la pièce doit être automatiuement déblouée une fois ue l ordre de mise en attente est levé (une pièce peut donner lieu à de multiples ordres de mise en attente). Seul l employé chargé de la gestion des pièces au sein de l office concerné ou une personne ayant des fonctions éuivalentes doit pouvoir autoriser certains membres du personnel à émettre, modifier ou lever un ordre de mise en attente d un dossier.

Annexe 5, page 80 5.5 PRINCIPES DIRECTEURS APPLICABLES AUX MÉTADONNÉES La présente section contient des principes directeurs applicables aux métadonnées de types Reformatage, Copie et Transfert. 5.5.1 Métadonnées de type reformatage Ce type de métadonnées comprend des éléments d entrée et des éléments de sortie. Ces éléments doivent permettre de saisir des informations détaillées sur l état d un dossier avant et après reformatage en vue de jeter les bases de sa fiabilité au fil du temps. Il y a tout lieu de croire ue, lors du premier reformatage, bon nombre d éléments d entrée seront extraits des métadonnées de types Dossier ou Pièces de dossier. Lors des reformatages ultérieurs, un lien sera établi avec l opération de traitement la plus récente (p. ex. : reformatage, copie ou transfert) et les éléments pertinents seront extraits. EXEMPLE DE MÉTADONNÉES DE TYPE REFORMATAGE (ENTRÉE) Date du reformatage Numéro d itération du reformatage Identificateur du dossier Identificateur de la pièce du dossier (le cas échéant) Formats de fichier utilisés TIFF (V6.0 avec compression de groupe 4, monoruban, en codage Intel, 200, 300 ou 400 dpi, taille maximale A4 ou format commercial) JPEG PDF (compatible Acrobat version 3, texte non comprimé, texte non crypté, pas de signature numériue, pas d objets incorporés en OLE, toutes polices de caractères, spécification PS17 ou construite à partir des polices de caractères Adobe NM) 3 XML (jeu de caractères Unicode UCS-2 (ISO/IEC 10646:193) codé UTF-8 ou JIS-X0208 codé ISO-2022-JP; pour demandes PCT, caractères chinois GB2312 et caractères coréens KSC 5601 aussi acceptés) SGML Autres (p. ex. : unités de travail complexes) Nombre d octets du dossier ou de la pièce 3 Le format PDF peut être utilisé lorsu il permet un archivage à long terme par l office de propriété intellectuelle concerné.

Annexe 5, page 81 Authentification de la liste (si nécessaire) CRC Valeur de hachage Supports de stockage Vendeur Type (p. ex. : RAID, 3480 ou bande DLT) Nom du produit Identification du volume Logiciel utilisé pour le reformatage Nom du produit Numéro de la version EXEMPLE DE MÉTADONNÉES DE TYPE REFORMATAGE (SORTIE) Date du reformatage Numéro d itération du reformatage Identificateur du dossier Identificateur de la pièce du dossier (le cas échéant) Formats de fichier utilisés TIFF (V6.0 avec compression de groupe 4, monoruban, en codage Intel, 200, 300 ou 400 dpi, taille maximale A4 ou format commercial) JPEG PDF (compatible Acrobat version 3, texte non comprimé, texte non crypté, pas de signature numériue, pas d objets incorporés en OLE, toutes polices de caractères, spécification PS17 ou construite à partir des polices de caractères Adobe NM) 4 XML (jeu de caractères Unicode UCS-2 (ISO/IEC 10646:193) codé UTF-8 ou JIS-X0208 codé ISO-2022-JP; pour demandes PCT, caractères chinois GB2312 et caractères coréens KSC 5601 aussi acceptés) SGML Autres (p. ex. : unités de travail complexes) Nombre d octets du dossier ou de la pièce Authentification de la pièce (si nécessaire) 4 Le format PDF peut être utilisé lorsu il permet un archivage à long terme par l office de propriété intellectuelle concerné.

Annexe 5, page 82 CRC Valeur de hachage Supports de stockage Vendeur Type (p. ex. : RAID, 3480 ou bande DLT) Nom du produit Identification du volume Comparaison Nombre d octets CRC Valeur de hachage Inspection visuelle Anomalies (le cas échéant) Corrections (le cas échéant explications) Examen du superviseur Lieu du stockage Document primaire Copie de sauvegarde 5.5.2 Métadonnées de type copie Les éléments de métadonnées du modèle de format de copie doivent permettre de saisir des informations détaillées sur l état d un dossier avant et après copie en vue de jeter les bases de sa fiabilité au fil du temps. Par conséuent, les métadonnées de type Copie comprennent des éléments d entrée et des éléments de sortie. Les dossiers de propriété intellectuelle peuvent être copiés après classement, après le premier reformatage ou lors d un transfert (voir plus loin). Il y a tout lieu de croire ue, lors de la première copie, bon nombre d éléments d entrée seront extraits du modèle création-utilisation ou reformatage. Lors des copies ultérieures, un lien sera établi avec l opération de traitement la plus récente (p. ex. : reformatage, copie ou transfert) et les éléments de métadonnées pertinents seront extraits.

Annexe 5, page 83 EXEMPLE DE MÉTADONNÉES DE TYPE COPIE (ENTRÉE) Date de la copie Numéro d itération de la copie Identificateur du dossier Identificateur de la pièce du dossier (le cas échéant) Formats de fichier utilisés TIFF (V6.0 avec compression de groupe 4, monoruban, en codage Intel, 200, 300 ou 400 dpi, taille maximale A4 ou format commercial) JPEG PDF (compatible Acrobat version 3, texte non comprimé, texte non crypté, pas de signature numériue, pas d objets incorporés en OLE, toutes polices de caractères, spécification PS17 ou construite à partir des polices de caractères Adobe NM) 5 XML (jeu de caractères Unicode UCS-2 (ISO/IEC 10646:193) codé UTF-8 ou JIS-X0208 codé ISO-2022-JP; pour demandes PCT, caractères chinois GB2312 et caractères coréens KSC 5601 aussi acceptés) SGML Autres (p. ex. : unités de travail complexes) Nombre d octets du dossier ou de la pièce Authentification de la pièce (si nécessaire) CRC Valeur de hachage Supports de stockage Vendeur Type (p. ex. : RAID, 3480 ou bande DLT) Nom du produit Identification du volume Logiciel utilisé pour le reformatage Nom du produit Numéro de la version 5 Le format PDF peut être utilisé lorsu il permet un archivage à long terme par l office de propriété intellectuelle concerné.

Annexe 5, page 84 EXEMPLE DE MÉTADONNÉES DE TYPE COPIE (SORTIE) Date de la copie Numéro d itération de la copie Identificateur du dossier Identificateur de la pièce du dossier (le cas échéant) Formats de fichier utilisés TIFF (V6.0 avec compression de groupe 4, monoruban, en codage Intel, 200, 300 ou 400 dpi, taille maximale A4 ou format commercial) JPEG PDF (compatible Acrobat version 3, texte non comprimé, texte non crypté, pas de signature numériue, pas d objets incorporés en OLE, toutes polices de caractères, spécification PS17 ou construite à partir des polices de caractères Adobe NM) 6 XML (jeu de caractères Unicode UCS-2 (ISO/IEC 10646:193) codé UTF-8 ou JIS-X0208 codé ISO-2022-JP ; pour demandes PCT, caractères chinois GB2312 et caractères coréens KSC 5601 aussi acceptés) SGML Autres (p. ex. : unités de travail complexes) Nombre d octets du dossier ou de la pièce Authentification de la pièce (si nécessaire) CRC Valeur de hachage Supports de stockage Vendeur Type (p. ex. : RAID, 3480 ou bande DLT) Nom du produit Identification du volume Comparaison Nombre d octets CRC Valeur de hachage Inspection visuelle 6 Le format PDF peut être utilisé lorsu il permet un archivage à long terme par l office de propriété intellectuelle concerné.

Annexe 5, page 85 Anomalies (le cas échéant) Corrections (le cas échéant explications) Examen du superviseur Lieu du stockage Document primaire Copie de sauvegarde 5.5.3 Métadonnées de type transfert Tout comme les métadonnées de types Reformatage et Copie, les métadonnées de type Transfert permettent de saisir des informations détaillées sur les opérations exécutées dans le cadre de cette activité, ui permettront de jeter les bases de la fiabilité des dossiers électroniues de propriété intellectuelle malgré l évolution des techniues. Ces éléments de métadonnées permettent de saisir des informations détaillées sur l état d un dossier avant et après transfert. Il y a tout lieu de croire ue, lors du premier transfert, bon nombre d éléments d entrée seront extraits soit du modèle reformatage, soit du modèle copie. Lors des transferts ultérieurs, un lien sera établi avec l opération de traitement la plus récente (p. ex. : reformatage, copie ou transfert) et les éléments de métadonnées pertinents seront extraits. EXEMPLE DE MÉTADONNÉES DE TYPE TRANSFERT (ENTRÉE) Date du transfert Numéro d itération du transfert Identificateur du dossier Identificateur de la pièce du dossier (le cas échéant) Formats de fichier utilisés TIFF (V6.0 avec compression de groupe 4, monoruban, en codage Intel, 200, 300 ou 400 dpi, taille maximale A4 ou format commercial) JPEG PDF (compatible Acrobat version 3, texte non comprimé, texte non crypté, pas de signature numériue, pas d objets incorporés en OLE, toutes polices de caractères, spécification PS17 ou construite à partir des polices de caractères Adobe NM) 7 XML (jeu de caractères Unicode UCS-2 (ISO/IEC 10646:193) codé UTF-8 ou JIS-X0208 codé ISO-2022-JP; pour demandes PCT, caractères chinois GB2312 et caractères coréens KSC 5601 aussi acceptés) 7 Le format PDF peut être utilisé lorsu il permet un archivage à long terme par l office de propriété intellectuelle concerné.

Annexe 5, page 86 SGML Autres (p. ex. : unités de travail complexes) Nombre d octets du dossier ou de la pièce Authentification de la pièce (si nécessaire) CRC Valeur de hachage Supports de stockage Vendeur Type (p. ex. : RAID, 3480 ou bande DLT) Nom du produit Identification du volume Logiciel utilisé pour le reformatage Nom du produit Numéro de la version EXEMPLE DE MÉTADONNÉES DE TYPE TRANSFERT (SORTIE) Date du transfert Numéro d itération du transfert Identificateur du dossier Identificateur de la pièce du dossier (le cas échéant) Formats de fichier utilisés TIFF (V6.0 avec compression de groupe 4, monoruban, en codage Intel, 200, 300 ou 400 dpi, taille maximale A4 ou format commercial) JPEG PDF (compatible Acrobat version 3, texte non comprimé, texte non crypté, pas de signature numériue, pas d objets incorporés en OLE, toutes polices de caractères, spécification PS17 ou construite à partir des polices de caractères Adobe NM) 8 XML (jeu de caractères Unicode UCS-2 (ISO/IEC 10646:193) codé UTF-8 ou JIS-X0208 codé ISO-2022-JP; pour demandes PCT, caractères chinois GB2312 et caractères coréens KSC 5601 aussi acceptés) 8 Le format PDF peut être utilisé lorsu il permet un archivage à long terme dans chaue office de propriété intellectuelle.

Annexe 5, page 87 SGML Autres (p. ex. : unités de travail complexes) Nombre d octets du dossier ou de la pièce Authentification du dossier (si nécessaire) CRC Valeur de hachage Supports de stockage Vendeur Type (p. ex. : RAID, 3480 ou bande DLT) Nom du produit Identification du volume Comparaison Nombre d octets CRC Valeur de hachage Inspection visuelle Anomalies (le cas échéant) Corrections (le cas échéant explications) Examen du superviseur Lieu du stockage Document primaire Copie de sauvegarde

Annexe 5, page 88 Supplément 6. Sigles PKCS ICP SDIF SGML XML epct Public Key Cryptographic Standard Standard de cryptographie à clé publiue Infrastructure à clé publiue SGML Document Interface Format Format d interface de document SGML Standardised Generic Mark-up Language Langage normalisé de balisage généralisé Extensible Mark-up Language Langage de balisage extensible Demande électroniue PCT [L appendice II suit]

Annexe 5, page 89 APPENDICE II DTD SELON LE XML POUR L ÉCHANGE DE DOCUMENTS DE PROPRIÉTÉ INTELLECTUELLE Résumé Le présent document présente toutes les DTD utilisées pour l échange électroniue de documents de propriété intellectuelle tel u il est défini dans l annexe F des Instructions administratives du PCT et son Appendice I. Il contient également des précisions sur la méthodologie adoptée pour l élaboration de ces DTD. Table des matières SUPPLÉMENT 1. DTD POUR LES DOCUMENTS XML... 90 SUPPLÉMENT 2. PAQUETS STANDARD ET SPÉCIFICATIONS D EN-TÊTE... 92 SUPPLÉMENT 3. DTD POUR LES NOUVELLES DEMANDES PCT... 97 n:\orgipis\shared\williams\scit\projects\p8\an5f_ap2.doc

Annexe 5, page 90 Supplément 1. DTD pour les documents XML 1.1 Stratégie de développement des DTD Bien ue limitée à ce stade au dépôt électroniue initial d une nouvelle demande PCT, la présente spécification verra par la suite son champ d application élargi aux échanges formels ultérieurs entre les parties prenantes. On trouvera ci-dessous la liste des DTD nécessaires pour la phase initiale de la présentation électroniue d une demande électroniue. D autres DTD seront nécessaires pour les phases ultérieures du traitement de la demande électroniue PCT. Bien ue la présente spécification ait pour objet immédiat la prise en charge des demandes électroniues PCT, les offices participant à la coopération trilatérale envisagent de l appliuer à leurs propres demandes électroniues nationales pour différentes catégories de titres de propriété intellectuelle et préconisent u elle serve de base à une éventuelle norme de l OMPI applicable par d autres offices. Dans cette perspective, les DTD élaborées pour les demandes électroniues PCT seront construites sur la base de DTD dites architecturales, ui contiennent les modèles de définitions d éléments et à partir desuelles les offices de la coopération trilatérale et les autres offices pourront, de manière cohérente et compatible, déduire des éléments et des DTD répondant à leurs besoins. Les projets de DTD déjà établis pour les demandes électroniues PCT seront révisés en fonction des structures architecturales. Les DTD ui se révéleront nécessaires par la suite seront aussi fondées sur les DTD architecturales. La fonction domaines nominaux du XML (XMLNS) sera utilisée pour la mise en œuvre des architectures dans les DTD ui acceptent cette spécification. Afin de faciliter la création des DTD et des structures architecturales, un tableau des éléments et des structures figurant dans les sources des DTD proposées et des DTD nouvellement créées pour cette spécification sera établi, ui illustrera leurs rapports et leurs définitions. 1.2 Inventaire des DTD au 5 novembre 1999 1. Demande électroniue PCT : public -//wipo//dtd epct v0.2 1999-10-30//en in epct-v02.dtd 2. En-tête de pauet : public -//wipo//dtd epct-ph v0.1 1999-10-30//en In epct-package-header-v01.dtd 3. Certificat de confirmation : public -//wipo/dtd epct-cc v0.1 1999-10-30//en In pcte-confirmation-certificate-v01.dtd 4. Ticket : public -//wipo/dtd epct-ti v0.1 1999-10-30//en in epct-ticket-header-v01.dtd

Annexe 5, page 91 1.3 DTD à venir 5. communications postérieures au dépôt de la demande, communications de procédure et communications formelles de divers types 6. envoi d un office récepteur au Bureau international 7. envoi d un office récepteur à une administration chargée de la recherche internationale 8. envoi du Bureau international à une administration chargée de la recherche internationale 9. envoi du Bureau international à une administration chargée de l examen préliminaire international 10. envoi d une administration chargée de la recherche internationale au Bureau international 11. envoi d une administration chargée de l examen préliminaire international au Bureau international 12. envoi du Bureau international à un office récepteur 13. DTD reuises pour d autres catégories de titres de propriété intellectuelle 1.4 Composants réutilisables Compte tenu de leur nombre, les DTD pour l échange de documents de propriété intellectuelle seront échafaudées à l aide de certains composants standard réutilisables en combinaison avec des composants spécifiues à la transaction. La méthode utilisée pour obtenir et organiser ces composants sera basée sur la structure XML dite architecturale. Les composants suivants ont été définis : Reuête Description Revendications Abrégé Dessins Listage des séuences Données de l office récepteur selon le PCT Signature électroniue

Annexe 5, page 92 Supplément 2. Pauets standard et spécifications d en-tête 2.1 Objet en-tête de pauet Les éléments de l objet en-tête sont rédigés en XML selon la DTD suivante : <?xml version="1.0" > <!- DTD for Package header object --> <!-- To use this DTD define DOCTYPE declaration like below. --> <!-- <!DOCTYPE pkgheader SYSTEM "pkgheader.dtd" > --> <!ELEMENT pkgheader (ip,package,return-route?,file+)> <!ELEMENT ip EMPTY> <!ATTLIST ip type CDATA #REQUIRED procedure CDATA #REQUIRED> <!ELEMENT package (#PCDATA)> <!ATTLIST package id CDATA #REQUIRED> <!ELEMENT return-route (#PCDATA)> <!ELEMENT file (#PCDATA)> <!ATTLIST file type CDATA #REQUIRED> Les balises sont décrites ci-après : 1) pkgheader Contenu Attribut Répétition/Omission 2) ip Contenu Attribut Répétition/Omission : Balise de procédure. L information vient sous cette balise. : Aucun : Une fois/impossible : Aucun : type (obligatoire) Type de demande 1 : Brevet 2 : Modèle d utilité 3 : Dessin ou modèle 4 : Marue ### Développer si nécessaire ## procédure (obligatoire) Type de procédure 1 : Demande 2 : Modification 3 : Demande d examen ## Développer si nécessaire ## : Une fois/impossible

Annexe 5, page 93 3) package Contenu : Indiue le type de pauet Attribut : id (obligatoire) Type de pauet 1 : Demande de ticket 2 : Ticket 3 : Nouvelle demande 4 : Certificat de confirmation Répétition/Omission : Une fois/impossible 4) return-route Contenu Attribut Répétition/Omission : Indiue la méthode de réponse : Aucun : Une fois/impossible 5) file Contenu : Indiue le nom de fichier de l élément Attribut : type (obligatoire) Type d élément 1 : En-tête 2 : Documents de propriété intellectuelle 3 : Données du ticket ## Développer si nécessaire ## Répétition/Omission : Une ou plusieurs fois/impossible Voici un exemple d objet en-tête : <?xml version="1.0" > <!DOCTYPE pkgheader SYSTEM "pkgheader.dtd" > <pkgheader> <ip type="1" procedure="1" /> <package id="3">new application</package> <file type="1">header.xml</file> <file type="2">ipdoc.dat</file> <file type="3">ticket.dat</file> </pkgheader> 2.2 Certificat de confirmation La version XML du certificat de confirmation doit suivre la DTD suivante : <?xml version="1.0" > <!-- DTD for Confirmation Certificate --> <!-- To use this DTD define DOCTYPE declaration like below. --> <!-- <!DOCTYPE confcertificate SYSTEM "confcertificate.dtd" > --> <!ELEMENT confcertificate (application-number, applicants-reference, date-ofreceipt, action, message-digest, result-code, resultmessage?)>

Annexe 5, page 94 <!ELEMENT application-number (#PCDATA)> <!ELEMENT applicants-reference (#PCDATA)> <!ELEMENT date-of-receipt (#PCDATA)> <!ELEMENT action (#PCDATA)> <!ELEMENT message-digest (#PCDATA)> <!ELEMENT result-code (#PCDATA)> <!ELEMENT result-message (#PCDATA)> Les balises sont décrites ci-après : 1) confcertificate Contenu : Balise de procédure. L information vient sous cette balise. Attribut : Aucun Répétition/Omission : Une fois/impossible 2) application-number Contenu : Indiue le numéro attribué à la demande Attribut : Aucun Répétition/Omission : Une fois/impossible 3) applicants-reference Contenu : La référence utilisée par le déposant Attribut : Aucun Répétition/Omission : Une fois/impossible 4) date-of-receipt Contenu : Date de réception du document PI attribuée par l office Attribut : Aucun Répétition/Omission : Une fois/possible 5) action Contenu : Type de document PI envoyé (par ex. nouvelle demande US) Attribut : Aucun Répétition/Omission : Une fois/possible 6) message-digest Contenu : Une représentation hexadécimale de la valeur de l empreinte du message Attribut : Aucun Répétition/Omission : Une fois/impossible 7) result-code Contenu : Une représentation numériue du résultat de la transaction indiuant si celle-ci a réussi ou échoué (0=OK) Attribut : Aucun Répétition/Omission : Une fois/impossible 8) result-message Contenu : Une représentation par chaîne de caractères de la cause de tout échec éventuel Attribut : Aucun Répétition/Omission : Une fois/impossible Voici un exemple de certificat de confirmation :

Annexe 5, page 95 <?xml version="1.0" > <!DOCTYPE confcertificate SYSTEM "confcertificate.dtd"> <confcertificate> <application-number>ep98200345</application-number> <applicants-reference>myref001</applicants-reference> <date-of-receipt>19990929</date-of-receipt> <action>new-ep-application</action> <message digest>12:34:56:af:c3: 12:34:56:af:c3: 12:34:56:af:c3:12:34:56:af:c3</message digest> <result-code>0</result-code> </confcertificate> 2.3 Ticket Le ticket est utilisé pour fixer l information reçue par l office récepteur; il est rédigé en XML. Observer la DTD suivante lors de la rédaction du ticket en XML. <?xml version="1.0" > <!-- DTD for Ticket --> <!-- To use this DTD define DOCTYPE declaration like below. --> <!-- <!DOCTYPE ticket SYSTEM "ticket.dtd" > --> <!ELEMENT ticket (ticket-number, stamp-date, expire-date, message digestfile)> <!ELEMENT ticket-number (#PCDATA)> <!ELEMENT stamp-date (#PCDATA)> <!ELEMENT expire-date (#PCDATA)> <!ELEMENT message-digest (#PCDATA)> Les balises sont décrites ci-après : 1) ticket Contenu : Balise de procédure. L information vient sous cette balise. Attribut : Aucun Répétition/Omission : Une fois/impossible 2) ticket-number Contenu : Indiue le numéro attribué au ticket Attribut : Aucun Répétition/Omission : Une fois/impossible 3) stamp-date Contenu : Indiue la date d émission du ticket sous la forme CCYYMMDDHHMMSSTMZ, où TMZ est le fuseau horaire Attribut : Aucun Répétition/Omission : Une fois/impossible 4) expire-date Contenu : Indiue la date d expiration du ticket (minuit 5 jours plus tard) Attribut : Aucun Répétition/Omission : Une fois/possible

Annexe 5, page 96 5) message-digest Contenu Attribut Répétition/Omission : Une représentation hexadécimale de la valeur de hachage : Aucun : Une fois/impossible Voici un exemple de ticket : <?xml version="1.0" > <!DOCTYPE ticket SYSTEM "ticket.dtd" > <ticket> <ticket-number> 01234567 </ticket-number> <stamp-date>19990929112734cet</stamp-date> <expire-date>19991228</expire-date> <message-digest>12:34:56:af:c3: 12:34:56:af:c3: 12:34:56:af:c3:12:34:56:af:c3</message digest> </ticket>

Annexe 5, page 97 Supplément 3. DTD pour les nouvelles demandes PCT <?xml version= 1.0 encoding= ISO-8859-1?> <!--Document type definition for international patent applications filed electronically under the patent cooperation treaty epct v0.3, 1999 November 5 Reference this DTD as public -//wipo//dtd epct v0.3 1999-11-05//en contacts: EPO: JPO: USPTO: bruce.cox@uspto.gov WIPO: ********** Revision History ********** Revised 1999 November 5, Bruce B. Cox, USPTO..Modified name structure to accommodate both persons with organizational...affiliation and organizations..converted all element names to lower case, following XML convention Revised 1999 October 25, Bruce B. Cox, USPTO..Moved electronic-signature to party structure...and changed content model from (#PCDATA) to...(date,((mark,signature-file?) (signature-file,mark?)) first draft 1999 October 18, Bruce B. Cox, USPTO..Based on elements found in..1) Proposed sgml specification for pct/easy, version 8, dated 1999 may 14...(represented by b000 tags and b tags with wo suffix);..2) st.32 and st.32/us/grant v1.8, 1999 august 26 (uspto s red book)...(represented by the remaining b tags and most of the non-b tags in uppercase);..3) USPTO s team DTD for a patent specification, u-specif.dtd, 1999 June 25...(represented by tag names in lower case; some content models modified...to remove parochial characteristics)...additional tags created for the purpose. --> <!DOCTYPE pct-international-application [ <!ELEMENT address (pobox?,street,city,postcode?,country,telephone*,fax*,email*, b7110wo-formatted-address*) > <!ELEMENT address-1 (#PCDATA) > <!ELEMENT address-2 (#PCDATA) > <!ELEMENT appendix-data (heading,program-reference+) > <!ELEMENT application-filing-date (date) > <!ELEMENT application-reference (document-number,application-filing-date,country, kind-code) > <!ELEMENT artwork (drawing-reference-character*) > <!--the agency or other body issuing the identification number, or some other indication of the source or meaning of the number. for example, ssn for u.s. social security number; uspto registration for agents and attorneys registered to practice before

Annexe 5, page 98 the uspto.--> <!ELEMENT authority (#PCDATA) > <!ELEMENT b000-wo (b020wo-receiving-office?,b031wo-record-copy-at-ib-date, b040wo-signatory,b060wo-check-data?) > <!--receiving office elements. #usage:for use by receiving office only.--> <!ELEMENT b020wo-receiving-office (b021wo-drawings-not-received?, b022wo-corrected-date-of-receipt?,b023wo-date-of-receipt-pct-11-2?, b024wo-search-copy-delayed-until-fee-paid?) > <!--drawings not received. (pct reuest no. 10-2)--> <!ELEMENT b021wo-drawings-not-received EMPTY > <!--corrected date of actual receipt due to later but timely received papers or drawings completing the purported international application.--> <!ELEMENT b022wo-corrected-date-of-receipt (date) > <!--date of timely receipt of the REQUIRED corrections under pct article 11(2).--> <!ELEMENT b023wo-date-of-receipt-pct-11-2 (date) > <!--flag: transmittal of search copy delayed until search fee is paid. (pct reuest no. 10-6) #usage:element present when true, absent when false.--> <!ELEMENT b024wo-search-copy-delayed-until-fee-paid EMPTY > <!--date of receipt of the record copy by the ib.--> <!ELEMENT b031wo-record-copy-at-ib-date (date) > <!--signatory information.--> <!ELEMENT b040wo-signatory (b041wo-applicant-agent+) > <!--applicant / agent information. #usage:repeat for each person signing the application.--> <!ELEMENT b041wo-applicant-agent (party,b042wo-signatory-capacity?) > <!--capacity (role) of signatory. (pct reuest ix-x-3)--> <!ELEMENT b042wo-signatory-capacity (#PCDATA) > <!--reuest.--> <!ELEMENT b0601wo-reuest EMPTY > <!ELEMENT b0603wo-claims (claims) > <!--abstract.--> <!ELEMENT b0604wo-abstract (heading,paragraph) > <!--drawings.--> <!ELEMENT b0605wo-drawings (embedded-image+) > <!--check data--> <!ELEMENT b060wo-check-data (b0601wo-reuest?,b0610wo-signed-power-of-attorney?, b0611wo-general-power-of-attorney?,b0612wo-lack-of-signature?, b0613wo-fee-calculation-sheet?,b0614wo-microorganisms?, b0615wo-seuence-listing?,b0617wo-lack-of-novelty?, b0618wo-translation?) > <!--flag: separate signed power-of-attorney--> <!ELEMENT b0610wo-signed-power-of-attorney EMPTY >

Annexe 5, page 99 <!--flag: general power-of-attorney--> <!ELEMENT b0611wo-general-power-of-attorney EMPTY > <!--flag: statement explaining lack of signature--> <!ELEMENT b0612wo-lack-of-signature EMPTY > <!--flag: fee calculation sheet--> <!ELEMENT b0613wo-fee-calculation-sheet EMPTY > <!--flag: separate indications concerning deposited microorganisms--> <!ELEMENT b0614wo-microorganisms EMPTY > <!--flag: nucleotide and/or amino acid seuence listing and statement--> <!ELEMENT b0615wo-seuence-listing EMPTY > <!--flag: statement concerning non-prejudicial disclosures or exceptions to lack of novelty--> <!ELEMENT b0617wo-lack-of-novelty EMPTY > <!--flag: translation of application--> <!ELEMENT b0618wo-translation EMPTY > <!ELEMENT b200-filing-info (b210-ia-number,b211wo-country, b220-international-filing-date,b250-language) > <!--international application number--> <!ELEMENT b210-ia-number (document-number) > <!--receiving office specified by applicant using st.3 code.--> <!ELEMENT b211wo-country (country) > <!ELEMENT b220-international-filing-date (date) > <!--language of filing (ISO 9)--> <!ELEMENT b250-language (#PCDATA) > <!--priority information--> <!ELEMENT b300-priority-info (b310-priority-application-number,b320-priority-date, b330wo-pct-application,b330-office-of-filing,b340-paris-state, b345wo-priority-doc-reuested,b346wo-priority-doc-attached) > <!--priority application number--> <!ELEMENT b310-priority-application-number (document-number) > <!--priority date--> <!ELEMENT b320-priority-date (date) > <!--priority office-of-filing (WIPO Standard ST.3)--> <!ELEMENT b330-office-of-filing (#PCDATA) > <!--flag: pct application--> <!ELEMENT b330wo-pct-application EMPTY > <!--paris convention state--> <!ELEMENT b340-paris-state (country) > <!--flag: priority document reuested from RO--> <!ELEMENT b345wo-priority-doc-reuested EMPTY >

Annexe 5, page 100 <!--flag:priority document attached--> <!ELEMENT b346wo-priority-doc-attached EMPTY > <!ELEMENT b500-search-report (b540-title,b560-search) > <!ELEMENT b540-title (b541-language,b542-title) > <!--title language (ISO 639)--> <!ELEMENT b541-language (#PCDATA) > <!ELEMENT b542-title (#PCDATA) > <!--citations, search report data--> <!ELEMENT b560-search (b567-place-of-search,b567wo-earlier-search-by, b568wo-earlier-search-date) > <!--place of search (international search authority)--> <!ELEMENT b567-place-of-search (country) > <!--earlier search country or regional office--> <!ELEMENT b567wo-earlier-search-by (country) > <!--earlier search date--> <!ELEMENT b568wo-earlier-search-date (date) > <!--specification and drawings--> <!ELEMENT b590-drawings (b598-figures-to-publish*) > <!--figures (drawings)--> <!ELEMENT b598-figures-to-publish (#PCDATA) > <!--applicant--> <!ELEMENT b700-parties (b710-applicants,b720-inventors?,b740-agents?) > <!--main applicant--> <!ELEMENT b710-applicants (b711-applicant-inventor+) > <!--applicant information--> <!ELEMENT b711-applicant-inventor (party,b716wo-capacity-of-legal-rep, b717wo-dead-inventor-name?,b711wo-applicant-is-inventor?, b715wo-applicant-for-listed-states?,(b712wo-applicant-for-all-states b713wo-not-us-applicant b714wo-us-only-applicant)) > <!--address formatted for printing as a label--> <!ELEMENT b7110wo-formatted-address (#PCDATA) > <!--flag: applicant is also one of the inventors--> <!ELEMENT b711wo-applicant-is-inventor EMPTY > <!--flag: applicant for all designated states--> <!ELEMENT b712wo-applicant-for-all-states EMPTY > <!--flag: applicant for all designated states except us--> <!ELEMENT b713wo-not-us-applicant EMPTY > <!--flag: applicant for us only--> <!ELEMENT b714wo-us-only-applicant EMPTY > <!--applicant for listed national/regional states-->

Annexe 5, page 101 <!ELEMENT b715wo-applicant-for-listed-states (country*,b718wo-regional*) > <!--legal representative capacity--> <!ELEMENT b716wo-capacity-of-legal-rep (#PCDATA) > <!--flag: inventor is deceased--> <!ELEMENT b717wo-dead-inventor-name EMPTY > <!--regional filing--> <!ELEMENT b718wo-regional (b719wo-region,country) > <!--regional office code (WIPO Standard ST.3)--> <!ELEMENT b719wo-region (#PCDATA) > <!--inventor--> <!ELEMENT b720-inventors (b721-inventor+) > <!--inventor name, address, residence--> <!ELEMENT b721-inventor (party,b726wo-dead-inventor?,( b712wo-applicant-for-all-states b713wo-not-us-applicant b714wo-us-only-applicant)) > <!--flag: inventor is deceased (relevant to u.s.).--> <!ELEMENT b726wo-dead-inventor EMPTY > <!--agent--> <!ELEMENT b740-agents (b741-agent+) > <!--agent--> <!ELEMENT b741-agent (party,b742wo-common-representative,b743wo-mailing-address?) > <!--flag: acting as common representative--> <!ELEMENT b742wo-common-representative EMPTY > <!--correspondence address--> <!ELEMENT b743wo-mailing-address (address) > <!ELEMENT background-of-invention (heading,(paragraph list section seuence chemistry math table)+) > <!ELEMENT biological-deposit (deposit-date,deposit-term,depository, deposit-accession-number,deposit-description) > <!ELEMENT biological-deposit-data (heading?,biological-deposit+) > <!ELEMENT brief-description-of-drawings (heading,(paragraph figure)+) > <!ELEMENT chemistry EMPTY > <!--city--> <!ELEMENT city (#PCDATA) > <!ELEMENT claim (preamble-claim,(claim-step+ paragraph-claim)) > <!ELEMENT claim-step (claim-step paragraph-claim)+ > <!ELEMENT claims (heading,claim+) > <!ELEMENT colspec EMPTY >

Annexe 5, page 102 <!ELEMENT copyright (#PCDATA) > <!--WIPO Standard ST.3 code for country or other administrative unit.--> <!ELEMENT country (#PCDATA) > <!ELEMENT cross-reference (#PCDATA) > <!ELEMENT custom-character EMPTY > <!--yyyymmdd--> <!ELEMENT date (#PCDATA) > <!ELEMENT date-signed (date) > <!ELEMENT dependent-claim-reference (#PCDATA) > <!ELEMENT deposit-accession-number (#PCDATA) > <!ELEMENT deposit-date (#PCDATA) > <!ELEMENT deposit-description (#PCDATA) > <!ELEMENT deposit-reference (#PCDATA) > <!ELEMENT deposit-term (#PCDATA) > <!ELEMENT depository (address-1,address-2?,city,state,postcode,country,telephone*, email*,fax*) > <!--description--> <!ELEMENT detailed-description (heading,biological-deposit-data?,(paragraph list section seuence chemistry math table)+) > <!--document number--> <!ELEMENT document-number (#PCDATA) > <!ELEMENT drawing-reference-character (#PCDATA) > <!--the character string which singifies the signor s intention to sign.--> <!ELEMENT electronic-signature (date-signed,place-signed,((signature-mark, signature-file?) (signature-file,signature-mark?) use-digital-signature)) > <!--email address--> <!ELEMENT email (#PCDATA) > <!--embedded image file reference.--> <!ELEMENT embedded-image EMPTY > <!ELEMENT emphasis (#PCDATA superscript subscript)* > <!ELEMENT entry (#PCDATA emphasis)* > <!ELEMENT family-name (#PCDATA) > <!--telefacsimile number--> <!ELEMENT fax (#PCDATA) >

<!ELEMENT fiche-count (#PCDATA) > <!ELEMENT fiche-frame (#PCDATA) > SCIT/P 8/99 Rev.1 Annexe 5, page 103 <!ELEMENT figure (copyright?,(artwork seuence chemistry math table)) > <!ELEMENT given-name (#PCDATA) > <!ELEMENT heading (#PCDATA) > <!ELEMENT hybrid-claim-reference (#PCDATA) > <!--idendification number of an individual or an organization.--> <!ELEMENT id-number (authority,number) > <!ELEMENT kind-code (#PCDATA) > <!ELEMENT list (list-item+) > <!ELEMENT list-item (list-item paragraph seuence chemistry math table)+ > <!ELEMENT middle-name (#PCDATA) > <!ELEMENT name ((middle-name?,family-name,name-prefix?,given-name,name-suffix?, ref-number?,id-number?,organization-name?,title-at-organization?) ( name-prefix?,given-name,middle-name?,family-name,name-suffix?, ref-number?,organization-name,title-at-organization?,id-number?)) > <!ELEMENT name-prefix (#PCDATA) > <!ELEMENT name-suffix (#PCDATA) > <!--state of nationality--> <!ELEMENT nationality (country) > <!--the identification number.--> <!ELEMENT number (#PCDATA) > <!ELEMENT open-literature-reference (#PCDATA) > <!ELEMENT organization-name (#PCDATA) > <!ELEMENT paragraph (#PCDATA custom-character emphasis subscript superscript application-reference patent-reference open-literature-reference deposit-reference cross-reference seuence-fragment seuence chemistry math table)* > <!ELEMENT paragraph-claim (#PCDATA hybrid-claim-reference cross-reference)* > <!ELEMENT party (name,electronic-signature?,address?,nationality?,residence?) > <!ELEMENT patent-reference (document-number,publication-date,country,kind-code) > <!ELEMENT pct-international-application (sdobi-bibliographic-data,sdoab-abstract?, sdode-description,sdocl-claims,sdodr-drawings?) > <!ELEMENT place-signed (city?) > <!--post office box-->

Annexe 5, page 104 <!ELEMENT pobox (#PCDATA) > <!--postal code--> <!ELEMENT postcode (#PCDATA) > <!ELEMENT preamble-claim (#PCDATA dependent-claim-reference cross-reference)* > <!ELEMENT program-listing (#PCDATA) > <!ELEMENT program-listing-deposit (heading?,program-listing) > <!ELEMENT program-reference (fiche-count,fiche-frame) > <!ELEMENT publication-date (date) > <!--reference number provided by the filer (docket number, etc.).--> <!ELEMENT ref-number (#PCDATA) > <!ELEMENT related-documents (heading,paragraph+) > <!--state of residence--> <!ELEMENT residence (country) > <!ELEMENT row (entry+) > <!--subdocument abstract.--> <!ELEMENT sdoab-abstract (b0604wo-abstract) > <!--subdocument: bib data--> <!ELEMENT sdobi-bibliographic-data (b000-wo,b200-filing-info,b300-priority-info, b500-search-report,b590-drawings,b700-parties) > <!--subdocument claims--> <!ELEMENT sdocl-claims (b0603wo-claims) > <!--specification or description of the invention.--> <!ELEMENT sdode-description (title-of-invention,related-documents?, background-of-invention?,summary-of-invention?, brief-description-of-drawings?,detailed-description, program-listing-deposit?,appendix-data?,seuence-listing?) > <!--subdocument drawings.--> <!ELEMENT sdodr-drawings (b0605wo-drawings) > <!ELEMENT section (heading,(paragraph list section seuence chemistry math table)+) > <!ELEMENT seuence (seuence-identification) > <!ELEMENT seuence-fragment (#PCDATA seuence-identification)* > <!ELEMENT seuence-identification (#PCDATA) > <!ELEMENT seuence-listing (heading,seuence+) > <!--an external file containing either: an image of a page to which the party s signature has been affixed, or an image of the party s signature alone.--> <!ELEMENT signature-file EMPTY >

Annexe 5, page 105 <!--a text string representing the party s mark.--> <!ELEMENT signature-mark (#PCDATA) > <!ELEMENT state (#PCDATA) > <!--street--> <!ELEMENT street (#PCDATA) > <!ELEMENT subscript (#PCDATA) > <!ELEMENT summary-of-invention (heading,(paragraph list section seuence chemistry math table)+) > <!ELEMENT superscript (#PCDATA) > <!ELEMENT table (heading,tgroup+) > <!ELEMENT tbody (row+) > <!--telephone number--> <!ELEMENT telephone (#PCDATA) > <!ELEMENT tgroup (colspec*,thead?,tbody) > <!ELEMENT thead (row+) > <!ELEMENT title-at-organization (#PCDATA) > <!ELEMENT title-of-invention (#PCDATA emphasis superscript subscript)* > <!--Flag: a digital signature is used.--> <!ELEMENT use-digital-signature EMPTY > <!ATTLIST address-1 text CDATA #FIXED [address: ] > <!ATTLIST address-2 text CDATA #FIXED [address: ] > <!ATTLIST application-reference hytime CDATA #FIXED hylink > <!ATTLIST artwork id ID #REQUIRED source ENTITY #REQUIRED size (a4 letter) letter color (black-and-white color) > #FIXED black-and-white <!ATTLIST biological-deposit id ID #REQUIRED type (original replacement supplemental) corroboration ENTITY #IMPLIED viability ENTITY #IMPLIED > #IMPLIED <!ATTLIST biological-deposit-data id ID #REQUIRED > <!ATTLIST chemistry

Annexe 5, page 106 id ID #IMPLIED source ENTITY #REQUIRED display (display) #IMPLIED > <!ATTLIST claim id ID #REQUIRED > <!ATTLIST claim-step class CDATA #FIXED paragraph > <!ATTLIST colspec colnum CDATA #IMPLIED colname CDATA #IMPLIED colwidth CDATA #IMPLIED colsep CDATA #IMPLIED rowsep CDATA #IMPLIED align (left right center justify char) char CDATA #IMPLIED charoff CDATA #IMPLIED > #IMPLIED <!ATTLIST copyright class CDATA #FIXED primitive > <!ATTLIST cross-reference hytime CDATA #FIXED hylink anchrole CDATA #FIXED mention target mention IDREF #IMPLIED target IDREFS #REQUIRED linktrav CDATA #FIXED e e anchcstr CDATA #FIXED #self #REQUIRED EMPTYanc CDATA #FIXED error error reftype CDATA #FIXED target (seuence-listing chemistry math table ireftype CDATA #FIXED target (seuence-listing chemistry math table > <!ATTLIST custom-character source ENTITY #IMPLIED > <!ATTLIST dependent-claim-reference hytime CDATA #FIXED hylink class CDATA #FIXED reference depends_on IDREFS #REQUIRED data-format CDATA #FIXED claim-number > <!ATTLIST deposit-accession-number text CDATA #FIXED [deposit accession number: ] > <!ATTLIST deposit-date text CDATA #FIXED [deposit date: ] > <!ATTLIST deposit-description text CDATA #FIXED [deposit description] > <!ATTLIST deposit-reference

Annexe 5, page 107 hytime CDATA #FIXED hylink > <!ATTLIST deposit-term text CDATA #FIXED [deposit term: ] > <!ATTLIST drawing-reference-character id ID #IMPLIED > <!--ti, type of image: ad = abstract drawing cf = chemical formulae ci = clipped image cp = computer program listings dn = dna seuences dr = drawings ff = undefined characters fg = figures gr = graphs mf = mathematical formulae pa = full-page facsimile image ph = photograph sr = search report form tb = table or tabular data tx = text character [deprecated in us documents] ui = undefined image [deprecated in us documents]--> <!ATTLIST embedded-image id ID #REQUIRED he NMTOKEN #IMPLIED wi NMTOKEN #IMPLIED file ENTITY #REQUIRED lx NMTOKEN #IMPLIED ly NMTOKEN #IMPLIED imf (st33 tiff) #IMPLIED ti (ad cf ci cp dn dr fg ff gr mf pa ph sr tb tx ui) #IMPLIED > <!ATTLIST entry colname NMTOKEN #IMPLIED namest NMTOKEN #IMPLIED nameend NMTOKEN #IMPLIED morerows CDATA #IMPLIED colsep CDATA #IMPLIED rowsep CDATA #IMPLIED align (left right center justify char) char CDATA #IMPLIED charoff CDATA #IMPLIED valign (top middle bottom) #IMPLIED > #IMPLIED <!ATTLIST family-name class CDATA #FIXED primitive label CDATA #FIXED [family name:] > <!ATTLIST figure id ID #REQUIRED view (alternate exploded modified partial sectional) #IMPLIED > <!ATTLIST heading id ID #REQUIRED >

Annexe 5, page 108 <!ATTLIST hybrid-claim-reference hytime CDATA #FIXED hylink depends_on IDREFS #REQUIRED class CDATA #FIXED reference data-format CDATA #FIXED claim-number > <!ATTLIST list <!ATTLIST math id ID #REQUIRED > source ENTITY #IMPLIED class CDATA #IMPLIED style CDATA #IMPLIED id ID #IMPLIED other CDATA #IMPLIED macros CDATA #IMPLIED mode CDATA #IMPLIED type CDATA #IMPLIED name CDATA #IMPLIED height CDATA #IMPLIED width CDATA #IMPLIED baseline CDATA #IMPLIED overflow (scroll elide truncate scale) scroll altimg CDATA #IMPLIED alttext CDATA #IMPLIED > <!ATTLIST middle-name class CDATA #FIXED primitive label CDATA #FIXED [middle initial:] > <!ATTLIST name-suffix class CDATA #FIXED primitive label CDATA #FIXED [name suffix:] > <!ATTLIST organization-name class CDATA #FIXED primitive label CDATA #FIXED [organization name:] > <!ATTLIST paragraph id ID #REQUIRED > <!ATTLIST paragraph-claim class CDATA #FIXED paragraph > <!ATTLIST patent-reference hytime CDATA #FIXED hylink data-format CDATA #FIXED patent-number > <!ATTLIST pct-international-application dtdv CDATA #REQUIRED > <!ATTLIST program-listing id ID #REQUIRED xml:space (default preserve) > #FIXED preserve <!ATTLIST program-reference id ID #REQUIRED >

Annexe 5, page 109 <!ATTLIST row rowsep CDATA #IMPLIED valign (top middle bottom) #IMPLIED > <!ATTLIST section id ID #REQUIRED > <!ATTLIST seuence id ID #REQUIRED submission ENTITY #IMPLIED > <!--the type of signature file. digital = digital certificate page = image of page on which the signature has been written scrawl = image of the signature only--> <!ATTLIST signature-file type (digital page scrawl) #REQUIRED > <!ATTLIST state text CDATA #FIXED [state: ] > <!ATTLIST table frame (top bottom topbot all sides none) colsep CDATA #IMPLIED rowsep CDATA #IMPLIED pgwide CDATA #IMPLIED id ID #REQUIRED > #IMPLIED <!ATTLIST tbody valign (top middle bottom) #IMPLIED > <!ATTLIST tgroup cols CDATA #REQUIRED colsep CDATA #IMPLIED rowsep CDATA #IMPLIED align (left right center justify char) #IMPLIED > <!ATTLIST thead valign (top middle bottom) #IMPLIED > <!ATTLIST title-at-organization class CDATA #FIXED primitive label CDATA #FIXED [title:] > <!ATTLIST title-of-invention id ID #REQUIRED > ]> [L annexe 6 suit]