作者：夏彬 专利代理人
一、概述
随着互联网技术的快速发展，计算机与网络结合的软件类专利申请越来越多。在计算机软件领域中，一个技术方案往往涉及到多个实施主体，通过多个实施主体之间的交互实现发明目的。例如，对于客服方法来说，往往涉及到为用户提供服务的客服方、为客服方提供数据支持的云端存储器方以及方法指向的用户方。
在权利要求的撰写中，对于方法类权利要求，如果直接按照交互流程来撰写方法的步骤，每个步骤的实施主体可能彼此不同，即形成了多边撰写。比如，一个客服方法，首先用户方向客服方发送服务请求，客服方根据用户方的请求至云端存储器中查询相关数据，云端存储器则在查询到相关数据后返回至客服方。
在这种情况下，最大的问题是，在侵权诉讼中，责任无法分清，难以确定侵权者。对于客服方法来说，如果将用户方、客服方和云端存储器均作为侵权者显然是不合适的，因为客服方法面对的是广泛的受众，不可能将使用该方法的用户作为侵权者，而云端存储器则是相对中立的第三方，甚至可能跟侵权诉讼的原告也存在一些合作，不适合于作为侵权诉讼的对象。
为此，笔者认为，采用权利要求的“单边撰写原则”可以较好的避免上述问题。所谓单边撰写原则，与多边撰写相对应，指的就是在撰写方法权利要求中，仅以方法交互中的一侧设备作为实施主体来撰写方法的各个步骤。具体地，例如对上述客服方法改写为：首先客服方接受到用户方发送的服务请求，客服方根据用户方的请求至云端存储器中查询相关数据，并接收云端存储器返回的查询数据。
采用单边撰写方法后，在判定侵权时，只需要将客服方作为侵权者，并且在采用全面覆盖原则进行专利侵权判定时，只需要针对客服方判断其是否实施了方法权利要求的所有步骤即可，对于侵权诉讼的原告来说，也大大降低了取证的难度。
二、撰写思路
下面以一个具体实例来进一步介绍计算机软件方法类权利要求的单边撰写思路。
技术方案简介：提供了一种规则引擎，在该规则引擎中，用户可以通过用户终端自由配置新的规则，规则引擎根据预设的规则，将用户终端对规则的配置数据进行编译，生成可执行的class文件，然后将class文件发布至需要执行该规则的目标对象，目标对象接收到该class文件后通过class加载器加载到内存。由此，目标对象可以直接通过读取内存执行class文件的方式来执行用户自由配置的规则。
1.技术方案分析
首先，需要对上述技术方案进行简单分析，得到该方案涉及到的实施主体：规则引擎、用户终端和目标对象。
本技术方案解决的技术问题是，通过规则引擎建立起用户终端和目标对象的桥梁，将用户终端配置的规则直接输出到目标对象，成为目标对象可以执行的文件。
2.方法流程梳理
然后，根据上述技术方案，将包括三个实施主体的技术方案梳理如下：
S100：规则引擎推送规则配置界面给用户终端；
S200：用户通过用户终端在推送配置界面中配置规则；
S300：规则引擎将用户终端的规则配置数据进行编译，生成可执行的class文件；
S400：规则引擎将class文件发布至需要执行该规则的目标对象；
S500：目标对象接收到该class文件后通过class加载器加载到内存；
S600：目标对象读取内存执行class文件。
3.核心实施主体提取
根据上述技术问题的分析，可以知道，该方案的主体是规则引擎，其起到了用户和目标对象之间的桥梁作用。通过规则引擎的沟通，实现了用户自由配置的规则可以快速加载到目标对象中。因此，选择规则引擎为核心实施主体，也就是本专利需要保护的对象。
在考虑核心实施主体时，也可以从侵权诉讼的角度来看。在侵权诉讼中，如果将用户终端作为侵权者显然是不合理的，用户作为使用方，实际上是解决相应技术问题的需求者，而不是解决者。而目标对象往往受众较大，一般指的是需要执行具体规则的服务器，其在接收到class文件后加载到内存，然后读取内存执行class文件的过程，实际上是本方案要实现的目的。对于专利保护者来说，其面对的目标对象可能与侵权者的目标对象存在重合，因此，不适合将目标对象也作为权利要求保护的实施主体。
在考虑核心实施主体时，也可以从专利申请者自身的业务来看。一般，申请该技术方案的专利申请者，往往是规则引擎的开发商，其与用户终端以及目标对象存在的都是合作关系，而非包含关系，因此为了更好地保护专利申请者的权益，将规则引擎作为核心实施主体。
4.提取核心实施主体执行的步骤
对于该方案，提取规则引擎执行的步骤如下：
S100：规则引擎推送规则配置界面给用户；
S300：规则引擎将用户对规则的配置进行编译，生成可执行的class文件；
S400：规则引擎将class文件发布至需要执行该规则的目标对象。
可以看出，提取后的步骤所形成的流程并不是十分完整，缺失了一些关键步骤，因此需要下一步的步骤填充。
5.转化非核心实施主体执行的步骤
转化的方法主要有如下三种：
（1）非核心实施主体与核心实施主体之间的交互步骤，将数据发送方作为主体转化为数据接收方作为主体
对于该方案来说，步骤S100后，规则引擎推送规则配置界面给用户后，执行的是步骤S200用户通过用户终端对规则引擎推送规则进行配置，步骤S200可以转化为以规则引擎执行的动作，在该步骤中，用户终端是发送配置数据方，而规则引擎是接收配置数据方。因此步骤S200转化为：规则引擎接收用户终端发送的规则配置数据；
（2）非核心实施主体自身执行的动作，从执行步骤转化为非核心实施主体的限定内容
步骤S500中，目标对象接收到该class文件后通过class加载器加载到内存。由于在该过程中，不再涉及到目标对象和规则引擎之间的交互，而是目标对象在接收到相应文件后，自身执行的动作。此时，无法再将步骤S500转化为核心实施主体执行的步骤。
在这种情况下，可以将步骤S500转化为目标对象的限定内容，例如在步骤S400规则引擎将class文件发布至需要执行该规则的目标对象之后，增加对于目标对象的限定“该目标对象被配置为接收到class文件后将所述可执行文件加载到内存”。经过此种转化后，目标对象是特定的需要满足一定条件“接收到class文件后可以将class文件加载到内存”的，其作为步骤S400的限定，也就是核心实施主体执行操作时选择目标对象的限定，而不再作为目标对象执行的步骤而存在。
（3）非必要步骤可以删除
对于该方案来说，核心技术方案是“规则的配置和发布”，步骤S600目标对象读取内存执行class文件中，目标对象执行的则是规则实施的步骤。规则实施属于规则发布之后必然会执行的动作，并且并不属于本发明的核心保护内容。因此，步骤S600可以删除。
6.整理转化后的单边撰写权利要求
根据上述提取和转化，可以整理得到转化后的单边撰写权利要求如下：
S100：规则引擎推送规则配置界面给用户；
S200：规则引擎接收用户终端发送的规则配置数据；
S300：规则引擎将用户的规则配置数据进行编译，生成可执行的class文件；
S400：规则引擎将class文件发布至需要执行该规则的目标对象，该目标对象被配置为接收到class文件后将所述可执行文件加载到内存。
可以看出，修改后的权利要求的技术方案可以解决上述根据用户对规则的配置编译生成规则执行文件并发布至目标对象的技术问题。同时，权利要求中各个步骤的执行主体均为规则引擎。在侵权诉讼中，可以将落入授权专利的保护范围之内的规则引擎的提供商作为侵权者，并且在取证过程中只需要调取规则引擎执行的方法步骤，也降低了取证难度，避免了上面所说的多边撰写存在的问题。