這輩子沒打過官司，破天荒第一遭，其實也不算事主。剛開始只是替老闆出力，盡一點員工本份；沒想到事隔多年，換了兩份工作，依然陰魂不散，還得出席聽證會，幫忙打官司。

起因是過去服務的一家公司（原告），和另一家公司（被告）合作破裂。原告認為對方藉機竊取商業機密，從而在六個月後推出競爭產品，因而提出專利權、著作權等一系列訴訟，纏訟經年。原告大都失利，原因多半歸咎於當年對電腦軟體的智財權法律保障不足。在我涉入那當口，只剩專利侵權官司還在進行。

找我做的是所謂鑑定資料。一般來說，讀法律的法官、律師，對技術細節往往難以掌握，遇上不易釐清的智財權官司，會委託公正第三方進行鑑定，就鑑定結果做出裁決。鑑定資料則是由涉訟雙方提供給鑑定人的法律、技術文件，其中法律部份由律師事務所代勞，技術部份就得自己動手。

兩造老闆是頂尖大學前後期學長、學弟，專利發明人也是該校教授。找我幫忙搞鑑定資料之前，教授的子弟兵早已做出一份詳盡文件，鑑定結果卻不盡理想。律師爭取到重行鑑定的機會，檢討再出發的會議上，認為可能原因之一，是技術文件過於艱澀，沒能讓鑑定人看懂。老闆風聞敝人有些特異功能，便把任務交下來，看有無機會補強。後來我才知道，真正的問題在法律層面。當初的專利請求有些瑕疵、弱點，是一路挨打的主因。但當時的氛圍，大家都想藉技術面坐實侵權指控扳回一城，於是我便著手研究。

軟體本身的功能，簡單說是把使用者輸入的文字，經由程式，以附帶資料表中的描述，畫成圖形輸出；更換資料表，可以得到不同輸出。專利要項的演算法在程式中執行，其變項儲存於資料表，兩者息息相關。由於對手拒絕提供原始碼，前一版鑑定資料的論證手法，是把程式當做黑箱，經由修改資料表中關鍵變項，產生預期輸出結果，從而證明對方採用相同技術，因此侵犯我方專利。以巷仔內看法，不能說不到位；然而隔行隔山的公正第三方，顯然未被說服。

推測可能原因，把程式當做黑箱這回事，或許令鑑定人擔心，會不會以不同演算法，也能得到相同結果（被告即作此主張）。另一方面，限於資料格式和演算法的複雜度，厚厚一本鑑定資料，實際上只舉了兩三個例子，其他依此類推。鑑定人也許懷疑少數樣本的可靠性。於是我便針對這兩方面著手補強。

首先以逆向工程手法，敲開程式黑箱，把執行檔的二進位碼，反組譯成組合語言，重點標示各個模組的功能作用。前版鑑定資料，已經對資料表格式做了徹底剖析，為反組譯鋪好基礎，過程還算順利。其次依照反組譯結果，重新寫一支程式，讀取原來的資料表，依使用者輸入，產生對應結果。最後將反組譯程式碼、新程式及其原始碼，加上兩者的模組對照表、流程圖等，組合成文件付審。於是鑑定人可以任意輸入文字，由新程式產生結果加以觀察，並與原程式交叉比對。服務都做到這樣，鑑定人想必十分開心，於是給了這項專利破天荒第一次，可能也是空前絕後的勝利。

後來我離開那家公司，聽說被告找出專利漏洞，爭取到翻案機會，兩造繼續纏訟。每隔兩三年，會找我出席聽證會，主要是為當初那份文件背書，並針對爭議點補強證據。攻防多半在法律層面，很少徵詢技術意見，因為對方被迫終於繳出原始碼，出入其實不大。以專業眼光，對方應該是自行開發，沒有抄襲剽竊問題；至於是否侵犯專利，則頗有討論空間。

離職八、九年之後，原告法務最後一回找我，說對手再次抓到專利的軟肋，問我能否在技術上找出證據反駁。我看了一會，當下婉拒。那純粹是字義法條上的口舌之爭，讓律師去拗吧，我著實愛莫能助。和科學技術相比，法律的灰色模糊地帶太多，不是我這種簡單頭腦能夠應付的。記得有一回聽證會，被告也找離職多年的工程師回來作證，同樣枯坐半响，講不到幾句話。休息時間咱倆隔空相視一笑，俱感無奈。

倒也不是沒有收穫。每次聽證會前，都由律師或法務進行一兩小時演練，除了複習智財權相關法律概念之外，便是耳提面命，什麼該講什麼不該，當如何講，免得我們這些法律白癡臨時被點名，說錯話要圓，就難了。領車馬費之餘，還能免費上課，倒也不算太吃虧。此後自己申請專利，雖然專利工程師寫出來的東西依舊難懂，「眉角」倒是多少知道一些。那天萬一自己上陣打官司，這些「實戰經驗」，好歹有點幫助吧！

串聯》2015年大家一起拉拉手「我的第一次」