Softwarepatenter

Software har kort været nævnt i indlægget om ting, der er udelukket fra patentering. Men softwarepatenter har man da hørt om, så helt udelukkede er de måske alligevel ikke. Lad os dykke lidt dybere ned i, hvad man kan og ikke kan få lov at tage patent på, når det kommer til software.

”Software i sig selv” er udelukket

I den europæiske patentlov (EPC) står der, at computerprogrammer (eller software) ikke betragtes som opfindelser.

Så kunne man jo tænke, at den diskussion ikke var længere. Sagen er dog den, at det der er udelukket, er at gøre krav på ”software i sig selv” (eller den engelske formulering ”claiming software as such”). Med det skal forstås, at software ikke kan patenteres alene.

For at kunne få patent på noget, der involverer software, skal det være i kombination med noget fysisk, og det skal give anledning til en teknisk effekt. Vigtigere endnu er det denne tekniske effekt, der skal give opfindelsen sin opfindelseshøjde.

Det er altså ikke nok at automatisere noget, som allerede gøres af mennesker, hvis ’opfindelsen’ er at gøre det på en computer. Dette ville være at søge patent på en kendt metode, implementeret i software. Det nye ville udelukkende være at digitalisere denne kendte metode. Minder det om noget? Det er dette, som kaldes ’software i sig selv’. Og det er jo fair nok, at man ikke kan få patent på at digitalisere gængse processer.

Men hvad så med alle dem som opfinder nye metoder og systemer som kun virker, eller virker kvalitativt bedre, fordi de er implementeret som software?

Software med yderligere teknisk effekt

For at software kan betragtes som en opfindelse, skal der opnås en fysisk og teknisk effekt.

Elektronik-ingeniørerne derude kunne snildt påpege, at det jo har en teknisk effekt at køre et program, fordi det sender elektriske impulser rundt i kredsløbene, og det er jo en fysisk effekt. Og det er sandt, det er en fysisk effekt. Men den betragtes som ”den normale interaktion imellem program og computer” og er derfor ikke nok, hvilket også er årsagen til, at det bliver kaldt en yderligere teknisk effekt (engelsk: further technical effect).

Så hvad kunne en yderligere teknisk effekt være?

Et eksempel givet af den europæiske patentmyndighed (EPO) er computerstyring af ABS-bremser på en bil.

Et menneske kan godt selv sørge for at pulse bremserne i bilen for at undgå, at de blokerer, men man kan få en anden effekt ud af, at det er computerstyret. Computerstyring gør det simpelthen muligt at pulse bremsen hurtigere end noget menneske kan, og det bidrager til at mindske bremselængden. Dertil kommer, at en computerstyring koblet til en sensor også har mulighed for bedre at vurdere, hvornår ABS-bremserne skal aktiveres.

Computerstyringen af bremserne har altså ikke udelukkende den effekt, at et menneske slipper for at skulle pulse bremsen selv. Det er heller ikke bare et spørgsmål om, at computerstyringen tillader, at det kan gå hurtigere – det er forventeligt, at en computer kan udføre noget hurtigere end et menneske. Den yderligere tekniske effekt kommer, når den hurtigere styring, sensormuligheder og den slags, gør resultatet bedre end, hvad der kunne opnås uden software.

Der kan også godt være programmer, der skaber en yderligere teknisk effekt inde i en computer, hvis de opnår, at computeren opererer på en anden måde, end hvad der er normalt. For eksempel hvis det er et program til at håndtere memory allocation eller noget tilsvarende i hvordan computeren håndterer data og processer.

Computerprogram eller computer-implementeret metode

Software anses i patentsammenhæng som en sekvens af computer-eksekverbare instruktioner, der kan køres på en computer. Så på en måde kan det anses som det, der i gamle dage ville ligge på den CD, man installerede programmet fra, og som nu om stunder ofte er det, man downloader og installerer.

En computerimplementeret metode, er derimod set som det at løse et problem ved at udføre nogle handlinger i et bestemt system. Metoden kan måske kun lade sig gøre, fordi de er computerimplementerede, eller måske gør det den bare mere effektiv, men det er metoden i sig selv, der er opfindsom, og derfor er softwareimplementeringen ikke en begrænsning.

Lidt groft sagt er det, du kan at tage patent på en metode, hvor software på en computer styrer bremserne i en bil, og beskytte den samlede metode til at sikre bilens opbremsning. Men du kan ikke tage patent alene på det software, som er skrevet til at styre opbremsningen, hvis ikke det bruges sammen med bilen. Dette binder igen op på, at der skal opnås en fysisk effekt, som her vil være forbedret bremsning.

Hvorfor udelukke softwarepatenter?

Som med en del af de andre ting, der er udelukket fra patentering, er der delvist tale om, at det allerede er beskyttet og delvist, at verden har udviklet sig i en anden retning end systemet havde forudset.

Hvis du skriver et stykke software, har du copyright på din tekst. Det er jo meget fint, men problemet med software og copyright er, at copyright beskytter selve teksten – ikke ideen eller algoritmen bagved. En anden programmør kan forholdsvist nemt skrive en tilsvarende kode med andre parameternavne og lidt anden rækkefølge i koden og så ikke bryde copyright, da det ikke er den samme tekst længere. Men da pointen med software ikke er teksten men funktionen, giver det jo ikke den beskyttelse, du gerne vil have.

Til gengæld har copyright den fordel at det er nemt at vise, hvis nogen har lavet præcis den samme kode, og at det automatisk giver beskyttelse i de 151 lande der er medlem af the Berne Convention for the Protection of Literary and Artistic Works, fra det øjeblik koden er skrevet.

Formentlig har dem, der skrev patentlovgivningen i sin tid tænkt, at software ikke var opfindsomt og derfor blev det oprindeligt udelukket. Sidenhen formåede nogen så at gøre noget opfindsomt med software, og derfor blev der lukket mere og mere op for det, og systemet har langsomt forsøgt at tilpasse sig.

En af mine kollegaer delte en god analogi med mig: Man kan betragte software som et materiale. Det er ikke opfindsomt at lave en kendt ting i et kendt materiale, hvis man ikke får en opfindsom effekt. For eksempel kunne der være en genstand, man normalt lavede i træ, og det ville ikke være opfindsomt at lave den samme ting i stål, hvis det man ville opnå, var at gøre den hårdere. En fagperson ville godt vide, at stål er hårdere end træ og kunne nemt lave den ændring uden opfindsomhed. Hvis det at lave genstanden i stål derimod tillod, at man kunne opnå noget andet med denne genstand – at den kunne laves mindre end man kan i træ, eller støbes og svejses så den bliver hul, og det har opfindsomme fordele – så bliver materialebruget i sig selv relevant for opfindsomheden.

Det samme gælder software. Hvis den eneste effekt er noget, der altid kommer direkte af software – det skal ikke styres af en person eller det kan gøres hurtigere – så er det ikke en opfindelse at gøre det med software. Der skal noget mere til.

Skal man patentere sin software?

Der har tidligere været en del usikkerhed om softwarepatenter, fordi lovgivningen har været under udvikling, og fordi den også stadig varier landene imellem. Generelt er EPO ret lempelige med computer-implementerede metoder. USA har haft en noget mere varierende praksis i forhold til software. Før 2014 blev softwarepatenter ret bredt accepteret i USA, men en retssag, hvor et softwarepatent tabte og blev erklæret for abstrakt, ledte til en afgørelse som skabte grundlaget for en markant strammere praksis. Det lader dog til, at der langsomt bliver løsnet op igen og nogen tolker det som om, at USA er ved at tilpasse sig EPO’s praksis med den yderligere tekniske effekt.

En vigtig pointe er også, at det kan være svært at håndhæve et softwarepatent. Hvis den software du bruger, primært ligger et sted på en server, og dine konkurrenters software ville gøre det samme, er det svært at komme til at sandsynliggøre, at deres virksomhed bygger på præcis det samme stykke software som din. Mange effekter, der ligner hinanden, kan opnås med forskellige algoritmer. Det er ikke så stort et problem netop for computerimplementerede metoder, men jo mindre den fysiske effekt er, desto sværere kan det være at eftervise krænkelse.

Vil det sige, at du slet ikke skal prøve at tage et softwarepatent? Njah, det kommer jo an på din opfindelse. Hvis du har fået en genial ny ide, som du tror, vil revolutionere det hele, er det altid en overvejelse værd. Hvis det faktisk er en ”computerimplementeret metode” er det måske slet ikke så dumt med et patent. Det kan også være, at du har en nystartet lille virksomhed, og det er vigtigt for dig at kunne vise et patent til en investor. Der kan godt være gode grunde, men når det kommer til software, er andre strategier – inklusive hemmeligholdelse – også relevante overvejelser. Det vigtigste er egentlig, at du forholder dig til, hvordan du vil beskytte din forretning.

Det kommer altid an på din konkrete sag, så jeg vil helt sikkert ikke sige, at man skal glemme alt om, at softwarepatenter eksisterer. Det bedste råd jeg kan give, er at spørge en patentrådgiver om det giver mening. Masser af patentkontorer tilbyder gratis indledende møder, hvor du netop kan spørge om et software patent giver mening for din opfindelse, eller om det er bedre bare at holde koden hemmelig.

Software fungerer i forhold til patenter egentlig ligesom alt andet: er det nyt og har opfindelseshøjde, så er det en patenterbar opfindelse.

Så hvad synes I, bør software kunne patenteres? Og hvad med de computerimplementerede metoder?