2017年2月，国家知识产权局局长申长雨签署发布第74号局令，《国家知识产权局关于修改<专利审查指南>的决定》自2017年4月1日起施行。此次修改主要涉及：对商业模式创新中的技术方案给予积极鼓励和恰当保护、明确对涉及计算机程序发明允许的多种撰写方式、明确申请日之后补交的实验数据的审查规则、适度放开无效宣告程序中专利文件的修改方式、扩大公众可以查阅和复制专利文件的范围等。这些修改内容解决了近年来业界非常关心的问题，引起了广泛关注。笔者亲历了《专利审查指南》（下称《指南》）整个研究和修改过程，尝试从修改的背景出发，解读修改方案，说明对于争议问题的研究和思考，希望帮助读者对《指南》修改方案形成更为全面清晰的认识。

　　涉及《指南》第二部分第一章有关商业模式的修改

　　（一）修改背景

　　目前，信息、通讯、网络等新技术发展给经济社会带来了深刻变革,从而引发了创新模式的改变——从传统的以技术发展为导向的科技创新活动转向以用户体验为中心、以共同创新、开放创新为特点的用户参与的创新模式，经济增长从技术创新和商业模式创新两个维度获得动力，我国创新主体对于涉及商业模式创新的保护存在比较强烈的需求。

　　（二） 修改方案和说明

　　此次修改在《指南》第二部分第一章第4.2节第（2）项之后新增一段，内容如下：“涉及商业模式的权利要求，如果既包含商业规则和方法的内容，又包含技术特征，则不应当依据我国专利法第二十五条排除其获得专利权的可能性。”通过上述修改，希望向社会公众进一步明确：利用计算机和/或网络技术实现的、涉及商业内容的发明专利申请，如果其权利要求含有技术特征，不认为其属于我国专利法第二十五条第一款第二项所述的“智力活动的规则和方法”而予以排除。

　　但是，排除适用专利法第二十五条并不意味着同时排除专利法第二条第二款的适用。专利法第二条第二款规定了发明是对产品、方法或者其改进所提出的新的技术方案，即发明应是一种技术方案。专利法第二条第二款和第二十五条从正反两个方面界定了专利保护的客体。对于涉及商业内容的专利申请，即使其不属于第二十五条第一款第二项排除的纯粹智力活动的规则和方法的范畴，如果不是采用技术手段解决技术问题，以获得符合自然规律的技术效果的方案，亦不属于可专利保护的客体。

　　（三）修改的影响

　　商业领域通常被认为是非技术领域，纵观各国相关法律规定和保护情况,可以发现，纯粹的商业方法均不被认为是专利保护的客体。

　　在当前“互联网+”发展模式下，互联网与经济社会各个领域深度融合，技术领域与非技术领域、技术性与非技术性特征的界限开始变得模糊，很多传统上认为涉及商业领域的专利申请已不宜从保护客体上直接排除其获得专利权的可能性，而应继续审查，判断其对现有技术的贡献是否足以获得专利保护的对价交换。

　　对于涉及商业方法的专利申请的审查标准的调整，需要将有关客体与“三性”的法律条款统筹考虑。此次修改并未具体涉及“创造性”审查内容，未来在《指南》修改工作中，还需要进一步深入研究和论证。

　　关于涉及计算机程序的发明专利申请审查的若干规定

　　（一）修改背景

　　1.《指南》的规定和解释

　　《指南》在第二部分第九章第5.2节对涉及计算机程序发明专利申请的权利要求书的撰写和解释做了具体规定，涉及计算机程序的发明专利申请的权利要求可以写成一种方法权利要求，也可以写成一种产品（装置）权利要求。同时，对于应如何撰写方法和装置权利要求进行了进一步说明：对于全部以计算机流程为依据的装置类权利要求，《指南》规定应按照与该计算机程序流程的各个步骤或者该方法权利要求中的各个步骤完全对应一致的方式撰写，即写成所谓的“功能模块构架”类权利要求，并且规定“由这样一组功能模块限定的装置权利要求应当理解为主要通过说明书记载的计算机程序实现该解决方案的功能模块构架，而不应当理解为主要通过硬件方式实现该解决方案的实体装置。”

　　因计算机程序发明涉及时序特征，之前往往被认为是方法发明。在1993版《指南》实施之前，涉及计算机程序的发明只能以方法权利要求的形式提出专利申请。但是，对于方法专利，一般只有使用专利方法才构成侵权，权利人无法追究计算机程序的复制者或销售者的侵权责任，而计算机程序的直接使用者往往是普通消费者，非商业目的的私人使用也不构成侵权。随着计算机技术的迅猛发展，方法权利要求在专利保护上的局限性日益凸显，诉讼对象的难于确定导致基于计算机程序的发明创造得不到有效的保护。

　　法律需要不断调整以适应经济技术发展的需要。在1993版《指南》中开始允许涉及计算机程序发明撰写成装置权利要求。在2006版《指南》中具体提出了上述“功能模块构架”的装置权利要求, 同时增加了对于涉及计算机程序的发明专利申请中包含有硬件结构改变的专利申请说明书的撰写要求。2010版《指南》对有关规定未作修订。

　　《指南》设定“功能模块构架”权利要求，一方面希望通过这类“装置”权利要求赋予计算机程序发明以产品的保护效力；另一方面，对这类权利要求的撰写形式做了严格的规定，希望使得审批者和社会公众能够轻易地识别出这类权利要求，并在此基础上适用《指南》中对此类装置权利要求的保护范围所做的、不同于一般权利要求的狭义解释。在既往的审查实践中，方法权利要求以及与之一一对应的装置权利要求是成对出现的。

　　2.引发的讨论和争议

　　时代在进步，技术在发展，这些年来，《指南》的有关规定在专利的申请、授权、确权和保护方面存在一些争议。

　　（1）“完全对应一致”含义不清，给撰写和审查造成一定困惑

　　由于《指南》规定的“功能模块构架”的装置，仅是在专利申请阶段为了满足撰写形式要求而“组装”的虚拟产品，在实际软件开发阶段并没有这样的概念。模块构架并非客观存在的物理实体装置或装置单元，且功能模块的拆分与合并比较随意，无客观划分标准，这必然给申请人撰写申请文件带来诸多不确定性。

　　在审查实践中，对于何为“完全一一对应”的理解也存在分歧。有观点认为装置权利要求中的各功能模块与方法权利要求中的各步骤必须在文字上绝对、严格地对应一致才能被认为是“完全一一对应”（严格符合《指南》示例），进而认为是功能模块构架的装置权利要求；也有观点认为不应如此机械理解，实质上“一一对应”即可。这些不一致理解给审查员检索现有技术、评判权利要求是否得到说明书支持等可能带来困惑。

　　（2）“功能模块构架”权利要求的保护范围的理解和解释不一致

　　自2006版《指南》设定“功能模块构架”权利要求的撰写方式以来，对此类权利要求的保护范围的理解一直存在争议，主要包括：a.“功能模块构架”装置权利要求具体指向的产品类型是什么，是软件，硬件，还是软件与硬件的结合？b.装置（产品）权利要求中包含计算机流程步骤特征时，步骤特征部分与装置之间有何关系？是否对权利要求的保护范围有限定作用？c.由于“功能模块构架”权利要求的表现形式上往往会出现“用于……的装置”或“被配置为……”这样的措辞，使得对其“功能模块构架”权利要求的表现形式易与一般功能性限定混淆，导致权利要求的保护范围更加难于确定。

　　（3）“功能模块构架”权利要求在司法保护方面存在争议

　　在司法实践中，可以看到上述“功能模块构架”权利要求范围的不同解释。从颇受关注的诺基亚公司诉上海华勤通讯技术有限公司侵害发明专利权纠纷案可以看到，上海中级和高级人民法院对于有关特征是按照一般功能性特征认定和解释的。

　　涉案权利要求7涉及：“如权利要求6所述的终端设备，其特征在于：所述终端设备被配置为……用于输入消息的消息编辑器……”

　　上海市第一中级人民法院和上海市高级人民法院均认为：由于涉案专利权利要求7包含功能性技术特征，且结合涉案专利说明书及附图仍然不能确定权利要求7的保护范围，不应判定被告构成侵权。可见，法院将“被配置为……”解释为限定装置的功能性特征，并结合涉案专利说明书及附图来寻找装置本身“被配置为”的具体实施方式和相对于对现有装置的技术贡献，以确定权利要求的范围。这与《指南》对功能模块构架权利要求的解释是不同的，《指南》规定功能模块构架的装置权利要求不应当理解为“主要通过硬件方式实现该解决方案的实体装置”。

　　（4）无法满足创新主体的保护需求

　　与其他国家相比，对于涉及计算机程序发明，我国现行《指南》允许的权利要求撰写方式，形式要求更加严格，且与其他国家常见的权利要求表征形式不尽相同，这使得我国申请人难于有效利用优先权制度，授权后的权利要求也可能因不符合产品的实际形态，导致侵权认定时出现困难。

　　（二）修改方案和说明

　　本次修改主要从以下几个方面进行：

　　1.将“功能模块”修改为“程序模块”

　　将《指南》第二部分第九章5.2节第二段中的所有“功能模块”修改为“程序模块”，目的是为了更好地反映技术本质，避免功能模块构架的方式与“功能性限定”相混淆。

　　2.明确装置权利要求的组成部分可以包括程序（软硬混合）

　　将《指南》第二部分第九章第5.2节第1段第3句中的“并详细描述该计算机程序的各项功能是由哪些组成部分完成以及如何完成这些功能”修改为“所述组成部分不仅可以包括硬件，还可以包括程序”。

　　在计算机领域，软件和硬件经常是两个协同工作的部分。通过修改，明确装置权利要求的组成部分可以包括程序流程特征，允许申请人直接描述其对软件的改进，而不将此程序流程特征理解为限定硬件装置的方法或功能。

　　3.明确“计算机程序本身”的含义，允许“介质+计算机程序流程”的权利要求表达方式

　　此次修改在《指南》第九章第2节第（1）项中的两处增加了“本身”两个字，进一步明确了“计算机程序本身”不同于“涉及计算机程序的发明”，实质上缩小了“计算机程序本身”的外延，允许“介质+计算机程序流程”的权利要求的表达方式。

　　对于何为“计算机程序本身”，在《指南》第九章引言部分有明确规定。该定义与《计算机软件保护条例》中对“计算机程序”的定义基本相同。

　　对于“全部以计算机程序流程为依据”的技术方案，可以写成： “一种计算机可读存储介质，其上存储有计算机程序（指令），其特征在于，该程序（指令）被处理器执行时实现以下步骤……”；或“一种计算机可读存储介质，其上存储有计算机程序（指令），其特征在于，该程序（指令）被处理器执行时实现权利要求x 所述方法的步骤”。

　　4.删除第3节的“案例9”

　　原案例9对现行审查实践已无指导意义，其更适合用“创造性”进行审查。

　　（三）修改的影响和相关思考

　　通过此次修改，允许申请人以回归发明的实际形态、更能体现此类发明的发明构思和实质性贡献的方式撰写申请文件，丰富了允许的权利要求的撰写类型，适应了我国经济社会发展现状的要求，加强了涉及计算机程序发明的专利保护力度。在修改过程中，引发了对以下问题的思考。

　　1.装置权利要求中的“程序流程特征”

　　本领域常见的包括程序流程特征的装置权利要求，往往是通用计算机设备执行具体程序流程步骤，其应当理解为“执行所述具体流程步骤的装置”，在这里，程序流程特征被认为是装置权利要求的组成部分，对权利要求的保护范围起到限定作用，程序流程特征的限定作用或其对现有技术的贡献并不取决于该程序流程特征对硬件装置的结构本身有无影响。

　　这是因为，涉及计算机程序的发明与一般产品发明实质是不同的。通常，当结构特征不足以充分定义产品权利要求时，允许借助制备方法或功能（用途）特征进行限定。此时，发明的实质仍然是产品本身，方法或功能（用途）限定只是借以限定权利要求的替代方式（替代结构特征），在确定产品权利要求的范围时，当然要看其对要求保护的产品产生什么影响。但对于涉及计算机程序的发明而言，软件和硬件是协同工作的两个部分，发明的实质可以完全是软件（流程步骤特征），流程步骤特征被认为是装置（产品）权利要求的组成部分，硬件只是执行程序流程的通用设备，要获得专利保护并不意味着必须对硬件装置作出什么改进。

　　虽然解释的逻辑不尽相同，其他国家对于包括计算机流程步骤特征权利要求的解释也是类似的。美国专利审查指南规定，当涉及计算机程序的发明通过功能来表述时（功能是通过计算机程序实现），通常将其理解为执行特定程序的产品（装置）。

　　欧洲审查指南规定，在数据处理/计算机程序领域，如果装置特征是“装置+功能”（means-plus-function）类型（“装置，用于……”），该特征将被理解为该装置专用于（adapted to）实施相关步骤/功能，而不能理解为一般意义上的该装置适合于（suitable for）实施相关步骤/功能。因此，相对于那些通用数据处理装置或执行不同流程步骤里的装置具有新颖性。

　　日本2002年修改的专利法在第二条第三款中明确：计算机程序属于产品发明。其审查指南进一步规定，程序、系统和可读介质权利要求等均属于产品权利要求，应当按照一般产品权利要求的解释原则进行理解。

　　因此，对于此类装置权利要求，无论理解为“实现特定功能的装置”或者“专用于”实现所述方法的装置，流程步骤的特征对于权利要求的保护范围均是起到限定作用的，在审查中也应基于同样的理解去进行检索现有技术和审查“三性”。

　　2.装置权利要求中的程序流程特征与功能性特征

　　对于功能模块构架的装置权利要求或者“软硬结合”的装置权利要求中的流程步骤特征，如前所述，不应理解为限定硬件装置的功能或方法，而与一般功能性限定混淆。当然，除非有特别的要求，在撰写方面，也应当尽量避免可能误引发功能性限定审查意见的标识语， 如“能够（用于）……”。

　　对于功能性特征，如果没有特别规定，一般是参照其字面含义的“最大合理解释”解释权利要求范围。

　　美国作为首个允许用功能（效果）表述技术特征的国家，其功能性权利要求的认定，审查与解释自成一套逻辑体系。法律层面，美国专利法第一百一十二条第六款明确规定，对功能性限定权利要求的解释不同于对一般的功能性特征的“最大合理范围”的理解，应解释为包括说明书公开相应的结构、材料和行为或其等同物；其次，只有当申请人申请专利时采用特别的标识语（装置/步骤+功能），审查员在审查时才适用专利法第一百一十二条第六款（而非一般意义上的第一百一十二条第一款）。在审查过程中，如果有疑问，申请人与审查员可以就其是否“意图”适用专利法第一百一十二条第六款（或第一百一十二条第一款），或者说适用权利要求功能性特征的特殊解释原则充分沟通，并达成一致认识；共识一旦达成，在专利侵权中根据实施例及其等同方式确定功能性限定权利要求的保护范围。

　　欧洲专利审查指南规定与我国类似，对权利要求的表征不限于结构性特征，功能性特征也是允许的（被认为是上位概括）。除另有规定外，功能性限定一般按照功能性特征的字面含义理解，审查中严格审查权利要求是否得到说明书支持。如果根据申请文件记载的内容，所述功能仅能以特定方式实现，而功能性限定使其涵盖了其他实现方式或者所有实现方式，审查员应提出权利要求不支持的质疑；在专利侵权中根据本领域技术人员（不需创造性能力）能够想到的实施方式加以解释。

　　如果对于装置权利要求中的程序流程特征是否属于功能性特征存在疑义，应当通过审查过程使得申请人的理解和审查员的理解达成一致，以免对后续程序造成不必要的困扰。

　　3.计算机程序产品的权利要求

　　一般而言，计算机程序产品权利要求有以下几种常见表现类型：

　　【A】 一种计算机程序，当其在计算机上运行时令计算机实现功能A，功能B，功能C，……（计算机程序权利要求）；

　　【B】 “一种存储有计算机程序的计算机可读存储介质，其中所述计算机程序使计算机执行步骤A，步骤B，步骤C，……”（计算机可读介质权利要求）；

　　【C】 “一种计算机程序产品，包括计算机程序指令，其中所述计算机程序指令使计算机实现功能A，功能B，功能C，……”（程序产品权利要求）；

　　【D】 “一种制造物，包括存储有计算机程序的计算机可读介质,所述程序被运行用于执行步骤A，步骤B，步骤C，……”（制造物权利要求，更常见于美国专利申请）；

　　【E】 “一种数据流，用于表示下列计算机程序产品，所述计算机程序产品包括：程序代码段1，用于……；程序代码段2，用于……”（信号权利要求）。

　　各国允许的撰写形式不尽相同，比如，美国审查实践中允许B、C、D类型权利要求；欧洲审查实践中允许A、B、C、E类型权利要求，不允许D类型权利要求；日本审查实践中允许A、B类型权利要求，但根据日本审查指南的规定，当主题名称是“一种程序”（A类型）时，应撰写成“一种使计算机执行xx功能的计算机程序”，理由是因计算机程序本身不能实现其功能，因此必须写入装置“计算机”。

　　此次《指南》修改，通过允许“介质+计算机程序流程”的撰写方式，已经能够对“程序产品”进行比较有效的保护。而对于“计算机程序产品”的主题名称的含义的理解，各方认识尚未达成共识，其可以理解为程序本身、记录程序的介质、运行此程序的电子设备等，由此可能导致权利要求保护范围不清楚。 （未完待续）（知识产权报　作者　周胡斌　张宪锋　戴磊）