# Litigation Risk Monitor > 涉诉专利风险监测与同族扩展分析技能。触发场景：用户提供目标申请人名单（1～N 个，中英文均可），希望自动检索这些申请人名下的涉诉专利，做 INPADOC 同族扩展，结合 Patsnap legal 模块与 web.search 公开诉讼信息双向交叉，输出同族基础分析（地域/技术点/法律状态/审查历史）、诉讼时间线（含涉案专利号）、涉诉案件深度分析（原被告/案号/进程/争议焦点/抗辩/结果）、核心发明人近 3 年延伸分析，并生成单一 HTML 报告 + 结构化 JSON/CSV 附件，给出地域风险、应诉预警、趋势预测三维结论。不适用于：单件专利新颖性/创造性分析（路由 novelty-check / non-obviousness-check）、纯 FTO 法律意见、无申请人名单的开放式情报、与"涉诉专利同族 + 诉讼案件 + 发明人趋势"无关的一般性问答。 - Skill: `patsnap/litigation-risk-monitor` (Agent Skill, multi-file: 7 files) - Install (CLI): `npx skillmds@latest add patsnap/litigation-risk-monitor` - Raw SKILL.md: https://api.skillmd.com/api/skills/patsnap/litigation-risk-monitor/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Web & Frontend - Author: patsnap (https://skillmd.com/u/patsnap) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/patsnap/litigation-risk-monitor --- # litigation-risk-monitor — 涉诉专利风险监测 v10（target-centric 报告模板） ## 触发条件 - 用户给出 **目标申请人名单**（1～N 个，中英文均可），并希望对其名下专利做 **涉诉风险监测 / 同族风险扩展 / 诉讼案件梳理 / 发明人趋势分析**。 - 关键词信号：涉诉专利、专利诉讼监测、同族风险、INPADOC 同族、原被告分析、应诉预警、发明人近 3 年布局。 ## 不适用 - 单件专利新颖性 / 创造性分析 → 路由 `novelty-check` / `non-obviousness-check`。 - 纯 FTO 法律意见、专利无效检索 → 走专门的 FTO / 无效流程。 - 无申请人名单的开放式技术情报、产品调研 → 走通用检索或其它技能。 ## 输入契约 | 字段 | 必填 | 说明 | |---|---|---| | `assignees` | ✅ | 目标申请人列表（=被监测主体 target），中英文均可 | | `inventor_lookback_years` | ❌ | 发明人近期检索回溯年限，默认 `3` | | `family_scope` | ❌ | 同族范围，默认 `inpadoc` | | `max_litigated_per_assignee` | ❌ | 每个申请人最多分析的涉诉专利数，默认 `30` | > **主体口径**：报告中第一个 `assignees` 元素视为"被监测主体（target）"，所有统计卡片、章节标题、NAV tab、战略建议措辞**必须以 target 为主语**；其它公司一律以"对手 / 原告 / 被告"等中性角色出现，**严禁**出现"<对手公司>涉诉专利"、"<对手公司>反诉专利"等以对手为维度的章节标题。 --- ## 执行流程（全自动，不中途确认） ### Step 1 — 涉诉专利初筛 #### 1a — Patsnap MCP + web.search 双路初筛 - 对每个 `assignee` 调用 `patent.search`：`search_strategy=["filter"]`，`filters.assignees=[assignee]`，在返回结果中按法律事件含 litigation/诉讼/lawsuit/infringement 字段做候选筛选。 - 同时用 `web.search` 查询 `"" patent litigation lawsuit 诉讼 专利` 做交叉确认。 - 合并两路结果，按 `pn` 去重，保存到内存变量 `litigated_patents[]`。 - 对每件 `litigated_patents[i]` 标注 `target_role ∈ {"defendant","plaintiff","co_party"}`： - target 在该案为被起诉方 → `defendant` - target 在该案为起诉/反诉/主张方 → `plaintiff` - 其它（共同申请人、第三人等）→ `co_party` #### 1b — 新闻专利号识别与补充 对 Step 1a 的全部 `web.search` 返回内容识别： - **ZL格式**（如 `ZL202110123456.7`）：提取纯数字作申请号检索 - **CN格式**（如 `CN211719631U`）：直接作公开号用 `patent.fetch` 获取 去重合并：已存在→来源升级为 `"patsnap+web_news"`；仅新闻→`source="web_news"` 加入列表。 ### Step 2 — 同族扩展 + 深度分析 #### 2a — 同族扩展 - 对每件涉诉专利调用 `patent.fetch(keys=[pn], key_type="pn", module=["basic","legal","family"], include_structured=true, include_images=true)` - 从返回结构中提取：同族成员列表（pn/authority/legal_status/application_date/grant_date）、第一张摘要图片URL、legal关键事件 - 同时提取 `patent_id`，用于生成超链接 - ⚠️ **patent_id 必须从 patent.fetch 返回结构中提取，严禁伪造或使用任何占位UUID** #### 2b — 摘要附图下载（⚠️ 必须完成） 使用 Python 脚本（调用 `scripts/orchestrator.py` 中的 `fetch_abstract_image_b64`）： 1. 对每件涉诉专利，传入 `pn` 和 Step 2a 获取的签名图片URL 2. 下载图片到 `@skill_workspace/outputs/images/_fig1.png`，同时返回 base64 字符串 3. 将 base64 字符串保存在内存变量，Step 8 写 HTML 时直接内嵌到 `src="data:image/png;base64,..."` 4. 失败时 base64 留空，HTML中显示 `
暂无摘要附图
` #### 2c — 权利要求对比 对 CN/US/EP 各取1件代表性同族专利，读取独立权利要求，比较保护范围/保护重点/技术覆盖差异。 保存内存变量：`claim_comparison[]` 含 pn/authority/protection_scope/protection_focus/tech_coverage_notes #### 2d — 地域布局分析 基于同族成员 `authority` 统计，分析主要布局国家、有效/审中/失效分布，识别潜在风险地域。 保存内存变量：`geo_analysis`（300字以上文字）、`geo_risk_by_authority[]`（含 authority/family_count/active_count/pending_count/risk_level/reason） #### 2e — 法律状态与审查历史 从 `patent.fetch` 的 `legal` 模块，提取每件涉诉专利及关键同族的关键审查节点。 保存内存变量：`legal_detail[]` 含 pn/authority/legal_status/grant_date/expiry_date/key_events[] ### Step 3 — 诉讼时间线构建 收集所有诉讼事件，每个事件包含：date/title/description/event_type/patents[](含pn+title+url)/amount/court/case_no/result/result_type。按日期升序排列，保存 `litigation_timeline[]`。 ### Step 4 — 涉诉案件深度梳理 提取：原告/被告/案号/法院/起诉日/当前进程/争议焦点/审理结果/关键节点。每条事实挂 `[S#]` 来源标记。保存 `cases[]`。 ### Step 5 — 核心发明人延伸分析 - 聚合同族 `inventors`，取 TOP-10，保存 `core_inventors[]` - 对每位发明人查近3年申请量（按年统计），保存 `yearly_stats[]`（year/count） - 归纳近3年主要技术布局点（3～8个方向），保存 `tech_focus_list[]`（tech/patent_count/representative_pn/representative_url） ### Step 6 — 三维结论合成 - **地域风险**：基于 `geo_risk_by_authority`，逐地域给出风险评级+建议，保存 `geo_litigation_risk[]` - **应诉预警**：不少于800字完整段落，覆盖争议点/被告策略/攻防博弈/态势研判/建议行动，保存 `litigation_alert_summary` - **趋势预测**：基于近3年申请内容，总结技术布局趋势（200字以上）+ 重点方向列表 + 短/中/长期预测，保存 `trend_forecast` --- ## Step 8 — HTML报告生成（⚠️ 核心步骤，严格遵守 v3 模板） ### ⚠️ 严禁调用 render_report.py 进行渲染 **绝对不要**： - 生成 JSON 数据文件然后调用 `render_report.py` 渲染 - 使用 Jinja2 模板 - 调用任何 Python 渲染脚本生成 HTML ### ✅ 正确做法：Agent 直接将收集到的真实数据写入 HTML 使用 `files.begin_write` → 多次 `files.append`（每次约4000字节）→ `files.finish_write` 写入： ``` @skill_workspace/outputs/_litigation_risk_report.html ``` **核心原则**：HTML 中的每一个数据点（专利号、标题、日期、分析文字、base64图片等）都必须是前面各步骤收集到的**真实数据**，直接硬编码进 HTML 字符串。不得出现任何占位符如 `【占位符】` 或 `{{ variable }}`。 --- ### 🎯 v3 主体口径规则（必须遵守） **target = 第一个 `assignees` 元素 = 被监测主体**。整份 HTML 报告的视角必须以 target 为主语： | 维度 | ❌ 旧版（以对手为维度，禁止） | ✅ v3（以 target 为主体，必须） | |---|---|---| | NAV tab | `宁德时代涉诉专利` `中创新航反诉专利` | `涉诉专利`（合并为一个 tab） | | 章节标题 | `⚔️ 宁德时代起诉专利（原告方·N件）` `🛡️ 中创新航反诉专利（被告方·N件）` | `⚖️ 涉诉专利（共 N 件）` | | 内部小标题 | 以"原告方/被告方"做章节级标题 | `一、作为被告的涉诉专利（N 件）` `二、作为原告主张的涉诉专利（N 件）` | | 统计卡片 | `<对手>起诉专利数` `反诉专利数` | `被诉专利数` `主张专利数` | | 战略建议措辞 | `反诉专利` | `主张专利` | **严禁**： - NAV、`

/

/

` 标题、`section-header` 中出现以对手公司名为主语的章节标题（如"<对手>起诉专利"、"<对手>诉讼专利"） - 统计卡片的 `stat-label` 出现"<对手>起诉专利数"等以对手为主语的口径 **允许**： - 在执行总结、案件背景叙事、诉讼时间线事件描述、深度分析正文中，可以客观提及对手作为原告/被告的事实——这是事实陈述，不是"以对手为维度的章节"。 ### HTML报告章节写法规范 报告使用以下固定 CSS 头部（直接复制写入 append sequence=1）： ```html 涉诉专利风险监测报告 — [target简称] ``` 尾部固定 JS（写入最后一个 append）： ```html
本报告由 Eureka 自动生成 | 基于智慧芽专利数据库及公开网络信息 | 生成时间：[真实时间]
``` ### v3 NAV 模板（target-centric，固定 7 个 tab） ```html ``` > ⚠️ NAV 中**不得**出现以对手公司名为主语的 tab（如"宁德时代涉诉专利"、"<对手>起诉专利"）。涉诉专利 tab 始终只有一个，主语始终是 target。 ### ⚠️ 专利超链接格式（严格执行） 所有专利公开号超链接必须使用以下格式： - **有 patentId 时**（从 `patent.fetch` 返回结果中提取，⚠️ 严禁伪造或使用任何占位UUID）： ``` https://analytics.zhihuiya.com/patent-view/abst'figures/?_type=query&source_type=search_result&rows=100&patentId=<真实patentId> ``` - **无 patentId 时**（降级，仅在 patent.fetch 确实未返回 patentId 时使用）： ``` https://analytics.zhihuiya.com/search?q=<公开号> ``` - **patentId 获取方式**：调用 `patent.fetch(keys=[pn], key_type="pn", include_structured=true)` 后，从返回的 `structured.basic` 或顶层字段中提取 `patentId` / `patent_id`。 - **验证**：写入 HTML 前，确认每个 patentId 均为 patent.fetch 实际返回值，格式为标准 UUID（含连字符，共36字符），例如 `d5044ca4-876a-4e5a-9968-977050522a51`。 ### 章节具体写法（每章直接写真实数据，无占位符） #### 第0章：执行总结（⚠️ 必须写在 h1 标题之后、stat-panel 之前） **要求**：三段式，总字数不少于500字，段落之间逻辑递进，全部基于本轮收集的真实数据。 - **第一段（案件背景与核心争议）**：介绍涉诉双方基本情况、诉讼缘起、涉及的核心专利技术领域、专利权属与核心争议的技术焦点，以及双方在市场上的竞争关系背景。字数不少于180字。 - **第二段（诉讼进展与关键转折）**：按时间顺序梳理主要诉讼节点，包括起诉时间、法院、索赔金额、一审/二审结果、专利无效宣告结果、反诉情况等重大转折事件。字数不少于180字。 - **第三段（风险研判与战略建议）**：基于同族布局、地域风险、技术趋势，给出综合风险评级（高/中/低），并提出3～5项具体可操作的战略建议（措辞以 target 为主语，例如"强化对 target 主张专利的权利稳定性维护"，**不要写成"反诉专利"**）。字数不少于140字。 ```html

📋 执行总结

[第一段：案件背景与核心争议，≥180字]

[第二段：诉讼进展与关键转折，≥180字]

[第三段：风险研判与战略建议，≥140字，措辞以 target 为主语]

``` #### 第1章：概览（统计面板 + 三级映射） **v3 统计卡片必须以 target 为主语**，标准 4 卡口径（数字根据真实数据填）： ```html

⚖️ 涉诉专利风险监测报告 — [target真实名称]

生成时间：[真实时间] | 数据来源：智慧芽 Patsnap + 公开网络信息
[N1]
[target]被诉专利数
[N2]
[target]主张专利数
[金额]
合计涉案金额（元）
[N3]
诉讼时间线节点数

1. 概览

1.1 [target] → 涉诉专利 → 同族号 映射

[target全称] [角色：被诉/主张/共同申请人]
🔴 [CN号]
[专利真实标题]
[同族公开号] [受理局] ●有效
``` > ⚠️ 禁用的旧 stat-label：`<对手>起诉专利数`、`反诉专利数`。一律改为 `被诉专利数`、`主张专利数`。 #### 第3章：诉讼时间线（⚠️ 每个节点必须包含涉案专利号） ```html

3. 诉讼时间线

⚖
[真实日期，如 2021-07]
[真实事件标题]
[真实事件描述，含法院名称、索赔金额等]
📋 涉案专利： [CN真实号][专利真实标题]
💰 [真实索赔额] 🏛️ [真实法院] [真实状态]
``` #### 第4章：[target] 涉诉专利详情（⚠️ v3：合并为单一 SECTION，以 target 为主体） **v3 必须采用以下结构**——一个 `section`，一个 `section-header`，内部用两个轻量 `

` 小标题分组（不要并列两个 section）： ```html
⚖️ [target]涉诉专利（共 [N总] 件）

下列专利按 [target] 在各诉讼案件中的角色分组列出，包含同族表、摘要附图、权利要求等结构化信息。

一、[target]作为被告的涉诉专利（[N1] 件）

[真实CN号] 🔴 高风险·被诉在审
[真实专利标题]
[真实摘要]
[CN号]摘要附图
权利人
[真实申请人]
申请日
[真实日期]
IPC
[真实IPC]
诉讼角色
[target] 被诉

📋 INPADOC 同族专利（[N]件）

公开号受理局申请日法律状态
[同族公开号][受理局][申请日]有效

二、[target]作为原告主张的涉诉专利（[N2] 件）

[真实CN号] 🟢 主张·原告方
[真实专利标题]
权利人
[真实申请人]
诉讼角色
[target] 主张（原告）
``` ⚠️ **严禁**写成两个并列的 section，例如： - ❌ `
⚔️ <对手>起诉专利（原告方·N件）
...
` + `
🛡️ 反诉专利（被告方·N件）
...
` - ✅ 一个 section，header 文案 = `[target]涉诉专利（共 N 件）`，内部用 `

` 小标题分组。 #### 第6章：核心发明人（⚠️ 包含真实统计图和技术点列表） ```html

6. 核心发明人延伸分析

👤 [发明人真实姓名]（近3年共 [真实N] 件）

近3年主要技术布局方向

  • [真实技术方向1]（[N]件，代表：[CN号] [专利标题]）
``` #### 第7章：三维结论 ```html

7. 三维结论

7.1 潜在涉诉地域分析

CN — 中国大陆 高风险
[真实分析文字：说明CN有效同族数量、主要专利技术特征、潜在诉讼风险点]
建议：[真实建议]
同族专利号专利标题申请日法律状态
[CN同族号][标题][申请日]有效

7.2 应诉预警综合总结

[真实分析段落1：案件主要争议点...]

[真实分析段落2：[target] 应诉策略...]

[真实分析段落3：攻防博弈重点...]

[真实分析段落4：当前态势研判...]

[真实分析段落5：建议行动项，措辞以 target 为主语...]

7.3 趋势预测

[200字以上技术布局趋势总结]
短期（6～12个月）
[真实内容]
中期（1～3年）
[真实内容]
长期（3年以上）
[真实内容]
``` #### 第8章：汇总列表 ```html

8. 涉诉专利汇总列表

涉诉专利专利标题[target]角色同族公开号受理局法律状态申请日
[CN号] [专利标题] [被诉/主张] [同族公开号] [受理局] 有效 [申请日]
``` --- ## 自检清单（写完 HTML 后必须逐项核对） 写完 HTML 后，使用 `files.grep` 对生成文件做以下正则检查，**任一项命中即必须修订**： | # | 正则 | 含义（命中即违规） | |---|---|---| | 1 | `<对手公司名>(起诉|涉诉|诉讼)专利` 出现在 `class="nav"` 或 `

/

/

/section-header` 内 | NAV/章节标题以对手为主语 | | 2 | `(反诉专利)` 出现在 `stat-label` 或 `exec-summary` 内 | v3 已统一为"主张专利" | | 3 | `<对手>起诉专利数` 出现在 `stat-label` 内 | 统计卡片以对手为主语 | | 4 | 出现 `【.*】` 或 `\{\{.*\}\}` | 残留占位符 | | 5 | `patentId=[^&"']*` 不是合法 UUID（36字符含连字符） | 伪造 patentId | 通过自检后再交付。 --- ## 计数语义守则 - `matched_total` 是查询范围内的命中总数，`returned_count` 是当页样本。 - 报告中展示分布图/表格时，必须写明"样本范围"与"查询过滤条件"。 ## 来源标注 - `[S#]` Patsnap patent.search / patent.fetch（注明 pn 与模块） - `[S#]` web.search / web_fetch（注明 URL 与命中片段） - 冲突时双源并列展示 ## 关键脚本 - `scripts/orchestrator.py`：图片下载/base64转换工具函数（`fetch_abstract_image_b64(pn, image_url)`） - `scripts/render_report.py`：**CSS/JS参考文件，不调用其渲染函数** - `scripts/config.py`：默认参数 ## 失败回退 - Patsnap legal 为空 → 标注 `[web_only]`，仅基于 web.search 证据 - 同族扩展失败 → HTML中显示"同族扩展失败" - 摘要附图失败 → `
暂无摘要附图
` - 应诉预警数据不足 → 尽力生成，标注"基于现有公开信息，部分内容待核实" ## 使用前配置 本 Skill 依赖智慧芽开放平台 MCP 服务： - 完成安装、初次使用时需进行自检，参见 README.md - 用户需完成账号授权，并确保 Agent 环境已启用对应 MCP 工具 - 若未完成配置，本 Skill 只能提供分析框架，无法检索实时数据或生成基于数据库的结论 - 缺少MCP配置时，引导用户参照 README.md 在 [[open.zhihuiya.com](https://open.zhihuiya.com/)](https://open.zhihuiya.com/) 获取MCP。