發明通常是軟體，而適格性取決於它對機器做了什麼。

許多自動化發明與資料有關：以共同的時間基準從各自獨立的裝置子系統取得資料、賦予其脈絡、為將使用它的系統進行轉換，並呈現在儀表板上或雲端中。一項止步於蒐集、分析與顯示資訊的請求項，正符合聯邦巡迴上訴法院在 Electric Power Group 案中認定為抽象的模式，而來自工廠的資料，並不會因為出自機器就得以豁免。

在最後加上一個實體步驟，並不能補救這一點。Diehr 與 Flook 兩案都是製程控制案件，劃出了這條界線：Diehr 案肯認了一項橡膠硫化製程，其中電腦反覆重新計算硫化時間並開啟壓機；Flook 案則否定了一項方法，其唯一的新元素是更新警報界限值的公式——即使該界限值支配著一個運行中的化學製程。站得住腳的，是控制步驟本身就是發明發揮作用之處的請求項，或是改良控制器或其網路本身運作方式的請求項，例如在控制器記憶體中維持資料一致性。說明書必須從一開始就以這種方式呈現發明，因為審查官不會代為補上。

協同編輯、版本控制、回溯至某個里程碑、同一程式的文字檢視與圖形檢視同步：審查官通常能在一般軟體工程中找到上述每一項，並主張將其應用於自動化專案是顯而易見的。在 KSR 判決之後，於鄰近領域中對已知技術所作的可預期運用，很可能被認定為顯而易見，而這正是設計環境類申請案應預期會收到的核駁。

答案在於控制專案與一般原始碼的不同之處。程式綁定於實體 I/O 與特定控制器，可能在該控制器正運行製程時被編輯，而將它回復到先前的狀態時，可能不只要處理文字，還必須顧及硬體。一份闡明這些限制、並以請求項記載滿足這些限制之步驟的說明書，能給審查官一個理由，說明一般技術為何無法直接套用；而一件只把該工具描述為軟體的申請案，則讓這項論述毫無立足之地。