在專利答辯過程中，為了取得專利，通常會進行修正，修正的樣態很多種，比如單純的刪除、前述基礎修正、為了明確要求的修正、為了迴避先前技術的修正，甚至是擴大專利範圍的修正以及刪除...，不過修正時，往往也會考量這樣的修正是否過度限縮專利範圍？是否產生影響將來侵權主張的"禁反言"？是否已經扭曲了本來的發明精神？一般的回應是，這些修正將來一定會被"嚴格檢驗"，如果只是取得一紙專利，那還好；如果是要積極主張專利權、尋求技術轉移、授權等用途，專利範圍的修正以及答辯內容應該要小心一點。只是，過度小心也會有過度擔心的"疑心病"，這裡有個案例表示，在法院的態度有時會"意料之外"的寬廣。
補充一點，在Festo最高法院的決定下，如果審查過程中產生限縮範圍的修正，將來主張專利權時並不適用均等論。不過CAFC法官的態度在修正時「擴大專利範圍」，將非Festo判例的適用，也就是沒有禁反言的問題。
這件"古老"的專利（申請日在1991年），從所探討的議題也可以感受到它的久遠（用UI存取資料庫，在當年或許是創舉），系爭專利揭露一種使用不特定SQL語意而存取關聯式資料庫的系統（Relational database access system using semantically dynamic objects），也就是一般資料庫存取應該依照一種標準SQL語言，也沒不好，不過還是有人希望可用更友善的語言來存取資料庫，特別是資料庫表單為互相依存（關聯），可能共享內容屬性，搜尋時有一定的複雜度，如果要解決這類問題，需要一個"介面"，這時直覺地認為這會需要一層"編譯層（如系爭專利提出的使用者介面"，其內部已經解決可以編譯一般語意到SQL標準語言的功能。
案件資訊：
系爭專利：US 5,555,403
專利權人：Business Objects, S.A.
被告侵權者：Microstrategy, Inc.（提供的產品讓使用者用一般語言存取關聯式資料庫）
案件檔案：http://www.cafc.uscourts.gov/images/stories/opinions-orders/04-1009.pdf
系爭專利界定可以不用一般標準SQL語法的語意動態物件（semantically dynamic objects）而存取關聯式資料庫的技術，其中在使用者端提供一個使用者介面，用一般熟悉的用語連結標準的SQL語法，比如SELECT（選資料庫表單）、WHERE（設定搜尋範圍），資料庫內設定一個表格來界定這些資料庫用語的功能；接著，系統接收使用者透過使用者介面所產生的搜尋指令；於是根據設定好的語言進行存取資料。
CAFC判決書提到403案可以解決的問題，可以讓使用者透過組合多種SQL語言而產生一特定搜尋目的的功能，有點像是macro script，而不用一步步鍵入SQL指令才能得到最後結果：
列舉相關獨立請求項：
claim 1：
1. A method for accessing values in a relational database, wherein the relational database operates in a computer system and provides returned values responsive to queries specified in a predefined query language, wherein the relational database supports the use of functions and operators to perform operations on values within the database, wherein the relational database includes a plurality of tables, wherein each table is associated with one or more attributes, wherein each attribute has a set of values, wherein the method includes a user interface executing on a computer system operated by a human user, wherein the computer system executing the user interface includes a processor coupled to a memory, wherein the processor is further coupled to the user interface and the relational database, the method comprising the following steps:
associating a first familiar name with a first returned value, wherein the familiar name is also associated with the following: a SELECT clause describing the values returned using a combination of the functions and operators supported by the predefined query language; a WHERE clause describing a condition which can be used to restrict the scope of the returned value; and a plurality of tables containing the attributes on which the SELECT and WHERE clauses operate;
accepting signals from the user interface to specify a query, wherein the query includes the familiar name;
generating a query in the predefined query language, wherein the query includes the condition; and
using the query to access one or more attributes in the relational database.
claim 4：4. A relational database access system comprising:
a computer system including a processor coupled to a memory;
a relational database including attributes, wherein the relational database is responsive to a query in a predefined query language for accessing the attributes in the relational database;
a user interface for allowing a human user to specify one or more familiar names in the form of a user query;
selection means coupled to the user interface for allowing the human user to select familiar names and to associate two or more familiar names together; and
query engine means for generating queries in the predetermined query language based on a given combination of two or more selected and associated familiar names, wherein the query engine means generates first and second queries based on first and second combinations, wherein the first and second combinations both include a same first familiar name but different additional familiar names, wherein the first query based on the first combination results in the retrieval of a first set of returned values based on the first familiar name, wherein the second query based on the second combination results in the retrieval of a second set of returned values based on the same first familiar name from the same database.
地院階段：專利權人對Microstrategy提出侵權告訴，不過地方法院法官在解釋專利範圍時，認為專利權人在審查歷史已經拋棄部分專利範圍，於是在進行侵權判斷時，除了認為被告侵權物並未有文義侵害外，更不適用均等論，認為侵權不成立。
CAFC階段：
專利權人於是上訴CAFC，CAFC法官在claim 1與claim 4的解釋上有同意（claim 1），以及不同意（claim 4）地方法院的決定，理由是claim 1的修正或許已經限縮專利範圍，不適用均等論，但對於claim 4的修正反而是擴大專利範圍，不適用禁反言。
解釋專利範圍：
可以參考以上CLAIM 1，其中明確界定「SELECT/WHERE」等SQL語言連結到所未熟悉的名稱而讓搜尋引擎（QUERY ENGINE）連結這些語言，以產生相關執行步驟。這些產生限制的條件使得判斷侵權時並不符合文義讀取。
不過，類似的步驟在CLAIM 4中係以功能手段用語（query engine means for generating queries in the predetermined query language ...），經參考說明書內容，仍有可以擴大範圍的空間。
侵權判斷：
因為被告侵權物並未連結SELECT/WHERE等用語為一般熟悉的名稱，因此不符合文義侵害。
對於均等論適用的判斷，針對CLAIMS 1, 2，CAFC同意地方法院參考系爭專利審查歷史中為了克服先前技術的阻礙而作出修正（直接涉及相關限制）產生了禁反言，因此認為均等論不適用，對於CLAIMS 1, 2侵權不成立。
針對CLAIM 4，專利權人於審查過程中的修正以"generating..."取代了"translating..."，CAFC法官認為這個修正反倒是「擴大專利範圍」，另有修正"predetermined"也非限縮專利範圍，因此認為不適用Festo案例，仍適用均等論解釋專利範圍。
最後發回地院，要求本案要以均等論適用（claim 4）的方式解釋專利範圍並判斷侵權與否。
後語：
審查歷史的修正都會影響專利範圍，不過仍有「縮小」與「擴大」的可能，顯然，如果是擴大範圍，並非是主動限縮範圍。如果採取比較小心的語言修正，也可能迴避禁反言的產生。
資料參考：
http://patentlyo.com/patent/2005/01/festo_defined_a.html
Ron
沒有留言:
張貼留言