Come e quando brevettare un software in Italia e in Europa

Una guida ragionata per capire quando il software è brevettabile, come funziona il brevetto per software in Europa e quali alternative esistono per proteggere algoritmi, app e interfacce.

Nei corridoi degli studi legali, negli uffici R&D e nelle stanze delle startup la stessa domanda torna ciclicamente: posso brevettare il mio software? È una domanda che sembra semplice ma spalanca subito una trama normativa densa, nella quale ogni parola pesa.
Nel sistema europeo la legge esclude esplicitamente una categoria ben precisa: i “programmi per elaboratore in quanto tali”, cioè i programmi software considerati solo come codice o sequenza d’istruzioni, senza alcun contributo tecnico ulteriore. È l’espressione utilizzata dall’articolo 52, paragrafo 2, della Convenzione sul Brevetto Europeo (EPC) e dall’articolo 45, comma 2, del Codice della Proprietà Industriale (CPI). Eppure esistono casi in cui proprio un software diventa il cuore di una domanda di brevetto.
La vera questione diventa allora: dove passa il confine tra ciò che può essere tutelato come invenzione e ciò che deve restare affidato solo al diritto d’autore?
 

L’esclusione non è assoluta

La Convenzione sul Brevetto Europeo, nel momento in cui esclude i programmi per elaboratore “in quanto tali”, non chiude affatto la porta alle cosiddette invenzioni implementate tramite computer (Computer Implemented Inventions). La giurisprudenza dell’Ufficio Europeo dei Brevetti (EPO) e le decisioni più recenti in ambito europeo insistono su un’idea chiave: un software può essere oggetto di brevetto se produce un effetto tecnico ulteriore rispetto al semplice funzionamento standard del computer.
Questo effetto deve essere concreto, verificabile, collegato alla soluzione di un problema tecnico reale e non semplicemente ad una scelta organizzativa o commerciale. In molti casi è utile poterlo esprimere anche attraverso parametri tecnici o miglioramenti quantificabili ma, più che la misurazione in sé, conta che il contributo si traduca in una soluzione tecnica riconoscibile rispetto alle soluzioni note.
Chi lavora in azienda vede bene la differenza: per esempio un codice che introduce un nuovo meccanismo di gestione della memoria e rende il processore più reattivo, ha una valenza tecnica ben diversa da una semplice macro che ordina fatture. Un programma che dialoga con i sensori di un impianto o di un sistema frenante e regola in automatico il comportamento della macchina, non è solo un insieme di calcoli ma modifica concretamente ciò che accade fuori dallo schermo. Allo stesso modo un algoritmo che rielabora segnali o immagini migliorando la qualità del dato in ingresso, si colloca sul piano delle soluzioni tecniche, non delle sole astrazioni matematiche.

Al contrario restano fuori dal terreno brevettabile gli algoritmi che si limitano a calcolare profitti, gestire flussi amministrativi, proporre raccomandazioni commerciali sulla base di regole note o replicare passaggi mentali astratti. Qui il contributo riguarda il modo di fare impresa o di presentare informazioni, non il funzionamento tecnico di un apparato e l’articolo 45 CPI considera queste attività estranee alla nozione d’invenzione.

È utile ricordare che la tutela brevettuale è riservata a soluzioni che abbiano carattere tecnico e che rispettino i tre requisiti classici: novità ai sensi dell’articolo 46 CPI; attività inventiva ai sensi dell’articolo 48; applicabilità industriale ai sensi dell’articolo 49. Il software non sfugge a queste condizioni, ma deve presentare qualcosa di più della semplice automatizzazione di procedure già note.
 

Diritto d’autore e brevetto: due tutele distinte e complementari

Molti sviluppatori e anche molti imprenditori trascurano un dato fondamentale: il software è già protetto fin dal momento della sua creazione dal diritto d’autore: infatti la legge 22 aprile 1941, n. 633, all’articolo 2, numero 8, include espressamente i programmi per elaboratore tra le opere dell’ingegno protette, in qualsiasi forma siano espressi, purché originali. Questo significa che il codice sorgente, l’eventuale codice oggetto, il materiale preparatorio e persino certi output audiovisivi possono beneficiare della tutela autoriale.
Le interfacce utente, invece, non sono di regola protette come “programma per elaboratore” in senso stretto, ma possono essere tutelate come opere dell’ingegno (ad esempio opere grafiche) quando presentano un sufficiente grado di creatività.

La protezione però riguarda la forma espressiva, non l’idea tecnica sottostante: se un concorrente sviluppa un software diverso che realizza lo stesso effetto tecnico senza copiare codice o materiale protetto, il diritto d’autore può fare ben poco. È qui che il brevetto offre una leva ulteriore: non difende il modo in cui il programma è scritto, ma il metodo implementato.
Ecco spiegato perché due software basati su linguaggi diversi, se attuano lo stesso procedimento tecnico, possono rientrare nella medesima sfera di protezione brevettuale.

Di fatto, per chi progetta strategie di tutela, il modo più efficace di ragionare è considerare il diritto d’autore come lo strumento di difesa sulla “pelle” del software e il brevetto come la protezione sul suo “scheletro” tecnico. Quando entrambe le componenti sono presidiate, la posizione dell’impresa nei confronti di terzi si rafforza sensibilmente.
 

Il nodo dell’effetto tecnico

Le Linee guida dell’EPO e le prassi degli uffici IP europei insistono su un aspetto: l’effetto tecnico non è un’etichetta generica ma deve emergere chiaramente dalla domanda. Può essere esterno al computer, come nel controllo di un processo industriale; nel pilotaggio di un dispositivo medico; nella regolazione intelligente di un impianto. Oppure può essere interno, quando l’algoritmo migliora la gestione delle risorse; riduce i tempi di elaborazione; introduce nuove modalità di organizzazione della memoria o di trattamento dei dati che abbiano impatto reale sul funzionamento della macchina.

Questo effetto tecnico va però raccontato bene: nel testo brevettuale non basta dire che il software “ottimizza” o “migliora” qualcosa; occorre spiegare in termini tecnici come il programma interagisce con componenti fisici o logici, quali passaggi di calcolo mette in atto, quali risultati tecnici riconoscibili o quantificabili produce rispetto alle soluzioni note.
Diagrammi a blocchi, flussi logici, descrizioni architetturali non sono un orpello formale ma la chiave perché un esaminatore possa riconoscere la differenza rispetto allo stato della tecnica.
 

Cosa non è brevettabile: esempi borderline

Nella pratica non sono rari i casi in cui una domanda di brevetto per software viene respinta perché il contributo tecnico è giudicato inesistente o troppo modesto. Accade per molte soluzioni che si limitano a riprodurre in forma automatizzata flussi decisionali umani già noti. Accade quando l’unico elemento “nuovo” è il modello di business incorporato nel software. Accade ancora quando l’invenzione si riduce a un miglioramento puramente estetico dell’esperienza utente, senza un vero cambiamento nel funzionamento della macchina o nel modo in cui l’utente porta a termine un compito tecnico.
Fanno eccezione solo quei casi in cui la struttura dell’interfaccia utente contribuisce in modo credibile all’esecuzione di un compito tecnico (per esempio riducendo errori nell’utilizzo di un dispositivo di controllo o rendendo più sicure determinate operazioni su un impianto) perché, in situazioni del genere, anche alcune scelte di UI possono assumere rilievo tecnico.

Ad ogni modo, la prassi dell’EPO lo ribadisce con chiarezza: serve un effetto tecnico che vada oltre la normale interazione hardware-software. Se il cuore dell’idea è economico, organizzativo, di marketing, ci si sta muovendo fuori dal terreno delle invenzioni anche se la realizzazione avviene tramite codice.
 

Come si deposita un brevetto software

Un fraintendimento frequente riguarda il contenuto della domanda di brevetto: molti immaginano di dover depositare il codice sorgente; nella realtà il codice non viene allegato ed è spesso preferibile mantenerlo come know-how o segreto industriale. La domanda deve contenere invece una descrizione tecnica completa dell’invenzione sufficiente a permettere ad un esperto del settore di riprodurla, come richiedono l’articolo 51 CPI e l’articolo 83 EPC.
A questa descrizione si affiancano una o più rivendicazioni che definiscono l’oggetto della protezione e i disegni o diagrammi necessari a comprendere il funzionamento del sistema.

Le rivendicazioni, in concreto, descrivono la soluzione sotto forma di metodo, di sistema o di cosiddetto computer-program-product: un programma per elaboratore che, quando eseguito su un computer o memorizzato su un supporto leggibile dalla macchina, attua il metodo rivendicato.
Su questa base l’Ufficio Italiano Brevetti e Marchi (UIBM), nel caso del deposito nazionale, o l’EPO, per il brevetto europeo, valutano la presenza dei requisiti di brevettabilità.
Per chi sceglie la via europea, il pacchetto normativo sul Brevetto Unitario offre la possibilità di ottenere una protezione unitaria in un numero ampio di Stati membri, opzione che per i software ad alto potenziale commerciale può essere molto interessante in termini strategici e di costi complessivi.
 

Quali alternative se il brevetto non è possibile

Quando il software non presenta un contributo tecnico sufficiente, oppure non supera i requisiti di novità e attività inventiva, il diritto d’autore resta la prima linea di difesa. La registrazione facoltativa del programma presso la SIAE consente di attribuire una data certa all’opera e di rafforzare la posizione del titolare in caso di contenzioso, soprattutto se il codice è stato diffuso solo in forma eseguibile.
Accanto a questo, il segreto industriale disciplinato dall’articolo 98 CPI permette di proteggere algoritmi e architetture non note al pubblico finché permangono ragionevoli misure di riservatezza.

Per le interfacce grafiche e gli aspetti estetici del software, la registrazione di disegni e modelli a livello nazionale o a livello di design EU, secondo il Regolamento (CE) n. 6/2002 sui disegni e modelli comunitari modificato dal più recente intervento dell’Unione europea, offre una tutela specifica sull’aspetto esteriore, inclusi i layout e gli elementi grafici delle interfacce.

Accanto agli strumenti di proprietà intellettuale, resta fondamentale curare gli aspetti contrattuali con sviluppatori, fornitori e partner, prevedendo accordi di riservatezza e una chiara disciplina dei diritti di utilizzo. È spesso questa combinazione di misure, più che il solo brevetto, a fare davvero la differenza nella protezione del software.