Forside · Gennemgået oktober 2026 · Af John Nielsen
Et claim chart er en tabel, der opdeler et patentkrav i dets enkelte træk og for hvert træk viser, om og hvor det findes i en konkret implementering, med henvisning til bevismaterialet. Det er et arbejdsredskab, ikke en fast formel, men det er den mest udbredte måde at gøre en påstand om krænkelse, eller en indsigelse imod den, konkret og efterprøvelig. I sager om software er den tekniske udfordring at finde og dokumentere hvert træk i kode, adfærd og dokumentation, uden at blande fortolkningen af kravet sammen med de tekniske fund.
Artiklen beskriver den tekniske side. Dokumentation af et udviklingsforløb i patentsager er beskrevet fra advokatens side på digital-bevissikring.dk, og den sagkyndiges rolle ved Den Fælles Europæiske Patentdomstol (UPC) er beskrevet i ekspert og sagkyndigt vidne i IT-sager.
Software og patenter i korte træk
Den Europæiske Patentkonvention udelukker programmer for computere fra patentering, men kun i det omfang, ansøgningen angår dem “som sådan”. I praksis meddeles der patenter på computerimplementerede opfindelser, når de har en teknisk karakter. Kravene beskriver da typisk en fremgangsmåde, et system eller et medium med instruktioner, formuleret som en række trin eller komponenter.
Det er kravene, der fastlægger beskyttelsens omfang. Beskrivelsen og tegningerne bruges til at fortolke dem. For den tekniske sagkyndige betyder det, at udgangspunktet altid er kravets ordlyd, ikke patentets overskrift eller et produkts markedsføring.
Opdeling af kravet
Første skridt er at dele kravet op i træk, typisk ét pr. trin eller komponent. Et forenklet krav kunne lyde: en fremgangsmåde, hvor en klient sender en forespørgsel med et tidsstempel, serveren sammenligner tidsstemplet med en gemt værdi, og serveren afviser forespørgslen, hvis forskellen overstiger en tærskel. Det giver tre træk, plus indledningen.
Opdelingen er ikke rent teknisk. Hvor et træk slutter, og hvad ordene betyder, er et spørgsmål om kravfortolkning, som parterne og i sidste ende domstolen tager stilling til. Den sagkyndige bør derfor arbejde ud fra en fortolkning, som opdragsgiveren har fastlagt eller som er aftalt, og angive den tydeligt. Hvor ordlyden kan forstås på flere tekniske måder, kan diagrammet vise fundene under hver af dem.
Opbygning af diagrammet
Et claim chart har typisk tre kolonner:
- 1a: klienten sender forespørgsel med tidsstempel · Fund i implementeringen: Funktionen, der danner forespørgslen, tilføjer feltet med aktuel tid · Bevis: Fil og linjenumre i kildekoden, optaget netværkstrafik
- 1b: serveren sammenligner med gemt værdi · Fund i implementeringen: … · Bevis: …
For hvert træk skal fundet være konkret og henvisningen præcis: filnavn og linjer i en bestemt version, et tidsstempel i en optagelse, en side i dokumentationen. Generelle udsagn som “produktet gør dette” er ikke nok.
Hvor et træk ikke findes, skal diagrammet sige det lige så tydeligt. Et diagram, der kun viser de træk, der passer, er ikke uvildigt og falder ofte ved første modspørgsmål.
Kilder til bevis
Hvilke kilder der er til rådighed, afhænger af, om man har adgang til kildekoden.
Med kildekode, fx efter edition, i forbindelse med syn og skøn eller fordi det er egen kode:
- funktioner, klasser og konfiguration, der realiserer hvert træk
- Git-historik, der viser, hvornår funktionaliteten blev indført; se kildekode og Git som bevis
- test og byggeskripter, der viser, hvordan koden er tænkt brugt
Uden kildekode, ud fra det, der er offentligt eller lovligt tilgængeligt:
- observeret adfærd ved kontrollerede forsøg
- netværkstrafik mellem klient og server, optaget i et testmiljø
- offentlig dokumentation, API-beskrivelser og udviklervejledninger
- konfigurationsfiler og kode, der leveres til klienten, fx JavaScript i en webapplikation
Analyse af andres software kan være begrænset af licensvilkår og lovgivning. Den skal holde sig inden for de rammer, opdragsgiveren har fået afklaret juridisk.
Versioner og tidspunkt
En implementering ændrer sig. Diagrammet skal derfor angive præcis hvilken version der er undersøgt, og hvornår den var i brug. Det er relevant for perioden, kravet vedrører, og for, om ændringer undervejs har fjernet eller tilføjet træk.
For hver version bør fremgå versionsnummer, commit-id eller hashværdi for den undersøgte fil, hvor og hvornår den blev hentet, og hvilket miljø forsøg blev udført i. Sikringen af en applikation, der hentes fra en butik eller et register, kræver samme omhu som andre beviser; se hashmanifest for filsamlinger.
Forsøg og målinger
Når et træk skal vises ud fra adfærd, skal forsøget være beskrevet, så det kan gentages: testmiljø, version, input, værktøj til optagelse af trafik, tidspunkt og resultat. Kør forsøget flere gange, og vis også et forsøg, hvor trækket forventes ikke at optræde, fx med en tærskel overskredet eller en funktion slået fra. Et kontrolforsøg gør det sværere at bortforklare fundet som tilfældigt. Gem optagelser og logs med hashværdier sammen med sagen.
Typiske faldgruber
- Fortolkning gemt i fundene. Står fortolkningen af et ord ikke åbent, men er indbygget i beskrivelsen af fundet, kan hele diagrammet anfægtes.
- Funktionel lighed som bevis. At to løsninger opnår samme resultat, viser ikke, at de gør det på den måde, kravet beskriver.
- Død kode. Kode, der findes, men aldrig kaldes, viser ikke, at trækket bruges. Kaldestien skal vises.
- Konfiguration. Et træk kan være slået fra som standard. Det skal fremgå, om det var aktivt i den undersøgte installation.
- Tredjepartskomponenter. Realiseres et træk af et bibliotek, kan det være relevant at vise hvilket og i hvilken version.
- Sprog. Sager ved UPC føres ofte på engelsk, og diagrammet skal bruge kravets termer præcist; se engelsksprogede tekniske rapporter.
Uafhængighed
UPC’s procesregler stiller krav om, at også en parts ekspert er uafhængig og objektiv over for domstolen. Det stemmer med god praksis i det hele taget: diagrammet skal kunne gennemgås af modpartens sagkyndige og føre til de samme tekniske fund, selv om parterne er uenige om fortolkningen. John Nielsen, Nielco IT, har selv været IT-sagkyndig ved UPC; af hensyn til tavshedspligten oplyses intet om sagerne.
Det modsatte diagram
Samme metode bruges, når gyldigheden af et patent anfægtes. Her holdes kravets træk op mod tidligere kendt teknik i stedet for en implementering. Kravene til dokumentation af den tidligere kendte teknik er anderledes og beskrevet i prior art i software.
Hvad diagrammet kan og ikke kan bevise
Et claim chart kan vise, træk for træk, hvad en bestemt version af en implementering gør, og hvor det kan efterprøves. Det kan ikke afgøre, hvordan kravet skal fortolkes, eller om der foreligger krænkelse. Det kan heller ikke sige noget om patentets gyldighed. Diagrammets styrke ligger i, at de tekniske fund holdes adskilt fra fortolkningen, så retten kan tage stilling til fortolkningen med fundene som fast grundlag.
Kilder og versioner
- EPO: Den Europæiske Patentkonvention, artikel 52
- EPO: Guidelines for Examination, G-II 3.6, programs for computers
- Unified Patent Court: legal documents, herunder Rules of Procedure
Senest gennemgået: oktober 2026.
Næste skridt
- GitHub, GitLab og Azure DevOps: auditlogs for kloning, forks og tokens
- Massesletning efter en tvist er opstået: tekniske tegn
Læs også: Arkitektur og skalerbarhed, når systemet ikke kan bære belastningen · Prior art i software: dokumentation af tidligere kendt teknik
→ Uvildig IT-sagkyndig med forensic-baggrund · For IT-afdelingen · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT
