Den Fælles Europæiske Patentdomstol, Unified Patent Court (UPC), behandler sager om europæiske patenter med virkning i de deltagende EU-lande. Danmark deltager, og der er en lokalafdeling i København, hvor sagerne kan føres på dansk eller engelsk. For danske virksomheder og advokater betyder det, at en patentsag om software kan føres ved en domstol med virkning i flere lande på én gang, efter procesregler, der adskiller sig fra retsplejeloven.
Denne artikel handler om den tekniske side: hvad den IT-sagkyndige kan bidrage med i en softwarepatentsag ved UPC, og hvad advokaten bør tænke på, når den tekniske dokumentation forberedes. Patentretlige vurderinger og processuelle valg er advokatens og den patentretlige rådgivers felt. Domstolens egne oplysninger findes på unifiedpatentcourt.org.
Nielco IT har været IT-sagkyndig ved UPC. Artiklen bygger på den generelle erfaring og omtaler ikke konkrete sager.
Softwarepatenter kort
Efter Den Europæiske Patentkonvention er edb-programmer “som sådan” ikke opfindelser, der kan patenteres. Se EPC artikel 52. Det udelukker ikke patenter på computerimplementerede opfindelser, når opfindelsen har teknisk karakter. I praksis findes der derfor mange europæiske patenter, hvis krav beskriver en metode eller et system, der helt eller delvis udføres af software.
For den tekniske dokumentation betyder det, at patentkravene ofte er formuleret abstrakt, fx som trin i en metode eller som moduler i et system. Opgaven er at holde de abstrakte formuleringer op mod en konkret implementering, ofte i kildekode, som ingen af kravene nævner direkte.
Hvor den tekniske sagkyndige typisk indgår
Krænkelse. Udfører modpartens produkt hvert enkelt trin i patentkravet? Det kræver, at implementeringen dokumenteres trin for trin. Et hjælpemiddel er en kravtabel, ofte kaldet claim chart, hvor hvert kravelement står ved siden af det sted i produktet eller koden, der påstås at opfylde det.
Gyldighed. Var opfindelsen kendt før patentets prioritetsdato? I software kan tidligere kendt teknik findes i open source-projekter, gamle versioner af produkter, dokumentation, foredrag og webarkiver. Dateringen af materialet er ofte det svære. → Wayback Machine i retten: bevisværdi og indsigelser
Egen udvikling. Påstår modparten, at klientens produkt bygger på patentet, eller vil klienten vise en tidligere egen brug, skal klientens udviklingsforløb dokumenteres. → Patentsager: dokumentation af udviklingsforløbet
Partens sagkyndige og domstolens sagkyndige
UPC’s procesregler skelner mellem sagkyndige, som parterne selv fremlægger, og sagkyndige, som domstolen udpeger. Domstolens adgang til at udpege sagkyndige følger af aftalen om en fælles patentdomstol, artikel 57, og domstolens dommerpaneler kan omfatte teknisk kyndige dommere.
For advokaten har det praktiske konsekvenser:
- Skriftlighed. Den tekniske dokumentation fremlægges i vid udstrækning skriftligt og tidligt. Det, der ikke er med i de skriftlige indlæg, kan være svært at få ind senere.
- Uafhængighed. Procesreglerne forudsætter, at en sagkyndig, også en partsudpeget, er uafhængig og objektiv over for domstolen. Den sagkyndiges forhold til parten skal kunne oplyses. En erklæring, der læser som et indlæg, svækker sig selv. → Uvildighed og inhabilitet hos IT-sagkyndige
- Teknisk kyndige læsere. Når panelet har teknisk indsigt, bliver upræcise forklaringer opdaget. Metoden skal kunne efterprøves.
- Sprog. Ved lokalafdelingen i København kan sagen føres på dansk eller engelsk. Kildekode, dokumentation og tekniske termer er ofte på engelsk, og erklæringen skal skrives, så den kan bruges på processproget.
Kravtabellen i en softwaresag
Kravtabellen er ofte det centrale tekniske dokument. Den skal være præcis, fordi hvert kravelement skal kunne genfindes i implementeringen. For software betyder det:
- Identifikation af version. Hvilken version af produktet eller koden er undersøgt, og hvordan er den sikret? Software ændrer sig hurtigt, og et produkt kan have opfyldt et krav i én version og ikke i den næste.
- Kilde til implementeringen. Er beskrivelsen baseret på kildekode, på observation af det kørende produkt, på netværkstrafik eller på dokumentation? Hver kilde har sin styrke og sin svaghed.
- Henvisninger. Hvert element bør henvise til konkrete filer, funktioner, skærmbilleder eller logudskrifter, som modparten kan efterprøve.
- Forbehold. Hvis et kravelement kun kan sandsynliggøres og ikke vises direkte, skal det fremgå.
Den tekniske metode til at holde krav op mod kode er et selvstændigt fagområde. Den IT-sagkyndige beskriver, hvad implementeringen gør. Fortolkningen af patentkravene er derimod et patentretligt spørgsmål, og den skal advokaten og den patentretlige rådgiver fastlægge, før den tekniske analyse kan bruges.
Adgang til modpartens kode
Modpartens kildekode er sjældent tilgængelig. Ofte må analysen begynde med det, der kan observeres udefra: det kørende produkt, apps, offentlige grænseflader, dokumentation og netværkstrafik. Det kan være nok til en påstand, men ikke altid til et bevis.
UPC kan efter aftalen om en fælles patentdomstol, artikel 60, træffe afgørelse om sikring af beviser, herunder i visse tilfælde uden at modparten høres først. Kildekode og interne systemer er typisk forretningshemmeligheder, og domstolen kan fastsætte ordninger for fortrolighed. Teknisk er det vigtigt, at en anmodning præcist beskriver, hvad der skal sikres: hvilke kodedepoter, hvilke versioner, hvilke systemer og hvilken periode. Erfaringerne fra dansk fogedretlig bevissikring er relevante for den tekniske planlægning. → Fogedretlig bevissikring: IT-sagkyndiges rolle
Datering af tidligere kendt teknik
I en gyldighedssag kan et tidligere open source-projekt eller en ældre produktversion være afgørende. Det tekniske spørgsmål er, om materialet fandtes på det påståede tidspunkt og var offentligt tilgængeligt.
- Kodedepoter: Commit-tidspunkter kan sættes manuelt og er ikke alene tilstrækkelige. Udgivelser, pakker i offentlige registre, mailinglister og arkiverede kopier kan understøtte dateringen. → Kildekode og Git som bevis
- Webarkiver: Arkiverede sider kan dokumentere offentliggørelse, men arkivets dækning og tidsangivelser skal vurderes.
- Produkter: Gamle installationsfiler, manualer og versionshistorik kan vise, hvad et produkt kunne på et givet tidspunkt.
Om materialet udgør tidligere kendt teknik i patentretlig forstand, er en juridisk vurdering.
Hvad advokaten bør forberede
- Sikr klientens egen kode og udviklingshistorik med hashværdier tidligt. → Hashalgoritmer: MD5, SHA-1 og SHA-256
- Sikr modpartens offentligt tilgængelige produkt i de relevante versioner, med dokumentation af tid og fremgangsmåde.
- Afklar tidligt, hvilken version af modpartens produkt sagen handler om.
- Få den patentretlige fortolkning af kravene på plads, før den tekniske analyse færdiggøres.
- Planlæg sprog, så erklæringer og bilag kan bruges på processproget.
Typiske fejl
- Kravtabellen henviser til produktet generelt i stedet for til konkrete steder i implementeringen.
- Den undersøgte version kan ikke identificeres eller genskabes.
- Commit-datoer bruges som eneste datering af tidligere kendt teknik.
- Den sagkyndiges erklæring tager stilling til patentretlige spørgsmål.
- Forholdet mellem den sagkyndige og parten er ikke oplyst.
Tjekliste
- ☐ Processprog og afdeling er afklaret med den patentretlige rådgiver
- ☐ Kravfortolkningen er fastlagt, før den tekniske analyse afsluttes
- ☐ Undersøgte versioner er sikret og identificeret
- ☐ Kravtabellen henviser til konkrete og efterprøvelige steder
- ☐ Tidligere kendt teknik er dateret ud fra flere uafhængige kilder
- ☐ Den sagkyndiges uafhængighed og forhold til parten er beskrevet
En uvildig IT-sagkyndig kan vurdere de tekniske spørgsmål og skrive erklæringen, så den kan efterprøves af domstolen og modparten. → IT-sagkyndig og skønsmand i civile sager
→ Send en sag · Tlf. 70 13 63 23 · IT-sagkyndig og skønsmand hos Nielco IT
