kr-patent-prior-art-report — 우선심사용 선행기술 조사 패키지 생성
입력 / 산출물
입력: 한국 특허 명세서 .docx (청구항 포함), 케이스 폴더 경로 (docx가 있는 폴더가 기본)
산출물 (모두 케이스 폴더에 저장):
선행특허 1_{cc}{번호}{종별}.pdf ~ 선행특허 4_...pdf — 공보 원문 4건[{REF}]선행기술조사_{발명의 명칭}.md — 조사 보고서[OUR_REF]우선심사신청설명서.hwpx — 특허청 양식 설명서 (파일명 고정: 리터럴 "[OUR_REF]")
워크플로우
1단계: 명세서 파악
python scripts/extract_docx_text.py "<명세서.docx>" <scratchpad>/spec.txt
- Grep으로
【청구항, 【발명의 명칭】 위치 확인 후 청구항 전체와 과제해결수단을 Read.
- 독립항 번호(인용 문구 없는 항: 통상 방법/시스템/프로그램 3건)와 핵심 구성요소를
목록화한다. 핵심 구성요소는 이후 문헌 선정의 커버리지 기준이 된다.
- 특징적 종속항(차별화 포인트가 되는 항)도 2~3개 뽑아둔다.
2단계: 선행특허 4건 검색·검증 (WebSearch + WebFetch)
- WebSearch로
patents.google.com을 대상으로 검색한다. 검색어는 핵심 구성요소별로
국문/영문/중문을 섞어 여러 번 fan-out (예: "볼트 체결 딥러닝 검사 patents.google.com",
""bolt loosening" detection deep learning patent KR").
- 선정 원칙:
- 총 4건. 각 문헌이 서로 다른 핵심 구성요소를 커버하도록 분산 배치
(예: 센서 측정 / AI 판정 / 설계 대비 비교 / 개별 요소기술).
- 국가 혼합 권장 (예: 중국 공개 1건 + 한국 등록/공개 3건). 등록특허 우선.
- 반드시 실존 특허여야 함 — 후보마다
patents.google.com/patent/{번호}/{ko|en}을
WebFetch로 열어 서지사항(명칭·출원인·공개/공고일·청구항 1·법적상태)과
patentimages PDF 링크를 확인한다. 검증 안 되면 교체.
- 각 문헌에 대해 대비 청구항 매핑을 정한다 (독립항 중심, 종속항 보강).
3단계: PDF 다운로드
curl -sL -o "선행특허 N_{cc}{번호}{종별}.pdf" "https://patentimages.storage.googleapis.com/..."
- 파일명 규칙: 한국 등록
kr2292602b1 (등록번호 7자리+종별, "10-" 접두 제거),
한국 공개 kr20180131471a, 중국 cn118654725a. 영문 번역본이면 _en 접미.
- 다운로드 후 각 PDF의 페이지 수를 검증한다 (1~2페이지면 다운로드 실패 의심):
python -c "import re; d=open('파일.pdf','rb').read(); print(len(re.findall(rb'/Type\s*/Page[^s]', d)))"
4단계: 조사 md 작성
파일명: [{REF}]선행기술조사_{발명의 명칭}.md. 구성 (KIPO 우선심사 자체조사 양식 준용):
# [{REF}] 선행기술 조사 — {발명의 명칭}
대상 출원: ... (독립항: 청구항 X(방법), Y(시스템), Z(프로그램))
【검색결과】
1. 중국 공개특허 제XXXXXXXXX호 (YYYY.MM.DD. 공개) ← 공개특허는 "공개", 등록특허는 "공고"
2. 한국 등록특허 제10-XXXXXXX호 (YYYY.MM.DD. 공고)
...
* 문헌 서지 정보: 번호/명칭/출원인/첨부 PDF 파일명
【선행기술과의 대비설명】
| 청구항 | 선행기술 문헌명 | 유사점 | 차이점 | 대비 판단 | ← 문헌별 1행, 총 4행
## 종합 의견 (어느 문헌에도 개시되지 않은 본원 통합 구성 정리)
- 유사점: "문헌 N은 ~한다는 점에서, 청구항 X 및 Y와 유사점이 있음" 정형.
- 차이점: "청구항 X 발명은 **{본원 핵심 구조}**인 반면에, / 문헌 N은 **{문헌 방식}**임"
2문단 정형. 강조 부분이 hwpx에서 밑줄·볼드 처리되는 부분이다.
- 대비 판단: "문헌 N에는 ~에 대응되는 구성이 개시되어 있지 않음" 정형.
5단계: hwpx 빌드
python scripts/build_hwpx.py <config.json>
- config 스키마는
references/config_example.json (실전 예시) 참조. md 4단계에서
작성한 문안을 그대로 config의 rows/results에 옮긴다.
- 템플릿: 사용자가 제공한 기존 우선심사신청설명서 hwpx가 있으면 그것을,
없으면
assets/template_우선심사신청설명서.hwpx를 사용.
템플릿은 [14p: 기존 건 예시] + [58p: 복제본] 구조여야 하며, 스크립트는
후반부(마지막 출현)만 교체한다. 위치는 마커 텍스트로 동적 탐색하므로
같은 구조의 다른 템플릿에도 그대로 작동한다.
- 교체 항목: 【검색어】, 【검색IPC】, 【검색결과】 4항목, 대비표 데이터 4행
(밑줄·강조 charPr 자동 승계), 신청이유 1번 문단.
- 플레이스홀더 규칙 (사용자 확정 관행):
- 출원번호:
제10-{연도}-0000000호 (0 채움)
- 출원일:
{연도}년 월 일 — 월·일은 공란으로 남긴다 (임의 날짜 기입 금지)
- 신청이유 2~4번 문단(출원인·법적 근거)은 출원인이 같으면 손대지 않는다.
- 출력 파일명:
[OUR_REF]우선심사신청설명서.hwpx 고정 (리터럴 그대로,
REF 치환하지 않음 — 사용자가 결재 시스템 관행에 맞춰 직접 관리).
- 앞 예시 페이지 자동 삭제:
drop_example(기본 true)이면 빌더가 앞부분
참조용 예시 건(1~4p)을 스크립트로 제거하여 최종본을 실제 기입 복사본(4페이지
이내)만 남긴다. 문서 구역 설정(secPr)·단 설정(colPr)은 최초 문단 첫 run에만
있으므로 삭제 전에 새 첫 문단으로 자동 이동시킨다(이걸 안 하면 문서가 깨짐).
예시를 남기고 싶으면 config에 "drop_example": false.
- 페이지 수는 반드시 4페이지 이내. 대비설명 문안이 길면 표가 페이지를 넘겨
5~6페이지가 되므로,
table_font_height(1/100 pt, 표 데이터 셀 charPr 17·18)로
표 글자를 줄인다. 기본 900(9pt) 권장 — 템플릿 원본은 1100(11pt)이고 이 값이면
대개 6페이지가 나온다. 검증된 실측(PU26131KR 피로 예측 건): 1100→6p, 1000→4p,
900/850→4p. 안전마진을 위해 900 사용.
- 빌드 후 검증:
leading example dropped: True 로그 + 재파싱 OK 확인.- 실제 페이지 수 측정 (한컴오피스 설치 시):
python scripts/measure_pages.py <출력.hwpx>
→ COM으로 PageCount를 읽는다. pageBreak 개수 추정은 표가 넘칠 때 틀리므로
이 도구가 최종 판정. 4를 초과하면 table_font_height를 850, 800으로 낮춰
재빌드·재측정하여 4 이하로 수렴시킨다.
- 남은 문단 텍스트 덤프로 기입 내용 육안 확인.
6단계: 보고
- 산출물 목록, 문헌 4건 표(번호/일자/내용/대비 청구항), 대비 논리 요지 보고.
- 반드시 플래그: 출원번호·출원일 공란(수기 기입 필요), 대비설명 문안은 결재 전
변리사 검토 필요, hwpx는 한글에서 열어 표 레이아웃·페이지 수(4p 이내) 확인 권장.
- 최종본은 앞 예시 페이지가 빌더에 의해 자동 삭제되어 실제 기입 복사본만 남는다
(4페이지 이내). 대비표 분량이 많으면 한글에서 미세조정이 필요할 수 있다.
주의사항
- hwpx XML 조작 시: ET.register_namespace로 원본 프리픽스 보존, 직렬화 후 루트
시작 태그를 원본(전체 xmlns 선언)으로 되돌리고, mimetype 엔트리는 ZIP_STORED 유지.
- linesegarray는 교체 문단에서 제거 (한글이 열 때 재계산).
- WebSearch 결과의 특허번호·일자는 반드시 WebFetch로 재검증 후 사용 (환각 방지).
- 이 스킬은 조사 보고서 생성용이며, 진보성 판단의 법적 자문이 아니다.
누적 학습 항목
- (2026-07-09, PU26122KR 모듈러 접합부 건) 출원일을 오늘 날짜로 임의 기입했더니
사용자가 "2026년 월 일" 공란으로 수정함 → 이후 출원일은 항상 월·일 공란으로 생성.
- (2026-07-09) 출력 파일명은 케이스 REF로 치환하지 말고 리터럴
"[OUR_REF]우선심사신청설명서.hwpx" 그대로 사용 (사용자 확정).
- (2026-07-09) 공개특허 인용 시 일자 뒤 표기는 "공개", 등록특허는 "공고"로 구분
(참고 샘플은 전부 "공고"였으나 정확 표기 우선).
- (2026-07-09, PU26131KR 피로 예측 건) 최종 출력본에는 앞 참조용 예시 페이지가
없어야 하고 4페이지를 넘기지 말 것 → 빌더에
drop_leading_example 추가하여
기본 자동 삭제하도록 함. secPr/colPr을 새 첫 문단으로 옮긴 뒤 앞 문단 제거하는
방식이라 문서가 깨지지 않음(이전엔 사용자가 수동 삭제했음).
- (2026-07-09) 후보 특허가 공개 상태로 검색돼도 등록되었으면(KR10-XXXXXXXB1 존재)
등록번호·등록공고일로 표기하고 등록공보 PDF를 받는 것이 정확. Google Patents의
등록번호 페이지를 WebFetch하면 등록공고일과 등록공보 PDF 링크를 얻을 수 있음.
- (2026-07-09, PU26131KR) drop_example만으로 4페이지라 추정했으나 실제로는 6페이지였음
(표가 페이지를 넘김). pageBreak 개수 추정은 신뢰 불가 →
measure_pages.py(한컴 COM)로
실측이 필수. 표 폰트 table_font_height=900으로 낮춰 4페이지로 수렴시킴. 이후
기본값으로 900 채택하고, 초과 시 850/800으로 재조정.
- (2026-07-09) build_hwpx.py의 zip 쓰기에서 원본 ZipInfo 객체를 writestr에 재사용하면
header_offset이 남아 파이썬 zipfile 재읽기 시 "Overlapped entries" 에러 → 파일명
문자열 + compress_type로 쓰도록 수정(한/글은 열렸으나 후처리 스크립트가 깨졌었음).
1---2name: kr-patent-prior-art-report3description: 한국 특허 명세서 워드(.docx)를 입력받아 우선심사신청용 선행기술 조사 패키지를 한 번에 생성하는 스킬. ① 명세서에서 독립항·핵심 구성요소를 파악하고, ② Google Patents 웹검색으로 실존 선행특허 4건을 선정·검증하여 공보 PDF를 "선행특허 N_{국가}{번호}{종별}.pdf"로 케이스 폴더에 저장하고, ③ 【검색결과】+ 【선행기술과의 대비설명】(청구항/문헌명/유사점/차이점/대비판단 5열 표, 문헌별 4행) 형식의 조사 md 파일을 만들고, ④ 이를 기반으로 특허청 우선심사신청설명서 hwpx (검색어·IPC·검색결과·대비표·신청이유 자동 기입, 출원번호는 0000000 플레이스홀더, 출원일은 "YYYY년 월 일" 공란)를 빌드한다. "선행특허 조사해줘", "우선심사 선행조사", "선행기술조사 md", "대비설명 만들어", "우선심사신청설명서 hwpx", "선행특허 4개 찾아서 저장", "prior art search report" 같은 표현이 보이거나, 명세서 docx를 주며 우선심사 결재자료를 만들려는 맥락이면 사용. (검색식 작성만=kr-patent-search-query, 키워트 건수만=keywert-patent-count 스킬은 별개.)4---56# kr-patent-prior-art-report — 우선심사용 선행기술 조사 패키지 생성78## 입력 / 산출물910입력: 한국 특허 명세서 .docx (청구항 포함), 케이스 폴더 경로 (docx가 있는 폴더가 기본)1112산출물 (모두 케이스 폴더에 저장):131. `선행특허 1_{cc}{번호}{종별}.pdf` ~ `선행특허 4_...pdf` — 공보 원문 4건142. `[{REF}]선행기술조사_{발명의 명칭}.md` — 조사 보고서153. `[OUR_REF]우선심사신청설명서.hwpx` — 특허청 양식 설명서 (파일명 고정: 리터럴 "[OUR_REF]")1617## 워크플로우1819### 1단계: 명세서 파악2021```bash22python scripts/extract_docx_text.py "<명세서.docx>" <scratchpad>/spec.txt23```2425- Grep으로 `【청구항`, `【발명의 명칭】` 위치 확인 후 청구항 전체와 과제해결수단을 Read.26- **독립항 번호**(인용 문구 없는 항: 통상 방법/시스템/프로그램 3건)와 **핵심 구성요소**를27 목록화한다. 핵심 구성요소는 이후 문헌 선정의 커버리지 기준이 된다.28- 특징적 종속항(차별화 포인트가 되는 항)도 2~3개 뽑아둔다.2930### 2단계: 선행특허 4건 검색·검증 (WebSearch + WebFetch)3132- WebSearch로 `patents.google.com`을 대상으로 검색한다. 검색어는 핵심 구성요소별로33 국문/영문/중문을 섞어 여러 번 fan-out (예: "볼트 체결 딥러닝 검사 patents.google.com",34 "\"bolt loosening\" detection deep learning patent KR").35- **선정 원칙**:36 - 총 4건. 각 문헌이 서로 다른 핵심 구성요소를 커버하도록 분산 배치37 (예: 센서 측정 / AI 판정 / 설계 대비 비교 / 개별 요소기술).38 - 국가 혼합 권장 (예: 중국 공개 1건 + 한국 등록/공개 3건). 등록특허 우선.39 - 반드시 실존 특허여야 함 — 후보마다 `patents.google.com/patent/{번호}/{ko|en}`을40 WebFetch로 열어 서지사항(명칭·출원인·공개/공고일·청구항 1·법적상태)과41 **patentimages PDF 링크**를 확인한다. 검증 안 되면 교체.42- 각 문헌에 대해 대비 청구항 매핑을 정한다 (독립항 중심, 종속항 보강).4344### 3단계: PDF 다운로드4546```bash47curl -sL -o "선행특허 N_{cc}{번호}{종별}.pdf" "https://patentimages.storage.googleapis.com/..."48```4950- 파일명 규칙: 한국 등록 `kr2292602b1` (등록번호 7자리+종별, "10-" 접두 제거),51 한국 공개 `kr20180131471a`, 중국 `cn118654725a`. 영문 번역본이면 `_en` 접미.52- 다운로드 후 각 PDF의 페이지 수를 검증한다 (1~2페이지면 다운로드 실패 의심):5354```bash55python -c "import re; d=open('파일.pdf','rb').read(); print(len(re.findall(rb'/Type\s*/Page[^s]', d)))"56```5758### 4단계: 조사 md 작성5960파일명: `[{REF}]선행기술조사_{발명의 명칭}.md`. 구성 (KIPO 우선심사 자체조사 양식 준용):6162```markdown63# [{REF}] 선행기술 조사 — {발명의 명칭}64대상 출원: ... (독립항: 청구항 X(방법), Y(시스템), Z(프로그램))6566【검색결과】671. 중국 공개특허 제XXXXXXXXX호 (YYYY.MM.DD. 공개) ← 공개특허는 "공개", 등록특허는 "공고"682. 한국 등록특허 제10-XXXXXXX호 (YYYY.MM.DD. 공고)69...70* 문헌 서지 정보: 번호/명칭/출원인/첨부 PDF 파일명7172【선행기술과의 대비설명】73| 청구항 | 선행기술 문헌명 | 유사점 | 차이점 | 대비 판단 | ← 문헌별 1행, 총 4행7475## 종합 의견 (어느 문헌에도 개시되지 않은 본원 통합 구성 정리)76```7778- **유사점**: "문헌 N은 ~한다는 점에서, 청구항 X 및 Y와 유사점이 있음" 정형.79- **차이점**: "청구항 X 발명은 **{본원 핵심 구조}**인 반면에, / 문헌 N은 **{문헌 방식}**임"80 2문단 정형. 강조 부분이 hwpx에서 밑줄·볼드 처리되는 부분이다.81- **대비 판단**: "문헌 N에는 ~에 대응되는 구성이 개시되어 있지 않음" 정형.8283### 5단계: hwpx 빌드8485```bash86python scripts/build_hwpx.py <config.json>87```8889- config 스키마는 `references/config_example.json` (실전 예시) 참조. md 4단계에서90 작성한 문안을 그대로 config의 rows/results에 옮긴다.91- 템플릿: 사용자가 제공한 기존 우선심사신청설명서 hwpx가 있으면 그것을,92 없으면 `assets/template_우선심사신청설명서.hwpx`를 사용.93 템플릿은 [1~4p: 기존 건 예시] + [5~8p: 복제본] 구조여야 하며, 스크립트는94 **후반부(마지막 출현)만** 교체한다. 위치는 마커 텍스트로 동적 탐색하므로95 같은 구조의 다른 템플릿에도 그대로 작동한다.96- 교체 항목: 【검색어】, 【검색IPC】, 【검색결과】 4항목, 대비표 데이터 4행97 (밑줄·강조 charPr 자동 승계), 신청이유 1번 문단.98- **플레이스홀더 규칙** (사용자 확정 관행):99 - 출원번호: `제10-{연도}-0000000호` (0 채움)100 - 출원일: `{연도}년 월 일` — **월·일은 공란으로 남긴다** (임의 날짜 기입 금지)101 - 신청이유 2~4번 문단(출원인·법적 근거)은 출원인이 같으면 손대지 않는다.102- 출력 파일명: **`[OUR_REF]우선심사신청설명서.hwpx` 고정** (리터럴 그대로,103 REF 치환하지 않음 — 사용자가 결재 시스템 관행에 맞춰 직접 관리).104- **앞 예시 페이지 자동 삭제**: `drop_example`(기본 true)이면 빌더가 앞부분105 참조용 예시 건(1~4p)을 스크립트로 제거하여 최종본을 실제 기입 복사본(4페이지106 이내)만 남긴다. 문서 구역 설정(secPr)·단 설정(colPr)은 최초 문단 첫 run에만107 있으므로 삭제 전에 새 첫 문단으로 자동 이동시킨다(이걸 안 하면 문서가 깨짐).108 예시를 남기고 싶으면 config에 `"drop_example": false`.109- **페이지 수는 반드시 4페이지 이내**. 대비설명 문안이 길면 표가 페이지를 넘겨110 5~6페이지가 되므로, `table_font_height`(1/100 pt, 표 데이터 셀 charPr 17·18)로111 표 글자를 줄인다. **기본 900(9pt) 권장** — 템플릿 원본은 1100(11pt)이고 이 값이면112 대개 6페이지가 나온다. 검증된 실측(PU26131KR 피로 예측 건): 1100→6p, 1000→4p,113 900/850→4p. 안전마진을 위해 900 사용.114- 빌드 후 검증:115 - `leading example dropped: True` 로그 + 재파싱 OK 확인.116 - **실제 페이지 수 측정** (한컴오피스 설치 시): `python scripts/measure_pages.py <출력.hwpx>`117 → COM으로 `PageCount`를 읽는다. pageBreak 개수 추정은 표가 넘칠 때 틀리므로118 이 도구가 최종 판정. 4를 초과하면 `table_font_height`를 850, 800으로 낮춰119 재빌드·재측정하여 4 이하로 수렴시킨다.120 - 남은 문단 텍스트 덤프로 기입 내용 육안 확인.121122### 6단계: 보고123124- 산출물 목록, 문헌 4건 표(번호/일자/내용/대비 청구항), 대비 논리 요지 보고.125- **반드시 플래그**: 출원번호·출원일 공란(수기 기입 필요), 대비설명 문안은 결재 전126 변리사 검토 필요, hwpx는 한글에서 열어 표 레이아웃·페이지 수(4p 이내) 확인 권장.127- 최종본은 앞 예시 페이지가 빌더에 의해 자동 삭제되어 실제 기입 복사본만 남는다128 (4페이지 이내). 대비표 분량이 많으면 한글에서 미세조정이 필요할 수 있다.129130## 주의사항131132- hwpx XML 조작 시: ET.register_namespace로 원본 프리픽스 보존, 직렬화 후 루트133 시작 태그를 원본(전체 xmlns 선언)으로 되돌리고, mimetype 엔트리는 ZIP_STORED 유지.134- linesegarray는 교체 문단에서 제거 (한글이 열 때 재계산).135- WebSearch 결과의 특허번호·일자는 반드시 WebFetch로 재검증 후 사용 (환각 방지).136- 이 스킬은 조사 보고서 생성용이며, 진보성 판단의 법적 자문이 아니다.137138## 누적 학습 항목139140- (2026-07-09, PU26122KR 모듈러 접합부 건) 출원일을 오늘 날짜로 임의 기입했더니141 사용자가 "2026년 월 일" 공란으로 수정함 → 이후 출원일은 항상 월·일 공란으로 생성.142- (2026-07-09) 출력 파일명은 케이스 REF로 치환하지 말고 리터럴143 "[OUR_REF]우선심사신청설명서.hwpx" 그대로 사용 (사용자 확정).144- (2026-07-09) 공개특허 인용 시 일자 뒤 표기는 "공개", 등록특허는 "공고"로 구분145 (참고 샘플은 전부 "공고"였으나 정확 표기 우선).146- (2026-07-09, PU26131KR 피로 예측 건) 최종 출력본에는 앞 참조용 예시 페이지가147 없어야 하고 4페이지를 넘기지 말 것 → 빌더에 `drop_leading_example` 추가하여148 기본 자동 삭제하도록 함. secPr/colPr을 새 첫 문단으로 옮긴 뒤 앞 문단 제거하는149 방식이라 문서가 깨지지 않음(이전엔 사용자가 수동 삭제했음).150- (2026-07-09) 후보 특허가 공개 상태로 검색돼도 등록되었으면(KR10-XXXXXXXB1 존재)151 등록번호·등록공고일로 표기하고 등록공보 PDF를 받는 것이 정확. Google Patents의152 등록번호 페이지를 WebFetch하면 등록공고일과 등록공보 PDF 링크를 얻을 수 있음.153- (2026-07-09, PU26131KR) drop_example만으로 4페이지라 추정했으나 실제로는 6페이지였음154 (표가 페이지를 넘김). pageBreak 개수 추정은 신뢰 불가 → `measure_pages.py`(한컴 COM)로155 실측이 필수. 표 폰트 `table_font_height=900`으로 낮춰 4페이지로 수렴시킴. 이후156 기본값으로 900 채택하고, 초과 시 850/800으로 재조정.157- (2026-07-09) build_hwpx.py의 zip 쓰기에서 원본 ZipInfo 객체를 writestr에 재사용하면158 header_offset이 남아 파이썬 zipfile 재읽기 시 "Overlapped entries" 에러 → 파일명159 문자열 + compress_type로 쓰도록 수정(한/글은 열렸으나 후처리 스크립트가 깨졌었음).
lsj4232