L'invenzione è di norma software, e l'ammissibilità a brevetto dipende da ciò che esso fa alla macchina.

Molte invenzioni nel campo dell'automazione riguardano i dati: acquisirli da sottosistemi di dispositivi distinti su una base temporale comune, contestualizzarli, trasformarli per il sistema che li utilizzerà e presentarli su una dashboard o nel cloud. Una rivendicazione che si ferma alla raccolta, all'analisi e alla visualizzazione di informazioni corrisponde allo schema che il Federal Circuit ha ritenuto astratto in Electric Power Group, e i dati di un impianto non ne sono esenti per il fatto di provenire da una macchina.

Aggiungere una fase fisica alla fine non basta a porvi rimedio. Diehr e Flook, entrambi casi relativi al controllo di processo, segnano il confine: Diehr ha riconosciuto l'ammissibilità a brevetto di un processo di vulcanizzazione della gomma in cui un computer ricalcolava ripetutamente il tempo di vulcanizzazione e apriva la pressa, mentre Flook l'ha esclusa per un procedimento il cui unico elemento nuovo era la formula per aggiornare un limite di allarme, benché tale limite governasse un processo chimico in corso. Ciò che regge è una rivendicazione in cui la fase di controllo è il punto in cui l'invenzione opera, oppure una rivendicazione che migliora il funzionamento del controllore o della sua rete in sé, ad esempio mantenendo la coerenza dei dati nella memoria del controllore. La descrizione del brevetto deve presentare l'invenzione in questo modo fin dall'inizio, perché un esaminatore non lo farà al suo posto.

Modifica collaborativa, controllo delle versioni, ritorno a una versione di riferimento, viste testuali e grafiche sincronizzate dello stesso programma: un esaminatore riesce di norma a trovare ciascuno di questi elementi nell'ingegneria del software in generale e sosterrà che applicarlo a un progetto di automazione era ovvio. Dopo KSR, un uso prevedibile di una tecnica nota in un campo contiguo sarà verosimilmente ritenuto ovvio, ed è questo il rigetto che una domanda relativa a un ambiente di progettazione deve attendersi.

La risposta sta in ciò che distingue un progetto di controllo dal normale codice sorgente. Il programma è vincolato a I/O fisici e a un determinato controllore, può essere modificato mentre quel controllore sta eseguendo un processo, e riportarlo a uno stato precedente può richiedere di tenere conto dell'hardware oltre che del testo. Una descrizione del brevetto che espone tali vincoli, con rivendicazioni che enunciano la fase che li soddisfa, fornisce all'esaminatore una ragione per cui la tecnica generale non si trasferisce semplicemente; una domanda che descrive lo strumento solo come software lascia quell'argomentazione priva di fondamento.