Brevetti software: per chi sono utili?

di Caterina Bo


  1. La tutela del software

Un software, in italiano “programma per elaboratore”, è un insieme coerente di istruzioni che permettono di far eseguire delle operazioni ad un computer. Quando le istruzioni sono dirette a fornire all’utente finale la possibilità di eseguire una specifica funzione (ad esempio la scrittura di un testo, l’esecuzione di un calcolo), si preferisce parlare di applicazione o, come siamo ormai soliti chiamarle, di “app”.

Ai fini del presente contributo, è sufficiente sapere che il software viene “scritto” dal programmatore in un linguaggio informatico (detto appunto “linguaggio di programmazione”) e si presenta dunque come un testo in cui ciascuna sequenza di simboli corrisponde ad un comando/istruzione.

Poiché tuttavia un testo così fatto non è comprensibile da un elaboratore, le istruzioni scritte dal programmatore devono essere tradotte in linguaggio binario, cioè in sequenze di 0 e 1 (che naturalmente non sono invece comprensibili dagli esseri umani). Il codice comprensibile da un programmatore umano viene chiamato “codice sorgente”, mentre quello comprensibile alla macchina viene chiamato “codice oggetto”.

I software naturalmente hanno un valore economico che, a seconda della complessità delle funzioni che sono in grado di far svolgere ad un computer (si pensi ai programmi di computer grafica o ai videogiochi), può essere anche molto ingente. Come per le altre opere dell’ingegno umano, ci si è dunque chiesti in che modo poter garantire una remunerazione per l’attività di programmazione, dal momento che vi è una notevole sproporzione tra il tempo e lo sforzo impiegati nel scrivere un software e la facilità con cui è possibile riprodurlo da parte di un terzo.

La prima protezione che storicamente è stata conferita al software è quella del diritto d’autore, poiché, come anticipato sopra, il codice sorgente è scritto in un linguaggio che sembra comprensibile e riconducibile ad un testo[1]. Tale protezione è tuttavia limitata alla sola forma individuale dell’opera, ovvero alla specifica forma espressiva del singolo software.

Proprio per tale motivo, nel tempo le case produttrici (c.d. “softwarehouse”) hanno ritenuto di tutelare meglio i propri interessi distribuendo unicamente il codice oggetto – comprensibile solo dalla macchina – e di tenere invece “nascosto” il codice sorgente, proteggendolo quale segreto industriale (secondo livello di protezione). In questo modo, l’utente finale è in grado di ottenere l’esecuzione della funzione desiderata, poiché il computer esegue il codice oggetto, ma non è in grado di comprendere l’architettura del software stesso.

Infine, l’evoluzione giurisprudenziale ha evidenziato come la soluzione di un problema tecnico possa derivare tanto da un’invenzione meccanica quanto dall’esecuzione di un programma da parte di un computer. Di qui il terzo livello di protezione che insiste sul software, la tutela brevettuale, che approfondiremo nel prossimo paragrafo.

  1. Problematiche ed evoluzione giurisprudenziale della tutela brevettuale del software

Un brevetto è un diritto di sfruttamento in regime di monopolio di una originale soluzione ad un problema tecnico preesistente. La sua caratteristica principale è la limitazione nel tempo e nell’oggetto: il diritto di utilizzare in esclusiva la propria invenzione dura solamente venti anni e non è detto che comprenda un intero prodotto, poiché ha ad oggetto solamente ciò che, all’interno del prodotto stesso, può essere considerato strettamente “nuovo”.

A partire dagli anni ’90, la neocostituita Corte d’Appello per il Circuito Federale degli Stati Uniti, specializzata in materia brevettuale, ha iniziato a riconoscere con larghezza la tutela brevettuale al software. I giudici specializzati cioè hanno via via sempre più avallato la teoria che qualunque funzione pratica (come ad esempio l’operazione di conversione della valuta[2]) ottenibile mediante un programma informatico fosse tutelabile quale “invenzione implementata tramite computer[3]”.

La proliferazione di diritti di monopolio in ambito software ha tuttavia suscitato diverse perplessità.

Difatti, una volta che è stato concesso un brevetto su un particolare trovato tecnico, i soggetti che operano nel medesimo settore hanno due possibilità: o ottenere dietro pagamento l’autorizzazione ad usarlo (tramite una licenza), oppure sviluppare un’invenzione ulteriore e più sofisticata complementare e migliorativa dell’invenzione stessa (c.d. “invenzione di sviluppo”). La ratio di tale meccanismo viene comunemente ravvisata nell’incentivo all’innovazione derivante dalla certezza di un sicuro ritorno economico dei propri investimenti in ricerca, permettendo altresì che l’idea inventiva non resti segreta ma possa venire utilizzata liberamente una volta scaduto il periodo ventennale di protezione.

In un periodo storico dove la frontiera tecnologica avanza velocemente, tuttavia, una volta trascorso il periodo di tutela brevettuale l’oggetto del software rischia di essere obsoleto, di fatto neutralizzando la ragione stessa della concessione del monopolio. Il rischio è dunque che si creino delle barriere all’entrata nel mercato, che apparterrà al primo venuto e a quei pochi grandi attori economici in grado di potersi permettere di sostenere i costi di licenza, senza che tale situazione oligopolista abbia un contrappeso nella successiva libera utilizzabilità delle invenzioni protette.

Tali inconvenienti paiono particolarmente problematici nell’ambito dei software, dove a ben vedere la porzione innovativa delle soluzioni tecniche ottenute è spesso minima (specie per quei brevetti che si risolvono nella descrizione dell’esecuzione tramite computer di un trovato tecnico di per sé già conosciuto), ed è invece fondamentale il miglioramento e l’implementazione pratica della soluzione stessa (si pensi alla necessità di risolvere i c.d. “bug” che regolarmente si manifestano nell’utilizzo di un nuovo programma informatico), che tuttavia non sono oggetto di protezione brevettuale.

A ciò si aggiunga che spesso alcune funzioni informatiche non possono che essere espresse in un certo modo, e dunque l’insistenza di un brevetto su di esse comporta che tutti gli operatori del settore dovranno necessariamente acquisire la relativa licenza per poter elaborare software più complessi (c.d. standard tecnologici).

L’eccessiva larghezza con cui la Corte d’Appello per il Circuito Federale degli Stati Uniti ha ammesso la brevettabilità di soluzioni tecniche ottenute tramite l’esecuzione di un computer ha portato all’intervento della Corte Suprema statunitense nel 2014 in Alice Corp v. CLS Bank, che nel caso di specie ha dichiarato la mancanza di altezza inventiva di tutti i brevetti software azionati, in quanto radicalmente mancanti di innovatività e descrittivi di una mera idea astratta[4]

Sicuramente con tale sentenza la Corte Suprema ha inteso segnare un cambiamento di passo nel perimetro di tutela da riconoscere ai brevetti software, che è divenuto più ristretto. Una simile impostazione, benché parta da premesse molto diverse, è condivisa anche dagli uffici brevetti e dalle corti europee, che interpretando l’art. 52 della Convenzione sul Brevetto Europeo[5] sono giunte a riconoscere la concedibilità di brevetti ad invenzioni implementate tramite programmi per elaboratore solo qualora le stesse siano considerabili nuove, dotate di altezza inventiva e atte ad avere un’applicazione industriale.

  1. Stato dell’arte e conclusioni

Nonostante la giurisprudenza abbia mostrato saltuariamente di recepire le numerose critiche rivolte alla tutela brevettuale del software, è difficile immagine che le grandi softwarehouse – e per loro gli avvocati specializzati in materia – rinunceranno all’idea di ottenere un’esclusiva su una nuova applicazione. Ciò a maggiore ragione se si considera che attualmente la detenzione di un significativo “pacchetto software” è prerequisito e condizione per poter accedere al tavolo delle trattive e negoziare i c.d. crosslicensing, ovvero la reciproca concessione di famiglie di brevetti essenziali per l’elaborazione sinergica di tecnologie innovative. In effetti, i dati mostrano che i brevetti software generano una buona metà dei ricavi dell’industria tecnologica nel suo insieme[6].

Paradossalmente, l’esistenza in diversi ordinamenti di corti specializzate in materia, se da un lato costituisce un elemento positivo di velocizzazione e accuratezza delle decisioni, dall’altro rischia di eliminare la riflessione critica sulla opportunità di una tutela brevettuale del software in sé e per sé, che presuppone una valutazione complessiva degli interessi in gioco. È sempre più evidente, infatti, il rischio che la concessione di brevetti ad applicazioni di idee astratte eseguite da un computer possa portare alla creazione di ostacoli al progresso tecnologico – con pochi operatori interessati a capitalizzare la tecnologia già esistente e brevettata – anziché incentivarlo[7].

Astrattamente esistono già i correttivi adeguati ad evitare che ciò accada, perché la soluzione sviluppata dal brevetto dovrebbe essere non ovvia e contribuire significativamente a raggiungere un risultato tecnico prima non raggiungibile o raggiungibile in maniera molto più dispendiosa. Tali requisiti, tuttavia, devono essere applicati in maniera rigorosa dalle corti: il rischio è che, altrimenti, il sistema brevettuale diventi di fatto un freno, invece che un incentivo all’innovazione.


[1]https://eur-lex.europa.eu/legal-content/IT/ALL/?uri=celex%3A31991L0250 e https://www.normattiva.it/uri-res/N2Ls?urn:nir:stato:decreto.legislativo:1992-12-29;518!vig=. Attualmente i programmi per elaboratore sono menzionati tra le opere oggetto di tutela autorale dall’art. 2, n. 8 della L. 633/1941 (Legge Autore).

[2]https://arstechnica.com/features/2018/06/why-the-supreme-courts-software-patent-ban-didnt-last/

[3]https://uibm.mise.gov.it/index.php/it/brevetti/brevetto-per-invenzione-industriale/brevetti-e-software

[4]https://www.supremecourt.gov/opinions/13pdf/13-298_7lh8.pdf: “the relevant question is whether the claims here do more than simply instruct the practitioner to implement the abstract idea of intermediated settlement on a generic computer. They do not.”.

[5]https://fedlex.data.admin.ch/filestore/fedlex.data.admin.ch/eli/cc/2007/849/20130503/it/pdf-a/fedlex-data-admin-ch-eli-cc-2007-849-20130503-it-pdf-a.pdf.

[6]https://www.ipwatchdog.com/2022/03/21/us-patent-grants-fell-7-last-year-software-related-grants-remained-63/id=147745/

[7]https://arstechnica.com/features/2018/06/why-the-supreme-courts-software-patent-ban-didnt-last/.


Autore:

Caterina Bo

en_US