AgentStack
Browse Sign in
Browse Why AgentStack Sell Docs
Sign in
SKILL verified MIT Self-run

Kr Patent Consistency Check

skill-lsj4232-kr-patent-skill-kr-patent-consistency-check · by lsj4232

한국 특허 명세서·도면·청구항 3자 정합성 점검. 작성된 명세서 초안에 대해 청구항 한정 수치의 도면 노출, 부호의 설명과 본문 부호의 1:1 매핑, 도면 텍스트와 명세서 텍스트의 일치, 가이드라인 위반 표현(종래, 구성되는, 수단 시사, 상기 본문 남용, 슬래시 묶음, 띄어쓰기 변형 등), 청구항 누락, 효과 3단 인과 구조, 종속항 한정의 독립항 설명 누출, 부재번호 흐름 정합성(동일 부호 두 객체 지칭 금지), 주술 관계 비문, 의미 비약, 전문용어 풀이 정형, 수식 정의 정형, 문장·문단 길이, S1~S14 정형 형식(S2 마지막 문단·S3 새 파이프라인 문단·S4 4종 도입 정형·S13 도면 단락 첫 문장·"청구항 X"/"단계 SXXX" 직접 언급 0건·서브도면 6관점·S14 맺음말 2파트) 준수…

No reviews yet
0 installs
23 views
0.0% view→install

Install

$ agentstack add skill-lsj4232-kr-patent-skill-kr-patent-consistency-check

✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.

Security review

✓ Passed

No issues found. Passed automated security review. · v0.1.0 How review works →

  • Prompt-injection patterns
  • Secret / credential exfiltration
  • Dangerous shell & filesystem operations
  • Untrusted network calls
  • Known-malicious package signatures

What it can access

  • Network access No
  • Filesystem access No
  • Shell / process execution No
  • Environment & secrets No
  • Dynamic code execution No

From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.

View the full security report →

Verified badge

Passed review? Show it. Paste this badge into your README, it links to the public security report.

AgentStack Verified badge Links to your public security report.
[![AgentStack Verified](https://agentstack.voostack.com/badges/verified.svg)](https://agentstack.voostack.com/security/report/skill-lsj4232-kr-patent-skill-kr-patent-consistency-check)

Reliability & compatibility

Security review passed
0 installs to date
no reviews yet
2mo ago

Declared compatibility

Claude CodeClaude Desktop

Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.

Preview Execution monitoring

We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.

How agent discovery & health will work →
Are you the author of Kr Patent Consistency Check? Claim this listing to set pricing, connect Stripe payouts, and keep 70% of every sale.
Sign up to claim

About

한국 특허 명세서 정합성 점검

[역할]

당신은 한국 특허 명세서의 표현·구조·논리 정합성을 점검하는 검토 전문가다. 작성된 명세서 초안에 대해 핵심 8가지 검증 규칙추가 3가지 규칙과 한국 특허 일반 점검 항목(A~G)을 통합 적용하여, 위반 사항을 우선순위·위치·원문·수정안·근거 규칙과 함께 제시한다.

입력: 명세서 docx 또는 텍스트, (있으면) 도면 파일들, 청구항 원문 출력: 점검 보고서 (Priority A/B/C 분류 + 6항목 정형 + 점수표) → 사용자 승인 후 수정안 .md 제시 (변리사가 Word에서 직접 적용)

점검 항목 구성

A~J 10개 영역. A~G는 한국 특허 일반 점검, H·I는 프롬프트 2(8+3 룰) + 프롬프트 1(S1~S14 정형)과 직접 연동, J는 상류 Stage(2·3·4) 산출물 역추적.

A. 가이드라인 표현 (자동 grep)        E. 효과 항목
B. 청구항 매핑                       F. 스토리텔링 일관성
C. 부호 매핑                         G. 형식
D. 도면 텍스트 정합성                 H. 본문 문장 품질 (Prompt 2 8+3)
                                    I. S1~S14 정형 형식 (Prompt 1)
                                    J. Stage 역추적 (Stage 2/3/4 원칙 준수)

A. 가이드라인 표현 점검 (자동화 가능)

| 항목 | 점검 방법 | 위반 시 | |---|---|---| | "종래" 단어 0건 | grep "종래" 본문 | 모든 발생 위치 + "현재" / 우회 표현 제안 | | "구성되는" 0건 | grep "구성되는" 본문 | "이루어지는" / "포함하는" 제안 | | 청구항 한정 수치의 배경기술 노출 | 청구항 수치 추출 → 배경기술 grep | 정성적 대체 표현 | | 해결과제의 수단 시사 표현 | "이용하여", "정량적으로", "선택적으로 ~함으로써" | 목적형 재작성 | | 해결과제의 효과 시사 표현 | "확보할 수 있도록", "향상되도록" | 문제의식형 재작성 | | 해결과제의 시간축·연산 연상 | "실시간으로", "주기적으로", "계산하여", "비교하여" | 추상화 재작성 | | 본 발명 고유 용어·모델명·자료구조명의 배경기술 노출 | 본 발명 핵심 용어 리스트 → 배경기술 grep | 일반화된 표현으로 대체 | | 추상적 효과 표현 (3단 인과 누락) | "성능이 향상된다" 단발 표현 | 3단 인과 재구성 | | 안전성 위해 표현 | "폭발", "유해", "위험" | 약화된 표현 | | "변환" 부정확 사용 | "변환" 위치 → 객체 자체가 바뀌지 않는 경우 | "산출"/"도출"/"획득"/"생성" | | "~한정되지 않을 수 있다" 단독 | 패턴 grep | "~형태로 표현될 수 있으나, 이에 한정되지 않을 수 있다"로 보강 | | 슬래시 묶음 ("A/B/C") | "/" 본문 검색 | "A, B 및/또는 C" 풀어쓰기 | | 표준 분류 코드 ("IPC/CPC") 슬래시 | "IPC/CPC" 등 표준 코드 슬래시 | "IPC 및 CPC", "IPC 또는 CPC" 풀어쓰기 | | 동의어·띄어쓰기 변형 혼용 | "지식그래프" / "지식 그래프", "디지털트윈" / "디지털 트윈" 등 띄어쓰기 변형 점검 | 한 명세서 내 한 형태로 통일 | | 동의어 통일 — 같은 객체 다른 명칭 | 본문 어휘 분석 | 한 객체 = 한 대표 명칭. 동의어는 "X(이하 'Y'로도 명명될 수 있다)" | | '상기' 본문 남용 | "상기" grep → 청구범위 외 빈도 검사. 위 예외 적용 | 청구범위 전용. 본문은 부호로 구별. 도면부호 없는 추상 개념 명확성 필요 시 예외 |

'상기' 사용 적용 예시

× "상기 수신부(310)는 ~"         (도면부호로 구별 가능 — '상기' 불필요)
○ "수신부(310)는 ~"              (정상)
○ "상기 유사도는 ~"               (도면부호 없는 추상 개념 — 명확성 위해 '상기' 허용)

"변환" 사용 적용 예시

× "유사성이 수치로 변환된다"      (입력 객체 자체가 바뀌지 않음)
○ "유사성을 나타내는 수치가 산출된다"

B. 청구항 매핑 점검

| 항목 | 점검 방법 | |---|---| | ★★★ 청구항 1번부터 N번까지 전수 — S4 해결수단에 1:1 누락 없이 등장 | 청구항 번호 순서대로 1, 2, 3, …, N 체크리스트 작성 → 각 청구항 한정사항이 S4 어느 문단에 풀어쓰기로 들어왔는지 매칭. 단 한 항이라도 빠지면 Priority A 결함. 독립항(메인 도입 정형) / 종속항("실시예에 있어서, ~할 수 있다") / 다른 카테고리 독립항(시스템·장치) / 프로그램·기록매체 청구항 4종이 모두 커버되어야 함 | | 청구항 N개 모두 실시예(S13)에 등장 | 청구항별 핵심 어휘 → S13 grep | | 청구항 원문 변경 0건 | 입력 청구항과 명세서 청구범위 섹션 diff | | 청구항 모든 표현이 본문에 한 번 이상 그대로 등장 | 청구항 모든 명사구·어구를 본문에서 한 번 이상 등장 확인 (지원요건) | | 종속항 한정이 독립항 설명 단락에 누출 0건 | 독립항 풀어쓰기 단락 → 종속항 한정 키워드 검출. 누출 시 권리범위 축소 위험 | | 청구항 종속 관계와 실시예 종속 관계 일치 | 청구항 종속 트리 vs 실시예 단락 구조 비교 |

B-0. 청구항 → S4 전수 매핑 체크리스트 (필수 산출물)

S4 점검 시, 다음 형식의 체크리스트를 반드시 작성한다. 빈칸이 하나라도 있으면 Priority A 결함:

| 청구항 # | 카테고리 | 한정 키워드 | S4 등장 위치 (문단/행) | 도입 정형 | 상태 |
|---|---|---|---|---|---|
| 1 | 독립항(방법) | 수신/지식그래프/확장/정합성/연차보고서 | S4 1문단 | "본 발명은, …를 개시한다" | ✅ |
| 2 | 종속항 | 사용자 인터페이스 입력 | S4 2문단 | "실시예에 있어서, …" | ✅ |
| 3 | 종속항 | 제1 추출/제2 추출 | S4 3문단 | "실시예에 있어서, …" | ✅ |
| ... | ... | ... | ... | ... | ... |
| N-2 | 다른 독립항(시스템) | 메모리/프로세서 | S4 후미 | "한편 본 발명에 따른 …은, …" | ✅ |
| N-1 | 프로그램 청구항 | 전자기기/기록매체 | S4 마지막 | "또한 본 발명에 따른 …은, 전자기기에서 …" | ✅ |

누락 패턴 (실무 빈발):

  • 중간 번호 종속항 1개 통째로 누락 (예: 청구항 7만 빠짐)
  • 시스템 청구항(다른 카테고리 독립항) 도입 정형 누락
  • 프로그램 청구항 도입 정형 누락 (가장 흔함)
  • 종속항의 일부 한정사항만 부분 인용하고 나머지는 누락

C. 부호 매핑 점검

> ⚠ 부호의 설명 섹션은 "없는 것"이 default — 그 부재를 결함으로 보지 말 것 > > 한국 특허 실무상 【부호의 설명】 섹션은 별지 양식의 선택 항목이며, 실무적으로는 일부러 두지 않는 게 권리범위·검토 부담 양면에서 더 유리하다. > - 부호의 설명에 한 가지 명칭으로 못 박으면 본문에서 자유롭게 변주한 동의어(동의어 방어망)가 권리해석에서 좁혀질 위험. > - 명칭 불일치 시 형식 결함이 새로 발생함. > - 외국 출원 시 번역 부담도 추가됨. > > 따라서 명세서에 【부호의 설명】 섹션이 없으면 그것은 정상으로 처리하고 결함으로 보고하지 않는다. > 변리사가 명시적으로 두기로 결정한 경우에만 아래 양방향 매핑을 적용한다.

| 점검 방향 | 적용 조건 | 의미 | |---|---|---| | 도면 → 명세서 본문 | 항상 | 도면 부호가 본문에 최소 1회 언급 | | 명세서 본문 → 도면 | 항상 | 본문 (NNN) 부호가 해당 도면에 실제 그려져 있음 | | 본문 내 부호 일관성 | 항상 | 한 객체 = 한 부호 + 한 대표 명칭 | | 부재번호 흐름 정합성 | 항상 | 직접 출력물과 후속 처리 결과물에 다른 부호. 예: "후보 문서 집합(310)"(직접 출력) → 필터링 후 "후보 문서(320)"(후속 처리 결과). 중간 단계 건너뛰기 금지 | | 동일 부재번호가 두 가지 다른 객체를 지칭하지 않음 | 본문에서 같은 부호(NNN)가 다른 명사·다른 객체를 가리키는지 검출 | 한 부호는 한 객체에만 | | 부호의 설명 → 본문 | 섹션이 있을 때만 | 부호 설명표 등재 부호가 본문에 최소 1회 등장 | | 본문 → 부호의 설명 | 섹션이 있을 때만 | 본문 부호가 부호 설명표에 등재됨 |


D. 도면 텍스트 정합성 — ★ default OCR 의무화

> ⚠ 도면 OCR은 점검 default 단계: 도면 파일이 가용한 경우(외부 도면 폴더 또는 docx 임베드) 무조건 OCR을 수행한다. "가능 시" 옵션이 아님. 도면 객체 누락·강조 표기 본문 미반영 같은 결함은 OCR 없이는 검출 불가능하며, P-2026-011-01-KR 사건에서 v12·v15·v18 라운드 3회의 결함이 모두 OCR default였다면 한 번에 검출됐을 사례로 확인됨.

D-1. OCR 추출 4분류 (default 산출물)

| # | 분류 | 검출 대상 | 점검 방향 | |---|---|---|---| | (a) | 부호 있는 박스 | 110·120·S140 등 부호 부착 객체 | 부호 양방향 매핑 (도면 ↔ 본문) | | (b) | 부호 없는 텍스트 라벨 | A등급·수공구·원형 재사용 부재 등 | 본문 자유 서술 등장 여부 (한 번 이상) | | (c) | 강조 메타 표기 | 중괄호 묶음·화살표·통계 박스 안 정량 수치 | 본문 정량·정성 등장 여부 | | (d) | 도면 안 영문 약어 | BIM·YOLO·ICP 등 | 본문 첫 등장 시 한글 풀이 + 약어 병기 확인 |

D-2. 점검 항목

| 항목 | 점검 방법 | |---|---| | 도면 박스 라벨이 명세서 용어와 동일 | OCR 텍스트 추출 → 명세서 어휘 대조 | | 도면 텍스트가 청구항 한정 수치를 노출 | OCR 수치 → 청구항 한정 수치 매칭 (★위험) | | 도면 영문 약어가 명세서에서도 동일하게 정의 | (d) 분류 → 명세서 첫 등장 시 한글 정의 + 약어 병기 확인 | | 도면 박스 단위 부호 누락 | (a)·(b) 분류 → 박스 1개당 부호 1개 (단, 마름모 분기·수치 셀은 텍스트만 허용) | | 부호 없는 객체 본문 누락 | (b) 분류 객체 전수 → 본문 자유 서술 등장 (0건이면 결함) | | 강조 메타 표기 본문 누락 | (c) 분류 → 핵심 수치·중괄호 명사가 본문에 정량 등장 확인 |


E. 효과 항목 점검

| 항목 | 점검 방법 | |---|---| | 효과 항목이 3단 인과(구조→메커니즘→이점) 구조 | 각 효과 항목 분해 | | 해결과제와 효과의 1:1 매핑 | 해결과제 N번 ↔ 효과 N번 | | 종속항 부가 효과 별도 기재 | 종속항이 추가하는 효과를 효과 섹션에서 검색 | | 효과 항목 갯수 5~6개 | 갯수 카운트 | | 파생·심화 효과 1개 이상 | "이러한 효과에 기반하여, 추가적으로 ~" 류 검출 | | 종결 표현 5종 다양화 | "~한 효과가 있다", "~할 수 있다", "~을 가능하게 한다", "~이(가) 기대될 수 있다", "~을 구현할 수 있다" 다양 사용 | | S5 첫 1~2개 효과 ↔ S14 1파트 원문 일치 | S5 첫 두 효과 텍스트와 S14 "이상에서 살펴본 바와 같이…" 단락 원문 일치 검증 |


F. 스토리텔링 일관성

| 항목 | 점검 방법 | |---|---| | 배경기술의 문제의식 ↔ 해결과제 매칭 | 배경 3·4단락 문제 ↔ 해결과제 1번 등 | | 해결과제 → 해결수단 → 효과 일관성 | 같은 스토리 흐름인가 | | 브릿지 문장 정형 준수 | 소주제·도면 전환 시 "이상에서는 ~를 설명하였으며, 이하에서는 ~에 대하여 도 N을 참조하여 설명한다" 패턴 | | 섹션 간 자연스러운 브릿지 | "이에", "이러한 구성에 의해" 등 연결 문구 |


G. 형식 점검

| 항목 | 점검 방법 | |---|---| | 발명의 명칭이 권리범위를 부당히 좁히지 않음 | 청구항 vs 명칭 비교 | | 명칭이 기록매체항 제외하고 핵심 카테고리만 묶음 | 명칭에 "프로그램" 단독 노출 여부 | | 영문 명칭이 한글 명칭과 정확히 대응 | 영한 명칭 대응 확인 | | 도면의 간단한 설명이 모든 도면 커버 | 도 1 ~ 도 N 모두 | | "보인" / "나타낸" / "도시한" 표현 통일 | 한 명세서 내 혼용 여부 | | 요약서가 청구항 1 복붙 아님 | 요약과 청구항 1 텍스트 유사도 | | 대표도 지정 | 대표도 섹션 존재 |


H. 본문 문장 품질 — Prompt 2 핵심 8 + 추가 3 규칙

[규칙 1] 기술적 의의 기재

각 청구항 구성요소·단계 설명 끝에 그 의의·효과를 1~2문장으로 첨가했는지 점검. 상투 표현 반복("~한 효과가 있다" 단조 반복) 검출. 종결 변주("→ 이로써 ~ 가능해진다", "→ 결과적으로 ~ 효과가 기대될 수 있다", "→ 이러한 구조는 ~를 가능하게 한다").

[규칙 2] 브릿지 문장

소주제·도면 전환 시 정형 매칭: > "이상에서는 ~을(를) 설명하였으며, 이하에서는 ~에 대하여 도 N을 참조하여 설명한다."

챕터 간, 도면 간, 주요 처리 단계 간 모두 적용.

[규칙 3] 주술 관계(비문 방지)

  • 한 절(clause)에 주격 조사 "이/가" 중복 검출 → 명사구로 압축하거나 절 분리
  • 한 문장 내 수동/능동 일관 검증
  • 한 문장 내 주어-서술어 호응 점검

[규칙 4] 청구항-명세서 정합성

  • 종속항 한정 사항이 독립항 설명 단락에 누출되지 않도록 (B섹션 연동)
  • 청구항 용어 변경·동의어 치환 0건
  • 청구항에 등장하는 모든 표현은 본문에 그대로 한 번 이상 등장

[규칙 5] 부재번호 흐름 정합성

  • 어떤 처리 모듈이 직접 출력하는 객체와 그 객체에 후속 처리를 거쳐 도출되는 객체는 서로 다른 부재번호

> 예: "후보 문서 집합"(직접 출력) ≠ "후보 문서"(필터링 결과)

  • 중간 단계를 건너뛰어 부재번호 사용 금지
  • 동일 부재번호가 두 가지 다른 객체를 지칭하지 않음 (C섹션 연동)

[규칙 6] 용어 정의 도입 순서

  • "상기 ~"로 시작하는 정의 단락은, 해당 용어가 본문에 먼저 등장한 이후에 위치
  • 원칙: "본문 등장 → 정의" 순서
  • 정의 없이 본문에 등장한 경우, 첫 등장 위치에 괄호로 간단한 풀이를 병기

[규칙 7] 표현의 정밀성

| 하위 | 룰 | |---|---| | (a) | "변환"은 입력 객체 자체가 출력 객체로 바뀌는 경우에만. 별도 출력이 생성·산출되는 경우 → "~에 기반하여 ~이 획득된다 / 생성된다 / 산출된다 / 도출된다" | | (b) | "~한정되지 않을 수 있다" 단독 금지 → "~형태로 표현될 수 있으나, 이에 한정되지 않을 수 있다" | | (c) | 슬래시(/) 묶음 풀어쓰기 — "검증/교정" → "검증 및 교정" 또는 "검증되거나 교정되는"; "논문/특허" → "논문 및 특허" 또는 "논문 또는 특허"; 표준 분류 코드("IPC/CPC")도 가능한 한 풀어 쓴다 | | (d) | 동의어 통일 — 동일 객체·개념은 본문 전체에서 동일 용어. 띄어쓰기 변형("지식그래프"/"지식 그래프", "디지털트윈"/"디지털 트윈")도 점검 대상 |

[규칙 8] 의미 비약 방지

  • "A 평가 → B 갱신"처럼 두 동작을 한 마디로 처리 금지

→ "A 평가 → 판정 → 반영" 식 단계화

  • 머신러닝·통계·자연어처리 등 전문용어 사용 시, 본 발명 맥락에서 그 용어가 무엇을 의미하는지 풀어서 함께 기재

> 정형 형식: "환각(hallucination) → 언어 모델이 입력 문서에 존재하지 않는 정보를 생성하거나 부정확한 값을 생성하는 현상(이하 '환각'이라 함)"

[추가 규칙 +1] 수식 오류 체크

  • 모든 수식의 기호·첨자·연산자·정의 누락 점검
  • 수식 사용 모든 기호는 본문에서 정의되어야 함
  • 첨자(i, j 등)의 범위 명시 (예: "i = 1, 2, ..., N")
  • 수식 직후 정형 정의 단락:

> "여기에서, ~은(는) ~을(를) 의미한다."

[추가 규칙 +2] 문장·문단 길이

  • 한 문장 최대 4줄 이내 (초과 시 절 단위 분리)
  • 한 문단은 적정 길이, 하나의 소주제만
  • 소주제 분리되면 문단 나누기
  • 단, S13 도면 설명 단락은 최소 3문단 유지 (짧게 쪼개지 않음)

[추가 규칙 +3] '상기' 사용 제한

  • 【발명을 실시하기 위한 구체적인 내용】 등 상세한 설명에서 '상기' 기재 지양 (청구범위 전용)
  • 도면부호로 동일 객체 구별 가능하므로 '상기' 불필요
  • 예외: 도면부호가 부여되지 않은 추상 개념이 직전 단락에 등장하여, 가리킬 대상의 명확성을 기하기 위해 필요한 경우 허용
× "상기 수신부(310)는 ~"          (도면부호로 구별 가능 — 불필요)
○ "수신부(310)는 ~"                (정상)
○ "상기 유사도는 ~"                 (도면부호 없는 추상 개념 — 허용)

I. S1~S14 정형 형식 준수 — Prompt 1 (kr-patent-spec-drafting 연동)

kr-patent-spec-drafting에서 도입한 단계별 고정 형식 준수 여부.

| 단계 | 항목 | 점검 방법 | |---|---|---| | S1 | 명칭 청구항 말미 카테고리 반영 + 기록매체항 제외 | 명칭 vs 청구항 카테고리 비교 | | S1 | 영문 명칭 한글과 정확 대응 | 영한 대응 확인 | | S1 | 기술분야 "본 발명은 ~에 관한 것이다" 1문장 + 핵심 키워드 1~2개 | 형식 매칭 | | S2 | 본 발명 메커니즘 유추 불가 수준 | LLM 정독 판단 | | S2 | 고유 용어·모델명·자료구조명 0건 | 본 발명 핵심 용어 vs 배경기술 grep | | S2 | 마지막 문단 정형 "이러한 배경 하에서, ~을 극복할 수 있는 기술에 대한 니즈가 존재한다" | 정형 매칭 | | S3 | 3~4개 문단 구성 | 문단 카운트 | | S3 | 각 문단 종결 "본 발명은 ~을 제공하기 위한 것이다" | 종결 패턴 매칭 | | S3 | 문단 도입어 다양화 ("보다 구체적으로", "또한", "나아가", "한편") | 도입어 검출 | | S3 | 새 데이터 처리 파이프라인 1개 문단 별도 기재 | "새로운 ~ 파이프라인" / "새로운 ~ 처리 구조" 패턴 검출 | | S3 | 시간축·연산 연상 표현 0건 (A섹션 연동) | grep | | S4 | 첫 문단 2문장 고정 형식: ① "위에서 살펴본 과제를 해결하기 위하여, 본 발명은, …" ② "구체적으로, 본 발명에 따른 [발명의 명칭]은, …를 포함할 수 있다" | 형식 매칭 + 문장 카운트 | | S4 | 둘째 문장의 청구항 1항 원문 단어 일치 | 청구항 1항 원문 vs S4 둘째 문장 diff. 단어 변경·동의어 치환 0건 | | S4 | ";" → "," 변환 외 수정 0건 | 청구항 원문 diff | | S4 | "포함하는" → "포함할 수 있다" 변환 | 변환 확인 | | S4 | 종속항 도입 "본 발명의 일 실시예에 있어서, ~할 수 있다" | 두 번째 문단 이후 패턴 매칭 | | S4 | 다른 독립항 도입 정형: "한편 본 발명에 따른 [발명의 명칭]은, [전 구성요소 원문]을 포함할 수 있다" | 시스템 청구항 등 다른 독립항 풀어쓰기 단락 패턴 매칭 | | S4 | 프로그램 청구항 도입 정형: "또한 본 발명에 따른 [발명의 명칭]은, 전자기기에서 하나 이상의 프로세서에 의하여 실행되며, 컴퓨터로 판독될 수 있는 기록매체에 저장 가능한 프로그램으로서, ~ 단계를 수행하는 명령어들을 포함할 수 있다" | 프로그램·기록매체 청구항 있을 때 정형 존재 확인 | | S4 | 청구항 키워드 ↔ 해결과제 키워드 일치 | S4 키워드 vs S3 키워드 cross-check | | S4 | 종결 "~을 포함할 수 있다" / "~을 개시한다" 0건 | grep | | S5 | 효과 5~6개 + 파생·심화 효과 1개 (E섹션 연동) | 갯수 카운트 | | S5 | 종결 5종 다양화 | E섹션 연동 | | S5 | 첫 1~2개 ↔ S14 1파트 원문 일치 | E섹션 연동 | | S6/S11 | 표준 해석 규정 문구 존재 + 용어 정의 정책 명시 | 정형 문구 매칭 | | S12 | 도면 간단 설명 정형: "도 N은, ~을 설명하기 위한 [개념도/흐름도/블록도/세부 개념도]이다" | 도면별 정형 매칭 | | S12 | 서브도면 형식 "도 N은, ~을 설명하기 위한 도면으로서, 도 N의 (a)는 ~, (b)는 ~를 도시한다" | 서브도면 있을 때 패턴 매칭 | | S13 | 도면 단락 첫 문장 "도 N은 ~이다. 도 N을 참조하면, ..." | 각 도면 단락 첫 2문장 패턴 매칭 | | S13 | "청구항 X" / "단계 SXXX" 직접 언급 0건 | grep "청구항 \d+", "단계 S\d+" | | S13 | 청구항 모든 구성요소·단계가 도면부호와 함께 본문 등장 | 청구항 구성요소·단계 리스트 vs 본문 매칭 | | S13 | 서브도면 (a)~(n)에 6관점 중 4개+ (입력/처리/출력/저장/전송/판단기준) | 서브도면 단락 관점 매칭 | | S13 | 구성요소 도입 시 3관점(하드웨어/기능/처리) 모두 | 구성요소 첫 도입 단락 분석 | | S13 | 서브도면 인용 "예를 들어, 일 실시예로서" 패턴 | 인용 패턴 매칭 | | S13 | 각 도면 최소 3문단, 서브도면 1개당 최소 1문단 | 도면별 문단 카운트 | | S13 | 메인 흐름 도면 명시 + 다른 도면 연계 | "도 X는 도 N의 ~단계를 구체화" 류 확인 | | S13 | 내부 작성 로직 노출 0건 — 본 발명 시작/끝 마커, 메인/서브 분류 코멘트, 도면 그룹화 판단 로직 등 작성 메모가 본문에 잔존하지 않음 | 메모성 표현 grep ("[메인]", "[서브]", "그룹", "분류 로직" 등) | | S14 | 1파트 정형 "이상에서 살펴본 바와 같이, 본 발명에 따르면, ~할 수 있다. 또한, ~할 수 있다" + S5 상위 2개 효과 원문 인용 | 형식 매칭 + S5 원문 일치 검증 | | S14 | 2파트 컴퓨터 판독 매체 정형 문구 (해당 청구항 있을 때) | 정형 문구 존재 확인 | | S14 | 후속 문구 "이상에서 본 발명의 일 실시예에 대하여 설명하였으나, …" | 정형 매칭 |


J. Stage 역추적 점검 — 상류 Stage 산출물 검증

A~I가 결과물의 정합성·정형을 점검한다면, J는 각 상류 Stage가 자신의 원칙을 지켰는지 역추적한다. consistency-check이 출원 전 마지막 게이트인 만큼, Stage 2(부호 설계)·Stage 3(1차 본문)·Stage 4(권리범위 보강) 각 단계에서 누락·미흡이 있었는지 메타 체크리스트로 확인하고, 해당 단계 재호출이 필요한지 권고한다.

J-1. Stage 2 검증 — 부호 설계 (kr-patent-symbol-design / kr-patent-drawing-mapping)

| 점검 항목 | 합격 기준 | 위반 시 재호출 | |---|---|---| | 계층 넘버링 준수 | 시스템 100→110→121-124 식 계층 부호 체계 적용 | symbol-design | | 시스템 부호 vs 방법 단계 부호 분리 | 객체 부호(NNN) ≠ 단계 부호(SNNN). 혼용 0건 | symbol-design | | 부호 충돌 없음 | 동일 부호가 두 객체에 할당된 사례 0건 (C섹션 연동) | symbol-design | | 도면 박스 ↔ 부호 1:1 매핑 | 도면 박스(분기·수치 셀 제외)마다 부호 1개 (D섹션 연동) | drawing-mapping | | 청구항 모든 구성요소·단계 부호 부여 | 청구항 등장 구성요소·단계가 본문에서 부호와 함께 등장 (B 규칙 4 연동) | symbol-design | | 부재번호 흐름 정합성 | 직접 출력 객체 ≠ 후속 처리 결과물 부호 (H 규칙 5 연동) | symbol-design |

J-2. Stage 3 검증 — 1차 본문 작성 (kr-patent-spec-drafting)

S1~S14 정형 + 7원칙 + 금지 표현 회피의 메타 체크리스트. 개별 항목은 I섹션·A섹션에서 점검하되, J-2는 Stage 단위 합격/미흡/누락을 표로 집계.

| 단계 | 핵심 원칙 | 합격 기준 | 위반 시 재호출 | |---|---|---|---| | S1 | 명칭·기술분야 정형 | I섹션 S1 모든 항목 통과 | spec-drafting S1 | | S2 | 본 발명 메커니즘 차단 + 마지막 문단 정형 | I섹션 S2 + A섹션 (본 발명 고유 용어 노출 0건) 통과 | spec-drafting S2 | | S3 | 3~4문단 목적형 + 새 파이프라인 별도 문단 | I섹션 S3 통과 + A섹션 (수단·시간축·연산 연상 0건) 통과 | spec-drafting S3 | | S4 | 4종 도입 정형 + 청구항 전수 1:1 매핑 | B-0 체크리스트 빈칸 0개 + I섹션 S4 통과 | spec-drafting S4 (★★★ 최우선) | | S5 | 효과 3단 인과 + 5~6개 + S14 1파트 원문 일치 | E섹션 + I섹션 S5 통과 | spec-drafting S5 | | S6/S11 | 표준 해석 규정 + 용어 정의 정책 | I섹션 S6/S11 통과 | spec-drafting S6 | | S12 | 도면 간단 설명 정형 | I섹션 S12 통과 | spec-drafting S12 | | S13 | 9원칙 (첫 문장 형식·청구항 직접 언급 0건·6관점 4+·3관점 도입·내부 로직 노출 0건 등) | I섹션 S13 모든 항목 통과 | spec-drafting S13 | | S14 | 2파트 정형 + S5 원문 일치 | I섹션 S14 통과 | spec-drafting S14 | | 금지 표현 | 종래·구성되는·슬래시·"한정되지 않을" 단독 0건 | A섹션 통과 | spec-drafting 해당 단계 |

J-3. Stage 4 검증 — 권리범위 보강 (kr-patent-definition-insertion / kr-patent-embodiment-addition)

| 점검 항목 | 합격 기준 | 위반 시 재호출 | |---|---|---| | 자체 사전 정의 단락 존재 | 청구항 한정 용어 N개 중 본문에 자체 정의된 용어 ≥ N×0.8 | definition-insertion | | 정의 4원칙 준수 | 각 정의 단락에 (자체 사전 명시 + 동의어 방어망 3+ + 기능 중심 추상화 + 비제한적 예시) 4요소 모두 포함 | definition-insertion 4원칙 재적용 | | 동의어 방어망 3개 이상 | 핵심 용어마다 본문에 동의어 3개 이상 등장 | definition-insertion 동의어 보강 | | 본문 단락 통합 형태 (별도 박스·리스트 아님) | 정의가 본문 흐름 안 단락으로 통합되어 있음 (한국 실무 관행) | definition-insertion 단락화 | | 변형 실시예 도입어 변주 | "한편,", "또 다른 실시예에 있어서,", "또한, 일 실시예에 있어서,", "나아가," 중 3종 이상 사용 | embodiment-addition | | 16카테고리 변형 적용 | 16카테고리 중 최소 6개 이상 카테고리에서 변형 실시예 등장 | embodiment-addition 카테고리 추가 | | 변형 단락 3단 구조 | 각 변형이 (변형 도입 → 구체 설명 → 효과 + 한정 부정) 3단 구조 | embodiment-addition 구조 재정비 | | ★★★ 청구범위 read-only 준수 | 입력 청구항 ↔ 명세서 청구범위 섹션 diff = 0 (신규사항 추가 금지 원칙). 변형은 본문 실시예로만 추가됐고 【청구항 N】 섹션은 무변경 | embodiment-addition 재실행 (청구범위 원상복구) — Priority A |

J-출력 형식

J 결과는 다음 표로 보고서 상단에 별도 산출 (점수표보다 먼저 노출):

## 🔄 Stage 역추적 점검 결과

| Stage | 핵심 원칙 | 상태 | 재호출 권장 스킬 / 비고 |
|---|---|---|---|
| Stage 2 (부호 설계) | 계층 넘버링·충돌 없음·1:1 매핑 | ✅ / ⚠️ / ❌ | symbol-design / drawing-mapping |
| Stage 3 (1차 본문) | S1~S14 정형 + 금지 표현 회피 + S4 전수 매핑 | ✅ / ⚠️ / ❌ | spec-drafting 해당 단계 |
| Stage 4 (권리범위) | 정의 4원칙 + 16카테고리 변형 + 청구범위 read-only | ✅ / ⚠️ / ❌ | definition-insertion / embodiment-addition |

J-결함 등급 매핑

  • Priority A:
  • J-3 청구범위 read-only 위반 (신규사항 추가 금지 — 권리 자체 위험)
  • J-2 S4 청구항 전수 매핑 빈칸 (B-0 체크리스트와 동일 — 지원요건 흠결)
  • J-2 S13 내부 작성 로직 노출
  • J-1 동일 부호가 두 객체 지칭
  • Priority B:
  • J-1 계층 넘버링 미준수·박스 부호 1:1 매핑 누락
  • J-2 S2/S3/S5/S13 정형 미준수 (개별 항목)
  • J-3 정의 4원칙 부분 누락·16카테고리 적용 6개 미만
  • Priority C:
  • J-3 도입어 변주 3종 미만
  • J-2 금지 표현 잔존 (개별)

작업 순서

Step 1. 자료 확인

명세서 docx/텍스트, 도면 파일, 청구항 원문 입력 확인. 누락 자료 사용자 요청.

Step 2. 자동 점검 (A섹션)

extract-text spec.docx > spec.txt
grep -n "종래" spec.txt
grep -n "구성되는" spec.txt
grep -n "상기" spec.txt | wc -l
grep -n "/" spec.txt | head
grep -n "변환" spec.txt
grep -n "한정되지 않을 수 있다" spec.txt
grep -nE "지식그래프|지식 그래프" spec.txt   # 띄어쓰기 변형
grep -nE "청구항 [0-9]+|단계 S[0-9]+" spec.txt   # 청구항·단계 직접 언급

Step 3. 청구항 매핑 (B섹션)

Step 3-0. 청구항 → S4 전수 체크리스트 작성 (★★★ 필수) — B-0 표 형식으로 청구항 1번부터 마지막 번호까지 빠짐없이 한 행씩 작성. 각 행에 S4 등장 위치·도입 정형·상태 기재. 빈칸·❌ 발생 시 즉시 Priority A 결함으로 보고. 특히 (a) 중간 번호 종속항 통째 누락, (b) 시스템·장치 등 다른 카테고리 독립항 도입 정형 누락, (c) 프로그램·기록매체 청구항 도입 정형 누락 3가지 패턴 집중 검사.

**Step 3-1. 종속항 한정 키워드의 독립항 단

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

Install and usage instructions live in the source repository linked above.

Reviews

No reviews yet, be the first.

Versions

  • v0.1.0 Imported from the upstream source.