权利要求绑死 Google API、括号一堆：一件疑似 AI 生成的专利

最近读到一份专利范围，读着读着就皱起眉头。修正后的权利要求不但把技术特征绑死在特定的 Google API 上，独立项里还塞了一大堆括号补充。看到这样的写法，心里浮现的第一个念头是：这大概是靠 AI 生成的稿子。

以下把那段独立项的样貌大致重现一下，让没接触过专利文字的人也能感受一下它的模样：

一种基于对话式界面之信息处理方法，由一配置有至少一处理器之服务器运行，包含：

(a) 接收用户通过实时通信软件（如 LINE、Messenger、Slack 等具 Webhook 回调功能之平台）发出之非结构化指令（自然语言文本、语音转文字或多媒体消息）；

(b) 发送至第一 AI 模型（如 Transformer 架构之 LLM）运行意图分析，输出含任务意图（搜索、摘要、集成）及至少一第一参数（关键字、时间范围、文件类型）之结构化指令（如 JSON）；

(c) 依任务意图，由路由逻辑模块自主判断并动态调用至少一云存储服务 API（如 Google Drive API）为内部信息源，及一互联网搜索引擎 API（如 Google Search API）为外部信息源，分别取得私有文件摘要信息（矢量语意摘要或关键内文片段）与公开搜索结果（网页标题、摘要片段或影音脚本）；

(d) 将两者数据清洗、格式化，集成为结构化综合性上下文（Context），并依模型上下文窗口限制优化排序；

(e) 发送综合性上下文及结构化指令至第二 AI 模型（可与第一模型相同或不同），进行综合、推论与重组，生成深度集成信息之最终产出（结构化报告、图文摘要或回应消息），并通过实时通信软件之消息推送 API 回传用户。

两个看了就不安的地方

第一个问题，是权利要求里把“调用 Google Drive API”“调用 Google Search API”这种绑定特定厂商产品的写法，直接放进了界定范围的技术特征。专利范围写成这样，等于把权利的边界缩到只涵盖用了那几个特定 API 的实作。哪天别人换了一套等效的云存储或搜索服务，甚至 Google 自己改了 API 名称与行为，这个范围还罩不罩得住，都要打上大大的问号。

第二个问题，是独立项里塞满了括号。括号本来是用来举例或补充的，但一个独立项里出现这么多层层叠叠的补充，读起来像是把脑中所有想得到的可能性一次全倒进去，却没有真正想清楚：到底哪些才是界定发明不可或缺的技术特征。

这其实是个时代现象

我想谈的，并不是去指认某一件个案，而是这种写法背后透露出的普遍现象。

当 AI 生成专利稿变得容易，“把字堆满、把例子举全”这件事几乎不费力气。于是我们愈来愈常看到，一份范围写得洋洋洒洒、逻辑表面通顺，细看之下却把权利绑死在特定产品、或是被过多的括号限缩得动弹不得。

外行看到权利要求写得又长又完整，容易觉得“保护很周全”；但真正的问题往往就藏在这种“看起来很完整”里。专利范围不是字愈多愈值钱，而是每一个写下去的技术特征，都会变成日后主张权利时绑在自己身上的绳子。

AI 会帮忙把砖砌得又快又整齐，但它不见得知道哪一面墙根本不该砌上去。这一段，恰恰是最需要人来把关的地方。