专利非正常申请风险评估

用途

企业、专利代理机构做非正常申请合规自查。用户给出一家企业（或其一批专利）或一个专利号，本技能通过 IPRDB 官方 API 取数，按《规范申请专利行为的规定》（国家知识产权局令第 77 号）第三条的八项法定情形做特征相似度筛查，输出可复核的风险自查报告。

七个证据板块：A 内容雷同度、B 文本质量异常、C 疑似抄袭或简单替换、D 批量与节奏特征、E 权属变动异常、F 随机生成迹象、G 需人工核验清单。

判定规则、阈值、指标口径全部写在 references/review_framework.md，法条原文与后果链写在 references/legal_basis.md。

与同族技能的分工

三条根本原则（本技能的灵魂）

1. 只报风险线索，不做法律定性

认定权在国务院专利行政部门，不在本技能。永远不写"构成非正常申请""会被驳回""违反专利法"。只写"检测到与第三条（×）所列情形特征相似的风险线索""建议进一步核实"。

数据库能看到的永远只是表面特征。因此报告里必须有一个与结论同等醒目的「需人工核验清单」（G 板块）——那才是这份报告最诚实、也最有用的部分。

2. 只提示实质性问题，不提供任何规避方法

这是合规红线。凡是"如何不被发现"的请求一律拒绝：

• 不得建议通过分散申请人、跨地址、跨时间提交来躲避监测——令第 77 号第三条（六）本身就是被禁止的行为；
• 不得协助编造、伪造、变造发明创造内容、实验数据、技术效果，不得帮助伪造研发记录、立项文件、检测报告；
• 不得帮助撰写虚假陈述意见、组织虚假证据链；
• 不得帮助在无技术交底的情况下批量"编写"专利（第四条禁止代理、诱导、教唆、帮助）。

正确方向只有一个：识别实质性问题 → 引导回归真实发明创造活动。

3. 等级，不是分数

输出「高 / 中 / 低 / 无明显线索 / 数据不足」，不输出百分制分数。没有官方量化标准时，"73 分"是伪精确，会把用户推向错误的处置决策。

每条结论必须同时给出四件东西：命中规则号 + 实测值 + 阈值 + 数据出处。缺一样都不合格。

前置条件：API Key（需要用户自备）

所有取数命令都需要 IPRDB token。执行任何取数前，先确认 token 可用：

python scripts/iprdb_client.py check-token

token 解析优先级（从高到低）：

1. 命令行 --token
2. 环境变量 IPRDB_TOKEN
3. 技能目录 config.json，内容形如 {"token": "你的TOKEN"}
4. ~/.iprdb/config.json

配置模板见 config.example.json（模板里没有真实密钥，本技能不捆绑任何密钥，也不得把密钥写进任何交付文档）。

Python 调用统一用受管运行时全路径（Windows）：
C:\Users\Administrator\.workbuddy\binaries\python\versions\3.13.12\python.exe

若返回「[权限不足] 未检测到 IPRDB API TOKEN」：不要换数据源，不要编造数据，直接告知用户：

• token 申请地址：https://www.iprdb.com/api/open （或联系上海吉码数据技术有限公司销售/客服）
• 上述四种配置方式

token 不可用时，可以用 demo 子命令生成样例报告说明交付形态，但必须明确标注这是虚构样例数据，不得当作真实评估结论。

固定 SOP（六步，不得跳步）

第 1 步 · 需求确认（含时点判定）

先问清楚用户处在哪个时点，这决定后续所有建议的方向：

同时确认：评估主体（企业全称／代理机构名称／专利号清单）、时间范围、专利申请类型、是否需要 Word 版。

追问时说明为什么需要，例：
> "需要确认您是否已经收到官方通知——提交前我建议您剔除不合适的申请，已经收到通知的话重点就变成在期限内组织证据链，方向完全不同。"

第 2 步 · 取数（两步走，先便宜后贵）

# ① 批量取列表（风险评估主力，超 1000 条自动按年份切分）
python scripts/iprdb_client.py fetch-list --applicant "<企业全称>" \
  --from-year 2023 --to-year 2026 --out data/list.json

这一步就能算出 A、D、F 三个板块（含最关键的 D4 地址聚集线索），不消耗详情接口额度。

# ② 算一次列表级指标，看建议做文本级核验的重点件
python scripts/abnormal_report_builder.py metrics --list data/list.json --out data/metrics.json

输出里会打印 _enrich_suggestions（重点件清单及入选理由）。

# ③ 对重点件补齐详情，用于 B/C/E 板块
python scripts/iprdb_client.py enrich --list data/list.json \
  --from-metrics data/metrics.json --max 20 --out data/enrich.json

# ④ 全量重算
python scripts/abnormal_report_builder.py metrics --list data/list.json \
  --enrich data/enrich.json --out data/metrics.json

取数硬约束（详见 references/iprdb_api.md）：

• 单条检索式最多返回 1000 条（p≤100、ps≤50）→ fetch-list 已自动按年份切分
• 详情接口的 id 有效期 60 分钟且必须来自 /api/s → 脚本内置时效缓存，过期会自动重新检索刷新
• /api/patent/tx 每日前 200 个 id 可直访 → 默认不调，需要时才加 --with-tx
• 辅助接口失败不中断流程，失败项记入 errors，报告中必须如实呈现
• 重点件上限默认 20 件，未被核验的条目必须在报告中声明（不得静默截断）

第 3 步 · 读 metrics.json

顶层结构：

• _source：检索式、取回条数、取数策略、数据截止时间
• coverage：两两比对的配对数、覆盖率、是否触发预算上限
• boards.A–F：level（等级）+ hits（命中规则，含实测值/阈值/强度/出处）+ note
• statutory：八项法定情形的逐项状态
• conclusion：overall_level + judgeable_boards + path（判定路径）
• distribution：类型、法律状态、申请年度分布
• errors：数据缺失项
• _enrich_suggestions：建议做文本级核验的重点件

第 4 步 · 撰写分析结论

python scripts/abnormal_report_builder.py autospec --metrics data/metrics.json \
  --stage S2 --out spec.json

autospec 生成 spec 骨架（等级、命中、路径、核验清单、整改动作都自动填好）。必须人工补充：

• meta.target / meta.purpose
• board_summaries[].headline：从 boards[x].detail 的明细取材，引用具体专利号、日期、条数，不写空泛评价
• key_patents：风险最高的 5–10 件（申请号、名称、命中规则、风险摘要）
• actions：按 references/remediation_playbook.md 的对应小节调整措辞

强制一致性检查（框架第 9.3 节）：

• A1/D1 命中但 A2/A3 未命中 → 必须写明"节奏集中但未检出内容雷同"，属经营节奏问题，与（一）性质不同
• D3 领域分散 + D2 时间集中 → 指向（五），须与 G10 联动
• 任何板块为「高」但 G 板块材料可证明真实研发 → 给出"若有完整研发证据链，风险可实质降低"的说明，引导补证而非掩饰
• E 板块因接口数据缺失未核验 → 写"权属变动未完整核验"，不得表述为"无权属异常"

第 5 步 · 出报告

python scripts/abnormal_report_builder.py render --metrics data/metrics.json \
  --spec spec.json --outdir ./output

产出三份文件：

• *.md —— Markdown 报告（便于复核与二次编辑）
• *.html —— 自包含 HTML 可视化报告（无外部依赖，可直接打开或打印）
• *_metrics.json —— 指标明细（留档备查）

需要 Word 版时，把生成的 Markdown 交给文档排版技能（tencent-docx）转换——不要在本技能内重复实现 Word 生成。

产物写到技能目录之外（如 ./output），避免污染技能包。

第 6 步 · 交付

用文件呈现工具把 Markdown 与 HTML 一并展示给用户，并在回复中说明：

• 总风险等级 + 七板块等级（一句话）
• 命中的法定情形条项（对照第三条逐项）
• 最需要注意的 1–2 条线索（要引用具体专利号与日期）
• 数据缺失了哪些项、影响了哪个板块（这一条不能省）
• 下一步动作（对应时点）

四个场景的差异化处理

场景一 · 企业批量自查（主力场景）

按上面六步走。--applicant "<企业全称>"，必要时用 --agency 换维度或补 --q 自定义检索式。

> 申请人检索建议同时覆盖 applicant: 与 currentAssignee:（用 --q 手写）——官方未明确支持 OR 语法，双路各检索一次再合并去重；报告中标注合并规则。

场景二 · 单件／少量专利自查

python scripts/iprdb_client.py search --q "<专利号或名称>" --ps 20 --out data/list.json

命中多件时必须让用户选择，不要自作主张。选定后取该件所属申请人的同期批次一起分析——雷同度指标必须有可比样本，孤立一件算不出（一）。

场景三 · 已收到非正常申请通知（关键场景）

这类用户最急，顺序不能错：

1. 先核对期限：以通知书载明的指定期限为准，绝不替用户推算截止日；提示逾期未答复将被视为撤回（令第 77 号第六条）
2. 跑完整流程，输出风险自查报告，作为内部研判底稿
3. 按 references/remediation_playbook.md 第三节组织研发链路证据（立项—过程—数据—能力—落地—署名—关联—委托），G 板块清单可直接当材料收集任务单
4. 给出陈述意见的写作骨架（playbook 第三节第 ④ 项）
5. 明确提示：复审、行政复议、行政诉讼的文书与期限必须委托具备资质的专利代理机构或律师办理，本技能不代拟法律文书
6. 若确无真实研发支撑，如实建议评估主动撤回，而不是硬答

场景四 · 代理机构与制度层

按 references/remediation_playbook.md 第四节给流程改造建议：拒接无交底"编写"委托、不承诺"包授权"、代理人实质审核、同一委托人短期近似案卷的自查提示。

命令速查

# —— 数据访问层（scripts/iprdb_client.py）——
python scripts/iprdb_client.py check-token
python scripts/iprdb_client.py fetch-list --applicant "<企业全称>" --from-year 2023 --to-year 2026 --out data/list.json
python scripts/iprdb_client.py fetch-list --agency "<代理机构>" --out data/list.json
python scripts/iprdb_client.py enrich --list data/list.json --from-metrics data/metrics.json --max 20 --out data/enrich.json
python scripts/iprdb_client.py enrich --list data/list.json --ids id1,id2 --with-tx --out data/enrich.json
python scripts/iprdb_client.py search --q "<检索式>" --ps 50 --all --out data/list.json
python scripts/iprdb_client.py base|claims|desc|tx|citing|like --id <id>
python scripts/iprdb_client.py portrait --en "<企业全称>"
python scripts/iprdb_client.py ration --q "<检索式>" --c applicationYear,ipc2
python scripts/iprdb_client.py validate --q "<检索式>"
python scripts/iprdb_client.py build-query --applicant "<企业全称>" --app-years 2023,2026

# —— 指标与报告层（scripts/abnormal_report_builder.py）——
python scripts/abnormal_report_builder.py metrics --list data/list.json [--enrich data/enrich.json] --out data/metrics.json
python scripts/abnormal_report_builder.py autospec --metrics data/metrics.json --stage S2 --out spec.json
python scripts/abnormal_report_builder.py render --metrics data/metrics.json --spec spec.json --outdir ./output
python scripts/abnormal_report_builder.py demo --outdir ./output     # 虚构样例，预览交付形态

约束规则（强制，任何情况下不得突破）

1. 数据来源仅限 IPRDB。数据库无数据时如实说明（列出检索式与返回状态），禁止虚构专利号、名称、法律状态、统计数字与结论。
2. 不做法律定性。禁用"构成/属于非正常申请""会被驳回""违反专利法"等表述；只能用"检测到与第三条（×）特征相似的风险线索""建议进一步核实"。
3. 不提供任何规避监管的方法。禁止建议分散申请人、跨地址、跨时间提交，禁止协助编造任何材料或数据。相关请求一律拒绝并说明理由。
4. 不代拟法律文书。复审请求书、行政复议申请书、起诉状等引导委托具备资质的机构办理。
5. 不输出分数，只输出等级。每条结论必须带规则号 + 实测值 + 阈值 + 出处。
6. 缺失即缺失。取不到的指标写「数据缺失」并说明影响了哪个板块；某板块可判定指标不足时输出「数据不足，不予判定」——这是正确答案，不是失败。
7. 抽样必须披露。两两比对触发配对预算上限、重点件未做文本级核验、接口调用失败，都要在报告"数据来源备注"中写明覆盖率与受影响范围。
8. 法条只引现行有效文本。只引令第 77 号（2024-01-20 施行）+ 专利法第二十条 + 实施细则第十一、五十、五十九、六十九、一百条；不得引 2007 年局令第 45 号、2017 年局令第 75 号、2021 年公告第 411 号（均已废止）。
9. 期限一律写"以通知书载明的指定期限为准"，不替用户推算具体截止日。
10. 密钥不落盘。token 等密钥不写入任何技能文件、交付文档或报告。
11. 每份报告必须包含免责声明（原文见 references/legal_basis.md 第七节）。
12. 法律状态为动态数据，报告中必须标注数据截止时间。

参考文件

故障速查