Patentsager: dokumentation af udviklingsforløbet

Patentsager drejer sig ofte om tidspunkter. Hvornår blev opfindelsen gjort? Var den kendt, før patentet blev søgt? Hvem bidrog med hvad? Svaret ligger sjældent i én fil. Det ligger spredt i udviklingssystemer, mails, tegninger og testdata, og det skal kunne dokumenteres, at tidspunkterne er ægte.

Artiklen gennemgår, hvad advokaten bør spørge om, hvor dokumentationen typisk findes, og hvordan den sikres, så den kan bære i en tvist. Den patentretlige vurdering er advokatens. IT-siden handler om, hvorvidt dokumentationen holder.

Typiske spørgsmål i sagen

• Nyhed: Var opfindelsen offentliggjort før ansøgningsdatoen, for eksempel på en messe, i en artikel eller på en hjemmeside?
• Opfinderskab: Hvem bidrog til opfindelsen, og hvornår?
• Ansattes opfindelser: Blev opfindelsen gjort som en del af ansættelsen?
• Krænkelse: Hvornår begyndte modparten at bruge løsningen, og hvordan ser den ud?

Hvert af spørgsmålene peger på forskellige kilder. Nyhed handler om det, der var offentligt. Opfinderskab og ansattes opfindelser handler om det interne forløb. Krænkelse handler ofte om modpartens produkt og markedsføring. Det er derfor nyttigt at afklare, hvilket spørgsmål der er det centrale, før sikringen planlægges.

Hvad advokaten bør spørge klienten om

• Hvilke systemer blev brugt i udviklingen, og er de stadig i drift?
• Hvem havde adgang, og har nogen af dem forladt virksomheden?
• Er der brugt eksterne samarbejdspartnere, konsulenter eller universiteter, og hvor ligger deres materiale?
• Hvornår blev løsningen første gang vist uden for virksomheden: til kunder, på messer, i tilbud eller på hjemmesiden?
• Er der flyttet systemer eller ryddet op i perioden, for eksempel ved skift fra én versionsstyring til en anden?
• Findes der backup fra den relevante periode, og hvor længe gemmes den?

Svarene afgør, hvad der skal sikres først. → Tjekliste til det første møde med klienten

Hvor dokumentationen ligger

• Git og andre versionsstyringssystemer · Hvem der skrev hvad, og hvornår
• CAD-filer og tegninger · Versioner, forfatter og ændringsdatoer i metadata
• Elektroniske laboratoriejournaler · Forsøg, resultater og underskrifter med tidsstempel
• Mails og projektværktøjer · Idéer, beslutninger og hvem der var involveret
• Hjemmesider og præsentationer · Hvornår noget blev gjort offentligt
• Backup · Hvordan materialet så ud på et bestemt tidspunkt

Hertil kommer sagsstyringsværktøjer, interne wikier og chatkanaler, hvor beslutninger ofte er truffet uformelt. De glemmes let, fordi de ikke opfattes som dokumentation. → Hvad er metadata?

Kan tidspunkterne stoles på?

Det er sagens svage punkt. Tidsstempler i filer og i Git kan ændres. Derfor skal dokumentationen bygge på flere uafhængige kilder, der peger på samme tidspunkt:

• en commit i Git, der svarer til en mail med samme indhold,
• metadata i en fil, der stemmer med en backup fra samme periode,
• en server, der har modtaget filen på et kendt tidspunkt.

→ Kildekode og Git som bevis · Tidsstempler og tidszoner

Hvad data kan og ikke kan vise

• En commit viser, hvilken bruger der står som forfatter, og hvilket tidspunkt der er registreret. Begge dele kan sættes manuelt. Det, der giver vægt, er sammenhængen med serverens egne logs og andre kilder.
• Metadata i et dokument viser, hvad programmet har registreret. Kopiering, konvertering og upload til skyen kan ændre datoerne, uden at nogen har gjort noget forkert.
• En backup viser, hvordan materialet så ud, da backuppen blev taget. Den er ofte den stærkeste kilde, fordi den er lavet af et system, som udviklerne ikke styrer.
• Fravær af en fil beviser ikke, at den ikke har eksisteret. Den kan være slettet, flyttet eller aldrig gemt centralt.

En samlet tidslinje, hvor hver begivenhed er knyttet til mindst to uafhængige kilder, er det, der gør dokumentationen robust. → Tidslinjeanalyse

Offentliggørelse på nettet

Er spørgsmålet, om noget var offentligt tilgængeligt før en bestemt dato, kan webarkiver og hjemmesidens egen historik være afgørende. En hjemmeside, der er ændret siden, kan nogle gange genskabes fra backup eller fra udgivelsessystemets versioner. → Bevissikring af en WordPress-hjemmeside

Det samme gælder pdf-brochurer, produktblade og præsentationer, der har ligget til download. Serverens logs kan i nogle tilfælde vise, hvornår en fil første gang blev hentet udefra. Det er stærkere end filens egne datoer, fordi det viser, at den faktisk var tilgængelig. → Gem en webside som dokumentation

Sikring i praksis

• Sikr udviklingssystemerne som helhed, ikke kun udvalgte filer. Historikken er beviset.
• Dokumentér adgangsrettigheder. Hvem kunne ændre i systemet i perioden?
• Sikr tidligt. Udviklere rydder op i gamle grene og projekter.
• Vær opmærksom på fortrolighed. Materialet indeholder ofte forretningshemmeligheder, som modparten ikke skal se mere af end nødvendigt. → Editionsbegæring set fra IT-siden

En praktisk rækkefølge:

1. Send en bevarelsesbesked internt, så ingen rydder op i repositories, projektmapper eller backup. → Bevarelsespligt og litigation hold
2. Sikr versionsstyring, projektværktøjer og relevante postkasser med hashværdier og dokumentation.
3. Sikr backup fra den relevante periode, før den overskrives.
4. Sikr offentligt materiale: hjemmesider, brochurer og præsentationer.
5. Lav først derefter analysen og tidslinjen.

Typiske fejl

• Udviklerne eksporterer selv et udvalg af filer. Udvalget kan være rigtigt, men det kan ikke efterprøves, og historikken mangler.
• Repository’et ryddes op eller flyttes under sagen. Ved flytning mellem platforme kan dele af historikken gå tabt.
• Man stoler på én kilde. En enkelt dato i en fil er let at anfægte.
• Tidszoner overses. I internationale samarbejder kan en forskel på få timer flytte en begivenhed til en anden dato.

Når modparten fremlægger sit udviklingsforløb

Fremlægger modparten sin egen dokumentation for, hvornår løsningen blev udviklet, bør den gennemgås med de samme krav som klientens. Spørgsmål, en IT-sagkyndig typisk vil stille:

• Er materialet fremlagt som udskrifter eller som originaldata? En udskrift af en commit-historik kan ikke efterprøves. En kopi af repository’et med serverens logs kan.
• Hvor mange uafhængige kilder bygger tidspunkterne på? Peger de alle tilbage til det samme system, som modparten selv har styret, er de svagere end tidspunkter, der også fremgår af mails til eksterne eller af tredjemands systemer.
• Er der spring eller uregelmæssigheder? For eksempel commits, der er registreret i en anden rækkefølge end de tidspunkter, de angiver, eller filer, hvis metadata er nyere end den dato, de påstås at stamme fra.
• Er historikken flyttet eller omskrevet? Ved migrering mellem platforme eller ved bevidst omskrivning af historikken kan spor være gået tabt.

Det er rimeligt at bede om adgang til originaldata, så de kan undersøges på samme måde som klientens. → Forskningsdata og laboratoriejournaler → Skabelsestidspunkt i ophavsretssager

Syn og skøn

I patentsager er der ofte både en teknisk sagkyndig i selve fagområdet og en IT-sagkyndig. Den IT-sagkyndige udtaler sig ikke om opfindelsen, men om, hvorvidt dokumentationen er ægte og tidspunkterne pålidelige. → Syn og skøn i IT-sager

Spørgsmålene til den IT-sagkyndige bør derfor holdes til det, data kan besvare. Et eksempel på et brugbart spørgsmål: “Er der tegn på, at tidsstemplerne i repository’et er ændret efter den dato, de angiver?” Et spørgsmål om, hvem der har opfundet løsningen, hører hjemme hos fagskønsmanden og retten.

Er sagen også et spørgsmål om ophavsret til kildekoden, gælder mange af de samme overvejelser. → Ophavsret til software og kildekode

→ Send en sag · Tlf. 70 13 63 23 · IT-sagkyndig bistand til advokater hos Nielco IT