上篇文章，我们一起捋清了一个自动驾驶调度方案的技术逻辑，和大家一起提高了技术理解能力。

点击了解技术方案：《这个专利的技术方案，是真写清楚了还是包装得好？》

接下来，来考考你的独权撰写能力。

假设你要保护上面这个技术方案，下面这两版独权，哪个保护效果更好？

PS：即使不看技术方案，直接看两版独权，其实也能做出基本判断了。

两版独权

独权1

独权2

很多人可能会选独权1。

觉得：“独权1字数少、技术限定少，那么保护范围自然就更大。而独权2多了”特征数据”状态信息”这些限定，保护范围肯定不如独权1大。”

但选独权1，你可能犯了一个错：认为“字少=范围大”。

这个坑，很多人踩过。为什么是坑呢？下面借助两版独权具体分析一下。

一、独权1看似保护范围大，实则发明点保护不到位

独权1保护的是这样一个流程：发请求 – 收响应 – 定目标 – 建协议 – 出计划。

发现问题了吗？

如果脱掉应用场景的外衣，这套流程和现有的常规平台调度，几乎一模一样。

如果独权中是这种缺乏核心技术特征的“纯业务流程”，审查时极易被现有技术破坏新颖性或创造性。此外，后期OA答复时为了争辩新创性，只能不断补入技术特征，保护范围还是会被大幅限缩。

如果你看了上篇文章《这个专利的技术方案，是真写清楚了还是包装得好？》，就知道本案真正想保护的，是：

•基于特征数据进行匹配，而非简单按位置找目标；

•在行程中持续接收状态信息进行监测，而非建完关系就结束。

再来对比独权2。

•①获取第一车辆以及候选第二车辆的特征数据……所述特征数据包括用于表征对应车辆的至少部分运行能力、状态参数或偏好参数的数据

独权2把商业词汇“模型克隆”还原到车辆特征数据本身。这样一来，本案和普通调度平台的差别就出来了：它是在更底层的数据层面做匹配，而非简单收请求、看响应。独权2保护了本案区别于现有技术的关键技术点。

•②在行程计划的执行过程中，接收第一车辆和目标第二车辆的状态信息，所述状态信息用于监测所述领航-跟随关系的服务状态

独权2又把前端词汇“心跳显示”还原到“服务状态监测”。因为本案真正要保护的不是界面怎么显示，而是服务器在行程中持续接收状态信息并监测服务状态这一底层机制，发明点保护到位了。

二、独权1主体执行边界模糊

•独权1：在所述第一车辆与所述目标第二车辆之间建立服务协议，使得所述第一车辆将动态驾驶任务交接给所述目标第二车辆；

这句权要的主体边界是模糊的。

这是一条“由服务器执行”的方法权利要求。服务器可以做的是接收请求、处理数据、协调协议、下发信息，但它本身并不能直接完成“车辆已经把驾驶任务交接出去”这个物理层面的结果。

如果把实体交接结果直接写成服务器执行的动作，会导致执行主体和动作不匹配，后面不管是审查还是侵权比对，都容易出问题——取证和比对都会更麻烦。

再来看独权2：

•所述虚拟链接协议用于指示所述第一车辆……将动态驾驶任务交接给所述目标第二车辆……

注意这里不是直接说“服务器使车辆完成交接”，而是说协议用于指示这一交接。

这就把服务器的执行边界写清楚了：服务器负责协调、建立协议、下发协议内容；至于车端后续如何执行，是协议所指向的内容，而不是服务器亲自完成的动作。

三、什么真正的“保护范围大”？

看独权1就知道，不是申请专利时，写一个覆盖范围尽可能大的独权就行了。

还要考虑：

•最终是否真的能拿到保护范围大的授权？

•授权后是否经得起无效挑战？

如果你申请时写了一个保护范围大的独权，答复时为了争辩创造性不断上提特征，最终拿到的授权范围被大幅限缩；或者虽侥幸获得了保护范围大的授权，但很容易被竞争对手无效成功，那也没有意义。

具体怎么在追求保护范围的同时，兼顾授权和无效的问题？我们会在后续的系列文章中，结合真一个个案例拆解其中的门道。

而今天这个案子，已经给了我们一个非常明确的启示——追求保护范围时，一定要确保两点：

•一是核心发明点要写进独权；

•二是执行主体要清楚、明确。

独权2虽然字数更多，但它多出来的部分，正是保护本案最核心、能和现有技术拉开差距的技术特征。

同时，独权2又很克制，没有把“异常发生后如何重规划”等异常分支全塞进独权。只要竞争对手用了这套主干逻辑，即使实际运行过程中从来没触发异常分支，也已经可能落入保护范围。

这才是真正有意义的保护。

四、更多的话

如果这篇文章对你有一点启发，欢迎点赞、转发，让更多人一起加入讨论。

也欢迎在评论区留下你在独权撰写中的困惑或心得——说不定下一期就会拿你的问题做案例。