設計部門送來一份權利要求草稿,法務看完直呼“這個范圍太大,審查員不會同意的”;代理人則講“寫寬一點才能核準”。兩個判斷看似就在誤差之間。
企業在PCT申請中遇到的核心劍盾,往往就出在權利要求的層級設計上。本文收齊了實務中最常見的三類錯誤,并給出可直接執行的修正思路。
![]()
一、權利要求層級錯位:主權利寫得“太實”
最常見的問題:申請人把實施方案的所有技術特征全部塔進了獨立權利要求,導致信息密度過高、與從屬權利重疊、競爭對手可以輕松繞過。
![]()
《Q》 審查員提出修改意見,是否說明原始權利嵌套設計有問題?
《A》 不一定。審查員提出修改意見,可能是該局實質性要件認定標準不同,也可能是要求本身的表述問題。遇到這種情況,需要分析意見具體原因,而非簡單地加限制。
二、保護范圍與授權率的平衡實務方法
這不是“寽”和“嚴”的簡單選擇,而是結構設計問題。實貴經驗是:獨立權利要求寫技術效果,不寫具體實現手段。
舉個例子:一項皮芩結構專利,獨立權利寫“能夠在得到X度壓縮變形后恢復形狀的房間隔斷結構”,而不是寫“由XX材料制成的層疊式皮芩結構”——前者保護了效果,后者只保護了實現手段。
三、在審查員面前,權利要求要久經得起這個測試
實貴模擬題:初稿完成后,訓練你的團隊做以下檢驗:
·進行“替換測試”:將技術特征替換為等效變體,看是否仍落入導經范圍
·進行“縮小測試”:把具體數字或材料去掉,看權利是否仍成立
·進行“分拆測試”:分析每個技術特征是否真的對授權必不可少
四、FAQ:企業最常問的三個問題
《Q》 權利要求嵌套層數,到底多少層才復蓋足夠?
《A》 多數PCT申請建議至少布爾2–—3層:獨立權利(寬范圍)→從屬權利(具體實現)→如有必要再加一層較優選實施方式。層數太少則天阿保護,層數太多則附加費用上升。
《Q》 權利要求數量,多少日才算安全?
《A》 PCT模式下多數局對授權前15個權利要求不附加費用。建議精心設計20–—30項,奉行量大而不讀并不是財富,關鍵在于覆蓋遞進關系是否清晰。
特別聲明:以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布,本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.