Algoritmi da brevettare: dove finisce il codice e dove inizia l'invenzione
Un algoritmo è brevettabile quando produce un ulteriore effetto tecnico applicato a un campo della tecnica, non quando si limita a eseguire una sequenza di operazioni matematiche o logiche. Questo criterio, codificato nelle linee guida dell’EPO e richiamato dal Codice della proprietà industriale, distingue un software proteggibile solo dal diritto d’autore da un’invenzione attuata per mezzo di computer. Nei paragrafi seguenti chiariamo come riconoscere questa soglia e come tradurla in una domanda di brevetto solida.
In breve:
L’algoritmo deve produrre un effetto tecnico ulteriore che agisce su una grandezza fisica o tecnica e risulta verificabile indipendentemente dall’utente per essere brevettabile.
I modelli di intelligenza artificiale contribuiscono al carattere tecnico solo se applicati a una soluzione tecnica concreta o adattati a un contesto tecnico specifico, come il monitoraggio biometrico.
Un algoritmo che controlla un dispositivo fisico, elabora segnali o ottimizza risorse hardware può superare il test tecnico, mentre metodi commerciali o linguistici restano esclusi.
La brevettabilità richiede di collegare chiaramente l’algoritmo a una grandezza tecnica misurabile e di descrivere dettagliatamente questa relazione per l’esame.
La distinzione tra tutela con diritto d’autore e brevetto si basa sul fatto che il brevetto protegge la soluzione sottostante, indipendentemente dal codice, e richiede una descrizione esaustiva di un effetto tecnico riproducibile.
Indice
Che cosa dice il diritto su software e algoritmi brevettabili
Dove finisce il codice e dove inizia l’invenzione da proteggere
Errori comuni e segnali d’allarme nelle domande su algoritmi
Perché affidarsi a competenze legali e tecniche specialistiche
Cosa insegna la giurisprudenza sul confine tra codice e invenzione
Le implicazioni etiche e di policy della brevettabilità degli algoritmi
Che cosa dice il diritto su software e algoritmi brevettabili
Il punto di partenza normativo è duplice. A livello europeo, l’articolo 52 della Convenzione sul brevetto europeo esclude dalla brevettabilità i programmi per elaboratore «in quanto tali». A livello italiano, l’articolo 45 del Codice della proprietà industriale, introdotto dal decreto legislativo 10 febbraio 2005, n. 30, ripete la stessa esclusione per i programmi per elaboratore considerati nella loro astrazione. L’elemento chiave è l’inciso «in quanto tali»: un algoritmo resta fuori dalla tutela brevettuale solo finché rimane un’idea matematica priva di applicazione tecnica concreta.
Le linee guida EPO G II 3.6 definiscono con precisione quando questa soglia viene superata: un programma per elaboratore produce un «ulteriore effetto tecnico» quando, eseguito, genera un risultato che va oltre la normale interazione fisica tra software e hardware. Gli esempi citati nel testo includono il controllo di un sistema ABS, la compressione video e il miglioramento della qualità di un segnale. In questi casi l’algoritmo non è più un’astrazione: diventa il cuore funzionale di un dispositivo o di un processo tecnico misurabile.
La giurisprudenza delle commissioni di ricorso EPO ha affinato ulteriormente questo confine. Le sintesi di case law pubblicate dall’ufficio riportano decisioni come T 702/20 e T 761/20, nelle quali rivendicazioni formulate in termini puramente astratti, senza un impiego tecnico concreto e verificabile, sono state respinte. Il principio emerso è coerente: non basta descrivere un metodo computazionale efficace, occorre dimostrare che quel metodo risolve un problema tecnico specifico, misurabile con parametri oggettivi come velocità di elaborazione, consumo di memoria o accuratezza di un segnale.
Risolvere un «problema tecnico», nel linguaggio degli esaminatori, significa qualcosa di molto concreto:
L’algoritmo deve agire su una grandezza fisica o tecnica, come un segnale, una risorsa hardware o un parametro di sistema.
Il risultato ottenuto deve essere riproducibile e verificabile indipendentemente dalle preferenze soggettive dell’utente.
Il contributo non tecnico, come una regola commerciale o un criterio puramente linguistico, non può da solo fondare l’attività inventiva.
Un dato da trattenere: secondo le linee guida EPO G II 3.6, la presenza di un effetto tecnico ulteriore è il criterio che separa un’invenzione attuata per mezzo di computer da un semplice programma escluso dalla tutela, ed è su questo principio che si fonda l’intero impianto di esame delle domande software in Europa.
Un capitolo a parte riguarda l’intelligenza artificiale e il machine learning. Le linee guida EPO G II 3.3.1 chiariscono che i modelli di apprendimento automatico sono di natura astratta, ma possono contribuire al carattere tecnico di un’invenzione quando vengono applicati a una soluzione tecnica specifica o adattati a un’implementazione tecnica particolare. Anche le fasi di addestramento del modello possono assumere rilevanza tecnica, se collegate direttamente allo scopo tecnico perseguito. Questo significa che una rete neurale generica, descritta in astratto, non supera l’esame; una rete neurale addestrata e configurata per il monitoraggio biometrico in un dispositivo medico, invece, può farlo.
Esempi concreti: quali algoritmi superano il test tecnico
Capire la teoria aiuta fino a un certo punto: la distinzione tra codice escluso e invenzione brevettabile diventa chiara solo osservando casi reali.
Controllo di dispositivi fisici. Un algoritmo che regola la frenata antibloccaggio di un veicolo agisce su un parametro fisico misurabile, la decelerazione della ruota, e produce un effetto tecnico diretto: questo tipo di rivendicazione si traduce bene in un claim di metodo o di dispositivo.
Compressione dati e segnali. Un metodo che riduce la dimensione di un file video mantenendo una soglia di qualità definita incide su risorse tecniche concrete, come banda e memoria, ed è tra gli esempi più ricorrenti citati dalle linee guida EPO.
Ottimizzazione della gestione delle risorse hardware. Un algoritmo che riorganizza l’allocazione della memoria cache in funzione del carico di lavoro del processore agisce sull’architettura del sistema, non su una preferenza d’uso, e per questo tende a superare l’esame di tecnicità.
Crittografia applicata a un fine tecnico specifico. Un metodo di cifratura progettato per proteggere la comunicazione tra sensori IoT in tempo reale, con vincoli di latenza misurabili, dimostra un contributo tecnico concreto.
Elaborazione di segnali medici. Un algoritmo che filtra il rumore da un tracciato elettrocardiografico per isolare un’anomalia clinica agisce su un segnale fisico e produce un effetto tecnico diagnostico riproducibile.
Sul fronte opposto, alcuni algoritmi restano quasi sempre esclusi. Un metodo per ottimizzare una strategia di prezzo in un marketplace, per quanto sofisticato matematicamente, resta un metodo commerciale: manca l’interazione con una grandezza tecnica. Allo stesso modo, un sistema di traduzione automatica valutato solo sulla qualità linguistica del testo prodotto, senza un collegamento a un problema tecnico come la latenza di elaborazione o l’integrazione hardware, rischia di essere trattato come un metodo linguistico in quanto tale. Anche le simulazioni numeriche pure, prive di un collegamento a un’interazione fisica o a un dispositivo reale, sono tra le candidate più deboli, salvo quando riproducono un fenomeno fisico con un livello di dettaglio e un’applicazione che un esaminatore può riconoscere come tecnica.
Un consiglio: quando descrivete un algoritmo, indicate sempre la grandezza fisica o tecnica su cui agisce e il parametro misurabile che migliora: è quel collegamento, più della complessità del codice, a convincere l’esaminatore.
Dove finisce il codice e dove inizia l’invenzione da proteggere
Il diritto d’autore tutela l’espressione del codice sorgente, cioè la forma specifica in cui le istruzioni sono scritte: variabili, struttura dei file, commenti, organizzazione delle funzioni. Due programmatori che risolvono lo stesso problema con codice diverso detengono due opere distinte agli occhi del diritto d’autore, anche se producono lo stesso risultato. Il brevetto, al contrario, tutela la soluzione tecnica sottostante, indipendentemente dal linguaggio di programmazione o dall’implementazione specifica usata per realizzarla.
Questa differenza ha conseguenze pratiche immediate sulla strategia di tutela:
Il diritto d’autore protegge automaticamente il codice dal momento della creazione, senza necessità di deposito, ma impedisce solo la copia letterale dell’espressione, non il riuso dell’idea tecnica.
Il brevetto richiede un deposito formale, un esame e un investimento di tempo, ma impedisce a terzi di sfruttare la stessa soluzione tecnica anche se riscritta in un linguaggio diverso.
Il segreto industriale protegge dettagli implementativi che non emergono dalla documentazione pubblica, come parametri di configurazione o dataset proprietari, e può convivere con una domanda di brevetto limitata agli aspetti tecnici misurabili.
Una guida tecnica sul confine tra software brevettabile e non approfondisce come distinguere, caso per caso, la parte di un progetto che merita un deposito brevettuale da quella che resta meglio tutelata come opera dell’ingegno. Per molte startup la scelta più efficiente è ibrida: si brevetta l’aspetto tecnico misurabile, come un metodo di compressione o di controllo, mentre il codice che lo implementa resta protetto dal diritto d’autore e i dettagli di configurazione restano riservati come segreto commerciale, come indicato anche nei materiali didattici della Camera di Commercio di Trento. Quando il software non produce alcun effetto tecnico ulteriore, la tutela disponibile resta il diritto d’autore, con deposito facoltativo presso i registri competenti per fissare una data certa. Per chi valuta la strada alternativa alla brevettazione, un approfondimento su come proteggere il codice sorgente senza brevetto offre indicazioni operative su copyright e segreto industriale.
Come scrivere una domanda di brevetto per un algoritmo
Una volta accertato che l’algoritmo produce un effetto tecnico, la qualità della domanda dipende dalla formulazione delle rivendicazioni e dalla sufficienza della descrizione.
Scegliete il formato di rivendicazione più adatto al contesto. Una rivendicazione di metodo descrive la sequenza di passi tecnici eseguiti; una rivendicazione di dispositivo descrive il sistema che implementa quel metodo; una rivendicazione su supporto di memorizzazione tangibile copre il programma registrato su un mezzo leggibile da calcolatore. Spesso conviene depositare tutte e tre le forme nella stessa domanda, per coprire differenti modalità di sfruttamento da parte di terzi.
Garantite una descrizione sufficiente a riprodurre il risultato. L’esaminatore deve poter verificare che l’effetto tecnico dichiarato sia realmente ottenibile: questo richiede dettagli di implementazione, parametri di addestramento se si tratta di un modello di apprendimento automatico, caratteristiche del dataset utilizzato ed esempi numerici concreti.
Allegate materiale di supporto che dimostri il miglioramento tecnico. Diagrammi di flusso, dati di benchmark comparativi, pseudocodice e risultati di test che mostrino un guadagno misurabile rispetto allo stato dell’arte rafforzano in modo sostanziale la domanda. Le linee guida EPO G II 3.3.1 indicano che, nelle domande legate ad AI e machine learning, fornire dataset di riferimento e metriche di performance aumenta sensibilmente le probabilità che l’effetto tecnico venga riconosciuto.
Bilanciate trasparenza e riservatezza. Non tutti i dettagli implementativi devono comparire nella domanda: è possibile descrivere il principio di funzionamento e i parametri rilevanti per la riproducibilità tecnica, lasciando alcuni dettagli di ottimizzazione come know-how riservato, purché la descrizione resti sufficiente a soddisfare il requisito di riproducibilità richiesto dall’esame.
Un consiglio: prima di scrivere le rivendicazioni, elencate i parametri tecnici che il vostro algoritmo migliora rispetto a una soluzione nota: quella lista diventa la base delle rivendicazioni dipendenti e del materiale di supporto da allegare alla domanda.
Un approfondimento dedicato agli aspetti fiscali e strategici, utile per chi valuta la brevettazione come parte di una pianificazione più ampia, è disponibile nella nostra analisi su brevettazione di algoritmi e intelligenza artificiale.
Errori comuni e segnali d’allarme nelle domande su algoritmi
Molte domande respinte condividono gli stessi difetti strutturali, spesso evitabili con una redazione più attenta.
Rivendicazioni formulate come puri metodi matematici, senza un collegamento esplicito a un’applicazione tecnica, finiscono quasi sempre escluse ai sensi dell’articolo 52 EPC.
L’assenza di dati comparativi che dimostrino il miglioramento tecnico rispetto allo stato dell’arte indebolisce la domanda, perché l’esaminatore non può verificare l’effetto dichiarato.
Una descrizione troppo generica, che non consente di riprodurre il risultato tecnico senza sforzo inventivo aggiuntivo, viola il requisito di sufficienza della descrizione.
Confondere un vantaggio commerciale, come un risparmio di costi o un’interfaccia più gradevole, con un contributo tecnico porta a rivendicazioni respinte perché il beneficio non tecnico non può da solo fondare l’attività inventiva secondo l’approccio COMVIK richiamato nei materiali di formazione sulla tutela del software.
Un’analisi dedicata ai limiti della brevettabilità per i contenuti generati da sistemi di intelligenza artificiale, utile per chi lavora con modelli generativi, è disponibile nel nostro approfondimento su dove finisce la brevettabilità dell’AI.
Perché affidarsi a competenze legali e tecniche specialistiche
Valutare la brevettabilità di un algoritmo richiede una lettura incrociata tra competenza giuridica e comprensione tecnica del funzionamento del software: due ambiti che raramente convivono nella stessa figura professionale senza una formazione specifica. Lavoriamo quotidianamente all’intersezione tra proprietà industriale e tecnologia, seguendo progetti in settori come il food tech, il gaming e il monitoraggio IoT, e utilizziamo strumenti avanzati di intelligenza artificiale per rendere più efficiente l’analisi preliminare di brevettabilità e la gestione dei fascicoli.
Il nostro supporto pratico copre l’intero percorso: valutazione tecnica preliminare per capire se l’algoritmo supera la soglia dell’effetto tecnico ulteriore, ricerche di anteriorità per verificare lo stato dell’arte prima del deposito, redazione delle rivendicazioni e gestione dell’intera procedura di deposito presso gli uffici competenti.
Tempi e costi di massima per depositare un brevetto
La procedura segue fasi standard, anche se le tempistiche esatte variano in base all’ufficio scelto e alla complessità tecnica della domanda. Dopo il deposito, la domanda viene sottoposta a un esame formale preliminare, seguito dalla pubblicazione, che in sede europea avviene tipicamente a diciotto mesi dalla data di priorità. Segue poi l’esame di merito, durante il quale l’esaminatore verifica novità, attività inventiva e applicazione industriale, con eventuali scambi di osservazioni tra richiedente e ufficio. La concessione arriva solo al termine di questo confronto, che per le domande software e AI tende ad allungarsi proprio per la necessità di dimostrare l’effetto tecnico ulteriore.
I costi variano sensibilmente in base al numero di paesi designati, alla complessità delle rivendicazioni e al numero di repliche necessarie durante l’esame: comprendono tasse di deposito, tasse di ricerca, tasse di esame e, per le domande europee, tasse di designazione e convalida nei singoli stati. Per questo motivo una valutazione preliminare di brevettabilità, condotta prima del deposito, resta spesso l’investimento più efficiente per evitare di sostenere i costi di una procedura destinata al rigetto.
Cosa insegna la giurisprudenza sul confine tra codice e invenzione
Le decisioni delle commissioni di ricorso EPO restano il punto di riferimento più solido per capire dove tracciare la linea. Nei casi richiamati dalle sintesi di case law EPO, come T 702/20 e T 761/20, il filo conduttore è la richiesta di specificità: una rete neurale o un metodo di apprendimento automatico descritto in termini puramente matematici, senza indicare il dato tecnico trattato né l’impiego pratico del risultato, viene trattato come esclusione in quanto tale.
Al contrario, le domande che hanno superato l’esame condividono un tratto comune: collegano esplicitamente il modello computazionale a un problema tecnico misurabile, come l’elaborazione di un segnale proveniente da un sensore fisico o il controllo di un parametro di sistema. Questa giurisprudenza conferma che la soglia di brevettabilità non dipende dalla sofisticazione dell’algoritmo, ma dalla capacità del richiedente di ancorarlo a un’applicazione tecnica verificabile e di descriverla con un livello di dettaglio che consenta la riproducibilità.
Strategie di redazione delle rivendicazioni per algoritmi
Una rivendicazione efficace per un algoritmo tecnico si costruisce per livelli. La rivendicazione principale descrive il passo tecnico essenziale, quello che produce l’effetto ulteriore, evitando di includere dettagli puramente implementativi che ne restringerebbero inutilmente la portata. Le rivendicazioni dipendenti aggiungono progressivamente le varianti tecniche: parametri specifici, condizioni operative, configurazioni hardware alternative.
Una strategia che si rivela spesso efficace consiste nel redigere rivendicazioni parallele di metodo, dispositivo e supporto di memorizzazione, così da coprire sia chi implementa il metodo sia chi distribuisce il software che lo esegue. È utile inoltre evitare di esprimere il contributo tecnico solo in termini di risultato desiderato: la rivendicazione deve indicare anche i mezzi tecnici con cui quel risultato viene raggiunto, perché una formulazione puramente funzionale rischia di essere considerata troppo astratta in sede di esame.
Le implicazioni etiche e di policy della brevettabilità degli algoritmi
La possibilità di brevettare algoritmi, in particolare modelli di intelligenza artificiale, solleva interrogativi che vanno oltre la tecnica giuridica. Un brevetto troppo ampio su un principio computazionale di base rischia di ostacolare la ricerca successiva, soprattutto in settori come la diagnostica medica o l’elaborazione del linguaggio, dove molte innovazioni si costruiscono per incrementi successivi sullo stesso impianto matematico.
Per questo le linee guida EPO insistono sulla specificità dell’applicazione tecnica come condizione di brevettabilità: un principio matematico generale resta patrimonio comune, mentre solo la sua applicazione a un problema tecnico concreto può essere oggetto di esclusiva. Questo equilibrio, tra incentivo all’innovazione e libertà di ricerca, resta uno dei temi più discussi nel dibattito europeo sulla regolazione dell’intelligenza artificiale, e si riflette anche nella cautela con cui gli esaminatori valutano le domande che coinvolgono modelli di apprendimento automatico di portata generale.
Le differenze tra procedura europea e procedura italiana
La procedura davanti all’Ufficio Europeo dei Brevetti e quella nazionale italiana condividono gli stessi criteri sostanziali di brevettabilità, perché il Codice della proprietà industriale riprende all’articolo 45 la medesima esclusione per i programmi per elaboratore in quanto tali prevista dalla Convenzione sul brevetto europeo. La differenza principale riguarda l’estensione territoriale e la procedura di esame: un brevetto europeo, una volta concesso, va convalidato nei singoli stati designati, mentre un brevetto italiano produce effetti limitati al territorio nazionale fin dall’origine.
Dal punto di vista pratico, l’Ufficio Italiano Brevetti e Marchi applica gli stessi principi di tecnicità elaborati dalla giurisprudenza EPO quando esamina domande nazionali relative a invenzioni attuate per mezzo di computer, per garantire coerenza con il sistema europeo. Per le startup che puntano a una protezione internazionale, la scelta tra via nazionale, via europea o entrambe dipende soprattutto dai mercati di interesse e dal budget disponibile per le fasi di convalida.
Casi pratici di brevetti concessi o respinti su algoritmi
Gli esempi tratti dalla case law EPO offrono indicazioni concrete più di qualunque principio astratto. Nei casi T 702/20 e T 761/20, richiamati dalle sintesi ufficiali della giurisprudenza, le commissioni di ricorso hanno respinto rivendicazioni che descrivevano metodi di elaborazione dati privi di un collegamento esplicito a un’applicazione tecnica misurabile, confermando che la sola efficienza computazionale non basta a fondare l’attività inventiva quando manca la specificità richiesta sul piano tecnico.
Sul fronte opposto, le domande che superano l’esame condividono sempre un elemento: il legame diretto tra l’algoritmo e un problema tecnico verificabile, come dimostrato dagli esempi di controllo ABS e compressione video citati nelle linee guida EPO. La lezione pratica per chi prepara una domanda è costante in entrambi i casi: la rivendicazione deve rendere esplicito non solo cosa fa l’algoritmo, ma su quale grandezza tecnica agisce e con quale beneficio misurabile.
Cosa ci insegna davvero il confine tra codice e brevetto
Il dibattito pubblico su algoritmi e brevetti tende a polarizzarsi tra chi vorrebbe estendere la tutela a qualsiasi innovazione software e chi, al contrario, vorrebbe escludere in blocco l’intelligenza artificiale dalla brevettabilità. Entrambe le posizioni semplificano un criterio che la prassi EPO ha reso piuttosto preciso: conta l’effetto tecnico dimostrabile, non la sofisticazione dell’algoritmo né il clamore mediatico attorno a una tecnologia.
Il nostro punto di vista, maturato osservando l’evoluzione delle linee guida e della giurisprudenza, è che molte startup sottovalutano il valore di una valutazione preliminare rigorosa e sopravvalutano la forza di un’idea computazionale in sé. Un algoritmo brillante senza un collegamento tecnico esplicito non vale, agli occhi di un esaminatore, più di un’idea di business non protetta. La priorità pratica, prima ancora di scrivere una rivendicazione, è identificare con precisione quale grandezza tecnica il proprio algoritmo modifica e con quale beneficio misurabile: è quel dato, non la complessità del codice, a determinare l’esito della domanda.
— STUDIO
Come possiamo aiutarti a proteggere il tuo algoritmo
Trasformare un algoritmo in un brevetto solido richiede una lettura tecnica accurata prima ancora che giuridica, ed è proprio in questo passaggio che un confronto preliminare con chi lavora quotidianamente su invenzioni attuate per mezzo di computer fa la differenza.
[
Offriamo un percorso che integra competenze tecniche e giuridiche con strumenti digitali per rendere più rapida ed efficiente l’analisi preliminare dei fascicoli:
Valutazione tecnica della brevettabilità del vostro algoritmo, con verifica dell’effetto tecnico ulteriore richiesto dalle linee guida EPO.
Ricerche di anteriorità per mappare lo stato dell’arte prima del deposito e ridurre il rischio di rigetto.
Redazione delle rivendicazioni e gestione dell’intera procedura di deposito, dalla domanda nazionale a quella europea.
Se state valutando se la vostra soluzione tecnica è pronta per un deposito, potete approfondire i nostri servizi di registrazione brevetti e richiedere un primo confronto con il nostro team.
Questo articolo fornisce informazioni generali e non sostituisce il parere di un avvocato qualificato. Consulta un professionista legale qualificato riguardo al tuo caso specifico prima di agire in base a questo contenuto.
Domande frequenti
Come faccio a brevettare un’invenzione basata su un algoritmo?
Occorre innanzitutto verificare che l’algoritmo produca un effetto tecnico ulteriore applicato a un campo della tecnica, come richiesto dalle linee guida EPO. Successivamente si predispone una domanda con descrizione sufficiente a riprodurre il risultato e rivendicazioni di metodo, dispositivo o supporto tangibile, da depositare presso l’ufficio nazionale o europeo competente.
Quali sono i requisiti per la brevettabilità di un’invenzione software?
I requisiti sostanziali sono gli stessi di qualsiasi invenzione: novità, attività inventiva e applicazione industriale, come stabilito dal Codice della proprietà industriale. Per il software si aggiunge una condizione specifica: la soluzione deve produrre un effetto tecnico che vada oltre la normale esecuzione del programma su un computer generico.
Qual è il confine più discusso nella giurisprudenza sugli algoritmi?
Il confine più dibattuto riguarda le rivendicazioni che descrivono modelli di apprendimento automatico in termini astratti, senza un collegamento esplicito a un’applicazione tecnica. Decisioni come T 702/20 e T 761/20, richiamate dalle sintesi di case law EPO, hanno chiarito che la specificità tecnica è decisiva per l’esito dell’esame.
Quanto costa brevettare un algoritmo o un’invenzione software?
I costi dipendono dal numero di paesi designati, dalla complessità delle rivendicazioni e dalle fasi di esame necessarie, e comprendono tasse di deposito, ricerca, esame ed eventuale convalida nei singoli stati. Una valutazione preliminare di brevettabilità aiuta spesso a contenere questi costi, evitando di avviare una procedura destinata al rigetto.
Fonti
Raccomandati
Commenti