摘要：中国审查指南修改后，对于商业方法专利申请的审查有新的变化，要求新颖性和创造性审查从包含商业规则的权利要求的全部特征去考虑，同时后续司法实践中权利要求的保护范围解释也给予统一，从而在撰写中就需要考虑商业方法技术方案的特殊性问题。
2019年12月31日中国国家知识产权局发布、自2020年2月1日起实施的《专利审查指南》修改决定，规定对于商业方法类申请的审查应当针对要求保护的技术方案，即权利要求所限定的技术方案进行。在审查中，不应当简单割裂技术特征与算法特征或商业规则和方法特征等，而应将权利要求记载的所有内容作为一个整体，对其中涉及的技术手段、解决的技术问题和获得的技术效果进行分析。
对于商业方法类的专利申请，除包括技术特征，也会包含算法或商业规则和方法等智力活动的规则和方法特征，在撰写中如何结合技术特征和非技术特征，要考虑如何针对客体、新颖性、创造性及侵权场景的适应性撰写。同时，在新颖性问题的审查中，进一步强调了审查对象是权利要求记载的全部特征，而不单纯强调必要技术特征，同时也强调了审查创造性问题要考虑所述的商业规则和方法特征对技术方案所作出的贡献。针对一个实际案例：现有技术中，乘客打车是通过招手即停或者电话呼叫调度中心的方式进行。本申请提供一种方案，基于一个互联网平台实现乘客与所有车辆的共享乘车。在本申请中，核心是一种商业方法，将乘客需求发布，同时所有的车辆可接收发布的需求信息，通过一个平台将二者信息对接以促成交易，从而降低空载、提升运输能力、运输效率并且从中获取商业利益。在该申请的撰写实践时，笔者主要遵从以下的撰写原则，来设计权利要求架构和特征布局。构建权利要求，首先考虑创新特征，针对创新特征构建最少特征的技术方案。考虑最少特征的技术方案是否可以独立解决技术问题，从而设计独立权利要求；避免根据发明人的完整方案来构建独立权利要求，将较多的非必要特征纳入到独立权利要求中。构建权利要求，其次考虑创新特征的独立性和组合性，将不同的创新特征争取分别构建不同的独立权利要求，或者尽可能围绕每个不同的创新特征组合来构建不同的独立权利要求，考虑商业方法特征和技术特征的组合方式。考虑应用领域的扩展性问题，本技术方案考虑的是打车应用，但实际上，该方案可以应用到多种交通工具共享应用的处理，那么可以修改主题或者增加主题到交通工具的共享处理方法。考虑单边撰写的可能性，本方案虽然是多端结构，但是考虑到用户的多样性和各个终端的独立性，就需要构建不同独立权利要求限定特定的应用端，针对不同的实施主体来撰写。同时，在从属权利要求中考虑如果应用到不同的终端，在处理输入和输出时候的区别特征。总的来说，在每个方案中，都要注意实施主体的唯一性，以及整套方案的实施主体的唯一性。考虑显性撰写的可能性，显性撰写是指技术特征的描述能够以实施可见或者结果可见的方式来撰写方案。对于该技术方案，需要考虑在终端设备进行处理时候获取的对象，以及比较后提供的结果，而处理过程可以布置到从属权利通过“以用于”的方式来进行撰写。这样，可以明确看到侵权设备的直接出现的比较特征，便于后续维权使用。考虑虚拟系统的必要性，该方案明确的是一种方法，但是为了适用美国申请和日本申请的需要，布置虚拟系统和存储介质是必要的，但是国内申请的虚拟装置就不一定需要出现，实际上在处理流程上也不会出现，或者侵权设备上也不具备可以一一比对的特征模块。考虑客体问题，这个是尤其要关注的，虽然发明人提供的案件可能是规则或者处理流程，但是考虑到来源于工业应用，必然有其具体的应用环境。结合应用环境，并且将技术特征归结到具体自然技术结构或者自然技术特征，可以避免这个问题。尤其针对本方案，有明确的应用对象和处理对象，这在客体问题上将不会产生困扰。在过去对于商业方法的撰写中，为了避免客体问题，一般将部分技术特征写到权利要求中。进一步，为了保证权利要求的技术方案的新颖性和创造性，在具有非技术创新特征存在的前提下，还需要增加满足新颖性、创造性的必要技术特征，从而造成了方案中非必要特征过多，权利要求脱离原始商业方法的出发点和总体思路、局限于实现该商业方法的某个技术方案上而导致保护范围过小的问题。
无论是过去还是现在，单纯的商业模式，在大多数国家的审查实践中，是不能授予专利权的。那么，对应需要增加技术特征进去，首先要加入发布载体和处理载体，或者从方法角度加入信息发布步骤；其次，要增加中间信息的处理步骤，也就是筛选匹配的步骤，这两个步骤的存在将保证该技术方案不会遇到客体问题。
但是，目前的信息发布和筛选匹配的概括性的特征，即便能够满足新颖性的问题，但遇到创造性审查时往往难以克服，单纯这些技术特征往往难以规避常规技术和容易想到的两个审查思路。从而，需要进一步增加其他技术特征，把方案的贡献引导到不是这个商业模式带来的贡献，而是由于匹配度和精确度带来的明确技术贡献上。
此时，撰写出独立权利要求：
一种乘车匹配方法，其特征在于，包括：
第一用户发布乘车需求，第二用户发布可乘信息；
服务器获取所述乘车需求和所述可乘信息，根据乘车需求中的起点终点信息和可乘信息中的路线信息进行匹配，提供给第二用户选择；
第二用户选定对应的乘车需求后，服务器根据第二用户当前位置、第一用户起点信息和路况信息来规划接乘路线，发送第二用户信息到第一用户。
从过去的审查来讲，这个权利要求不存在客体问题，但是从创造性审查角度，主要的技术特征是匹配和筛选方法，而两个信息的路线匹配和筛选算法往往会被认为是常规技术，这样，方案的创造性就会出现问题。进一步，为了保证获权，将交通信息、天气信息的处理增加到技术方案中，在路线的规划上增加这种筛选的关联复杂度，提高筛选的精度和速度，以保证创造性不受影响。但是，这种撰写明显脱离了这个方案的原始商业构想，变成了一种双端需求的技术匹配方案。
但是，对于一个申请方案的考虑，从维权角度，还需要进一步确定方案中技术特征的可比对性和侵权判定的明显性，这就要求在这个权利要求的撰写过程中注意单边问题和显性问题。对于这个方案，将乘客、司机和服务器分别考虑为不同的端设备，从方法上都按照单一端设备的角度考虑撰写。以司机端设备为例，也就是第二用户角度，构建独立权利要求为：
一种乘车匹配方法，其特征在于，包括：
发布可乘信息；
接收乘车需求进行选择确认；
其中，所述乘车需求根据多个原始乘车需求中的起终点信息和所述可乘信息中的路线信息进行匹配获取。
对于该权利要求，保证基于单边撰写的侵权判定便利的可能性，但是还要解决新颖性和创造性的问题。那么，对于当前权利要求，假设现有技术是招手即停或者电话呼叫，那么从技术方案上考虑，也基于目前商业应用的领域，是可以确认新颖性和创造性的。而如果将现有技术扩展到匹配筛选算法是现有技术，那么技术方案的新颖性和创造性就会受到影响。
此时，按照修改后的审查指南来考虑新颖性和创造性，不仅要考虑技术特征，也要考虑非技术特征，还要考虑非技术特征对应的影响效果。对于此方案的非技术特征，包括乘车匹配应用、交通应用领域、信息发布和选择确认，这种模式带来的相应效果足够明显，无论是社会效益、综合技术效果，也是足够显著的。那么，即便是技术特征为常规技术，那么非技术特征也是没有披露的，技术特征和非技术特征结合起来，考虑这种结合后总的方案对应的效果，这个方案的新颖性和创造性就能够得到保证。
进一步，虽然目前获权的可能性存在，单边撰写的方式也已经考虑，但是在特征认定时候是否明显可见，在维权阶段是否容易取证，还要继续考虑特征显性问题。
特征明显可见，一种方式是特征所表达的就是所见的，例如结构类权利要求；另一种对于计算机类案件，要从用户可见的角度尝试去撰写，或者可以从用户操作的角度去撰写，而首先不在独立权利要求中撰写实现可见和实现操作所对应的技术特征。
对于计算机类案件，单纯从商业方法专利的非技术特征来看，尤其是商业方法一般是多主体、后台实现和不可见的，商业逻辑可能清晰，但是表达成权利要求，再混合后台实现的技术特征，就会导致权利要求的特征经常不能取证或者难以直接比对。所以，对于特征的考虑，就要在单边撰写的前提下，将不可见特征转化为可见特征。
对于此案，根据显性撰写的原则，进一步修改为：
一种乘车匹配方法，其特征在于，包括：
发布可乘信息；
选择确认接收的乘车需求；
其中，所述乘车需求基于多个原始乘车需求中的起终点信息和所述可乘信息中的路线信息获取。
其中，将匹配的技术特征去除，将通过第一用户和第二用户的操作所输入的信息引申为技术特征写入权利要求，而这两个信息来源是用户操作或者用户操作可见的；将接收动作隐性处理，变成来源限定；将选择确认的操作前置，明显突出这种用户操作或者用户可见的特征。这样，保证方案中技术特征的存在，也保证技术特征和非技术特征组合的方案的新颖性和创造性。
在后续的撰写中，为了保证保护范围的完整性，进一步撰写第一用户端的方法权利要求、服务器端（或者云端）的方法权利要求，以及对应的设备权利要求。由于目前对于多主体的判决有了新的变化，原来摒弃的多主体的权利要求还要保留，将第一用户、第二用户及服务器的总体交互方法和交互系统撰写一个独立权利要求。另外，为了其他国家的审查需求，或者未来审查动向变化，建议还要做一套纯商业方法的权利要求，完全将技术特征去除，仅体现商业方法的运行逻辑。
涉及商业方法案件，由于审查基础是包括非技术特征的总体方案，那么在非技术特征具有创新性的前提下，尽量避免技术特征过多，同时将技术特征转化为显性特征。并且，由于实现商业方法的对应的技术手段的多样性，在技术特征的确认上要尽量减少，以总体方案来考虑客体问题和新颖性创造性问题。
对于每一种方案，要考虑维权时候的特征比对便利，将单边撰写和显性撰写作为撰写的基本原则，将隐藏在显性特征之后的技术特征避免写入独立权利要求，注意将这类技术特征以多样化的实现方式撰写实施例，以在从属权利中进行概括撰写技术特征。在用可显现的特征来构建权利要求时，要综合考虑用户可见、用户可操作和用户应用环境的特征，尽可能将技术特征转化为显性特征的表达方式。
