第16章 思想與表達之區別及合併─電腦程式結構保護之界線

16.7 Altai案之抽離─過濾─比較測試法

16.7          Altai[49] 案之抽離─ 過濾─比較測試法
       前揭Lotus案雖然繼Whelan案之後確認電腦程式之非文字部分可為表達而受著作權法保護,但就思想與表達之判別一節,僅只援用抽象測試法,並未針對電腦業界之特性有所調整。然則,電腦程式之撰寫雖可能有多種方法,就著作權法對傳統著作所用之必要場景原則或合併原則而言,其表達方式應受著作權法保護,蓋唯有思想之表達方法為唯一或極其有限時,思想與表達方始合併而不受保護,他人始得自由模仿,惟實際進行電腦程式之開發時,基於邏輯演繹法上效率之考量、基於市場上之硬體規格標準已無法改變、或基於應用程式須受制於作業系統之牽制,事實上能選擇者極為有限,而傳統之抽象測試法及Lotus案對此並未予以考量,直至Altai案方有進一步之發展。
 
16.7.1            Altai 抽離─ 過濾─比較「三步驟測試法」之精義
       Altai案中所採用之抽離─過濾─比較測試法,實質上即為三步驟測試法[50]。所謂抽離─ 過濾─比較測試法(Abstraction─Filtration─Comparison Test),乃是將著作是否抄襲之判斷分為三個步驟。第一步驟係將電腦程式解構、抽離,使之抽象化,亦即將電腦程式從機器碼、原始碼、參數表、模組(module)、常式(routine)、 次常式(subroutine)、程式最終功能目的之一般性描述分為數個層級,目的係在不斷抽離過程中,使其模式浮現,以便在下一步驟中判斷該結構或模式是否具有著作權法保護之適格而決定應否濾除,此步驟與抽象原則之抽離過程完全相同。第二步驟為過濾,即將不屬著作權法保護之部分濾除,換言之,即將未具有原創性、未具有特殊性或其他應屬公共財產之結構濾除。第三步驟則將濾除後之應受保護之表達進行是否實質相似之比較。如前所述,Lotus案雖然繼Whelan案之後確認電腦程式之非文字部分可為表達而受著作權法保護,但如前所述,就構想與表達之判別一節,僅只援用抽象測試法,並未針對電腦業界之特性有所調整。然則,電腦程式之撰寫雖可能有多種方法,就著作權法對傳統著作所用之必要場景原則或合併原則 (The merger doctrine)而言,其表達方式應受著作權法保護,蓋唯有構想之表達方法為惟一或極其有限時,構想或表達方始合併而不受保護,他人始得自由模仿,惟實際進行電腦程式之開發時,基於邏輯演繹法上效率之考量、基於市場上之硬體規格標準已無法改變、或基於應用程式須受制於作業系統之牽制,事實上能選擇者極為有限,而傳統之抽象測試法對此並未予以考量。
       第二巡迴上訴法院在一九九二年六月之Computer Associate International, Inc. v.
Altai, Inc. 案[51]乃針對抽象測試法予以修正使適合於電腦程式著作權侵害之判斷。
       緣Altai 公司本即擁有一「工作進度程式」(job scheduling program) ﹐此程式稱為 Zeke﹐本來設計在VSE作業系統上使用﹐其主要功能在於控制電腦CPU執行多個不同之程式指令之先後次序。Altai公司僱用Computer Associates公司(以下簡稱CA公司)之職員Claude Arney為此程式撰寫與MVS作業系統匹配之介面(interface)程式﹐以便將Zeke之程式翻譯為MVS之作業系統程式能瞭解之語言。
       CA公司本有自有之工作進度程式﹐稱為CA-Scheduler,該公司並已自行開發稱為Adapter之工具程式﹐能使 CA-Scheduler在Dos/VSE﹑MVS﹑及CMS作業系統上使用﹐此Adapter乃是CA-Scheduler之次程式(sub-program)﹐並未能單獨使用﹐一向與CA-Scheduler程式一同出售。Arney非常熟悉Adapter程式﹐當其受雇前往Altai公司工作時﹐將Adapter之原始碼同時一帶至Altai公司﹐並抄襲Adapter程式之百分之三十﹐為ZEKE發展出稱為OSCAR 3.4 之介面程式。當CA公司對Altai公司提起訴訟後﹐Altai遂另派一組程式設計師重新撰寫 OSCAR程式﹐這些工程師以前未接觸過OSCAR程式﹐受命開發新的OSCAR程式後﹐亦被禁止接觸Arney本人及Adapter之原始碼﹐工程師只是被給予ZEKE之資料以便能發展介面程式﹐最後開發出OSCAR 3.5 版之電腦程式。
        Altai公司對於地方法院判決其所有之OSCAR 3.4 電腦程式侵害CA 公司之著作權一節並未上訴﹐因此在上訴法院之系爭重點在於其後所開發之OSCAR 3.5   是否構成抄襲。上訴法院法官Walker審理結果﹐判決稱OSCAR 3.5 並未侵害CA公司在Adapter軟體上之著作權。
       上訴法院同意Whelan案判決之意見﹐認為電腦程式之非文字成分(non-literal element)可為著作權保護之標的﹐但不同意Whelan案中法官所稱每一電腦程式僅有其基本目的(purpose)為構想﹐一旦該單一特定構想被確定﹐則其餘之部分均為表達(expression)之法律意見。Altai案之法官 Walker 認為﹐每一模組(module)或副常式(subroutine)均蘊涵一構想﹐故電腦程式之構想可能有多個﹐而非單一。
       至於如何認定電腦程式有無抄襲﹐法官Walker採用「抽離-過濾-比較法」(abstraction--filtration—comparison test)之三步驟測試法。細言之﹐第一步驟乃由法院將涉及被侵害著作權之電腦程式之各部分組成結構(constituent structural parts)予以解構(dissection)﹐此種解構之程序由程式目的碼開始﹐包含原始碼、參數表、模組(module)、常式(routine)、次常式(subroutine)、順序(sequence)、條件(condition)、乃至程式最終功能之一般性描述。在Altai案中﹐經此抽離後﹐法院發現﹐如依各層級漸增普遍性 (increasing generality)之方法排列﹐則其抽象化程度(the level of abstraction)依序為:目的碼﹑原始碼﹑參數表 (parameter   lists)﹑所要求之服務(services required)﹑及最後之一般性之輪廓(general outline)。此抽離之方法即是援用法官 Hand 在其抽象測試法中所用之抽離(abstraction)之方法。
       第二步驟則為過濾﹐亦即當分解(breakdown)完成後﹐將不受著作權法保護即未具可著作權性(copyrightability)之思想及其他屬於公共財產之部分濾除。依上訴法院之見解﹐所謂未具可著作權性之部分乃指具有高度抽象性(a high level   of abstraction)之成分﹐此包含構想﹑公共財產(public domain)﹑及基於效率(efficiency)或電腦軟硬體功能外部因素(external factors)所限制之部分。法官Walker指出﹐雖然可能有很多種方法可以完成該程式所要到達之目的﹐但基於效率之實際上限制﹐可能只有一種或二種表達方法﹐在此情形﹐構想應與表達合併﹐而不受著作權保護。依Walker之意見﹐於完成前述兩步驟後﹐原告所稱其著作權被侵害之電腦程式不受著作權保護部分已被去除﹐所留者均為具有著作權法保護之適格。然後進入第三步驟﹐即將原告程式可受著作權保護之表達與被告之電腦程式詳細比較﹐以判斷是否有相似,如有相似,是否構成實質相似(substantial
similarity)。
       藉著以上三步驟測試法﹐Altai案之法官解構(dissect)原告之程式﹐區分每一抽象層級(isolating each level of abstraction)﹐同時過濾排除其中因具有抽象普遍性或因基於效率考量或其他外部因素考量因而不受著作權法保護之成分﹐最後﹐法院將原告程式中所過濾餘下之部分( 含程式之文字碼 ) 與被告之程式比較結果﹐認定被告公司並未侵害原告之著作權﹐該案援用抽象測試法再加以修改,其細緻處實令人印象深刻。
 
16.7.2            濾除之標的與思想與表達之合併之關係

       值得注意的是在第二步驟之過濾程序中,法官在決定應濾除之內容時,其所採用之基準,究其實質,即係思想與表達之合併理論。據此理論適用之結果,不受著作權法保護之成分乃指:

16.7.2.1             基於內部效率因素考量所決定之部分
       電腦程式之執行最重效率,法院認為達成同一功能之途徑雖可能有多種,但最有效率之執行方法卻可能只有一種或極其有限。故倘因基於效率之考量而限縮了表達方式之選擇範圍,因而造成程式表達方法之相似,在此情形下,應認為思想與表達合併,均不受著作權法保護。

16.7.2.2  基於外部因素之考量所決定之部分
       判決中指出,程式之開發者經常受下述之外部考慮所限制,故表達與思想應合併,而排除在著作權法保護之範圍之外:
1. 將來執行該程式之電腦機器規格(mechanical specifications);
2. 此程式與其他程式(作業系統或其他介面程式)之相容性;
3. 電腦製造商之設計標準規格;
4. 基於特定產業所撰寫之程式,該產業對此程式之實際需求;
5. 電腦業界普遍被接受之程式撰寫慣例。
       該案所使用第一步驟之抽離即是法官Hand之抽象模式基準測試法,但Altai案中法官Walker所發展之「過濾」卻遠較Hand法官所描述者為精緻。在Nichols案中,法官Hand僅將著作中具有普遍性(generality)之成分列為思想,具有特殊性(specificity)者歸類為表達。但在Altai案中,法官將有普遍性之概念延伸及於基於效率或電腦之外部因素所不得不採行之表達方式。換言之,Altai案就電腦程式之非文字成分結構是否具有普遍性之判斷,已使用思想與表達合併之原則而予充實及修正,該案所採用之測試法嗣後廣為後續案例所援用[52]

16.7.3           Nimmer 連續過濾測試法(Successive Filtering Method) 
       美國著作權法大師Nimmer指出,由於法官及陪審員對於電腦程式很難以理解,因此判斷有無侵害著作權時非常不容易。特別是在判斷電腦程式之結構、組織之非文字侵害時顯得極為困難。抑有進者,電腦程式不但是藝術,也是一種科學。程式之撰寫者通常沒有像傳統文學著作一般之廣泛表達選擇權。有些外部因素,例如程式所使用之電腦硬體標準、該程式與其他程式間之互動或是該程式所欲解決問題性質等,均會影響或限制程式之設計、結構與實際碼(actual code)。除此以外,電腦科學已有極多之文獻可以提供撰寫不同種類程式之共同程式技術,而此種技術並非程式撰寫人個人之創意所得,故吾人可在不同種類之電腦程式中發現有甚多共同之撰寫程式技術。
       再者,電腦軟體市場之本質亦使得電腦程式之著作權侵害判斷不易。在很多領域內,同一種功能之多數軟體往往直接面臨競爭。因此,即使是獨立創作之軟體亦可能在很多方面均甚為雷同,因此,分析其模式是否具有普遍性、是否應使思想與表達合併等益趨複雜,故有必要為電腦程式提出分析方法作判斷著作權侵害之準據。
        Nimmer指出,雖然著作權保護原創性,但並非所有之原創性作品成分均受保護,必須屬於表達才有受保護之適格。故在評估著作實質相似時,理應將不受著作權法保護之成分去除(eliminate)。但欲完成此工作,必須先將電腦程式分成不同之數個層級(several different levels),不同之著作權學說適用於每一層次,並基於該學說濾除原告著作中不受著作權法保護之成分,然後就所餘留之受保護之成分與被告著作為實質相似之分析與判斷。
       Nimmer鑑於上揭電腦程式之特殊性及新的分析方法必要性,乃綜合整理美國聯邦法院實務上之見解,發展出「連續過濾法」(The Successive Filtering of Computer Programs)[53],並認為連續過濾測試法不僅適合於電腦程式著作權侵害之判斷,且當然可適用於傳統著作之解析。根據Nimmer之理論,判斷電腦程式何種部分受著作權法保護,應將下列成分先連續過濾排除,所剩餘者即為受保護之部分,然後再與被訴侵害其著作權之著作物比較是否實質相似。
       Alai案之判決於進行第二步驟「過濾」(Step Two:Filtration)時,即明白支持Nimmer之連續測試法並予援用,認為於分離(separating)著作中受保護與不受保護之成分時,應使用用該法決定每一抽離後之層級(each level of abstraction)之結構成分(structural components)是否被效率所支配(dictated by consideration)而構成思想與表達之合併,並因之判斷著作權法保護之範圍[54]

16.7.3.1            排除電腦程式中僅屬抽象構想之成分(excluding program
                          elements that constitute only abstract ideas)

       著作權法僅保護思想或觀念之表達,不保護思想或觀念本身,此乃我國與美國著作權法之所同,因此,依Nimmer意見,第一步驟首須將思想與表達分離,並將思想之成分過濾排除,因為在電腦科學中,思想係任何人均得接觸並模仿的。
       按一個電腦程式通常是由一個非常一般性之功能描述開始,例如設計一個事務所之利潤計算程式等,此種功能描述僅是一般性之思想。然後,程式設計師研究終端使用者之需求並分析問題之輪廓,並描述資料結構(data structure)及執行法(algorithm),在此階段,流程圖(flow charts), 假碼(pseudo-code)常被程式設計師使用以組織程式之結構。程式設計師可能將一個問題分為數個模組(modules)或次常式(subroutines)。每一模組或次常式解決整個程式問題之一特殊部分。此模組或次常式本身亦可能分割為更多之模組或次常式。至最後,則是將此模組與次常式以原始碼編碼,並協調模組或次常式間之互動關係。
       在此階段,何者為應不受保護之抽象部分乃成為問題之所在。Nimmer氏指出判斷之際應參考法官Hand在1930年所提出之「抽象測試法」(abstraction test)。依該測試法,法院應將著作中各事件逐漸抽離,產生越來越抽象或越來越普遍化之一般性「模式」 (patterns),此種普遍化之模式可普遍適用於一般其他作品之主題或戲劇之名稱即是。故在此一連串之抽離過程中,必然存在某些屬公共財產(public domain),為著作權法所不保護之思想。具有抽象普遍性(generality)之模式為思想,未具普遍性之模式則為表達。是故,如兩作品間之事件順序、角色之特徵、劇本之布局等相當細微而不具普遍性之模式亦為實質相似,則屬表達之抄襲。
       依Nimmer氏之看法,此抽象測試法雖原來旨在判斷文學著作(literary works)、戲劇著作(dramatic works)及電影著作,但以之用來分析電腦軟體何種部分應受保護則是相當適合
。發展電腦程式時所用之系統性之方法將使得抽象測試法更易於使用。傳統之文學著作並非像電腦程式般有系統性、秩序性之組織。在大部分之情形,文學作品可能在撰寫之始即等同於最後之完稿,並未如電腦軟體般須有廣泛之準備或系統性之發展。但電腦程式設計初始,程式設計者對於電腦程式應有何種功能往往只有一個相當普遍化之概念(general notion),此部分乃屬於不受著作權保護之範圍。當程式設計完成時,設計者已完成原始碼之撰寫。在這兩極端之間,特殊化(即表達之方式是否唯一或有限)之程度將成為決定構想或表達之基礎。
       職是,Hand法官之抽象測試法事實上已隱含著任何特定之著作可能包含著無數個構想及表達,範圍從最簡單之一般性之陳述開始,例如「這著作是關於什麼」,以迄文字或程式碼之選擇。抽象測試法可強迫法院思考何者是電腦程式中重要之構想、何者具有一般性及何者
具有特殊性,法院必須在保護著作人之勞力及使他人得自由利用之公共需求間取得一定之平衡。
 
16.7.3.2             排除程式中因邏輯、效率因素所支配之成分(Excluding Program
                            Elements Dictated by Logic and Efficiency)

       按照「合併原則」(The Merger Doctrine),如思想或觀念只有一種表達方法時,則該表達與構想合併,著作權法將不予保護,否則無異使思想亦為著作權法所保護,因而造成思想之獨占。在電腦程式領域內,因產業之特性,合併原則之適用與傳統著作權法有些不同。雖然在理論上完成特定電腦程式之構想存有甚多表達方式,然基於程式執行之效率考量,程式之設計者只能被迫選擇一種或兩種表達方式,因而實際上其他之表達方式已被排除。在此情形下,根據合併原則,該特定的表達將不再受保護,該表達成分因此應予排除。
      電腦程式中有關輸入資料搜尋及分類之執行法或邏輯演繹法(Algorithm)[55]可對此提供最佳之說明。任何處理大量資訊之電腦系統將耗費相當時間用於資料的搜尋及分類,故花在資料搜尋及分類之時間將影響程式之操作速度。因此,設計師均渴望尋找一種有效率之方法以執行此工作,並投入相當多時間、精力於研究找出相對有效率之方法。雖然有多種搜尋資料之方法,惟經研究發現,僅有少數幾種方法才真正迅速有效,故在理論上思想雖有多種的表達方式,然基於執行效率考量,設計師往往不得不採取該效率最高的表達方式,在此情形下,合併原則乃有適用之空間,該最有效「表達方式」將不受著作權保護。此外,兩造電腦程式如皆採用最有效率搜尋及歸類檔案資料之表達方式以設計程式時,縱有雷同,此一最有效率之分析方法即可作為獨立創作抗辯之參考,亦可作為思想與表達區分與合併判斷之依據。
 
16.7.3.3                  排除程式中受外部因素支配所形成之成分(Excluding Program
                               Elements Dictated by External Consideration)

       依據「必要場景原則」(Scenes a Faire),著作人在處理某一類戲劇、小說主題時,實際上不可避免而必須採用某些事件、角色、布局、或布景,雖該事件、角色、布局或布景之表達方法與他人雷同,但因為係處理該特定主題不可或缺或至少是標準之處理方式,故其表達方法不構成著作權之侵害。
       此原則通常適用於以事實或歷史事件為題材之著作(factual or historical work),因該事實或歷史事件常支配該著作之表達方式。但此原則在電腦程式領域內亦有其適用,蓋在特定的電腦環境下,欲設計某程式以完成特定任務,幾乎完全不可避免地必須配合或使用當時之標準技術(standard techniques)。因此在判斷電腦程式著作權之侵害時,依Nimmer之見解,法院必須將這些完成該程式特定功能所不可或缺或至少是標準處理方式之成分剔除。這些影響電腦程式設計之外部因素通常為:
1.    硬體標準(Hardware Standard)   
       電腦程式所欲適用之電腦支配該程式中的許多成分。程式設計師為使其程式適於某特定
規格電腦,必須符合該電腦之設計標準來設計其程式,以便能在該電腦上操作。這種因硬體
標準所導致在程式中有甚多相同成分之結果,與傳統文學著作中所適用之「必然情景原則」
之情形並無二致。因此在適用於同一類型電腦之不同程式間必然存在有甚多相似之處。此種
相似不是由於獨立創作(independent creation)之結果,而僅僅是由於欲求程式在該型機器操作所必要之設計。
       舉例言之,當電腦程式必須以標準指令驅動電腦內部功能。以IBM個人電腦為例,欲使
其電腦螢幕上產生影像(video display)必須使用某種正確格式(a precise format)之字母
(characters)或符號(graphics)。任何將使用IBM電腦之電腦程式,如果想在其螢幕上顯示影像,必須在程式中包含這些特別指令。職是,不同電腦程式間之相似如係導源於此種硬體標準,則該相似之處不應構成著作權之侵害而應予濾除。
       抑有進者,電腦硬體上之特定碼(specific code)亦可能形成程式寫作之限制。舉例言之,
IBM個人電腦之鍵盤最上一行包含著10至12個鍵(F1,F2...)能執行數種不同功能。在很多程式內,這些按鍵用以取代電腦螢幕上之功能表(menu),該功能鍵之目的,即在於提供程式設計師作為設計程式之基礎,因而二程式間使用相同的功能鍵界面(function key interface)不應被認為是著作權之侵害[56]。法院對於甚多類似此種硬體標準限制軟體設計之成分應在專家之協助下予以濾除。

2.    軟體標準(Software Standard)
       如同電腦硬體標準支配電腦程式之成分,在開發程式或執行程式時之軟體環境亦可能支
配該程式的成分。任何終端使用者程式(end user program),例如文書處理系統程式或試算
表程式,必須與操作系統程式(operating system)[57]溝通。因此,電腦程式與作業系統程式間
相容性(compatibility)之考量將支配該應用程式之設計,例如程式讀取磁碟中檔案資料的方
法或程式使用者呼叫程式方式即是。因此,在同一作業系統中執行且功能又相同之程式很容
易有相似之處。此種相似並非因程式抄襲所造成,故不應為判斷著作權侵害之考慮要素。
       除作業系統程式之限制外,撰寫程式時所使用之電腦語言亦會控制該程式之部分成分。
例如,程式設計師所得以選擇使用之資料結構形態(the types of data structures)將視其
所使用之電腦語言而定,因此程式之資料之流程(flow of data)及次常式之順序(the
ordering of subroutines)顯示極大之相似性。這些因為軟體環境特性之限制所產生之近似
既非由於抄襲之結果,均應予以濾除。

3.    電腦製造廠商的設計標準(Computer Manufacturers' Design Standards)
       電腦製造廠商經常為軟體設計者建立標準,提供程式設計師於設計程式時參考,以便於其所設計的程式能與該廠製造之電腦相容。這些標準與程式之正確執行與否並不相關,通常只是關於使用者介面(user interface) 或是關於螢幕顯示的風格(nature)而已。電腦製造商提供設計之標準,目的在使電腦程式設計師有一致而熟悉之界面以便撰寫。雖然在開發電腦程式之過程中並非完全必須依循上述電腦廠商之標準,但電腦製造廠商常藉由此手段鼓勵程式設計者依循該標準去設計電腦程式。故如果兩程式之近似乃因使用該廠商所設定之標準所造成,實不應被認為被抄襲之結果,故該相似部分亦應先予濾除。

4.    電腦程式使用者之商業上習慣(Target Industry Practice)
       程式終端使用者之商業上慣行(practice)之方法或技術要求乃為影響程式設計最重要
之外在因素。例如,為紐約證券交易所之股票買賣而設計之程式必須遵守證券交易之法令規
章及實務運作。因此,倘二個程式均為同一商業行為而設計,二者之間將會有相當程度之相
似。
       此種外部因素所造成的相似不應被用來判斷該二程式結構與組織是否構成著作權之侵害。聯邦第五巡迴上訴法院即基於此原則在有關棉花市場交易程式之實質相似判斷時稱:「系
爭兩造有關棉花市場交易程式之相似部分係由棉花市場之外部因素所支配(dictated by the
externalities of the cotton market)」
,因而駁回原告假處分之聲請[58]

5.    電腦軟體工業在設計程式時之習慣(Computer Industry Programming Practices)
       電腦軟體工業所普遍接受與使用之程式設計習慣及技術亦是構成不同電腦程式間相似的
原因之一。大部分之程式設計師均倚賴傳統方法解決程式設計方面所面臨的問題。例如在處
理一些設計程式時數量未知之大量資料而欲將該筆資料加以分類及取回時,程式設計師已發
展並運用一種稱為「連結表列」(linked-list)的資料結構法。該方法允許無限制地增加、
刪除或取回任何表列上的資料,並改變儲存於記憶體之位址,唯一限制是電腦記憶體必須足
夠。此方法可改變表列的大小及所佔用記憶空間位址,使得此種資料結構法成為廣受歡迎之
程式設計技術,常出現於眾多獨立創作之電腦程式中。
       職是,程式間雖使用相似方法或技術,但尚不能作為著作權侵害之證據,因為一般標準
程式設計技術就如同「必要場景原則」中所稱之普通主題、事件或情節等成分,只是屬於電
腦程式中平凡不具創意的平凡成分(stock element)。雖然如此,法院處理此外部因素之過濾
時必須謹慎小心。按電腦程式設計乃是一種具高度創作性及個人性(individualistic)之活
動,故法院不應輕易採信被告辯解,率認原告之電腦程式僅係由某些眾所周知的技術與物質所
組成,而不具有任何的原創性及技巧。當然法院亦不可輕率相信原告所主張兩程式之組織、
結構有高度之相似,而在未經被告適當解釋該部分之重要性及其形成之原因之前,即為對原
告有利之判決。然則,倘如一個程式是過於暢銷,以致於使用者期待其鍵盤使用與命令結構
在任何程式中均可出現而執行相同之功能,在此情況下,被告是否能主張其所模仿之成分僅
係電腦工業之標準或習慣,不能構成著作權之侵害。就此問題,Nimmer認為如該成分係源自
於原告自己之創意而與其他之外部因素(external factors)無關,則自應受著作權之保護,
不能因其銷售成功而剝奪著作權法保護之適格[59]
 
16.7.3.4                排除程式中擷自公共財產之成分(Excluding Program
                             Elements Taken From the Public Domain)

       眾所周知,公共所有之成分不受著作權法保護;縱使其被使用於受著作權保護之著作中亦然。法院於系統分析比較兩程式的相似時亦須特別注意此點。
       在電腦工業之領域中,有無數之電腦程式屬於公共所有之成分。BBS站亦提供很多自由使用之軟體。此外,電腦程式設計之相關書籍中亦載有許多實際碼(actual code)之例示並鼓勵設計者複製。程式設計師經常將屬於公共所有電腦軟體使用其程式中,故於比較兩程式間是否構成著作權侵害時,法院必須將此些屬於公共所有之成分排除。
 
16.7.3.5               所餘成分之相似性之分析(Analysis of any Remaining Similarities)
       經由上述連續過濾原則將原告程式連續過濾後,所剩餘者只是原告程式中受著作權保護之成分,以此成分與被告之程式相比較,再判斷其近似是否已達到充分(sufficient)之程度,而決定是否構成著作權侵害。倘如被抄襲之成分乃微不足道(de minimis)時,則不足以構成實質近似,但有時雖被抄襲之數量甚少,但對原告程式卻特別重要,則亦可能構成實質近似。例如雖然只是抄襲程式一小部分,但卻是該程式獨有之特色,為該程式具特殊創意之所在,為使用者所特別喜歡,則亦足以構成實質相似。
       Nimmer氏之連續過濾測試法係以抽象測試法為基礎而發展,氏更舉莎氏比亞之劇本「羅蜜歐與茱莉葉」(已喪失著作權之保護而為公共財產)、「阿比的愛爾蘭玫瑰」(Abie's Irish Rose)及電影「西城故事」(West Side Story)為比較之案例,以說明抽象測試法之精義。氏認為「兩個敵對家族成員間之羅曼史」乃是普遍性之模式,為抽象性之構想,無數之故事與劇作均以之為基礎,「阿比的愛爾蘭玫瑰」即其適例。但該劇之模仿僅止於此,故不構成著作間之實質相似。
       但西城故事則不然。此音樂戲劇及電影描述在現代紐約城中兩個互鬥中之少年幫派成員間之愛情故事,其對白全新、很多角色特質及故事發展(story line)與情節均與莎劇不同,乍看似「阿比的愛爾蘭玫瑰」情形,均未與莎劇實質相似。但依Nimmer分析,西城故事與羅蜜歐與茱莉葉不僅前述之普遍性之構想相同,在重要事件之次序及角色互動也相同,氏列舉其相同之處如下:
1. 男孩與女孩均是互有敵意團體之成員;
2. 他們在舞會相識;
3. 他們夜裡在陽台墜入情網;
4. 女孩已與另一名男子訂婚;
5. 男孩與女孩互相立下婚約之誓言;
6. 當兩個敵對團體相遇時,女孩之堂兄弟殺死男孩之摯友;
7. 男孩之摯友所以死亡,係因男孩為避免暴力衝突,阻攔其摯友之手,以至於其摯友被刺死亡;
8. 男孩為其摯友報仇,殺死女孩之堂兄弟;
9. 其結果,男孩逃亡藏匿;
10. 當男孩逃亡途中,女孩曾託人送訊息給男孩,告訴男孩她將與男孩在某處會面之計劃;
11. 但男孩一直未接獲此訊息;
12. 嗣後男孩聽說女孩已死亡;
13. 男孩很悲傷,因此自殺(或讓其自己被殺)。
以上所列舉13點具有某種程度之抽象性,自各點往下分析,則有甚多不同細節,但均被省略,但此13點相同之處絕非最高程度之抽象層次,最高層次之抽象性是「兩個敵對團體成員間之羅曼史」,此基本構想與「阿比的愛爾蘭玫瑰」完全相同,均非著作權保護之範圍。雖然此13點相同之處有相當程度之抽象性,但已足夠具體描述兩作品中「重要之事件次序」(the essential sequence of events)及「角色之互動」(character interplay),均屬於著作權法中應予保護之「表達」,故如莎氏比亞之劇本「羅蜜歐與茱莉葉」仍有著作權,西城故事之著作人已侵害著作權。是以依Nimmer之理論,如劇本或小說情節(plot)之模仿已具體地包含於作品中「重要之事件次序」及「角色之互動」時而非僅是主題或高度抽象性之模式相同時,則可構成「實質相似」(substantial similarity)。

 
[49] Computer Associates International, Inc. v. Altai, Inc., 982 F.2d 693 (2d Cir. 1992).
[50] 在Alai案中,法官在標題為「Substantial Similarity Test for Computer Program Structure: Abstraction-Filtration -Comparison」下,明白將此判斷方法稱為三步驟測試程序(a three-step procedure)),並分別描述其三步驟分別為:「Step One: Abstraction; Step Two: Filtration; Step Three: Comparison」. See Altai, 982 F.2d at 706-710. 但亦有稱之為「three-pronged approach」, see Daniel A. Crowe, The Scope of Copyright Protection for Non-Literal Design Elements of Computers Software: Computer Associates International, Inc. v. Altai, Inc. 37 St. Louis U. L.J. 207,229 (Fall, 1992).
[51] Computer Associates International, Inc. v. Altai, Inc. 982 F.2d 693 (2d Cir. 1992).
[52] 下列之案例均採用Altai之測試方法:Sega Enters., Ltd. v. Accolade, Inc., 977 F.2d 1510,1525 (9th Cir. 1992)(“the Second Circuit’s approach is an appropriate one”; Atari Games Corp. v. Ninentendo of Am., Inc., 975 F.2d 832,839 (Fed.cir.1992)(citing Atari, “the court must next filter the protectible components from the protectible expression.”); Apple Computer, Inc. v. Microsoft Corp., 35 F.3d 1435, 1445(9th Cir. 1994)(“same process of analytical dissection albeit articulated differently from Altai”), cert denied, 513 U.S. 1184(1995). See generally 4 NIMMER ON COPYRIGHT, 13.03[F]( April 2005); Morgan Chu & Andre Brunel, Computer Copyright and Trade Secret Litigation After Altai, 369 PLI/PAT 223,236(1993); Thomas M. Byron, As Long As There Is Another way: Point v. Charlene Products As An Accidental Template For A Creativity-Driven Useful Article Analysis, 49 IDEA 147, 156(2009); Peter Lee, The Evolution of Intellectual Infrastructure, 83 Wash. L. Rev. 39,79(2008).
[53] 請參考Nimmer on Copyright, vol. 4, April 2005, §13.03[F].
[54] Altai, 982 F.2d 693 (2d Cir. 1992) at 706 (“Once the program’s abstraction levels have been discovered, the substantial similarity inquiry moves from the conceptual to the concrete,. Professor Nimmer suggests, and we endorse, a “successive filtering method” for separating protectable expression from non-protectable material. See generally 3 Nimmer §13.03〔F〕. This process entails examining the structural components at each level by considerations of efficiency, so as to necessarily incidental to that idea; required by factors external to the program itself; or taken from the public domain and hence is nonprotectable expression.”) 
[55] Algorithm 在美國聯邦法院一度被認為是數學邏輯演繹法,惟其後已予澄清。在 In re Pardo, 684 F. 2d 912,915 (C.C.P.A.1982)案中,法院審理結果認為該案申請者雖利用電腦程式以產生特定之結果,但該程式並未涉及數學邏輯演繹法則(mathematical  algorithm),其申請可授與專利。另外,在Diamond v. Diehr 450 U.S. 175, note
      9, Justice Rehnquist 承認在 Benson及Flook案中algorithm之定義太窄,algorithm 應有更廣之意義,包括完成特定目標之一系列步驟。要言之,algorithm與電腦程式之關係可擇要陳述如下:(a)algorithm(邏輯演繹法則)乃是一組指令(instructions),操作者遵照此指令執行每一步驟達成特定目標,但不一定與數學有關;(b)algorithm 不一定以數位電腦為其指令之執行者;(c) algorithm 是電腦科學之基礎,每一電腦程式至少包含一個algorithm; (d)algorithm能被用來解決很多問題,不僅僅是數學問題。
以上可參見John Swinson," Copyright of Patent of Both: An Algorithm Approach to Computer Software Protection."(1991)5 Harward Journal of Law & Technology145, 148-150;羅明通等著,電腦法,上冊,83年11月,第89至94頁。
[56] 依美國聯邦法院之見解,鍵盤敲擊之順序(key-punching sequences)乃是表達之一部分而為著作權法所保護。故如原告之電腦程式改變原來電腦設計,另以程式改變功能鍵之功能,而被告之程式在此部分居然與原告相同,則其甚有抄襲之可能性。詳見 Nimmer, supra §13.03[F].
[57] 所謂作業系統是一種介乎電腦硬體與終端使用者間之界面程式,經由此界面程式,使用者可驅動硬體並提供一個使用者可執行其程式之環境,例如DOS及WINDOW 95即是作業系統程式。
[58] Plains Cotton Coop. Ass'n v. Goodpasture Computer Serv., Inc., 807 F.2d. 1256, 1262 & n.4(5th Cir.), cert. denied, 484 U.S. 821 (1987).
[59] See Nimmer, supra §13.03[F][3][e].