Få de daglige nyheder fra Version2 og Ingeniøren. Læs mere om nyhedsbrevene her.

close
Ved at tilmelde dig accepterer du vores Brugerbetingelser, og du accepterer, at Teknologiens Mediehus og IDA-gruppen lejlighedsvis kan kontakte dig om arrangementer, analyser, nyheder, job og tilbud m.m. via telefon og e-mail. I nyhedsbreve, e-mails fra Teknologiens Mediehus kan der forefindes markedsføring fra samarbejdspartnere.
Patentkontoret bloghoved

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.

Illustration: axonite fra Pixabay

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.

Illustration: James Osborne fra Pixabay

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?

Louise Floor Frellsen er fysik-ingeniør, ph.d. og postdoc fra DTU og nu patentrådgiver hos Chas. Hude. Bloggen Patentkontoret opdaterer hun hver anden mandag skiftevis med betragtninger fra IP-verdenen og med eksempler på alverdens finurlige patenter.
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først

"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. "

Det er en misforståelse. Copyright beskytter også mod systematiske eller trivielle omskrivninger, ellers ville en oversættelse af en roman til et andet sprog ikke være omfattet af copyright. Så for at omgå copyright på et program, så skal du kunne argumentere for, at du har implementeret dit program fra bunden uden at have skelet til programteksten i det program, du vil genskabe. Du må gerne studere, hvordan programmet opfører sig, men ikke, hvordan det er implementeret. Altså en "clean room" implementering. Det kan dog være svært både at bevise og modbevise.

  • 5
  • 0

Du har selvfølgelig ret i at det er groft oversimplificeret – og det er selvfølgelig ikke så nemt som bare at klippe en linje kode fra et sted til en anden eller kalde ”x” for ”y” i stedet. Det skal stadig være en ”anden tekst” og tak for at du sørger for, at jeg ikke bare får lov at udbrede misforståelsen videre ved at bruge det samme simple eksempel.

Essensen er blot – som du også selv siger – at det kan være utroligt svært at be- eller afkræfte i hvor høj grad det er ”den samme kode” hvis man sætter sig og skriver den igen med ”sine egne ord”.

Du ved nok også langt mere om copyright for programkode end jeg gør, for copyright er jo ikke noget, jeg selv gør mig i, og jeg har kun prøvet et par forskellige programmeringssprog. Til gengæld var der ret stor forskel på de programmeringssprog jeg har prøvet, og jeg kom til at tænke på, ved du hvordan copyright forholder sig til det? Hvis jeg læser nogens kode i et program, skriver algoritmen/tankerne bag ned og så selv skriver en kode baseret på det samme i et andet sprog. Er det sådan en situation ”clean room” implementering ville dække? (også uden det behøvede at være et andet programmeringssprog, det var bare fordi det i hvert fald kan gøre selve teksten betydeligt anderledes). Eller svare det bare til en oversættelse at flytte det fra et programmeringssprog til et andet?

  • 0
  • 0

Hvis jeg læser nogens kode i et program, skriver algoritmen/tankerne bag ned og så selv skriver en kode baseret på det samme i et andet sprog.

Kan du det, efter at prøvet to sprog? Eller er 5-10 stykker nok? Jeg tvivler ;)

Man har vist US-patenter på SW. Men jeg har mest gjort mig i åbne systemer, så jeg ved det (heller) ikke.

Mange forveksler open systems med open source, som forveksles med gratis SW.

Der er vist (her på siden) en såkaldt freeBSD "kerneudvikler"; samme job, som Linus Thorvalsen havde på Linux, men men men, BSD er fra Berkely og Linux er kun en (fleksibel) kerne? (Som mindst et middelstort open systems firma også hjalp til med.) Intet under at alt roder på SW-fronten herhjemme;)

Proprietary SW systems kan også være "open source" - fx kræver US-govenment vist adgang til kildetekst til Windows (NT), men igen: min data er ikke helt nye mere.

  • 1
  • 0

Kan du det, efter at prøvet to sprog? Eller er 5-10 stykker nok? Jeg tvivler ;)

Hehe det kommer vist an på, hvor simpel koden er. Jeg kom til at tænke på det, fordi det var en øvelse vi havde til et introkursus i programmering en gang. Men altså det var også et stykke "software" på under ti linjer, så som sagt ikke lige min ekspertise :) Jeg har kun rigtig brugt småkoder til at styre apparater i laboratoriet og lave lidt databehandling.

fx kræver US-govenment vist adgang til kildetekst til Windows (NT), men igen: min data er ikke helt nye mere.

Uhh det lyder spændende, hvor meget regeringen kan kræve adgang til, det må jeg lige have læst op på.

  • 0
  • 0

Hvis jeg læser nogens kode i et program, skriver algoritmen/tankerne bag ned og så selv skriver en kode baseret på det samme i et andet sprog. Er det sådan en situation ”clean room” implementering ville dække?

En rigtig clean-room implementering kræver, at du ikke har adgang til teksten af det program, du vil genskabe. Men det er selvfølgelig svært at bevise, så i praksis skal programmerne være så forskellige, at det nye kunne være lavet so clean-room implementering.

Bare at omskrive koden til et andet sprog er ikke nok -- det svarer til oversættelsen af en roman. En erfaren programmør, der kender begge sprog godt, vil sagtens kunne se forskel på en systematisk oversættelse og en genimplementering uden kendskab til den oprindelige kode.

På universiteterne er der ofte kurser, hvor alle studerende får den samme programmeringsprojektopgave. Det er i reglen ikke svært for eksaminatorer og censorer at se, om to studerende har arbejdet sammen eller ej, selv om de prøver at sløre det ved at omstrukturere koden og bruge andre navne. Man kan se, at fremgangsmåden er den samme. Og det er netop fremgangsmåden, man ser på, hvis man vil sammenligne programmer i forskellige sprog.

  • 3
  • 0

Eksempel på softwarepatent
Hej Louise

Udtrykket softwarepatenter lyder ganske rigtigt som noget med programlinier og ophavsret hertil. Du nævner forbindelse til en fysisk konstruktion.

Man kan sagtens tage patent i USA på software som ikke er programlinier med forbindelse til et fysisk apparat, men i stedet har forbindelse til noget, som sker på en skærm.
Lad mig give som eksempel et af mine allerførste patenter i USA, patent nummer 6,931,603. Dette patent kan kategoriseres under begrebet software patenter, for der indgår ingen hardware.
Her er kort opfindelsen:
Jeg fandt ud af, at en grafikfil, det være sig JPG eller GIF format, udgør en afsluttet struktur. Dermed kan man "skrive/appende" noget information til filen uden at nogen opdager det.
En web browser viser grafikken uden at tage hensyn til det tilføjede, og ethvert grafik-værktøj kan bruges til at modificere grafikken.
Denne opdagelse er det som udgør opfindelseshøjden (hvilket er er et besynderligt udtryk, jeg ynder mere at bruge det engelske "inventive step").
Denne opdagelse er det som ingen andre har tænkt på.
Opfindelsen kan bruges når man f.eks. har et billede til et kørekort. Alle data om den pågældende person kan være gemt i billedet selv.
Eller hvis man har et billede, hvor der forekommer hotspots på, det kan være et landkort, ja så kan links tilhørende disse hotspots være gemt i billedet selv.
Jeg håber at dette hjælper med at nuancere billedet af softwarepatenter.

  • 0
  • 0

Denne opdagelse er det som udgør opfindelseshøjden

Men det er gjort så mange gange før. Måske ikke lige præcis med jpeg filer men tilsvarende på andre formater .

På stående fod kan jeg eksempelvis nævne DHCP som er en ovenbygning på BOOTP. Ved at tilføje og bruge områder som BOOTP ignorere har man udvidet funktionaliten. En DHCP pakke er derfor også en gyldig BOOTP selvom de ikke havde tænkt på at fremtidssikre.

Jeg vil mene det er en rimelig standard metode til at være bagudkompatibel og det vil undre hvis ikke der findes eksempler helt tilbage til datalogiens fødsel.

Det er der en RFC på. Men sikkert ikke i patentdatabaserne.

  • 2
  • 0

Baldur Norddahl

Et patent er tæt knyttet til det tekniske problem, som opfindelsen løser.
Min opfindelse løser følgende problem:
Man har et billede, og på billedet ønsker man hotspots visse steder.
Man har oplysninger om placeringen af hotspots på billedet samt tilhørende link for hver hotspot.
Hvordan downloader man disse informationer i eet download.

Det med kørekortet er ikke omfattet af patentet, og naturligvis heller ikke noget om DHCP og BOOTP.
En patentguru fortalte mig engang, at jeg kunne få et særskilt patent på det med kørekortet, for det drejer sig om et andet problem.
Men det forfulgte jeg aldrig.

  • 1
  • 0

Baldur Norddahl
Jeg tog ikke et kendt værktøj. Og "examiners" undersøgte min opfindelse for såkaldt "prior art" og fandt ikke noget. Men ellers er jeg enig i problemstillingen. Og jeg forfulgte aldrig det med kørekortet.

  • 0
  • 0

Jeg kommer i tanker om, at jeg genbrugte opfindelseshøjde fra et patent i et andet patent.
Det kan man godt, men så skal der være tale om det, som man kalder "a surprising effect".
Det drejer sig om US patent number 8,683,313. Jeg taler om USA, jeg tror måske at denne blog er målrettet Europa, hvilket jo er naturligt.

Men i dette patent genbrugte jeg opfindelseshøjden, at gemme data tilføjet i slutningen af en grafikfil.
Hvis nogen spørger, så vil jeg forklare hvad patentet går ud på, ellers kan man læse patentet på USPTO.

  • 0
  • 0

Efter at have læst Louises indlæg igen, må jeg sige, at mine to nævnte patenter ikke er softwarepatenter, men i stedet metoder. De er computerimplementerede metoder. Men det er metoder, som er uanvendelige UDEN computer. Computerimplementerede indikerer altså ikke her at metoderne også kan udføres manuelt.

  • 0
  • 0

Efter dit venlige svar måtte jeg lige opdatere mig;-)
Søge streng til din søgemaskine - uden plinger "...":
"usa software windows source code access"

Så kan du finde ud af hvad, hvor og hvem.
Jeg blev temmelig overrasket; MS har et Shared Source Inititive og jeg nåede at skimme - andre steder - at bl.a. Sverige også har købt Windows source code. Resten må du selv opdage.

  • 0
  • 0
Bidrag med din viden – log ind og deltag i debatten