kr-patent-prior-art-report git:20261104.5dfc34dA

Immutable. This exact content never changes and is served at /api/v1/blob/035da6ce1ea05f69.

---
name: kr-patent-prior-art-report
description: 명세서와 확인된 선행문헌을 바탕으로 우선심사용 선행기술 조사 대비표와 HWPX 보고서를 작성한다. 검색식만 필요한 경우에는 사용하지 않는다.
---

# kr-patent-prior-art-report — 우선심사용 선행기술 조사 패키지 생성

## 입력 / 산출물

입력: 한국 특허 명세서 .docx (청구항 포함), 케이스 폴더 경로 (docx가 있는 폴더가 기본)

산출물 (모두 케이스 폴더에 저장):
1. `선행특허 1_{cc}{번호}{종별}.pdf` ~ `선행특허 4_...pdf` — 공보 원문 4건
2. `[{REF}]선행기술조사_{발명의 명칭}.md` — 조사 보고서
3. `[OUR_REF]우선심사신청설명서.hwpx` — 특허청 양식 설명서 (파일명 고정: 리터럴 "[OUR_REF]")

## 워크플로우

### 1단계: 명세서 파악

```bash
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 다운로드

```bash
curl -sL -o "선행특허 N_{cc}{번호}{종별}.pdf" "https://patentimages.storage.googleapis.com/..."
```

- 파일명 규칙: 한국 등록 `kr2292602b1` (등록번호 7자리+종별, "10-" 접두 제거),
  한국 공개 `kr20180131471a`, 중국 `cn118654725a`. 영문 번역본이면 `_en` 접미.
- 다운로드 후 각 PDF의 페이지 수를 검증한다 (1~2페이지면 다운로드 실패 의심):

```bash
python -c "import re; d=open('파일.pdf','rb').read(); print(len(re.findall(rb'/Type\s*/Page[^s]', d)))"
```

### 4단계: 조사 md 작성

파일명: `[{REF}]선행기술조사_{발명의 명칭}.md`. 구성 (KIPO 우선심사 자체조사 양식 준용):

```markdown
# [{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 빌드

```bash
python scripts/build_hwpx.py <config.json>
```

- config 스키마는 `references/config_example.json` (실전 예시) 참조. md 4단계에서
  작성한 문안을 그대로 config의 rows/results에 옮긴다.
- 템플릿: 사용자가 제공한 기존 우선심사신청설명서 hwpx가 있으면 그것을,
  없으면 `assets/template_우선심사신청설명서.hwpx`를 사용.
  템플릿은 [1~4p: 기존 건 예시] + [5~8p: 복제본] 구조여야 하며, 스크립트는
  **후반부(마지막 출현)만** 교체한다. 위치는 마커 텍스트로 동적 탐색하므로
  같은 구조의 다른 템플릿에도 그대로 작동한다.
- 교체 항목: 【검색어】, 【검색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로 쓰도록 수정(한/글은 열렸으나 후처리 스크립트가 깨졌었음).