Kun je software, een algoritme of een AI-model patenteren?

Vraag op internet of software gepatenteerd kan worden en je zult twee zelfverzekerde antwoorden vinden. De ene kant zegt nee, omdat software abstract is. De ander zegt ja, want er bestaan ​​duizenden softwareoctrooien.

Beide antwoorden zijn te lui om nuttig te zijn.

Dit is de versie die oprichters en ingenieurs wat mij betreft als eerste moeten horen: een octrooi beschermt normaal gesproken geen blok code. Het auteursrecht beschermt de concrete code die je hebt geschreven. Een octrooi kan de uitvinding achter die code beschermen, beschreven aan de hand van technische kenmerken en afgebakend in octrooiconclusies—zelfs als een concurrent die kenmerken later met volledig andere code implementeert.

Daarom zijn de eerlijke antwoorden op drie veelgestelde vragen allemaal “soms”:

• Kan software gepatenteerd worden? Soms.
• Kan een algoritme gepatenteerd worden? Soms, als het deel uitmaakt van meer dan een abstracte methode.
• Kan een AI-model gepatenteerd worden? Soms, wanneer de geclaimde uitvinding een concrete technische oplossing is en niet alleen het label ‘AI’ op een gewenst resultaat.

Ik weet dat ‘soms’ niet het bevredigende antwoord is. Maar het leidt tot de nuttige vraag: welk technisch probleem lost de uitvinding op, hoe lost ze dit op, en wat zou het octrooi precies claimen?

De drie dingen die mensen steeds door elkaar halen

Deze drie lagen zijn gemakkelijk samen te vatten tot één.

De code is de specifieke brontekst: de functies, namen van variabelen, structuur en implementatie die je hebt geschreven. Auteursrecht kan die uitdrukking beschermen, maar belet normaal gesproken niet dat iemand onafhankelijk andere code schrijft die dezelfde functie vervult.

Het algoritme is de logische of wiskundige procedure. Een sorteerregel, scoreformule, optimalisatiemethode of neurale netwerkarchitectuur kunnen intellectueel indrukwekkend en commercieel waardevol zijn. In abstracto zijn wiskundige methoden en abstracte ideeën echter doorgaans uitgesloten van octrooibescherming.

De in een computer geïmplementeerde uitvinding is het algoritme dat binnen een gedefinieerd technisch systeem opereert om een technisch resultaat te produceren. Dat kan een controller zijn die het opladen van de batterij verandert als reactie op voorspelde degradatie, een pijplijn voor beeldverwerking die sensorvervorming compenseert, of een planningsmethode die congestie in een communicatienetwerk vermindert.

Bij die derde laag begint meestal een geloofwaardige octrooizaak. De code is één uitvoering; de uitvinding is de technische leer eronder.

In de VS verandert het toevoegen van “op een computer” niets

In de Verenigde Staten moet een software- of AI-conclusie eerst binnen de octrooieerbare materie van 35 U.S.C. 101 vallen. Rechtbanken hanteren uitzonderingen voor abstracte ideeën, natuurwetten en natuurverschijnselen. Alleen “met behulp van een computer” toevoegen aan een abstracte bedrijfsregel maakt daarvan dus nog geen uitvinding.

De huidige USPTO-richtlijnen over octrooieerbare materie vragen onder meer of een conclusie op een rechterlijke uitzondering is gericht en of die uitzondering in een praktische toepassing is geïntegreerd. De AI-voorbeelden zetten conclusies die alleen wiskundige concepten noemen bewust tegenover conclusies die deze in een concrete toepassing gebruiken.

Dit is slechts de eerste drempel. De uitvinding moet daarnaast nieuw, bruikbaar en niet voor de hand liggend zijn, en de aanvraag moet haar voldoende beschrijven. Een conclusie kan technisch klinken en toch stranden omdat een eerder octrooi of artikel hetzelfde al openbaar maakte. Ook kan een aanvraag een functie beloven zonder uit te leggen hoe die wordt bereikt.

Daarom is de octrooieerbaarheid van software geen kwestie van de juiste labels. ‘AI-gestuurd’, ‘cloudgebaseerd’ en ‘uitgevoerd door een processor’ zijn versiering zolang de aanvraag de techniek erachter niet uitlegt.

Europa vraagt zich af of de bijdrage technisch is

Europa gebruikt een andere taal, maar stuit op een daarmee samenhangende praktische uitdaging. Op grond van het Europees Octrooiverdrag zijn computerprogramma’s en wiskundige methoden “als zodanig” uitgesloten. In computers geïmplementeerde uitvindingen kunnen niettemin octrooieerbaar zijn wanneer de relevante kenmerken bijdragen aan het technische karakter van de uitvinding en een technisch probleem helpen oplossen.

In de richtlijnen van het EOB uit 2026 staat dat modellen voor AI en machinaal leren [op zichzelf abstract wiskundig van aard] zijn (https://www.epo.org/en/legal/guidelines-epc/2026/g_ii_3_3_1.html). Het gebruik ervan betekent niet automatisch dat een uitvinding niet octrooieerbaar is. Ze kunnen een bijdrage leveren wanneer ze worden toegepast op een technisch doel of aangepast aan een specifieke technische implementatie.

Het EOB geeft nuttige voorbeelden. Een neuraal netwerk dat in een hartbewakingsapparaat wordt gebruikt om onregelmatige hartslagen te identificeren, kan een technische bijdrage leveren. Dat geldt ook voor de classificatie van afbeeldingen, video, audio of spraak op basis van signaalkenmerken op laag niveau. Daarentegen is het classificeren van tekst alleen op basis van de taalkundige inhoud niet automatisch een technisch doel.

Er bestaat niet één wereldwijde ‘softwareoctrooiregel’. Dat is lastig, maar de les bij het opstellen is simpel: beschrijf de echte techniek zo grondig dat verschillende juridische kaders deze kunnen zien.

Vier zinnen die het verschil blootleggen

Vergelijk deze paren.

Zwak: “Gebruik AI om energieverbruik terug te dringen”

De verklaring bevat een doel en een modieus hulpmiddel, maar geen uitvinding. Wat verbruikt de energie? Welke signalen worden waargenomen? Wat voorspelt het model? Welke fysieke werking verandert? Waarom vermindert die verandering de consumptie in plaats van er alleen maar melding van te maken?

Sterker: adaptieve regeling van een industrieel koelsysteem

Het systeem ontvangt gegevens over temperatuur, druk, flow en compressorstatus; genereert een voorspelling van de thermische belasting op korte termijn; beperkt de voorspelling volgens apparatuurlimieten; en verandert de compressorvolgorde om de piekvraag te verminderen terwijl een gedefinieerd temperatuurbereik behouden blijft. Het model, de regelkring, beperkingen en apparatuurinteractie kunnen nu worden doorzocht en beschreven.

Zwak: “Een algoritme dat de beste leveranciers rangschikt”

Dit kan commercieel nuttig zijn, maar het rangschikken van zakelijke opties op basis van commerciële gegevens lijkt veel dichter bij een abstract besluitvormingsproces.

Sterker: netwerkroutering onder veranderende radio-interferentie

De methode meet de kanaalomstandigheden op gedefinieerde intervallen, produceert een schatting van de congestie op basis van gegevens op linkniveau, wijst pakketten toe aan routes onder latentiebeperkingen en werkt de routeringstabel bij wanneer een drempel wordt overschreden. De octrooiconclusie is niet langer ‘kies de beste optie’. Het is gekoppeld aan de werking van een communicatiesysteem.

Voor geen van beide sterkere voorbeelden is een octrooi gegarandeerd. Ze hebben eenvoudigweg de grens overschreden van slogan naar mechanisme, en dat is waar de octrooivraag de moeite waard wordt om te stellen.

“Het maakt gebruik van een neuraal netwerk” is geen openbaarmaking

AI-toepassingen hebben een bijzondere valkuil: het model wordt een zwarte doos in de exacte zin waarin al het interessante werk gebeurt. Ik zie voortdurend dezelfde snelkoppeling.

“Het model genereert een geoptimaliseerde output” vertelt de lezer vrijwel niets. Een nuttig concept moet wellicht het volgende uitleggen:

• wat de input vertegenwoordigt en hoe deze wordt verkregen;
• voorbewerking en featureconstructie;
• de relevante modelarchitectuur of verwerkingsfasen;
• hoe training en gevolgtrekking worden uitgevoerd;
• beperkingen, drempels, feedback of nabewerking;
• hoe de output een technisch systeem verandert; en
• welke alternatieven hetzelfde technische effect opleveren.

Niet iedere aanvraag hoeft broncode, exacte gewichten of de volledige trainingsdataset te bevatten. Maar als het effect afhangt van bepaalde eigenschappen van de dataset, moeten die mogelijk wel worden beschreven. Het EOB merkt specifiek op dat eigenschappen van trainingsdata die nodig zijn om een technisch effect te reproduceren, moeten worden uitgelegd wanneer een vakman die anders niet zonder buitensporige inspanning kan bepalen.

Buiten AI geldt hetzelfde principe: verberg de inventieve stap achter het woord ‘automatisch’ niet.

Kan het model zelf de uitvinding zijn?

Soms willen aanvragers een getraind model beschermen als een object dat losstaat van het systeem dat er gebruik van maakt. Dit kan moeilijk zijn.

Een model kan worden gekarakteriseerd als wiskundige parameters, een datastructuur, een door een computer leesbare implementatie, een trainingsmethode, een gevolgtrekkingsmethode of een onderdeel van een groter apparaat. Dit zijn geen uitwisselbare strategieën voor octrooiconclusies. Hun behandeling verschilt ook per rechtsgebied.

In praktische termen is de zaak meestal sterker als je ten minste één van deze punten kunt uitleggen:

• een specifiek technisch gebruik van het model;
• een modelarchitectuur aangepast aan een technische beperking;
• een trainingsproces dat een aantoonbaar technisch effect oplevert;
• een bepaalde inzet die de werking van hardware of een ander technisch systeem verbetert; of
• een verbetering op computerniveau, zoals geheugengebruik, verwerkingsdistributie, beveiliging, latentie of resourceverbruik.

De richtlijnen voor wiskundige methoden van het EOB geven een ongewoon concreet voorbeeld: het toewijzen van data-intensieve trainingsstappen aan een GPU en voorbereidende stappen aan een CPU kan bijdragen aan het technische karakter wanneer de implementatie gebruik maakt van de architectuur van het computerplatform. “Sneller AI” is vaag. Een gedefinieerde manier om hardware te gebruiken om de verbetering te bereiken is veel nuttiger.

Vergeet het uitvinderschap niet wanneer AI heeft meegeholpen

Er is een tweede AI-vraagstuk dat niets te maken heeft met de vraag of de technologie in aanmerking komt: wie heeft het uitgevonden?

Volgens de herziene USPTO-richtlijnen van november 2025 kunnen alleen natuurlijke personen als uitvinder worden genoemd. AI-systemen gelden als hulpmiddelen; voor de mensen die de geclaimde uitvinding hebben bedacht blijft de gewone juridische maatstaf gelden.

Het gebruik van AI tijdens onderzoek of ontwikkeling staat een octrooi niet automatisch in de weg. Het maakt goede documentatie wel verstandig. Leg vast welk technisch probleem het team heeft vastgesteld, welke keuzes mensen maakten, welke voorstellen zijn aanvaard of afgewezen en hoe de geclaimde oplossing vorm kreeg.

De aanvraag hoeft geen dagboek van iedere prompt te worden. Het bedrijf moet wel kunnen uitleggen welke menselijke gedachtegang achter de geclaimde uitvinding zit.

Zoek meer dan alleen productnamen

Software-oprichters zoeken vaak op de naam van hun productcategorie, vinden niets en voelen zich opgelucht. Ik zou mij verdacht voelen. De betreffende stand van de techniek kan hetzelfde mechanisme in een compleet andere markt beschrijven.

Een wachtrijbeheertechniek voor cloudtaken kan lijken op planning die in de telecommunicatie wordt gebruikt. Een fraudedetectiefunctie kan de architectuur delen met foutdetectie in industriële sensoren. Een aanbevelingsmodel ziet er misschien nieuw uit in de detailhandel, maar is bekend in de ranking van de media.

Doorzoek het technische mechanisme op verschillende niveaus:

1. Het resultaat. Wat bereikt het systeem?
2. De methode. Welke reeks of welk model levert dat resultaat op?
3. De architectuur. Welke componenten wisselen welke gegevens uit?
4. De beperking. Welke technische beperking wordt overwonnen?
5. Het effect. Wat wordt sneller, veiliger, nauwkeuriger, minder hulpbronnenintensief of fysiek anders?

Met Patenta kun je dat mechanisme in gewone taal beschrijven en in octrooidocumenten zoeken op betekenis in verschillende rechtsgebieden. Zodra je de dichtstbijzijnde systemen heeft gevonden, kun je hun kenmerken met die van je vergelijken en de verschillen in een gestructureerd concept verwerken, in plaats van opnieuw op te starten vanaf een leeg document.

octrooidatabanken vormen niet het hele universum van de stand van de techniek. Voor software en AI kunnen ook papers, standaarden, documentatie, conferentiemateriaal, open-source repository’s en eerdere publieke producten van belang zijn. Gebruik het zoeken naar octrooien als een sterk startpunt, en niet als een belofte dat er niets anders bestaat.

Bepaal wat er in het octrooi thuishoort, en wat niet

een octrooi is niet de enige manier om een softwareproduct te beschermen.

• Copyright beschermt de broncode en andere originele expressies, niet de onderliggende functie.
• Bescherming tegen handelsgeheimen kan geschikt zijn voor modelgewichten, interne evaluatiemethoden, processen voor het opschonen van gegevens of server-side technieken die vertrouwelijk kunnen blijven.
• Een octrooi kan een geclaimde technische methode of een systeem beschermen, zelfs wanneer een concurrent andere code schrijft.

De zakelijke vraag is of openbaarmaking het potentiële recht waard is. Als een proces onzichtbaar is op je servers en moeilijk van buitenaf te detecteren is, kan het geheimhouden ervan de sterkste zet zijn. Als de uitvinding zichtbaar zal zijn in een product, standaard, API-gedrag of apparaat, kan octrooibescherming waardevoller zijn.

Het antwoord kan ook een combinatie zijn: patenteer de extern betekenisvolle technische architectuur, houd afstemmingsmethoden en operationele gegevens vertrouwelijk, en vertrouw op het auteursrecht voor de code zelf.

Een praktische checklist voor het opstellen

Voordat je aan een conceptaanvraag voor software of AI begint, noteer je het volgende:

1. Het technische probleem. Beschrijf niet alleen de zakelijke doelstelling.
2. De systeemcontext. Identificeer de betrokken apparaten, services, sensoren, processors, netwerken of opslag.
3. Het verwerkingspad. Volg gegevens van invoer tot technische uitvoer.
4. Het inventieve onderscheid. Geef aan wat hier gebeurt wat de dichtstbijzijnde stand van de techniek niet leert.
5. Het technische effect. Leg de operationele verbetering uit en hoe de geclaimde kenmerken die teweegbrengen.
6. De implementatie. Voeg voldoende details toe om te voorkomen dat de belangrijkste stap een black box wordt.
7. De alternatieven. Leg verschillende architecturen, modellen, drempels en implementatieregelingen vast.
8. Het bewijs. Behoud benchmarks, simulaties en ontwerpredenen zonder resultaten te bedenken die je niet heeft.
9. De menselijke bijdrage. Houd een praktisch uitvindingsverslag bij wanneer AI-tools deelnamen aan de ontwikkeling.

Dat is genoeg om een zinvolle zoektocht en een eerste versie te beginnen. Het ontwerp zal je, zonder veel diplomatie, vertellen dat de verklaring nog steeds berust op labels in plaats van op techniek.

Kort gezegd

Software, algoritmen en AI-modellen vallen niet categorisch buiten het octrooisysteem. Ze zijn ook niet octrooieerbaar louter en alleen omdat het om een ​​nieuwe code gaat.

De sterkste kandidaat is een concrete technische oplossing: een oplossing die je kunt uitleggen als een systeem of methode, die je kunt onderscheiden van de stand van de techniek, die verband houdt met een technisch effect en die je met voldoende details kunt onthullen om te kunnen worden geïmplementeerd.

Begin niet met ‘we gebruiken AI’. Begin met het probleem, het mechanisme en de verandering die het mechanisme teweegbrengt.

Denk je dat je software of AI-systeem een octrooieerbare technische uitvinding bevat? Beschrijf haar in Patenta, zoek naar de dichtstbijzijnde stand van de techniek en zet het technische verschil dat overblijft om in een gestructureerde eerste versie.