基本駕駛操作已是先前技術；請求項存在於情境之中。

審查官能以卷內既有的系統拼湊出大多數駕駛輔助請求項：一份辨識車道的引證文件、另一份變換車道的引證文件、第三份發出碰撞警示的引證文件。依據 KSR 判決，以已知方法結合習知元件，若僅產生可預期的結果，很可能被認定為顯而易見。通常能存活下來的，是某個特定駕駛情境——道路分岔、車道標線的幾何形狀、低速時車旁的障礙物、控制應加以緩和的駕駛人要求——與該情境所需之控制回應的配對。

這樣的配對必須在說明書中加以解釋，而不只是記載於請求項中。反駁引證文件組合的論述，建立在申請案本身的說明之上：已知做法為何在該情境下失效，以及請求項所記載的回應如何因應；一份只描述控制、卻從不描述問題的說明書，會讓請求項只能仰賴律師論述。綁定單一情境的請求項也容易被迴避，因此保護來自一系列申請案所組成的專利家族，涵蓋競爭對手的系統實際上會遇到的各種情境。

車輛控制申請案通常會提出彼此平行的裝置、方法與儲存媒體獨立請求項，各自記載相同的步驟。其中暴露於風險的是裝置請求項。當它被寫成一連串各自被配置為執行某項功能的單元——辨識單元、判定單元、控制單元——即使從未出現「手段」（means）一詞，仍可能落入第 112(f) 條的適用範圍：自 Williamson 判決以來，反對如此處理的推定已不再強固，而一個僅以其作用來界定的單元，並未指明任何結構。此時，請求項僅涵蓋說明書中為每一項功能所揭露的結構及其均等物；對於由電腦執行的功能，該結構就是演算法，而一份只呈現一個加了標籤的方塊、背後卻沒有演算法的說明書，會使該請求項不明確。

審查官依指示須辨識出這類限定條件，並將其解釋載明於卷證中；而對此的回應是關於權利範圍的決定，並非形式上的手續：接受該解釋，或修正請求項以記載結構——執行各步驟的處理器與記憶體。無論哪一種，都由說明書決定，這正是每一個功能單元都需要在文字與流程圖中完整寫出其演算法的原因——條件、閾值、各項判定的順序。方法請求項與儲存媒體請求項通常不會依第 112(f) 條解釋，因此若未如此審慎處理，裝置請求項最後可能比與其一同提出的方法請求項還要狹窄。