淺談評價專利申請文件撰寫質(zhì)量的基本原則

2004-12-15
淺談評價專利申請文件撰寫質(zhì)量的基本原則
文/集佳知識產(chǎn)權代理有限公司 資深專利代理人 逯長明
專利申請文件的撰寫質(zhì)量能夠決定一個技術方案的命運，追求專利申請文件的撰寫質(zhì)量是申請人不惜代價要作的事。所謂申請文件質(zhì)量高，是指一個申請文件表述的技術方案具有較強的有效性，從另一個角度說是具有較少的撰寫損失。因此，在申請人進行文件審核或者代理人進行文件撰寫時，如果能夠盡可能發(fā)現(xiàn)申請文件的不當之處，就可以提高申請文件的質(zhì)量。
高質(zhì)量申請文件有四個明顯的特征：（1）主題抓得準；（2）權利要求、說明書清楚；（3）權利要求、說明書有效且說明書公開充分；（4）權利要求層次分明、保護范圍適當。只有在撰寫階段充分認識現(xiàn)有技術和本發(fā)明技術方案的基礎上，充分考慮審查、無效，甚至訴訟階段可能出現(xiàn)的問題，才有可能撰寫出具有上述特征的申請文件。一般認為，申請文件的撰寫依賴代理人的三方面要素：技術能力、法律修養(yǎng)和基本素質(zhì)。技術能力能夠影響代理人與發(fā)明人的交流質(zhì)量，從而影響技術方案的挖掘是否充分以及對技術方案的再創(chuàng)造程度；法律修養(yǎng)（主要指專利法修養(yǎng)）決定了代理人是否能夠將一個技術方案按照法律的要求恰當?shù)刈珜懗鰜恚⑶疫@種撰寫充分考慮到了審查階段和可能出現(xiàn)的無效、訴訟階段出現(xiàn)的問題；基本素質(zhì)能夠決定撰寫效率、減少撰寫損失的程度等。由于撰寫不當能夠降低申請文件的質(zhì)量、影響其有效性，但是任何人的所述三要素都不可能完美無缺，尤其在所述三要素有缺陷時，更難以避免撰寫損失，因此，討論評價專利申請文件撰寫質(zhì)量的基本原則就具有特殊的意義。
申請文件質(zhì)量不佳會以多種形式出現(xiàn)，例如，口頭語、方言土語、語句過于復雜和語法規(guī)則雜亂可能導致文件內(nèi)容不清楚等問題。本文要討論的基本原則不涉及上述純粹由代理人基本素質(zhì)導致的問題，只涉及由于三要素缺陷導致的專利法的理解問題，更具體地說涉及審查指南的理解和運用的問題。
鑒于審查指南規(guī)定了專利說明書的組成部分及其關系和權利要求的撰寫原則，因此，依據(jù)審查指南所規(guī)定的說明書、權利要求書的撰寫方式和規(guī)定可以獲得內(nèi)容“匹配原則”；依據(jù)獨立權利要求和從屬權利要求的撰寫方式和規(guī)定可以獲得“鑲嵌原則”、和“替換原則”，上述原則可以用于確定申請文件是否存在形式、構思等缺陷，例如表述方式缺陷。
所述匹配原則，就是核查說明書的主題名稱、技術領域、背景技術及問題、本發(fā)明要解決的問題與（獨立）權利要求（發(fā)明方案）、發(fā)明效果之間的匹配關系，如果上述內(nèi)容的每個部分不清楚、表述有缺陷或各部分之間邏輯上不協(xié)調(diào)，相互不支持，就不符合匹配原則。因此，該原則可用于審核說明書各部分內(nèi)容、各部分內(nèi)容之間，說明書和權利要求書之間，權利要求的各個特征自身、特征之間以及有引用關系的不同權利要求之間的內(nèi)容是否匹配，從而確定上述內(nèi)容是否存在撰寫缺陷。匹配原則核查的對象是邏輯支持的充分性和準確性，適用于說明書和權利要求書的核查，例如權利要求中特征語句間的邏輯和特征語句本身的邏輯是否準確、充分等。
所謂鑲嵌原則和替換原則主要來源于權利要求撰寫的下述規(guī)定：1、獨立權利要求應當包括前述部分和特征部分，其中前述部分記載與最接近的現(xiàn)有技術共有的必要技術特征，特征部分記載必要的區(qū)別特征；2、從屬權利要求包括引用部分和限定部分，其中限定部分記載附加技術特征，該附加技術特征是對所引用權利要求技術特征進一步限定的技術特征，也可以是附加技術特征。3、權利要求的內(nèi)容應當與要解決的技術問題有關。因此，在獨立權利要求撰寫合理時，每一個從屬權利要求與其引用的權利要求結合起來應當能夠構成一個完整的解決技術問題的技術方案。更具體地說，如果具體的附加特征是追加型特征，則將新的特征鑲嵌到原特征集合中應當能夠構成一個新的、完整、合理的技術特征的集合，即符合鑲嵌原則；如果具體的附加特征是對所引用權利中所概括的實體特征、關系特征、限定特征（這是指針對裝置，對于方法則對應為實體特征、動作特征、限定特征）的實例化特征（即用具體支持概括的特征）或新的限定特征，則該實例化或新限定的特征替換所概括的特征，則新的特征集合也應當是完整、合理的技術特征的集合，即符合替換原則。
需要指出的是，審查指南強調(diào)的是特征，因此，在撰寫從屬權利要求時，至少應當搞清下述問題，否則可能導致不清楚：1、從屬特征是追加型特征還是實例化（限定）型特征；2、如果是實例化（限定）型特征，其所涉及的特征對象（即是哪個特征的實例化或是對哪個特征的限定）。
下面以一個實例討論上述原則的應用。該例中，重點討論所述三原則的應用，忽略了一些小問題，如概念不統(tǒng)一，描述不恰當、不準確等，所述技術方案部分用權利要求書的內(nèi)容取代，以使分析更加清楚，同時，在括號中有用下劃線和黑體字標識的評述。

防范計算機網(wǎng)絡攻擊的方法
技術領域
本發(fā)明涉及計算機通信技術，特別涉及針對DoS(Denial ofService，拒絕服務攻擊)與DDoS(DistributedDenialOfService，分布式拒絕服務攻擊)的安全技術。
背景技術
發(fā)送一個包含SYN標志的請求建立連接的TCP報文，SYN即同步(Synchronize)，同步報文會指明客戶端請求使用的服務器端口以及建立TCP連接的初始序號：第二步，服務器(或受信主機)在收到客戶端的SYN報文后，將返回一個SYN+ACK的報文，表示客戶端的請求被接受，同時確認序號為客戶端初始序列號加1，ACK即確認(Acknowledgement)。第三步，客戶端也返回一個確認報文ACK給服務器端，同樣確認序列號為服務器初始序列號加1，到此一個TCP連接完成。以上的連接過程在TCP協(xié)議中被稱為三次握手(Three-wayHandshake)。
TCP連接的三次握手中，假設一個用戶向服務器發(fā)送了SYN報文后突然死機或掉線，那么服務器在發(fā)出SYN+ACK應答報文后是無法收到客戶端的ACK報文的(第三次握手無法完成)，這種情況下服務器端一般會重試(再次發(fā)送SYN+ACK給客戶端)并等待一段時間后丟棄這個未完成的連接(half~open連接)，這段時間的長度我們稱為SYN Timeout(Timeout,超時)，一般來說這個時間是分鐘的數(shù)量級(大約為30秒—2分鐘)；一個用戶出現(xiàn)異常導致服務器的一個線程等待1分鐘并不是什么很大的問題，但如果有一個惡意的攻擊者大量模擬這種情況，偽造不同的IP地址向服務器發(fā)出大量SYN報文，并誘使服務器向偽造的IP地址發(fā)送SYN-ACK報文，服務器端將為了維擴一個非常大的半連接列表而消耗非常多的資源一一數(shù)以萬計的半連接，即使是簡單保存并遍歷也會消耗非常多的CPU時間和內(nèi)存，何況還要不斷對這個列表中的IP進行SYN+ACK的重試。實際上如果服務器的TCP／IP棧不夠強大，最后的結果往往是堆棧溢出崩潰——即使服務器端的系統(tǒng)足夠強大，服務器端也將忙于處理攻擊者偽造的TCP連接請求而無暇理睬客戶的正常請求(畢竟客戶端的正常請求比率非常之小)，此時從正常客戶的角度看來，服務器失去響應，這種情況，即通常所言的SYNFlood攻擊。
現(xiàn)有的解決方法，一種是縮短SYNTimeout時間，由于SYNFlood攻擊的效果取決于服務器上保持的SYN半連接數(shù)，這個值等于SYN攻擊的頻度與SYNTimeout之乘積，所以通過縮短從接收到SYN報文到確定這個報文無效并丟棄該連接的時間，例如設置為20秒以下(過低的SYNTimeout設置可能會影響客戶的正常訪問)，可以成倍的降低服務器的負荷。
第二種方法是設置SYNCookie，就是給每一個請求連接的IP地址分配一個Cookie，如果短時間內(nèi)連續(xù)收到某個IP的重復SYN報文，就認定是受到了攻擊，以后從這個IP地址來的包會被一概丟棄。
上述的兩種方法只能對付比較原始的SYN-Flood攻擊，縮短SYNTimeout時間僅在對方攻擊頻度不高的情況下生效，SYNCookie更依賴于對方使用真實的IP地址，如果攻擊者以數(shù)萬／秒的速度發(fā)送SYN報文，同時利用SOCK RAW隨機改寫IP報文中的源地址，則無法防范。（1、從背景技術可知，現(xiàn)有的方法無法解決改進的同步飽和攻擊（SYN-Flood）引發(fā)的問題，即無法有效防范SYN-Flood攻擊。然而從主題名稱可知，本發(fā)明談論的是一種“防范計算機網(wǎng)絡攻擊的方法”，因此，初步判斷，主題名稱可能范圍過大，易使對手找到廣泛檢索對比文件的依據(jù)。）
發(fā)明內(nèi)容
本發(fā)明要解決的技術問題是，提供一種防范SYN-FLOOD攻擊的方法，能夠阻止攻擊對HALF-OPEN連接隊列的過度消耗，使攻擊不能成功，對服務器提供保護。（1、本發(fā)明提供的方法在邏輯上與主題名稱所述的方法有錯位；2、背景技術部分明確指出現(xiàn)有技術主要的問題是無法解決“同步飽和攻擊”問題，因此，此處本發(fā)明要解決的問題應當與背景技術的問題相適應，然而，目前指出的本發(fā)明所提供的方法只能提供攻擊導致的HALF-OPEN連接隊列的過度消耗，由于HALF-OPEN連接隊列的過度消耗只是無法解決“同步飽和攻擊”問題的一個方面，還有其他如CPU資源消耗過多，緩存資源消耗過多等問題，因此目前指出的所要解決的問題與背景技術部分的問題匹配性差，可能會限制本發(fā)明權利要求的構思思路甚至對本發(fā)明的限制）
本發(fā)明解決其技術問題所采用的技術方案是：
1、防范SYN-FLOOD攻擊的方法（與主題名稱不對應，盡管可以說這是形式問題，但是由于不符合整體匹配原則，可能導致權利要求構思的錯位），包括以下步驟：
(1)攔截外來的數(shù)據(jù)包，并記錄所述數(shù)據(jù)包中所含的源主機A身份信息；
(2)轉發(fā)所述數(shù)據(jù)包至受信主機B，并設置定時器(c1)；
(3)如果在定時器cl超時以前接收到來自受信主機B的響應報文(a1)，則記錄其中的受信主機B的身份信息，并進入步驟4；如果在定時器(c1)超時尚未接收到來自受信主機B的響應報文(a1)，則釋放步驟1中記錄的身份信息；（如果“超時……”與步驟（4）矛盾）
(4)以步驟l記錄的源主機A的身份信息向受信主機B發(fā)送響應報文(a2)；并根據(jù)步驟1記錄的源主機A的身份信息，轉發(fā)受信主機B向源主機A發(fā)送的響應報文(a1)，并設置定時器(c2)；
(5)如果步驟4設置的定時器c2超時以前收到源主機A的響應報文(a3)，即撤銷定時器(c2)，視為連接建立成功；如果在步驟4設置的定時器(c2)超時，即根據(jù)所記錄的源主機A身份信息，以源主機A的身份向受信主機B發(fā)出RESET信息，撤銷該連接。（1、該權利包括較多的特征，因此范圍較小。由于背景技術沒有指出與上述特征集合相似的方法，因此可以將該權利寫得的更寬，即具有更少的必要技術特征。否則，就應當在背景技術部分指出最接近的方法，以利于權利1寫得更準確。2、可能該權利所述方案不能解決本發(fā)明要解決的問題：假設源主機A為攻擊主機，主機B為服務器，操作者為中間防火墻，由于身份信息是可以修改的，假設A在步驟（1）向B發(fā)數(shù)據(jù)包，數(shù)據(jù)包被攔截提取身份信息后在步驟2被發(fā)向B，由于B 為服務器，通常會在定時器超時前反饋應答信息，這時，在步驟（4），防火墻以A的身份向B發(fā)應答（無論A的身份為真和假可能都會成功），同時，防火墻以B的身份向A發(fā)應答，這時會出現(xiàn)2種情況，1）A的身份是真的，它可以在定時器超時前有效應答，由于A是攻擊者，它要頻繁地發(fā)出請求信息，也能夠及時應答，而防火墻對這種情況并不能處理，而這恰是背景技術部分第三段描述的現(xiàn)有技術的問題；2）A的身份是假的，使它不能反饋有效應答，則要在定時器超時后才能撤銷攻擊連接；因此，由于在超時前不能撤銷連接，可能由于攻擊導致的HALF-OPEN連接隊列的過度消耗問題仍不能解決。3、步驟（5）證明，只有定時器超時才撤銷“連接”，不知其如何解決背景技術的“超時” 問題？）
2、如權利要求1所述的防范SYN-FLOOD攻擊的方法，所述步驟(1)中，所述外來的數(shù)據(jù)包為TCP建連請求(SYN)報文，所述身份信息為初始序列號、源IP地址和源端口；創(chuàng)建TCB結構記錄所述初始序列號、源IP地址和源端口，同時記錄目的IP地址、目的端口以及該連接的初始狀態(tài)。（這實例化的權利，由公知特征組成，在權利1不成立時對新權利的成立沒有幫助）
3、如權利要求1所述的防范SYN-FLOOD攻擊的方法，所述步驟(3)中，所述響應數(shù)據(jù)包為SYN-ACK報文，所述受信主機B的身份信息為受信主機B的初始序列號、源IP地址和源端口。（同權利2的標注）
4、如權利要求1所述的防范SYN-FLOOD攻擊的方法，所述步驟(4)中，所述確認信息(a2)為ACK報文，所述確認信息(a1)為SYN-ACK報文。（同權利2的標注）
5、如權利要求1所述的防范SYN-FLOOD攻擊的方法，所述步驟(5)中，所述響應報文(a3)為ACK報文，若于定時器(c2)超時以前收到源主機A的響應報文(a3)，視為連接建立成功，撤銷定時器(c2)，并丟棄此報文，釋放該連接的TCB結構（該結構權利1中沒有）；若超時，即根據(jù)所記錄的源主機A身份信息，以源主機A的身份向受信主機B發(fā)出RESET信息，撤銷該連接，釋放該連接的TCB結構。（1、該權利的內(nèi)容不能與權利1有效結合，故應當更換描述方式；2、與權利1步驟（5）有較多的重復）
本發(fā)明的有益效果是，由于主機迅速由syn_recved狀態(tài)進入established狀態(tài)，避免了half_open隊列的過度消耗，從而降低了服務器負荷，解決了SYN—FLOOD攻擊對服務器的影響。（效果寫的不清楚，且來源無推理依據(jù)，無法說明如何“避免了half_open隊列的過度消耗”）
以下結合附圖與具體實施方式對本發(fā)明作進一步說明。
附圖說明
圖1是TCP三次握手示意圖。
圖2是本發(fā)明示意圖。
具體實施方式
作為具體的實施方式，外網(wǎng)與內(nèi)網(wǎng)之間，或者說，在源主機A與受信主機B之間以防火墻隔離，如圖2所示。防火墻對收到的SYN報文按以下程序處理：
1、源主機A向受信主機B發(fā)出建連請求(SYN)報文，報文中包含主機A的初始序列號seq(a)。
2、防火墻創(chuàng)建TCB結構(傳輸控制塊，Transmission Control趴ock)，記錄源主機A的初始序列號，同時記錄源IP地址、源端口、目的IP地址和目的端口，然后轉發(fā)此SYN報文，同時啟動SYN-ACK定時器c1，等待主機B的SYN-ACK報文的到來。如果定時器c1超時，防火墻釋放該連接的TCB結構。
3、如果在SYN—ACK定時器超時以前，主機B的響應報文a1到來，則防火墻撤銷SYN—ACK定時器cl，記錄主機B的初始序列號seq(b)，防火墻轉發(fā)此響應報文al，然后防火墻立即以主機A的身份向主機B發(fā)送ACK報文a2，使主機B的該連接從syn_recved狀態(tài)進入“tab“shed狀態(tài)，同時啟動ACK定時器。
4、如果在ACK定時器超時前，主機A的響應(ACK)報文a3到來，則防火墻認為建立連接成功，丟棄此報文，撤銷ACK定時器，釋放該連接的TCB結構。
5、如果ACK定時器超時，防火墻以主機A的身份向主機B發(fā)送RESET報文，撤銷該連接，同時釋放該連接的TCB結構。
本具體實施方式不應理解為對本發(fā)明權利要求的限制，基于本發(fā)明構思的其他實施例，例如，雖然未以“防火墻”命名，但同樣基于本發(fā)明構思實現(xiàn)的路由器功能模塊，依然屬于本發(fā)明權利要求范圍之內(nèi)。（由于實施例公開內(nèi)容太少且與權利要求類似，因此當權利要求有問題時，說明書較難提供幫助。）
通過上述例子可以看出：
1、該文件存在許多問題－主要是邏輯混亂，使該文件的有效性受到質(zhì)疑。最突出的問題是各部分內(nèi)容整體之間、各部分內(nèi)容內(nèi)部都存在不匹配的現(xiàn)象，例如主題名稱與本發(fā)明的實質(zhì)不匹配，主題名稱與現(xiàn)有技術的問題以及本發(fā)明要解決的問題、以及本發(fā)明方案不匹配；權利要求之間有些不符合鑲嵌原則和替換原則等。這樣將使各部分內(nèi)容缺乏效力以及缺乏相互之間互相支持的凝聚力，難以成為一篇有效力的申請文件，并為將來的審查程序和可能出現(xiàn)的無效、訴訟程序預留了較多的隱患，當然也增加了修改的難度和工作量。如果僅獨立地看待各部分內(nèi)容，上述問題很難發(fā)現(xiàn)，然而通過匹配原則、鑲嵌原則和替換原則就可以檢測出來。
2、源于審查指南的評價專利申請文件撰寫質(zhì)量的三個基本原則可用于評價或衡量專利申請文件的撰寫質(zhì)量，如果文件的內(nèi)容不符合三原則，則該文件肯定會存在較多的撰寫損失，文件的有效性會變差，會有較多的將來被對手利用的缺陷存在。所述三原則用于評價階段僅能用于某種程度上判斷權利要求、說明書是否有效以及是否清楚問題，難以全面解決問題是否抓準、公開是否充分得當、權利范圍和層次是否適當?shù)葐栴}。當然，將所述三原則用于撰寫階段對提高文件質(zhì)量會有較大幫助。按照經(jīng)驗，代理人如能熟練應用所述三原則，很多復雜的問題都可能輕易解決，但如何寫的更充實、有效，例如如何使權利要求1更恰當且有效等，還需要有其他的解決方法配合，例如，如何有效挖掘技術內(nèi)容的方法，如何撰寫更有效的方法、問題分析的方法。
通過上例還可以看出，由于權利1的基礎地位，其有效性對申請文件的有效性有決定性的影響。有時，權利要求1的缺陷，將會導致撰寫的從屬權利要求難以符合所述三原則，甚至導致無論如何修改也無法增加其有效性。因此，我們在討論權利要求的保護范圍以前，首先應當討論其有效性?；诳赡軣o效的權利，討論保護范圍是沒有意義的。

　

相關關鍵詞