如何有效率地撰寫專利說明書!? - 專利

※ 引述《VanDeLord (HelloWorld)》之銘言：
: SOURCE: http://iknow.stpi.narl.org.tw/Post/Read.aspx?PostID=8762
: 陳博士分享了其求學歷程與事務所撰稿的實務經驗,
: 如何寫的又快又好,簡單來說就是由Claim先入手,
: 由claim 描述完整發明整體技術特徵,加快專利撰稿速度。
: 對某些事務所剛入行的菜鳥來說,這方法不算陌生。
: 由事務所的角度當然是"天下武功、唯快不破",時間就是金錢,
: 但是否快就一定好,這見人見智,至少寫的快卻不能犯錯,這就至關重要。
: 就in-house角度來說,建立在專利技術特徵上的專利權項布局才是關注的核心。
: 就企業來說,好不容易取得的專利權項卻輕易地被迴避掉,那就有點心酸了。
: 根據我專利分析與迴避的經驗,我發現
: Nokia的專利權項布局就值得參考,微軟與IBM的權項就顯得中規中矩。
: 簡單來說,Nokia會測試審查底線以取得較大範圍。
: 至於其寫法是否採用上述的方式,我覺可能性較低,
: 至少能發動訴訟且經得起訴訟的專利才是好的專利。
: "天下武功、唯快不破"，快，可能反而成為布局上的罩門。
陳老師的行文方式似乎造成了不少人誤解，
導致相關討論集中在是否會因為求快而犧牲品質這點(實施例不夠，布局失敗，etc)。
但其實真正的目的並不是縮短時間，而是善用時間。

如同陳老師提到的，歐美attorney基本上是按時計費的。
但是客戶通常會設定一個預算上限，收到帳單如果發現超過就會來抗議。
所以撰稿時基本上就是依照預算和自己的鐘點費來規劃自己要花多少時間，
如果比預期提早寫完，通常都是多花一些時間進一步提昇品質而不是早早交稿。
否則真的出了錯，客戶只會怪你犯錯不會謝謝你原本想幫他省錢，
老闆也會怪你怎麼該賺的錢不賺還降低品質搞烏龍。

所以基本上是時間分配的問題，而不是時間長短的問題。
假設預算容許花四天來寫，
文中的「菜鳥專利律師」就是那種一開始就衝進無止盡的細節中，
花一大堆時間寫實施例加畫圖，
結果要開始寫claim時已經花了三天半。
接著發現半天根本沒辦法把claim寫完，
只好開始填所謂'non-billable hours'，講白了就是作白工，
原文所謂的「省時間」其實是在講這個部分。

所以在假設attorney會把預算剛好用完的前提下，
其實不需要太過擔心品質不足的問題。
假設用原文的方法花了一天半把整套claim搞定，
剩下兩天半可以全部放心拿來寫細節，而且至此基本上撰稿已經及格，
剩下的只是要拿多高分的問題。

反過來說，是否真的要把整套claim都完成倒是見仁見智。
我個人覺得一些細節的附屬項重要性可以放在說明書後面，
特別是claim dependency，增減個一兩項就要整個更動也往往是浪費時間的元兇。
但是先把獨立項完成這是無庸置疑的。

再來就是撰寫獨立項的部份，
原文看似建議先完成abstract，然後改寫成獨立項，然後再加附屬項等等等等
後面舉的電子香煙的例子也似乎呼應了這點，
但我覺得重點其實在於如何萃取發明最精華的部份，
再由這部份分別發展成獨立項和摘要，
這個部分是要花時間慢慢琢磨的。
如果只是Abstract本身，沒寫好的影響其實並不會非常大。

原文可惜的地方在於並沒有描述那「一句話主義」的一句話要如何得到。
那其實是一個反覆淬鍊，過濾雜質的過程，
我個人認為是整個撰稿過程中最有趣的部份。

下面分享我常用的方法：
基本上我會先寫一個完整的獨立項，
把我認為實行發明必要的特徵寫進去。
然後在下面用簡單的話描述三樣東西：prior art, problem, solution
prior art不用多說，
problem基本上就是基於prior art的objective technical problem，
solution的部份則寫本發明如何解決問題，以及為什麼問題可以這樣被解決。

理論上solution應該要就是獨立項的技術特徵，但是往往這時會發現一些mismatch，
原因就是在撰寫獨立項時摻了雜質進去。
這些雜質可能是次要的技術特徵，
也可能像前幾天板友討論的，寫進去的根本就是problem的一部分，
換句話說，把目的/效果和技術特徵搞換了。
到這裡就是個信號告訴自己要回頭修正請求項了。
不斷問自己「why does this feature solve the problem?」
也往往可以得到更精華的技術特徵。
反覆個幾次，基本上就可以得到滿意的結果了。
過濾掉的雜質留著，之後再看是要寫成附屬項還是丟進發明內容就好。

接著我會寫一些立刻想到的附屬項的技術特徵，claim dependency則先留白，
這些附屬項多半也可以用類似的problem-solution approach，只是比較具體。
然後我會另開一份文件開始寫說明書細節的部份，保持兩份文件的同步
在這個過程中寫到適合抽象化成claim的特徵就寫進第一份文件中。
說明書細節部分寫完後，第一份文件就可以作為寫成整套claim和發明內容的基礎。
除了關於prior art的部份要特別小心以外(這個前幾天也剛好有板友討論)，
其他寫下來的思考過程都可以為未來進步性的答辯鋪路。

說穿了我用的方法一樣是試圖得到描述發明最精簡的一句話，
但我覺得得到這一句話的重點不只是新穎性而已。
同一個發明概念可能可以用五種不同的「一句話」來描述，
也就是可以用五種不同方式來定義技術特徵，
當然都有新穎性是沒有問題，
但是五種方式在面對進步性的挑戰時，往往就會凸顯出差異。

--