软件专利撰写和理解的核心

  1.序

  虽然我们阐述了软件撰写的核心要素，但是，从整体的逻辑上来看，仍需要加深理解和认知。

  2.技术性

  2.1 为什么技术性是核心技术性是所有案子的核心，所以，我们聊的都是技术方案、技术特征等内容。在聊技术特征的时候，我们更多的是聊整体性，比如技术问题、技术方案、技术效果。基于此，软件类案子也是聚焦在此。另一方面，从知识产权的分类来看，专利保护的就是技术，商标保护的是品牌，版权保护的是作品（代码等），商业秘密保护的是不对外的技术。所以，专利的本质也就是技术。所以，从技术上来理解软件专利是底层逻辑，后面我们逐步展开。

   2.2 软件类案子为什么更要谈技术性比如，我们谈商业规则方法，或者算法特征的时候，也是从技术性的角度去理解的，比如，近的修指南，也是区分了技术特征和非技术特征，并把技术特征和非技术特征之间的关联性作为客体、三性审查的核心。所以，相比较机械、化学、电学等类的案子的技术性比较强，或者技术性显而易见之外，软件类案子更需要理解，或者深度重视技术性。比如，你要理解算法类案子、商业规则方法类案子，肯定是跑不掉的。

   2.3 软件类案子与软著的不同软件类案子之所以能够成为专利，还是内容和形式的问题，也就是说：专利保护的是内容，软著保护的是形式。所谓的专利保护的内容，也就是保护的技术性的内容，保护的是技术方案。结合来说，技术方案之外，具有N个不同的软著形式。比如，滑动解锁的技术（专利）在苹果哪里，但是，实现滑动解锁的功能的代码（软著）却是每家不同。

  2.4 软件类案子更多的来自于应用软件类案子的技术性相对来说，在于软件技术在各个领域的运用，其生命力也在于此。所以，软件类案子的技术性在于与其他领域的结合，比如，商业模式上的滴滴打车，机床的数据控制，医疗方案的AI诊断等等。这也是打开软件专利的核心逻辑。

  2.5 总结技术性是软件类案子的核心逻辑，后面所有的逻辑都可以从这个点展开，这也算打开软件类案子的一把核心钥匙。

  3.与要素的逻辑关系分析

  3.1 数据逻辑写软件的技术本质虽然是代码，但是，其代码是二进制语言，体现在日常的技术描述来说，就是数据的输入，输出和处理。比如，软件在于计算机，计算机的设置就是输入设备、输出设备和处理设备，比如，输入设备是键盘，摄像头等；输出设备是显示器等；处理设备就是CPU、内存，硬盘等。所以，软件的技术实质就是数据的获得、输入、输出和处理。所以，从技术性逻辑来看，就是数据的逻辑写。

  3.2 虚拟装置写从技术性上来看，软件并不是保护的核心，核心是软件赋能产品之后，使得产品有了更好的性能，所以，软件技术必须落在产品上才有价值。但是，软件本身是方法，按照传统的产品和方法的二分法，软件方法依靠方法的侵权判断逻辑没有价值，所以，只能落在产品的保护上才可。基于此，聪明的专利从业人员，设计了虚拟装置，不论是一对一写的虚拟装置，还是修指南之后的处理器模式，本质都是使其从方法的保护价值，延展到产品的保护价值上。

3.3 机器端写软件在技术上或者产品上具有三个逻辑，底层的是二进制的代码，中间是技术性的数据逻辑，外部是用户端的使用方法，这里面，我们关注的是技术性的数据逻辑。现实中，大家容易从用户端的使用方法去撰写软件类案子，为了避免这个问题的出现，特意规定了机器端写，用机器的眼光去看数据逻辑，这才是技术性的本质。相比较而言，机器端写的另外一面就是用户端写，用户端写就是外部的用户端的使用方法。

3.4 一端写随着互联网技术的方法，软件技术不仅仅是单体的，计算机内部的处理逻辑，它往往需要数据的传递，传递到其他单体设备上，传递到服务器上，而这些传输又是看不见，摸不着的。进一步的，软件技术在产品的售卖上，往往又是不同的主体，这个时候，又要借用产品的保护逻辑，产品的逻辑又是单体设备的，所以，为了产品逻辑的保护，就必须落在一个设备上，这样才能检测侵权。所以，一端写就是软件技术性逻辑的必须体现方式。说到这里，你可以认为是软件方法用产品逻辑保护的必然需求。

3.5 场景化写软件技术的核心在于应用，应用的核心在于场景，不同的场景对应不同的应用。所以，从软件技术的本质来看，核心在于场景，这个不论是在于单个案子的撰写，还是整体方案的保护，还是数量的挖掘，都在于此。所以，理解场景化的内容，也要回到软件的技术性的本质上来。

3.6 可视化写如前所述，软件类案子的技术性上有两个逻辑：逻辑1：要用产品去保护方法，逻辑2：底层是代码，中间是技术，外是用户。从这两个逻辑来看，软件技术方案的保护，既要是中间的技术，有需要用户端的产品的保护逻辑，所以，从撰写的角度来说，用户端的可视化角度就容易检测侵权，就更容易保护软件技术。所以，可视化写的要素也可以从这个角度来理解。

  3.7 过程结果写这个主要是撰写的顺序，或者属于语文描述的逻辑，从技术性角度来看，关联度不高。如果硬要推，可以从一端写、数据逻辑写的角度去分析一下。这个当给大家留个作业吧。4.说明书的撰写

  4.1 发明名称的撰写除了传统的发明名称的撰写之外，基于软件的技术性，我们建议更好的带上应用场景，这个可以是技术领域上的，也可以是使用的领域。现在这个阶段，不建议采用诸如：一种信息处理方法和系统的专利名称。较好的是：技术领域上的：用于在网络之间转向终端设备的设备和方法。使用的领域上的：一种用于智能交通的路侧设备和方法。

  4.2 技术领域的撰写原则上，技术领域有两个写法，一个写技术上的分类，一个写应用上的分类，从软件的技术性角度来说，如果是，计算机自己的创新、通用性的创新，就写技术上的分类，如果是软件和具体领域的结合，核心是应用的场景，那么就要写应用上的分类。具体的范围大小，还是看创新度，看创新的边界。

  4.3 背景技术的撰写背景技术的撰写除了三段论的写法之外，从软件的技术性角度来看，核心需要注意的是：商业上的描述和技术上的描述的区分，这里面主要是一个度。从现有的撰写逻辑来看，背景技术写过多的商业上的描述是较大的问题，技术性的认知不够。但是，完全转变为技术上的描述也比较难，或者，软件的技术性就是软件+应用（商业逻辑），所以，这个度就要把握好。这个度，如同机器端写和用户端写的认知一样，关键在于把握好。

  4.4 发明内容的撰写技术问题，主要是技术上的问题，不能是商业上的问题，这一点十分重要。而且，问题的撰写不要写过笼统，比如，成本降低，效率提升等，要写的技术上的细。技术方案，这个按照我们的八要素来说去写权要，复制到位就可以了。技术效果，如同技术问题一样，不能写商业上的技术效果，要聚焦技术上的技术效果。从这个维度来说，特别注意的还是软件+应用上的逻辑，对于计算机的自身的改进这个技术上的问题还不太明显。  4.5 实施例实施例的技术性上的注意要点在于：要点1：场景铺垫，描述上软件上的应用逻辑，不然，软件的技术方案可能弄不清楚，方法的流程更是需要硬件的场景铺垫。这个场景铺垫，一方面需要计算机的逻辑，另一方面，还涉及一些特殊的改进的设备或者场景。要点2：用户端的描述。前面的所有描述都阐述注意技术性，技术性注意到位了，真正的商业上的改进，用户端的理解就有问题了。所以，实施例上要充分注意用户端的描述，要充分说清楚商业规则和方法的描述。要点3：多端的描述，技术性体现上一端写上，是为了保护，实施例的作用在于公开技术方案，所以，可以多端写，解决掉一端写的理解不足的问题。要点4：自定义术语的描述，软件的技术性体现在应用领域或者场景上，往往会有很多自造词，这个自造词是软件+场景的特殊内容，本领域技术人员不清楚，所以，务必要解释清楚。很多案子会有专门的自定义术语的阐述部分。要点5：可视化的描述。不是每个案子都能可视化撰写的，这就面临侵权检测难的问题。

  5.技术性的整体逻辑分析

  5.1 序在软件类案子中，特别是2019年12月31日的修指南的体例中，从25条，到2条2款，到创造性的审查逻辑中，技术性是一个主线，大家也可以从这里去体会软件的技术性逻辑。

  5.2 修指南的审查逻辑从审查指南的逻辑来看，审查员在审查软件类案子时，遵循如下步骤：

  一步：判断是否为智力活动的规则和方法(A25.1(2))如果权利要求涉及抽象的算法或者单纯的商业规则和方法，且不包含任何技术特征→不是客体。

第二步：判断是否属于技术方案(A2.2)整体考虑权利要求中记载的全部特征：如果对要解决的技术问题采用了利用自然规律的技术手段，并且由此获得符合自然规律的技术效果→是客体。

第三步：根据技术性判断是否满足新创性（A26.2（3））新颖性审查：整体考虑权利要求记载的全部特征。全部特征=技术特征+算法特征或商业规则和方法特征。创造性审查：将与技术特征功能上彼此相互支持、存在相互作用关系的算法特征或商业规则和方法特征与所述技术特征作为一个整体考虑。“功能上彼此相互支持、存在相互作用关系”是指算法特征或商业规则和方法特征与技术特征紧密结合，共同构成了解决某一技术问题的技术手段,并且能够获得相应的技术效果。

5.3 技术性分析从一步判断智力活动规则来看，技术性体现至少有一个技术特征即可。

从第二步判断技术方案来看，只要落实了技术问题、技术方案、技术效果即可。

从第三步判断新创性来看，从整体上，考虑技术特征和非技术特征构成的整体技术方案即可。所以，实质上来看，仍然是技术性作为主导。这又回到一开始，软件专利就是技术性。它也借此和代码的软著，用户的使用方法相区分。

作者 / 李鑫   编辑 /     池恩 免责声明：版权归原创所有仅供学习参考之用，禁止用于商业用途，部分文章推送时未能及时与原作者取得联系，若来源标错误侵犯到您的权益烦请告知我们将立即删除。