专利撰写 | 软件专利权利要求中,“确定”到底能不能随便用?

软件专利权利要求中，“确定”到底能不能随便用？

在中国软件类专利的撰写中，方法权利要求里经常会出现“确定”这一动作词，例如：

“确定目标对象”
“基于第一数据，确定第二数据”
“响应于用户操作，确定处理策略”

很多代理师喜欢使用“确定”，因为它看起来足够抽象，不像“计算”“匹配”“查询”“生成”那样容易把动作限定得过窄。但也有一些申请人或发明人不喜欢这个词，认为它太虚、太泛、看不出技术动作。

那么，“确定”到底能不能扩大保护范围？它会不会带来清楚性、支持性、授权稳定性和维权证明上的问题？

笔者建议：可以用，但不能空用。

01 “确定”能扩大保护范围吗？

“确定”不是扩大保护范围的万能词

从撰写角度看，“确定”确实是一个比较中性的上位动作词。

它可以覆盖多种软件处理方式，例如：

计算得到、查询得到、匹配得到、筛选得到、判断得到、模型输出得到。

因此，在不希望把权利要求限定到某一种具体算法或代码实现时，“确定”具有一定优势。

例如：

基于用户行为数据，确定目标推荐结果。

这个表述比“计算目标推荐结果”更宽，因为“确定”不必然限定为数学计算，也可以包括规则匹配、模型预测、排序筛选等方式。

但需要注意的是，宽泛不等于有效宽。

真正决定保护范围的，不是“确定”这个词本身，而是后面是否讲清楚：

确定什么；
依据什么确定；
如何确定；
确定后产生什么技术作用。

如果权利要求只是写“确定目标结果”，但没有限定数据来源、处理逻辑、技术约束或后续技术效果，那么这个“确定”很可能只是一个结果性表述，并不能带来稳定的保护范围。

02 风险：看起来很宽，实际上很虚

“确定”最大的风险：看起来宽，实际上虚

在中国专利审查中，软件类发明通常需要体现技术问题、技术手段和技术效果。

因此，单纯写：

确定用户意图；
确定风险等级；
确定最优路径；
确定推荐结果。

这些表述往往不够安全。

原因在于，它们更多是在描述“想要得到什么结果”，而不是描述“通过什么技术手段得到该结果”。

如果说明书也只是泛泛说明“系统根据数据确定结果”，没有公开具体输入、判断条件、数据结构、处理流程或示例规则，那么审查员可能会提出以下问题：

第一，权利要求不清楚。
“确定”到底是计算、判断、查询、匹配，还是人工设定？边界不明。

第二，说明书支持不足。
权利要求概括得很宽，但说明书只公开了一种很简单的实现方式，无法支持如此宽泛的“确定”。

第三，创造性贡献不突出。
如果区别特征只是“确定某结果”，而没有体现具体技术处理逻辑，容易被认为只是常规的数据处理或业务规则。

比“确定”更重要的是“确定的技术路径”

实务中，较好的写法不是简单写：

确定目标物理存储资源。

而是写成：

基于逻辑字段的字段类型、当前资源状态表以及预设负载条件，确定用于存储所述逻辑字段的目标物理存储资源。

后一种写法明显更稳。

因为它不仅写了“确定”的结果，还写出了：

**输入依据：**逻辑字段的字段类型；
**判断基础：**当前资源状态表；
**技术约束：**预设负载条件；
**输出结果：**目标物理存储资源。

这样，“确定”虽然仍然是上位动作词，但其内部已经嵌入了技术逻辑。审查、无效和侵权比对时，都更容易解释其技术含义。

对于软件方案，尤其是涉及数据库、AI模型、资源调度、数据映射、权限控制、推荐排序等场景时，建议不要让“确定”单独承担全部技术贡献，而应当把核心规则、参数关系或数据结构适度写入权利要求。

04 从授权、无效到维权：“确定”是一把双刃剑

授权、无效和维权中的不同影响

从授权角度看，“确定”有利于保持权利要求的上位概括，但前提是技术方案已经讲清楚。否则，容易被审查员质疑为抽象算法、业务规则或结果性限定。

从无效角度看，过于宽泛的“确定”容易被请求人攻击。常见攻击方式是：现有技术已经公开了“根据某数据得到某结果”的总体思路，本专利只是用“确定”概括了一下，并没有真正限定区别性的处理机制。

从维权角度看，“确定”具有双刃剑效果。

好处是，它可以覆盖不同代码实现方式，不容易被被诉方通过改变函数名称、计算方式或程序结构来规避。

但风险在于，侵权证明可能更困难。因为“确定”往往发生在后台系统内部，权利人需要通过接口返回、日志数据、测试结果、页面状态变化、数据库字段变化等方式证明被诉系统确实执行了该步骤。

所以，撰写时不仅要考虑授权，还要考虑将来能不能证明。

05 实务建议

实务建议：可以用“确定”，但要做到“三明一宽”

对于中国软件专利撰写，“确定”不是禁用词，也不是万能词。比较稳妥的策略是：

第一，对象明确。
不要只写“确定结果”，而要写清楚确定的是参数、状态、资源、路径、策略、权限，还是映射关系。

第二，依据明确。
尽量写出“基于什么确定”，例如数据类型、状态表、特征向量、阈值条件、映射关系、模型输出等。

第三，技术作用明确。
确定之后要做什么？是控制设备、分配资源、更新映射、触发流程，还是改变数据存储方式？这一点要尽量体现出来。

第四，表达适度宽。
独立权利要求中可以使用“确定”保持概括性；从属权利要求和说明书中再展开具体的计算方式、匹配方式、判断规则、模型结构或数据表结构。

结语

“确定”本身并不能自动扩大保护范围。

它真正的价值在于：在不牺牲技术逻辑的前提下，为软件方案保留合理的实现弹性。

好的软件权利要求，不是简单堆砌“确定”“获取”“生成”“发送”，而是通过这些上位动作词，把背后的数据流、判断逻辑和技术效果组织成一个清楚、稳定、可授权、可无效抗辩、也可维权证明的技术方案。