Hvorfor du ikke bør patentere nøyaktig det du har bygget

Ta et enkelt eksempel. Et lite teknologiselskap har utviklet en løfteanordning. Prototypen bruker en hydraulisk sylinder, en bestemt trykksensor og en sveiset stålarm. Det nye er ikke noen av disse delene hver for seg. Det nye er at armen låser seg automatisk når lasten begynner å bli skjev, slik at den ikke kan vippe.

Hvis patentet bare beskytter en arm med akkurat denne sylinderen og denne sensoren, kan en konkurrent velge en elektrisk aktuator og en annen type sensor – og kanskje oppnå den samme låsefunksjonen uten å omfattes av patentet.

Beskrivelse og patentkrav har ulike oppgaver

En patentsøknad består blant annet av en beskrivelse og et sett med patentkrav. De to delene gjør forskjellige jobber.

• Beskrivelsen skal forklare oppfinnelsen så grundig at en fagperson kan forstå og gjennomføre den. Her hører den faktiske løsningen hjemme, gjerne med detaljer, tegninger og alternative utførelser dere kjenner til.
• Patentkravene angir hva dere søker beskyttelse for. Det er kravene som avgjør hva andre ikke kan gjøre uten tillatelse.

Budskapet er altså ikke at dere skal utelate tekniske detaljer. Tvert imot: Det som ikke er beskrevet i søknaden da den ble levert, kan som regel ikke legges til senere. Poenget er at kravene ikke automatisk bør låses til den ene utgaven som står på verkstedgulvet.

Ingeniøren optimaliserer – kravene må skille det vesentlige fra resten

I utviklingsarbeidet er det riktig å gjøre prototypen så god som mulig. Dere velger komponenter som er tilgjengelige, dimensjonerer for reelle laster og legger til det som trengs for at testen skal lykkes.

Når patentkravene skal formuleres, er spørsmålet et annet: Hvilke trekk er nødvendige for at løsningen skal gi den tekniske effekten, og hvilke er bare ett av flere mulige valg? I eksemplet er låsefunksjonen kanskje det vesentlige, mens sylindertypen og sensormerket er praktiske valg.

Spørsmålet som hjelper: Virker det uten denne delen?

En nyttig øvelse er å gå gjennom løsningen del for del og spørre:

• Virker prinsippet fortsatt hvis denne komponenten fjernes eller byttes ut?
• Kan den samme effekten oppnås på en annen måte, for eksempel mekanisk i stedet for hydraulisk?
• Er denne detaljen nødvendig, eller valgte vi den fordi den var tilgjengelig?

Svarene gir et bedre grunnlag for å vurdere hvilke varianter kravene bør favne. Hvis dere kjenner til realistiske alternativer, bør de også beskrives i søknaden, slik at det finnes grunnlag for å dekke dem.

Bredt nok – men ikke bredere enn det er grunnlag for

Det betyr ikke at kravene alltid skal være så brede som mulig. Bredden må vurderes opp mot kjent teknikk, altså det som allerede er kjent før søknaden ble levert, og opp mot det som faktisk er beskrevet i søknaden. Et krav som også dekker kjente løsninger, vil ikke bli godkjent slik det står.

Derfor bygges kravene ofte i nivåer. Et selvstendig krav angir den bredeste beskyttelsen dere mener det er grunnlag for. Underkrav legger til flere trekk og gir mer avgrensede alternativer, for eksempel en bestemt type aktuator eller sensorplassering. Underkrav kan være nyttige hvis det bredeste kravet må begrenses under behandlingen, men de garanterer ikke at patentet blir gyldig.

Hva er verdt å beskytte?

Hvor mye arbeid som bør legges i kravene, henger sammen med hva patentet skal oppnå for virksomheten. Skal det hindre konkurrenter i å lage tilsvarende produkter? Skal det styrke en forhandling med en partner? Da er det særlig viktig at kravene treffer det konkurrentene sannsynligvis vil ønske å kopiere – ikke bare den utgaven dere selv valgte å bygge. Mer om dette i hva skal IP-en løse.

Tre spørsmål til neste utviklingsmøte

1. Hvilken teknisk effekt er det egentlig som gjør løsningen vår bedre enn det som finnes?
2. Hvilke deler kunne en konkurrent byttet ut og fortsatt fått den samme effekten?
3. Hvilke alternative utførelser har vi testet, vurdert eller forkastet – og har vi notert dem?

Står dere med en prototype som virker, og lurer på hva som bør beskyttes? Ta kontakt for en innledende samtale, så ser vi på det sammen før noe deles utenfor selskapet.