請求項綁死 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 會幫忙把磚砌得又快又整齊，但它不見得知道哪一面牆根本不該砌上去。這一段，恰恰是最需要人來把關的地方。