発明はたいていソフトウェアだ。適格性は、それが機械に何をもたらすかで決まる。

オートメーションの発明の多くは、データに関するものです。別々の機器サブシステムから共通の時間軸でデータを取得し、それに文脈を与え、それを利用するシステムに合わせて変換し、ダッシュボードやクラウド上に提示することです。情報の収集、分析、表示で止まる請求項は、連邦巡回控訴裁判所が Electric Power Group で抽象的と判断した型に当てはまります。プラントから得たデータであっても、機械から来たというだけで例外とはなりません。

末尾に物理的なステップを付け加えても、それは解消されません。いずれもプロセス制御の事件である Diehr と Flook が、その境界線を示しています。Diehr は、コンピュータが硬化時間を繰り返し再計算してプレスを開くゴム硬化プロセスについて特許適格性を認め、Flook は、唯一の新しい要素が警報限界値を更新するための数式である方法について、その限界値が稼働中の化学プロセスを支配していたにもかかわらず、特許適格性を否定しました。持ちこたえるのは、制御ステップこそが発明の働く場所となっている請求項か、コントローラのメモリ内でデータの整合性を保つことのように、コントローラやそのネットワーク自体の動作の仕方を改良する請求項です。審査官がそれを補ってくれることはないため、明細書は最初から発明をそのように提示しなければなりません。

共同編集、バージョン管理、マイルストーンへのロールバック、同じプログラムのテキスト表示とグラフィカル表示の同期。審査官は通常、これらのそれぞれを一般的なソフトウェア工学の中に見いだし、それをオートメーションプロジェクトに適用することは自明であったと主張するでしょう。KSR 以降、隣接分野における既知の技術の予測可能な利用は自明と判断される可能性が高く、設計環境に関する出願が覚悟すべきなのは、まさにその拒絶です。

答えは、制御プロジェクトを通常のソースコードと異なるものにしている点にあります。そのプログラムは物理的な入出力と特定のコントローラに結び付けられており、そのコントローラがプロセスを実行している最中に編集されることがあり、以前の状態に戻す際にはテキストだけでなくハードウェアも考慮しなければならない場合があります。こうした制約を明らかにし、それを満たすステップを記載した請求項を備えた明細書は、一般的な技術がそのままでは転用できない理由を審査官に示します。ツールを単なるソフトウェアとしてしか記述していない出願では、その主張には拠って立つものが何もありません。