一、先说一件被第25条直接干掉的案子
2021年春天接的一个活，客户是做电商推荐的小团队，CTO 抱着笔记本过来，说这套算法他们写了两年，想申个专利卡一下对手。我当时入行没多久，胆子大，权利要求第一稿是这么写的：一种基于协同过滤的商品推荐方法，其特征在于，包括：获取用户历史行为数据；计算用户间相似度；按相似度排序；向用户推送前N个商品。
审查意见通知书下来，就一句话：《专利法》第25条第1款第2项，智力活动的规则和方法，不授予专利权。新颖性都没查。
这一条得说清楚。《专利法》第25条列了六类不授予专利权的东西，软件撞的是第二项，智力活动的规则和方法。但《专利法》第2条第2款又规定，发明是指对产品、方法或者其改进所提出的新的技术方案，而技术方案是「对要解决的技术问题所采取的利用了自然规律的技术手段的集合」。这两句话摆一起，就是软件专利的全部战场——你交上去的那份东西里，得能被扒出利用自然规律的技术手段。
什么算利用自然规律？CPU 跑指令、内存读写、网络带宽占用、GPU 并行计算，这些是。用户想买什么、打几分、偏好哪个品类，这些不是。所以那个推荐案后来怎么救回来的：我们把权利要求整体挪到了服务器资源调度上，特征改成「根据用户行为特征预测访问峰值，动态调整所述服务器集群中容器实例的数量」。核心算法一行没动，但落脚点从「用户喜欢什么」换成了「服务器多开几个容器」。这案子后来授权了。
我不觉得这是耍花招。《专利审查指南》对算法特征与技术特征紧密结合的要求，本身就承认算法的技术价值，前提是它得落在具体技术环境里，而不是悬在半空。
二、中美欧三条路，宽窄差得不是一点
2014年6月19日，美国最高法院在 Alice Corp. v. CLS Bank International 里定了个两步法：先判断权利要求是不是指向抽象概念，如果是，再看有没有「明显多于」抽象概念的东西。判决一出，软件专利被 35 U.S.C. §101 驳回的比例肉眼可见地涨，做支付、做广告投放、做风控的申请成片死在这一关。一直到2016年 Enfish, LLC v. Microsoft Corp. 才撕开一道缝——联邦巡回法院认为，如果权利要求改进的是计算机本身的功能（那案子是自引用数据库表），就不属于抽象概念。
欧洲的路子更拧巴。EPO 用 COMVIK 方法：先把所有非技术特征从权利要求里剥掉，看剩下那点技术特征有没有产生技术贡献。问题在于，剥的过程基本靠审查员主观判断，同一件案子在不同审查部能出两种结论。
中国反而是口子最宽的。2019年12月31日国家知识产权局发布《专利审查指南》修改，2020年2月1日施行，第二部分第九章专门新增了涉及算法特征、商业规则和方法特征的审查规定：如果权利要求涉及算法特征，且算法处理的是具体技术领域的数据、算法执行受技术手段约束、或者算法本身解决了技术问题，整体上构成技术方案，就不该被第25条挡掉。
这个差别对写代码的人意味着什么？同一件推荐系统专利，在美国大概率被 §101 打回来，在国内改三稿有戏。所以产品主要市场在国内的团队，别照搬美国代理人给的模板——他们那套为了躲 Alice 把权利要求写得极窄的防御性写法，在国内等于白白浪费保护范围。
三、三种写法摆一起看，哪种能活
拿同一个功能「订单超时自动取消」当例子。
第一种，纯业务逻辑：一种订单处理方法，其特征在于，接收订单；判断订单是否超过预设时长未支付；若超过，则取消订单。这种直接死，标准的第25条。
第二种，加个计算机当遮羞布：一种基于计算机的订单处理方法，其特征在于，由计算机接收订单……也死。加一台通用计算机不产生技术贡献，美国那套两步法也是这么判的。
第三种，落到技术细节：一种订单超时处理方法，其特征在于，应用于服务器集群，包括：接收客户端提交的订单请求，将订单数据写入分布式数据库的第一分片；启动定时任务，所述定时任务基于时间轮算法在内存中维护超时队列；当所述时间轮指针扫过所述订单对应的槽位时，向消息队列投递取消指令；由消费线程从所述消息队列读取指令，执行库存回滚并释放所述第一分片上的锁。这个能活。时间轮、分片、消息队列、锁释放，全是具体技术手段。
差别不在「技术含量」高低，而在于权利要求里有没有能被指认为利用自然规律的硬件或系统行为。
还有几条是踩过坑才知道的。说明书里别只贴代码，要写清现有技术怎么做、卡在哪儿、你的方案把哪个指标从多少提到了多少。我经手的一个图像处理案子，说明书里有这么一句：本方案将单帧推理耗时从 47ms 降到 19ms。这句话后来在答复创造性的时候被审查员引用了，比一堆「显著提升」好用得多。另外，权利要求里别出现「优选」「例如」「可以」这种词，一出现就是范围不清楚的隐患，第26条第4款随时等着你。
四、官费和时间，别被报价单唬住
一个软件发明专利走完流程，官费大概是这样：申请费 900 元，公布印刷费 50 元，实质审查费 2500 元，加起来 3450 元。这三项如果符合《专利收费减缴办法》的条件（个人上年度月均收入低于 5000 元，或者企业上年度应纳税所得额低于 100 万元），单个申请人可减缴 85%，也就是实交 517.5 元；多个申请人共同申请可减缴 70%。年费是授权之后逐年交，第一到第三年每年 900 元，往后逐级递增，具体档位以当年公告的收费标准为准，这块政策改过好几轮，别信几年前的攻略。
时间上，发明专利从申请到授权，走普通程序大概两到三年；请求提前公开并同时提实审，能压到一年半左右。软件基本只能走发明专利，因为实用新型不保护方法，也不保护没有形状构造的东西——这一点经常有人问，答案是死的，别抱幻想。
代理费这块，市面上一个软件发明专利的撰写报价从三千到两三万都有，差在代理人懂不懂技术。我见过报价八千但把分布式事务写成「发送请求、接收响应」的，也见过报价两万五、说明书连数据流图都画好了的。预算有限的话，钱花在「让代理人读懂你的系统」这件事上最值：你自己先画一张架构图、写清数据从哪来到哪去、哪个环节是瓶颈，比事后改三稿便宜得多。
五、一个可能不太主流的看法
大部分人申请软件专利的顺序是反的。先做完产品，再找代理人把已经写好的功能描述一遍，能授权就授权，不能就算了。这么做出来的专利，保护范围基本贴着你的实现细节走，竞争对手换个消息队列、换个缓存策略就绕过去了。
我的看法是：软件专利真正值钱的部分，不是「我做了什么」，而是「我决定了什么是必须这么做的」。分布式系统里有些约束是逃不掉的——要么一致性要么可用性，要么延迟要么成本。把这些约束写进权利要求，比写功能有用得多。上面那个订单超时的例子，真正有价值的特征不是「取消订单」，是「在时间轮槽位触发时投递指令」这个时序约束，因为任何想做高吞吐超时的系统都绕不开类似结构。
当然这话有争议，也确实不是所有领域都适用。纯业务类软件，比如 CRM、报表工具，约束本来就不强，硬套反而写出一堆看起来技术、实际上没人会去侵权的权利要求。这种时候老实承认专利保护不了它，靠商标加商业秘密，可能更划算。承认有些东西不该申专利，比硬申一堆垃圾专利要有用。