软硬件合案：方法权利要求写“算法”，装置权利要求写什么才不浪费一次申请
作者：成都余行专利代理事务所 算法专利团队
人形机器人的算法申请，绝大多数是“软硬件合案”：同一个技术方案，既想保护算法流程，又想保护承载算法的装置，还想覆盖存储介质。理想情况下，一件申请三层保护，覆盖方法实施者、设备制造者和软件分发者。
现实情况是，大量合案申请里，方法权利要求写得有模有样，装置权利要求却退化成了模板句——“一种机器人控制装置，包括处理器和存储器，所述处理器执行所述存储器中的程序时实现权利要求1所述的方法。”存储介质权利要求更省事：“一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述程序被处理器执行时实现权利要求1所述的方法。”
这两句本身没有错，但如果整件申请的装置和介质权利要求只有这两句，这次合案就浪费了。这篇文章讲清楚：方法权利要求写算法时，装置权利要求到底该写什么，才能让三层保护真正各司其职。
一、先理解三层权利要求各自打谁
合案申请的三层结构，对应三类不同的侵权主体和行为：
| 权利要求类型 | 保护对象 | 主要针对的侵权主体 | 侵权行为 |
|---|---|---|---|
| 方法权利要求 | 算法执行流程 | 算法使用者、系统集成商、终端用户 | 使用该方法 |
| 装置权利要求 | 承载算法的物理实体或功能实体 | 机器人整机制造商、控制器厂商、模组供应商 | 制造、销售、许诺销售该装置 |
| 存储介质权利要求 | 承载程序代码的介质 | 软件分发者、固件提供方、云端服务商 | 制造、销售、传播该介质 |
三层保护的价值在于覆盖不同环节的侵权主体。如果装置权利要求只是“处理器+存储器+实现方法”，那它和方法权利要求在保护范围上几乎重合，制造者只要不“使用”方法、只卖设备，就可能绕开方法权利要求的直接侵权认定。装置权利要求写好了，才能把制造和销售环节圈进来。
二、装置权利要求的三种写法，从弱到强
以一件人形机器人力控装配算法为例。方法权利要求大致是：获取六维力/力矩信号→估计接触状态→计算阻抗控制参数→输出关节力矩指令。
写法A（最弱）：模板化装置权利要求
一种机器人力控装配装置，包括处理器和存储器，所述处理器执行所述存储器中存储的计算机程序时实现权利要求1所述的方法。
问题： 这个装置权利要求没有任何独立的技术特征，它完全依附于方法权利要求。审查员在创造性审查时，会把它和方法权利要求视为同一技术方案；在侵权比对时，制造者可以主张“我只是卖硬件，没有执行方法”。这种写法等于只申请了方法专利，装置部分没有独立价值。
写法B（中等）：功能模块化装置权利要求
一种机器人力控装配装置，包括：力觉采集模块，用于获取六维力/力矩信号；接触状态估计模块，用于根据所述力/力矩信号估计接触状态；参数计算模块，用于根据接触状态计算阻抗控制参数；力矩输出模块，用于将所述阻抗控制参数转换为关节力矩指令并输出至关节驱动器。
改进： 装置有了自己的结构——功能模块。它不再是一句“处理器实现方法”，而是把方法步骤映射为装置模块。这种写法比A强，但仍然有一个隐患：纯功能模块化撰写容易被质疑为“功能性限定”缺乏具体结构支撑，尤其是在装置权利要求中，如果模块只写“用于……的模块”，审查员可能要求说明书提供更多硬件实现细节，否则支持性存疑。
写法C（较强）：功能模块+硬件落点
一种机器人力控装配装置，包括：六维力/力矩传感器，安装于机器人腕部，用于采集接触力/力矩信号；接触状态估计单元，与所述传感器信号连接，用于根据力/力矩信号估计接触状态；阻抗参数计算单元，用于根据接触状态计算阻抗控制参数；关节力矩输出单元，与关节驱动器信号连接，用于将阻抗控制参数转换为关节力矩指令；其中所述接触状态估计单元和阻抗参数计算单元集成于机器人控制器中，所述关节力矩输出单元通过总线与各关节驱动器通信。
优势： 装置权利要求里出现了传感器安装位置、信号连接关系、单元集成位置、通信方式这些硬件落点。它不再只是方法的模块化复述，而是一个有物理结构的装置。制造者销售这样一台控制器或整机，就落入装置权利要求的保护范围，不需要证明它“使用了方法”。
三种写法的差距，就是“合案是否浪费”的差距。写法C不一定每件申请都能做到（取决于交底书是否提供了硬件信息），但它应该是撰写时努力的方向。
三、方法特征与装置特征的对应关系：一张映射表
装置权利要求不是把方法步骤换个词重写一遍，而是要回答：方法里的每一步，在装置里由什么实体执行、输入从哪来、输出到哪去。
| 方法步骤 | 装置特征 | 需要写清的落点 |
|---|---|---|
| 获取六维力/力矩信号 | 六维力/力矩传感器 | 安装位置、量程、采样频率、信号接口 |
| 估计接触状态 | 接触状态估计单元 | 集成于哪个控制器、输入信号来源、输出形式 |
| 计算阻抗控制参数 | 阻抗参数计算单元 | 与估计单元的连接关系、参数存储位置 |
| 输出关节力矩指令 | 关节力矩输出单元 | 总线类型、通信周期、与驱动器的连接 |
| （方法中没有的） | 安全限幅单元 | 力矩上限、碰撞检测、急停回路 |
最后一行值得注意：装置权利要求可以包含方法权利要求中没有的硬件特征，比如安全限幅、急停回路、冗余传感器。这些特征不是方法的一部分，但它们是装置的实际组成部分，写进去可以增强装置权利要求的独立性和稳定性。
反过来，方法权利要求中的某些步骤，在装置中可能由同一个硬件单元完成，这时装置权利要求不必机械地一步一模块，而应按物理实体和信号流向组织。
四、存储介质权利要求：不是凑数，是覆盖软件分发环节
存储介质权利要求常被当成“合案标配”，写一句模板句了事。但它的实际作用很具体：当算法以软件包、固件更新、云端下发的方式传播时，方法权利要求难以直接抓到分发者，存储介质权利要求可以。
写好存储介质权利要求，注意三点：
第一，程序与方法的对应关系要明确。 “程序被处理器执行时实现权利要求1所述的方法”是基本写法，但如果方法权利要求有多项，要写清楚实现的是哪一项或哪几项，避免范围不清。
第二，可以增加程序的结构性描述。 比如“所述程序包括接触状态估计代码段、阻抗参数计算代码段和力矩指令生成代码段”，让存储介质权利要求不只是方法的附庸，而有自身的程序结构特征。
第三，介质类型可以适当具体化。 只写“计算机可读存储介质”范围较宽，但如果交底书里有具体的部署形态（控制器固件、边缘计算盒、云端镜像），可以在从属权利要求中进一步限定，形成层次。
五、合案撰写中最常见的四个错误
错误一：装置权利要求写成方法的“翻译版”。 方法写“获取”，装置写“获取模块”；方法写“计算”，装置写“计算模块”。一步一模块，没有任何硬件落点和信号连接关系。这种装置权利要求在侵权诉讼中很难独立主张。
错误二：方法权利要求和装置权利要求的范围不匹配。 方法权利要求限定了“摩擦系数取实测值”，装置权利要求却只写“参数计算模块”，没有对应的摩擦系数输入或存储特征。结果是装置权利要求范围宽于方法，但缺乏支撑，审查时容易被要求限缩。
错误三：存储介质权利要求与方法脱节。 方法权利要求有10项，存储介质只写“实现权利要求1所述方法”，从属权利要求的附加特征全部丢失。如果独立权利要求被无效，存储介质权利要求没有退路。
错误四：说明书只按方法流程写，没有装置视角的描述。 这是根源性问题。如果交底书只给了算法流程图，没有传感器安装、控制器集成、总线通信、执行器接口的信息，撰写者想写写法C也写不出来。装置权利要求的上限，在交底书阶段就决定了。
六、交底书阶段就要问的五个问题
为了让合案不浪费，在收交底书时就要把装置侧的信息问出来：
- 算法运行在哪个硬件上？机器人控制器、边缘计算盒、云端，还是分散在多处？
- 输入信号从哪些传感器来？安装在哪里？通过什么接口/总线传入？
- 算法输出到什么执行器？经过哪些中间环节（驱动器、安全模块、通信总线）？
- 算法模块之间是同一处理器内的软件模块，还是分布在不同硬件上的独立单元？
- 有没有方法流程之外的硬件特征——安全限幅、急停、冗余传感、状态监测——值得写进装置权利要求？
这五个问题的答案，决定了装置权利要求能写到写法B还是写法C。如果交底书里一个都答不上来，合案申请大概率只能停在写法A。
七、一个判断合案是否“浪费”的自检
提交前，用五个问题过一遍：
- 装置权利要求删掉“实现权利要求1所述方法”这句话后，是否还有独立的技术特征？
- 装置权利要求里有没有至少一个硬件落点（传感器、控制器、总线、执行器接口）？
- 方法特征与装置特征之间，能否画出一张信号流向映射表？
- 存储介质权利要求是否覆盖了从属权利要求的附加特征，而不只是独立权利要求？
- 说明书里有没有装置视角的描述，足以支撑装置权利要求的硬件落点？
五个问题里如果有三个答“否”，这次合案很可能只保护了方法，装置和介质两层没有发挥应有作用。
回到标题
方法权利要求写算法，装置权利要求写什么？一句话回答：写方法步骤在物理世界里的落点——谁执行、输入从哪来、输出到哪去、模块之间怎么连。
合案申请的价值不在于“一份申请写了三种权利要求”，而在于三层权利要求各自圈住不同的侵权主体和行为。方法圈使用，装置圈制造和销售，介质圈软件分发。三层各司其职，一次申请才不算浪费。
延伸工具：《软硬件合案申请自检表》——按方法—装置映射、硬件落点、存储介质层次、说明书支撑四个维度逐项自查，附装置权利要求写法A/B/C对照示例。可在网站工具页获取。
本文展示合案申请的撰写方法与结构思路，不构成对授权结果的承诺。具体案件需结合完整权利要求、说明书公开内容和审查意见判断。
