발명은 대개 소프트웨어이며, 특허적격성은 그것이 기계에 무엇을 하느냐에 달려 있습니다.

많은 자동화 발명은 데이터에 관한 것입니다. 개별 기기 서브시스템에서 공통의 시간축에 맞추어 데이터를 취득하고, 맥락을 부여하고, 그것을 사용할 시스템에 맞게 변환하고, 대시보드나 클라우드에 표시하는 것입니다. 정보의 수집, 분석, 표시에서 멈추는 청구항은 연방순회항소법원이 Electric Power Group 판결에서 추상적이라고 판시한 패턴과 일치하며, 플랜트에서 나온 데이터라고 해서 기계에서 나왔다는 이유로 예외가 되지는 않습니다.

끝에 물리적 단계를 덧붙인다고 해서 그 문제가 치유되지는 않습니다. 둘 다 공정 제어 사건인 Diehr 판결과 Flook 판결이 그 경계를 보여줍니다. Diehr 판결은 컴퓨터가 경화 시간을 반복적으로 재계산하고 프레스를 여는 고무 경화 공정의 특허적격성을 인정했고, Flook 판결은 유일하게 새로운 요소가 경보 한계값을 갱신하는 수식뿐인 방법을, 그 한계값이 가동 중인 화학 공정을 좌우했음에도 배척했습니다. 버텨 내는 것은 제어 단계가 곧 발명이 작용하는 자리인 청구항, 또는 컨트롤러 메모리 내 데이터의 일관성 유지처럼 컨트롤러나 그 네트워크 자체의 작동 방식을 개선하는 청구항입니다. 명세서는 처음부터 발명을 그렇게 제시해야 합니다. 심사관이 대신 채워 주지는 않기 때문입니다.

공동 편집, 버전 관리, 마일스톤으로의 롤백, 같은 프로그램에 대해 동기화된 텍스트 뷰와 그래픽 뷰 — 심사관은 대개 이들 각각을 일반 소프트웨어 공학에서 찾아낼 수 있으며, 그것을 자동화 프로젝트에 적용하는 것은 자명했다고 주장할 것입니다. KSR 판결 이후, 인접 분야의 공지 기법을 예측 가능한 방식으로 사용하는 것은 자명하다고 판단될 가능성이 높으며, 설계 환경에 관한 출원이라면 바로 그 거절을 예상해야 합니다.

답은 제어 프로젝트를 일반적인 소스 코드와 다르게 만드는 요소에 있습니다. 그 프로그램은 물리적 I/O와 특정 컨트롤러에 결부되어 있고, 그 컨트롤러가 공정을 가동하는 도중에 편집될 수도 있으며, 이전 상태로 되돌릴 때는 텍스트뿐 아니라 하드웨어까지 고려해야 할 수도 있습니다. 이러한 제약을 기술하고 그 제약을 충족하는 단계를 기재한 청구항을 갖춘 명세서는, 일반적인 기법이 그대로 옮겨 오지 않는 이유를 심사관에게 제시합니다. 도구를 소프트웨어로만 기술한 출원서는 그 주장이 설 토대를 전혀 마련해 주지 못합니다.