首页 > 技术云
专利撰写

专利撰写流程?如何撰写申请专利
由中国国家知识产权局于2019年12月31日发布,自2020年2月1日起实施的修订后的《专利审查指南》,规定对于商业方法类申请的审查应当针对要求保护的技术方案即权利要求所限定的技术方案进行;在审查中,不应当简单割裂技术特征与算法特征或商业规则和方法特征等,而应将权利要求记载的所有内容作为一个整体,对其中涉及的技术手段、解决的技术问题和获得的技术效果进行分析。

商业方法类的专利申请,除包括技术特征外,也会包含算法或商业规则和方法等智力活动的规则和方法特征。在此类专利申请中,为结合技术特征和非技术特征,要考虑如何针对客体、新颖性、创造性及侵权场景进行适应性撰写。修订后的《专利审查指南》在新颖性问题的审查中,进一步强调了审查对象是权利要求记载的全部特征,而非单纯强调必要技术特征,同时也强调了审查创造性问题要考虑申请所述的商业规则和方法特征对技术方案所作出的贡献。

撰写原则

引入一个实际案例:现有技术中,乘客打车是通过招手即停或者电话呼叫调度中心的方式进行。本申请提供一种方案,基于一个互联网平台实现乘客与所有车辆的共享乘车。在本申请中,核心是一种商业方法,将乘客需求发布,同时所有的车辆可接收发布的需求信息,通过一个平台将二者进行信息对接以促成交易,从而降低空载、提升运输能力、运输效率并且从中获取商业利益。

在该申请的撰写实践中,笔者主要遵从以下的撰写原则,来设计权利要求架构和特征布局:

构建权利要求。首先,考虑创新特征,针对创新特征构建最少特征的技术方案。考虑最少特征的技术方案是否可以独立解决技术问题,从而设计独立权利要求;避免根据发明人的完整方案来构建独立权利要求,将较多的非必要特征纳入到独立权利要求中。其次,考虑创新特征的独立性和组合性,将不同的创新特征争取分别构建为不同的独立权利要求,或者尽可能围绕每个不同的创新特征组合来构建不同的独立权利要求,考虑商业方法特征和技术特征的组合方式。

考虑应用领域的扩展性问题。本技术方案考虑的是打车应用,但实际上,该方案可以应用于多种交通工具共享的处理,故而可以采用修改主题或者增加主题到交通工具的共享处理方法。

考虑单边撰写的可能性。本方案虽然是多端结构,但是考虑到用户的多样性和各个终端的独立性,就需要构建不同独立权利要求限定特定的应用端、针对不同的实施主体来撰写。同时,在从属权利要求中要考虑应用到不同的终端时在处理输入和输出时候的区别特征。总的来说,在每个方案中,都要注意实施主体的唯一性,以及整套方案的实施主体的唯一性。

考虑显性撰写的可能性。显性撰写是指技术特征的描述能够以实施可见或者结果可见的方式来撰写方案。对于该技术方案,需要考虑在终端设备进行处理时候获取的对象,以及比较后提供的结果,而处理过程可以布置到从属权利,通过“以用于”的方式来进行撰写。这样,可以明确看到侵权设备的直接出现的比较特征,便于后续维权使用。

考虑虚拟系统的必要性。该方案明确的是一种方法,但是为了适用美国申请和日本申请的需要,布置虚拟系统和存储介质是必要的;但在国内申请中,虚拟装置不一定需要出现,在处理流程上也实际上不会出现,或者侵权设备上也不具备可以一一比对的特征模块。

考虑客体问题。这个是尤其要关注的,虽然发明人提供的案件可能是规则或者处理流程,但是考虑到来源于工业应用,必然有其具体的应用环境。结合应用环境,并且将技术特征归结到具体自然技术结构或者自然技术特征,可以避免这个问题。尤其针对本方案,其有明确的应用对象和处理对象,在客体问题上将不会产生困扰。

撰写示例

在过去对于商业方法的专利申请撰写中,为了避免客体问题,一般将部分技术特征写到权利要求中。进一步,为了保证权利要求的技术方案的新颖性和创造性,在具有非技术创新特征存在的前提下,还需要增加满足新颖性、创造性的必要技术特征,从而造成了方案中非必要特征过多,权利要求脱离原始商业方法的出发点和总体思路、局限于实现该商业方法的某个技术方案上而导致保护范围过小的问题。

无论是过去还是现在,单纯的商业模式,在大多数国家的审查实践中都是不能被授予专利权的。对此,撰写申请时就需要增加技术特征:首先,要加入发布载体和处理载体,或者从方法角度加入信息发布步骤;其次,要增加中间信息的处理步骤,也就是筛选匹配的步骤。这两个步骤的存在将保证技术方案不会遇到客体问题。

不过,目前的信息发布和筛选匹配的概括性特征,即便能够满足新颖性的问题,但也往往难以克服创造性问题。单纯增加前述的技术特征,往往难以规避常规技术和容易想到的两个审查思路,故而需要进一步增加其他技术特征,把方案的贡献引导到匹配度和精确度带来的明确的技术贡献而非商业模式带来的贡献上。

此时,撰写出独立权利要求:

一种乘车匹配方法,其特征在于,包括:

第一用户发布乘车需求,第二用户发布可乘信息;

服务器获取所述乘车需求和所述可乘信息,根据乘车需求中的起点终点信息和可乘信息中的路线信息进行匹配,提供给第二用户选择;

第二用户选定对应的乘车需求后,服务器根据第二用户当前位置、第一用户起点信息和路况信息来规划接乘路线,发送第二用户信息到第一用户。

从过去的审查来讲,这个权利要求不存在客体问题,但是从创造性审查角度,主要的技术特征是匹配和筛选方法,而两个信息的路线匹配和筛选算法往往会被认为是常规技术,这样,方案的创造性就会出现问题。因此,为了保证获权,可将交通信息、天气信息的处理增加到技术方案中,在路线的规划上增加这种筛选的关联复杂度,提高筛选的精度和速度,以保证创造性不受影响。但是,这种撰写明显脱离了这个方案的原始商业构想,变成了一种双端需求的技术匹配方案。

此外,从维权角度出发,对于一个申请方案的考虑,还需要进一步确定方案中技术特征的可比对性和侵权判定的明显性,这就要求在权利要求的撰写过程中注意单边问题和显性问题。对于本方案,可将乘客、司机和服务器分别考虑为不同的端设备,从方法上都按照单一端设备的角度考虑撰写。以司机端设备为例(也就是第二用户角度),构建独立权利要求为:

一种乘车匹配方法,其特征在于,包括:

发布可乘信息;

接收乘车需求进行选择确认;

其中,所述乘车需求根据多个原始乘车需求中的起终点信息和所述可乘信息中的路线信息进行匹配获取。

对于该权利要求,在保证其基于单边撰写的侵权判定便利的可能性的同时,还要解决新颖性和创造性的问题。假设现有技术是招手即停或者电话呼叫,那么,对于当前的权利要求,从技术方案上考虑,也基于目前其商业应用的领域,是可以确认其新颖性和创造性的。而如果将现有技术扩展到匹配筛选算法,则上述技术方案的新颖性和创造性就会受到影响。

此时,按照修改后的《专利审查指南》来考虑新颖性和创造性,就不仅要考虑技术特征,也要考虑非技术特征,还要考虑非技术特征对应的影响效果。本方案的非技术特征包括乘车匹配应用、交通应用领域、信息发布和选择确认,这种模式带来的社会效益、综合技术效果是足够显著的。因此,即便其技术特征为常规技术,其非技术特征也未披露,技术特征和非技术特征结合后总的方案对应效果,便能够保证本方案的新颖性和创造性。

进一步地看,虽然目前存在获权的可能性,也已经考虑了单边撰写的方式,但要明确特征认定时候是否明显可见、维权阶段是否容易取证,则还要继续考虑特征显性问题。

特征明显可见,一种方式是特征所表达的就是所见的,例如结构类权利要求;另一种对应于计算机类案件,要从用户可见的角度尝试去撰写,或者可以从用户操作的角度去撰写,而首先不在独立权利要求中撰写实现可见和实现操作所对应的技术特征。

对于计算机类案件,单纯从商业方法专利的非技术特征来看,尤其是商业方法一般是多主体、后台实现和不可见的情况下,商业逻辑即使是清晰的,但一旦表达成权利要求,再混合后台实现的技术特征,就会导致权利要求的特征经常不能取证或者难以直接比对。此时,就需要在单边撰写的前提下,将不可见特征转化为可见特征。

综上,对于本申请,根据显性撰写的原则,进一步修改为:

一种乘车匹配方法,其特征在于,包括:发布可乘信息;选择确认接收的乘车需求;

其中,所述乘车需求基于多个原始乘车需求中的起终点信息和所述可乘信息中的路线信息获取。

其中,将匹配的技术特征去除,将通过第一用户和第二用户的操作所输入的信息引申为技术特征写入权利要求,而这两个信息来源是用户操作或者用户操作可见的;将接收动作隐性处理,变成来源限定;将选择确认的操作前置,明显突出这种用户操作或者用户可见的特征。这样,保证方案中技术特征的存在,也保证技术特征和非技术特征组合的方案的新颖性和创造性。在后续的撰写中,为了保证保护范围的完整性,还需进一步撰写第一用户端的方法权利要求、服务器端(或者云端)的方法权利要求,以及对应的设备权利要求。由于目前对于多主体的判决有了新的变化,原来被摒弃的多主体的权利要求还要保留,将第一用户、第二用户及服务器的总体交互方法和交互系统撰写为一个独立权利要求。另外,为了应对其他国家的审查需求,或者未来审查动向变化,还需要做一套纯商业方法的权利要求,完全将技术特征去除,仅体现商业方法的运行逻辑。

总结

涉及商业方法的专利申请案件,由于其审查基础是包括非技术特征的总体方案,在非技术特征具有创新性的前提下,撰写申请时应尽量避免出现过多的技术特征,同时将技术特征转化为显性特征。并且,由于实现商业方法的对应技术手段的多样性,应尽量减少技术特征的确认,从总体方案的角度出发考量客体问题和新颖性、创造性问题。

对于每一种方案,要考虑维权时候的特征比对便利,将单边撰写和显性撰写作为撰写的基本原则,将隐藏在显性特征之后的技术特征避免写入独立权利要求,注意将这类技术特征以多样化的实现方式撰写实施例,以在从属权利中进行概括撰写技术特征。在用可显现的特征来构建权利要求时,要综合考虑用户可见、用户可操作和用户应用环境的特征,尽可能将技术特征转化为显性特征的表达方式。