通信SEP专利对标分析工具

standard_claim_charting 是通信领域 SEP（标准必要专利）分析工具。它面向 3GPP/ETSI 标准与专利 claim 的对标分析场景，可以根据输入专利 PN 自动串联 TS/TR 标准推荐、标准 section 候选召回、AICC claim charting 三阶段分析，并返回结构化 SEP 判断、证据 section、claim feature mapping 和解释说明。

• 需要判断某个通信专利是否可能构成 SEP 时。 • 需要对专利 claim 与 3GPP TS/TR 标准文本进行 claim charting 时。 • 只有 PN，希望系统自动推荐相关 TS/TR 并完成端到端分析时。 • 已经知道相关 TS/TR，希望跳过 TS 推荐，直接做 section 召回和对标时。 • 已经知道候选 section_id，希望跳过推荐和召回，直接做 AICC 对标分析时。 • 需要指定某一条 claim，例如 claim_num=2，只针对该 claim 做分析时。

• 不适合用于非通信领域、非标准必要性相关的普通专利检索。 • 不适合修改、上传、审批或发布 3GPP 标准文档。 • 不适合替代法律意见；输出是技术对标辅助分析结果，需要专家复核。 • 不适合在没有 PN、TS 或 section 证据上下文的情况下进行纯自然语言判断。

必填参数 • PN：专利公开/公告号，例如 US8767570B2。 可选参数 • claim_num：要分析的 claim 编号，例如 2。传入后工具会读取专利 claim 文本并抽取指定编号 claim。 • TS：指定 TS/TR 列表。传入后跳过 TS 推荐。 [ {"std_num": "TS 37.213", "version": "v17.8.0"}, {"std_num": "TS 38.321", "version": "v19.0.0"} ] • section_id：指定标准 section 分组。传入后跳过 TS 推荐和 section 召回。 [ { "std_num": "TS 37.213", "version": "v17.8.0", "section_id": [ "n8801592123893449684-1707790277789616748:61", "n8801592123893449684-1707790277789616748:18" ] } ] • lang：语言参数，支持 en、cn，其他值默认 en。

工具返回 JSON 字符串，统一结构为： { "error_code": 0, "error_message": "ok", "total": 1, "data": { "mode": "pn", "patent": {}, "used_claim": "...", "used_ts": [], "candidate_section_count": 622, "section_recall": [], "aicc_result": {} } } 关键字段说明： • mode：执行模式，取值为 pn、ts、section_id。 • patent：PN 解析出的内部 patent_id、申请号、申请日等信息。 • used_claim：传入 claim_num 时抽取出的 claim 文本。 • used_ts：实际用于 section 召回或 AICC 分析的 TS/TR。 • candidate_section_count：候选 section 总数。 • section_recall：每个 TS/TR 的召回状态、召回数量和 metadata。 • aicc_result：最终 AICC claim charting 结果，包括 is_sep、explanation、all_mappings 等。

• PN 是必填参数。 • 只传 PN 时默认使用 TS 推荐结果中的前 5 个有效 TS/TR 继续后续分析。 • TS 和 section_id 均支持版本号带 v 或不带 v。 • 对外 MCP endpoint 是 streamable HTTP，响应为 text/event-stream，客户端应按 SSE 读取 event: message 的 data。 • 下游 TS 推荐接口也是流式接口，工具内部已经处理最终 type=result 事件。

截至 2026-07-10，QA 环境已完成以下验证： • MCP tools/list 注册发现通过。 • section_id、TS、PN-only 三种业务模式均通过。 • 60 秒以上 SSE 长连接验证通过，实测 66.70s 重请求期间正常输出 ping 并成功返回。 • 低 QPM 并发测试通过，3 个场景各 2 次、并发 2，总计 6/6 成功，最长 PN-only 请求 239.83s 成功返回。 最终结论：功能测试、长连接稳定性测试、低 QPM 性能测试均通过。