软件和算法能不能申请专利？关键看机制有没有写进权利要求

我做了二十年专利，先做专利代理，后来也做专利诉讼。客户拿着软件来问我最多的一句话是「我这个代码能不能申请专利」。这个问题本身问偏了：专利保护的不是代码本身，而是代码背后的技术方案。真正要问的是，有没有技术方案，权利要求有没有把它写出来。

软件和算法专利，代理师最先看什么？

一件软件或算法案子到我手上，我先看一件事：相对于现有技术，算法究竟通过什么具体机制解决了技术问题，这个贡献有没有写进权利要求。

围绕这件事，我分三点去核：

第一，技术性。 它解决的是识别误差、通信延迟、内存占用、设备控制这类技术问题，还是仅仅改变了营销、收费、商业排序的规则？后者再巧妙也是商业改进，在权利要求里加上「服务器」「人工智能」几个字，性质并不会变。

第二，创造性。 区别在哪里？为什么不是同行顺手就能想到的常规处理？算法名称新、公式复杂，或者只是换了一个应用行业，都不足以证明创造性。

第三，公开充分。 输入输出、处理步骤、关键关系和必要的模型细节是否交代清楚，让同行能够实现，并且能够理解技术手段为什么会产生所述的效果。

软件权利要求看的是机制，不是数学。同一个公式，写在只有数学处理的权利要求里不能授权；写在交代了具体技术过程的权利要求里，就有机会成为可授权的技术方案。

中国专利法对软件和算法是什么口径？

从法条上讲，有三个基本点值得申请人心里有数：

• 专利法第二条第二款把发明定义为「对产品、方法或者其改进所提出的新的技术方案」。关键词是「技术方案」。
• 专利法第二十五条第一款第（二）项把「智力活动的规则和方法」排除在可授权客体之外。纯粹的数学计算方法、纯粹的商业规则都落在这里。
• 《专利审查指南》第二部分第九章（现行版本含 2026 年 1 月 1 日起施行的修改）专门规定了涉及计算机程序的发明专利申请的审查，后来又补充了涉及算法、商业方法等的审查规定。现行口径要求把技术特征和算法特征、商业规则特征作为一个整体考察，看它是否采用技术手段、解决技术问题、获得技术效果，而不能因为用了计算机就认定符合要求。

所以，同样是一段阈值计算，判断它能不能授权，不是看公式本身，而是看权利要求整体有没有构成一个技术方案。这也和我上面说的三点是一致的。

一个被写成「数学题」的权利要求，是怎么改过来的？

下面是我亲自经手的真实案子，也是我讲软件专利时最常举的例子。

客户开发了一套焊缝缺陷检测系统，核心是一种自适应阈值算法：根据数据的均值和波动程度计算阈值，超过阈值的点识别为异常。

最初另一家代理机构把权利要求写成了这样：

一种异常数据识别方法，获取数据集合，计算均值及标准差，根据均值与标准差确定阈值，将超过阈值的数据标记为异常。

这句话只描述了抽象的数学处理：数据是什么、要解决什么问题、靠什么起作用，一概没有。这不属于可以授予专利权的技术方案。

我接手以后，没有急着改字句，而是回头把原说明书从头梳理了一遍。梳理下来发现，研发真正解决的问题是：金属表面的反光变化，会让固定阈值产生误报；而系统是通过特定的图像区域选择和阈值更新机制来补偿这种变化的。

于是我把权利要求修改为：

采集焊缝图像，根据焊缝位置确定检测区域及对应的参考区域，排除参考区域中的饱和反光像素，利用剩余像素的均值和标准差计算局部阈值，再用该阈值识别对应检测区域中的缺陷。

修改前后，数学公式完全相同。变化在于保护对象：它已经明确成为一套具体的工业图像检测方案。这件专利最终获得授权。

焊缝这件案子能改过来，前提是原说明书里本来就写了反光问题和区域选择机制。修改不能超出原说明书和权利要求书记载的范围——真实的工程细节必须在提交前就写进去，事后补不进来。

研发团队写软件交底书，应该怎么写？

从焊缝这件案子和其他很多案子里，我给研发团队的建议都很实际：

先写技术问题，不要先写算法名字。 原来哪里出问题：误报、延迟、内存吃紧、控制不稳？在什么条件下出问题？把「技术问题」写清楚，后面的机制才有落脚点。

一步一步写清机制。 数据从哪里取、怎么筛选或分区、算什么、算出来的结果怎样驱动下一步。流程图、数据流图对代理师和审查员都很有帮助。

说明为什么有效。 审查员和以后的法官都需要看懂技术手段和技术效果之间的因果关系。「排除饱和反光像素，避免参考区域的统计量被强反光拉偏」是解释；「算法经过优化」不是。

只写真实做过的东西。 交底书是真实研发的记录，只能写团队实际实现、实际验证过的机制，不能为了让申请看起来更有分量去编造特征或数据。

把贡献落到独立权利要求里。 很常见的情况是：说明书讲了一个很完整的技术故事，权利要求却只剩下「获取—计算—比较」的通用流程。审稿的人应该逐句核对，真正的贡献有没有出现在权利要求里。

业务规则和技术方案的界线怎么把握？

有些创新实际上发生在业务层，比如排序规则、收费规则、优惠规则。按中国发明专利的口径，只有收费、优惠、排序或分配规则，加上「服务器」「AI」等词，仍然没有解决技术问题。一个简单的自查办法是：把权利要求里「服务器」「终端」「模型」这类词拿掉，看剩下的是不是只是一条商业规则。如果是，这件申请的根基就不稳；如果拿掉以后仍然能看到一个解决技术问题的具体机制，比如为了降低延迟而对数据结构或通信方式作出的相互配合的调整，那才值得往下写。

结构化思考能帮上什么忙？

很多软件发明，本质上是解决了一个技术矛盾：固定阈值简单，但会误报；阈值调得敏感，又容易被反光干扰。把问题表述成矛盾，更容易看清楚方案里哪一部分才是真正的贡献，也就知道权利要求必须写什么。基于 TRIZ 的工具可以帮研发团队在写交底书之前把这个矛盾理清楚；至于能不能授权、权利要求怎么写，仍然需要专业代理师在读过真实说明书之后作出判断。