软件能不能申请专利，不看它是不是纯软件，而看方案有没有落在技术层面。审查时用三条衡量：解决的是技术问题、采用的是技术手段、取得的是技术效果。三条同时满足，就属于可授权的客体；只满足一两条，容易被归入智力活动的规则和方法。
什么情况会被认为不是技术方案
典型的例子是「一种按规则计算费用的方法」「一种对文本进行分类的规则」。这类方案的处理对象是抽象数据，手段是人为规定的规则，结果也不涉及技术效果，属于专利法排除的客体。
反过来，如果同一个分类规则用在改进服务器的负载分配、降低了响应延迟，处理对象变成了设备内部运行状态，手段是数据处理与资源调度的配合，结果是可以测量的性能提升，这就落到了技术方案上。
三条标准的判断方式
- 技术问题：问题是不是关于设备、系统、数据的运行与性能，而不是关于商业规则或管理流程。
- 技术手段：方案里有没有计算机内部的处理过程、硬件资源的调度、数据结构的改进。单纯「用计算设备实现」不算技术手段。
- 技术效果：效果能不能在说明书里用技术指标描述，比如时延、吞吐、内存占用、识别准确率。
常见类型的落地写法
| 方案类型 | 可写的角度 | 不建议的角度 |
|---|---|---|
| 业务流程系统 | 数据采集、校验、存储结构 | 业务规则本身 |
| 算法改进 | 与具体应用场景结合的步骤 | 纯数学推导 |
| 交互界面 | 界面元素与设备响应的配合 | 单纯的视觉设计 |
| 数据处理 | 输入输出与数据结构的改进 | 数据内容的含义 |
撰写时按这个顺序整理
- 先把方案写成流程图，每一步都是对数据的处理动作，不是对业务的动作。
- 标出每一步的输入和输出，尤其是和硬件交互的地方：传感器读取、存储写入、网络发送。
- 写出至少一个可量化的技术效果，并说明是哪个步骤带来的。
- 检查权利要求里有没有出现纯商业用语，比如「订单」「结算规则」「审批流」，尽量替换成数据结构层面的描述。
软著和专利不是一回事
软件著作权保护的是代码表达，登记时不审查技术内容，拿证快；专利保护的是技术方案，要经过实质审查。两者可以同时做，但解决的不是同一个问题：别人重写一遍代码，著作权基本拦不住，专利才有用。
实际操作里更常见的组合是：核心算法走发明专利，界面和文档走软著，产品外观走外观设计。三者的材料准备完全不同，不要指望一份文档改改就用。
常见问题
纯软件没有硬件能申请专利吗
可以。只要方案处理的是技术问题、用的是技术手段，载体是不是硬件不影响客体判断。
APP 的功能怎么申请
从数据处理和交互响应的角度写，把用户操作转成设备侧的步骤，不要写成功能清单。
算法本身能申请吗
单独的算法属于智力活动规则。必须与具体技术领域结合，形成完整的技术方案才可能授权。
商业方法类方案有机会吗
有，但要能证明技术贡献。仅仅把线下流程搬到线上，很难被认可。
软著和专利哪个更有用
看目的。防抄袭代码用软著，防别人实现同样方案用专利，很多公司两样都做。
软件类方案在撰写时最容易写成功能清单，用 专利Pro 可以先把功能拆成设备侧的处理步骤，再检验每一步的输入输出是否完整，适合自查客体和技术方案的一致性。
具体审查标准以国家知识产权局现行专利审查指南为准。