Europese softwareoctrooien: wie weet er een leuk, recent voorbeeld?

| AE 2255 | Intellectuele rechten | 12 reacties

Octrooi op software in Europa, het blijft een heikel punt van debat. (Minstens zo heikel trouwens als de debatten over downloaden en FTD, waarover elders). Mag het wel, mag het niet? En hoe erg is het nu eigenlijk?

Recent verscheen een artikel over softwareoctrooien waarin werd gesteld dat “uitsluiting op grond van die bepaling is vrij eenvoudig te voorkomen wanneer met de software een nieuw en innovatief technisch effect kan worden gerealiseerd”. Op zich klopt dat wel min of meer, maar die “wanneer” is wel cruciaal – en bovendien vrij lastig te behalen met een softwareoplossing, zo heb ik gemerkt. Maar verhalen zijn er genoeg over triviale octrooien en octrooien op pure softwaretechnieken.

Ik zou hier dan ook graag induiken maar omdat ik enigszins uitgeput ben van de hele week FTD verdedigen, zou ik deze keer graag eerst jullie een vraag willen stellen: wie weet er een mooi, recent voorbeeld van een verleend Europees octrooi dat we “softwareoctrooi” kunnen noemen?

Octrooien zoeken doe je via Esp@cenet. Vul “EPB” in in het veld “Publication number” zodat je alleen de verleende octrooien (“B-publicaties”) krijgt en niet ook alle aangevraagde maar (nog) niet verleende rommel.

Voor mij is recent iets dat in 2008 of later is toegekend. Helaas kun je daar niet op zoeken, want het veld “publicatiedatum” gaat uit van de publicatie van de aanvraag en niet van de toekenning. Maar met “EPB” en een paar slim gekozen trefwoorden vind je hopelijk wat leuks. Ik ben in ieder geval erg benieuwd!

Ik zal volgende week twee artikelen publiceren die ik schreef voor het jubileumboek van 100 jaar Rijksoctrooiwet. De titel “De puinhopen van het Europese softwareoctrooi” van het ene artikel geeft alvast een voorzetje voor de discussie. šŸ™‚

Arnoud

Deel dit artikel

  1. Enkele probleemetjes. Ten eerste, softwareoctrooien zijn nooit mooi šŸ™‚

    Ten tweede, er zijn te veel. Vul “xml” in in het veld “Keyword(s) in title or abstract” en alle resultaten zijn waarschijnlijk softwareoctrooien. Welke zou het “mooist” zijn?

    Ten derde, het gevaar van recente octrooien is vaak niet bekend. Normaal moeten we efkes wachten om de problemen te zien. Dus kan ik “EP 1 993 255 B1” antwoorden en je kan zeggen dat mijn voorbeeld toont dat recente softwareoctrooien niet gevaarlijk zijn omdat “EP 1 993 255 B1” is nog niet in een hof gebruikt. (Ik heb maar Claim #1 gelezen maar ik zie geen technisch effect.) Het hangt echt af van de definitie van “mooi”.

  2. Met “mooi” doel ik op iets dat je eenvoudig uit kunt leggen aan een zaal vol publiek. Geen geneuzel over een klein palletje achterin een XML schema, maar een concreet item: een interface die via XML wordt opgebouwd bijvoorbeeld.

    Ik was niet op zoek naar bewezen gevaarlijke octrooien. Wat ik wil onderzoeken, is of er nog “echte” softwareoctrooien (interfaces met XML, userinteractie an sich) worden verleend sinds die strenge jurisprudentie van een paar jaar terug.

    Ik heb je voorbeeld er even bijgepakt. Het gaat hier om een truc om een XML-bericht te beschermen tegen XML rewriting aanvallen. Zo te lezen is de truc dat je een hash van de pre-order traversal list maakt en die digitaal signeert. Zo kan een gemanipuleerd element snel worden gedetecteerd zonder dat je het hele XML-document moet encrypten en ook zonder dat whitespace verandering leidt tot een foute hash. Best slim op zich.

    Waarom is dit pure software? Is het beschermen van datacommunicatie tegen injecties en aanvallen niet “gewoon” techniek?

  3. Als het publiek weet wat CSS is dan misschien EP1661036B1? Anders is EP1299850B1 ook goed.

    Waarom is EP1993255 pure software? Maar, er is niks maar bits en hashen.

    Het is zoals ik zeg dat de eerste letters van de paragrafen en de aantal “e” in die reactie zijn AWHW68. Ik heb dus een datacommunicatie tegen injecties en aanvallen beschermd. Slim misschien maar er is geen technisch effect. Niks buiten de computer is verandered. Zelfs niks binnen de computer is echt veranderd.

    (Welke jurisprudentie vindt je streng?)

  4. Als ik nadenk over de wenselijkheid van software-octrooien, en het onderscheid tussen software- en andere octrooien, dan kom ik er meestal op uit dat alle soorten octrooien ongewenst en schadelijk zijn, maar dat het probleem extra schrijnend is voor software.

    Het verschil bij software is dat het vrijwel gratis is om nieuwe instanties te maken en verspreiden, en dat het relatief goedkoop is om nieuwe software te ontwikkelen. Deze eigenschap geeft software een enorme vrijheid en dynamiek, die door elk klein octrooi-licentiebedrag de kop in kan worden gedrukt.

    Als je graag een onderscheid wilt maken tussen software- en andere octrooien, dan zou ik dat op de volgende manier doen: als er software (of willekeurige andere configuratie-data) denkbaar is die je kunt verspreiden als computerbestand, die bij installatie een apparaat kan veranderen van een apparaat dat geen inbreuk maakt op het octrooi in een apparaat dat wel inbreuk maakt op het octrooi, dan is het betreffende octrooi een software-octrooi.

    “het beschermen van datacommunicatie tegen injecties en aanvallen” kan je op verschillende manieren doen. Als je methode bestaat uit een heel goede innovatieve kluis waar je een USB-stick in kunt doen, dan is het gewone techniek. De beschreven methode voor XML-bestanden is software.

    Merk op dat volgens mijn definitie een heleboel elektronica ook potentieel ‘software’ is, door het bestaan van FPGA’s. Wat mij betreft is dit gewenst. Als programmeerbare radio-hardware een beetje populair wordt, dan mogen wat mij betreft alle octrooien over het versturen van beeld/geluid/data over radiogolven ook de prullenbak in.

    Als je nou een duidelijke, techniek-onafhankelijke wet wilt die wel normale maar geen software-octrooien accepteert, dan zou je elke technische methode als octrooieerbaar kunnen accepteren, met als uitzondering dat data-bestanden (incl. software) nooit inbreuk maken, en dat samenstellingen van niet-inbreukmakende, hardware met bepaalde data geen inbreuk maken, zelfs als de combinatie van hardware en data wel een implementatie vormt van de geoctrooieerde techniek.

    Dat is, als je ?berhaupt octrooien wilt hebben. Er zijn genoeg historische voorbeelden te vinden waaruit blijkt dat octrooien een remmende invloed hebben op de ontwikkeling van de techniek. Dit geldt dus niet alleen voor software, maar ook voor ‘gewone’ techniek.

  5. Je bedoelt iets zoals Method for synchronizing access to a shared resource, corresponding device, storage means, and software program therefore? Gepubliceerd in 2010, betreft een techniek om in software de toegang tot bepaalde resources te beveiligen. Hoewel er ook gesproken wordt over hardware is het een techniek die zo’n beetje standaard is sinds de uitvinding van multi-threaded applicaties. šŸ™‚ Het gaat er ook alleen maar om hoe de software reageert als de toegang to een resource (geheugen, bestand, poort) al in gebruik is. Hoe kan ik zien of deze ook daadwerkelijk verleend is?

  6. @Wim: je kunt zien of iets verleend is omdat er een “B1” bij het informatieveld staat:

    Publication info: EP2175368 (A1) – 2010-04-14 EP2175368 (B1) – 2010-07-14

    Er is dus op 14 juli een octrooi verleend voor deze uitvinding. Het enige onhandige is dat je dan apart door moet klikken naar de B1 publicatie om te zien wat er precies in het verleende octrooi staat. Normaal krijg je namelijk alleen de gepubliceerde aanvraag zelf te zien.

    In dit geval is er verleend:

    A method for synchronizing access to a shared resource between at least two threads of execution, the method comprising the steps of retrieving (103) a request message from a queue (212) and, based on the request message, accessing (104) the shared resource, characterized in that the method comprises the precursory steps of checking (101), in a first thread of execution, whether the shared resource is locked by a further thread of execution and, in response to the shared resource being locked by the further thread of execution, enqueueing (102) the request message by the first thread of execution, and upon enqueueing the request message, terminating the first thread of execution, wherein the first thread of execution and the further thread of execution run interrupt handlers, the request message is retrieved (103) by the further thread of execution upon unlocking the shared resource and the shared resource is accessed (104) by the further thread of execution based on the request message.
    Wie me hier het praktisch nut van kan uitleggen, mag het zeggen.

  7. Het practische nut van dit patent? Simpel… Computers kunnen meerdere dingen tegelijkertijd uitvoeren. Dit gebeurt via threads. Daarbij kan het gebeuren dat meerdere threads dezelfde resource willen benaderen. Een resource kan een stukje data zijn in het geheugen, een bestand op de schijf, een poort naar een geluidskaart of printer, of iets anders. Als twee threads tegelijkertijd deze resource benaderen dan vindt er al snel een conflict plaats. Vergelijk het maar met een Word document die door twee gebruikers tegelijkertijd open is en beiden maken steeds aanpassingen en slaan deze op. Dan krijg je steeds dat de wijzigingen van de een de weijzigingen van de ander ongedaan maken. Dus moet je zorgen dat er een soort synchronisatie plaats vindt.

    En daar is dit dan voor.

    Het lijkt mij overigens een toepassing voor binnen het besturings-systeem zelf. Windows heeft daar dus al Critical Sections voor, maar Windows is niet het enige besturings-systeem. Nu er vooral ook mobiele telefoons en andere gadgets van allerlei besturings-systemen worden voorzien heeft het vastleggen van dit patent mogelijk te maken met dergelijke, alternatieve besturings-systemen. Dit soort technieken zijn er al in diverse varianten en zijn vaak ook afhankelijk van het precieze doel. In Windows krijg je dan b.v. te maken met Critical Sections, mutexen, Semaphores en nog meer van dat soort multi-threading ondersteuning. Dit patent geeft een alternatieve oplossing voor dit probleem en ik vraag mij zelfs af hoe uniek dit is. Maar er zit dus kennelijk wel een patent op…

    Het is overigens een variant op een techniek die al tientallen jaren wordt gebruikt. Terwijl je dit leest op je scherm is je computer al massaal bezig om the multi-threaden en dus een andere techniek te gebruiken voor hetzelfde resultaat. Vanuit dat oogpunt lijkt het mij een waardeloos patent maar ik vermoed dat er toch meer achter zit…

    Misschien dat ze nu de makers van enkele besturings-systemen eens op kosten gaan jagen door te claimen dat hun patent wordt geschonden. Wie weet?

  8. Er is een heel aardig boek, “Math you can’t use,” door Ben Klemens, maar dat gaat vrijwel uitsluitend over de Amerikaanse situatie. Gezien dat bijvoorbeeld een open source videospeler als VLC in Europa compleet met allerlei “gepatenteerde” uitvindingen erin gewoon op een publieke site beschikbaar is, wordt hier de soep blijkbaar iets minder heet opgediend.

    In ieder geval laat het boek een beetje de rampspoed zien die octrooien op software veroorzaken, en waarom dat zo is.

    Ikzelf ben ervan overtuigd dat alle vormen van octrooien verwerpelijk zijn, omdat zij de technische en economische vooruitgang hinderen — alle bezweringen van het tegendeel ten spijt, en dat dit met name evident wordt in software, omdat hier het onderscheid tussen een (traditioneel niet patenteerbare) idee en de (traditioneel wel patenteerbare) uitwerking ervan, dat is de uitvinding, compleet vervaagt is.

    Een software engineer die per ongeluk een keer een software patent onder ogen krijgt zal over het algemeen eerst eens goed moeten nadenken wat er staat. De taal staat over het algemeen behoorlijk ver af van wat in die wereld gebruikelijk is.

  9. Het bewijs is te leveren door het besturings-systeem van je concurrent te “reverse engineeren”. Maar het werkt natuurlijk ook goed tegen al die nieuwe, open-source besturings-systemen zoals Linux en Android waar iedereen gewoon de broncode kan nakijken. De iPad en vergelijkbare tablets, plus de iPhone en andere mobiele telefoon-systemen maken allemaal gebruik van besturings-systemen met multi-threading mogelijkheden waar dit soort technieken best handig zijn. Alcatel-Lucent is aktief op het gebied van software voor de mobiele industrie dus dit patent geeft hen een stevig houvast in deze markt. Je moet wel een beetje buiten het gebied van de normale PC denken maar het gaat hierbij gewoon om software voor “intelligente apparatuur”.

  10. Op het artikel op boek9.nl is inmiddels een reactie verschenen:

    Inderdaad is het zo dat de uitsluitingsbepaling op basis van de jurisprudentie van de kamers van beroep eenvoudig kan worden omzeild. (…)

    Waar het natuurlijk om gaat is dat de volgende hindernis, namelijk die van de inventiviteit, in zeer veel gevallen aanmerkelijk meer problemen geeft. Uit bovengenoemde beslissingen, die door de Enlarged Board of Appeal in G 03/08 lijken te worden gesanctioneerd, is duidelijk dat alleen technische maatregelen aan de inventiviteit van de uitvinding kunnen bijdragen. De niet-technische maatregelen worden niet meegenomen in de beoordeling van de inventiviteit. Het probleem is dat voor veel ICT bedrijven de ???crux??? van hun software vaak juist op dat niet-technische gebied ligt.

Laat een reactie achter

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

(verplicht)

Volg de reacties per RSS