Alice, of het einde van het Amerikaanse softwarepatent

In de VS is alles octrooieerbaar, zo luidt een veelgehoorde opvatting. Waar onder het Europese octrooirecht strenge eisen gelden ten aanzien van het technisch karakter en de inventiviteit van een uitvinding, is in de VS overdwars schommelen al patenteerbaar. Deze opvatting is echter achterhaald sinds de Alice-uitspraak van het Supreme Court van vorig jaar. Alleen uitvindingen die “significant” verder gaan dan enkel abstracte ideeën of algoritmes, kunnen nog voor octrooi in aanmerking komen. Deze uitspraak heeft geleid tot een forse kaalslag bij verlening en handhaving van Amerikaanse softwareoctrooien: meer dan 70% van deze octrooien is ondertussen van tafel.

Vorig jaar deed de hoogste Amerikaanse rechter eindelijk uitspraak over de vraag wanneer een software-uitvinding nu voor octrooi in aanmerking komt. Men trok een lijn door die in 2012 ingezet was met de Mayo-uitspraak: een natuurwet of abstract principe kan niet geoctrooieerd worden, de uitvinding moet significant meer zijn dan enkel dat principe. Enkel de toevoeging van een generieke computerimplementatie is niet genoeg, net zo min als een beperking tot een specifiek toepassingsgebied. De uitspraak benoemt echter niet in detail wat dan wél genoeg is, afgezien van een generieke verwijzing naar “improving the computer itself” en “an improvement in any other technology or technical field.”

De uitspraak kwam zo te zien als een grote opluchting voor het USPTO, dat vol enthousiasme zaken ging afwijzen met dit nieuwe criterium. Een recent onderzoek van Robert Sachs laat zien dat Alice een fundamentele breuk vormt met de praktijk van de afgelopen vijftien jaar: het aantal dossiers met afwijzingen (office actions) op grond van statutory subject matter is van gemiddeld zo’n 30 procent naar meer dan 85 procent gestegen. Het aantal verleende octrooien (notices of allowance) in deze vakgebieden is overeenkomstig gekelderd, naar minder dan tien procent sinds Alice tegen 20 tot 30 procent in de drie jaren daarvoor. In sommige deelgebieden worden zelfs vrijwel geen octrooien (<2%) meer verleend.

Specifiek waar het gaat om business methods is de situatie nog dramatischer. In dit vakgebied komen 58% van de octrooi-onderzoekers tot een afwijzing van alle octrooiaanvragen die op hun bureau belanden. Nog eens 20% wijst in meer dan 90% van de zaken de aanvraag af. Oftewel: meer dan 70% van alle business method-octrooiaanvragen wordt op grond van de Alice-uitspraak afgewezen bij het USPTOin de verleningsprocedure. En wie meent in de interne bezwaarprocedure een kans te maken, komt helemaal bedrogen uit: de volle honderd procent van alle (27) bezwaarprocedures waarin statutory subject matter aan de orde was, wijst de aanvraag op die grond af. Auw.

Sachs onderzocht eveneens 106 gerechtelijke uitspraken (eerste instantie en hoger beroep). Uit deze analyse blijkt een zeer sterke tendens om octrooien ongeldig te verklaren omdat zij niet statutory zijn. In meer dan 70% van alle octrooirechtszaken waarin op deze grond een octrooi werd aangevochten, werd het octrooi ook daadwerkelijk als non-statutory ongeldig verklaard. In hoger beroep gaat het zelfs om 92%.

Een inhoudelijke reden voor al deze afwijzingen is het feit dat veel softwareoctrooien in de praktijk niet veel meer zijn dan een abstract idee waarbij niet nader gespecificeerde software een generieke implementatie daarvan vormt. Deze praktijk is verklaarbaar door de eerdere jurisprudentie van het USPTO en rechtbanken, die immers niet veel meer eiste dan een koppeling met hardware (“een computer voorzien van een opslagmedium met instructies voor het uitvoeren van algoritme X”) en zelden tot nooit ter discussie stelde of het resultaat wel useful, concrete and tangible was – dat was onder de oude regels van State Street Bank immers vrijwel altijd wel het geval. Maar wie zijn aanvraag opstelde conform deze ervaringsregels, zag zijn octrooi (of aanvraag) reddeloos verloren gaan onder de Alice-criteria.

Onder Alice moet een uitvinding worden onderzocht op de aanwezigheid van een abstract idee in de claims. Bij software zal hier al heel snel sprake van zijn. De vraag wordt dan of men méér dan dit idee claimt, hetgeen in de praktijk vereist dat het functioneren van de onderliggende hardware wordt verbeterd of het idee wordt toegepast op een manier die een technische vooruitgang oplevert. Enkel opmerken dát een en ander per computer wordt uitgevoerd, is niet meer genoeg.

Het nieuwe Amerikaanse criterium van “significant meer dan het abstracte idee” komt in de praktijk neer op dezelfde afweging als de Europese probleem/oplossing-analyse. In beide gevallen wordt het abstracte idee als een gegeven genomen vanaf waar de vakman tot zijn inventieve activiteit moet komen. De Europese praktijk vereist dan een technische oplossing, waar de Amerikaanse praktijk een significante vooruitgang wil zien. Dus we hebben nu hooguit nog softwarepatenten Europese-stijl over, maar de bekende voorbeelden van het overdwars schommelen of one-click shopping kunnen we nu eindelijk in de vuilnisbak van de geschiedenis deponeren.

Arnoud

26 reacties

  1. Het werd tijd dat dit werd aangepast, ik ben benieuwd wat de invloed hiervan gaat zijn in de ‘slide to unlock’-zaak tussen Apple en Samsung, evenals soortgelije zaken.

    @Arnoud: ik vermoed dat je server nog niet op wintertijd staat, deze post was een uur te vroeg online… (de tijd van deze reactie heeft ook een uur afwijking)

      1. Met TZ=CET in de omgeving zou het gewoon moeten werken, ook bij zomertijd (en als het dat niet doet, is dat een bug). Dat gebeurt op een lager niveau, daar heeft woordpers -als het goed is- niks mee te maken. –zeur.

  2. Kan je nog een keer uitleggen wat de Europese norm dan precies is op het gebied van software-patenten? Dat heb ik nooit echt begrepen. Misschien met twee duidelijke voorbeelden: 1 ding dat duidelijk niet patenteerbaar is, en 1 ding dat duidelijk wel patenteerbaar is. Het liefst twee voorbeelden die erg op elkaar lijken, zodat het onderscheid het scherpst zichtbaar is.

    1. De Engelstalige wikipedia geeft een donders goede uitleg: https://en.wikipedia.org/wiki/SoftwarepatentsundertheEuropeanPatentConvention

      Helaas is dat niet in twee regels samen te vatten, omdat er vele andere concepten uit het octrooirecht samenkomen.

      Om het te simplificiren: Software op zichzelf: zeker nee Een computer waarop die software draait: Mogelijk ja (passeert de ‘first hurdle’), maar moet wel een technisch (en niet een adminstratief of zakelijk of marketing etc) probleem oplossen, en dat ook nog eens een keer op een manier die niet voor de hand ligt (zoals alle uitvindingen)

      Dus een facebook kloon voor een doelgroep waar er nog geen voor is, met wat aanpassingen die het voor die doelgroep aantrekkelijker maken: geen kans, want er is geen technisch probleem, alleen een marketingprobleem.

      Als er nu echter een nieuwe, snellere inlogprocedure inzit (dus minder data uitwisseling voor hetzelfde niveau van veiligheid) zou die aanpassing waarschijnlijk wel octrooieerbaar kunnen zijn.

      Om het nog anders te simplifceren: Wat de software doet: waarschijnlijk niet octrooieerbaar, Hoe die software dat doen: wel octrooieerbaar indien nieuw en inventief.

      1. Wat de software doet: waarschijnlijk niet octrooieerbaar

        Dit maakt het voor mij onbegrijpelijk. Het bedenken wat de computer moet doen is juist de inventieve moeilijke stap. Als je een exacte beschrijving hebt van “wat” de computer moet doen (exacte specificatie), kan een computer dit automatisch vertalen naar een uitvoerbaar programma (“hoe”). Die laatste stap (“hoe”) is nog slechts een beperkte keuze: of het nu op android moet of op apple/i-os en welke tooling (en eventueel welke programmameurs, als de tooling of specificatie onvoldoende is) daar precies te voor te gebruiken lijkt me juist een redelijk standaard proces …

          1. Als programmeur schaar ik me geheel aan zijde van Elroy: mijn ervaring leert me dat specificeren en programmeren creatief werk is, geen inventief werk. Als je éénmaal weet wat de klant/eindgebruiker nodig heeft (en om daarachter te komen moet je ook soms behoorlijk creatief zijn, al zijn ook daar diverse standaardmethoden voor) , is het vertalen van die noden in een functionerend programma/applicatie niet bepaald baanbrekend werk, maar wel moet je soms creatief zijn in het omgaan met de combinatie tussen de gebruikerswensen en de beperkingen die de programmeertaal of het framework je oplegt.

          2. Uitwerken (“hoe”) is in de praktijk vaak (zeer) creatief werk. Dat komt enerzijds omdat de specificaties onvolledig/ongestructureerd zijn en anderzijds omdat de tooling voor veel platformen (nog) niet voldoende is. Ik denk dat de creatieve kant ook regelmatig onderschat wordt. Helemaal met je eens dat auteursrechtenbescherming daarvoor op zijn plaats is en (dus?) niet het octrooirecht. Het gaat me er juist om dat ik zou verwachten dat het octrooirecht zou moeten gelden voor het idee (“wat”) (dat inderdaad vaak van de werkgever komt). Daarbij moet dat idee natuurlijk wel enigszins concreet zijn. Het octrooirecht duurt ook veel korter dan het auteursrecht en dat lijkt me ook in dit licht wel een terecht principe (hoewel ik beide erg lang vind).

    2. De regel is dat je een technische verbetering moet claimen, een technische oplossing voor een probleem. Een bekend voorbeeld is een algoritme dat een ABS-remsysteem in een auto effectiever laat remmen (sneller stilstaan zonder te slippen). Hoewel dat algoritme puur software is, levert het in het remsysteem een duidelijke verbetering in de echte wereld, een duidelijke technische verbetering op.

      Een niet-octrooieerbare uitvinding is een online veiling waarbij het probleem wordt opgelost dat twee mensen min of meer tegelijkertijd kunnen bieden (en je dus niet weet wie er wint). Die oplossing is op zich nuttig in het vakgebied, maar het is geen techniek doch een zakelijke aanpak. Dat is niet octrooieerbaar.

      Wel octrooieerbaar zou zijn een techniek voor een online veiling waarbij je met een token-achtige constructie voorkomt dat twee mensen tegelijkertijd kunnen bieden. In feite bouw je dan een berichtensysteem met collisie-preventie. Het domein “veiling” doet er dan niet meer toe.

      1. Je ABS-voorbeeld doet vermoeden dat het moet gaan om software die op (andere(*)) takken van de techniek voordelen biedt, met name op het gebied van de mechanica. Je veiling-voorbeeld doet dat vermoeden teniet.

        Ik vind je veiling-voorbeelden interessant. Wat betekenen deze voorbeelden? Begrijp ik goed dat het idee om het probleem van tegelijkertijd bieden op te lossen niet patenteerbaar is, maar dat het idee om dat probleem met een specifieke methode op te lossen wel patenteerbaar is?

        Zou het daarbij uit maken als wiskundig aantoonbaar is dat die methode de enige mogelijke methode is, of dat elke alternatieve methode wiskundig equivalent is aan de beschreven methode (wat op het zelfde neer komt)? Zou het uitmaken als er een declaratieve programmeertaal is waarin je het op te lossen probleem kunt specificeren, waarna de computer zelf de methode kan genereren? Bewijst dat dat de gekozen methode niet creatief is, of dat computers blijkbaar wel creatief kunnen zijn? Is de probleemspecificatie in de declaratieve programmeertaal in wezen ook een implementatie, en daarmee gelijkwaardig aan imperatieve implementaties? Maar waarin is die probleemspecificatie anders dan je eerste voorbeeld, dat niet patenteerbaar was?

        (*) afhankelijk van of je software als “techniek” ziet; er zijn ook andere zienswijzen.

        1. Inderdaad moet het om takken van de techniek gaan. Maar digitale communicatie is ook een tak van de techniek, toch? Daarom zie ik daar geen inherent probleem. En inderdaad moet het gaan om een hoe, een methode.

          De methode kan een zeker niveau van abstractie kennen. Bijvoorbeeld: een muziekbestand met een stereosignaal kun je verkleinen door slechts één kanaal volledig op te slaan en van het andere kanaal te noteren welke verschillen er zijn met het ene kanaal. Dat kost immers minder opslagruimte en je kunt toch het stereo-signaal afspelen. Dit is een oplossing die abstract is maar volgens mij nét technisch genoeg om al te kunnen patenteren. De aanvraag moet dan wel uitleggen hoe je bij een willekeurig stereo-signaal die verschillen uitrekent ,want je moet in je octrooi wel vertellen hoe de uitvinding werkt.

          1. Hoe je voor een willekeurig stereo-signaal de verschillen uitrekent? Gewoon per sample dit toepassen, zou ik zeggen, maar dat heeft absoluut prior art, en is triviaal. Hoe je ervoor zorgt dat de verschillen kleiner kunnen worden opgeslagen? Via deze methode, zou ik zeggen, of via deze methode (maar die is gepatenteerd geweest).

            Op jouw nieuwe voorbeeld van muziek-compressie kan je de zelfde analyse toepassen als op het veiling-voorbeeld. Het algemene idee is: muziek lossless comprimeren. Dat algemene idee zal wel niet patenteerbaar zijn, maar een specifieke manier (verschil-codering tussen stereo-kanalen) wellicht wel. Het interessante is hier dat er duidelijk meerdere compressie-methoden zijn, die niet wiskundig equivalent zijn: er is geen 1-op-1 relatie tussen probleem en oplossing, en dus ook geen computerprogramma dat jou, gegeven het probleem, “de” oplossing geeft.

            Er is alleen wel een vergelijkbaar computerprogramma mogelijk, door 1 abstractie-niveau hoger te gaan zitten: je kunt een computerprogramma maken dat, gegeven een specificatie van de syntax van bepaalde bestanden, en gegeven een hele schijf vol met zulke bestanden, op zoek gaat naar een effectieve lossless compressie-methode. Zo’n computerprogramma kan dan op zoek gaan naar allerlei correlaties binnen de gegeven voorbeelden, en op basis daarvan een geschikt algoritme genereren. Je zou zo’n programma ook nog bepaalde constraints kunnen geven, bijvoorbeeld snelheid van decompressie, en seekbaarheid en streambaarheid van het formaat.

            De uitkomst van zo’n computerprogramma, losgelaten op muziekbestanden, zal ongetwijfeld beter zijn dan een willekeurige methode als “stereo verschil encoding”. Het is ook goed mogelijk dat de uitkomst onder andere “stereo verschil encoding” toepast.

            Dan is mijn vraag: is zo’n gegenereerd algoritme een inbreuk op het patent, of toont het aan dat de gekozen methode niet creatief is (want “de computer kan het ook”)?

            Volgens mij kan je dit spelletje met elke uitvinding spelen (ook niet-software patenten), door een computerprogramma te maken dat op 1 abstractie-niveau hoger problemen oplost, en vervolgens dat computerprogramma uit te voeren.

            1. Zo’n patent op arithmetic coding heb ik dus een probleem mee. Ja het geeft een technische verbetering (minder opslagruimte), maar het is puur wiskunde en gebaseerd op wetmatigheden (Information Theory).

              Ik heb dan minder moeite met een patent op MP3, daarbij gaat informatie verloren, maar op een zodanige manier dat het nauwelijks hoorbaar is. Welke informatie verloren gaat is gebaseerd op een psycho acoustisch model en daar heb je er meerdere van. Een patent op een specifiek model lijkt mij niet onredelijk. Een patent op het gebruik van zo’n model in het algemeen lijkt me dan weer niet, dat is meer een idee, dan een specifieke implementatie.

    1. Dat klopt. En ze worden massaal ongeldig verklaard bij de rechtbank, zoals blijkt uit het onderzoek van Robert Sachs.

      Een belangrijke reden voor dit grote aantal afwijzingen bij de rechter is de procedurele kant van de zaak. Onder het Amerikaans octrooirecht wordt de geldigheid van een octrooi gezien als een matter of fact en derhalve iets voor de jury om te beslissen. Dit is een langdurig en onzeker proces, omdat de jury gewoonlijk weinig kaas gegeten heeft van de techniek en dus moeilijk kan inschatten of een uitvinding iets innovatiefs is ten opzichte van de stand der techniek.

      Dit is echter anders bij de vraag of een octrooi statutory subject matter betreft. Dit is een matter of law en dus door de rechter zelf te beslissen. Deze beslissing kan al in een (veel) vroeger stadium worden genomen, meer specifiek voordat de kostbare, langdurige en complexe discovery-procedure gevoerd gaat worden die veel partijen doet afschrikken van een octrooiprocedure. Wie vóór Alice in een octrooiprocedure werd betrokken, moest kiezen tussen een langdurige en kostbare procedure of een schikking. Wie dat ná Alice overkomt, kan kiezen voor de snelle en relatief goedkope tegenaanval op statutory gronden.

    1. De grenzen van het softwarepatent zijn wel héél ver opgerekt sinds die jaren zeventig. Toen kon je onder Benson of Flook wel een en ander krijgen, maar altijd beperkt tot machines of harde innovatie (dat ABS-systeem). Eind jaren negentig ging het mis toen de CAFC met State Street Bank ineens zei, alles kan als het geld oplevert. Waarom ze dat nu doen en niet al eerder (bv. bij Mayo), geen idee. Misschien werd de aanhoudende druk van trollen (die profiteren van zwakke octrooien en lastige vernietiging daarvan) een motivatie?

    2. In mijn ervaring is het Supreme Court niet echt happig op vrijwillig misstanden rechtszetten. Van de ene kant hebben ze al een enorme werkdruk omdat er ontelbaar veel verzoeken klaar liggen om een zaak door hen te laten behandelen. Van de andere kant vereist iedere zaak die ze wel doen een zee van tijd. Naast het wet-technische aspect moeten ze ook een inhoudelijk oordeel (the ‘opinions’) geven. Met soms verstrekkende gevolgen. Kijk maar recentelijk naar Alice of de vraag of het homohuwelijk ongrondwettelijk is.

      Het hele systeem achter patenten (in de VS dan) kan je zien als een uiting van The American Dream: rijk worden met behulp van je eigen intelligentie. Zulke intelligente/innovatieve mensen verdient bescherming. Dat was het uitgangspunt. Nu moet dat zijn: verdiende. Maar zo dacht men wel. Waarbij even een flinke sneer uitgedeeld mag worden richting het USPTO: ze verdienen jaarlijks goed op elk goedgekeurd patent, maar bijna niks op elk afgekeurd patent. Afgekeurde patenten levert ze vaak alleen maar rechtszaken op waarin ze moeten getuigen en waarbij de kleinste fout van hun kant ze een miljoenenclaim aan hun broek oplevert.

      Vergeet ook niet in deze de tijdlijn. Toen was een terminal hebben vrij uniek, vandaag de dag telt elk huishouden meerdere computers, tablets en smartphones. Waar in de jaren 1970 iedere programmeur een hoge opleiding had genoten of tenminste heel intelligent en ervaren was, kan vandaag de dag iedere beunhaas met een internet verbinding leren om code schrijven om zo iets softwarematig te regelen. Wat het aantal patentaanvragen flink heeft verhoogd.

      Mooi voorbeeld: Ik heb een keer een vriend gehad die wilde patent aanvragen op de manier waarop een rekenmachine een getal (x boven y) uitrekent. Op veel rekenmachines levert het al snel een error op, terwijl het antwoord niet buiten hun bereik ligt. Dat komt omdat de routine onder de breuk de waarden in volgorde van klein naar groot afwerkt. Als je het antwoord zou plotten per rekenstap, dan levert dat een bergparabool op met een top boven het maximum bereik. Daarom kreeg je die error. Zijn vinding was om onder de breuk de volgorde van groot naar klein te doen. Dan ging het wel. Zeg nou zelf, is dát nou echt een patent waard?

      1. Mischa, je maakt naar mijn mening 2 denkfouten

        1) als je eenmaal de uitvinding kent, is het makkelijk om te zeggen: is dat nou alles. Probeer je eens terug te plaatsten in de tijd, waarin je alleen denkt: verdorie, die berekening is toch wel onnauwkeurig. Zou je dan vanzelf op die oplossing van je vriend zijn gekomen?

        2)Je moet niet van het idee uitgaan dat een patent een soort ‘award’ is van de overheid om te zeggen: wat heb jij een grote prestatie geleverd.

        Een octrooi kan je krijgen voor iedere technische vinding, groot of klein, zolang die aan de voorwaarden technisch/nieuw/inventief voldoet. En inventief heeft niets te maken met de grootte van de vooruitgang, maar met de voor de hand liggendheid ervan,

        De keus om daar een octrooi voor aan te vragen, en de afweging of daar business in zit, is aan de aanvrager/uitvinder

        Die vriend zal ook alleen een octrooi gekregen hebben voor rekenmachines die die methode toepassen. Rekenmachines volgens de oude methode, of volgens een andere nauwkeurige methode, vallen buiten het octrooi. Dus al is het octrooi voor iets kleins, who cares, er is geen schade voor de maatschappij, want ook de beschermingsomvang zal klein zijn er er zijn voldoende alternatieven.

        Het basisprincipe is dat iemand die iets bijzonders maakt, daar bescherming voor verdiend. In een democratie betekent dat dat de overheid dus een goede reden moet hebben om NIET een octrooi toe te kennen, niet dat de aanvrager een goede reden moet hebben om er wel een te krijgen (in de praktijk is het natuurlijk een balans, maar het principe blijft: wie erom vraagt en aan de wettelijke voorwaarden voldoet, krijgt een octrooi voor zijn uivinding, of die nu klein of groot is, economisch interessant of niet)

        1. Het probleem met veel huidige software patenten in de US is dat de stap van idee naar uitvoering niet inventief is. Neem (het nu niet meer mogelijke?) Slide to unlock. Gegeven: 1. de hardware; 2. het idee schuiven over het aanraakgevoeligescherm om te unlocken; Kan iedere kundige programmeur slide to unlock implementeren. Het is niet veel meer dan input van een touchscreen lezen en die data verwerken. De stap van idee naar uitvoering is niet inventief. Het idee is wel creatief en de graphics die je gebruikt kunnen best creatief zijn, maar daar hebben we auteursrechten voor.

          In het geval van die rekenmachine gaat het om wiskunde, dan vindt ik het al weer een stuk enger worden om te patenteren.

Geef een reactie

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren, <UL>/<OL> voor lijsten, en <em> en <strong> voor italics en vet.