ההמצאה היא בדרך כלל תוכנה, והכשירות לפטנט תלויה במה שהיא עושה למכונה.

המצאות אוטומציה רבות עוסקות בנתונים: קליטתם מתת-מערכות נפרדות של התקנים על בסיס זמן משותף, הוספת הקשר להם, המרתם עבור המערכת שתצרוך אותם, והצגתם בלוח מחוונים או בענן. תביעה שנעצרת באיסוף, בניתוח ובהצגה של מידע תואמת את הדפוס שה-Federal Circuit קבע כי הוא מופשט בעניין Electric Power Group, ונתונים ממפעל אינם פטורים מכך רק משום שמקורם במכונה.

שלב פיזי שנוסף בסוף אינו מרפא זאת. Diehr ו-Flook, שני פסקי דין בעניין בקרת תהליכים, מסמנים את הקו: בעניין Diehr אושר תהליך לגיפור גומי שבו מחשב חישב מחדש שוב ושוב את זמן הגיפור ופתח את המכבש, ובעניין Flook נדחתה שיטה שהרכיב החדש היחיד בה היה הנוסחה לעדכון סף התרעה, אף שהסף שלט בתהליך כימי פעיל. מה שמחזיק מעמד הוא תביעה שבה שלב הבקרה הוא המקום שבו ההמצאה עושה את עבודתה, או תביעה שמשפרת את אופן פעולתם של הבקר או של הרשת שלו עצמם, כגון שמירה על עקביות הנתונים בזיכרון הבקר. פירוט הפטנט צריך להציג את ההמצאה כך מלכתחילה, משום שבוחן לא יעשה זאת במקומו.

עריכה שיתופית, ניהול גרסאות, חזרה לאבן דרך, תצוגות טקסטואליות וגרפיות מסונכרנות של אותה תוכנית: בוחן יכול בדרך כלל למצוא כל אחד מאלה בהנדסת תוכנה כללית, ויטען שהחלתו על פרויקט אוטומציה הייתה מובנת מאליה. מאז הלכת KSR, סביר ששימוש צפוי בטכניקה ידועה בתחום סמוך ייחשב מובן מאליו, וזו הדחייה שבקשה בתחום סביבות התכנון צריכה לצפות לה.

התשובה טמונה במה שמבדיל פרויקט בקרה מקוד מקור רגיל. התוכנית כבולה לכניסות וליציאות (I/O) פיזיות ולבקר מסוים, ייתכן שתיערך בזמן שהבקר מריץ תהליך, והחזרתה למצב קודם עשויה לחייב התחשבות בחומרה ולא רק בטקסט. פירוט פטנט שמציג את האילוצים האלה, עם תביעות שמציינות את השלב העונה עליהם, נותן לבוחן סיבה לכך שהטכניקה הכללית אינה עוברת פשוט כמות שהיא; בקשה שמתארת את הכלי כתוכנה בלבד אינה מותירה לטיעון הזה דבר לעמוד עליו.