Forside · Gennemgået oktober 2026 · Af John Nielsen
Prior art, på dansk den kendte teknik, er alt, der var gjort tilgængeligt for offentligheden før patentansøgningens indleveringsdato. I sager om softwarepatenter findes den kendte teknik ofte ikke i patentlitteraturen, men i open source-projekter, udgivelser, manualer, mailinglister og produkter, der var i brug. Den tekniske opgave er at vise to ting med pålidelig dokumentation: hvad materialet beskrev eller indeholdt, og at det var offentligt tilgængeligt på et bestemt tidspunkt. Det sidste er ofte det sværeste.
Hvordan et patentkrav holdes op mod en implementering eller mod tidligere kendt teknik i en tabel, er beskrevet i softwarepatenter: claim chart. Spørgsmålet om, hvem der skabte noget først i en ophavsretssag, er beslægtet, men har andre krav; det er beskrevet på digital-bevissikring.dk.
Hvad der tæller som kendt teknik
Efter Den Europæiske Patentkonvention omfatter den kendte teknik alt, der er gjort tilgængeligt for offentligheden ved skriftlig eller mundtlig beskrivelse, ved brug eller på anden måde før indleveringsdatoen. For software betyder det blandt andet:
- offentliggjort kildekode i et åbent repository eller en udgivet pakke
- udgivne programmer, apps og firmware, som kunne hentes eller købes
- dokumentation, manualer, API-beskrivelser og udviklervejledninger
- artikler, konferenceindlæg, blogindlæg og videoer
- diskussioner i offentlige mailinglister, fora og fejlsporingssystemer
- produkter, der var i offentlig brug, hvis funktionen kunne erkendes
Det afgørende er offentlig tilgængelighed. Kode i et privat repository eller i en virksomheds interne systemer er som udgangspunkt ikke offentlig, selv om den er ældre end patentet. Om materiale delt under fortrolighed eller i en lukket kreds er offentligt, er en juridisk vurdering, men de tekniske fakta om adgangen kan dokumenteres.
Datoen er det svære
EPO’s retningslinjer om internetoffentliggørelser siger, at information på nettet anses for offentligt tilgængelig fra den dato, den blev lagt ud. Bevisstandarden er en afvejning af sandsynligheder, men en dato, der blot er sandsynlig, er ikke nok. Udtrykkelige datoer accepteres som udgangspunkt, og indirekte beviser kan være nødvendige for at fastslå eller bekræfte en dato.
For software findes mange datoer, og de er ikke lige pålidelige:
- Commit-dato i Git · Hvad datoen viser: Hvad forfatteren eller systemet har registreret · Svaghed: Kan sættes frit lokalt
- Platformens tidsstempler for push, udgivelse og tag · Hvad datoen viser: Hvornår platformen modtog materialet · Svaghed: Siger ikke altid, om repositoriet var offentligt
- Pakkeregistrets udgivelsesdato · Hvad datoen viser: Hvornår en version blev offentliggjort · Svaghed: Pakker kan trækkes tilbage eller genudgives
- Webarkivets kopi · Hvad datoen viser: At siden fandtes i den form på arkiveringstidspunktet · Svaghed: Viser ikke, hvornår indholdet første gang kom online
- Software Heritage · Hvad datoen viser: At koden fandtes, da arkivet besøgte kilden · Svaghed: Besøgsdatoen er senest mulige, ikke første offentliggørelse
- Trykte og elektroniske udgivelser med ISBN, DOI eller arkiv · Hvad datoen viser: Udgivelsesdato fra tredjepart · Svaghed: Indholdet kan afvige fra senere versioner
Commit-datoer i Git kan sættes til hvad som helst; se kildekode og Git som bevis. De er derfor sjældent tilstrækkelige alene. Stærkest er datoer registreret af en uafhængig tredjepart, og flere uafhængige datoer, der peger samme vej.
Indholdet: hvad blev offentliggjort?
En dato hjælper kun, hvis det er klart, hvilket indhold den hører til. For kode betyder det en bestemt version, ikke projektet i dag. Software Heritage giver hver fil, mappe og revision en indholdsbaseret identifikator, SWHID, standardiseret som ISO/IEC 18670. En SWHID ændrer sig, hvis indholdet ændres, og gør det muligt at henvise entydigt til præcis det, der blev arkiveret.
For hjemmesider og dokumentation skal kopien vise indholdet, som det var. En webarkivkopi kan mangle billeder, scripts eller indhold, der hentes dynamisk, og den kan være sammensat af elementer arkiveret på forskellige tidspunkter. Det skal undersøges, ikke antages.
Søgning
Kendt teknik i software findes ofte bedst ved at søge efter de tekniske begreber, som en udvikler ville have brugt dengang, ikke patentets egne termer. Nyttige kilder er projektarkiver, pakkeregistre, fejlsporingssystemer, mailinglistearkiver, standardiseringsorganers dokumenter, konferenceartikler og ældre produktdokumentation.
Søgningen skal dokumenteres: søgetermer, kilder, datoer og resultater, også de søgninger, der ikke gav fund. Det gør det muligt at vise, at søgningen var systematisk, og at fundene ikke er håndplukket uden sammenhæng.
Sikring af fundene
Hvert fund, der skal bruges, bør sikres, så indholdet og datoen kan efterprøves:
- Kode: klon repositoriet med fuld historik, notér commit-id for den relevante version, og hent SWHID fra Software Heritage, hvis versionen er arkiveret.
- Pakker: hent den udgivne pakke, beregn hashværdi, og gem registrets metadata med udgivelsesdato.
- Websider: gem i et format, der bevarer indhold og hentetidspunkt, fx WARC med hashværdi; se webarkivering i forensisk kvalitet. Gem også arkivkopien, hvis datoen bygger på et webarkiv.
- Dokumenter: gem den originale fil med metadata og hashværdi, og notér, hvor den er hentet.
- Programmer: gem installationsfilen med hashværdi, og dokumentér, hvordan den kan afvikles i et testmiljø for at vise funktionen.
Registrér alt i et samlet hashmanifest, så materialet senere kan vises at være uændret; se hashmanifest for filsamlinger og produktioner.
At vise funktionen
En ældre version af et program kan være kendt teknik for en funktion, men det skal vises, at funktionen faktisk fandtes i den version. Det kan ske ved at gennemgå kildekoden for versionen eller ved at afvikle programmet i et testmiljø, der svarer til tidens forhold, og dokumentere adfærden. Gamle programmer kan kræve gamle operativsystemer eller biblioteker, og forskellen mellem testmiljøet og den oprindelige brug skal beskrives.
Offentlig brug og ældre produkter
Kendt teknik kan også være et produkt, der var i brug, fx et program solgt til mange kunder. Her skal det dokumenteres, at produktet var tilgængeligt, fx med fakturaer, udgivelsesnoter, presseomtale eller arkiverede downloadsider, og at funktionen kunne erkendes af en bruger eller fagperson. Ældre installationsmedier kan have værdi, hvis deres herkomst kan dokumenteres. Notér, hvor mediet er fundet, hvem der har opbevaret det, og om indholdet kan dateres uafhængigt af filernes egne tidsstempler.
Typiske faldgruber
- Den nyeste version i stedet for den relevante. Projektets nuværende kode kan have fået funktionen efter patentets dato.
- Datoer fra én kilde. Én commit-dato eller én arkivkopi er sårbar. Find flere.
- Tidszoner. Indleveringsdato og offentliggørelse kan ligge tæt på hinanden. Angiv tider i UTC; se sommertid og tidszoner i rapporten.
- Privat blev offentligt senere. Et repository, der i dag er offentligt, kan have været privat på det relevante tidspunkt.
- Ufuldstændige arkivkopier, der fortolkes, som om de viste hele siden.
Hvad dokumentationen kan og ikke kan bevise
God dokumentation kan vise, hvad et bestemt materiale indeholdt, og med hvilken sikkerhed det var offentligt tilgængeligt på et bestemt tidspunkt. Den kan ikke afgøre, om materialet foregriber patentkravet eller gør opfindelsen nærliggende. Det er en vurdering, der foretages af patentkyndige og i sidste ende af domstolen eller patentmyndigheden, med de tekniske fund som grundlag.
Kilder og versioner
- EPO: Den Europæiske Patentkonvention, artikel 54
- EPO: Guidelines for Examination, G-IV 7.5, internet disclosures
- Software Heritage
- ISO/IEC 18670:2025, SWHID
Senest gennemgået: oktober 2026.
Næste skridt
Læs også: Softwarepatenter: claim chart, krav holdt op mod implementering · Escrow: verifikation af, at den deponerede kildekode kan bygges
→ Uvildig IT-sagkyndig med forensic-baggrund · For IT-afdelingen · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT
