Nella mia esperienza, spesso mi sono trovato ad esaminare casi di brevetto di software. In questo post, esaminiamo alcuni dei principi generali in materia e cercheremo di rispondere alla domanda: si può brevettare un programma?
Brevetto di software: la convenzione di monaco sul brevetto europeo
Il punto di partenza di ogni riflessione in materia è costituito dall’art. 52 della Convenzione di Monaco sul Brevetto Europeo. La disposizione richiamata sostanzialmente esclude la brevettabilità dei programmi per computer [..] nella misura in cui la domanda di brevetto concerna uno di questi elementi, considerato in quanto tale.
Che cosa significa?
Sostanzialmente, alla luce della Convenzione di Monaco sarebbe esclusa la brevettabilità di un software, nella misura in cui sia l’oggetto esclusivo della domanda.
Cerchiamo di fare un esempio:
supponiamo di creare un semplicissimo programma di calcolo di una somma con Javascript. Il nostro codice sorgente potrebbe essere:
<script type=”text/javascript“>
function somma (a,b) {
return a+b;
}
alert(somma(3,5));
In sostanza, abbiamo creato un programma, cioè una sequenza di istruzioni che, trasmesse ad un elaboratore, consentano di raggiungere un obiettivo determinato. Nel caso di specie, abbiamo chiesto al nostro elaboratore di sommare due numeri 3 e 5 e di restituirci sotto forma di popup il relativo risultato.
Potremmo mai depositare una domanda di brevetto che si fonderà esclusivamente sulla funzione somma?
Anche il lettore più a digiuno di diritto della proprietà intellettuale, probabilmente, risponderebbe di no, dicendo “non si può brevettare una somma”. Tralasciamo che la somma in quanto tale è un metodo matematico anch’esso escluso dalla brevettabilità dall’art. 52 della Convenzione di Monaco e concentriamoci sul programma.
Modifichiamo il nostro programma:
<script type=”text/javascript“>
function somma (a,b) {
return a+b;
var x = 8;
var y = 12;
var somma = somma(x,y);
if (somma < 20) {
alert(“emetti luce“);
} else {
alert (“non fare nulla“);
}
Abbiamo inserito una struttura di controllo (un classico ciclo if – else). Immaginiamo che il sistema effettui un controllo e se il valore della variabile somma (ossia il risultato della somma delle variabili x e y) sia inferiore a 20, il sistema dovrà emettere una luce, altrimenti il sistema non dovrà fare nulla.
Se applicassimo questo principio ad una macchina per l’emissione di radiazioni nocive, potremmo escluderne immediatamente la brevettabilità?
Il nostro lettore, qui, probabilmente inizierebbe ad avere qualche dubbio. Potrebbe dire “effettivamente qui c’è un qualcosa di più”!
Eccoci dunque giunti ad un primo risultato.
Un sistema complesso, in cui il software è un elemento (anche preponderante) di un processo tecnico (nel caso di specie si tratta di un sistema di controllo per emissione di radiazioni nocive) non può essere inteso come “programma per computer in quanto tale” e quindi potrebbe essere brevettabile.
Il brevetto di software: l’effetto tecnico ulteriore
Il medesimo ragionamento sopra esposto è stato effettuato dalle Commissioni Tecniche dell’Ufficio Europeo Brevetti che, sostanzialmente, hanno “limitato” la portata del divieto di cui all’art. 52 della Convenzione a quei trovati che mirassero ad ottenere un diritto esclusivo su di un insegnamento astratto, incapace di produrre alcun effetto tecnico ulteriore.
Per effetto tecnico ulteriore (anche denominato “Contribution Approach”), in un primo momento si era intesa o l’alterazione e/o trasformazione di un oggetto esterno al sistema informatico stesso, prodotta attraverso le istruzioni impartite dal programma oppure la messa a punto di una nuova modalità di funzionamento del sistema tecnico completo, grazie alla interazione tra software e hardware.
Questo è stato l’approccio seguito, ad esempio, nelle decisioni Vicom (15 luglio 1986) e Kock & Sterzel (21 maggio 1987).
In sintesi, con la prova del contributo tecnico, le commissioni di ricorso escludevano che ci si trovasse in presenza di un “software in quanto tale” e, di fatto, veniva superato il divieto sopra citato di cui all’art. 52 della Convenzione di Monaco sul Brevetto Europeo.
Il brevetto di software: i più recenti orientamenti delle Commissioni Tecniche
Negli ultimi anni, le Commissioni Tecniche hanno, parzialmente, aggiustato il tiro. Più che cercare il “contributo tecnico” a monte, hanno iniziato ad affrontare la questione da un diverso punto di vista.
In primo luogo, hanno esteso la nozione di carattere tecnico dell’invenzione (caso Hitachi/Auction Method T 258/03), affermando che, in sostanza, l’utilizzo di mezzi tecnici varrebbe sempre a conferire carattere tecnico al trovato, con la sola esclusione di concetti e nozioni puramente astratte e prive di qualunque implicazione tecnica.
Secondo questa nuova impostazione, quindi, il semplice fatto di utilizzare un computer e, più in generale, un apparecchio programmabile escluderebbe, in radice, il riconoscimento di un software in quanto tale.
Quindi si è lasciato campo libero al brevetto di software?
Assolutamente no, l’Ufficio – pur avendo ampliato la nozione di “invenzione brevettabile” e di “problema”– continua ad applicare in modo molto restrittivo i requisiti di “altezza inventiva” e di “originalità”.
“In buona sostanza, l’effetto tecnico ulteriore che era uscito dalla porta, rientra dalla finestra“.
Il contributo o effetto tecnico è anche oggi un elemento centrale per la brevettabilità di un software (o meglio di un’invenzione implementata attraverso un software).
L’unica differenza rispetto al passato è che il giudizio si sposta dal piano della possibilità di individuare una invenzione brevettabile (un pre-requisito, potremmo dire) a quello di valutarne l’”originalità” e l’”altezza inventiva” (ossia, i classici requisiti richiesti per la concessione del brevetto.).
Ad esempio, la Commissione ha sostenuto (caso T 0336/07) che si avrebbe un trovato provvisto di originalità ed altezza inventiva in presenza di una combinazione tra elementi tecnici ed elementi non tecnici (ossia il software) che producano dei vantaggi ulteriori rispetto a quelli che vengono generati esclusivamente dalle entità non tecniche.
Cosa vuol dire tutto ciò?
Torniamo, in buona sostanza, al punto da cui siamo partiti. La prassi dell’EPO in materia di software è molto “oscillante”. Dovendo formulare una risposta in via generale potremmo dire che:
Con elevata probabilità non sarà brevettabile un trovato in cui, attraverso l’ausilio del software, si ottengano solo dei vantaggi in termini di migliore gestione e/o efficienza delle informazioni (si tratta dei tipici e connaturati vantaggi connessi con l’utilizzo delle tecnologie dell’informazione, ma non costituiscono una soluzione tecnica ed originale di un determinato problema).
Ad esempio, nel caso T1755/2010, con decisione del 6 novembre 2014, è stata esclusa la brevettabilità di un metodo per la determinazione di “commissioni” nei confronti di una pluralità di destinatari.
La Commissione, in buona sostanza, aveva rilevato che:
- L’obiettivo era quello di incentivare gli agenti di vendita, attraverso un migliore sistema di remunerazione (obiettivo di natura commerciale e non tecnica)
- Il semplice utilizzo di un linguaggio di programmazione per modificare lo stato interno della memoria di un computer non vale ad attribuire “carattere tecnico” al trovato;
- In assenza di un “effetto tecnico ulteriore”, il semplice utilizzo di un software non consente la concessione di un “brevetto”.
Con buona probabilità potrebbe, invece, essere brevettabile un trovato in cui il software, pur rappresentando un elemento non tecnico, contribuisca assieme all’apparato tecnico a risolvere in modo tecnico ed originale un determinato problema.
Ad esempio, nel caso T0690/2011, con decisione del 1 marzo 2016, è stato concesso un brevetto con riferimento ad un sistema informatico per la dialisi, composto di un dispositivo con schermo, un server web e un browser web. Più nel dettaglio, il browser aveva la funzione di far visualizzare a schermo (sul dispositivo) una serie di informazioni utili a guidare un operatore nell’avvio di un trattamento di dialisi, illustrandone anche il progresso.
In questo caso, è stato ritenuto che la presentazione di informazioni concernenti le procedure di set-up di un trattamento di dialisi unitamente, poiché direttamente collegate agli input dell’operatore umano con riferimento al trattamento in questione e, quindi, all’interazione tra il sistema di dialisi e l’operatore, non potevano essere considerate come prive di un carattere tecnico.
Come ulteriore esempio, possiamo citare il caso T 0979/06, dove, con decisione del 21 settembre 2010, è stato concesso un brevetto per un metodo e un apparato per ridurre lo sfarfallio di una sequenza video registrata attraverso una videocamera.
In conclusione: si può richiedere un brevetto di software? La risposta, alla luce della prassi EPO, può essere positiva, ma solo a condizione che il programma faccia parte di un sistema più complesso finalizzato a fornire una soluzione tecnica ed innovativa ad un determinato problema. La soluzione tecnica, tuttavia, non potrà consistere, come già detto, nel semplice utilizzo di un computer.
L’immagine del post è realizzata da Hades2k
