europaisches european office europeen patentamt patent...

Europaisches Patentamt

Elektronische Einreichung von europaischen Patentanmeldungen

Beilage zum Amtsblatt Nr.4/2001

ISSN 0170/9291

European Patent Office

The electronic filing of European patent applications

Supplement to Official Journal No. 4/2001

Office europeen des brevets

Depot electronique de demandes de brevet europeen

Supplement au Journal officiel nO 4/2001

Amtsblatt des Europaischen Patentamts

Herausgeber und Schriftleitung Europaisches Patentamt Direktion 5.2.2 D-80298 Munchen ~ (+49-89) 2399-5225 Fax: (+49-89) 2399-5219 E-Mail: [email protected]

Fur den Inhalt verantwortlich Direktion 4.1 .9

© EPA

Bestellungen sind zu richten an: Europaisches Patentamt Dienststelle Wien Postfach 90 A-1031 Wien ~ (+43-1) 521 26-411 Fax: (+43-1) 52126-3591 E-Mail: [email protected]

Druck Druckerei Schuler AG Jurastrasse 10 CH - 2501 Biel ~ (+41-32) 3292727 Fax: (+41-32) 329 27 37 E-Mail: [email protected]

Official Journal of the European Patent Office

Published and edited by European Patent Office Directorate 5.2.2 D-80298 Munich ~ (+49-89) 2399-5225 Fax: (+49-89) 2399-5219 E-mail: [email protected]

Responsible for the content Directorate 4.1.9

© EPO

Please send your order to: European Patent Office Vienna sub-office P. O. Box 90 A-1031 Vienna ~ (+43-1) 52126-411 Fax: (+43-1) 52126-3591 E-mail: [email protected]

Printer Druckerei Schuler AG Jurastrasse 10 CH - 2501 Biel ~ (+41-32) 329 27 27 Fax: (+41-32) 32927 37 E-mail: [email protected]

Journal officiel de l'Office europeen des brevets

Publication et redaction Office europeen des brevets Direction 5.2.2 D-80298 Munich ~ (+49-89) 2399-5225 Fax: (+49-89) 2399-5219 E-mail : [email protected]

Responsable de la redaction Direction 4.1 .9

©OEB

Les commandes doivent etre adressees a : Office europeen des brevets Agence de Vienne BoTte postale 90 A-1031 Vienne ~ (+43-1) 52126-411 Fax: (+43-1) 52126-3591 E-mail: [email protected]

Impression Druckerei Schuler AG Jurastrasse 10 CH - 2501 Biel ~ (+41-32) 329 27 27 Fax: (+41-32) 329 27 37 E-mail: info@schueler-printing .ch

8eilage zum Amtsblatt Nr. 4/2001 / Supplement to Official Journal No. 4/2001 / Supplement au JournClI officiel n° 4/2001 Seiten / Pages / pages 1 - 65

Inhalt Contents Sommaire

- BeschluB des Prasidenten des Euro- - Decision of the President of the - Decision du President de l'Office paischen Patentamts vom 7. Dezem- European Patent Office dated europeen des brevets du 7 decembre ber 2000 uber die elektronische 7 December 2000 on the electron ic 2000, relative au depot electronique Einreichung von europaischen filing of European patent applications de demandes de brevet europeen et Patentanmeldungen und anderen and subsequent documents 23 de documents produits Unterlagen 1 ulterieurement 45

- Technischer Standard fUr die elek- - Technical standard for the elec- - Norme technique relative au depot tronische Einreichung von europai- tronic filing of European patent electronique de demandes de brevet schen Patentanmeldungen und applications and subsequent europeen et de documents produits anderen Unterlagen 5 documents 27 ulterieurement 49

1. Hintergrund 5 1. Background 27 1. General ites 49

2. Umfang 5 2. Scope 27 2. Portee 49

3. Sicherheit und PKI 5 3. Security and PKI 27 3. Securite et ICP 49 3.1 Public Key Infrastructure 5 3.1 Public Key Infrastructure 27 3.1 Infrastructure a cle publique 49 3.2 Digitale Zertifikate 5 3.2 Digital certificates 27 3.2 Certificats numeriques 49 3.3 Zertifizierungsstellen 5 3.3 Certification authorities 27 3.3 Autorites de certification 49 3.4 Digitale Signaturen 5 3.4 Digital signatures 27 3.4 Signatures numeriques 49 3.5 Verschlusselungsalgorithmen 6 3.5 Cryptographic algorithms 28 3.5 Algorithmes

cryptographiques 50 3.6 Versiegelung der Daten 6 3.6 Data enveloping 28 3.6 Enveloppement des donnees 50 3.7 Hash-Algorithmen 6 3.7 Message digest algorithms 28 3.7 Algorithmes de compactage 50

4. Signaturverfahren 6 4. Signature mechanisms 28 4. Mecanismes de signature 50 4.1 Faksimile-Abbildung 7 4.1 Facsimile signature 29 4.1 Signature en fac-simile 51 4.2 Zeichenkette 7 4.2 Text string signature 29 4.2 Signature composee d'une

chaine de caracteres 51 4.3 Digitale Signatur gemaB 4.3 PKCS#7 digital signature 29 4.3 Signature numerique PKCS#7 51 PKCS#7 7

5. Datenformat 7 5. Data format requirements 29 5. Exigences en matiere de format des donnees 51

5.1 Vorbereitung der Dokumente 7 5.1 Document preparation 29 5.1 Preparation des documents 51 5.2 Bundelung der Dokumente 8 5.2 Wrappring documents 30 5.2 Compactage des documents 52 5.3 Signatur der gebundelten 5.3 Signing wrapped application 5.3 Signature des documents Anmeldungsunterlagen 9 documents 31 constitutifs de la demande,

compactes 53

6. Ei.!1reichung 12 6. Submission 34 6. Envoi 56 6.1 l,Jbertragungspaket 12 6.1 Transmission package 34 6.1 Paquet de transmission 56 6.2 l,Jbertragungsverfahren 15 6.2 Transmission mechnism 37 6.2 Mecanisme de transmission 59 6.3 Ubertragungsprotokoll 16 6.3 Transmission protocol 38 6.3 Protocole de transmiss ion 60

7. Datentrager 16 7. Physical media 38 7. Supports materiels 60

2001 Beilage zum Amtsblatt Nr. 4/2001 / Supplement to Official Journal No. 4/2001 / Supplement au Journal officiel n° 4/2001

BeschluB des Prasidenten des Europaischen Patentamts vom 7. Dezember 2000 fiber die elektronische Einreichung von europaischen Patentanmeldungen und anderen Unterlagen

Der Prasident des Europaischen Patentamts (EPA), gestutzt auf.die Regeln 24 (1), 27a, 35 (2), 36 (5), 77 (2) d) und 101 EPU

und auf die fur aile elektronischen Datensatze geltenden Grundanforderungen:

a) Authentizitat, d. h. die Bestatigung, daIS ein Dokument tatsachlich das Dokument ist, das es vorgeblich sein soil, und tatsachlich von der Person stammt, die vorgeblich der Autor sein soil

b) Integritat, d. h. die Unversehrtheit der Daten und insbesondere die Garantie, daIS jede unberechtigte Veranderung oder Zerstbrung aufgedeckt und verhindert werden kann

c) Vertraulichkeit, d. h. die Sicherstellung, daIS die Existenz eines Dokuments oder sein Inhalt Nichtberechtigten nicht zur Kenntnis gelangt

d) Verbindlichkeit, d. h. die Sicherstellung, daIS der Absender (unter Mithilfe des Empfangers) einen zuverlassigen Nachweis uber den Eingang der Daten und der Empfanger einen zuverlassigen Nachweis der Identitat des Absenders erhalt, damit weder der Absender noch der Empfanger das Senden bzw. den Empfang der Daten abstreiten und ein Dritter ihre Integritat und ihren Ursprung uberprufen kann

sowie auf die folgenden grundlegenden Standards fur die Verwaltung elektronischer Datensatze:

(1) Aile elektronisch eingereichten Unterlagen mussen sich in Papierform ausdrucken sowie verlustfrei und unverandert auf ein Archivierungsmedium ubertragen lassen.

(2) Von den automatischen Systemen routinemalSig erfalSte Informationen uber die Datensatze, sogenannte Metadaten, sind als Teil des elektronischen Datensatzes zu behandeln und durch die automatischen Systeme zu speichern.

(3) Elektronische Dokumente sind in einem yom Amt festzulegenden elektronischen Dateiformat zu ubermitteln; ihre Archivierung hat ebenfalls in dem elektronischen Format zu erfolgen, in dem sie ubermittelt wurden.

(4) Der Absender einer elektronischen Eingabe mulS eine Empfangsbestatigung erhalten, aus der hervorgeht, daIS das Amt die Unterlagen erhalten hat. Diese Empfangsbestatigung mulS eine Identifikation des Amts sowie Datum und Uhrzeit des Eingangs (die dann als offizieller Zeitpunkt des Eingangs beim Amt gelten) enthalten und mit einer yom Amt gegebenenfalls vergebenen Referenzoder Anmeldenummer versehen sein.

(5) Jedes Amt, das die elektrqnische Einreichung gestattet, mulS auch die Einreichung in Papierform zulassen. Diese Papierunterlagen kbnnen anschlielSend gescannt werden, damit aile Unterlagen in einer einzigen elektronischen Akte abgelegt werden kbnnen.

(6) Es sind Vorkehrungen zu treffen, um die Authentizitat und Integritat der e ~ ektronisch eingereichten Unterlagen sicherzustellen. Zu diesem Zweck ist eine Mbglichkeit vorzusehen, die Identitat des Absenders (Anmelder oder bevollmachtigter Vertreter) zu uberprufen und jede nach seiner Einreichung vorgenommene unberechtigte Veranderung eines Dokurnents festzustellen.

(7) Systeme fur die elektronische Einreichung mussen die Erstellung von Sicherungskopien und die Wiederherstellung von Daten gestatten, um elektronische Einreichungen gegen Systemausfalle zu schutzen.

(8) Die elektronischl9n Datensatze sind so abzulegen, daIS sie auf lange Zeit gespeichert und zugriffsbereit sind.

(9) Elektronische Dateien sind vor ihrer Bearbeitung auf Computerviren oder andere Arten bbsartiger Software zu prufen; gegebenenfalls sind geeignete MalSnahmen zu ergreifen, um den Anmeldetag aufrechtzuerhalten.

(10) Der Zugang zu den fur die elektronische Einreichung genutzten Rechnern darf die Sicherheit anderer Computernetzwerke oder -anwendungen des Amts nicht gefahrden.

(11) Systeme fur die Verwaltung elektronischer Datensatze mussen Mbglichkeiten fur die Qualitatssicherung und -kontrolle der eingereichten Unterlagen bieten.

(12) Die Systeme fur die Verwaltung elektronischer Datensatze mussen jegliche Erganzungen oder Veranderungen der elektronischen Datensatze nachvollziehbar protokollieren, indem sie Eingangsinformationen oder sonstige Informationen uber die Erstellung und jedwede Veranderung der Datensatze aufzeichnen.

(13) Sind vertrauliche Daten auf elektronischem Weg zuganglich, so ist der Zugang entsprechend zu sichern und darf nur berechtigten Nutzern offenstehen. Die Dateien sind durch geeignete MalSnahmen gegen etwaige Veranderungen zu schutzen. Jeder Zugriff durch Anmelder, Vertreter oder andere berechtigte Personen mit elektronischen Mitteln ist durch Angaben uber die Identitat des Zugreifenden, clas Datum (und wahlweise die Uhrzeit) des Zugriffs sowie Einzelheiten aller eingereichten Dokumente zu dokumentieren. Diese Angaben sind als vertrauliche Daten abzulegen.

(14) Der Offentlichk'9it ist in dem im EPU vorgesehenen Umfang Zugang zu den verbffentlichten europaischen Patentanmeldungen und Patenten zu gewahren.

(15) Aile elektronisch eingereichten Unterlagen sind bei Eingang auf einem schreibgeschutzten Datentrager zu speichern.

beschlielSt:

Artikel1 Einreichung europiiischer Patentanmeldungen

Europaische Patentanmeldungen kbnnen beim EPA in elektronischer Form wie folgt eingereicht werden:

a) online uber die Computer-Server des Europaischen Patentamts unter folgender Adresse: https://secure.epoliine.org

b) auf CD-R.

2 8eilage zum Amtsblatt Nr. 4/2001 / Supplement to Official Journal No. 4/2001 / Supplement au Journal officiel nO 4/2001 2001

Europaische Patentanmeldungen konnen auch bei den zustandigen nationalen Behorden der Vertragsstaaten, die dies gestatten, in elektronischer Form eingereicht werden. Die nationalen Vorschriften der Vertragsstaaten, die die Einreichung von Erstanmeldungen beim nationalen Amt vorschreiben oder die die Einreichung bei einer anderen Behorde von einer vorherigen Zustimmung abhangig machen (Artikel 75 (2) EPU), bleiben unberuhrt.

Artikel2 Standard fiir die elektronische Einreichung

Der technische Standard fur die elektronische Einreichung, der als Anhang zu diesem Beschlu~ wiedergegeben ist (im folgenden "Standard" genannt), ist Bestandteil dieses Beschlusses. Jede kunftige uberarbeitete Fassung dieses Standards oder jeder kunftige, von der Weltorganisation fur geistiges Eigentum fur die Einreichung nationaler Patentanmeldungen empfohlene Standard erlangt mit der Veroffentlichung eines entsprechenden Beschlusses des Prasidenten des Europaischen Patentamts Gultigkeit.

Artikel3 Anfertigung von Unterlagen

Nach Artikel 1 eingereichte Unterlagen sind unter Verwendung von Software anzufertigen, die entweder yom EPA gebuhrenfrei zur Verfugung gestellt wird oder laut Bestatigung des EPA dem Standard entspricht.

Artikel4 Form der Unterlagen

Die nach Artikel 1 eingereichten Unterlagen der europaischen Patentanmeldung einschlie~lich aller Zeichnungen mussen dem im Standard vorgegebenen Format entsprechen. Bei Anmeldungen, die nach Artikel 1 a) eingereicht werden und ein Sequenzprotokoll umfassen, braucht dieses nicht auf einem separaten Datentrager eingereicht zu werden.

Artikel5 Erteilungsantrag

Ein nach Artikel 1 eingereichter Antrag auf Erteilung eines europaischen Patents soil zusatzlich zu den Angaben gema~ Regel 26 (2) EPU die elektronische Anschrift des Anmelders und gegebenenfalls des bestellten Vertreters enthalten.

Artikel6 Lesbarkeit Infizierte Dateien

(1) Sofort nach ihrem Eingang pruft das EPA nach Artikel 1 eingereichte europaische Patentanmeldungen dahingehend, ob sie

a) lesbar sind,

b) Computerviren oder andere Arten bosartiger Software enthalten.

(2) 1st eine europaische Patentanmeldung ganz oder teilweise unlesbar, so erachtet das EPA den Teil der Unterlagen, der unlesbar ist, als nicht eingegangen und wird nach Moglichkeit den Anmelder unverzuglich unterrichten.

(3) Stellt sich hera us, da~ die europaische Patentanmel dung mit einem Computervirus infiziert ist oder andere bosartige Software enthalt, so erachtet das EPA sie als nicht lesbar und ist nicht verpflichtet, sie zu offnen oder zu bearbeiten. Das EPA versucht mit allen ihm zur Verfugung stehenden Mitteln, die Einreichung zu lesen, um einen Anmeldetag zuerkennen zu konnen. Es benachrichtigt den Anmelder nach Moglichkeit unverzuglich.

(4) Werden in del' europaischen Patentanmeldung Mangel nach den Absatzen 2 oder 3 festgestellt und kann ein Anmeldetag deshalb nicht zuerkannt werden, so fordert das EPA den Anmelder nach Moglichkeit auf, die festgestellten Mangel innerhalb einer yom EPA zu bestimmenden Frist zu beseitigen. Der Anmeldetag ist der Tag, an dem die Man~lel beseitigt sind. Werden die Mangel nicht rechtzeitig beseitigt, so wird die Anmeldung nicht als europaische Patentanmeldung behandelt.

Artikel7 Priifung bestimmter Formerfordernisse

Wird die europaische Patentanmeldung in einem Format eingereicht, das nicht Artikel 4 entspricht, so ergreift das EPA angemessene Ma~nahmen, um die Einreichung zu lesen und ihr einen Anmeldetag zuzuerkennen. Scheitert dies, findet Artikel 6 (4) Anwendung. Gelingt dies, so ist der Anmelder aufzufordern, die Anmeldung innerhalb einer yom EPA zu bestimmenden Frist in dem in Artikel 4 vorgegebenen Format erneut einzureichen. Wird die Anmeldung nicht fristgerecht im vorgegebenen Format .. vorgelegt, so ist sie nach Ma~gabe des Artikels 91 (3) EPU zuruckzuweisen.

Artikel8 Einreichung anderer Unterlagen

Wird die europaische Patentanmeldung nach Ma~gabe des Artikels 1 eingereicht, konnen Vollmachten und Erfindernennung ebenfalls nach Ma~gabe des Artikels 1 eingereicht werden. Die Artikel 3, 4 und 6 finden Anwendung. Werden diese Unterlagen in einem Format eingereicht, das nicht Artikel 4 entspricht, so ist der Anmelder aufzufordern, sie innerhalb einer yom EPA zu bestimmenden Frist in dem in Artikel 4 vorgegebenen Format erneut einzureichen. Wird eine Vollmacht nicht fristgerecht im vorgegebenen Format vorgelegt, so findet Regel 101 (4) EPU Anwendung. Wird eine Erfindernennung nicht fristgerecht im vorgegebenen Format vorgelegt, so findet Artikel 91 (5) EPU Anwendung.

Artikel9 Originale - Stiickzahl Rechtlich maf3gebliche Fassung

(1) Nach den Artikeln 1 und 8 eingereichte Unterlagen gelten fur aile weiteren Verfahren vor dem Europaischen Patentamt als Originale und sind in einem Stuck einzureichen.

(2) 1st ein Dokument auf CD-R nach Artikel 1 oder 8 eingereicht worden, so gilt die elektronische Fassung, die das EPA an hand der CD-R erstellt hat und die in der elektroni schen Akte der europaischen Anmeldung aufbewahrt wird, als die rechtlich ma~gebliche Fassung des Dokuments. 1m Fall des Bestreitens konnen Uberprufungen anhand der ursprunglichen CD-R durchgefuhrt werden, die fur die in Regel 95a EPU vorgesehene Zeitdauer aufzubewahren ist.

2001 Beilage zum Amtsblatt Nr. 4/2001 / Supplement to Official Journal No. 4/2001 / Supplement au Journal officiel nO 4/2001 3

Artikel10 Papierunterlagen zur Bestatigung

(1) Fur die nach den Artikeln 1 und 8 eingereichten Unterlagen sind keine Papierunterlagen zur Bestatigung nachzureichen.

(2) Dennoch nachgereichte Papierunterlagen werden vom EPA nicht berucksichtigt, sofern es nicht ausdrucklich vom Anmelder darum gebeten wird. Eine Berucksichtigung dieser Papierunterlagen kann eine Anderung des Anmeldetags zur Foige haben.

(3) Nachgereichte Papierunterlagen mussen eindeutig als solche gekennzeichnet sein und entsprechende Angaben enthalten, anhand deren das EPA sie der betreffenden elektronischen Einreichung zuordnen kann.

Artikel11 Unterschriften

(1) Fur nach Artikel 1 eingereichte europaische Patentanmeldungen ist die im Antrag auf Erteilung eines europaischen Patents geforderte Unterschrift in einer der folgenden Formen zu erstellen:

a) Faksimile-Abbildung der eigenhandigen Unterschrift des Unterzeichners

b) elektronische Signatur, d. h. Daten in elektronischer Form, die anderen elektronischen Daten (Nachricht) be igefUgt oder logisch mit ihnen verknupft sind und dazu dienen, den Unterzeichner im Zusammenhang mit der Nachricht zu authentifizieren und sein Einverstandnis mit dem Inhalt der Nachricht zu dokumentieren, oder

c) fortgeschrittene elektronische Signatur, d. h. eine elektronische Signatur, die folgende Anforderungen erfullt:

i) Sie ist ausschlie~lich dem Unterzeichner zugeordnet.

ii) Sie wird mit Mitteln erstellt, die der Unterzeichner unter seiner alleinigen Kontrolle halten kann.

iii) Sie ist so mit den Daten, auf die sie sich bezieht, verknupft, da~ eine nachtragliche Veranderung der Daten erkannt werden kann.

(2) Eine elektronische Signatur im Sinne des Absatzes 1 b) ist eine Kette von Zeichen, vor und hinter der ein Schragstrich (/) steht und die der Unterzeichner zum Nachweis seiner Identitat sowie seiner Absicht, die jeweilige Nachricht abzuzeichnen, gewahlt hat.

(3) Eine fortgeschrittene elektronische Signatur im Sinne des Absatzes 1 c) ist eine digitale Signatur, die mit einem Public-Key-Infrastructure-generierten Zertifikat und einem entsprechenden privaten Schlussel erstellt wird.

(4) In allen ubrigen Fallen, .in denen gema~ EPU eine Unterschrift gefordert ist, mu~ das ubermittelte Datenpaket durch eine fortgeschrittene elektronische Signatur im Sinne der Absatze 1 c) und 3 signiert sein . Einzelne Unterlagen des Datenpakets ki:innen auch nach Ma~gabe des Absatzes 1 a) oder der Absatze 1 b) und 2 signiert sein.

(5) Fehlt im Antrag auf Erteilung eines europaischen Patents oder in sonstigen Unterlagen, die sich auf eine europaische Patentanmeldung beziehen und nach Artikel 1 a) eingereicht wurden, die Unterschrift des Anmelders oder genugt diese nicht den Anforderungen der jeweils zutreffenden Absatze 1 bis 4, so fordert das EPA

den Anmelder auf. die festgestellten Mangel innerhalb einer vom EPA zu bestimmenden Frist zu beseitigen . Werden die Mangel nicht fristgerecht beseitigt, so gilt das Datenpaket als nicht eingegangen .

(6) Europaischen Patentanmeldungen und sonstigen Unterlagen, die auf CD-R eingereicht werden, ist eine Unterlage in Papierform mit einer eigenhandigen Unterschrift beizufugen, die den Anmelder und seinen Vertreter ausweist, eine Zustellanschrift angibt und die auf der CD-R gespeicherten Dateien auflistet.

Artikel12 Empfangsbestiitigung

(1) Der Empfang der nach Artikel 1 a) eingereichten Unterlagen ist wahrend des Ubertragungsvorgangs ~!ektro nisch zu bestatigen" Stellt sich heraus, da~ die Ubermittlung einer solchen Bestatigung fehlgeschlagen ist, so ubermittelt das EPA die Bestatigung unverzuglich auf anderem Wege, sofern die ihm vorliegenden Angaben dies gestatten.

(2) Diese Empfangsbestatigung mu~ eine Identifikation des Amts, Datum und Uhrzeit des Eingangs, eine vom Amt vergebene Referenz- oder Anmeldenummer sowie eine Liste der ubermittelten Dateien enthalten. Die Bestatigung mu~ ferner einen sogenannten Message-Digest, d. h. die Nachricht in komprimierter Form, umfassen.

(3) Die Bestatigung des Empfangs ist nicht gleichbedeutend mit der Zuerkennung eines Anmeldetags.

Artikel13 Gebiihrenzahlungen

Die Regelungen fUr Gebuhrenzahlungen bleiben von diesem Beschlu~ unberuhrt.

Artikel14 EPA-Bescheide und Mitteilungen

Das EPA bestimmt, welche Bescheide und Mitteilungen online zugestellt werden konnen. Die Anmelder mussen bei Einreichung der europaischen Patentanmeldung angeben, ob und welche Bescheide und Mitteilungen ihnen online zugestellt werden soli en. Anderenfalls werden aile Bescheide und Mittleilungen bis auf weiteres in Papierform zugestellt.

Artikel15 Zustellungen

(1) Fur die Zustellung von Bescheiden und .. Mitteilungen in Papierform gelten die Regeln 78 bis 80 EPU .

(2) Werden Bescheide und Mitteilungen online zugestellt, so setzt das EPA den Anmelder daruber in Kenntnis, da~ ein Bescheid oder eine Mitteilung zum Abruf durch ihn bereitsteht. Dies erfolgt im Wege einer E-Mail an den Anmelder mit einer Verknupfung zur Mailbox des Anmel ders auf dem EPA-Server. Wird ein Bescheid oder eine Mitteilung nicht innerhalb von fUnf Tagen nach Absenden der E-Mail abgerufen, wird eine Kopie in Papierform nach Absatz 1 zugestellt.

(3) Nach Absatz 2 zugestellte Bescheide und Mitteilungen gelten als am zehnten Tag nach dem Absendedatum der E-Mail eingegangen.

(4) Die Bestimmungen der Regeln 81 und 82 EPU bleiben unberuhrt.

4 8eilage zum Amtsblatt Nr. 4/2001 / Supplement to Official Journal No. 4/2001 / SUlPplement au Journal officiel nO 4/2001 2001

Artikel16 Fristen

Es gelten die Regeln 83 bis 85 EPU. Nur diejenigen Anmelder, die einer Online-Zustellung zugestimmt haben, konnen auch Fristverlangerungen online beantragen.

Artikel17 Inkrafttreten

Dieser Beschlu[S tritt am 8. Dezember 2000 in Kraft.

Geschehen zu Munchen am 7. Dezember 2000.

Ingo KOBER Prasident


Technischer Standard fur die elektronische Einreichung von europaischen Patentanmeldungen und anderen Unterlagen

1. Hintergrund

Das vorliegende Dokument enthiilt die technischen Standards fur die elektronische Einreichung von Dokumenten beim EPA. Sie basieren auf dem im Rahmen der dreiseitigen Zusammenarbeit vereinbarten PKI-Standard (Public Key Infrastructure), der in Anlage F Anhang I der Verwaltungsvorschriften zum PCT aufgenommen worden ist.

Eine PKI-Umgebung bietet verschiedene Moglichkeiten zur Verarbeitung vertraulicher Informationen und wird aufgrund der Verschlusselung der Daten folgenden Erfordernissen gerecht: a) Authentizitiit: Es wird sichergestellt, da~ Ubermittlungen, Nachrichten und Absender echt sind und ein Empfiinger berechtigt ist, bestimmte Kategorien von Informationen zu erhalten. b) Datenintegritiit: Es wird gewiihrleistet, da~ die Ausgangsdaten unversehrt sind und nicht versehentlich oder mutwillig geiindert, verfiilscht oder zerstort wurden. c) Nachweisbarkeit: Ausreichend schlussige und zuverliissige Nachweise bieten dem Absender von Daten (unter Mithilfe des Empfiingers) die Gewiihr, da~ die Daten zugestellt wurden, und verschaffen dem Empfiinger Gewi~heit uber die Identitiit des Absenders, so da~ keiner von beiden abstreiten kann, im Besitz der Daten gewesen zu sein, und auch Dritte die Integritiit und die Herkunft der Daten uberprufen konnen. d) Vertraulichkeit: Es wird gewiihrleistet, da~ die Informationen nur von Berechtigten eingesehen werden konnen.

Dieser Standard umfa~t neben den obligatorischen Erfordernissen fur aile an der elektronischen Einreichung beteiligten Parteien auch eine Reihe fakultativer Erfordernisse.

2. Umfang

Dieser technische Standard deckt die Erfordernisse in folgenden Bereichen ab: a) Sicherheit und PKI b) elektronische Signatur c) Dokumentenformat d) Einreichung

3. Sicherheit und PKI

3.1 Public Key Infrastructure 1m Rahmen dieses Standards wird das Datenpaket nach der PKI-Technologie zusammengestellt und ubertragen. Wenn kunftig andere praktikable Sicherheitstechnologien zur Verfugung stehen, konnen diese in aktualisierte Fassungen des Standards aufgenommen werden.

Die Umsetzung von PKI-Systemen mu~ den Empfehlungen entsprechen, die von der Working Group on PKI Interoperability (PKIX) der Internet Engineering Task Force (IETF) aufgestellt wurden und in IETF RFC 2459 dokumentiert sind.

Fur die digitale Signatur und die Verschlusselung mussen jeweils eigene Schlusselpaare und digitale Zertifikate verwendet werden.

3.2 Digitale Zertifikate Soweit in diesem Standard die Verwendung digitaler Zertifikate vorgesehen ist, mussen diese der ITU-Empfehlung X.509 Version 3 zum Format von Zertifikaten entsprechen (lTU = International Telecommunication Union).

Fur die Online-Kommunikation mit dem EPA ist ein digitales Zertifikat erforderlich.

Der Standard sieht zwei Kategorien digitaler Zertifikate vor:

Hochwertiges Zertifikat: Digitales Zertifikat, das eine Zertifizierungsstelle dern Anmelder ausstellt und das zur Authentifizierung dler Identitiit des Anmelders verwendet werden kann. Die Zertifizierungsstelle mu~ in der vom EPA veroffentlichten Liste der anerkannten Zertifizierungsstellen aufgefuhrt sein (siehe 3.3).

Einfaches Zertifikat: Digitales Zertifikat, das das EPA dem Anmelder auf Antrag ausstellt. Fur ein salches einfaches Zertifikat mu~ der Anmelder seinen Namen und seine E-Mail-Adresse angeben, seine Identitiit aber nicht nachweisen.

3.3 Zertifizierungss;tellen Das EPA legt fest, welche Zertifizierungsstellen es anerkennt. Die Liste der anerkannten Zertifizierungsstellen wird auch einen Link zu den veroffentlichten PKI-Richtlinien dieser Zertifizierungsstellen umfassen.

Eine anerkannte Zertifizierungsstelle mu~ fortlaufend die Richtigkeit der elektronischen Zertifikate gewiihrleisten, die "nachweisen", da~ der Betreffende tatsiichlich derjenige ist, der er zu sein behauptet. Die Zertifizierungsstelle archiviert die Zertifizierungsdaten fur aile von ihr ausgestellten Zertifikate in einer Verzeichnisstruktur, die der ITU-Empfehlun!g X.500 entspricht. Fur die Veroffentlichung und den Abruf digitaler Benutzerzertifikate gibt es eine externe Schnittstelle entsprechend dem Lightweight Directory Access Protocol (LDAP) und RFC 1777 der IETF Network Working Group yom Miirz 1995. AuBerdem veroffentlicht die Zerti1fizierungsstelle Daten zur Sperrung von Zertifikaten gemii~ dem Standard X.509.

Diese Sperrdaten werden yom EPA regelmiiBig bezogen . Wird ein Zertifikat zur Authentifizierung einer Einzelperson verwendet, so konsultiert das EPA die von der betreffenden Zertifizierungsstelle veroffentlichten Sperrdaten, um sich zu vergewissern, daB das Zertifikat nicht gesperrt wurde.

3.4 Digitale Signatmen Digitale Signaturen, die bei der elektronischen Einreichung zur Unterzeichnung elektronischer Dokumente verwendet werden, mijssen in Format und Anwendung der Definition des Datentyps "signierte Daten" unter "signed data content type" in der Version 1.5 des von RSA Laboratories festgelegten Standards PKCS#7 zur Syntax verschlusselter NachrilChten (Cryptographic Message Syntax Standard) entspreclhen.

Zur Erzeugung sole her Signaturen ist ein Zertifikat zu verwenden, das den in Abschnitt 3.2 dargelegten Erfordernissen genugt.

Aile digitalen Signaturen sind entsprechend den in der ITU-Empfehlung X. '690 festgelegten DER-Codierungsregeln (Distinguished Encoding Rules) zu codieren.


3.5 Verschlusselungsalgorithmen Je nach Bedarf kbnnen symmetrische Algorithmen (geheimer Schlussel) oder asymmetrische Algorithmen (bffentlicher Schlussel) verwendet werden. Algorithmen, die nach dem nationalen Recht eines bestimmten Landes verboten sind, durfen nicht fur die elektronische Einreichung von Dokumenten aus diesem Land verwendet werden . In Hard- oder Software implementierte Algorithmen durfen nicht in einer Weise verwendet werden, die gegen etwaige Exportbeschriinkungen des Herkunftslandes der Hard- oder Software verstb~t.

Soweit mbglich ist zur asymmetrischen Verschlusselung der rsaEncryption-Algorithmus und zur symmetrischen Verschlusselung der dES-EDE3-CBC-Algorithmus zu verwenden. Derselbe asymmetrische Verschlusselungsalgorithmus ist auch bei der Erstellung digitaler Zertifikate und Signaturen sowie bei der Versiegelung einzusetzen.

3.6 Versiegelung der Daten Elektronische Dokumentendaten, die bei der elektronischen Einreichung aus Grunden der Vertraulichkeit verschlusselt werden, mussen in Format und Anwendung der Definition des Datentyps "signierte und versiegelte Daten" unter "signed and enveloped data content type" in der Version 1.5 des von RSA Laboratories festgelegten Standards PKCS#7 zur Syntax verschlusselter Nachrichten entsprechen.

3.7 Hash-Algorithmen Aus dem Datenstrom der Nachricht ist m it dem sehr sicheren Einweg-Hash-Algorithmus SHA-1 der Hash-Wert zu ermitteln .

4. Signaturverfahr'en

Dieser Standard sieht verschiedene Arten von Signaturen vor, die bei der elektronischen Einreichung akzeptiert werden: a) einfache elektronische Signatur

i) Faksimile-Abbildung der Unterschrift des Benutzers ii) Zeichenkette

b) komplexe elektronische Signatu r i) digitale Signatur gemii~ PKCS#7

ANMERKUNG: Der Benutzer mu~ zwar das eigentliche Dokument nicht unbedingt mit einer komplexen elektronischen Signatur versehen, braucht aber eine digitale Signatur gemii~ PKCS#7, um die gebundelten Anmeldungsunterlagen zum Paket zusammenzustellen (siehe 5.3). Ein Beispiel fUr ein gebundeltes und signiertes Paket ist in Abschnitt 6.1 dargestellt.

Die einfache elektronische Signatur wird im Bereich "party" des XML-Dokuments codiert (siehe nachstehender Teil der Dokumententypdefinition/DTD):

< !ELEMENT electronic-signature < !ATTLIST electronic-signature

(basic-signature, enhanced-signature?) >

DATE-SIGNED CDATA PLACE-SIGNED CDATA

< !ELEMENT basic-signature

#REQUIRED #IMPLIED >

(fax I text-string) >

< ! ELEMENT fax EMPTY >

< !ATTLIST fax FILE - NAME ENTITY #REQUIRED >

< !ELEMENT text-string (#PCDATA) >

< !ELEMENT enhanced-signature (pkcs7) >

< !ELEMENT pkcs7 EMPTY >


Eine einfache elektronische Signatur im XML-Dokument kann durch eine digitale Signatur der gebundelten Anmeldungsunterlagen erganzt werden.

4.1 Faksimile-Abbildung Zur Erzeugung einer solchen Signatur murs die XML-Datei das Element <fax> und im Attribut FILE-NAME einen Verweis auf die externe Datei mit der Bitmap der Signatu r enthalten:

<electronic-signature DATE-SIGNED= " Ol/Ol/2000"> <basic-signature>

<fax FILE-NAME= " signature . tif " /> </basic-signature>

</electronic-signature>

Ais Bitmap-Datei ist eine Abbildung des Formats TIFFGruppe 4, 300 dpi, einfacher Streifen, Intel-Codierung oder eine JFIF-(JPEG-)Datei vorgeschrieben.

4.2 Zeichenkette Zur Erzeugung einer solchen Signatur murs das XMLDokument das Element <text-string> mit einer Zeichenkette enthalten, die in Schragstriche (" /") gesetzt ist und als "handschriftliche" Unterschrift des Benutzers gilt:


<text-string>/janedoe/</text-string> </basic-signature>

</electronic - signature>

Die Zeichenkette ist eine Foige von Zeichen (ohne Schragstrich " j " ), die der Benutzer als elektronische Signatur wahlt. Beispiele:

<text-string>/John Smith/</text-string> <text-string>/Tobeornottobe/</text-string> <text-string>/1345728625235/</text-string> <text-string>/GDnter Fran~ois/</text - string>

4.3 Digitale Signatur gemaB PKCS#7 Signierte Daten gemars PKCS#7 werden aus der elektronischen Nachricht erzeugt, indem der Unterzeichner den Hash-Wert mit seinem privaten Signaturschlussel verschlusselt. Wenn sie versandt werden, umfassen sie auch eine Kopie des digitalen Zertifikats des Unterzeichners.

Die Verwendung einer Signatur gemars PKCS#7 ist in der XML-Datei durch das Element <pkcs7> anzugeben:

<electronic-signature DATE-SIGNED= " Ol/Ol/2000"> <enhanced- s i gnature>

<pkcs7 /> </enhanced-signature>


5. Datenformat

Beim Zusammenstellen der Dokumente zu einem Paket werden die Daten, die Auskunft daruber geben, was ubertragen wird, mit den ubertragenen Daten zu einem einzigen binaren Objekt, den sogenannten gebundelten Anmeldungsunterlagen (WAD - Wrapped Application Documents), zusammengefarst und dann mit einer geeigneten digitalen Signatur versehen und verschlusselt.

5.1 Vorbereitung d,er Dokumente Zu jedem eingereichten Dokument gibt es ein XML-Hauptdokument, das geg1ebenenfalls explizite Verweise auf aile Unterlagen enthalt, die zusammen ubermittelt werden . Diese Verweisdokumente bilden eine logische Einheit mit dem Hauptdokument (z. B. eine neue Patentanmeldung). Daruber hinaus konnen zu einem Hauptdokument noch Begleitdokumente \Iorliegen (z. B. Erfindernennung oder Gebuhrenzahlung).

Das XML-Hauptdokument murs einer der nachstehend spezifizierten Dokumententypdefinitionen (DTD) entsprechen. Bei den Verwleisdokumenten (externen Einheiten) handelt es sich in der Regel um eingebettete Abbildungen, Tabellen, Zeichnungen oder andere Verbunddokumente, die auf der Grundlage von XML, ST.25, PDF, ASCII , TIFF oder JFIF (JPEG) codiert sein konnen. Die Begleitdokumente sind eiglenstandige, aber zugehorige Dokumente im XML-, S1:.25-, PDF-, ASCII- oder Bild-Format. Begleitdokumente im XML-Format mussen ebenfalls einer der nachstehend sp,ezifizierten DTD entsprechen.

XML-Hauptdokument

Dokumente, auf die im XMLHauptdokument verwiesen wird

sonstige Be£lleitdokumente

ITML, PDF

ASCII, ST.25, TIFF, JPEG

-

'---r-------'~ I


5.1.1 Zeichencodierte Formate

5.1.1.1 XML Aile XML-Dokumente mussen einer der nachstehend spezifizierten DTD entsprechen. Anmelder konnen XMLDokumente, die diesem Standard genugen, mit der Client-Software des EPA fur die elektronische Einreichung erstellen.

Der codierte Zeichensatz fur aile XML-Dokumente darf nicht uber den des ISO/IEC-Standards 10646:2000 (Unicode 3) hinausgehen. Das Standard-Codierungssystem fur XML-Dokumente ist UTF-8.

5.1.1.2 ST.25 Ein Dokument, das mit SGML-Tags fur Sequenzprotokolle entsprechend WIPO-ST.25 erstellt wurde, kann als externes Dokument in die gebundelten Anmeldungsunterlagen aufgenommen werden .

5.1.1.3 ASCII Ein in reinem ASCII-Text erstelltes Dokument kann als externes Dokument in die gebundelten Anmeldungsunterlagen aufgenommen werden. Dann mu~ das XML-Hauptdokument die Codeseite des ASCII-Texts enthalten.

5.1.2 PDF Die bei der elektronischen Einreichung verwendeten PDFDokumente mussen folgenden Erfordernissen genugen:

Haupt- Verweis-dokument dokumente

17

" /' Haupt- Verweis-

dok. dok. ........ .

I? I?

a) kompatibel mit PDF Version 1.3 b) Text nicht komprimiert (zur Erleichterung der Suche) c) Text nicht verschlusselt d) keine digitalen Signaturen e) keine eingebett<eten OLE-Objekte f) Aile Fonts mussen eingebettet sein, dem Standard PS17 entsprechen oder auf Adobe® Multiple Master (MM) Fonts basieren. Das PDF-Format hat sich zum De-facto-Standard fur den Austausch formatierter Dokumente im Internet entwickelt.

5.1.3 Abbildungen Die Faksimile-Abbildungen, die bei der elektronischen Einreichung verwendet werden, mussen folgenden Erfordernissen genugen:

Format TIFF Version 6.0 mit Komprimierung Gruppe 4, einfacher Streifen, Intel-Codierung oder JFIF (JPEG)

200, 300 oder 400 dpi A4-Format

5.2 Bundelung dE!r Dokumente Das Hauptdokument wird mit allen externen Verweisdokumenten und allen Begleitdokumenten zu einem einzigen Datenblock zusammengefa~t. Dieser Datenblock - die gebundelten Anmeldungsunterlagen - wird nach dem ZIP-Standard erstlellt. Zur Zusammenstellung der Dokumentendateien eiller elektronischen Anmeldung mussen die Anmelder eine Software fur die Archivierung und Komprimierung im ZIP-Format verwenden.

Begleit-dokumente

17 I • Bunde In

Begleit-dok.

17 Z IP

gebiindelte Anmeldungsunterlagen


Die zur Erstellung der ZIP-Datei verwendete Software mui3 den in der "PKZlp® Application Note" von PKWARE® veroffentlichten Spezifikationen des ZIP-Dateiformats entsprechen (revidierte Fassung yom 1.8.1998) .

Aile in diesem Standard genannten Teile des Dokuments mussen im ZIP-Format zusammengefai3t werden. Die eingereichte ZIP-Datei mui3 aile externen Dateien enthalten, auf die in der Anmeldung verwiesen wird. 1m Hauptverzeichnis der ZIP-Datei enthaltene Dateinamen mussen der Spezifikation fur das jeweilige Betriebssystem entsprechen.

Eine ZIP-Datei mui3 eine flache Verzeichnisstruktur aufweisen. Wenn eine Sammlung von Dateien in die ZIPDatei eingebettet werden mui3, sind diese als eine einzige flache eingebettete ZIP-Datei aufzunehmen.

Nach dem ZIP-Standard kann die Komprimierungssoftware mit verschiedenen Komprimierungsalgorithmen arbeiten. Ais standardmai3iges Komprimierungsverfahren ist das "Deflation"-Verfahren zu wahlen.

5.3 Signatur der gE~bundelten Anmeldungsunterlagen Zur Bindung der Person, die das Paket zusammenstellt, an die gebundelten elektronischen Anmeldungsunterlagen wird eine digitale Signatur hinzugefugt und so das gebundelte und signierte Paket erstellt. Die Signatur gewahrleistet, dai3 diese Person identifiziert werden kann und der Empfanger etwaige unbefugte Veranderungen wahrend des Ubertragungsvorgangs feststellen kann.

Zur Erzeugung eine!s Datentyps " signierte Daten" fur die Signatur ist PKCS#7 zu verwenden .

Haupt- Verweis- Verweis- Beglei] h\ Datenty dok. dok. ......... dok. dok. p:

signiert e Daten Il gemaB

17 IJ PKCS# 7

/ ~, ~

I Signatur

I gebiindelte Anmeldungsunterlagen

I X.509

I

gebiindeltes und signiertes Paket


(A 1) Signed Data <oberste Ebene> (digitale Versiegelung fur die Signatur gemaB PKCS#7)

Datenpaket

(A2) Contentlnfo (Benutzerdaten)

Regeln fur die digitale Versiegelung der Daten zur Zertifizierung gemai3 PKCS#7

Objektbezeichner fur SHA-1

Objektbezeichner fur RSA-Verschlusselung

Objektbezeichner fur Triple DES

Tabelle A1: SignedData - oberste Ebene

(A3) Signerlnfos

(d igitale Signatur)

(A4) Certificates

(X.509)

Der gewahlte Objektbezeichner fur SHA-1 ist in OIW interconnection protocols, Teil 12 wie folgt definiert: sha-1 OBJECT IDENTIFIER ::={iso( 1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 26}

Der Objektbezeichner fur RSA-Verschlusselung ist im Standard PKCS#1 - RSA Encryption wie folgt definiert: pkcs-1 OBJECT IDENTIFIER ::={iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) 1} rsaEncryption OBJIECT IDENTIFIER ::={pkcs-1 1}

dES-EDE3-CBC OB.]ECT IDENTIFIER ::={iso(1) member-body(2) us(840) rsadsi(113549) encryptionAlgorithm(3) 7}

Nr. Bezeichnung Bezeichnung in PKCS#7 Inhalt

1 Version Version ganzzahligen Wert '1' setzen

2 Satz von DigestAlgorithms Algorithmusbezeichnern

2.1 Algorithmusbezeichner Algorithmidentifier nul' EINEN Satz von Algorithmusbezeichnern setzen {sha-1}

3 Information zum Inhalt Contentlnfo eine Information zum Inhalt setzen (s. Tabelle A2)

4 Zertifikate Certificates ein Zertifikat setzen (s. Tabelle A4)

5 Sperrlisten Crls nicht belegt (keine Daten setzen)

6 Information zum Signerlnfos eine Information zum Unterzeichner Unterzeichner setzen (s. Tabelle A3)


Tabelle A2: Contentlnfo - oberste Ebene


1 Art des Inhalts ContentType Objektbezeichner setzen {pkcs-7 1}

2 Inhalt Content Benultzerdaten setzen (binar)

Tabelle A3: Signerlnfos - oberste Ebene



2 Ausgabestelle und IssuerAndSerialNumber Ausgabestelle und laufende Nummer laufende Nummer des Zertifikats gemaB X.509

(Zertifikat des Unterzeichners)

3 Satz von Hash-Algorithmen DigestAlgorithm

3.1 Algorithmusbezeichner Algorithmidentifier zur Erzeugung des Hash-Werts der digitalen Signatur NUR EINEN Satz VON Algorithmusbezeichnern setzen {sha-1}

4 authentifizierte AuthenticatedAttributes nicht belegt (keine Daten setzen) Attribute

5 Algorithmus zur DigestEncryptionAlgorithm Objektbezeichner fur den Verschlusselung Algorithmus zur Verschlusselung des Hash-Werts des Hash-Werts (empfohlener

Algorithmus: rsaEncryption)

6 verschlusselter EncryptedDigest Hash-Wert, der mit privatem Hash-Wert Schlussel des Unterzeichners

verschlusselt wird

7 nicht authentifizierte UnauthenticatedAttributes nicht belegt (keine Daten setzen) Attribute

Tabelle A4: Certificates - oberste Ebene


1 Satz von ExtendedCertificatesAndCer Zertifikaten tificates

1.1 Zertifikat gemaB X.509 Certificate (gemaB Definition nur EINEN Satz von Zertifikatdaten in X.509) gemaB X.509 setzen


6. Einreichung

6.1 Ubertragungspaket Das EPA kann auf die in diesem Abschnitt beschriebene Versiegelung zur Verschlusselung fur Ubertragungszwecke verzichten, wenn eine Verschlusselung auf der Ebene des Kanals wie SSL oder ein Datentrager wie CD-R eingesetzt wird.

Die tatsachlich ubertragenen Daten, die zwischen dem Anmelder und dem EPA ausgetauscht werden, werden als Paket bezeichnet.

Je nach Paketart enthalt das Paket verschiedene Datenelemente, darunter: 1. Datenelement "Kopf" 2. gebundeltes und signiertes Paket, das durch Bundelung und Signatur der Anmeldungsunterlagen entsteht 3. Ubertragungsdaten, z. B. Zeitpunkt der Ubertragung

Das Datenelement "Kopf" gibt AufschluB uber die Art des Pakets, den Dateinamen des Datenelements usw. Es befindet sich immer im signierten und verschlusselten Paket und ist in XML abgefaBt.

----- ~ Kopf gebiindeltes und

signiertes Paket

[l

Biindeln

Kopf gebiindeltes und signiertes Paket

[l

\ ....

gebiindeltes Ubertragungspaket

Fur die Erstellung des signierten und verschlusselten Pakets gilt folgendles Verfahren: a) Erstellung eines gebundelten Ubertragungspakets durch weitere Bundelung des gebundelten und signierten Pakets und der fur die Ubertragung verwendeten Datenelemente mittels ZIP b) Erstellung eines signierten und verschlusselten. Pakets fur die Ubertragung im Netz durch Verschlusselung entsprechend der Defin ition des Datentyps "signierte und versiegelte Daten" unter "signed and enveloped data type" in PKCS#7

Die Signatur soli fur Kombination und Inhalt der einzelnen Datenelemente bLirgen und gewahrleisten, daB der Empfanger feststellen kann, ob bei der Ubertragung unbefugte Anderungen vorg,enommen wurden. Die Verschlusselung soli verhindern, daB Daten bei der Ubertragung unbefugt abgefangen werden.

Die digitale Signatur fur das gebundelte und signierte Paket kann vom Anmelder oder von seinem Vertreter erzeugt werden. Die digitale Signatur fUr das endgultige signierte und verschlusselte Paket erzeugt derjenige, der die Ubertragung einleitet.

Ubertra-gungs-daten

~ Ubertr.-

daten

~ / ~ ,-

S,b]u,,,1 J~

digi~I' ] Signatur

EJ

ZIP

signierte und versiegelte Daten gemaP., PKCS#7

signiertes und verschliisseltes Paket


(81) SignedAndEnveloped Data <oberste Ebene> (digitale Versiegelung fur die Signatur gemaB PKCS#7)

verschlusseltes Datenpaket

(82) EncryptedContentinfo (versch I u sselte 8en utzerdaten )

Regeln fUr die digitale Versiegelung zur Ubertragung gemiil3 PKCS#7

Tabelle 81: SignedAndEnvelopedData - oberste Ebene

Nr. 8ezeichnung 8ezeichnung in PKCS#7

1 Version Version

2 Information zum Recipientlnfos Empfiinger

2 Satz von DigestAlgorithms Algorithmusbezeichnern

2.1 Algorithmusbezeichner Algorithmidentifier

3 Information zum EncryptedContentl nfo verschlusselten Inhalt

4 Zertifikate Certificates

5 Sperrlisten Crls

6 Information zum Signerlnfos Unterzeichner

(83) Recipientl nfo

(verschlusselter Schlussel)

(A3) Signerlnfos

(digitale Signatur)

Inhalt

(A4) Certificates

(X.509)

ganzzahligen Wert '1' setzen

NUR EINEN Satz von Informationen zum Empfiinger setzen (s. Tabelle 83)

NUR EINEN Satz von Algorithmusbezeichnern setzen {sha-l}

eine Information zum verschlusselten Inhalt setzen (s. Tabelle 82)

ein Zertifikat setzen (s. Tabelle A4)

nicht belegt (keine Daten setzen)

eine Information zum Unterzeichner setzen (s. Tabelle A3)


Tabelle 82: EncryptedContentlnfo - oberste Ebene


1 Art des Inhalts ContentType Objektbezeichner setzen {pkcs-7 1}

2 Verschlusselungs- ContentEncryptionAlgorithm Objektbezeichner fur den algorithmus fur den Inhalt Algorithmus zur Verschlusselung

des Inhalts (empfohlener Algorithmus: dES-EDE3-CBC)

3 verschlusselter Inhalt EncryptedContent verschlusselte Benutzerdaten

Tabelle 83: Recipientlnfo - oberste Ebene



2 Ausgabestelle IssuerAndSerialNumber Ausgabestelle und laufende und laufende Nummer Nummer des Zertifikats, das den

offentlichen Schlussel zur Ver-schlusselung des Schlussels fur die Benutzerdaten enthiilt

3 Algorithmus zur KeyEncryptionAlgorithm Objektbezeichner fur den Verschlusselung Algorithmus zur Verschlusselung des Schlussels des Schlussels fur die

Benutzerdaten (empfohlener Algorithmus: rsaEncryption)

4 verschlusselter Schlussel EncryptedKey verschlusselter Schlussel zur Entschlusselung der Benutzerdaten


6.2 Ubertragungsverfahren Das Ubertragungsverfahren lauft wie folgt ab: • Zwischen dem Anmelder und dem EPA wird eine elektronische Verbindung hergestellt. • Der Anmelder ubermittelt das signierte und verschlusselte Paket. • Bei Eingang des signierten und verschlusselten Pakets wird sein Inhalt auf Viren uberpruft und der unverwech-

Hauptdokument

Hauptdok.

selbare Hash-Wert der gebundelten Anmeldungsunterlagen ermittelt. • Dieser Hash-Wert wird mit dem im gebundelten und signierten Paket enthaltenen Hash-Wert verglichen. Bei Ubereinstimmung lerhalt der Anmelder eine Empfangsbescheinigung; stirnrnen die Werte nicht uberein, so wird der Anrnelder entsprechend unterrichtet. Dann wird die Verbindung beendet.

Verweis- und ] Begleitdokumente

Begleitdok.

Biindeln ZIP


Hash-Funktion

Packen zu Datentyp "signierte Daten" gemiiB PKCS#7

HashWert

HashWert

digitale Signatur


X.509

Datenelement "Anmeldungsunterlagen"

6.2.1 Prufung des Hash-Werts Das EPA nimmt die gebundelten Anmeldungsunterlagen entgegen, 6ffnet die darin enthaltenen Datenelemente und weist ihnen entsprechend den Angaben im Datenelement "Kopf" ihre Funktion zu.

6.2.2 Empfangsbescheinigung Das Datenelement "Empfangsbescheinigung" umfaBt ein Datenelernent "Bescheinigung", ein Datenelement "Kopf", das das entsprechende Paket als Ernpfangsbescheinigung ausweist, und fakultativ bei einer neuen Anmeldung ein Datenelement "Anmeldungsunterlagen".

1m Faile von Problemen bei der Ubertragung oder beim Vergleich der Hash··Werte enthalt die Empfangsbescheinigung Informationen zum aufgetretenen Problem.

Die Empfangsbescheinigung wird in Forrn eines signierten und verschlusslelten Pakets zusammengestellt (siehe vorstehende Beschreibung).

16 Be ilage zum Amtsblatt Nr. 4/2001 / Supplement to Official Journal No. 4/2001 / Supplement au Journa l officiel nO 4/2001 2001

Anmelder

Emptangsbescheinigung

..----y... Entpacken der "signierten Daten" gemall PKCS#7

Koptdaten

Emptangs

bescheinigung

I EPA-Signatur

X.509

Bescheinigungsdaten

Bescheini

gungsdaten

Daten der

Empfangsbescheinigung

Dokumenten

daten

EJ X.SOg

Dokumenten

daten

Die Empfangsbescheinigung unterrichtet den Anmelder uber den Eingang der Anmeldung und mulS eine XMLVersion dieser Angaben enthalten . Daruber hinaus kann sie auch eine Version der Daten im PDF-Format umfassen. Diese Dateien werden zu einer einzigen ZIP-Datei zusammengefalSt und mit dem digitalen Zertifikat des EPA signiert.

6.3 Ubertragungsprotokoll Das EPA setzt ein Ubertragungsprotokoll auf der Grundlage von HTTP in Verbindung mit SSL ein.

Emptangs· bescheinigLing

Emptangs

bescheinigLing

EPA

Packen zu "signierten

Daten" gemall PKCS#7

I EPA-Signalur

X.S09

Kopt· daten

Bescheinigungsdaten

l3escheini

!lungsdaten

Bundeln, VerschlDsseln und Packen zu U versiegelten Daten" gemall PKCS#7

Daten der Emptangsbescheinigung

7. Datentrager

Dokumenten

daten

~ ~

X.SOg

Das EPA akzeptiert auch eine elektronische Einreichung auf CD-R. Die CD-R darf nur eine Anmeldung in Form der signierten gebundelten Anmeldungsunterlagen (WADWrapped Applica1tion Documents) enthalten, die im Stammverzeichnis zu speich ern sind und den Dateinamen "WADZIP" haben sollten . Das Begleitschreiben mulS niihere Einzelheiten zur Anmeldung bzw. zum Dokument umfassen und aU'f die "WAD.ZIP" -Datei auf der CD-R verweisen. Die Bezeichnung der CD-R mulS auf der Anmel dernummer basieren.


Anlage - Schaubilder zur Erlauterung des Standards

Die folgenden Schaubilder und Textpassagen enthalten zusatzliche (vereinfachte) Erlauterungen zum Standard.

Ein gebundeltes und signiertes Paket kann man sich als eine "Schachtel mit Dokumenten" vorstellen.

Die "innere Schachtel"

Dokumente und weitere Dateien

Vereinfachte Darst4ellung des signierten und verschlusselten Palkets

Abbildung 1 veranschaulicht fur den Laien, aus welchen Bestandteilen sich das signierte und verschlusselte Paket gemalS dem vorlienenden Standard zusammensetzt. Die Abbildung wurde bewulSt vereinfacht und verzichtet auf technische Details, die den Leser von den wesentlichen Aspekten des Paketaufbaus ablenken k6nnten. So wird in der Abbildung nicht auf die Bundelung zu einer "ZIP"Datei und die Codierungsstandards fur Objekte eingegangen.

Das Paket enthalt den Paketkopf, die Dateien mit den Obertragungsdaten und das gebundelte und signierte Paket.

(A 1: gebundeltes und signiertes Paket, s. unten) bindet die eigentlichen Dokumente an die digitale Signatur und das digitale Zertifikat des Anmelders.

PAKET (81) Die "auBere Schachtel" (signiertes und verschlusseltes Paket) dient der sicheren Obermittlung des In halts. 1

'10101010010100 1 10101O)1()1010"

..... 11010101001

01(11)1011001

Das Paket umfaBt einen verschlusselten Schlussel, mit dem der Empfanger (z. B. das EPA) das Paket 6ffnet, um den Inhalt zu lesen. AuBerdem enthalt das Paket eine digitale Signatur und ein digitales Zertifikat, die Gewahr fUr die Integritat der Daten bieten sollen.

Abbildung 1: Signiertes und verschlusseltes Paket

18 Beilage zum Amtsblatt Nr. 4/2001 / Supplement to Official Journal No. 4/200 1 / Supplement au Journal officiel nO 4/2001 2001

Vereinfachte Darstellung des gebundelten und signierten Pakets

Ein gebiindeltes und signiertes Paket kann man sich als eine "Schachtel mit Dokumenten" vorstellen.

I /-

Dokumente r-und weitere Dateien

---~ ~ I ~~~~

Das Paket enthalt aile Dateien, aus den en sich die Anmeldung zusammensetzt (Dokumente, Abbildungen usw).

Das Paket umfaBt eine digitale Signatur und ein digitales Zertifikat, die Gewahr fUr die

Die "Schachtel" (gebiindeltes und signiertes Paket) bindet die Dokumente an die digitale Signatur und das digitale Zertifikat des Anmelders.

digitale Signatur

hochwertiges Zertifikat J. ~----

Integritat der Daten bieten

, sollen, wobei eine komplexe

1101010100 ""e."". iIi elektronische Signatur auch als registriert Signatur fUr die Dokumente

0100101100 Vertreternr. #1234 dienen kann. 0101001010

Abbildung 2: Gebundeltes und signiertes Paket

Aufbau des Objekts "gebundelte Anmeldungsunterlagen"

In Abschnitt 5 wird festgelegt, wie die Dokumente zu "gebundelten Anmeldungsunterlagen" zusammengefa~t werden. 1m Faile der Offline-Einreichung auf Datentragern sind die weiteren Schritte zur Erstellung des gebundelten und signierten Pakets sowie des signierten und verschlus-

Komplexe elektronische Signatur

Einfache elektronische Signatur

Hochwertiges Zertifikat

11 0 101 0 1001 0 1001011 (101 0 10 1(0 11)101 0 111 010 1010

Abbildung 3: Arten von Zertifikaten/Signaturen

selten Pakets fakultativ. Die gebundelten Anmeldungsunterlagen bestehen aus Dateien, die zu einer einzigen "ZIP"-Datei zusammengefa~t und im Stammverzeichnis des Datentragers gespeichert sind.

Arten von Zertifikaten/Signaturen

Die Abbildungen3 bis 7 sollen den Unterschied zwischen den im Standard festgelegten verschiedenen Arten von digitalen Zertifikaten und elektronischen Signaturen veranschaulichen. Jedes Schaubild zeigt eine "Schachtel", die das gebundel1te und signierte Paket darstellt.

Einfaches Zertifikat


digitale Signa ur

110101010 001011001 001010101

Patentdokument

</komplexe Signatur>

registriert Vertreternr. 1

Abbildung 4: Komplexe elektronische Signatur/hochwertiges Zertifikat

digitale

Signatur

110101010 001011001 001010101

Patentdokument

</komplexe

Signatur>

einfaches Zertifikat

Jane Doe

nicht uberpruft

[email protected]

Abbildung 5: Komplexe elektronische Signatur/einfaches Zertifikat

Tag "komplexe Signatur" verweist auf die Signatur des Pakets.

Digitale Signatur dient als Signatur des Dokuments und bietet Gewahr fUr die Integritat des Pakets.

Hochwertiges Zertifikat gewahrleistet, da/1 das Paket von einem uberpruften Anmelder stammt.

Tag "komplexe Signatur" verweist auf die Signatur des Pakets.

Digitale Signatur dient als Signatur des Dokuments und bietet Gewahr fUr die Integritat des Pakets.

Einfaches Zertifikat dient zur Oberprufung der digitalen Signatur.


Patent- -

dokument t--

/ / IJane Doel

/~ I Ji------digitale __ ~

r.ochwertiges Zertifika1 ~\ Signatur

Jane Doe

fB ~\\

1101010100 registriert

0010110010 Vertreternr. 12345 V 0010101011

Abbildung 6: Einfache elektronische Signatur/hochwertiges Zertifikat

digitale

Signatur

110101010 001011001 001010101

Patentdokument

/Jane Doe/

einfaches Zertifikat

Jane Doe

nicht uberpruft

[email protected]

Abbildung 7: Einfache elektronische Signatur/einfaches Zertifikat

\ ~

~

-

Einfache Signatur gibt Unterzeichner des Dokuments an.

Digitale Signatur bietet lediglich Gewahr fur die Integritat des Pakets.

Hochwertiges ZertifIkat gewahrleistet, daj3 das Paket von einem iiberpriiften Anmelder starnmt.

Einfache Signatur gibt Unterzeichner des Dokuments an.

Digitale Signatur bietet lediglich Gewahr fOr die Integritat des Pakets.

Einfaches Zertifikat dient zur Oberprufung der digitalen Signatur.


Kombinationen von Ubertragungsverfahren und Paketarten \

Abbildung ? zeigt die zulassigen Kombinationsmoglichkeiten von Ubertragungsverfahren und Paketarten. Generell gilt fur die verschiedenen Ubertragungsverfahren folgendes: a) Online/Internet: Es ist ein signiertes und verschlusseltes Paket zu verwenden.

b) Online/geschutzt (Verschlusselung auf Kanalebene, z. B. privates Netz): Es ist ein signiertes und verschlusseltes Paket oder ein nebundeltes und signiertes Paket zu verwenden. c) Offline/Datentraner: Es kann ein signiertes und verschlusseltes Paket, ein gebundeltes und signiertes Paket oder ein Paket mit den gebundelten Anmeldungsunterlagen verwendet werden.

~ Signiertes und verschliisseltes Paket Gebiindeltes und signiertes Paket Gebiindelte Anmeldungsunterlagen

0 0 Online/ () I~~ ) Internet Internet

nicht zuliissig nicht zuliissig

0 Online/ () ) () "- ) -- -

geschiitzt ~;;.:=--:::;:,- ==-= geschiitzt geschiitzt

nicht zuliissig

Offline/

® @ @) Datentrager

Abbildung 8: Ubertragungsprotokolle und zulassige Pakete


Decision of the President of the European Patent Office dated 7 December 2000 on the electronic filing of European patent applications and subsequent documents

The President of the European Patent Office (EPO), having regard to Rules 24(1), 27a, 35(2), 36(5), 77(2)(d) and 101 EPC,

having regard to the basic requirements to be fulfilled by any electronic record, namely

(a) authenticity - ie confirmation that a document is what it purports to be, and was authored by the person who purports to have done so,

(b) integrity - ie consistency of the data and, in particular, detecting and preventing its unauthorised alteration or destruction,

(c) confidentiality - ie ensuring that a document's existence or content is not disclosed to unauthorised persons, and

(d) non-repudiation - ie ensuring that the sender (with the recipient's co-operation) has reliable evidence that the data has been delivered, and that the recipient has reliable evidence of the identity of the sender, so that neither party can successfully deny sending or receiving the data and a third party can verify its integrity and origin,

having regard to the basic standards of electronic records management, namely that

(1) all documents filed electronically must be capable of being printed as paper and transferred to archival media without loss of content or material alteration;

(2) information that is routinely collected by the automated systems concerning the record, often called metadata, is to be considered part of the electronic records and maintained by the automated systems;

(3) electronic documents must be submitted in an Officedesignated electronic file format; archive copies must also be retained in the electronic format in which they are submitted;

(4) all electronic submissions must generate a positive acknowledgment to the submitter indicating that the Office has received the submission. The positive acknowledgment must include the identity of the Office, the date and time of the submission's receipt (which is the Office's receipt date/time) and any Office-assigned reference or application number;

(5) every Office that accepts electronic filing must also provide for the submission of paper documents. These paper documents may be imaged to facilitate the creation of a single electronic case file;

(6) a mechanism must be provided to ensure the authenticity and integrity of the electronically filed document. This requires the ability to verify the identity of the submitter (the applicant or authorised representative) as well as the ability to verify that a document has not been altered without authorisation since it was filed;

(7) electronic filing systems must provide backup and recovery mechanisms to protect electronic filings against system failures;

(8) the electronic records must be maintained for long-term access and retention;

(9) electronic files must be scanned for computer viruses and other forms of malicious logic prior to processing, with appropriate action being taken in order to preserve the filing date, if possible;

(10) access to computers used for electronic filing must not jeopardise the security of other Office networks and applications;

(11) electronic records management systems must provide mechanisms for quality assurance and quality control of the submitted documents;

(12) the electronic records management systems must maintain an audit trail of all additions to or alterations of the electronic records, recording the receipt information or other information about the generation of each record and of all changes to the records;

(13) if access to confidential data by electronic means is allowed, this access must be secure and available to authorised viewers only. Measures to assure the protection of these files from alteration must be taken. Such access by applicants, representatives or authorised members of the pUlblic by electronic means must be documented as to the identity of the party, the date (and optionally time) of the transaction, and the details of any submissions. Such documentation should be maintained as confidential data;

(14) to the extent provided for in the EPC, adequate public access to the published European patent applications and patents must be provided; and

(15) all electronic submissions should upon receipt be copied to a read-only medium,

has decided as follows:

Article 1 Filing of European patent applications

European patent applications may be filed with the EPO in electronic form as follows:

(a) online, at the European Patent Office's computer servers at the following address: https://secure.epoline.org or

(b) on CD-R.

European Patent applications may also be filed in electronic form with the competent national authorities of those contracting states which so permit. The national provisions of the contracting states prescribing initial filing with the national authority or prior authorisation before filing with another authority (Article 75(2) EPC) are unaffected.

Article 2 Standard on electronic filing

The Technical Standard for Electronic Filing, annexed to this decision (referred to thereafter as "the Standard"), shall form an integral part of it. Any future amended version of this standard or any future standard recommended by the World Intellectual Property Organisation for the online filing of national patent applications shall become applicable after the publication of a corresponding decision of the President of the European Patent Office.


Article 3 Preparation of documents

Documents filed in accordance with Article 1 shall be prepared using software either provided free of charge by the EPa or certified by the EPa as conforming to the Standard.

Article 4 Presentation of documents

The documents making up the European patent application, including any drawings, filed in accordance with Article 1 shall be in the format specified in the Standard. Any sequence listing contained in applications filed in accordance with Article 1(a) need not be submitted on a separate data carrier.

Article 5 Request for grant

Any request for grant of a European patent filed in accordance with Article 1 shall comprise, in addition to the information pursuant to Rule 26(2) EPC, the electronic address of the applicant and of any representative appointed.

Article 6 Legibility Infected files

(1) Promptly upon receipt, the EPa shall check European patent applications filed in accordance with Article 1 for

(a) legibility and

(b) computer viruses and other forms of malicious logic.

(2) In so far as the European patent application is illegible in whole or in part, the EPa shall regard that part of the document which is illegible as not having been received and shall, if possible, promptly notify the applicant accordingly.

(3) If the European patent application is found to be infected with a computer virus or malicious logic, the EPa shall regard it as illegible and need not open or process it. The EPa shall use all means reasonably available to it to read the submission for the purposes of according a filing date and shall, if possible, promptly notify the applicant accordingly.

(4) Where the European patent application is found to be deficient under paragraphs 2 or 3, so that no filing date can be accorded, the EPa shall, if possible, invite the applicant to correct the deficiencies within a time limit to be set by it. The filing date shall be the date on which the deficiencies are remedied. If the deficiencies are not remedied in due time, the application shall not be dealt with as a European patent application.

Article 7 Examination for certain physical requirements

If the European patent application is filed in a format not complying with Article 4, the EPa shall make reasonable efforts to read the submission for the purpose of according it a filing date. If unsuccessful, Article 6(4) shall apply. If successful, the EPa shall set the applicant a time limit for re-submitting the application in a format complying with Article 4. If the application is not re-submitted in the prescribed format in due time, it shall be refused in accordance with Article 91 (3) EPC.

Article 8 Filing of other dOGuments

Where the European patent application is filed in accordance with Article 1, any authorisation or designation of inventor may also be filed in accordance with Article 1. Articles 3,4 and 6 shall apply. If these documents are filed in a format not complying with Article 4, the applicant shall be invited to re-submit them in a format complying with Article 4 within a time limit to be set by the EPa. If an authorisation is not re-submitted in the prescribed format in due time, Rule 101(4) EPC shall apply. If a designation of inventor is not re-submitted in the prescribed format in due time, Article B1(5) EPC shall apply.

Article 9 Original documents - Number of copies Authentic version

(1) Any documents filed in accordance with Articles 1 and 8 shall be the original documents for the purposes of all subsequent proceedings before the EPa. They shall be filed in one copy.

(2) Where documents have been filed on CD-R in accordance with Article 1 or 8, the electronic version obtained by the EPa from the CD-R and kept in the electronic file of the European patent application shall be deemed to be the authentic version of the document. In the event of any dispute, verification may be effected by comparison with the originally filed CD-R, which shall be kept for the period prescribed in Rule 95a EPC.

Article 10 Paper confirmation

(1) No confirmation on paper is required for documents filed in accordance with Articles 1 and 8.

(2) The EPa shall take no action in respect of any paper confirmation nonetheless filed, unless clearly instructed by the applicant to do so. Such action may result in a new filing date being accorded.

(3) Any paper confirmation filed must be clearly marked as such and must contain the information necessary for the EPa to be able to attribute it to the electronic submission concerned.

Article 11 Signatures

(1) When the European patent application is filed in accordance with Article 1, the signature required in the request for grant of a European patent shall be provided in one of the following forms:

(a) as a facsimile image of the signer's handwritten signature;

(b) as an electronic signature, ie data in electronic form which is attachedl to or logically associated with other electronic data (data message) and which serves as a method of authenticating the signatory in relation to the data message and indicates his or her approval of the information contained in the data message; or

(c) as an advanced electronic signature, ie an electronic signature which meets the following requirements:

(i) it is uniquely linked to the signatory;

(ii) it is created using means that the signatory can maintain under his or her sole control; and

2001 8eilage zum Amtsblatt Nr. 4/2001 / Supplement to Official Journal No. 4/2001 / SUPlPlement au Journal officiel nO 4/2001 25

(iii) it is linked to the data to which it relates in such a manner that any subsequent change of the data is detectable.

(2) An electronic signature within the meaning of paragraph 1 (b) is a series of characters chosen by the signatory to express his or her identity and intent to sign the data message in question, and is preceded and followed by the forward slash (/).

(3) An advanced electronic signature within the meaning of paragraph 1 (c) is a digital signature produced using a Public Key Infrastructure-generated certificate and the corresponding private key.

(4) In all other cases where a signature is required under the EPC, an advanced electronic signature within the meaning of paragraphs 1(c) and 3 must be produced in respect of the packaged submission. Individual documents within the package may be signed also in accordance with paragraph 1 (a) or paragraphs 1 (b) and 2.

(5) If the request for grant of a European patent or any other submission relating to a European patent application and filed in accordance with Article 1 (a) is not signed, or the signature furnished does not comply with paragraphs 1 to 4 as appropriate, the EPO shall set the applicant a time limit for correcting the deficiency. If the deficiency is not corrected in due time, the submission shall be deemed not to have been received.

(6) European patent applications and other submissions filed on CD-R must be accompanied by a paper document bearing a handwritten signature, identifying the applicant and the applicant's representative, indicating an address for correspondence and listing the files contained in the CD-R.

Article 12 Acknowledgment of receipt

(1) The receipt of submissions filed in accordance with Article 1 (a) shall be acknowledged electronically within the submission session. Where it becomes apparent that such acknowledgment was not successfully transmitted, the EPO shall promptly transmit the acknowledgment by other means where the necessary indications furnished to the EPO so permit.

(2) The acknowledgment shall include the identity of the Office, the date and time of the document's receipt, an Office-assigned reference or application number and a list of the files transferred . The acknowledgment shall also contain a message digest of the submission.

(3) Acknowledgment of receipt shall not imply the accordance of a filing date.

Article 13 Fee payments

The arrangements for fee payments shall remain unaffected by this decision .

Article 14 EPO communications

The EPO shall specify which communications may be notified online. Applicants shall indicate, upon filing the European patent application, which communications, if any, they wish to be notified online. Communications shall otherwise continue until further notice to be notified in paper form.

Article 15 Notifications

(1) If communications are notified on paper, Rules 78 to 80 EPC shall apply.

(2) If communications are notified online, the EPO shall inform the applicant that a communication is awaiting collection by the applicant. Such information shall be in the form of an e-mail containing a link to the applicant's mailbox at the EPO server. If a communication is not collected within five days from dispatch of the e-mail information, a paper copy shall be notified in accordance with paragraph 1.

(3) Communications notified in accordance with paragraph 2 shall be deemed to have been received on the tenth day foliowin£1 the date of dispatch of the e-mail information.

(4) Rules 81 and 82 EPC shall remain unaffected.

Article 16 Time limits

Rules 83 to 85 EPC shall apply. Only applicants who have agreed to receive notifications online may also request time-limit extensions online.

Article 17 Entry into force

This decision shall enter into force on 8 December 2000.

Done at Munich, 7 December 2000.

Ingo KOBER President


Technical standard for the electronic filing of European patent applications and subsequent documents

1 Background

This document contains the technical standards for the electronic filing of documents with the EPa. It is based on the Trilateral Public Key Infrastructure (PKI)-based standard that has been incorporated into Annex F, Appendix I of the PCT Administrative Instructions.

A PKI environment provides a suite of services for processing sensitive information. Through the use of cryptography, PKI can satisfy the requirements for: (a) Authentication - by ensuring that transmissions, messages and originators are valid, and that a recipient is authorised to receive specific categories of information. (b) Data integrity - by ensuring that data is unchanged from its source and has not been accidentally or maliciously modified, altered, or destroyed. (c) Non-repudiation - by ensuring strong and substantial evidence is available to the sender of data that the data has been delivered (with the co-operation of the recipient), and to the recipient of the sender's identity, so that neither party can successfully deny having possessed the data, and a third party can verify its integrity and origin. (d) Confidentiality - by ensuring that the information can be read by authorised entities only.

This standard sets out the mandatory requirements for all parties participating in electronic filing, as well as a number of optional requirements.

2 Scope

This technical standard covers requirements in the following areas: (a) Security and PKI (b) Electronic signatures (c) Document format requirements (d) Submission

3 Security and PKI

3.1 Public Key Infrastructure In this standard, packaging and transmission are performed using PKI technology. When feasible alternative security technologies become available, they may be incorporated in updates to the standard.

PKI must be implemented in accordance with the recommendations established by the Internet Engineering Task Force (IETF) Working Group on PKI Interoperability (PKIX) and documented in IETF RFC 2459.

Separate key pairs and digital certificates must be used for the digital signature and encryption .

3.2 Digital certificates Where the standard specifies use of a digital certificate, the certificate must comply with the International Telecommunication Union (ITU) X.509 (version 3) recommendation for certificate format.

A digital certificate is required when communicating with the EPa online.

The standard provides for two classes of digital certificate:

High-level certificate: a digital certificate issued by a certification authority to the applicant, which can be used to authenticate the identity of the applicant. The certification authority must appear on the list of "recognised" certification authorities published by the EPa (see 3.3 below).

Low-level certificatle: a digital certificate provided by the EPa to the applicant on request. To receive a low-level certificate, the applicant must provide his name and e-mail address, but is not required to furnish proof of identity.

3.3 Certification authorities The EPa will specify which certification authorities it accepts. This list of "recognised" certification authorities will include a link to the published PKI policy statement of each of these authorities.

Recognised certification authorities are responsible for maintaining the accuracy of the electronic certificates that " prove" a party is who he says he is. Certification authorities store certificate information for all the certificates they issue in a directory structure complying with ITU recommendation X.500. Such systems provide an external interface for publishing and retrieving user digital certificates that complies with the Lightweight Directory Access Protocol (LDAP) using the IETF Network Working Group's RFC 1777 dated March 1995. In addition, certification authorities publish revocation information about certificates drawn Ulp in accordance with the X.509 standard.

The EPa will subscribe to this revocation information. Whenever a certificate is used to authenticate an individual, the EPa will consult the revocation information published by the certification authority concerned to ensure that the certificate has not been revoked.

3.4 Digital signatures Digital signatures used to sign electronic documents for electronic filing must conform to the format and practice specified in RSA Laboratories' PKCS#7 Cryptographic Message Syntax Standard (version 1.5) with regard to the definition of the signed-data content type.

To build these signatures, a certificate meeting the requirements set out in Section 3.2 above must be used.

All digital signatures must be encoded using the distinguished encoding rules (DER) defined in ITU recommendation X.690.

28 8eilage zum Amtsblatt Nr. 4/2001 / Supplement to Official Journal No. 4/2001 / Sllpplement au Journal officiel nO 4/2001 2001

3.5 Cryptographic algorithms Both symmetric (secret key) and asymmetric (public key) algorithms may be used as required. Algorithms prohibited under the national law of a country may not be used for the electronic filing of documents from that country. Algorithms implemented in hardware or software may not be used in any manner contrary to the export restrictions of the country of origin of the hardware or software.

Where possible, the rsaEncryption algorithm is to be used for asymmetric encryption and the dES-EDE3-CBC algorithm for symmetric encryption. The same asymmetric encryption algorithm should be used to create digital certificates, digital signatures and envelopes.

3.6 Data enveloping Electronic document data that is encrypted to ensure confidentiality for electronic filing must conform to the format and practice specified in RSA Laboratories' PKCS#7 Cryptographic Message Syntax Standard (version 1.5) with regard to the definition of the signed and enveloped data content type.

3.7 Message digf,st algorithms The message stream must be input to the strong one-way message digest algorithm SHA-1 to create a message digest.

4 Signature meclhanisms

This standard provides for a number of signature types acceptable for electronic filing: (a) Basic electronic signatures

(i) Facsimile image of the user's signature (ii) Text string

(b) Enhanced electronic signature (i) PKCS#7 di'gital signature

NOTE: Although users may choose not to utilise an enhanced electronic signature mechanism for the document itself, a PKCS#7 digital signature is required to package the wrapped application document as described in section 5.3. See Section 6.1 for an example of a wrapped and signed package.

The basic electronic signature is encoded within the "party" structure of the XML document as specified by the portion of the Document Type Definition (DTD) shown below:

< !ELEMENT electronic-signature <!ATTLIST electronic-signature

(basic-signature , enhanced- signature?) >

DATE-SIGNEDC DATA PLACE-SIGNEDC DATA


<!ELEMENT basic-signature (fax I text-string) >

< !ELEMENT fax EMPTY > < !ATTLIST fax

FILE-NAME ENTITY #REQUIRED >

<!ELEMENT text-string (#PCDATA) >

< !ELEMENT enhanced-signature (pkcs7) >



A basic electronic signature within an XML document may be supplemented by the addition of a digital signature to the wrapped application documents.

4.1 Facsimile signature To create this type of signature, the XML file must include the <fax> element and an external entity reference set in the FILE-NAME attribute that points to the file containing the bitmap of the signature, as shown below:

<electronic-signature DATE-SIGNED= " Ol/01/2000"> <basic - signature>

<fax FILE-NAME= " s i gnature . tif " /> </basic-signature>


This bitmap file must be a 300dpi single strip, Intel encoded TIFF Group 4 image or a JFIF (JPEG) file.

4.2 Text string signature To create this type of signature, the XML document must include the <text-string> element containing a text string that represents the user's "wet" (ink) signature, enclosed in slash "/" characters, as shown in the example below:

<elect r onic-signature DATE - SIGNED= " Ol/Ol/20 00 "> <basic - signature>

<text-string>/janedoe/</text-string> </basic-signature>


The text string must be a string of characters, not including the forward slash"/" character, chosen by the user as his electronic signature, as shown in the following examples:

<text-string>/John Smith/</text-string> <text - string>/Tobeornottobe/</ t ext-string> <text-string>/ 1345728625235/</text-string> <text-string>/G0nter Fran~ois/</text- string>

4.3 PKCS#7 digital signature The PKCS#7 signed data type is generated from the electronic message by the signer, who uses his private signing key to encrypt the message digest. It includes a copy of the digital certificate of the ·signer when sent.

The use of a PKCS#7 signature must be indicated in the XML file by the <pkcs7> element, as shown below:

<electronic-signature DATE-SIGNED= " Ol / Ol / 2000"> <enhanced-signature>


</electroni c-signature>

5 Data format requirements

The document packaging mechanism is used to combine the data about what is being transmitted with the contents of the transmission to form a single binary object called a wrapped application document (WAD), and then to apply the appropriate digital signatures and encryption.

5.1 Document prelparation For each document filed there is a main XML document that may explicitly reference all documents to be sent in a single package. These referenced documents are logically part of the main document (eg a new patent application). In addition, a filing may include other accompanying documents (eg designation of inventor or fee payment).

The main XML document must conform to one of the DTDs specified below. The referenced documents (external entities) are typically embedded images, tables, drawings or other compound documents and may be encoded as either XML, ST2'5, PDF, ASCII, TIFF or JFIF(JPEG). The accompanying documents are separate, but related, documents that may be encoded as either XML, ST25, PDF, ASCII or Image. Any accompanying XML documents must also conform to one of the DTDs specified below.

Main XML

document

Documents referenced in main

XML document

Other accompanying documents

~(ML'PDF

ASCII, ST25, TIFF, JPEG

-----It/ I


5.1.1 Character-coded formats

5.1.1.1 XML All XML documents must conform to one of the DTDs specified below. Applicants will be able to create XML documents conforming to this standard by using the EPO's client software for electronic filing.

The coded character set used for all XML documents must be confined within that specified by ISO/IEC 10646:2000 (Unicode 3.0). The standard character-encoding scheme for XML documents is UTF-S.

5.1.1.2 ST.25 A document created using WIPO ST.25 SGML tags for sequence listings may be included in a WAD as an external document.

5.1.1.3 ASCII A document created as plain ASCII text may be included in a WAD as an external document. In this case, the main XML document must include the code page of the ASCII text.

5.1.2 PDF PDF documents for use in electronic filing must meet the following requirements:

Main Referenced

document documents

17

U /'

doc. [:] doc. 0 . ..... .

(a) PDF V1 .3 compatible (b) Non-compressed text to facilitate search ing (c) Unencrypted text (d) No digital signatures (e) No embeddecl OLE objects (f) All fonts must either be embedded, standard PS17 or built from Adobe® Multiple Master (MM) fonts

The PDF format has become the de facto standard for the exchange of formatted documents on the Internet.

5.1.3 Images Facsimile images used in electronic filing must meet the following requirements:

Format TIFF V6.0 with Group 4 compression, single strip, Intel encoded or

o JFIF(JPEG) 200, 300 or 4010 dpi A4 size

5.2 Wrapping documents The main document and any externally referenced documents and accompanying documents are wrapped and treated as one data block. This data block, called the wrapped application documents (WAD), is created using the ZIP wrapping standard. Applicants must use ZIP format archiving and compression software to package the document files constituting an electronic application.

Accompanying documents

• Wrapp mg

Accomp. doc.

/7 Z IP

Wrapped application documents


The software used to create the ZIP file must conform to the ZIP file format specification as published in the PKWARE® PKZlp® Application Note (revised: 8.1.1998).

The files to be zipped must include all parts of the document identified elsewhere in this standard. All external files referenced by the application must be included in the ZIP file submission . File names included in the central directory of the ZIP f.ile must comply with the specification for the applicable operating system.

All ZIP files must have a flat directory structure. If a collection of files needs to be embedded in the ZIP file, then these should be included as a single flat embedded ZIP file.

The ZIP standard allows the compression software to select from among a number of compression algorithms. The default compression method must be "Deflation".

5.3 Signing wrappl~d application documents To bind the person creating the package to the electronic wrapped application documents, a digital signature is added to create the wrapped and signed package. The purpose of adding 1the signature is to identify the person creating the packagle and to enable the recipient to detect any unauthorised alteration during transmission .

PKCS#7 is used to produce a signed data type for the signature.

Main Ref. [:J doc. doc. .. ...... doc. doc. [:J h\ PKCS# 7 data signed

type p p

/ ~, I~

I

Signature

I Wrapped application documents

I X.509

I

Wrapped and signed package

32 8e ilage zum Amtsblatt Nr. 4/2001 / Supplement to Official Journal No. 4/2001 / Supplement au Journal officiel nO 4/2001 2001

(A 1) Signed Data <top level> (PKCS#7 digital envelope for signature)

Data package

(A2) Contentlnfo (user data)

Rules for producing the PKCS#7 digital envelope for certification

Object identifier for sha-1

Object identifier for RSA encryption

Object identifier for triple DES

Table A 1 SignedData - top level

No. Item name PKCS#7 item

1 Version Version

(A3) Signerlnfos

(digital signature)

(A4) Certificates

(X.509)

The object identifier adopted for SHA-1 is defined in OIW interconnection protocols (part 12) as follows: Sha-1 OBJECT IDENTIFIER ::= {iso (1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 26}

The object identifier for RSA encryption is defined in RSA Encryption Standard PKCS#1 as follows: Pkcs-1 OBJECT IDENTIFIER ::= iso(1) member-body(2) US(840) rsoadsj(113549) pkcs(1) 1} RsaEncryption OB,JECT IDENTIFIER ::={pkcs-1 1}

dES-EDE3-CBC OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) rsadsi(113549) encryptionAlgorithm(3) 7}

Content .,

Set integer value '1'

2 Set of algorithm identifiers DigestAlgorithms

2.1 Algorithm identifier Algorithmldentifier Se,t ONE set of algorithm identifiers {sha-1} only

3 Content information Contentlnfo Se,t one content information (see table A2)

4 Certificates Certificates Set one Certificates (see table A4)

5 Certificate revocation lists Crls Not used (set no data)

6 Signer information Signerlnfos Set one Signerlnfos (see table A3)


Table A2 Contentlnfo - top level

No. Item name PKCS#7 item Content

1 Content type ContentType Set object identifier {pkcs-7 1}

2 Content Content Set user data (binary)

Table A3 Signerlnfos - top level


1 Version Version Set integer value '1'

2 Issuer and serial number IssuerAndSerialNumber Issuer of certificate and certificate serial number in acc. with X.509 (signer's certificate)

3 Set of digest algorithms DigestAlgorithm

3.1 Algorithm identifier Algorithmldentifier Set ONE set of algorithm identifiers {sha-1} only to make digest of digital signature

4 Authenticated attributes AuthenticatedAttributes Not used (set no data)

5 Digest encryption DigestEncryptionAlgorithm Algorithm OBJECT identifier algorithm of digest encryption

(recommended algorithm: rsaEncryption)

6 Encrypted digest EncryptedDigest Digest data encrypted using signer's private key

7 Unauthenticated attributes UnauthenticatedAttributes Not used (set no data)

Table A4 Certificates - top level


1 Set of certificates ExtendedCertificatesAnd Certificates

1.1 X.509 certificate Certificate (defined in X.509) Set ONE set of X.509 certificate data onlv

34 8e ilage zum Amtsblatt Nr. 4/2001 / Supplement to Official Journal No. 4/2001 / Supplement au Journal officiel nO 4/2001 2001

6 Submission

6.1 Transmission package The EPO may decide not to use the enveloping mechanism described in this section as the encryption mechanism for transmission where channel level encryption such as SSL or physical media such as CD-R are used.

The actual transmission data exchanged between the applicant and the EPO is called a package.

A package contains various data items depending on the type of package. These include: 1. Header object data item 2. Wrapped and signed package made by wrapping and signing the application documents 3. Transmission data such as time of transmission .

The header object data item indicates the package type, file name of data item, etc. It is always found in the signed and encrypted package, and is written in XML.

Header object

Header object

Wrapped and signed

package

Wrapping

Wrapped and signed

package

Wrapped transmission package

The procedure for creating signed and encrypted packages is as fo l lows: (a) Create a wrapped transmission package by wrapping the wrapped and signed package with the data items used for transm ission !Using ZIP (b) Create a signed and encrypted package for network transmission by encrypting using the PKCS#7 signed and enveloped data type.

The purpose of the signature is to ensure the combination and contents of t he individual data items, and to enable the recipient to detect any unauthorised alterations during transmission. Encryption is to prevent the unauthorised interception of data during communication.

The digital signature for the wrapped and signed package may be produced by either the applicant or his representative. The person that starts the transmission produces the digital signature for the final signed and encrypted package.

TransmISSIOn

data

Trans. data

~] ~

~J

ZIP

PKCS#7 signed and enveloped data type

Signed and encrypted package

2001 Beilage zum Amtsblatt Nr. 4/2001 / Supplement to Official Journal No. 4/2001 / Supp lement au Journal officiel nO 4/2001 35

(B1) SignedAndEnveloped Data <top level> (PKCS#7 digital envelope for transmission)

Encrypted data package

(82) EncryptedContentlnfo (encrypted user data)

Rules for producing the PKCS#7 digital envelope for transmission

Table 81 SignedAndEnvelopedData - top level

No. Item name PKCS#7 item

1 Version Version

2 Recipient Recipientlnfos information

2 Set of algorithm DigestAlgorithms identifiers

2.1 Algorithm identifier Algorithmldentifier

3 Encrypted EncryptedContentlnfo Content information

4 Certificates Certificates

5 Certificate Crls revocation lists

6 Signer information Signerlnfos

(83) Recipientlnfo

(Bncrypted key)

(A3) Signerlnfos

(digital signature)

(A4) Certificates

(X.509)

Content

Set integer value '1'

Set ONE set of Recipientlnfo only (see table 83)

Set ONE set of algorithm identifiers {sha-1} on Iy

Set one EncryptedContentlnfo (see table 82)

Set one Certificates (see table A4)

Not used (set no data)

Set one Signerlnfos (see table A3)


Table 82 EncryptedContentlnfo - top level


1 Content type ContentType Set object identifier {pkcs-7 1}

2 Content ContentEncryptionAlgorithm AI!~orithm OBJECT identifier encryption of content encryption algorithm (recommended algorithm:

dES-EDE3-CBC)

3 Encrypted content EncryptedContent Encrypted user data

Table 83 Recipientlnfo - top level


1 Version Version Set integer value '1'

2 Issuer and serial IssuerAndSerialNumber Issuer and serial number of number cert ificate including public

key for encrypting user data encryption key

3 Key encryption KeyEncryptionAlgorithm AI!gorithm OBJECT identifier algorithm for encrypting user data

encryption key (recommended algorithm: rsaEncryption)

4 Encrypted key EncryptedKey Encrypted decryption key for user data


6.2 Transmission mechanism The transmission mechanism operates as follows: • An electronic session is established between the applicant and the EPO. • The applicant transmits the signed and encrypted package. • When the signed and encrypted package is received, its contents are checked for the presence of viruses and the

Main document

wrapped application documents object is processed t o create its unique message digest . • This digest is compared with the message digest included in the wrapped and signed package. If they match, an acknowlledgement of receipt is sent t o the applicant. If they do not, t he applicant is informed accordingly. The session is then ended.

Ref. and accomp. docs o

Wrapping /? / P ' i ZIP

V ---,... Main Ref. §] doc. doc. . . . . ..

docs

Ii II


Message digest function

Pack as PKCS#7 signed data type

Message digest

Message digest

Digital signature


X.509

Application documents data item

6.2.1 Checking the message digest When the EPO receives the wrapped application documents, it opens the data items in them and ascerta ins the role of each one according to the information in the header object.

6.2.2 Confirmation certificate The confirmation certifi cate data item includes a certificate data item, a header object data item indicating that the corresponding packet is a confirmation certificate, and, optionally, the application documents data item received with the new application .

In the event of a communications or message digest comparison problem, the confirmation certificate conta ins information about the problem.

The confirmation certificate is packaged as a signed and encrypted packagB, as described above.

38 Beilage zum Amtsblatt Nr. 4/2001/ Supplement to Official Journal No. 4/2001 / Supplement au Journal officiel nO 4/2001 2001

Applicant

Confirmation certificate

+----y ... Unpack PKCS#7 signed data type


~POSignature I X.S09

Certificate data

Header object data

Certificate data

Document data

Confirmation certificate data Signer

X.S09

Document data

The confirmation certificate is used to inform the applicant of the receipt ofthe application and must contain an XML version of this information. It may also contain a formatted version of the data in PDF. These files are combined in a single ZIP file and signed using the EPO's digital certificate.

6.3 Transmission protocol The EPO uses a transfer protocol based on HTIP in conjunction with SSL.


EPO

Pack as PKCS#7 signed data type

Confirmation ~POSignature I certificate

X.S09

Certificate data

Header object data

Certificate data

Pack as PKCS#7 enveloped encrypted data type

Confirmation certificate data

7 Physical media

Document data

Signer

X.S09

The EPO also accepts electronic filing on CD-R. Each CD-R should contain one application only, in the form of a signed WAD written into the root directory. The name of the signed WAD file should be "WAD.ZIP". The accompanying paper form should include details of the application or document and should refer to the "WAD.zIP" file on the CD-R. The CD-R volume name should be based on the applicant's reference number.


Annex - Diagrams illustrating the standard

The following diagrams and text provide additional (simplified) information about the standard.

A signed and encrypted package may be thought of as a "box within a box"

The "inner box" (A 1 : wrapped and signed package, described below) is used to bind the documents themselves to the digital signature and the applicant's certificate

Documents & additional

files

PACKAGE (81)

-.., ...... -"0'0'0100 0100101100 0101001010 0"10'0101

Simplified anatomy of a signed and encrypted package

Figure 1 illustrates, for non-technical readers, the components of the signed and encrypted package mechanism specified in this standard. The diagram has been intentionally simplified to obscure technical detail that may distract the reader from the key issues of the package design. For example, the ZIP wrapping has been left out, and encoding standards for objects are not addressed.

High-level

C.rtiflalte m Regl$lered

Atry No. 1234

The package contains the package header and the transmission data files, as well as the wrapped and signed documents

The "outer box" (the signed and encrypted package) is used to transmit the contents securely

The package includes an encrypted key that the recipient (for example, the EPO) uses to open the package and read the contents. It also includes a digital signature and certificate for validating the integrity of the data.

Figure 1: Signed and encrypted package


Simplified anatomy of a wrapped and signed package

A wrapped and signed package may be thought of as a "box containing documents"

The "box" (the wrapped and signed package) is used to bind the documents to the digital signature and the applicant's certificate

Figure 2: Wrapped and signed package

Digital signature

1101010100 0100101100 0101001010

Patent documents

and additional

files

High-level certificate

Jane Dee me Registered Atty Ne.12345

-----

The package contains all of the files that make up the application (documents, images, etc.)

The package includes a digital signature and a certificate for validating the integrity of the data, and is optionally used (in the case of an enhanced electronic signature) as the signature for the documents

been 'zipped' together into a single file and placed in the root directory of the physical media.

Anatomy of the wrapped application documents object Certificate/signature types

The wrapped application documents object in section 5 defines how documents are "wrapped" together. In the case of offline submission on physical media, the further steps of creating the wrapped and signed package and the signed and encrypted package are optional. A wrapped application documents object consists of files that have

Enhanced electronic signature

Basic electronic signature

High-level certficate

11(110101001 Ol\)()IOIIOOI 01010010101 011101010 10

11010101001 010010 11001 01010010101 0 111010 1010

High-le\ el C'c r tifk:.te

, ,,' Doc ffi R .. -gistcn:d tpO

Any 12345

High-h~,,·tJ cf:'r1i fic~ te

,,,,,,[)o., ffi Registered ~ Alty 12345

Figure 3: Certificate/signature types

The diagrams in Figures 3 to 7 illustrate the differences between the types of "digital certificate" and "electronic signature" options as specified in the standard. Each diagram shows a "box" representing the wrapped and signed package.

Low-level certificate

Lo,,·h:~vel certificate Jane Doc Non-j do,.:(a I:lw.com

Low-le\ el cC'rtificliite Jane Doc Non-V'.I1idatOO jdCM.:(a1Iaw,com


Digital signature

1101010 0010110

Patent document

</enhanced signature>

Jane Doe Registered

I Atty No. 1234

Figure 4: Enhanced electronic signature/high-level certificate

Digital signature

110101010 001011001 001010101

Patent document

</enhanced

signature>

Low-level certificate

Jane Doe

Non-validated

[email protected]

Figure 5: Enhanced electronic signature/low-level certificate

Enhanced signature tag refers to the package signature

Digital signature serves as document signature and also validates package integrity

High-level certificate ensures package from validated applicant

Enhanced signature tag

refers to the package

signature

Digital signature serves as document signature and also validates package integrity

ow-level certificate used to validate digital signature


Digital signature

1101010100 0010110010 0010101011

Patent document

/jane doe/

I High-level certificate

Jane Doe !JJ EPO

Registered

l Atty No.123

Figure 6: Basic electronic signature/high-level certificate

Digital

signature

110101010 001011001 001010101

Patent document

Ijane doel

Low-level certificati

Jane Doe - '-t-+---tltr-+-

Non-validated II

I [email protected] .

Figure 7: Basic electronic signature/low-level certificate

Basic signature indicates signer of document

Digital signature serves to validate integrity of package only

High-level certificate ensures package from validated applicant

Basic signature indicates signer of document

Digital signature serves to validate integrity of package only

Low-level certificate used to validate digital signature


Transmission mechanism/packaging combinations

Figure 8 shows the various transmission mechanism/ packaging combinations that are permissible. The following applies to each transmission mechanism: (a) Online/internet: a signed and encrypted package must be used.

(b) Online/secure (channel encryption such as a private network): a signed and encrypted package or wrapped and signed package must be used. (c) Offline/physical media: either a signed and encrypted package, a wrapped and signed package, or a wrapped application documlsnts package may be used.

~ Signed and encrypted package Wrapped and signed package Wrapped application documents

0 0 Online/ () lEa-ell, ) Internet Internet

Not permitted Not permitted

0 Online/ () ) () - ) -- --;;;::--..- =~.;

Secure Secure Secure

Not permitted

Offline @ 0 ~ media

Figure 8: Transmission protocols and packages permitted


Decision du President de l'Office europeen des brevets du 7 decembre 2000, relative au depot electronique de demandes de brevet europeen et de documents produits ulterieurement

Le President de l'Office europeen des brevets (OEB), vu les regles 24(1), 27bis, 35(2), 36(5), 77(2)d) et 101 CBE,

vu les conditions de base que doit remplir toute piece electronique, a savoir :

a) I'authenticite, c'est-a-dire la confirmation qu'un document est bien ce qu'il pretend etre et que son auteur est bien la personne censee en etre I'auteur ;

b) I'integrite, c'est-a-dire la cohe'rence des donnees, notamment pouvoir deceler et eviter I'alteration et la destruction non autorisees de ces donnees;

c) la confidentialite, c'est-a-dire veiller a ce que I'existence ou Ie contenu d'un document ne soient pas divulgues a des personnes non autorisees, et

d) la non-repudiation, c'est-a-dire veiller a ce que I'expediteur (avec la collaboration du destinataire) dispose de preuves fiables du fait que les donnees ont bien ete transmises, et que Ie destinataire dispose de preuves fiables concernant I'identite de I'expediteur, afin qu'aucune des parties ne puisse nier de maniere credible avoir envoye ou re9u les donnees, et qu'un tiers puisse en verifier I'integrite et I'origine,

vu les normes de base en matiere de gestion des pieces electroniques, a savoir que:

(1) tous les documents deposes sous forme electronique doivent pouvoir etre imprimes sur papier et transferes sur un support d'archivage sans perte de contenu, ni alteration materielle ;

(2) les renseignements recueillis a chaque fois par les systemes informatiques au sujet des pieces electroniques, souvent appeles metadonnees, doivent egalement etre consideres comme faisant partie desdites pieces et conserves par ces systemes informatiques ;

(3) les documents electroniques doivent etre envoyes dans un format de fichier electronique d8tini par I'office, et les copies d'archive doivent egalement etre conservees dans Ie format electronique dans lequel elles ont ete envoyees;

(4) tous les depots electroniques doivent faire I'objet d'un accuse de reception adresse a I'expediteur pour indiquer que I'office a bien re9u Ie document. L'accuse de reception doit indiquer I'identite de I'office, la date et I'heure de reception du document (qui seront la date et I'heure officielles de reception par I'office), ainsi que tout numero de r8terence ou de demande attribue par I'office, Ie cas echeant;

(5) tout office qui accepte Ie depot electronique doit aussi permettre I'envoi de documents sur papier. Ces documents sur papier peuvent etre scannes de fa90n a faciliter la creation d'un dossier electronique unique;

(6) un mecanisme doit etre prevu afin de garantir I'authenticite et I'integrite du document depose sous forme electronique. Cela suppose la possibilite de verifier I'identite de I'expediteur (Ie deposant ou son mandataire), ainsi que la possibilite de verifier qu'un document n'a pas Me modifie sans autorisation depuis son depot;

(7) tout systeme de depot electronique doit prevoir des mecanismes de sauvegarde et de restauration pour proteger les depots electroniques contre ses propres d8taillances;

(8) les pieces electroniques doivent etre conservees et accessibles a long terme ;

(9) I'absence de virus et d'autres formes de logiciels nuisibles doit etre verifiee dans tous les fichiers electroniques avant leur traitement, et des mesures appropriees doivent etre prises afin de preserver, si possible, la date de depot;

(10) I'acces aux ordinateurs utilises pour Ie depot electronique ne doit pas rnettre en perilla securite des autres reseaux et applications de I'office ;

(11) les systemes de gestion des pieces electroniques doivent prevoir des mecanismes d'assurance et de controle de la qualite des documents produits ;

(12) les systemes de gestion des pieces electroniques doivent mettre en oeuvre une piste de controle gardant trace de toutes les adjonctions ou modifications apportees aux pieces electroniques et y consigner les renseignements concernant la reception et la production de chaque piece ainsi que de toute modification apportee a une piece;

(13) si I'acces a des donnees confidentielles par des moyens electroniques est perm is, il doit etre securise et reserve a un public auto rise. Des mesures doivent etre prises pour proteger ces fichiers contre toute alteration. Lorsqu'un deposant, un mandataire ou des membres autorises du public ont acces a des fichiers par des moyens electroniques, des renseignements doivent etre consignes sur I'identite de la partie concernee, sur la date (et eventuellement I'heure) de la transaction et sur tout envoi de documents. Ces renseignements doivent rester confidentiels ;

(14) dans la mesure prevue par la CBE, Ie public doit pouvoir avoir acces aux demandes de brevet europeen et aux brevets europeens publies ; et

(15) tout document electronique doit a sa reception etre copie sur un support a lecture seule,

decide:

Article premier Depot de demandes de brevet europeen

Les demandes de brevet europeen peuvent etre deposees a I'OEB sous forme electronique comme suit:

a) en ligne, aupres des serveurs informatiques de l'Office europeen des brevets, a I'adresse suivante : https://secure.epoline.org ou

b) sur CD-R.

Les demandes de brevet europeen peuvent etre egalement deposees sous forme electronique aupres des services nationaux competents des Etats contractants qui autorisent ce mode de depot. Les dispositions nationales des Etats contractants qui prescrivent qu'un premier depot doit etre effectue aupres de l'Office national ou que Ie depot aupres d'une autre autorite est soumis a une autorisation preal8lble (article 75(2) CBE) ne sont pas affectees.


Article 2 Norme relative au depot electronique

La norme technique relative au depot electronique figurant en annexe (denommee ci-apres "Ia norme") est partie integrante de la presente decision. Toute version future remaniee de cette norme ou toute norme future recommandee par l'Organisation Mondiale de la Propriete Intellectuelle pour Ie depot electronique de demandes nationales de brevet sera applicable apres publication d'une decision correspondante du President de l'Office europeen des brevets.

Article 3 Etablissement des pieces

Les pieces deposees conformement a I'article premier doivent iHre etablies a I'aide soit du logiciel fourni gratuitement par I'OEB, soit d'un logiciel certifie par I'OEB comme etant conforme a la norme.

Article 4 Presentation des pieces

Les pieces de la demande de brevet europeen, V compris les dessins, deposees conformement a I'article premier, doivent etre presentees dans Ie format specifie dans la norme. Les listes de sequences figurant dans les demandes deposees conformement a I'article premier, alinea a) ne doivent pas etre presentees sur un support separe de donnees.

Article 5 Requete en delivrance

Toute requete en delivrance d'un brevet europeen, deposee conformement a I'article premier, doit comporter, outre les informations requises a la regie 26(2) CBE, I'adresse electronique du demandeur, ainsi que celie de tout mandataire eventuellement designe.

Article 6 Lisibilite Fichiers infectes

(1) L'OEB verifie des leur reception si les demandes de brevet europeen deposees conformement a I'article premier

a) sont lisibles et

b) si elles contiennent des virus informatiques ou d'autres formes de logiciels nuisibles.

(2) Si la demande de brevet europeen est illisible en totalite ou en partie, I'OEB considere que la partie du document qui est illisible n'a pas ete re9ue et, si possible, en avise rapidement Ie demandeur.

(3) S'il est constate que la demande de brevet europeen est infectee par un virus informatique ou par un logiciel nuisible, I'OEB la considere comme illisible et n'est tenu ni de I'ouvrir, ni de la traiter. L'OEB met en oeuvre tous les movens dont il dispose normalement pour lire Ie document afin de pouvoir lui attribuer une date de depot et, si possible, avise rapidement Ie demandeur.

(4) S'il est constate que la demande de brevet europeen presente les detauts vises aux paragraphes 2 et 3, et qu'il n'est pas possible par consequent de lui accorder une date de depot, I'OEB invite si possible Ie demandeur a remedier aces detauts dans un delai qu'il lui impartit. La date de depot sera celie a laquelle il aura ete remedie

aux detauts. S'il n'est pas remedie en temps utile a ces detauts, la dernande n'est pas traitee en tant que dernande de brevet europeen.

Article 7 Examen relatif au respect de certaines conditions de forme

Si la demande de brevet europeen est presentee dans un format non conforme a celui specifie a I'article 4, I'OEB s'efforce dans une mesure raisonnable de lire les pieces deposees aux fins de I'attribution d'une date de depot. S'il n'v parvient pas, I'article 6(4) est applicable. S'il V parvient, I'OEB invite Ie demandeur, dans un delai qu'il lui impartit, a presenter de nouveau sa demande dans un format conforme a cl9lui specifie a I'article 4. Si la demande n'est pas representee en temps utile dans Ie format prescrit, elle est rejetee conformement a I'article 91 (3) CBE.

Article 8 Depot d'autres pi/kes

Si la demande de brevet europeen est deposee conformement a I'article premier, tout pouvoir ainsi que to ute designation d'inventeur peuvent egalement etre deposes conformement a l'artilCie premier. Les articles 3, 4 et 6 sont applicables. Si ces pieces sont presentees dans un format non conforme a clelui specifie a I'article 4, Ie demandeur est invite ales representer dans un format conforme a celui specifie a I'article 4, dans un delai que lui impartit I'OEB. Si un pouvoir n'est pas represente en temps utile dans Ie format pmscrit, la regie 101(4) CBE s'applique. Si la designation de I'inventeur n'est pas representee en temps utile dans Ie format prescrit, I'article 91(5) CBE s'applique.

Article 9 Pieces originales ·- nombre d'exemplaires Version authentique

(1) Les pieces deposees conformement aux articles premier et 8 sont reputees etre les pieces originales pour toutes les procedures engagees par la suite devant I'OEB. Elles sont produites en un exemplaire.

(2) Lorsqu'un document a ete depose sur CD-R conformement a I'article premier ou 8, la version electronique du document obtenue par I'OEB a partir du CD-R et stockee dans Ie dossier electronique de la demande de brevet europeen est reputee etre la version authentique du document. En cas de contestation par Ie deposant ou par des tiers, des verifications pourront etre effectuees a I'aide du CD-R original qui sera conserve pendant la peri ode prevue a la regie !95bis CBE.

Article 10 Confirmation sur papier

(1) II n'est pas exi<ge de confirmation sur papier pour les documents deposes conformement aux articles premier et 8.

(2) L'OEB ne tiendra pas compte des confirmations sur papier qui auraient pu neanmoins etre produites, a moins que Ie demandeur ne Ie lui ait expressement demande, auquel cas I'OEB pourra etre amene a modifier la date de depot deja accordiee.

(3) Toute confirmation sur papier qui aura ete produite devra etre clairernent signalee en tant que telle et contenir les informations permettant a I'OEB de la rattacher a la piece correspondante deposee par voie electronique.


Article 11 Signatures

(1) Lorsque la demande de brevet europeen est deposee conformement aux dispositions de I'article premier, la signature requise dans la requete en delivrance d'un brevet europeen doit figurer sous I'une des formes suivantes :

a) image en fac-simile de la signature manuscrite du signataire;

b) signature electronique, c'est-a-dire donnees sous forme electronique rattachees ou associees logiquement a d'autres donnees electroniques (message electronique), utilisees comme methode d'authentification du signataire du message et servant a indiquer qu'il approuve les informations contenues dans ce message; ou

c) signature electronique avancee, c'est-a-dire signature electronique remplissant les conditions suivantes :

i) etre liee uniquement au signataire ;

ii) etre creee par des moyens que Ie signataire peut garder sous son controle exclusif ; et

iii) etre liee aux donnees auxquelles elle se rapporte de telle sorte que toute modification ulterieure des donnees puisse etre detectee.

(2) Une signature electronique au sens du paragraphe 1 b) est constituee d'une serie de caracteres choisis par Ie signataire pour exprimer son identite et signifier son intention de signer Ie message electronique en question; cette serie de caracteres est precedee et suivie d'une barre oblique (f).

(3) Une signature electronique avancee au sens du paragraphe 1 c) est une signature numerique produite a I'aide d'un certificat genere par une infrastructure a cle publique et de la cle privee correspondante.

(4) Dans tous les autres cas ou une signature est requise en vertu de la CBE, Ie paquet de donnees transmises doit etre assorti d'une signature electronique avancee au sens du paragraphe 1 c) et du paragraphe 3. Les pieces a I'interieur de ce paquet peuvent egalement etre signees conformement au paragraphe 1 a) ou aux paragraphes 1 b) et 2.

(5) Si la requete en delivrance d'un brevet europeen ou tout autre document relatif a une demande de brevet europeen, deposes conformement a I'article premier, lettre a, ne comportent pas de signature ou si la signature apposee n'est pas conforme aux dispositions pertinentes des paragraphes 1 a 4, I'OEB invite Ie demandeur a remedier a cette irregularite dans un delai qu'illui impartit. S'il n'est pas remedie en temps utile a cette irregularite, Ie document est repute n'avoir pas ete re9u.

(6) Les demandes de brevet europeen et autres documents produits sur CD-R doivent etre accompagnes d'un document sur papier qui doit porter une signature manuscrite, permettre I'identification du demandeur ainsi que de son mandataire et com porter egalement une adresse pour la correspondance et une liste des fichiers contenus sur Ie CD-R.

Article 12 Accuse de reception

(1) La reception des documents deposes conformement a I'article premier a) est confirmee electroniquement pen-

dant la session de transmission. S'il s'avere que cette confirmation n'a pas Me transmise avec succes, I'OEB transmet rapidement cette confirmation par d'autres moyens, s'il dispose des informations voulues pour ce faire.

(2) L'accuse de reception devra indiquer I'identite de I'Office, la date et I'heure de la reception du document, un numero de reference ou de depot attribue par l'Office, ainsi qu'une liste des fichiers transmis. L'accuse de reception comportera aussi un condense numerique des documents transmis.

(3) L'accuse de reception n'equivaut pas a I'attribution d'une date de depot.

Article 13 Paiement des taxes

Les dispositions relatives au paiement des taxes ne sont pas affectees par la presente decision.

Article 14 Notifications de I'OEB

L'OEB precisera quelles notifications peuvent etre signifiees en ligne. Lors du depot de la demande de brevet europeen, les demandeurs indiqueront s'ils souhaitent que des notifications leur soient signifiees en ligne, et, dans I'affirmative, preciseront lesquelles. Les notifications continueront sinon a leur etre signifiees sur papier jusqu'a nouvel ordre.

Article 15 Significations

(1) Les significations effectuees sur papier sont regies par les regles 78, 79 et 80 CBE.

(2) Lorsque des notifications sont signifiees en ligne, I'OEB informe Ie demandeur qu'une notification lui a Me adressee et qu'il doit la recuperer. A cet effet, I'DEB envoie au demandeur un courrier electronique contenant un lien avec la boitlB aux lettres du deroandeur dans Ie serveur de I'OEB. Si une notification n'est pas recuperee dans un delai de cinq jours a compter de I'envoi du courrier electronique, il est procede a une signification sur papier conformement au paragraphe 1.

(3) Les notifications signifiees conformement au paragraphe 2 sont reputees re9ues Ie dixieme jour suivant la date d'envoi du courrier electronique.

(4) Les dispositions des regles 81 et 82 CBE ne sont pas affectees par la presente decision.

Article 16 Delais

Les regles 83, 84 et 85 CBE sont applicables en matiere de delais. Seuls les demandeurs qui ont accepte de recevoir des significations en ligne peuvent egalement requerir des prorogations de delais en ligne.

Article 17 Entree en vigueur

La presente decision prend effet Ie 8 decembre 2000.

Fait a Munich, Ie 7 decembre 2000.

Ingo KOBER President


Norme technique relative au depot electronique de demandes de brevet europeen et de documents produits ulterieurement

1 Generalites

Le present document expose la norme technique relative au depot electronique de documents aupres de I'OEB. II s'appuie sur la norme tripartite basee sur I'infrastructure a cle publique (ICP) qui a ete incorporee a l'Annexe F, Appendice I des Instructions administratives du PCT.

L'environnement ICP fournit un ensemble de services destines au traitement d'informations de nature confidentie lie. L'utilisation de la cryptographie permet a I'ICP de satisfaire aux exigences suivantes : a) authentification - consiste a s'assurer de la validite des transmissions, des messages ou de I'identite des emetteurs, ainsi que du fait qu'un destinataire est autorise a recevoir des types d'informations particuliers ; b) integrite des donnees - consiste a veiller a ce que les donnees ne subissent pas de modifications a partir du moment de leur envoi, et a eviter leur modification, alteration ou destruction par accident ou par suite d'un acte malveillant; c) non-repudiation - permet a I'expediteur des donnees de disposer de preuves solides et fondees du fait que les donnees ont bien ete transmises (avec la collaboration du destinataire) et au destinataire de beneficier de preuves solides et fondees concernant I'identite de I'expediteur, ces preuves devant etre telles que ni I'un ni I'autre ne puisse de maniere credible nier avoir ete en possession de ces donnees, et qu'un tiers puisse verifier I'integrite et I'origine de ces donnees; d) confidentialite - consiste a veiller a ce que les informations ne puissent etre lues que par des personnes autorisees.

La presente norme enonce les exigences obligatoires pour tous les demandeurs prenant part au depot electronique, ainsi que des exigences facultatives.

2 Portee

La presente norme technique couvre les exigances dans les domaines suivants : a) securite et ICP b) signatures electroniques c) prescriptions relatives au format des documents d) envoi

3 Securite et ICP

3.1 Infrastructure a cle publique Dans la presente norme, I'assemblage et la transmission sont executes en utilisant la technique ICP. Les mises a jour de la norme pourront inclure d'autres techniques de securite des qu'elles seront disponibles et realisables.

La mise en oeuvre des ICP s'effectuera conformement aux recommandations etablies par Ie groupe de travail sur I'interoperabilite des infrastructures a cle publique (PKIX) de l'lnternet Engineering Task Force (lETF), exposees dans I'appel a commentaires RFC 2459 de I'IETF.

Des paires de cles et des certificats numeriques distincts devront etre utilises aux fins de I'etablissement de la signature numerique et du chiffrement.

3.2 Certificats numeriques Lorsque la norme precise que I'utilisation d'un certificat numerique est requise, ce certificat devra suivre la recommandation X.509 de l'Union internationale des telecommunications (UIT)(version 3) en ce qui concerne Ie format des certificats.

Un certificat numerique est requis en cas de communication electronique avec I'OEB.

La norme admet deux categories de certificats numeriques:

Certificat qualifie : certificat numerique emis par une autorite de certification a I'intention du demandeur, ce certificat pouvant etre utilise pour authentifier I'identite du demandeur. L'autorite de certification doit figurer sur la liste des autorites de certification" reconnues", publiee par I'OEB (cf. 3.3 ci-dessous).

Certificat simplifie : certificat numerique emis par I'OEB a I'intention du demandeur, sur requete de ce dernier. Pour obtenir un certificat simplifie, Ie demandeur doit indiquer son nom et son adresse de courrier electronique, mais il n'est pas tenu de fournir des preuves de son identite.

3.3 Autorites de cE!rtification L'OEB precisera quelles sont les autorites de certification qu'il accepte. Cette liste d'autorites de certification "reconnues" inclura un lien vers I'enonce de politique ICP publie par chacune de ces autorites.

Les autorites de certification reconnues sont chargees de veiller a I'exactitude des certificats electroniques qui "prouvent" qu'une partie est bien ce qu'elle pretend etre. Elles stockent les informations relatives a tous les certifi cats qu'elles delivrent dans une structure d'annuaire conforme a la recommandation X.500 de I'UIT. Ces systemes comprennent, pour la publication et I'extraction de certificats numeriques d'utilisateurs, une interface externe conforme au protocole simplifie d'acces a I'annuaire «Lightweight Directory Access Protocol» (LDAP), utilisant I'appel a commentaire RFC 1777 (mars 1995) du groupe de travail de I'IETF sur les reseaux. En outre, les autorites de certification publient des informations concernant la revocation des certificats etablis selon la norme X .509.

L'OEB aura acces aux informations ayant trait a la revocation des certificats. Chaque fois qu'un certificat est utilise aux fins d'identification, I'OEB consultera les informations relatives a la revocation des certificats, publiees par I'autorite de certification concernee, afin de s'assurer que Ie certificat n'a pas ete revoque.

3.4 Signatures nurneriques Les signatures numeriques utilisees pour signer des documents electroniquEls aux fins du depot electronique doi vent respecter Ie format et la pratique specifies dans la norme PKCS #7 de RSA Laboratories relative a la syntaxe du message cryptographique, intitulee Cryptographic Message Syntax Standard (version 1.5) en ce qui concerne la definition du contenu du type signed data (donnees signees).

La construction de ces signatures necessite un certificat satisfaisant aux conditions indiquees au point 3.2 ci-dessus.

Toutes les signatures numeriques doivent etre codees selon les regles de cod ages distinctives (DER) detinies dans la recommandation X.690 de I'UIT.


3.5 Algorithmes cryptographiques En fonction des besoins, on pourra utiliser aussi bien des algorithmes symetriques (8 cle secrete) que des algorithmes asymMriques (8 cle publique). Un algorithme qui serait interdit en vertu de la loi nationale d'un pays ne pourra pas etre utilise pour Ie depot electronique de documents provenant de ce pays. Les algorithmes mis en oeuvre dans un materiel ou un logiciel ne pourront pas etre employes d'une maniere contraire aux restrictions 8 I'exportation imposees par Ie pays d'origine pour les materiels ou les logiciels consideres.

Dans la mesure du possible, I'algorithme rsaEncryption sera utilise com me algorithme de chiffrement asymetrique et dES-EDE3-CBC comme algorithme de chiffrement symMrique. Le meme algorithme de chiffrement asymetrique devrait etre employe pour creer les certificats, les signatures et les enveloppes numeriques.

3.6 Enveloppement des donnees Les donnees d'un document electronique qui font I'objet d'un chiffrement destine 8 en assurer la confidentialite aux fins du depot electronique devront respecter Ie format et la pratique specifies dans la partie consacree 8 la definition du contenu du type signed and enveloped data (donnees signees et enveloppees) figurant dans la version 1.5 de la norme PKCS #7 de RSA Laboratories relative 8 la syntaxe du message cryptographique.

3.7 Algorithmes de compactage A la chaine de caracteres du message devra etre applique I'algorithme de hachage 8 sens unique SHA-1, algorithme de compression 8 haut niveau de securite qui cree une empreinte du message.

4 Mecanismes de signature

La presente norme prevoit un certain nombre de types de signatures qui seront acceptees pour Ie depot electronique : a) signatures electroniques simples

i) image en fac-simile de la signature de I'utilisateur ii) chaine de caracteres

b) signature electronique renforcee i) signature numerique PKCS#7

REMARQUE : bien qu'un utilisateur puisse choisir de ne pas appliquer un mecanisme de signature electronique renforcee au document lui-meme, une signature numerique PKCS#7 est requise pour empaqueter Ie document constitutif de la demande, compacte, tel que decrit au point 5.3. Cf. point 6.1 pour un exemple de paquet compacte et signe.

La signature electronique simple est encodee dans la structure "Correspondant" du document XML comme specifie dans la partie de la DTD (Definition Type Document) indiquee ci-dessous :

< !ELEMENT electronic-signature < !ATTLIST electronic-signature

(basic-signature , enhanced-signature?) >

DATE-SIGNED CDATA PLACE-SIGNED CDATA

< ! ELEMENT basic-signature


(fax I text-string) >

< !ELEMENT fax EMPTY > < !ATTLIST fax

FILE-NAME ENTITY #REQUIRED >

< !ELEMENT text-string (#PCDATA) >

< ! ELEMENT enhanced-signature (pkcs7) >



Une signature electronique simple dans un document XML peut etre completee par I'adjonction d'une signature numerique aux documents constitutifs de demande, compactes.

4.1 Signature en fac-simile Pour creer ce type de signature, Ie fichier XML doit inclure I'element <fax> et un renvoi 11 une entite externe inscrite dans I'attribut FILE-NAME qui designe Ie fichier contenant la representation en mode point (bitmap) de la signature, comme indique ci-dessous :

<electronic-signature DATE-SIGNED="01/01/2000"> <basic-signature>

<fax FILE-NAME= "signature.tif" /> </basic-signature>


Le fichier de la representation en mode point doit etre une image monobande de 300 dpi, 11 codage Intel et au format TIFF groupe 4 ou JFIF(JPEG).

4.2 Signature composee d'une chaine de caracteres Pour creer ce type de signature, Ie document XML doit comprendre I'element <text-string> contenant une chaine de caracteres qui est I'equivalent de la signature "manuscrite" de I'utilisateur, encadree par Ie caractere 'barre oblique' "/", comme Ie montre I'exemple ci-dessous :


<text-string>/janedoe/ </text -string> </basic-signature>


La chaine de caracteres doit etre une chaine de caracteres, ne comprenant pas Ie caractere "/", choisie par I'utilisateur comme signature electronique, comme Ie montrent les exemples ci-dessous :

<text-string>/John Smith/</text-string> <text-string>/Tobeornottobe/</text-string> <text-string>/1345728625235/</text-string> <text-string>/G0nter Fran~ois/</text - string>

4.3 Signature numerique PKCS#7 Le type "donnees signees" PKCS#7 est produit a partir du message electronique par Ie signataire qui utilise sa cle de signature privee pour chiffrer I'empreinte du message. II com porte une copie du certificat numerique delivre au signataire lors de I'envoi.

L'utilisation d'une signature PKCS#7 doit etre mentionnee dans Ie fichier XML par I'element <pkcs7>, comme indique ci-dessous :

<electronic-signature DATE-SIGNED= " Ol/Ol/2000"> <enhanced-signature>



5 Exigences en matiere de format des donnees

On utilise Ie mecanisme d'assemblage de documents pour combiner en un seul et meme objet binaire, appele document constitutif de la demande compacte (wrapped application document = WAD), 11 la fois les renseignements sur ce qui est transmis et Ie contenu de la transmission ; on applique ensuite les signatures numeriques et Ie chiffrement appropries.

5.1 Preparation de,s documents Dans chaque depot de documents, il y a un document principal XML, qui peut renvoyer expressement 11 tous les documents a envoyer en un seul paquet. Ces documents forment un tout IOfJique avec Ie document principal auquel ils sont incorpores par renvoi (nouvelle demande de brevet par exemple). En outre, un depot peut inclure d'autres pieces jointes (designation de I'inventeur, paiement de taxes, etc.).

Le document principal XML doit se conformer 11 I'une des DTD specifiees ci-dessous. Les documents auxquels il renvoie (entites externes) sont generalement des images incrustees, des tableaux, des dessins ou d'autres documents composes; ils peuvent etre codes en XML, ST25, PDF, ASCII, TIFF ou JFIF (JPEG). Les pieces jointes sont des documents distincts, mais en rapport, qui peuvent etre codes en XML, ST25, PDF, ASCII ou format image. Toute piece jointe XML doit egalement se conformer 11 I'une des DTD specifiees ci-apres.

Document principal

XML

Documents auxquels renvoie Ie

document principal XML

Autres pieces jointes -

XML,PDF ASCII, ST25, TIFF,JPEG

~


5.1.1 Formats a codage de caracteres

5.1.1.1 XML Tous les documents XML doivent se conformer a I'une des DTD specifiees ci-dessous. Les demandeurs peuvent creer des documents XML conformes a la presente norme en utilisant Ie logiciel client de depot electronique.

Le jeu de caracteres codes utilise pour tous les documents XML doit etre limite a celui specifie par la norme ISO/IEC 10646:2000 (Unicode 3.0) . Le schema de codage de caracteres standard pour les documents XML est UTF-S.

5.1.1.2 ST.25 Un document cree en utilisant les balises SGML de la norme ST.25 de I'OMPI peut etre introduit comme document externe dans Ie bloc des documents constitutifs de la demande, compactes (WAD).

5.1.1.3 ASCII Un document cree en plein texte ASCII peut etre inclus comme document externe dans un document WAD. Dans ce cas, Ie document principal XML doit comporter la page de code du texte ASCII.

5.1.2 PDF Les documents PDF a utiliser pour Ie depot electronique doivent repondre aux prescriptions suivantes :

Document Documents

a) compatibilite PDF V1 .3 b) texte non com prime pour faciliter la recherche c) texte non crypte d) pas de signature numerique e) pas d'objets incorpores en OLE f) toutes polices de caracteres incorporees, standard PS17 ou construites a !partir des polices Adobe® Multiple Master (MM).

Le format PDF est devenu la norme de facto pour I'echange de documents formates sur l'lnternet.

5.1 .3 Images Les images en fac-simile a utiliser pour Ie depot electron ique doivent repondre aux prescriptions suivantes :

format ° TIFF V6.0 avec compression du groupe 4, mono-

bande,codage Intel ou ° JFIF (JPEG) 200, 300 ou 400 dpi taille A4

5.2 Compactage des documents Le document principal, les documents auxquels il renvoie expressement et les autres pieces jointes, Ie cas echeant, sont compactes en un seul bloc de donnees. Ce bloc de donnees, dit "documents constitutifs de la demande, compactes" (WJlIDj, est cree par application du standard de compression ZIP. Le demandeur doit utiliser un logiciel d'archivage et de compression en format ZIP pour grouper les fichiers des documents qui constituent la demande electronique.

Autres pieces

principal auxquels renvoie jointes Ie document

17 principal

." / • Comp

0 [:J Pieces

prInc. ref. . .. .. . jointes

p Z IP

Documents constitutifs de la demande, compactl~s


Le logiciel employe pour creer Ie fichier ZIP doit etre conforme aux specifications du format ZIP, publiees dans Ie descriptif du logiciel PKZlp® de PKWARE® (revise au 8.1.1998).

Devront etre comprimes les fichiers correspondant a toutes les parties du document identifiees par ailleurs dans la presente specification. Tous les fichiers externes auxquels renvoie la demande doivent etre inclus dans I'envoi en fichier ZIP. Les noms de fichiers figurant dans Ie repertoire central du fichier ZIP doivent respecter les specifications du systeme d'exploitation applicable.

Tous les fichiers ZIP doivent presenter une structure de reperto ire plate. Lorsqu'une collection de fich iers doit etre integree dans un f ichier ZIP, il faut la compacter en un fichier ZIP unique qui sera incorpore a plat.

Le standard ZIP donne au logiciel de compression Ie choix parmi un certain nombre d'algorithmes de compression. La methode de compression par defaut sera la "deflation".

5.3 Signature des documents constitutifs de la demande, compactes Afin de lier la personne qui cree Ie paquet aux documents electroniques de la demande compactes, une signature numerique est ajoutee pour creer Ie paquet compacte et signe. L'adjonction de cette signature a pour objet d'identifier la personne qui cree Ie paquet et de permettre au destinataire de detecter toute alteration non autorisee encours de transmission.

Les specifications PKCS#7 sont appliquees pour la production d'un type "donnees signees" pour la signature.

Doc. Doc.

~ Pieces]

~ Type "d

pnnc. ref. ...... ref. jointes signees' PKCS#

onnees

7 p p

/ ~, ~

I Signature

I Documents constitutifs de la demande, compactes

I X.509

I

Paquet compacte et signe


(A 1) SignedData <top level> (PKCS#7 digital envelope for signature)

Data package

(A3) Signerlnfos

(di,gital signature) (A2) Contentlnfo

(user data)

(A4) Certificates

(X.SOg)

Regles de production de I'enveloppe numerique PKCS#7 aux f ins de certification

Identificateu r d' objet pou r sha-1 L'identificateur d'objet adopte pour sha-1 est defini dans les protocoles d'interconnexion OIW, partie 12. La definition est la suivante : Sha-1 OBJECT IDENTIFIER ::= (iso (1) identified-organization(3) oiw(14) sec:sig(3) algorithm(2) 26}

Identificateur d'objet pour Ie chiffrement RSA L'identificateur d'objet pour Ie chiffrement RSA est defini dans Ie standard de chiffrement RSA PKCS#1. La definition est la suivante : Pkcs-1 OBJECT IDENTIFIER: ::= {iso (1) member-body(2) US(840) rsadsi(113549) pkc:s(1) 1} RsaEncryption OBJECT IDENTIFIER::={pkcs-1 1}

Identificateur d'objet pour triple DES dES-EDE3-CBC OBJECT IDENTIFIER ::= (iso (1) member-body(2) US(840) rsadsi(113549) encryptionAlgorithm(3) 7}

Tableau A1 SignedData (donnees signees), premier niveau

n° Nom d'article Article PKCS#7 Contenu

1 Version Version Met1tre la valeur entiere '1'

2 Jeu d'identificateurs DigestAlgorithms d'algorithme

2.1 Identificateur d'algorithme Algorithmidentifier Mettre UN seul jeu d'identificateurs d'al!)orithme {sha-1}

3. Information relative Contentlnfo Mettre une information relative au au contenu contenu (voir Ie tableau A2)

4 Certificats Certificates Mettre un element Certificates (voir Ie tableau A4)

5 Listes d'annulation Crls Vide (ne rien mettre)

6 Information relative Signerlnfos Mettre un element Signerlnfos (voir au signataire Ie tableau A3)


Tableau A2 Contentlnfo (information relative au contenu) , premier niveau


1 Type de contenu ContentType Mettre un identificateur d'objet {pkcs-7 1}

2 Contenu Content Mettre les donnees utilisateur (binaires)

Tableau A3 Signerlnfos (informations relatives au signataire), premier niveau


1 Version Version Mettre la valeur entiere '1'

2 Emetteur et numero d'ordre IssuerandSerialNumber Emelteur du certificat et numero d'orclre de celui-ci selon la specification X.509 (concernant Ie certificat du signataire)

3 Jeu d'algorithmes DigestAlgorithms de compression

3.1 Identificateur d'algorithme Algorithmidentifier Mettre UN seul jeu d' identificateurs d'algorithme {sha-1} pour la production d'une empreinte de signature numerique

4 Attributs authentifies AuthenticatedAttributes Vide (ne rien mettre)

5 Algorithme de chiffrement DigestEncryptionAlgoritm Identificateur d'OBJET de de I'empreinte I'algorithme de chiffrement de

I'empreinte (algorithme recommande : rsaEncryption)

6 Empreinte chiffree EncryptedDigest Empreinte des donnees du message; Ie contenu est chiffre au moyen de la cle privee du signataire

7 Attributs non authentifies Una uth enticatedAttri butes Vide (ne rien m ettre)

Tableau A4 Certificates (certificats), premier niveau


1 Jeu de certificats Extended CertificatesAndCertificates

1.1 Le certificat X.509 Certificate (detini dans la Mettre UN seul jeu de donnees specification X.509) de certificat X.509


6. Envoi

6.1 Paquet de transmission L'OEB peut decider de ne pas utiliser Ie mecanisme d'enveloppement decrit sous Ie present point comme mecanisme de chiffrement pour la transmission, lorsque sont utilises un chiffrement au niveau de la voie d'acces du type SSL ou des supports materiels comme les CD-R.

Le lot de donnees qui est effectivement transmis dans I'echange entre Ie demandeur et I'OEB est appele paquet.

Le paquet contient plusieurs articles, variables selon Ie type de paquet. On y trouve : 1. un objet "en-tete", 2. un paquet compacte et signe, comportant les documents constitutifs de la demande compactes et signes, 3. des donnees de transmission telles que I'heure de la transmission.

Dans I'en-tete sont indiques Ie type de paquet, Ie nom de fichier de I'element "documents", etc. L'objet en-tete est toujours present dans Ie paquet signe et chiffre, et il est ecrit en XML.

----- ---. Objet Paquet

En-tete compacte et signe

[7

La marche a suivre pour creer Ie paquet signe et chiffre est la suivante : a) creation d'un paquet de transmission compacte par compression ZIP du paquet compacte et signe, avec les elements utilises pour la transmission, b) creation d'un paquet signe et chiffre pour la transmission sur Ie reseau,. avec chiffrement selon Ie type" donnees signees et enveloppees" PKCS#7.

La signature a pour objet d'assurer la combinaison et Ie contenu de chaque element, et de permettre au destinataire de detecter toute alteration non autorisee intervenue en cours de transmission . Le chiffrement vise a eviter I'interception illicite des donnees en cours de communication.

La signature numlerique pour Ie paquet compacte et signe peut etre produite soit par Ie demandeur, soit par son mandataire. La personne qui engage la transmission produit la signature numerique pour aboutir au type "donnees signees et chiffrees".

Donn. de

trans-mission

ZIP compactage

'l, Objet Paquet

En-tete compacte et signe

Paquet de transmission compacte

Paquet signe et chiffre

Donn. de

trans.

chiffr.

~ ~J

~l

Type "donnees signees et enveloppees" PKCS#7


(81) SignedAndEnveloped Data <top level> (PKCS#7 digital envelope for transmission)

Encrypted data package

(82) EncryptedContentlnfo (encrypted user data)

Regles de production de I'enveloppe numerique de transmission PKCS#7

(83) IRecipientlnfo

(encrypted key)

(A3) Signerlnfos

(digital signature)

(A4) Certificates

(X.SOg)

Tableau 81 SignedAndEnvelopedData (donnees signees et enveloppees), premier niveau



2 Informations relatives Recipientlnfos Mettre UN seul jeu d'elements au destinataire Recipientlnfo (voir tableau 83)

2 Jeu d'identificateurs DigestAlgorithms d'algorithme

2.1 Identificateur d'algorithme Algorithmidentifier Mettre UN seul jeu d'identificateurs d'algorithme {sha-1}

3 Information relative EncryptedContentlnfo Mettre un element contenu au contenu chiffre chiffre (voir Ie tableau 82)

4 Certificats Certificates Mettre un element Certificates (voir Ie tableau A4)

5 Listes d'annulation Crls Vide (ne rien mettre)

6 Informations relatives Signerlnfos Mettre un element Signerlnfos au signataire (voir Ie tableau A3)


Tableau 82 Encryptedcontentlnfo (information relative au contenu chiffre), premier niveau


1 Type de contenu ContentType Mettre I'identificateu r d' objet {pkcs-7 1}

2 Algorithmes de chiffrement ContentEncryptionAlgorithm Identificateur d'OBJET de du contenu I'algorithme de chiffrement du

contenu (algorithme recommande : dES - EDE3 - CBC)

3 Contenu chiffre EncryptedContent Donnees utilisateur chiffrees

Tableau 83 Recipientlnfo (information relative au destinataire), premier niveau



2 Emetteur et numero IssuerAndSerialNumber Emetteur et numero d'ordre du d'ordre certificat comportant la cle publique

pour Ie cryptage de la cle de chiffre-ment des donnees utilisateur

3 Algorithme de la cle KeyEncryptionAlgorithm Identificateur d'OBJET de de chiffrement I'algorithme de cryptage de la cle de

chiffrement des donnees utilisateur (algorithme recommande : rsaEncryption)

4 Cle cryptee EncryptedKey Cle cryptee pour Ie dechiffrement des donnees utilisateur


6.2 Mecanisme de transmission Le mecanisme de transmission fonctionne comme suit: • une session electronique est ouverte entre Ie demandeur et I'DEB; • Ie demandeur transmet Ie paquet signe et chiffre ; • a reception du paquet signe et chiffre, son contenu fait I'objet d'un contrale antivirus et I'objet "documents constitutifs de la demande compactes" est traite de maniere a creer son empreinte univoque ;

Document principal

• celle-ci est compa ree a I'empreinte initiale du message, contenue dans Ie paquet compacte et signe. Si les deux empreintes correspondent, un accuse de reception est envoye au demandeur. Si elles ne correspondent pas, Ie demandeur en est informe. La session peut alors prendre fin.

Doc. references et pieces jointes

I? / I?P / ZIP

~ --,... Doc. Doc. Pieces prine. ref. ..... . jointes

17 p ~

Documents constitutifs de la demande, eompaetes

Fonetion de haehage

Assemblage en signed data PKCS#7

Empreinte du message

Empreinte du message

Signature numerique

Docs. constitutifs de la demande, compactes

X.509

Element "documents constitutifs de la demande"

6.2.1 Verification de I'empreinte du message Lorsque I'DEB re90it les documents constitutifs de la demande, compactes, il en ouvre les differents elements et decide Ie role de chacun conformement aux indications qui figurent dans I'en-tete.

6.2.2 Certificat de confirmation Le certificat de confirmation com porte un article "donnees du certificat", un objet d'en-tete indiquant que Ie paquet correspondant est un certificat de confirmation et, a titre facultatif, I'element "documents constitutifs de la demande" re9u avec la nouvelle demande.

En cas de probleme dans les communications ou dans la comparaison des empreintes de message, Ie certificat de confirmation renseigne sur ledit probleme.

Le certificat de confirmation est mis sous forme de paquet signe et chiffre, comme decrit precedemment.


Demandeur

Certificat de onfirmation

I? Desassemblage du type signed data PKCS#7

Certificat de §ignature OEB I confirmation

I I X.S09

Donnees certificat

~ ~ Objet Donnees Donnees Donnees certifieat document

Verifi en-lEite doc. 11 ~ i D",,~mbl,g., ",hiff"m."" f

decompactage en enveloped data tYI=I PKCS#7

\ ele

I chif1.

Donnees certificat de I confirmation

signataire I

I ll509 I

Donnees document

L-___ -'

Le certificat de confirmation sert a informer Ie demandeur de la reception de sa demande ; il doit contenir une version XML de cette information. II peut egalement contenir une version des donnees formatee en PDF. Ces fichiers sont combines en un fichier ZIP unique et signes au moyen du certificat numerique de I'OEB.

6.3 Protocole de transmission L'OEB utilise un protocole de transmission HTIP par liaison securisee (SSL).

ertificat de onfirmation

OEB

Assemblage du type signed data PKCS#7

Certificat de §ignature OEB I confirmation

X.S09

DonnEies certificat

Objet donnees en-tete

Donnees certificat

Assemblage, chiffrement et

Donnees document

compactage en enveloped data type PKCS#7

Donnees certificat de confirmation

7 Supports materiels

signataire

X.509

L'OEB accepte egalement Ie depot electronique sur CO-R. Le CD-R ne peut contenir qu'une demande sous forme d'un document constitutif de la demande, compacte (WAD) figurant dans Ie repertoire de base. Le nom du WAD signe doit etre "WAD.ZIP". Le formulaire papier d'accompagnement doit inclure les details de la demande ou du document et se referer au fichier "WAD.ZIP" figurant sur Ie CD. Le noih de volume du CD-R doit se fonder sur Ie numero de reference du demandeur.


ANNEXE Diagrammes iIIustrant la norme

Les diagrammes et Ie texte suivants fournissent des explications supplementaires (simplifiees) relatives a la norme.

On peut se representer un paquet signe et chiffre sous forme d'une "boTte a I'interieur d'une boTte"

Documents de propriete intellectuelle et fichiers supplementaires

Structure simplifiel~ du paquet signe et chiffre

La figure 1 presente au lecteur non specialise les elements composant Ie mecanisme du paquet signe et chiffre tel qu'expose dans cette norme. Le diagramme a ete intentionnellement simplifie afin d'exclure les details techniques susceptibles de detourner Ie lecteur des elements essentiels de la conception du paquet. Par exemple, Ie compactage PKZIP n'est pas illustre, et les normes de cod age d'objets ne sont pas traitees.

Le paquet contient I'entete de paquet et les fichiers de transmission de donnees, ainsi que Ie paquet compacte et signe.

La "boite interne" (Ie paquet compacte et signe A 1 , decrit ciapres) est utilisee pour lier les documents a la signature numerique et au certificat du demandeur

PAQUET ANNEXE F (81) La "boite externe" (Ie paquet signe et chiffre) est utilisee pour transmettre Ie contenu de maniere securisee.

Clede chiffrement

00011 11000100 0100100101010 0101010001010 11010

Signature numerique

11010101001

01010010101 01110101010

Ccrtificat Qualifi6

JaneDoe

Numero d'enregistremet@ Atty#12345 ill

Le paquet comprend une cle chiffree utilisee par Ie destinataire (I'OEB, par ex.) pour "ouvrir" Ie paquet et en lire Ie contenu. Le paquet contient aussi une signature numerique et un certificat permettant de confirmer I'integrite des donnees.

Figure 1 : paquet signe et chiffre


Structure simplifiee du paquet compacte et signe

Le paquet contient tous les fichiers formant les documents constitutifs

On peut se representer un Documents -- de la demande, les

paquet compacte et signe --sous forme d'une "boite brevet et fichiers images, etc.

contenant des / - supphflmentaires

~ ~ documents".

I . ;# Le paquet contient une

signature numerique et un certificat permettant

La "boite" (Ie paquet Certificat qualifie I ..----:;-. ..- de confirmer I'integrite

compacte et signe) est Signature des donnees, et pouvant utilisee pour lier les numerique J,"' D~ 1Xr

~ eventuellement (dans Ie

documents a la signature 1101010100 numerique et au certificat

No. d'enregistrem PO cas d'une signature 0100101100

du demandeur. 0101001010

Figure 2 : paquet compacte et signe

Structure de ('objet "documents constitutifs de la demande, compactes"

12345

La section 5 concernant I'objet "documents constitutifs de la demande, compactes" decrit comment s'effectue Ie "compactage" de ces documents. Lorsqu'il s'agit du depot hors ligne sur supports materiels, les eta pes supplementaires destinees a la creation du paquet compacte et signe et du paquet signe et chiffre sont facultatives.

Signature electronique renforcee

Signature electronique simplifiee

Certificat qualifie

Certific:lI qu:tlifii-

110]0101001 J:meDoe m 01001011001 Numero

~:~::f:~~~?~ d'cnn .. 'glstrcmcnt

I!!!!'<g!" ~====u

110]0101001 1)1001011001 01010010101

01110101010 ~~~===!J

Figure 3 : types de certificats/signatures

electronique renforcee) servir de signature authentifiant les documents.

Un objet "documents constitutifs de la demande, compactes" se compose de fichiers qui ont Me groupes en un fichier «ZIP» unique, puis places dans Ie repertoire de base des supports materiels.

Types de certific,at/signature

Les diagrammes des figures 3 a 7 font ressortir les differences existant entre les types de "certificat numerique" et de "signature electronique" disponibles, tels que specifies dans la norme. Chaque diagramme illustre une "boite" representant Ie paquet compacte et signe.

Certificat simplifie

1101010100] 01001011001 01010010101 01110101010

Ctrtifiut simplifif

)",<Ooc 111 Non--confirmc [email protected]

2001 Beilage zum Amtsblatt Nr. 4/2001 / Supplement to Offici al Journal No. 4/2001 / Supplement au Journal officiel nO 4/2001 63

Signature numerique

0001010101011 1010101 110001 1110010010100

Document brevet

</Signature renforcee>

c:::::= Certificat qualifie

Jane Doe No. d'enregistr EP

I Atty No 1234

Figure 4 : signature electronique renforcee I certificat qualifie

Signature numerique

110101010 001011001 001010101

Document brevet

</Signature

renforcee>

Certificat simplifh~

Jane Doe

Non confirmee

I [email protected]

Figure 5 : signature electronique renforcee I certificat simplifie

La balise signature renforcee (enhanced signature) se rapporte a la signature du paquet.

La si!~nature numerique sert de signature aux documents et permet egalement de confium er I'integrite du paquet.

Le certificat qualiM atteste que Ie paquet provient d'un demandeur dont I'identite a ete confirmee.

La balise signature renforcee (enhanced signature) se rapporte a la signature du paquet.

La signature numerique sert de signature aux documents et permet egalement de confirmer I'integrite du paquet.

Le certificat simplifie est utilise pour confirmer la validite de la signature numerique.


Document --

brevet

/ /jane doe/ / /~

I Ji-------Signature ____ ~ 1 -- Certificat qualifie

Numerique

lane Doe ~ 1101010100 Numero EPO

0010110010 d' enregistrement

0010101011 Atty #12345 I ,

Figure 6 : signature electronique simple / certificat qualifie

Signature numerique

110101010 001011001 001010101

Document brevet

Ijane doel

I

Certificat simplifie

Jane Doe Non confirmee [email protected]

Figure 7 : signature electronique simple / certificat simplifie

~~\

\?'"

V

\ ~

~

La signature simple permet d'indiquer l'identiM du signataire du document.

La signature numerique sert uniquement a confirmer I'integrite du paquet.

Le certificat qualifie atteste que Ie paquet provient d'un demandeur dont l'identiM a eM confirmee.

La signature e lectronique simple permet d'indiquer I'identite du signataire du document.

La signature numerique sert uniquement a confirmer I' integrite du paquet.

Le certificat simplifie est utilise pour confirmer la signature numerique.


Combinaisons mecanisme de transmission/creation de paquet

La figure 8 illustre les differentes combinaisons mecanisme de transmission/creation de paquet autorisees. On doit utiliser, pour chaque mecanisme de transmission: a) en ligne/lnternet : il faut utiliser un paquet signe et chiffre;

b) en ligne/environnement securise (chiffrement de voie du type reseau privle) : un paquet signe et chiffre ou compacte et chiffre .. c) hors ligne/supports materiels: un paquet signe et chiffre, ou un paquet compacte et signe ou encore un paquet de documents constitutifs de la demande, compactes.

Paquet signe et chiffre Paquet compacte et signe Documents constitutifs de la demande com actes

En ligne/ Internet

En ligne envlronnement securise

Hors ligne Supports materiels

() I~~, Internet )

EnvITOnnement securise

(2) Non auto rise

Enviroimement securise

Figure 8 : protocoles de transmission et paquets autorises

(2) Non autorise

(2) Non autorise

Europiiisches Patentamt (EPA) European Patent Office (EPO) Office europeen des brevets (OEB) 181 D-80298 Munchen o (+49-89) 2399-0 TelexfTelex: 523 656 epmu d Fax: (+49-89) 2399-4465 Internet: http://www.european-patent-office.org

Zweigstelle Den Haag Branch at The Hague Departement de La Haye Postbus 5818 181 NL-2280 HV Rijswijk o (+31-70) 340-2040 TelexfTelex: 31 651 epo nl Fax: (+31-70) 340-3016

Dienststelle Berlin Berlin sub-office Agence de Berlin 181 D-10958 Berlin o (+49-30) 25901-0 Fax: (+49-30) .25901-840

Dienststelle Wien Vienna sub-office Agence de Vienne Postfach 90 181 A-1031 Wien o (+43-1) 52126-0 Fax: (+43-1) 52126-3591