智慧財產及商業法院民事-IPCV,108,民專訴,69,20200326,3

智慧財產法院民事判決
108年度民專訴字第69號
原 告 一零四資訊科技股份有限公司

法定代理人 楊基寬
訴訟代理人 李世章律師
徐念懷律師
彭國洋律師
輔 佐 人 蕭甫明
訴訟代理人 蘇航申
被 告 一二三生活科技股份有限公司

兼法定代理人 李文明
共 同
訴訟代理人 陳和貴律師
楊益昇律師
輔 佐 人 蔡明翰
上列當事人間因侵害專利權有關財產權爭議等事件，本院於中華民國109 年2 月25日言詞辯論終結，判決如下：

主 文

原告之訴及假執行之聲請均駁回。

訴訟費用由原告負擔。

事實及理由甲、當事人之聲明及陳述要旨

壹、原告方面

一、原告為所有中華民國專利證書號第I373717 號「應用整頁編輯框架之求職網站架構及其應用方法」發明專利（下稱：「系爭專利」）之專利權人，被告一二三生活科技股份有限公司（下稱：「被告公司」）在其「yes 123 求職網」上推出「複製104 履歷」功能，足認被告公司為求「104 人力銀行」求職者履歷資料及「yes 123 求職網」求職者履歷資料兩者在編輯系統運作上接合，「yes 123 求職網」內關於履歷管理之編輯設計，必有極高之或然率實施系爭專利之技術特徵。

被告公司「yes 123 求職網」之「履歷管理」項下「修改履歷：我的履歷表」之編輯設計（下稱：「系爭編輯設計」）所採之技術內容，均落入系爭專利請求項1 至18之文義範圍。

又系爭專利並無得撤銷之事由。

二、為此，依專利法第96條第1項、第2項、第97條，公司法第23條第2項等規定，提起本件訴訟，並聲明：（一）被告公司不得使用（民事起訴狀）附件1 所示系爭編輯設計，以及不得為侵害原告所有系爭專利之行為。

（二）被告2 人應連帶給付原告新臺幣（下同）4,536,000 元，以及自本件起訴狀送達之翌日起至清償日止，按週年利率百分之5 計算之利息。

（三）原告願供擔保，請准就第（一）項、第（二）項之訴之聲明宣告假執行。

貳、被告方面

一、系爭專利係由原告於民國（下同）96年10月23日提出申請，原告於101 年3 月27日所為之修正，增加原申請書及圖示中未曾定義的「同一（個）共用框架」、就請求項1 之修正引進申請時該請求項或說明書所無之「欄位具有相同的標記」之技術內容、就請求項10之修正引進申請時該請求項或說明書所無之「欄位具有相同的標記」之技術內容、就請求項11之修正引進申請時該請求項或說明書所無之「欄位具有相同的標記」之技術內容，顯已超越申請時專利說明書所載說明、圖式、申請專利範圍，已變更申請時原申請內容，於法自有未合，系爭專利違反核准時專利法第49條第4項規定而有修正不合法之情形，其所為修正原即不應准許，如經濟部智慧財產局（下稱：「智慧局」）誤為准許並准予專利，該決定於法自有未合，系爭專利即應依核准時專利法第44條規定撤銷，而系爭專利即有智慧財產案件審理法第16條第1項規定所稱「應撤銷原因」。

二、系爭專利說明書及系爭專利請求項1 、10及11多次使用「共用同一個框架」或「同一共用框架」等用語，然該等用語在說明書中並未揭露具體技術內容而有不明確之情形；

原告曾於申復說明書中自承：「『同一共用框架』並非習知之在HTML上將欄位等元件寫在同一個frame 中」。

因此，該「共用同一個框架」或「同一共用框架」等用語，顯非程式設計之習知概念，然系爭專利說明書中，並未具體揭露「同一共用框架」之有別於習知技術之具體技術內容，則該用語難為系爭專利說明及圖式所支持，亦非該發明所屬技術領域中具有通常知識者能了解，實無從據以實施。

綜上，系爭專利違反核准時專利法第26條第2項及第3項規定，有應撤銷之原因。

三、乙證5 可證明系爭專利請求項1 至18不具進步性；乙證7 可證明系爭專利請求項1 至18不具進步性；

乙證5 及乙證7 之組合足以證明系爭專利請求項1 至18不具進步性；

乙證8 及乙證5 或乙證8 及乙證7 均足以證明系爭專利請求項1 至18不具進步性。

四、原告之舉證內容無法證明被告公司系爭編輯設計符合侵權比對之「全要件原則」，故並未落入系爭專利請求項1 至18項之文義範圍。

五、聲明：原告之訴及其假執行之聲請均駁回；如受不利判決，被告願供擔保請准免為假執行。

乙、法官整理兩造爭執及不爭執事項（見本案卷二第169 、171頁）

壹、不爭執事項

一、原告為系爭專利之專利權人。

二、原告主張之「yes123求職網」（下稱：「系爭網站」）為被告所有。

貳、爭執事項

一、系爭專利之修正（101 年3 月27日修正本）是否違反核准時專利法第49條第4項之規定？

二、系爭專利說明書是否違反核准時專利法第26條第2項之規定？

三、系爭專利請求項1 至18是否違反核准時專利法第26條第3項之規定？

四、乙證5 是否足以證明系爭專利請求項1 至18不具進步性？

五、乙證7 或乙證5 及7 之組合，是否足以證明系爭專利請求項1 至18不具進步性？

六、乙證8 及乙證5 或乙證8 及乙證7 之組合，是否足以證明系爭專利請求項1 至18不具進步性？

七、系爭網站是否落入系爭專利之專利權範圍？

八、原告請求被告不得侵害及請求損害賠償，是否有理由？

九、如原告請求損害賠償為有理由，損害賠償額度應為何？丙、得心證之理由

壹、系爭專利有效與否之法律上說明

一、依智慧財產案件審理法第16條第1 、2 項規定，當事人主張或抗辯專利權有應撤銷之原因者，法院應就其主張或抗辯有無理由自為判斷，法院認有撤銷之原因時，專利權人於該民事訴訟中不得對於他造主張權利。

本件被告提出系爭專利違反核准時（99年8 月25日修正公布）專利法第49條第4項、第26條第2項、第3項、第22條第4項等規定之撤銷原因，本院就此抗辯應自為判斷。

二、系爭專利於96年10月23日申請，並於101 年10月1 日公告，依專利法第71條第3項本文規定，系爭專利是否具有應撤銷專利權之情事，應依核准處分時有效之99年8 月25日修正公布之專利法（下稱：「核准時專利法」）為判斷。

三、「專利專責機關於審查發明專利時，得依職權通知申請人限期補充、修正說明書或圖式（第1項）。

申請人得於發明專利申請日起15個月內，申請補充、修正說明書或圖式；

其於15個月後申請補充、修正說明書或圖式者，仍依原申請案公開（第2項）。

申請人於發明專利申請日起15個月後，僅得於下列各款之期日或期間內補充、修正說明書或圖式：一、申請實體審查之同時。

二、申請人以外之人申請實體審查者，於申請案進行實體審查通知送達後3 個月內。

三、專利專責機關於審定前通知申復之期間內。

四、申請再審查之同時，或得補提再審查理由書之期間內（第3項）。

依前三項所為之補充、修正，不得超出申請時原說明書或圖式所揭露之範圍（第4項）」，核准時專利法第49條第1項至第4項定有明文。

四、發明說明應明確且充分揭露，使該發明所屬技術領域中具有通常知識者，能瞭解其內容，並可據以實施（核准時專利法第26條第2項規定參照）。

五、申請專利範圍應明確記載申請專利之發明，各請求項應以簡潔之方式記載，且必須為發明說明及圖式所支持（核准時專利法第26條第3項規定參照）。

六、發明為其所屬技術領域中具有通常知識者依申請前之先前技術所能輕易完成時，仍不得依本法申請取得發明專利（核准時專利法第22條第4項規定參照）。

七、發明申請案違反前揭同法相關規定者，應為不予專利之審定，復為核准時專利法第44條所明定。

又系爭專利有無違反前述所定情事而應撤銷其發明專利權，依同法第67條第1項及第2項後段規定，應由主張系爭專利無效之人即被告負舉證責任。

貳、系爭專利技術分析

一、技術內容（見本案卷一第235 頁摘要）：系爭專利係提供一種應用整頁編輯框架之求職網站架構及其應用方法，其包括一網路平台及一後端伺服器，在後端伺服器中使用共用框架之一顯示資料控制器及一編輯介面控制器，使每一編輯介面及欄位皆共用框架，當用戶端欲編輯、增減或抽換欄位時，編輯介面控制器僅針對將被變更之欄位跳出編輯介面以供用戶端進行修改，顯示資料控制器並將用戶端確認變更之欄位更新，再顯示於網路平台上，藉此減少資料傳輸量並簡化編輯之步驟。

二、主要圖式（見本案卷一第245至248頁）：第1 圖為應用整頁編輯框架之架構流程圖；

第2 圖為用戶端選擇語言項目進行編輯時之電腦畫面；

第3 圖為用戶端編輯完成後傳輸資料時之電腦畫面；

第4 圖為用戶端預覽畫面更新完成之電腦畫面。

三、申請專利範圍分析：系爭專利申請專利範圍共計18項請求項，其中請求項1 、10為獨立項，其餘均為附屬項，其內容依序如下（見本案卷一第242 至244 頁）：

（一）請求項1 ：一種應用整頁編輯框架之求職網站架構，包括：一網路平台，提供一用戶端登入，進入該網路平台之編輯模式後可在一預覽欄位上選取一編輯介面以進行編輯；

以及一後端伺服器，連接該網路平台，該後端伺服器中包括：一編輯介面控制器，控制該編輯介面中之複數欄位依照該用戶端所需任意排列及抽換，其中該編輯介面係使用同一共用框架，使該等欄位具有相同的標記；

以及一顯示資料控制器，顯示該用戶端所選取之該編輯介面於該網路平台上，並在該編輯介面完成編輯後顯示在該網路平台上。

（二）請求項2 ：如申請專利範圍第1項所述之應用整頁編輯框架之求職網站架構，其中該網路平台中包含一動態資料處理器，將該用戶端在該網路平台上之動作傳送到該後端伺服器。

（三）請求項3 ：如申請專利範圍第2項所述之應用整頁編輯框架之求職網站架構，其中該後端伺服器中更包括一函式庫，該動態資料處理器呼叫該函式庫以對該後端伺服器中之該共用框架進行處理。

（四）請求項4 ：如申請專利範圍第1項所述之應用整頁編輯框架之求職網站架構，其中該編輯介面中之複數欄位增減或編輯時，該編輯介面控制器利用該共用框架將該編輯介面更新。

（五）請求項5 ：如申請專利範圍第1項所述之應用整頁編輯框架之求職網站架構，其中該編輯介面係共用一組動態程式碼。

（六）請求項6 ：如申請專利範圍第1項所述之應用整頁編輯框架之求職網站架構，其中每一該欄位各有一組動態程式碼，於編輯時可自動載入執行。

（七）請求項7 ：如申請專利範圍第6項所述之應用整頁編輯框架之求職網站架構，其中該動態程式碼係依照該欄位之功能命名。

（八）請求項8 ：如申請專利範圍第2項所述之應用整頁編輯框架之求職網站架構，其中該動態資料處理器係分析該編輯介面中被修改之該欄位，並在該編輯介面控制器中載入該欄位以進行修改，再將修改後之該編輯介面顯示於該網路平台上以供該用戶端確認。

（九）請求項9 ：如申請專利範圍第5項或第6項所述之應用整頁編輯框架之求職網站架構，其中該動態程式碼係使用ajax語法。

（十）請求項10：一種整頁編輯框架應用於求職網站之方法，提供一用戶端於一求職網站之一網路平台上編輯，並利用一後端伺服器進行處理之方法，包括下列步驟：該用戶端登入該網路平台並進入編輯模式後，選取一預覽欄位中之複數編輯介面其中之一，複數該編輯介面係使用同一共用框架，使該等欄位具有相同的標記；

該後端伺服器中一顯示資料控制器將選取之該編輯介面顯示於該網路平台上；

以及該用戶端於該網路平台上編輯該編輯介面，利用該後端伺服器中一編輯介面控制器處理，控制該編輯介面中之小複數欄位依照該用戶端所需任意排列及抽換後，將經編輯之該預覽欄位顯示於該網路平台上。

（十一）請求項11：如申請專利範圍第10項所述之整頁編輯框架應用於求職網站之方法，其中該編輯介面控制器及該顯示資料控制器之程式碼係使用同一共用框架，使該等欄位具有相同的標記，當該編輯介面控制器及該顯示資料控制器運作時依該標記找到該等欄位的一元件位置。

（十二）請求項12：如申請專利範圍第10項所述之整頁編輯框架應用於求職網站之方法，其中該網路平台利用一動態資料處理器將該用戶端在該網路平台上之動作傳送到該後端伺服器。

（十三）請求項13：如申請專利範圍第12項所述之整頁編輯框架應用於求職網站之方法，其中該後端伺服器中更包括一函式庫，該動態資料處理器呼叫該函式庫以對該後端伺服器中之該共用框架進行處理。

（十四）請求項14：如申請專利範圍第10項所述之整頁編輯框架應用於求職網站之方法，其中該編輯介面中之該小欄位增減或編輯時，該編輯介面控制器利用該共用框架將該編輯介面更新。

（十五）請求項15：如申請專利範圍第10項所述之整頁編輯框架應用於求職網站之方法，其中該編輯介面係共用一組動態程式碼。

（十六）請求項16：如申請專利範圍第10項所述之整頁編輯框架應用於求職網站之方法，其中每一該小欄位各有一組動態程式碼，且該動態程式碼係依照該小欄位之功能命名，於編輯時可自動載入執行該動態程式碼。

（十七）請求項17：如申請專利範圍第12項所述之整頁編輯框架應用於求職網站之方法，其中該動態資料處理器係分析該編輯介面中被修改之該小欄位，並在該編輯介面控制器中載入該小欄位以進行修改，再將修改後之該編輯介面顯示於該網路平台上以供該用戶端確認。

（十八）請求項18：如申請專利範圍第15項或第16項所述之整頁編輯框架應用於求職網站之方法，其中該動態程式碼係使用ajax語法。

參、被告所提之引證資料

一、乙證5 「Ajax開發精要」書籍部分影本（見本案卷一第363至383 頁）：乙證5 於95年7 月出版，其公開日期早於系爭專利申請日96年10月23日，可為系爭專利之相關先前技術。

乙證5 第3 頁揭露Ajax係多種技術綜合或設計方式，包括Javascript、XHTML 和CSS 、DOM 、XML 和XSTL、XMLHttpRequest等技術。

第4 、5 頁則揭露典型瀏覽器中Ajax應用之生命週期，包含用戶訪問、頁面初始化、觸發瀏覽器事件、向伺服器發出請求、伺服器處理請求、伺服器回應請求及瀏覽器更新頁面。

二、乙證7 「Ajax設計模式」書籍部分影本（見本案卷一第501至552 頁、本案卷二第315 至353 頁乙證7-1 附錄A 記載Ajax框架和函式庫）：乙證7 於95年12月出版，其公開日期早於系爭專利申請日96年10月23日，可為系爭專利之相關先前技術。

乙證7 第14頁揭露「HTML提供網頁的結構，Ajax應用程式使用HTML文件顯示初始頁面，並且該文件持續被操控，以改變顯示內容並建立新事件」。

乙證7 圖5-6 及第84頁揭露「透過DOM 操控，增加、移除、移動、覆蓋元素。

DOM 是定義元件彼此如何相關的階層結構。

透過調整DOM 結構，你能夠調整元素出現在頁面上的位置」。

三、乙證8 則為系爭專利之說明書（見本案卷二第355 至359 頁）。

肆、申請專利範圍解釋

一、按「發明專利權範圍，以說明書所載之申請專利範圍為準，於解釋申請專利範圍時，並得審酌說明書及圖式」，核准時專利法第58條第3項定有明文。

又「由於文字用語之多義性及理解的易誤性，故系爭發明申請專利範圍之文字用語當然會有多種解釋之可能，於必要時，自得參酌發明說明或圖式，以求其所屬技術領域中具有通常知識者可以理解及認定之意涵。

再者，解釋申請專利範圍係比對專利要件之前提程序，必確定申請專利範圍之文義或結構、技術後，始能再加以比對與引證案之差異，且解釋申請專利範圍係屬法院之職權，並不以當事人爭執為限」（最高行政法院106 年度判字第351 號判決意旨參照）」。

而「在解釋申請專利範圍時，發明說明及圖式係立於從屬地位，未曾記載於申請專利範圍之事項，固不在保護範圍之內；

惟說明書所載之申請專利範圍通常僅就請求保護範圍為必要之敘述，或有未臻明確之處，自不應侷限於申請專利範圍之字面意義，而應參考其專利說明書及圖式，以瞭解其目的、技術內容、特點及功效，據以界定其實質內容。

解釋申請專利範圍，得參酌內部證據與外部證據，前者係指請求項之文字、發明說明、圖式及申請歷史檔案；

後者指內部證據以外之其他證據。

例如，創作人之其他論文著作與其他專利、相關前案、專家證人之見解、該發明所屬技術領域中具有通常知識者之觀點、權威著作、字典、專業辭典、工具書、教科書等，並以內部證據之適用為優先」（最高行政法院103 年度判字第417 號判決意旨參照）。

二、系爭專利請求項1、10之用語解釋：

（一）「整頁編輯框架」應解釋為「整個網頁資料的編輯功能使用相同的網頁開發架構」： 1、依系爭專利說明書第5 頁【先前技術】所載「…於網站上需要三種編輯模式…傳統方式有兩種，其一為整頁編輯，將所有相關資料整個帶出到編輯介面…」（見本案卷一第237 頁），可知「整頁編輯」係指整個網頁資料都可在編輯介面中加以編輯；

復依系爭專利說明書第8 頁第2 、3段「本發明提供之共用框架結構在同一預覽欄位中之所有編輯介面使用共同框架…」、「本發明中共同框架可使用ajax語法撰寫」、「本發明所提供之應用整頁編輯框架之求職網站架構及其應用方法係利用共用框架技術，將每個欄位元件化…」（見本案卷一第240 頁），可知系爭專利係針對同一預覽欄位中之所有編輯介面均採用相同之網頁開發架構或設計模式，例如ajax，因此可共用程式碼，故系爭專利請求項1 、10之「整頁編輯框架」應解釋為「整個網頁資料的編輯功能使用相同的網頁開發架構」。

2、原告主張應將「整頁編輯框架」中之「框架」，適用維基百科之「軟體框架」解釋定義云云（見本案卷二第44、176 、258 頁）。

惟原告並未將「整頁編輯」與「框架」併為解釋；

復依維基百科對於「軟體框架」之解釋乃「通常指的是為了實現某個業界標準或完成特定基本任務的軟體組件規範，也指為了實現某個軟體組件規範時，提供規範所要求之基礎功能的軟體產品」（https ：//zh .wikipedia .org/wiki/%E8 %BB%9F %E9%AB %94%E6 %A1%86%E6%9E%B6）。

爰參酌系爭專利內部證據後，將「整頁編輯框架」解釋為「整個網頁資料的編輯功能使用相同的網頁開發架構」，此與前述維基百科對於軟體框架之解釋，並無衝突。

（二）「編輯模式」應解釋為「該網路平台提供該用戶可對頁面各欄位資料進行編輯動作之功能」： 1、依系爭專利請求項1 、10之上下文「進入該網路平台之『編輯模式』後可在一預覽欄位上選取一編輯介面以進行編輯」、「該用戶端登入該網路平台並進入編輯模式後，選取一預覽欄位中之複數編輯介面其中之一」，以及說明書第8 頁第1 、2 行「…用戶端進入求職網站之網路平台，進入編輯模式後，整頁預覽，並可在預覽欄位中任意選擇要編輯者，當選出愈編輯之項目後…」（見本案卷一第240 頁）。

可知系爭專利請求項1 、10「編輯模式」係指可啟動對於頁面中各欄位資料予以編輯（例如新增、修改、刪除等動作）之功能，異於一般僅供用戶端閱覽而無法編輯之唯讀模式。

2、原告主張「編輯模式」指「應用程式提供編輯介面，使使用者能夠進行編輯動作」云云（見本案卷二第45頁）；

被告則將之解釋為「讓用戶端進行網頁表單（form）之資料輸入及提交/ 發送」等語（見本案卷二第78頁）。

惟系爭專利請求項1 、10中並未提及原告所述之「應用程式」或被告所述之「網頁表單」，故不應將之納為解釋內容而將請求項範圍作無謂之限縮解釋。

（三）「編輯介面」應解釋為「該網路平台供該用戶對頁面各欄位資料進行編輯動作之操作頁面」： 1、承前關於「編輯模式」之解釋，編輯介面係指該網路平台提供該用戶對於頁面各欄位資料進行編輯動作之操作頁面。

2、原告主張「編輯介面」係指「超文本標記語言（HTML）所構成之可供使用者操作表單等介面」云云（見本案卷二第45頁）；

被告則主張應解釋為「用戶端進行資料輸入用之網頁表單」等語（見本案卷二第78頁）。

惟系爭專利請求項1 、10之內容，並未提及原告所述之「超文本標記語言」或被告所述之「網頁表單」；

又「編輯」並非僅限於被告所述之「資料輸入」動作，尚包含重新排列、刪除等動作。

（四）「預覽欄位」應解釋為「用戶進入編輯模式後，該網路平台顯示供該用戶閱覽之頁面欄位」： 1、依系爭專利請求項1 、10之上下文「進入該網路平台之編輯模式後可在一『預覽欄位』上選取一編輯介面以進行編輯」、「該用戶端登入該網路平台並進入編輯模式後，選取一『預覽欄位』中之複數編輯介面其中之一」，以及說明書第8 頁第1 、2 行「…用戶端進入求職網站之網路平台，進入編輯模式後，整頁預覽，並可在『預覽欄位』中任意選擇要編輯者，當選出愈編輯之項目後…」（見本案卷一第240 頁）。

可知預覽欄位係指「用戶進入編輯模式後，該網路平台所顯示供該用戶閱覽之頁面欄位」，使得該用戶後續可於該頁面欄位中任意選擇其所欲進行編輯之項目。

2、原告主張「預覽欄位」係指「超文本標記語言（HTML）所構成，能表現資訊內容等欄位」云云（見本案卷二第45頁）。

被告則主張應解釋為「包含不同區塊之唯讀頁面內容」等語（見本案卷二第78頁）。

惟系爭專利請求項1 、10之內容，並未提及原告所述之「超文本標記語言」或被告所述之「不同區塊」；

況且原告之解釋並未將「預覽」之意義涵蓋在內。

（五）「該編輯介面係使用同一共同框架」、「使該等欄位具有相同的標記」係解釋為「網路平台上供用戶對頁面各欄位資料進行編輯動作之操作頁面，係使用相同的網頁開發架構，使得各欄位具有相同的標籤（tag ）（或其屬性（attribute ））」： 1、承前關於「編輯介面」之解釋，編輯介面係指用戶登入網路平台並啟動編輯功能（進入編輯模式）後，該網路平台提供該用戶對於頁面各欄位資料進行編輯動作之操作頁面。

而使用「同一共同框架」則如前述「整頁編輯框架」之解釋，即指各欄位資料之編輯介面均採用相同的網頁開發架構。

至於「使該等欄位具有相同的『標記』」，當指頁面中欄位採用超文本標記語言中之相同的標籤（tag ）（或其屬性（attribute ）），可使編輯介面控制器及顯示資料控制器運作時，循該標記或標籤找到欄位的元件位置（見本案卷一第239 頁系爭專利說明書第7 頁第2 段）。

2、原告將「編輯介面係使用同一共同框架」解釋為「編輯介面與框架存在合作關係」云云（見本案卷二第45頁），但何謂「存在合作關係」，實難以理解。

被告則主張「編輯介面係使用同一共同框架」應解釋為「在一個ajax開發框架中，對網頁表單進行資料輸入或提交」等語（見本案卷二第78頁），但系爭專利請求項1 、10中，並未以ajax開發框架為限，且編輯介面並非僅限於供使用者進行資料輸入或提交之動作。

三、系爭專利請求項2 、3 、8 、12、13及17之「動態資料處理器」：依系爭專利請求項2 所載，其界定「動態資料處理器」之功能係「將用戶端在網路平台上之動作傳送到該後端伺服器」，意即動態資料處理器為能將用戶操作網路平台之事件（event ）（例如點擊滑鼠）傳送至伺服器之程式模組，自應將之解釋為「網路平台中能將用戶端操作該網路平台之事件（event ）傳送至後端伺服器之程式模組」。

四、系爭專利請求項3 、13之「對該後端伺服器中之該共同框架進行處理」應解釋為「後端伺服器中之函式庫以相同的網頁開發架構回應動態資料處理器之請求」：

（一）依系爭專利請求項3 、13之附屬技術特徵所載「該後端伺服器中更包括一函式庫，該動態資料處理器呼叫該函式庫以對該後端伺服器中之該共用框架進行處理」，及其所依附之請求項2 、12等相關內容，可知動態資料處理器會呼叫後端伺服器中之函式庫，該函式庫則以相同之網頁開發架構，來回應動態資料處理器之請求。

（二）對於前述用語，原告僅解釋其在說明函式庫對應互動之對象為何，但仍未說明「進行處理」所指為何，是以其解釋內容並不可採。

被告則解釋為「在伺服器中以ajax開發框架處理http（或https ）請求」，然系爭專利請求項3 、13，並未限制採用ajax開發框架，自不得將之讀入於請求項解釋內容中。

五、系爭專利請求項5 至7 、9 、15、16及18之「動態程式碼」：參酌系爭專利說明書第5 頁倒數第2 、3 行「…每一欄位可由動態程式碼自行載入執行…」（見本案卷一第237 頁）及系爭專利請求項6 、16「…動態程式碼，於編輯時可自動載入執行」、「…動態程式碼係依照該小欄位之功能命名，於編輯時可自動載入執行該動態程式碼」，可知系爭專利之「動態程式碼」應解釋為「經特定事件觸發後始加以執行之程式碼」。

六、系爭專利請求項11之「程式碼係使用同一共同框架，使該等欄位具有相同的標記」：

（一）關於「使用同一共同框架」、「使該等欄位具有相同的標記」，其解釋詳如前述。

另依系爭專利請求項11之上下文所載，可知其係指編輯介面控制器及該顯示資料控制器之程式碼係採用相同之網頁開發架構，使得各欄位具有相同的標籤（tag ）（或其屬性（attribute ）），藉此，當編輯介面控制器及顯示資料控制器運作時，得依該標記找到該等欄位的元件位置，是應解釋為「編輯介面控制器及顯示資料控制器之程式碼係採用相同的網頁開發架構，使得各欄位具有相同的標籤（tag ）（或其屬性（attribute ））」。

（二）原告將之解釋為編輯介面控制器及顯示資料控制器也是框架定義的一環並有合作關係，開發設計上須讓欄位有共同標記，才能讓框架內之組件查找云云（見本案卷二第48頁），惟其所稱之「合作關係」為何，顯有疑義。

被告則主張前述用語中之「程式碼係使用同一共同框架」應解釋為「以ajax作為開發框架來進行http（或https ）請求，以呼叫程式碼」，惟系爭專利請求項11中，並未以ajax開發框架為限，且由系爭專利請求項11之上下文，並未見有呼叫程式碼之動作或功能，當無法依此加以解釋。

七、系爭專利請求項4 、14之「編輯介面控制器利用該共同框架」：

（一）系爭專利請求項4 、14係各自依附於請求項1 、10，是以系爭專利請求項4 、14所指之「該共同框架」當指請求項1 、10中編輯介面所使用之「同一共同框架」而言。

故如前述系爭專利請求項1 、10之「同一共同框架」解釋，系爭專利請求項4 、14之前述用語，應解釋為「編輯介面控制器係（與編輯介面）使用相同的網頁開發架構」。

（二）原告將之解釋為「系爭專利精神在於動態效果，當預覽內容時，動態切換為編輯模式，程式帶出編輯介面，而此編輯介面一樣在該共同框架的管理協助之下」云云（見本案卷二第49頁），惟原告之前述解釋內容，顯已逸脫系爭專利請求項4 、14之文義內容。

另被告將之解釋為「伺服器端之軟體程式，在ajax框架下，對網頁表單（form）進行資料之輸入及提交」，惟系爭專利請求項4 、14並未限於ajax框架，亦未提及表單，是其解釋亦不可採。

伍、系爭專利101 年3 月27日之修正（見本案卷一第319 至326頁乙證3 修正本）違反核准時專利法第49條第4項之規定：

一、按「專利專責機關於審查發明專利時，得依職權通知申請人限期補充、修正說明書或圖式（第1項）。

申請人得於發明專利申請日起15個月內，申請補充、修正說明書或圖式；

其於15個月後申請補充、修正說明書或圖式者，仍依原申請案公開（第2項）。

申請人於發明專利申請日起15個月後，僅得於下列各款之期日或期間內補充、修正說明書或圖式：一、申請實體審查之同時。

二、申請人以外之人申請實體審查者，於申請案進行實體審查通知送達後3 個月內。

三、專利專責機關於審定前通知申復之期間內。

四、申請再審查之同時，或得補提再審查理由書之期間內（第3項）。

依前三項所為之補充、修正，不得超出申請時原說明書或圖式所揭露之範圍（第4項）」，核准時專利法第49條第1項至第4項定有明文。

二、次按：「發明專利權範圍，以說明書所載之申請專利範圍為準，於解釋申請專利範圍時，並得審酌說明書及圖式」，核准時專利法第58條第3項定有明文。

復按：「申請案於審定前，雖然對於據以取得申請日之原說明書或圖式得進行補充、修正，但補充、修正之結果，不得增加其所未揭露之事項，亦即不得增加新事項（new matter）。

審查時，應以補充、修正後之說明書或圖式與原說明書或圖式比較，若其超出原說明書或圖式所揭露之範圍，應以核駁理由先行通知書敘明理由通知申請人限期再行補充、修正；

屆期未補充、修正者，則以違反專利法第49條第4項之規定為理由，予以核駁審定。

對於說明書或圖式補充、修正之審查，係判斷補充、修正後之說明書或圖式內容是否符合專利法第49條第4項所規定『不得超出申請時原說明書或圖式所揭露之範圍』。

原說明書或圖式所揭露之範圍，指申請當日已明確記載（明顯呈現）於原說明書或圖式（不包括優先權證明文件）中之全部事項，或該發明所屬技術領域中具有通常知識者自原說明書或圖式所記載事項能直接且無歧異（directly and unambiguously）得知者，因此並不侷限於逐字逐句解釋說明書或圖式所記載之文字意思。

該發明所屬技術領域中具有通常知識者自原說明書或圖式所記載事項能直接且無歧異得知者，係指該發明所屬技術領域中具有通常知識者自原說明書或圖式所記載之事項，若能明確得知（或不懷疑）其已經單獨隱含（solely implies）或整體隱含（collectively imply）補充、修正後之說明書或圖式所記載之固有的特定事項（specific matter ），而沒有隱含其他事項，則該固有的特定事項（例如單一技術特徵、複數技術特徵、功效或實施例等）係能直接且無歧異得知者。

此外，補充、修正後的事項若僅是在表達上不同於原說明書或圖式所記載之事項，但能被判斷為兩者均是敘述同一事項時，該事項可認為是該發明所屬技術領域中具有通常知識者自原說明書或圖式所記載事項能直接且無歧異得知者。

惟若原說明書或圖式所記載之事項可能隱含多數個意義，縱使補充、修正後之事項雖屬於其中的一個或某些個意義，但由於該一個或某些個意義並非補充、修正前所明確定義的特定事項，則補充、修正後所限定之事項不得認為係由原說明書或圖式即能直接且無歧異得知者。

補充、修正後之事項超出原說明書或圖式所揭露範圍者，包括非原說明書或圖式明確記載之事項（例如相反的或增加的事項），以及該發明所屬技術領域中具有通常知識者不能自原說明書或圖式記載之事項直接且無歧異得知者，即可判斷為引進了新事項」，100 年版智慧局發明專利審查基準亦同此見解（見本案卷一第327 、328 頁乙證4 ）。

準此，修正說明書、申請專利範圍、圖式係於申請專利案「審定前」為之，且修正案得援用原申請專利案之申請日，為平衡申請人及社會公眾的利益，並兼顧先申請原則及未來取得權利的安定性，避免變動後之記載內容增加新事項（new matter），影響社會公眾之權益，依前述核准時專利法第49條第4項規定，修正應僅限定在申請時說明書、申請專利範圍及圖式所揭露之範圍內始得為之，100 年版智慧局發明專利審查基準，亦同此見解。

三、經查：原告於101 年3 月27日向智慧局提出系爭專利之說明書修正頁，以及申請專利範圍修正本，其修正內容為：

（一）於申請時說明書第7 頁第2 段「…使用同一共同框架」後方（見本案卷一第297 頁），增加「使用同一個共用框架的意義在於標記的共同協定，使該等欄位具有相同的標記，當編輯介面控制器及顯示資料控制器運作時，可依標記找到欄位的元件位置」（見本案卷一第321 頁）。

（二）於申請時請求項1 、10「…編輯介面係使用同一共同框架」後方（見本案卷一第305 頁），增加「使該等欄位具有相同的標記」文字內容（見本案卷一第325 頁）。

（三）於申請時請求項11「…使用同一共同框架」後方（見本案卷一第305 頁），增加「使該等欄位具有相同的標記，當該編輯介面控制器及該顯示資料控制器運作時依該標記找到該等欄位的一元件位置」文字內容（見本案卷一第325頁）。

四、由上可知，系爭專利101 年3 月27日之修正內容，主要係針對「使用同一共同框架」進行說明，其敘明以「欄位具有相同標記」為技術手段，編輯介面控制器及顯示資料控制器可循該標記尋得欄位的元件位置。

五、惟遍查系爭專利申請時原說明書或圖式，並未見有「標記」一詞，遑論其與不同欄位間之關係，甚或是否屬於「使用同一共同框架」技術手段之一。

且依系爭專利申請時原說明書或圖式對於「使用同一框架」之相關說明：如【發明內容】部分，說明書第5 頁載明「…係利用共同框架將具關聯性之欄位放在同一個框架中，此共用框架並具有一組動態呈現及動態編輯之功能，並可結合及分享原有程式碼之存取及呼叫」（見本案卷一第293 頁）。

依系爭專利申請時原說明書【實施方式】部分，說明書第8 頁第2 段載明「…使用共同框架，因此可動態呈現及動態編輯，…由於每一種語言之小欄位皆相同，…，因此不需重複撰寫每一種語言之小欄位的程式碼，而是共用類似部份之程式碼…」（見本案卷一第299頁），可知系爭專利申請時原說明書或圖式，對於同一框架之使用，係指不同欄位間就相同或類似程式碼或函式的共用。

準此，系爭專利101 年3 月27日修正所增加之「欄位具有相同標記」等相關技術特徵，並非申請時說明書、圖式所明確記載之技術手段，且所屬技術領域中具有通常知識者，由申請時原說明書、圖式所揭露之範圍，僅能得知係以程式碼或函式之共用，來達成同一共同框架下，不需重複撰寫程式碼之優點或功效。

是以，系爭專利101 年3 月27日修正所新增之「使得欄位具有相同標記」相關技術內容，並非所屬技術領域中具有通常知識者，由申請時原說明書或圖式所能直接且無歧異得知者，故該修正內容，業已超出申請時原說明書或圖式所揭露之範圍。

因前述修正內容，涉及系爭專利發明說明及請求項1 、10、11，而請求項2 至9 係請求項1 之附屬項，請求項12至18係請求項10之附屬項，均包含獨立項1 、10之修正內容在內，故系爭專利請求項1 至18及對應之發明說明修正內容，均超出申請時原說明書或圖式所揭露之範圍，違反核准時專利法第49條第4項規定，而有應撤銷之原因。

六、原告陳稱：由系爭專利之發明名稱係應用於「網站架構」，可直接無歧異認定係使用超文本標記語言（HTML），而系爭專利原說明書第5 頁既提及「…共同框架將關聯性之欄位放在同一個框架中…」，所屬技術領域中具有通常知識者就不同欄位彼此間是否具關聯性之判斷，必然以其欄位上是否作相同標記為據。

再者，系爭專利說明書第8 頁內容已指出關聯性欄位會動態在框架中抽換，框架並非解釋何為關聯性欄位之依據。

另系爭專利第2 圖中顯示「語言」及「方言」欄位係屬關聯性欄位，在程序語言中即需透過欄位之程式標記使其具備關聯性。

故系爭專利之修正並未違反核准時專利法第26條第2 、3 項之規定云云（見本案卷一第419 頁第24行至第421 頁第1 行、本案卷二第404 、405 頁）。

而被告則陳稱：系爭專利修正後新增了對於「同一共用框架」之技術內容，暫不論「同一共用框架」乙詞是否明確，但此新增之技術內容並非系爭專利申請時發明說明及圖式已揭露之技術特徵（例如：系爭專利申請時專利說明書並未揭露「標記」之技術內容，但系爭專利修正後卻新增「標記的共同協定」、「欄位具有相同的標記」、「可依標記找到欄位的元件位置」等技術內容），則該發明所屬技術領域中具有通常知識者實無法從原說明書或圖式所記載之事項直接且無歧異得知該新增之技術內容，而屬「引進新事項」之情形，依系爭專利核准時有效之專利審查基準所載（乙證4 號），該修正內容即不應允許；

單就申請專利範圍第1項而言，其修正引進申請時該請求項或說明書所無之「欄位具有相同的標記」之技術內容，已實質超出申請時之內容；

單就申請專利範圍第10項而言，其修正引進申請時該請求項或說明書所無之「欄位具有相同的標記」之技術內容，已實質超出申請時之內容；

單就申請專利範圍第11項而言，其修正引進申請時該請求項或說明書所無之「欄位具有相同的標記」之技術內容，已實質超出申請時之內容等語（見本案卷一第253 至257 頁）。

經查：

（一）被告抗辯系爭專利因修正超出申請時原說明書或圖式所揭露之範圍，違反核准時專利法第49條第4項之規定，此與同法第26條第2 、3 項有關發明說明應充分揭露、申請專利範圍須為發明說明及圖式所支持，分屬不同專利要件。

原告將之混為一談，顯有誤會。

（二）依系爭專利申請時原說明書第5 頁「…係利用共同框架將具關聯性之欄位放在同一框架中，此共用框架並具有一組動態呈現及動態編輯之功能，並可結合及分享原有程式碼之存取與呼叫」內容（見本案卷一第293 頁），可知其僅描述將關聯性之欄位放在同一框架中之目的或優點，在於「結合及分享原有程式碼之存取與呼叫」，可見所謂「關聯性之欄位」在申請時原說明書係指可用相同程式碼或函式之欄位而言，與標記無涉。

復依系爭專利申請時圖式第2 圖（見本案卷一第311 頁），及申請時原說明書第8 頁相關說明「…編輯介面18中包含『語言』及『方言』兩種，並包含至少一種語言及聽、說、讀、寫等小欄位20…共用框架中相同功能之程式碼不需重複撰寫，例如用戶端在編輯語言項目且欲新增一種語言時，由於每一種語言之小欄位皆相同，都包括聽、說、讀、寫，因此不需重複撰寫每一種語言之小欄位的程式碼，而是共用類似部分之程式碼…」（見本案卷一第299 頁），可知「語言」及「方言」欄位係因小欄位（使用者均需各別就聽、說、讀、寫能力程度進行選擇）共通而具備關聯性，而既「語言」與「方言」欄位的小欄位共通，自可呼叫或引用相同的小欄位程式碼。

意即依系爭專利申請時原說明書、圖式所載，不同欄位（「語言」與「方言」）間之關聯性，係因其性質上可使用相同小欄位所致，並非因欄位上具有相同標記才被認定為關聯性欄位。

況且，系爭專利申請時原說明書、圖式並未提及「標記」，而是教示關聯性欄位「語言」及「方言」的共通小欄位，可使用相同的程式碼，所屬技術領域中具有通常知識者當無法直接且無歧異（directly and unambiguously）得知不同欄位具有相同標記，方能認定為關聯性欄位。

陸、乙證7 或乙證5 及7 之組合或乙證7 及8 之組合，均足以證明系爭專利請求項1 至18不具進步性：

一、按凡利用自然法則之技術思想之創作，且可供產業上利用者，依法得申請取得發明專利，固為核准時專利法第21條、第22條第1項前段所規定；

但發明如為其所屬技術領域中具有通常知識者依申請前之先前技術所能輕易完成時，仍不得依本法申請取得發明專利，同法第22條第4項亦有明文。

次按：「發明為所屬技術領域中具有通常知識者依據申請前之先前技術所能輕易完成者，該發明即不具進步性。

惟進步性之判斷應就申請專利之發明整體為之，非僅針對個別或部分技術特徵。

若該發明所屬技術領域中具有通常知識者依據先前技術，並參酌申請時之通常知識，顯然可能促使其組合、修飾、置換或轉用先前技術而完成申請專利之發明者，應認該發明不具進步性。

而二件以上之先前技術與申請專利之發明屬相同或相關之技術領域，所欲解決之問題、功能或作用相近或具關連性，且為申請專利之發明所屬技術領域具通常知識者可輕易得知，而有合理組合動機，且申請專利之專利技術內容，可為該等組合所能輕易完成者，則該等先前技術之組合可據以認定該申請專利之發明不具進步性」（最高法院104 年度臺上字第1111號、103 年度臺上字第906 號、102年度臺上字第427 號民事判決意旨參照）。

如「系爭發明與舉發證據間所存在之差異，為系爭發明之重要技術特徵者，審查時應就該技術特徵是否為舉發證據所揭露，或該技術特徵是否為該發明所屬技術領域中具通常知識者，以轉用、置換、改變或組合舉發證據等方式所能輕易完成等情，詳加審酌」（最高行政法院109 年度判字第29號判決意旨參照）。

二、比對系爭專利請求項1 與乙證7 之技術內容：

（一）查乙證7 第16、17頁（見本案卷一第517 、518 頁）圖1-4、1-5 及其相關說明，已揭露使用者將瀏覽器指向Ajax應用程式，而當使用者之動作引發事件後，藉由事件處理器傳送請求給伺服器，即對應揭露系爭專利請求項1 之「一網路平台，提供一用戶端登入…」及「一後端伺服器，連接該網路平台…」之技術特徵。

此外，乙證7 第83、84頁（見本案卷一第521 、522 頁），揭露可透過調整DOM（文件物件模型）結構，以增加、移除、移動、覆蓋元素，藉以調整各元素出現在頁面上的位置。

乙證7 第426 至429 頁（見本案卷一第535 至538 頁），揭露可提供Drag-And-Drop （拖曳與放置）機制，讓使用者直接重新安排頁面上的元素。

乙證7 第444 、445 頁（見本案卷一第541 、542 頁）揭露可建立由Malleable Content （延展性內容）區塊所構成的頁面，即一小塊、一小塊可以在頁面裡編輯的內容區塊，每個皆可獨立編輯。

前述乙證7 所揭露之內容，均提及可供用戶端自行調整或編輯頁面內容，即對應揭露系爭專利請求項1 之「進入該網路平台之編輯模式後可在一預覽欄位上選取一編輯介面以進行編輯」、「一編輯介面控制器，控制該編輯介面中之複數欄位依照該用戶端所需任意排列及抽換」等技術特徵。

（二）乙證7 全篇係以Ajax為開發架構，另乙證7-1 第623 頁起（見本案卷二第315 頁起）附有Ajax框架及函式庫說明（等同於系爭專利之同一共同框架），且乙證7 第444 、445 頁（見本案卷一第541 、542 頁）記載Malleable Content （延展性內容），其會將頁面切分為多個區塊，又乙證7 第14、15頁HTML/XHTML段落記載Ajax技術以超文本"標記" 語言HTML顯示頁面，所屬技術領域領域具有通常知識可輕易選擇以div 標記來分割複數區塊，且乙證7 第446 頁（見本案卷一第543 頁）第3 段，揭露「每個區塊的Malleable Content 是div 或textarea元素」、第451 頁（見本案卷一第548 頁）的程式碼範例，揭露「將頁面內容分析成一些Malleable Content 區塊，單一的div 被宣告在初始HTML裡，以保存這些區塊：< di vid="messages"> < /div>」，其所指之div 元素或< div> < /div > 標籤，即等同於系爭專利請求項1 之「該編輯介面係使用同一共用框架，使該等欄位具有相同的標記」技術特徵。

而不論是Drag-And-Drop （拖曳與放置）機制或MalleableContent （延展性內容），前述乙證7 之相關內容，均揭露使用端頁面上，會顯示經使用者變更或編輯過後之編輯介面，即對應揭露系爭專利請求項1 之「一顯示資料控制器，顯示該用戶端所選取之該編輯介面於該網路平台上，並在該編輯介面完成編輯後顯示在該網路平台上」技術特徵。

三、綜上，乙證7 已揭露可將頁面區分為多個可供使用者編輯之內容區塊，或供使用者自行在頁面上重新排列項目，並具有相同之標記，其與系爭專利請求項1 之差異僅在於：乙證7並非由伺服器端的程式來執行顯示或應用程式邏輯相關工作（乙證7 第15頁「Http、CGI 、表單提交」、「伺服器端Script」之相關說明），而是由瀏覽器的javascript來負責，此與系爭專利請求項1 界定之「編輯介面控制器」、「顯示資料控制器」係位於伺服器端有所不同。

惟對於所屬技術領域中具有通常知識者而言，在此類用戶端－伺服端的網路架構中，用戶端的網頁程式與伺服端之程式互動，不外乎只能將事件處理交由用戶端或伺服端其中之一進行，且不論何者均能達成預期中之相同處理結果。

是以，系爭專利請求項1之發明，係所屬技術領域中具有通常知識者，依申請時之通常知識，將乙證7 所揭露之技術內容中，由用戶端瀏覽器所處理之編輯介面控制及資料顯示功能，改由伺服器端之程式進行處理而能輕易完成者，故乙證7 足以證明系爭專利請求項1 不具進步性。

四、系爭專利請求項2 ，係依附於請求項1 ，並界定「該網路平台中包含一動態資料處理器，將該用戶端在該網路平台上之動作傳送到該後端伺服器」之附屬技術特徵。

查乙證7 第17頁（見本案卷一第518 頁）揭露「使用者動作將引起事件處理器被呼叫」、「事件處理器傳送請求給伺服器」即對應於前述系爭專利請求項2 之附屬技術特徵。

又乙證7 足以證明系爭專利請求項1 不具進步性之理由，均如前述，故乙證7亦足以證明系爭專利請求項2 不具進步性。

五、系爭專利請求項3 係依附於請求項2 ，並界定「該後端伺服器中更包括一函式庫，該動態資料處理器呼叫該函式庫以對該後端伺服器中之該共用框架進行處理」之附屬技術特徵。

查乙證7 第18頁（見本案卷一第519 頁）第1 至2 行揭露「在伺器內部，web service 收到此請求，並且進行處理」即對應於前述系爭專利請求項3 之附屬技術特徵。

又乙證7 足以證明系爭專利請求項2 不具進步性之理由，俱如前述，故乙證7 亦足以證明系爭專利請求項3 不具進步性。

六、系爭專利請求項4 係依附於請求項1 ，並界定「該編輯介面中之複數欄位增減或編輯時，該編輯介面控制器利用該共用框架將該編輯介面更新」之附屬技術特徵。

查乙證7 第84頁（見本案卷一第522 頁）揭露透過調整DOM 結構，能夠調整元素出現在頁面上的位置，以及其他影響頁面結構的重要CSS 樣式、乙證7 第426 頁（見本案卷一第535 頁）揭露讓使用者以拖曳及放置元素的方式重新安排物件、乙證7 第445頁（見本案卷一第542 頁）可建立由Malleable Content （延展性內容）區塊所構成的頁面，即一小塊、一小塊可以在頁面內編輯的內容區塊，改寫網站資料，其必然會顯示更新結果，乙證7 第446 頁（見本案卷一第543 頁）第2 段「Ajax技術導致更順利的編輯過程…，一旦使用者完成編輯，…，內容再次回復到唯讀」，即對應於前述系爭專利請求項4之附屬技術特徵。

又乙證7 足以證明系爭專利請求項1 不具進步性之理由，俱如前述，故乙證7 亦足以證明系爭專利請求項4 不具進步性。

七、系爭專利請求項5 、6 均依附於請求項1 ，並各界定「該編輯介面係共用一組動態程式碼」、「每一該欄位各有一組動態程式碼，於編輯時可自動載入執行」之附屬技術特徵。

查乙證7 第17頁（見本案卷一第518 頁）揭露JavaScript程式碼用來管理進一步互動，乙證7 第426 至429 頁（見本案卷一第535 至538 頁），揭露可提供Drag-And-Drop （拖曳與放置）互動機制，讓使用者直接重新安排頁面上的元素，因在拖曳放置不同元件時，僅拖曳放置之對象不同，拖曳放置功能實質相同，乙證7 第444 、445 頁（見本案卷一第541、542 頁）揭露可建立由Malleable Content （延展性內容）區塊所構成的頁面互動機制，即一小塊、一小塊可以在頁面內編輯的內容區塊，每個皆可獨立編輯，則Drag-And-Drop （拖曳與放置）及Malleable Content （延展性內容）之互動機制確實具備JavaScript動態程式碼，且若程式碼功能相同，僅輸入變數不同時，建立共用函式庫供不同互動欄位使用為所屬技術領域之通常知識，又如乙證7 第428 、429頁（見本案卷一第537 、538 頁）揭露有Drag-And-Drop （拖曳與放置）之函式庫及程式碼範例，乙證7 第451 至453頁（見本案卷一第548 至550 頁）另揭露有Malleable Content （延展性內容）程式碼範例，即對應於前述系爭專利請求項5 、6 之附屬技術特徵。

又乙證7 足以證明系爭專利請求項1 不具進步性之理由，俱如前述，故乙證7 亦足以證明系爭專利請求項5 、6 不具進步性。

八、系爭專利請求項7 係依附於請求項6 ，並界定「該動態程式碼係依照該欄位之功能命名」之附屬技術特徵。

惟將程式碼依照功能命名僅係所屬技術領域中具有通常知識者在編寫程式碼時常用之命名規則，以利於日後修改程式碼時閱讀並加以理解，如乙證7 第451 、452 頁（見本案卷一第548 、549 頁）中之程式碼範例，其對於滑鼠位於區塊上、滑鼠離開區塊之函式，即分別以功能加以命名為onMessagesLoaded、onMessageMouseOut ，況且程式碼命名方式，亦無涉於程式之執行效能或功能表現，系爭專利請求項7 當未因其附屬技術特徵產生任何無法預期之功效。

又乙證7 足以證明系爭專利請求項6 不具進步性之理由，俱如前述，系爭專利請求項7 ，僅係所屬技術領域中具有通常知識者，依乙證7 所揭露之技術內容並採取功能命名來撰寫程式碼而能輕易完成者，故乙證7 足以證明系爭專利請求項7 不具進步性。

九、系爭專利請求項8 係依附於請求項2 ，並界定「該動態資料處理器係分析該編輯介面中被修改之該欄位，並在該編輯介面控制器中載入該欄位以進行修改，再將修改後之該編輯介面顯示於該網路平台上以供該用戶端確認」之附屬技術特徵。

查乙證7 第17、18頁（見本案卷一第518 、519 頁）揭露有事件處理器傳送請求項給伺服器，而瀏覽器回呼函式收到伺服器回應後，瀏覽器會改變顯示內容，且乙證7 關於Drag-And-Drop （拖曳與放置）或Malleable Content （延展性內容）等章節，亦已揭露瀏覽器可顯示使用者修改後之頁面或編輯介面，即對應於前述系爭專利請求項8 之附屬技術特徵。

又乙證7 足以證明系爭專利請求項2 不具進步性之理由，俱如前述，故乙證7 足以證明系爭專利請求項8 不具進步性。

十、系爭專利請求項9 係依附於請求項5 或6 ，並界定「該動態程式碼係使用ajax語法」之附屬技術特徵。

查乙證7 通篇均係以Ajax開發架構進行設計，其書名即為「Ajax設計模式－以編程與使用性設計模式建立Web 2.0 網站」，對應於前述系爭專利請求項9 之附屬技術特徵。

又乙證7 足以證明系爭專利請求項5 、6 不具進步性之理由，俱如前述，故乙證7足以證明系爭專利請求項9 不具進步性。

十一、系爭專利請求項10係方法發明，其各步驟均對應於系爭專利請求項1 中各構件之功能或動作，故同前述乙證7 與系爭專利請求項1 之比對：乙證7 已揭露可將頁面區分為多個可供使用者編輯之內容區塊，或供使用者自行在頁面上重新排列項目，並具有相同之標記，其與系爭專利請求項10之差異僅在於：乙證7 係由用戶端的程式來負責頁面的顯示與控制，而系爭專利請求項10界定之「編輯介面控制器」、「顯示資料控制器」則是位於伺服器端。

惟對於所屬技術領域中具有通常知識者而言，在此類用戶端－伺服端的網路架構中，用戶端的網頁程式與伺服端之程式互動，不外乎只能將事件處理交由用戶端或伺服端其中之一進行，且不論何者均能達成預期中之相同處理結果。

是以，系爭專利請求項10之發明，係所屬技術領域中具有通常知識者，依申請時之通常知識，將乙證7 所揭露之技術內容中，由用戶端瀏覽器所處理之編輯介面控制及資料顯示功能，改由伺服器端之程式進行處理而能輕易完成者，故乙證7 足以證明系爭專利請求項10不具進步性。

十二、系爭專利請求項11係依附於請求項10，並界定「該編輯介面控制器及該顯示資料控制器之程式碼係使用同一共用框架，使該等欄位具有相同的標記，當該編輯介面控制器及該顯示資料控制器運作時，依該標記找到該等欄位的一元件位置」之附屬技術特徵。

查乙證7 全篇係以Ajax為開發架構，另乙證7-1 第623 頁起（見本案卷二第315 頁起）附有Ajax框架及函式庫說明（等同於系爭專利之同一共同框架），且乙證7 第444 、445 頁（見本案卷一第541 、542 頁）記載以Ajax技術開發Malleable Content （延展性內容）區塊所構成的頁面，即一小塊、一小塊可以在頁面裡編輯的內容區塊，每個皆可獨立編輯，則編輯及顯示功能必然使用同一共同框架開發，又乙證7 第14、15頁HTML / XHTML段落記載Ajax技術以超文本" 標記" 語言HTML顯示頁面，所屬技術領域具有通常知識者，可輕易選擇以div 標記來分割複數區塊，又查乙證7 第429 頁（見本案卷一第538 頁）之程式碼範例，即採用document .getElementById（）之DOM API ，可藉由id元素尋得元件。

另乙證7 第446 頁（見本案卷一第543 頁）第3 段揭露「每個區塊的Malleable Content 是div 或textarea元素」、第451 頁（見本案卷一第548 頁）的程式碼範例，揭露「將頁面內容分析成一些Malleable Content 區塊，單一的div 被宣告在初始HTML裡，以保存這些區塊：< div id="messages"> < /div>」，對應於前述系爭專利請求項11之附屬技術特徵。

又乙證7 足以證明系爭專利請求項10不具進步性之理由，俱如前述，故乙證7 足以證明系爭專利請求項11不具進步性。

十三、系爭專利請求項12至18係請求項10之直接或間接附屬項，且其附屬技術特徵，分別實質相同於請求項2 至6 、8 、9 之附屬技術特徵，不另贅述。

而乙證7 既足以證明系爭專利請求項2 至6 、8 至10不具進步性，故乙證7 亦足以證明系爭專利請求項12至18不具進步性。

十四、乙證7 既足以證明系爭專利請求項1 至18不具進步性，如前所述，故乙證7 及5 之組合、乙證7 及8 之組合自當足以證明系爭專利請求項1 至18不具進步性。

十五、原告於109 年2 月18日之民事準備書（五）狀第6 至10頁（見本案卷二第408 至412 頁）第參點及109 年2 月25日言詞辯論簡報第11至22頁（見本案卷二第433 至444 頁）主張系爭專利與被證7不同云云，惟查：

（一）原告民事準備書（五）狀理由第一（二）點更詳細地描述說明書第8 頁語言編輯流程，其中第1 至4 點記載「1.定義其共同協定，Lang-group，也就是共同標記；

2.編輯介面包含語言、方言兩種：< Field name="lang"class="Lang-group" …> < Fieldname="dialect"class="Lang-group" …> ；

3.用戶卻修改語言項目，將協定標記Lang-group送入動態資料處理器；

4.動態資料處理器分析標記Lang-group，將找到欄位lang及dialect 」（見本案卷二第408 頁），惟前述記載內容並非出自於系爭專利申請時原說明書或圖式所揭露之內容，判斷時自無法援引。

（二）關於原告民事準備書（五）狀理由第二（一）點主張乙證7 無法證明有同一個共用框架，甚至得證明有框架云云（見本案卷二第409 頁），經查：乙證7 全篇係以Ajax為開發架構開發之頁面編輯介面，另乙證7-1 第623 頁起（見本案卷二第315 頁起）附有Ajax框架及函式庫說明，等同於系爭專利之同一共同框架，故原告此部分主張並不足採。

（三）關於原告民事準備書（五）狀理由第二（二）點主張乙證7 無相同標記之設計及精神云云（見本案卷二第409 頁）。

經查：乙證7 第444 、445 頁（見本案卷一第541 、542 頁）記載以Ajax技術開發Malleable Content （延展性內容）區塊所構成的頁面，即一小塊、一小塊可以在頁面內編輯的內容區塊，每個皆可獨立編輯，又乙證7 第14、15頁（見本案卷一第515 、516 頁）HTML/XHTML段落記載Ajax技術以超文本" 標記" 語言HTML顯示頁面，所屬技術領域領域具有通常知識者，可輕易選擇以div 標記來分割複數區塊，div 標記即對應系爭專利之相同標記，且顯示網頁時確實是透過該div 標記來識別哪些欄位應該顯示於該div 區塊內，又查乙證7 第429 頁（見本案卷一第538頁）之程式碼範例，即採用document .getElementById（）之DOM API ，可藉由id元素尋得元件。

另乙證7 第446頁（見本案卷一第543 頁）第3 段揭露「每個區塊的Malleable Content 是div 或textarea元素」、第451 頁（見本案卷一第548 頁）的程式碼範例，揭露「將頁面內容分析成一些Malleable Content 區塊，單一的div 被宣告在初始HTML裡，以保存這些區塊：< div id="messages">