最 高 行 政 法 院 判 決
95年度判字第01471號上 訴 人 光寶科技股份有限公司代 表 人 甲○○訴訟代理人 林金榮律師
潘昭仙律師馮達發律師被 上訴 人 經濟部智慧財產局代 表 人 蔡練生
參 加 人 李正芳上列當事人間因發明專利舉發事件，上訴人對於中華民國93年9月10日臺北高等行政法院92年度訴字第2829號判決，提起上訴，本院判決如下：
主 文上訴駁回。
上訴審訴訟費用由上訴人負擔。
理 由
一、本件原專利申請人旭麗股份有限公司（該公司與上訴人光寶科技股份有限公司、臺灣光寶電子股份有限公司及致福股份有限公司合併，其中上訴人為合併後之存續公司，並經經濟部於91年11月13日以經授商字第09101461420號函核准在案，上訴人復於91年12月11日向經濟部聲明承受訴願），前於85年7月15日以「可擴充鍵盤功能鍵之方法」向經濟部中央標準局（88年1月26日改制為經濟部智慧財產局）申請發明專利，經被上訴人編為第00000000號審查，准予專利，並於公告期滿後，發給發明第101665號專利證書（下稱系爭案）。嗣參加人李正芳以其違反核准審定時專利法第19條及第20條第2項之規定，提起舉發，並提出舉發證據二為SystemBI0S for IBM R PC/T(TM)/AT R computers andCompatibles 1989,1988,1987（下稱引證一）；舉發證據三為82年出版之「怎樣才能認織和診斷個人電碼硬體系統」一書（下稱引證二）；舉發證據四為「Microsoft Win 32Software Development Kit」光碟一份及下載內容，中文節譯本，其建檔日期西元1993年7月29日（下稱引證三）；舉發證據五為「New Key Support for Microsoft Window0perating Systems and Appications」，發表日期為1994年9月6日（下稱引證四）；舉發證據六為臺灣東華書局股份有限公司83年出版之「整合計算機大辭典」一書（下稱引證五）等證據。案經被上訴人審查，略以綜合引證一至五之相關技術及對等者之組合，系爭案屬易於思及而不具進步性，乃於91年6月5日以智專三㈡04020字第09189001358號專利舉發審定書為「舉發成立，應撤銷專利權」之處分。上訴人不服，循序提起行政訴訟。
二、上訴人起訴主張：㈠系爭案申請當時之習知標準電腦鍵盤可設定按鍵之內碼雖有128個，然因扣除各國語文中使用之按鍵數及系統命令碼後，餘下可使用之按鍵碼數僅剩8個，無形中限制擴充功能鍵之使用；而針對特殊按鍵如：Insert、Home、Page Up、Page down等，則係組合IBM標準鍵碼與E0碼後，形成一延伸碼，並賦予一個定義，使該等按鍵得以別於標準按鍵而作用，而因該等按鍵雖屬新增，惟該等鍵碼為IBM公司所定義，並由作業系統軟體（如D0S或Windows 0S等於IBM PC系統作業之軟體）將該等鍵碼納入其系統加以辨識，故於IBM相容個人電腦中，該等按鍵便可為電腦系統所接受。亦即，系爭案申請當時之習知技術，雖然前揭組合IBM標準鍵碼與E0碼之作法，不必動用如上所述標準鍵盤少數僅存之鍵碼，即可擴充功能鍵之使用性，然IBM依上述以E0碼定義功能鍵之方式，僅定義少數特殊鍵之延伸碼，如欲在標準鍵盤上於IBM或作業系統所定義之功能鍵外再擴充其他功能鍵，由於該等擴充功能鍵未曾被IBM或作業系統賦予任何定義，則不管是否使用僅存之鍵碼或是自行組合成一延伸碼，皆不會為電腦系統或作業系統軟體 (Windows)接受，此即成為無法解決之技術課題。系爭案主要係使在鍵盤上之標準鍵碼，利用可配合IBM特殊鍵之E0碼習知技術，以形成系爭案技術自行定義之與IBM標準相容之延伸碼，並藉由相容於視窗作業系統之軟體應用程式之控制（攔截鍵盤掃描碼、判斷該掃瞄碼是否為系爭案所增設之鍵盤擴充鍵之鍵碼，進而產生相對應動作如開啟瀏覽網路程式），俾擴充鍵盤上功能鍵之使用性，使該鍵盤擴充功能鍵之鍵碼因係以IBM之E0碼技術加以定義，達到可與IBM PC完全相容，避免因作業系統擴充標準鍵碼，與鍵盤製造商自行額外增設功能鍵所可能造成之系統衝突，進而達到本件專利擴充功能鍵之主要創作目的。是此等自行定義延伸鍵並搭配視窗應用程式（非作業系統）作用之技術特徵，顯非熟習該項技術者所能輕易思及者，且得解決習知技術擴充鍵不足之問題，原處分及原訴願決定之事實認定顯有違誤。㈡又被上訴人關於證據之採用亦違背法令：⒈首先，系爭專利之申請專利範圍之對應特徵，與引證一之技術內容並不相同，自不得據為舉發成立之證據：⑴按引證一第130頁所揭示之「E0h」，係指於鍵盤定義中，在位置96h處具有一個位元組(byte)之大小，其中之狀態位元組中有一位元(bit)之最末碼為E0h，此處之「E0h」中的E0係依16進位法表示所指的最末碼值，並恰好稱為E0，而系爭案之申請專利範圍之「E0」碼，係作為新增「擴充碼」之基礎（前置）鍵碼；二者毫無關係。⑵再者，引證一之第151頁至160頁雖揭示「E0碼與16進位碼互相搭配而形成掃描碼」，然與系爭案申請範圍所描述「E0碼搭配標準鍵碼產生掃描碼」技術內容，並不相同，且引證一並未指出E0碼要如何衍生及適用於其他所有任意組合鍵碼。⑶引證一第130頁中的E0h為位元組之位元1=1時最末碼的值，而第151頁至160頁則揭示E0碼與16進位碼互相搭配形成掃描碼，前述兩者顯不具有關聯性，而無法結合引用為舉發證據。⑷末查，引證一之第13章說明之INT 15h中斷，僅是BI0S提供服務之一，其所謂多任務攔截云云，僅是對於電腦週邊設備之一些硬體控制或是程式不正常終止提供服務（參引證一第379頁），與系爭案係以運用於延伸碼之攔截與判斷之視窗應用程式之軟體程式必要步驟等特點，二者運用範圍與標的不同，自無法互為比對。⑸尤有甚者，引證一之第13章全文中有關鍵盤之操作僅是變化鍵盤之鍵碼配置而已，與本系爭案「可擴充鍵盤功能鍵之方法」發明，其所欲解決之技術課題根本無涉，即不能比附援引。⒉引證二係如何對等於系爭案之技術特徵，原處分及訴願決定書，均未逐一說明，顯有理由不備；且系爭案所稱之延伸碼與引證二之ASCII碼顯不相等，系爭案中按壓功能鍵(hot key)時送出E0碼+標準碼，為系爭案所稱自行定義之延伸碼，再由鍵盤控制器轉為另一種內定碼，ASCII碼只是一個交換碼，方便於各系統間檔案的交換與鍵盤之掃瞄鍵碼無關，並非系爭案所提應用於視窗作業系統送入系統訊息佇列(SMQ)之內定碼。又系爭案所提之延伸碼是否為擴充鍵掃描碼之判斷，係以申請專利範圍所述必要特徵之視窗應用程式達成，並非如引證二中係以BI0S之向量攔截功能呼叫完成，且引證二所提之向量攔截係以硬體達成中斷功效，而系爭案所提之攔截與判斷功能則係以軟體程序加以達成。是二者運用手段不同，自無從互為比較，亦不得以引證二作為舉發成立之判斷基礎。⒊系爭案顯較引證三有「以視窗應用程式對額外擴充功能鍵鍵碼訊息判斷之程序」之突出技術特徵，並進而達到額外增設擴充功能鍵之功效，自具有進步性；且關於Hook攔截功能內容部份公開日在西元2000年以後，晚於系爭案申請日，引證三顯不具證據能力。參加人雖於準備程序中另行提出「Windows程式設計實務㈡進階篇」一書，欲證明系爭案不具進步性，惟該項證據係屬原處分及訴願決定程序後始行提出之新證據，自無法依此等新證據作為認定原處分及訴願決定違法與否之依據，此有最高行政法院93年度判字第926號判決意旨可參。⒋引證四所述即為系爭案專利說明書所載之習知技術，然該習知技術有無法再擴充其他功能鍵之問題，引證四並未揭露或教示而足使熟習該項技術者能輕易完成並加以克服，系爭案卻能解決此一問題如前述，系爭案自具進步性。⒌引證五關於hot Key熱鍵之內容，僅為單純概念之敘述，敘述利用「既有」鍵盤按鍵之功能鍵如何運作，並未揭露可對等於系爭專利之技術特徵；其與系爭案「可『擴充』鍵盤功能鍵之方法」係為解決習用功能鍵不足時，如何自行定義並作用「額外增設」之擴充功能鍵方法者，完全不同，顯無法據為認定系爭案不具進步性之證據。⒍綜上，引證一至引證五，其分散於不同文獻，在選擇與結合上亦具有顯著困難，尤無庸論其個別之證據，尚存在無法逐一對應系爭申請專利範圍必要技術特徵，或存在證據能力之問題；況即便組合此五件之文獻內容，亦無法與系爭案必要技術內容「以視窗應用程式對額外擴充功能鍵鍵碼訊息之攔截及判斷程序」特徵相切合，依專利審查基準實非為系爭案專利申請時熟悉該項技術者所能輕易選擇組合而達成者，故系爭案具進步性。㈢專利審查時有關進步性之判斷，常涉及主觀意見之判斷，故非常嚴禁以「後見之明」評價系爭案與引證案之關係。且按被上訴人所編訂之專利審查基準第1-2-21頁明白揭示：「以先前技術之片斷部分互相組合，而判斷發明是否能輕易完成時，應考慮發明是否具有『突出的技術特徵』或『顯然的進步』。『突出的技術特徵』，係指申請專利之發明對熟習該項技術者而言，若以先前技術為基礎，仍然不易由邏輯分析、推理或試驗而得者。『顯然的進步』係指申請專利之發明克服先前技術中存在的問題點或困難性而言，通常係表現於功效上。例一：在技術發展空間有限之領域中(in the field of the crowded art)，如在技術上有微小的改進，得視為具有『顯然的進步』。例二：發明能解決人類長久未能解決之技術問題者，得視為具有『顯然的進步』。例三：在發明所屬之技術領域中，發明能突破熟習該項技術者長久根深蒂固存在之技術、知識時，可視為具有『顯然的進步』。」本件系爭案申請時，習知技術確實存在無法解決鍵盤製造或設計廠商欲自行額外擴充功能鍵之固有技術課題，申請人藉由IBM公司定義之E0碼使擴充之功能鍵得為BM PC所接受，並搭配申請專利範圍所主張之視窗應用程式之攔截與判斷程序之突出技術特徵，進而解決習知技術之長久以來受制於IBM定義或作業系統內嵌功能鍵定義技術課題，達成自行擴充功能鍵，不受IBM定義功能鍵不足限制之功效，在申請日前確實前所未見，亦確實解決並克服習知技術之困難，參諸前揭「專利審查基準」，該等突出之技術特徵與功效，其進步性自不待言。而因上訴人之努力，系爭案產品在投入市場數年後，因多媒體運用之市場需求而廣為消費者所接受，係屬當時為全世界第一大鍵盤製造廠之上訴人心血結晶與行銷努力而得，縱目前運用系爭案具有擴充功能鍵之鍵盤似屬普遍，亦不得就本案引證資料依目前之技術水準，加諸該等技術運用廣泛之情形，進而貶低系爭案於申請日當時之進步性。為此，請判決將訴願決定及原處分均撤銷，並命被上訴人為「舉發成立」之處分。被上訴人則以：㈠系爭案之說明書一再強調其係藉視窗(Windows)軟體程式之控制，俾擴充鍵盤上功能鍵之使用性。系爭案之可行性係建立在視窗Windows之應用程式處理之基礎上，故系爭案之發明時間應晚於視窗Windows之公佈日期，方能與其相容。㈡在技術手法上，系爭案所運用之鍵碼配合IBM特殊鍵之E0碼以形成定義延伸碼，其即係運用IBME0碼得以擴充延伸之技術概念，該技術概念係已習知者，且已應用於特殊按鍵，如引證一中所述及之Insert、Home、Page Up、Page down等，故上述系爭案擴充定義IBM之延伸碼仍係已習知技術之直接應用。引證二第229頁已揭示鍵盤按鍵被致動時，特定掃描碼之送出、接收及轉換成ASCII碼，再存入鍵盤緩衝器；在運作方式上其已可對應於系爭案第1項獨立項中之步驟(b)、(c)、(d)，引證二第379頁所述及之多任務攔截程式，其藉由置換INT 15h向量攔截功能呼叫並處理該等功能呼叫，而使功能呼叫中斷；在運作方式上其已可對應於系爭案第1項獨立項中之步驟(e)、(f)。引證三中已述明攔截程式可將訊息攔截並決定是否處理，其中並述及延伸鍵之概念。引證四已提出三個擴充功能鍵，其亦利用E0碼進行編碼；引證五已揭示利用特定之接鍵或接鍵順序而形成特定功能鍵，以使電腦啟動特定程式以執行對應之功能之技術。故系爭案技術特徵之步驟(a)係已習知技術之直接應用如上述者，亦已可見之於引證一、三、四、五，而其步驟(b)至(f)則已可見之於引證二。系爭專利之實質技術特徵相對之下僅是單純地擴充定義延伸之延伸碼至E0碼與標準鍵碼之搭配而已；故相對於引證一至五技術範疇之相關技術而言，系爭案應仍是熟習該項技術者所能輕易完成者，不具有進步性。是上述引證一至五均仍是相同技術範疇中相關聯之技術資料，並無技術組合上之困難，起訴理由所述並非事實等語，資為抗辯。
三、原審斟酌全辯論意旨及調查證據之結果，以：㈠系爭案之申請專利範圍：一種可擴充鍵盤功能鍵之方法，包含下列步驟：(a)使鍵盤上之標準鍵碼可配合IBM特殊鍵之E0碼，以形成定義延伸IBM之延伸碼；(b)鍵盤控制器會接收鍵盤送來之鍵碼，並轉換成另一種內定碼；(c)鍵盤驅動器會接收鍵盤控制器之內定碼，並送入系統訊息佇列(SMQ)；(d)系統訊息佇列會將該內定之鍵碼送出；(e)視窗之應用程式會判斷該內定之鍵碼是否為延伸碼？若是延伸碼，則依鍵碼功能定義，執行相關程式，俟執行完畢後，再清除該鍵碼；若不是延伸碼，則將鍵碼傳送至下一個攔截程序或釋放該鍵碼；（ｆ）如此，即可藉定義形成之延伸碼，配合視窗之應用程式，擴充鍵盤之功能鍵之使用性。㈡茲就引證案技術內容並與系爭案申請專利範圍比較進步性如後：⒈引證一相關之技術部分為其中第130頁中，鍵盤資料定義中位置96h之狀態位元組之位元1=1最末碼為E0h；第151頁至155頁及第156頁至160頁所列之碼表中鍵號62至86、89、96、108及124之按鍵之掃瞄碼皆係以E0碼搭配一個16進位碼；引證一第379頁則述及多任務攔截程式，其藉由置換INT 15h向量攔截功能呼叫並處理該等呼叫，而使功能呼叫中斷。⑴與系爭案相較，引證一第130頁中之E0h係指E0為16進位法表示，但第151頁至第160頁已揭示0碼與16進位碼互相搭配而形成掃描碼，其與系爭案搭配E0碼與標準鍵碼而形成一延伸碼之技術手法實質上應係相同者；相對之下，系爭案技術特徵之對應部分僅係將引證一擴充至E0碼與鍵盤上之標準鍵碼之搭配，其仍應是單純擴充而已，係熟習該項技術者所能輕易完成者。⑵上訴人雖主張引證一上開技術內容與系爭申請專利範圍第1項之步驟(a)所描述「E0碼搭配標準鍵碼產生掃描碼」技術內容並不相同，不能作為進步性之比較云云。惟查，系爭案之申請專利範圍所述：「(a)首先，使在鍵盤上之標準鍵碼（Key Code）可配合IBM特殊鍵之E0碼，以形成定義延伸IBM之延伸碼」，其中所述：「可配合IBM特殊鍵之E0碼，以形成定義延伸IBM之延伸碼」顯已指出IBM E0碼得以擴充延伸，亦即其原始擴充概念已經存在。且其擴充性概念於原IBM E0擴充碼已經存在，並已經應用於特殊按鍵（如Insert、Home、Page Up、Page down等，）則從系爭案範圍步驟(a)所述「IBM特殊鍵之E0碼」即係引證一鍵碼表中所列如鍵號62至86、89、95、108及124的按鍵，其掃描碼（Scan codes）皆係以E0碼搭配一個16進位碼，鍵62=E0+38；鍵64=E0+1D；鍵75=E0+52等（參引證一第153頁表）。其中38、1D以及52等皆為16進位碼表示之鍵碼，此種以E0碼搭配既存鍵碼以構成形成掃描碼之技術與系爭申請專利範圍所描述「E0碼搭配標準鍵碼產生掃描碼」並無差異，此由引證一之技術內容可知，是系爭案創作之原始概念已經存在。系爭案僅係將所搭配之按鍵碼擴及英文字母鍵及一般數字鍵所使用之鍵碼，不具進步性。又引證一（原處分誤書為引證二）第379頁述及多任務攔截程式，其藉由置換INT 15h向量攔截功能呼叫並處理該等功能呼叫，而使功能呼叫中斷，與系爭案相較，引證一（原處分誤書為引證二）在運作方式上對等於系爭案第1獨立項中之步驟(e)、(f)。⑶上訴人雖又主張：引證一中之INT 15h中斷，僅是BI0S提供服務之一，且多任務攔截僅是對於電腦週邊設備的一些控制或是程式不正常終止提供服務，與系爭案依延伸碼功能定義而執行相關程式之特點，二者各有不同運用範圍不得逕自比對。並進而強調系爭案之主要必要技術內容為「訊息之攔截及判斷程序」云云。惟查，綜觀系爭案之說明書，可知系爭案所謂攔截程序之應用為「視窗之應用程式會判斷該內定之鍵碼是否為延伸碼，若是延伸碼，則依鍵碼功能定義，執行相關程式，俟執行完畢後，再清除該鍵盤碼；若不是延伸碼，則將鍵碼傳送至下一個攔截程序或釋放該鍵碼（見系爭案申請專利範圍第1項步驟(e)」，於系爭案說明書亦記載：「同時，該程式會判斷該內碼是否是延伸碼，並根據『PLAY』鍵內定之功能，執行相關之程式……」，引證一有關多任務攔截程式之說明係表示在多任務操作系統中，藉由取代INT 15h向量並處理功能訊息呼叫以截斷該呼叫。引證一BI0S系統攔截程序概念亦是就功能訊息予以處理，而系爭案說明書第二圖清楚列明系爭案所送出之功能訊息，亦是經由Windows作業程式攔截處理，故引證一與系爭案送出資料訊息之處理並無二致。上訴人所主張系爭案之主要必要技術內容為「訊息之攔截及判斷程序」云云，自屬無稽。⑷至上訴人主張引證一第130頁所揭示之鍵盤資料定義，係在位置96h位置處，其狀態位元組之最末碼為E0h，此處之E0h中的E0係依16進位法表示所指的最末碼值，並恰好稱為E0 ，此與IBM特殊鍵之「E0」碼毫無關係。惟此與系爭案申請專利範圍「(a)首先，使在鍵盤上之標準鍵碼（Key Code）可配合IBM特殊鍵之E0碼，以形成定義延伸IBM之延伸碼」無涉。⒉引證二技術內容：引證二為82年出版之「怎樣才能認識和診斷個人電腦硬體系統」一書，在相關之技術部分，其第229頁述及鍵盤上之按鍵被致動時，會送出對應之特定掃描碼，PC之鍵盤控制器接收該掃描碼時會將其轉換成ASCII碼，再存入鍵盤緩衝器內，等待CPU來讀取。引證二第229頁述及：「除少數按鍵外，當鍵盤上的按鍵被按下、放開或持續壓著不放時，都會有掃瞄碼自鍵盤送到電腦上，這個掃瞄碼是微處理器給予每個按鍵獨有的編碼。在電腦的鍵盤控制器接收到掃瞄碼時，會先將它轉換成ASCII碼，然後存入鍵盤緩衝器內，等待CPU來讀取」鍵盤上之按鍵被致動時會送出對應之特定掃描碼，PC之鍵盤控制器接收該掃描碼時會將其轉換成ASCII碼，再存入鍵盤緩衝器內，與系爭案相較，其中掃描碼為系爭案所稱之「鍵碼」；ASCII碼為系爭案所稱「內定碼」，引證二所述在運作方式上對等於系爭案第1項獨立項中之步驟(b)、(c)、(d)，足證系爭案由「鍵碼」轉為「內定碼」及其後送出訊息之步驟，況再參以後述引證三所述鍵盤控制器會收到掃描碼（鍵碼），並轉換成另1種ASCII碼（內定碼），且送入鍵盤緩衝器等待讀取之技術內容，足見系爭案與將內定碼送入系統訊息佇列並送出之技術概念並無不同，且對習知此項領域的一般技術人士所輕易完成。⒊引證三技術內容：引證三為「Microsoft Win 32software Development Kit」光碟一份及下載內容，中文節譯本，其建檔日期1993年7月29日，在相關技術內容部分，其中述明攔截程式可將訊息攔截並決定是否處理，其中並述及延伸碼之概念。⑴經查，上訴人主張其系爭案申請日期早於Win3 Hooks之公開日期，惟依系爭案申請專利範圍及說明書中之「係視窗Windows之應用程式形成定義延伸IBM之延伸碼作進一步處理……」，乃指「系爭案與Windows之IBM延伸碼相容」；再者，系爭案之說明書一再強調其係藉視窗(Windows）軟體程式之控制，俾擴充鍵盤上功能鍵之使用性。則系爭案之發明時間顯應晚於Windows公佈日期，否則系爭案無法相容於Windows。上訴人主張引證三不具舉發進步性之證據能力云云，自非可採。⑵引證三有關Win32 Hooks部分攔截程序相關技術部份內容明確標示的日期為1993年7月29日。上訴人卻試圖以列印日期（2001年4月12日）來混淆視聽，指稱該列印日期晚於系爭案案之申請日。蓋列印日期僅是顯示該資料列印出來之日期，非指該等資料之公開日期，根本與證據能力之判定無涉。引證三係「MicrosoftWin32 software Development Kit」，即「微軟視窗（即Windows作業系統）32位元（即電腦所處理資料之單筆長度）軟體發展套件」，此套件係微軟公司為研發Windows 95（視窗95）作業系統，將該作業系統所涉功能之軟體程式開放並提供予硬體（如碟機、鍵盤、滑鼠、主機板等）相關協力廠商，以便其等所製造之硬體產品能配合Windows 95系統，以免造成Windows 95上市後空有軟體功能而無電腦週邊硬體設備配合之情形，故引證三之套件必早在Windows 95作業系統開發時已公開，則Windows 95（視窗95）作業系統既於西元1995年上市銷售，引證三套件必定於1995年前即已公開，早於系爭案申請日期即85年7月15日。⑶且Win32 Hooks及Windows 95已經定義延伸鍵之概念；引證三述明攔截程式可將訊息攔截並決定是否處理，其中並述及延伸鍵之概念，與系爭案相較，其在運作方式上對等於系爭案第1項獨立項中之步驟(e)，再參以前述引證一所述之技術內容，系爭案自為所屬技術領域中具有通常知識者，依申請前之先前技術所能輕易完成。至於參加人雖於準備程序中，另行提出參證三「Windows程式設計實務㈡進階篇」一書作為引證，惟該項證據係屬原處分及訴願決定程序後始行提出之新證據，在被上訴人及訴願機關中並無法審酌該等證據，自無法依此等新證據，在判斷行政處分是否違法之範圍內，認定被上訴人及訴願決定機關依原有證據認定事實適用法律之處分是否違法，依最高行政法院93年度判字第926號判決意旨，該等證據自不得作為認定原處分及訴願決定違法與否之依據，附此敘明。⒋引證四技術內容為「New Key Support MicrosoftWindow 0perating Systems and Applications」，發表日期為1994年9月6日，其揭露三個擴充功能鍵，Left Windows、Right Windows及Applications，並記載其編碼亦利用E0碼之方式。⑴引證四三個擴充功能鍵其編碼亦利用到E0碼；與系爭案相較，引證四已揭示利用E0碼之編碼規則以搭配部分標準碼而形成定義延伸之延伸碼，故系爭案之相關技術部分仍是習知技術之運用，其單純地擴充至E0碼與標準鍵碼之搭配，應係熟習該項技術者所能輕易完成者，不具進步性。⑵上訴人雖主張：系爭案擴大按鍵鍵碼組合增加功能之方法係「習知技術之盲點所在，亦非熟習該項技術者所能輕易完成者」云云，惟查依引證四揭露微軟作業系統中在鍵盤上設定三個擴充功能鍵，其亦方法是利用E0碼編碼，系爭案亦使用相同方法，僅係擴大按鍵之鍵碼組合範圍，則系爭案擴大電腦鍵盤上按鍵組合，達到擴充功能鍵之方法，與微軟作業系統中設定之擴充功能鍵之方法，並無不同。是以在電腦作業系統中要設定何種功能鍵，便利使用者之使用，僅為需求設計問題，並不因其鍵碼組合範圍之大小，而異其設定之方法，在技術上係熟習該項技術者所能輕易思及，上訴人主張，自不可採。⒌引證五技術內容：引證五為83年出版之「整合計算機大辭典」一書，其第382頁中述及hot key熱鍵經選定之按鍵或按鍵順序，可令計算機內立即發生某種功能。⑴引證五第382頁中述及hot key熱鍵經選定之按鍵或按鍵順序，可令計算機內立即發生某種功能，此種按鍵，常用以引動記憶常駐程式，與系爭案相較，引證五已揭示利用特定之按鍵或按鍵順序而形成特定功能鍵，以使電腦啟動特定程式以執行對應之功能之技術手法，系爭案仍是該技術手法之運用，只是特定於E0碼與標準鍵碼之搭配，不具進步性。⑵此外，除引證一足以證明系爭案關於攔截程式之應用技術概念已見於習知技術外，並有引證五亦明確揭示：「hot key熱鍵經選定之按鍵或按鍵順序，可令計算機內立即發生某種功能。此種按鍵，常用以引動記憶常駐程式（即TSR程式）。……」則其中熱鍵即系爭案所稱之擴充功能鍵。再綜合引證三述明攔截程式可將訊息攔截並判斷，例如I參數中有指明是否為延伸鍵之部分的說明，均足證上訴人所主張系爭案關於攔截程式之應用技術概念，確已揭露於先前技術中，不具進步性。⑶則被上訴人綜合引證一至五之相關技術及對等組合，認定系爭案為熟習該項技術者所能輕易完成者，不具進步性，並無不合。再按專利審查基準第1-2-21頁中規定：「由一般教科書、標準、辭典與其他文獻組合之事，通常視為能輕易完成的。」⑷綜觀上開引證，或為一般參考書籍、或為Windows相關標準之資料以及辭典等，所引用部分係屬習知此類領域之人技術上可推知之事項，更可證各引證相結合係為熟習該項技術者所能輕易完成。上訴人指稱「引證一至引證五，其分散於不同文獻，在選擇與結合上亦具有顯著困難，即便組合此5件之文獻內容，亦無法與系爭案必要技術內容『訊息之攔截及判斷程序』相切合」云云，並非可採。㈣此外系爭案不具進步性，亦經訴願機關送經財團法人工業技術研究院鑑定屬實，有該院92年3月24日工研院技字第0003114號函附審查意見書可資參照，亦可為本件判斷之佐證等由，駁回上訴人原審之訴。
四、上訴意旨復執前詞，並主張：㈠原審謂「引證三述明攔截程式可將訊息攔截並決定是否處理，其中並述及延伸鍵之概念，與系爭案相較，其在運作方式上對等於系爭案第1項獨立項中之步驟(e)」云云，惟引證三究竟何處揭示「攔截程式可將訊息攔截並決定是否處理，其中並述及延伸鍵之概念」，原審俱未載明。原審又謂引證三係「微軟視窗（即Windows作業系統）32位元（即電腦所處理資料之單筆長度）軟體發展套件」，此套件係微軟公司為研發Windows 95（視窗95）作業系統，將該作業系統所涉功能之軟體程式開放並提供予硬體（如碟機、鍵盤、滑鼠、主機板等）相關協力廠商……云云，其認定理由如何及證據為何，原審亦未交代。再者，原審恝置引證三封面及光碟片上均清楚載明「為Windows NT及Windows98」及「2000年4月」之事實不論，率斷「引證三」係為供Windows 95開發之用。另系爭案之申請專利範圍計有二項，第一項即上揭(a)、(b)、(c)、(d)、
(e)、(f )等步驟；原審僅論斷系爭案專利範圍第一項無進步性，對於第二項何以不具備進步性，則隻字未提，竟率斷謂系爭案整體不具進步性。以上均有理由不備之違法。㈡原審謂系爭案之發明時間顯晚於Windows公布日期，否則無法如系爭案說明書所稱相容於Windows云云，因而認引證三具有證據能力。惟查原審前開認事用法顯有違誤，蓋Windows乃微軟公司所開發一系列電腦作業系統之概稱，該公司分別於西元1992年推出Windows 3.0、1995年Windows 95、1998年Windows 98及Windows NT、2000年Windows 2000、2001年Windows XP。系爭案申請日固晚於Windows 3.0之1992年、Windows 95之1995年，卻早於Windows 98及Windows NT之1998年、Windows 2000之2000年或Windows XP之2001年。則原審指稱「系爭案之發明時間顯晚於Windows公布日期」之「Windows」究為何指？原審並未說明，有理由不備之違法甚明。實則，上揭引證三封面及光碟片均清楚載明「為Windows NT及Windows98」所設計及「2000年4月」，則引證三之公告日或公開日應晚於系爭案之申請日，不具證據能力。㈢原審復謂「引證三有關Win32 Hooks部分攔截程序相關技術部份內容明確標示的日期為1993年7月29日」云云，乃率論「引證三」具有本件舉發證據能力，然查，原審判決認為前開「明確標示的日期為1993年7月29日」，係援引參加人於原審陳稱下載自「引證三」之內容及其中文節譯本。惟原審參加人所下載內容及其中文節譯本之真實性為何？是否確為「引證三」光碟月所載之內容，非無疑義。況縱如原審判決所認「引證三有關Win32 Hooks部分攔截程序相關技術部份內容」係於1993年7月29日建檔，惟此充其量僅證明該內容係1993年7月29日「完成」，但並未證明此內容亦係於同日公告或公開。㈣經查，引證一固如原審判決所述，「其中第130頁中，鍵盤資料定義中位置96h之狀態位元組之位元1=1最末碼為EOh；第151頁及第156頁至160頁所列之碼表中鍵號62至86、89、96、108及124之按鍵之掃瞄碼皆係以E0碼搭配一個16進位碼」，惟查前開引證一所載本即屬系爭案申請專利範圍第1項步驟(a)中之「IBM特殊鍵之E0碼」，即僅是步驟(a)元素之一，並未揭示(a)之主要技術內容即鍵盤上標準鍵碼與IBM特殊鍵之E0碼相配合，並以此所定義出延伸碼。況且前開「引證一」亦僅記載相關鍵碼之位元組為何，並無任何實質技術內容可言。原審判決復認「又引證一第379頁述及多任務攔截程式，其藉由置換INT 15h向量攔截功能呼叫並處理該等功能呼叫，而使功能呼叫中斷」，「引證一BIOS系統攔截程序概念亦是就功能訊息予以處理，而系爭案說明書第二圖清楚列明系爭案所送出之功能訊息亦是經由Windows作業程式攔截處理，故引證一與系爭案送出資料訊息之處理，並無二致」，而認引證一在運作方式上對等於系爭案申請專利範圍第一項步驟(e)、(f)。然細觀引證一第379頁可知，原審判決所謂「多任務攔截程式」係BIOS之一項功能，然此「BIOS」係存於電腦晶片內，屬於電腦晶片內電路之一部。具體言之，「BIOS」得以達成攔截功能實源於電腦硬體即電晶片電路所致，惟系爭案純粹採用電腦軟體以達成攔截功能。此參原審判決亦認「可知系爭案所謂攔截程序之應用為『視窗之應用程式會判斷該內定之鍵碼是否為延伸碼，若是延伸碼，則依鍵碼功能定義，執行相關程式，俟執行完畢後，再清除該鍵盤碼；若不是延伸碼，則將鍵碼傳送至下一個攔截程序或釋放該鍵碼」即明。由上足證，「引證一」係採用電腦硬體，但系爭案則係採用電腦軟體處理，兩者技術顯不相同。原審判決昧於事實，率謂兩者並無二致，進而認定系爭案顯無進步性，實有違誤。㈤原審率認引證二已揭示系爭案申請專利範圍第1項步驟(b)、(c)、(d)之技術，並認ASCII碼為系爭案所稱「內定碼」；惟按所謂「ASCII」即「美國資訊交換標準碼」(American Standard Code
for Information lnterchange)，乃美國標準協會向國際標準化組織所建議提出，其目的在使不同系統間之資料傳輸得以標準化，並為國際標準化組織核准為ISO 646國際標準，且為電腦系統DOS作業軟體及UNIX作業軟體所採用。ASCII編碼方式係使用七個位元，用以指定最多達128個字元，其中有96個可列印字元，包括英文字母字元、數字字元及常用符號字元，以及32個控制字元；針對諸如法文、德文等國際字元及特殊符號，則利用ASCII延伸編碼方式(Extended ASCII)使用八個位元，用以指定最多達256個字元。經查：⒈系爭案申請專利範圍第1項之步驟(b)，縱有將鍵碼以鍵盤控制器轉換為內定碼，惟此內定碼並非原審所述之ASCII碼。蓋依ASCII字元集及其編碼表可知，其僅代表字母字元、數字字元、符號字元及控制字元如前述，並未有任一ASCII碼所對應之字元包含IBM E0碼延伸碼之鍵碼。⒉次查，系統訊息佇列(SMQ)為微軟視窗系統所特有，其作用在於供多個不同視窗應用程式實現相互通信。詳言之，訊息之發送者先將其所欲發送之資訊置入一容器（稱為Message）中，再將此容器保存至一系統訊息佇列，視窗應用程式再從該佇列取出容器並對其中資訊進行處理。一般具電腦技術知識者可以了解的是，在視窗作業系統中，鍵盤驅動器所送入系統訊息佇列的資訊係包含掃描碼資訊之一內定碼，並非為ASCII碼。果如原審所述系爭案之內定碼即為ASCII碼，則此ASCII碼隨後又會被送入系統訊息佇列中（系爭案申請專利範圍第1項之步驟(c)，顯與事實不符。再查，系爭案申請專利範圍第1項之步驟(e)係對內定碼進行攔截並判斷其是否為延伸碼，若依原審所述系爭案內定碼即為ASCII碼，則因ASCII碼並未代表任何延伸碼，此步驟(e)即不需進行任何判斷而可得知其非為延伸碼，是可證原審認定亦與事實有違。㈥引證四充其量僅揭示各功能鍵之編碼，並未揭示系爭案申請專利範圍第一項步驟(a)即「使在鍵盤上之標準鍵碼可配合IBM特殊鍵之E0碼，以形成定義延伸IBM之延伸碼」之技術；「引證五」，其僅單純敘述「熱鍵」之概念，並未揭露任何具體之技術內容，如世人皆知時光機概念，辭典亦有此記載，惟迄今仍無任何具體技術存在，上訴人業於原審主張。原審認「引證四已揭示利用EO碼之編碼規則以搭配部份標準碼而形成定義延伸之延伸碼」，「引證五已揭示利用特定之按鍵或按鍵順序而形成特定功能鍵」云云，其認事用法顯有違誤。另依專利法第73條第2項之反面解釋，系爭案既屬尚未撤銷確定，迄今仍屬有效存在之專利，則可隨時依法申請減縮系爭案之申請專利範圍。則上訴人業於本案原審判決後、上訴繫屬中，依專利法第64條第1項第1款規定申請減縮專利範圍，本件行政訴訟所依憑之基礎事實正變更中，自有類推適用行政訴訟法第177條第2項應予裁定停止訴訟程序云云。
五、本院按：凡利用自然法則之技術思想之高度創作，而可供產業上利用者，固得依系爭專利核准時專利法第19條及第20條第1項之規定申請取得發明專利。惟其發明如「係運用申請前既有之技術或知識，而為熟習該項技術者所能輕易完成時」，仍不得依法申請取得發明專利，復為同法第20條第2項所明定。經查，系爭案之申請專利範圍：一種可擴充鍵盤功能鍵之方法，包含下列步驟：(a)使鍵盤上之標準鍵碼可配合IBM特殊鍵之E0碼，以形成定義延伸IBM之延伸碼；(b) 鍵盤控制器會接收鍵盤送來之鍵碼，並轉換成另一種內定碼；
(c)鍵盤驅動器會接收鍵盤控制器之內定碼，並送入系統訊息佇列(SMQ)；(d)系統訊息佇列會將該內定之鍵碼送出；(e)視窗之應用程式會判斷該內定之鍵碼是否為延伸碼？若是延伸碼，則依鍵碼功能定義，執行相關程式，俟執行完畢後，再清除該鍵碼；若不是延伸碼，則將鍵碼傳送至下一個攔截程序或釋放該鍵碼；（ｆ）如此，即可藉定義形成之延伸碼，配合視窗之應用程式，擴充鍵盤之功能鍵之使用性此有發明專利說明書附於原處分卷可稽，經被上訴人就舉發人即參加人所提出之引證一至五之證據予以審查，認系爭案屬易於思及而不具進步性，乃為舉發成立之處分。上訴人提起訴願，訴願機關送請財團法人工業技術研究院審查，亦認原專利「可擴充鍵盤功能鍵之方法」，其專利範圍創新性不足，亦有該院92年3月24日工研院技字第0003114號函附審查意見書可資參考。另原審就系爭案與引證一至五予以比對，綜合引證一第130頁中之E0h係指E0為16進位法表示，但第151頁至第160頁已揭示0碼與16進位碼互相搭配而形成掃描碼，其與系爭案搭配E0碼與標準鍵碼而形成一延伸碼之技術手法實質上應係相同，系爭案技術特徵之對應部分僅係將引證一擴充至E0碼與鍵盤上之標準鍵碼之搭配，為單純擴充，係熟習該項技術者所能輕易完成者；引證二所述在運作方式上對等於系爭案第1項獨立項中之步驟(b)、(c)、(d)；引證三係「Microsoft Win 32 software Development Kit」，即「微軟視窗（即Windows作業系統）32位元（即電腦所處理資料之單筆長度）軟體發展套件」，此套件係微軟公司為研發Windows 95（視窗95）作業系統，將該作業系統所涉功能之軟體程式開放並提供予硬體等相關協力廠商，以便其等所製造之硬體產品能配合Windows 95系統，以免造成Windows 95上市後空有軟體功能而無電腦週邊硬體設備配合之情形，故引證三之套件必早在Windows 95作業系統開發時已公開，則Windows 95（視窗95）作業系統既於西元1995年上市銷售，引證三套件必定於1995年前即已公開，早於系爭案申請日期即85年7月15日；引證四三個擴充功能鍵其編碼利用到E0碼，與系爭案相較，引證四已揭示利用E0碼之編碼規則以搭配部分標準碼而形成定義延伸之延伸碼，故系爭案之相關技術，單純地擴充至E0碼與標準鍵碼之搭配，應係熟習該項技術者所能輕易完成；引證五第382頁中述及hot key熱鍵經選定之按鍵或按鍵順序，可令計算機內立即發生某種功能，此種按鍵，常用以引動記憶常駐程式，與系爭案相較，引證五已揭示利用特定之按鍵或按鍵順序而形成特定功能鍵，以使電腦啟動特定程式以執行對應之功能之技術手法，系爭案仍是該技術手法之運用，只是特定於E0碼與標準鍵碼之搭配等情，認系爭案屬易於思及而不具進步性，業於判決理由內詳述得心証之理由，經核並無不合，上訴人主張原審判決有理由不備之違誤云云，尚不足採。至於上訴人其餘訴稱，無非就原審取捨證據、認定事實之職權行使，指摘其為不當，仍無可採。綜上所述，上訴意旨指摘原判決違誤，求予廢棄，難認有理由，應予駁回。至於上訴人以其已依專利法第64條第1項第1款規定申請減縮專利範圍為由，聲請裁定停止訴訟程序乙節，因與行政訴訟法第177條第2項規定之要件未合，自無裁定停止訴訟程序之必要，併予敘明。
據上論結，本件上訴為無理由，爰依行政訴訟法第255條第1項、第98條第3項前段，判決如主文。
中 華 民 國 95 年 9 月 7 日
第三庭審判長法 官 趙 永 康
法 官 楊 惠 欽法 官 侯 東 昇法 官 黃 淑 玲法 官 林 文 舟以 上 正 本 證 明 與 原 本 無 異中 華 民 國 95 年 9 月 8 日
書記官 王 福 瀛