Coding

litigation-risk-monitor

涉诉专利风险监测与同族扩展分析技能。触发场景：用户提供目标申请人名单（1～N 个，中英文均可），希望自动检索这些申请人名下的涉诉专利，做 INPADOC 同族扩展，结合 Patsnap legal 模块与 web.search 公开诉讼信息双向交叉，输出同族基础分析（地域/技术点/法律状态/审查历史）、诉讼时间线（含涉案专利号）、涉诉案件深度分析（原被告/案号/进程/争议焦点/抗辩/结果）、核心发明人近 3 年延伸分析，并生成单一 HTML 报告 + 结构化 JSON/CSV 附件，给出地域风险、应诉预警、趋势预测三维结论。不适用于：单件专利新颖性/创造性分析（路由 novelty-check / non-obviousness-check）、纯 FTO 法律意见、无申请人名单的开放式情报、与"涉诉专利同族 + 诉讼案件 + 发明人趋势"无关的一般性问答。

What it does

The skill document

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）：

对每件涉诉专利，传入 pn 和 Step 2a 获取的签名图片URL
下载图片到 @skill_workspace/outputs/images/_fig1.png，同时返回 base64 字符串
将 base64 字符串保存在内存变量，Step 8 写 HTML 时直接内嵌到 src="data:image/png;base64,..."
失败时 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/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）：

<!DOCTYPE html>


涉诉专利风险监测报告 — [target简称]

尾部固定 JS（写入最后一个 append）：


本报告由 Eureka 自动生成 | 基于智慧芽专利数据库及公开网络信息 | 生成时间：[真实时间]

v3 NAV 模板（target-centric，固定 7 个 tab）


  
    风险概览
    [target]涉诉专利
    诉讼时间线
    深度分析
    核心发明人
    地域风险
    趋势预测

⚠️ 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字。

<!-- 执行总结：写在 h1 标题之后、stat-panel 之前 -->

  📋 执行总结
  [第一段：案件背景与核心争议，≥180字]
  [第二段：诉讼进展与关键转折，≥180字]
  [第三段：风险研判与战略建议，≥140字，措辞以 target 为主语]

第1章：概览（统计面板 + 三级映射）

v3 统计卡片必须以 target 为主语，标准 4 卡口径（数字根据真实数据填）：

⚖️ 涉诉专利风险监测报告 — [target真实名称]
生成时间：[真实时间] | 数据来源：智慧芽 PatSnap + 公开网络信息

<!-- 执行总结放在此处（见第0章规范） -->

<!-- v3 统计面板：4 卡，全部以 target 为主语 -->

  
    [N1]
    [target]被诉专利数
  
  
    [N2]
    [target]主张专利数
  
  
    [金额]
    合计涉案金额（元）
  
  
    [N3]
    诉讼时间线节点数
  


1. 概览
1.1 [target] → 涉诉专利 → 同族号 映射


  [target全称] [角色：被诉/主张/共同申请人]
  
    🔴 [CN号]
    [专利真实标题]
    
      [同族公开号] [受理局] ●有效

⚠️ 禁用的旧 stat-label：<对手>起诉专利数、反诉专利数。一律改为 被诉专利数、主张专利数。

第3章：诉讼时间线（⚠️ 每个节点必须包含涉案专利号）

3. 诉讼时间线

  
    ⚖
    
      [真实日期，如 2021-07]
      [真实事件标题]
      [真实事件描述，含法院名称、索赔金额等]
      
        📋 涉案专利：
        [CN真实号][专利真实标题]
      
      
        💰 [真实索赔额]
        🏛️ [真实法院]
        [真实状态]

第4章：[target] 涉诉专利详情（⚠️ v3：合并为单一 SECTION，以 target 为主体）

v3 必须采用以下结构——一个 section，一个 section-header，内部用两个轻量 `` 小标题分组（不要并列两个 section）：


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

    一、[target]作为被告的涉诉专利（[N1] 件）
    
      <!-- patent-card：header 用 .defendant 配色 -->
      
        
          [真实CN号]
          🔴 高风险·被诉在审
        
        
          [真实专利标题]
          [真实摘要]
          
          
            权利人[真实申请人]
            申请日[真实日期]
            IPC[真实IPC]
            诉讼角色[target] 被诉
          
          
            📋 INPADOC 同族专利（[N]件）
            
              公开号受理局申请日法律状态
              [同族公开号][受理局][申请日]有效
            
          
        
      
      <!-- ...更多被诉卡片 -->
    

    二、[target]作为原告主张的涉诉专利（[N2] 件）
    
      <!-- patent-card：header 用 .plaintiff 配色 -->
      
        
          [真实CN号]
          🟢 主张·原告方
        
        
          [真实专利标题]
          <!-- 同上结构 -->
          
            权利人[真实申请人]
            诉讼角色[target] 主张（原告）
          
        
      
    
  


<!-- 权利要求 modal -->

  
    ✕
    [CN号] — [专利标题]
    [权利要求全文，直接写入]

⚠️ 严禁写成两个并列的 section，例如：

❌ ⚔️ <对手>起诉专利（原告方·N件）... + 🛡️ 反诉专利（被告方·N件）...
✅ 一个 section，header 文案 = [target]涉诉专利（共 N 件），内部用 `` 小标题分组。

第6章：核心发明人（⚠️ 包含真实统计图和技术点列表）

6. 核心发明人延伸分析

  👤 [发明人真实姓名]（近3年共 [真实N] 件）
  
    
  
  
  近3年主要技术布局方向
  
    [真实技术方向1]（[N]件，代表：[CN号] [专利标题]）

第7章：三维结论

7. 三维结论
7.1 潜在涉诉地域分析
<!-- ⚠️ 地域风险分布必须展开为同族专利明细列表，不得仅显示汇总数字 -->

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


7.2 应诉预警综合总结
<!-- ⚠️ 不少于800字，完整连贯段落 -->

  [真实分析段落1：案件主要争议点...]
  [真实分析段落2：[target] 应诉策略...]
  [真实分析段落3：攻防博弈重点...]
  [真实分析段落4：当前态势研判...]
  [真实分析段落5：建议行动项，措辞以 target 为主语...]


7.3 趋势预测
[200字以上技术布局趋势总结]

  短期（6～12个月）[真实内容]
  中期（1～3年）[真实内容]
  长期（3年以上）[真实内容]

第8章：汇总列表

8. 涉诉专利汇总列表

  涉诉专利专利标题[target]角色同族公开号受理局法律状态申请日
  
    [CN号]
    [专利标题]
    [被诉/主张]
    [同族公开号]
    [受理局]
    有效
    [申请日]

自检清单（写完 HTML 后必须逐项核对）

写完 HTML 后，使用 files.grep 对生成文件做以下正则检查，任一项命中即必须修订：

#	正则	含义（命中即违规）
1	`<对手公司名>(起诉	涉诉
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/) 获取MCP。

Related skills

monitor-patent-litigation-risk-ip

Monitor patent-litigation exposure for a primary company and up to four named comparison parties. Use when users need target-centric identification of potentially litigated patents, patent-family and claim analysis, verified proceeding timelines, case deep dives, inventor activity, geographic exposure, litigation alerts, technology trends, and an evidence-backed HTML report with structured JSON or CSV attachments.

inventor-resignation-monitor

发明人离职监控简报生成工具。输入目标公司名称+技术领域，或直接输入发明人姓名，自动识别疑似离职发明人、检索其近N年在他处申请的专利，分析与原公司技术的相似度，输出结构化HTML风险预警简报。

睿观-实用新型专利检测

基于产品信息检测和搜索相似的实用新型/发明专利。当用户提到实用新型专利检测、专利侵权风险、专利相似度搜索、专利排查、发明专利查询、专利风险评估、TRO（临时限制令）风险分析、utility patent, invention patent detection, patent infringement risk, patent search, TRO risk, Ruiguan时触发此技能。即使用户未明确说"实用新型专利"，只要其需求涉及在目标市场销售前检查产品是否可能侵犯已有的实用新型/发明专利，也应触发此技能。

3 installs

patent-panorama-analysis

专利技术全景分析报告自动生成。用户上传专利数据Excel表格（含标题、申请人、申请日、法律状态、受理局、被引次数等字段）和技术拆解Excel表格后，自动分析专利数据并生成可编辑的HTML全景分析报告。报告包含5大模块：技术概况分析、重点技术分支分析、竞争对手分析、专利风险分析、企业专利布局建议。触发条件：当用户提及"专利分析""技术全景分析""专利全景报告""专利布局分析""CMC专利分析""专利竞争分析""专利风险""FTO分析""技术分解""专利趋势"等关键词时自动触发。也适用于用户上传专利数据Excel并要求生成分析报告的场景。

competitor-patent-landscape

竞争对手专利布局策略调研技能：给定竞争对手公司名称与技术领域，自动检索专利、识别重点布局、分析核心/外围策略，输出带有产品图可视化的HTML/PDF报告供企业IP团队和研发参考。

patent-portfolio-report

麦肯锡标准·专利组合解读分析报告交付Skill。输入分析标的（企业名称/专利清单/技术领域/竞争对手）及客户核心诉求，严格遵循10步SOP，按九大模块输出完整中文HTML专利组合分析报告，内含核心专利技术拆解可视化图、麦肯锡深蓝配色体系、金字塔原则排版。所有专利数据强制通过Patsnap实时检索，每模块末尾列明检索式备注。集成novelty-check、non-obviousness-check、triz-analysis、patsnap-mckinsey-sales-insight、patsnap-visit-strategist子技能流水线。适用场景：IPO尽调、并购估值、研发战略、337诉讼应对、企业出海布局、行业竞争格局分析。触发关键词：专利组合分析、专利尽调报告、专利价值评估、专利竞争格局、核心专利拆解、IPO知识产权尽调、专利战略报告、专利组合解读、麦肯锡专利报告。