可參考本部落格報導：
- 使用自然律的技術可專利性討論 - Mayo Collaborative Services v. Prometheus Laboratories, Inc. 2012)（http://enpan.blogspot.tw/2015/10/mayo-collaborative-services-v.html）
- 抽象概念若僅以一般目的電腦實現，不可專利 - Alice Corporation Pty. Ltd. v. CLS Bank International (2014)（http://enpan.blogspot.tw/2014/06/alice-corporation-pty-ltd-v-cls-bank.html）
事實上，判例雖有影響，卻不見得影響實務上的判斷，其中考量的因素常常是與客戶談軟體專利案時的提醒事項，甚至是更為嚴格的討論，不僅是要克服「抽象概念」而已，而是還要加入「與硬體特徵的連結」。
當然，仍無法排除「純軟體」的發明專利，因此面對引用Alice判例的101核駁意見時，答辯須說服審查委員專利範圍內具有「實質超越抽象概念的技術特徵」。具體來說，軟體專利往往是以電腦系統實施，因此需要說明發明是並非使用一般目的電腦執行的程序而已，其中需要有至少一個元件或是元件的組合產生非一般目的電腦可以達成的技術。
IPWatchdog揭露的統計值得注意（http://www.ipwatchdog.com/wp-content/uploads/2016/08/top-25-alice-rejection-companies.jpg），表格顯示接獲根據Alice判例作出的核駁意見的前25大公司，前幾名為IBMC, MICROSOFT, GOOGLE, SAMSUNG, ORACLE等，其中藍色為經答辯成功的案子。
（編按：這裡的表格需要連結到原出處）
另參考
http://www.law360.com/articles/801994/5-ways-to-overcome-an-examiner-s-post-alice-101-rejection
(1) 證明審查委員的核駁錯誤，如錯誤使用two-step test
(2) 證明請求項範圍有具體物件（非抽象概念）
(3) 提出說明書的具體結構與請求項所述功能（功能手段用語）的關聯
(4) 證明方法請求項不是由人執行
(5) 證明演算法的輸入條件需要具體物件
對於Alice-based的核駁意見，主要就是要證明請求項發明「實質超越」抽象概念，證明系爭案並非一般目的電腦達成的軟體發明、或是證明請求項範圍與特定硬體的關聯性、或是證明發明產生的功效（輸出）並非僅是抽象概念的效果。這裡也有一些答辯建議：
http://www.greyb.com/rejections-based-on-the-alice-decision/
以Oracle公司的專利13/673,347為例：
101核駁：
對此案，審查委員認為不符101規定的核駁意見包括：(1)請求項整體來看沒有實質超越抽象概念；(2)請求項僅是數學方程式的抽象概念；(3)除了抽象概念元件外，其他請求項元件的個別或是組合並沒有超過僅是一般目的電腦的指令，僅是相關技術常見的動作；(4)整體看來，這些除了抽象概念外的元件並沒有提供有意義的限制而轉換抽象概念為可專利的應用，而使得超越抽象概念本身。因此認為此案原請求項範圍僅是一般目的電腦執行的數學方法，引用案例為Alice Corporation Pty. Ltd v. CLS Bank International, et al.。
申請時Claim 1：
經此OA後，Claim 1修正如下：
Claim 15修正如下，讓整個系統增添了硬體特徵，其中執行步驟仍如Claim 1的內容：
修正內容包括限定一些技術用語，初步感覺，Claim 1整體看來還是一個貨架空間判斷的數學方法，Claim 15倒是併入了硬體元件。
在其答辯意見中，申請人提出不同意審查委員意見的理由，包括引用Alice v. CLS Bank案所衍生的Two-Step Test，認為當判斷發明是否是抽象概念時，即便claim 1描述了數學特徵，但審查意見卻忽略了其中有意義的特徵，如請求項發明輸出了貨架位置與物品的數量，這些並非抽象的東西。
更者，即便發明關於抽象概念，但是發明仍具有「實質超越」抽象概念的特徵，包括其輸出貨架位置與物品數量，為得是要優化貨架空間使用，這已經實質超越了數學演算的抽象概念。
結果，審查委員同意申請人意見，核准通知也引用了大部分申請人的答辯意見，算是十分成功的答辯案例。
資料來源：IPWatchdog
http://www.ipwatchdog.com/2016/08/21/off-record-tips-overcoming-alice/id=72197/
http://www.greyb.com/rejections-based-on-the-alice-decision/
2 則留言:
從事務所的角度來看，確實只能在螺獅殼裡做道場；但是從In house PE的角度來看，我傾向一開始就把這類案件拆成architecture + algorithm，然後確保architecture是無前案的；如果architecture確有前案，表示拆得還不夠細，再逼發明人把上位architecture的function block細部也拆成下位的architecture，直到確保其無前案為止。
因為有明確的架構，當然不會是抽象概念，演算法的不可專利問題更早已被剝離。換句話說，已經實質超越抽象概念。
所以，拆到最後，必須得出一個架構是前所未有的；既然前所未有，自然不是單純的把人已經在做的事，利用電腦強大運算的本質，重新發明輪胎一次。
純軟體案還是可以做到這一點，頂多就是達成相同效果的不同技術手段，逼發明人把那個技術手段找出來。
感謝留言，受教了！
Ron
張貼留言