소프트웨어 특허 명세서 작성 완전 가이드：방법-장치-기기-매체 4건 세트, Alice 테스트, AI 보조 생성
CNIPA.AI Team
기술 블로그
소프트웨어 방법 특허（IPC G06류）는 중국 발명특허 출원의 최대 품목으로 전체의 32% 이상을 차지한다. 그러나 소프트웨어 특허 명세서 작성에는 고유한 과제가 있다. 알고리즘이나 프로세스를 어떻게 특허법 요건을 충족하는 기술적 해결수단으로 '변환'할 것인가? 명세서에서 알고리즘 세부사항을 기술하면서 동시에 '지적 활동의 규칙'이라는 심사 함정을 어떻게 피할 것인가? 본 문서는 CNIPA 『특허심사지침』 제2부 제9장과 Alice/Mayo 테스트 프레임워크 및 실제 심사 실무를 기반으로 즉시 적용 가능한 작성 전략을 제공한다.
소프트웨어 특허의 보호객체：지적 활동 배제 회피의 기본 논리
4건 세트 구조를 논하기에 앞서, 소프트웨어 특허의 가장 핵심적인 생사선인 보호객체 적격성을 먼저 이해하여야 한다.
CNIPA 『특허심사지침』 제2부 제9장은 컴퓨터 프로그램에 관한 발명이 방법 또는 제품의 형태를 취할 수 있지만, 순수한 지적 활동의 규칙과 방법·수학적 개념 또는 수학적 규칙이어서는 안 된다고 규정한다.
보호객체 리스크 회피의 핵심 요건：청구범위는 전체로서 심사되어야 하며, 알고리즘 특징（추상적 정보 처리 논리）과 기술적 특징（구체적인 컴퓨터 처리 단계·데이터 형식·시스템 구성요소）사이에 기능적 상호작용 관계가 존재하여야 한다. 알고리즘 특징과 기술적 특징을 단순히 분리하여 기술적 특징 부분이 선행기술에 해당한다는 이유로 등록을 거절할 수 없다.
실무적 판단 기준：다음 유형의 청구범위는 일반적으로 보호객체 심사를 통과할 수 있다：
- 「특정 유형의 물리적 데이터（이미지/신호/센서 데이터）를 처리하기 위한 방법」——처리 대상이 기술적
- 「특정 물리적 기기（로봇/센서/산업제어시스템）를 제어하는 방법」——제어 대상이 기술적
- 「특정 기술적 수단（신경망 추론/특정 암호화 알고리즘/특정 데이터 구조 연산）으로 기술적 문제를 해결하는 방법」——기술적 수단이 구체적
다음 유형의 청구범위는 일반적으로 보호객체 리스크가 존재한다：
- 순수한 상업적 규칙 또는 수학적 알고리즘으로서, 단계 마지막에 「컴퓨터에서 실행」만을 부가한 것
- 신호나 데이터의 처리 과정 없이 순수하게 정보 내용 또는 데이터 의미만을 기술한 것
- 구체적인 정보 처리 기술 없이 순수한 인간-기계 인터페이스 설계만을 기술한 것
2025년 개정 CNIPA 심사지침은 AI 모델 구축/훈련 관련 발명에 대해 명세서 기재 요건을 신설하였다. 모델의 모듈·계층·연결 관계·훈련 단계 및 파라미터가 반드시 기재되어야 한다. 이는 AI/머신러닝 관련 소프트웨어 특허에 대한 중요한 신규 규정이다.
4건 세트의 완전한 구조：각 건별 작성 요점
제1건：방법 청구범위（핵심 보호 범위）
방법 청구범위는 4건 세트의 핵심으로, 특허청구범위(特許請求範圍) 중 일반적으로 가장 넓은 보호 범위를 가지며 특허 보호 범위의 주된 원천이다. 표준 형식：
특허청구범위 제1항
XXX 방법으로서,
이하의 단계를 포함하는 것을 특징으로 하는 방법：
S1：XXX 데이터를 취득/수신하는 단계；
S2：상기 XXX 데이터에 근거하여, YYY 알고리즘/모델을 통해 처리하여 ZZZ를 얻는 단계；
여기서, 상기 YYY 알고리즘은 구체적으로：……[구체적 기술 단계]를 포함하며；
S3：상기 ZZZ에 기반하여, WWW를 실행/출력/생성하는 단계.
작성 요점：단계 번호는 S1/S2/S3 또는 「단계 1, 단계 2」를 사용한다; 각 단계에서 입력·처리 논리·출력을 명확히 한다; 핵심 알고리즘 단계는 기능 기술에 그치지 않고 구체적인 기술적 수단 수준까지 세분화하여야 한다; 「지능적으로」「자동적으로」와 같은 모호한 부사를 피하여야 한다.
제2건：장치 청구범위（기능 모듈 매핑）
장치 청구범위는 방법 단계를 기능 모듈로 기계적으로 대응시키며, 각 모듈은 하나의 방법 단계에 대응한다：
특허청구범위 제2항
XXX 장치로서,
이하를 포함하는 것을 특징으로 하는 장치：
취득 모듈로서, XXX 데이터를 취득/수신하기 위한 취득 모듈；
처리 모듈로서, 상기 XXX 데이터에 근거하여 YYY 알고리즘으로 처리하여 ZZZ를 얻기 위한 처리 모듈；
실행 모듈로서, 상기 ZZZ에 기반하여 WWW를 실행/출력/생성하기 위한 실행 모듈.
작성 요점：모듈 명칭은 방법 단계에 대응한다（취득→취득 모듈, 처리→처리 모듈）; 각 모듈은 「~을 위한」으로 기능을 기술한다; 모듈 간 데이터 흐름은 기능 기술 내에 내재되어야 한다（「상기 취득 모듈이 취득한 XXX 데이터」）.
제3건：기기 청구범위（하드웨어 아키텍처 기술）
기기 청구범위는 소프트웨어를 탑재하는 컴퓨터 하드웨어 아키텍처를 보호한다：
특허청구범위 제3항
컴퓨터 기기로서,
이하를 포함하는 것을 특징으로 하는 기기：
메모리로서, 상기 메모리에는 컴퓨터 프로그램이 저장되는 메모리；
프로세서로서, 상기 프로세서는 상기 메모리에 접속되며,
상기 프로세서가 상기 컴퓨터 프로그램을 실행할 때, 이하의 단계를 실현하는 프로세서：
S1：XXX 데이터를 취득/수신하는 단계；
S2：……（방법 단계 반복）
제4건：저장매체 청구범위（CRM 청구범위）
저장매체 청구범위는 중국에서 「컴퓨터가독형저장매체（Computer Readable Medium, CRM）」라 불리며, CN 소프트웨어 특허의 표준 구성 요소다（미국에서는 CRM claims라 한다）：
특허청구범위 제4항
컴퓨터가독형저장매체로서,
상기 컴퓨터가독형저장매체에는 컴퓨터 프로그램이 저장되어 있고,
상기 컴퓨터 프로그램이 프로세서에 의해 실행될 때, 이하의 단계를 실현하는 것을 특징으로 하는 저장매체：
S1：……（방법 단계 반복）
저장매체 청구범위는 방법 청구범위의 단계를 원용함으로써 중복 기재를 피하는 동시에, 프로그램을 저장하는 물리적 매체를 독립적으로 보호한다.
종속청구범위의 전개 전략
독립청구범위는 가장 넓은 보호 범위를 커버하여야 하며, 종속청구범위는 「여기서」「구체적으로」「나아가」등의 한정어로 범위를 점차 좁히면서 독립청구범위를 지지한다（「청구범위가 명세서에 의해 뒷받침되지 않는다」는 거절 이유 회피）.
소프트웨어 특허 종속청구범위의 전형적인 전개 방향：
| 전개 방향 | 구체적 기재 예시 | 역할 |
|---|---|---|
| 핵심 알고리즘 단계 세분화 | 「여기서, 단계 S2의 상기 YYY 알고리즘은 구체적으로……를 포함한다」 | 구체적 기술적 수단 확보 |
| 입력 데이터 형식 한정 | 「여기서, 상기 XXX 데이터는 [구체적 형식/유형]이다」 | 청구범위 축소, 안정성 제고 |
| 모델 파라미터 한정 | 「여기서, 상기 신경망 모델은 [구체적 구조]이다」 | 구체적 실시 형태 보호 |
| 응용 시나리오 도입 | 「여기서, 상기 방법은 [구체적 시나리오]에 적용된다」 | 보호 포인트 확대 |
| 우선 실시 형태 추가 | 「여기서, 단계 S2는 또한……를 포함한다」 | 명세서 실시예 뒷받침 제공 |
표준 종속청구범위 수：CN 소프트웨어 특허는 23건의 독립청구범위（방법·장치·저장매체 커버）에 78건의 종속청구범위를 가산하여 총 9~11건으로 구성하고, 가장 일반적인 10건 추가 비용 임계치 이내로 유지하는 것이 권장된다.
미국 소프트웨어 특허의 Alice 테스트：중국 제25조와의 이동점과 공통점
미국 소프트웨어 특허가 직면하는 보호객체 적격성 도전은 35 USC 101 + Alice/Mayo 2단계 테스트다. Alice 테스트를 이해하는 것은 동일 발명의 CN-US 양방향 포트폴리오 구축에 있어 매우 중요하다.
Alice 2단계 테스트 프레임워크：
제1단계（Alice Step 1）：청구범위가 「추상적 개념」（수학적 개념·인간 활동 조직의 특정 방법·정신적 과정 포함）을 지향하는가？
제2단계（Alice Step 2A/B）：그렇다면, 주장하는 방안을 추상적 개념 자체를 현저히 초과하는 내용으로 전환하는 「발명적 개념（inventive concept）」이 존재하는가？ 2019년 USPTO 개정 심사지침은 이를 더욱 세분화하여 Step 2A Prong 1（실제 응용에 통합되었는가）과 Step 2A Prong 2（추상적 개념을 초과하는 실질적 내용을 제공하였는가）로 구분한다.
Alice 테스트 회피를 위한 작성 전략：
| 전략 | CN 기재 방법 | US 기재 방법 |
|---|---|---|
| 구체적 기술 효과 강조 | 「XXX 처리 효율을 향상시킨다」 | 「improves the technical functioning of a computer」 |
| 특정 컴퓨터 구현 한정 | 구체적 프로세서/메모리 상호작용 기술 | 「a specific machine or manufacture」 |
| 기능적 포괄 언어 회피 | 「임의의 XXX를 실현하기 위한 장치」 회피 | 「means for performing」 회피 |
| 구체적 데이터 변환 원용 | 구체적 데이터 형식 변환 기술 | 「transformation of data」 |
CN vs US의 핵심 차이：중국 특허법 제25조의 「지적 활동의 규칙」 배제 기준과 Alice 테스트의 「추상적 개념」 배제 기준은 논리적으로 유사하지만 실무적 세부사항이 다르다. CN은 알고리즘과 기술적 특징의 「기능적 상호작용」에 더 주목하고, US는 청구범위 전체가 「추상적 개념을 초과하는 발명적 개념」을 제공하는지에 더 주목한다. 동일 발명의 CN 및 US 출원은 일반적으로 독립청구범위의 기재 방식에서 맞춤형 조정이 필요하며, 완전히 동일하게 그대로 사용할 수 없다.
미국 소프트웨어 특허에는 CN에 없는 CRM（Computer Readable Medium）청구범위 형식이 있으며, 이는 US 특유의 저장매체 청구범위다. US의 CRM 청구범위와 CN의 저장매체 청구범위는 논리적으로 동등하지만 구체적인 기재 방식이 다르다.
소프트웨어 특허의 도면 전략：플로우차트 언어와 Mermaid
소프트웨어 특허의 도면은 플로우차트를 핵심으로 한다. CNIPA의 도면 형식 요건：흑백 선도·명확한 도면 부호（명세서와 일치）·문자 설명 불포함（도면 부호 및 필요한 기술 용어에 한정）.
표준 소프트웨어 특허의 핵심 도면 목록（10항의 청구범위를 갖는 특허 예시）：
| 도면 종류 | 내용 | 대응 청구범위 | 필요성 |
|---|---|---|---|
| 방법 플로우차트 | 주요 방법 단계의 실행 순서 | 방법 독립청구범위 | 필수 |
| 시스템 아키텍처도 | 전체 시스템 구조 | 전체 기술적 해결수단 | 필수 |
| 장치 구조 블록도 | 각 기능 모듈의 구성 | 장치 독립청구범위 | 필수 |
| 서브 플로우차트 | 핵심 단계의 상세 플로우 | 종속청구범위 | 권장 |
| 데이터 흐름도 | 시스템 내 데이터 흐름 | 데이터 처리 서브 단계 | 권장 |
| 시퀀스도 | 모듈 간 상호작용 순서 | 다중 컴포넌트 상호작용 시나리오 | 권장（다중 컴포넌트 시스템） |
| 모델 구조도 | 신경망/AI 모델 아키텍처 | AI 관련 종속청구범위 | 필수（AI류） |
Mermaid 언어는 소프트웨어 특허 도면 생성의 이상적인 도구다. Mermaid는 플로우차트（flowchart）·시퀀스도（sequenceDiagram）·상태도（stateDiagram）·클래스도（classDiagram）등 다양한 다이어그램 유형을 지원하며, 텍스트 설명에서 구조화된 도표를 자동으로 생성할 수 있어 AI 보조 생성 프로세스에 적합하다.
AI 이미지 생성（Stable Diffusion 등）은 구조화된 플로우차트가 아닌 UI 인터페이스 개요도에 적합하다. 플로우차트에서는 시각적 미려함보다 구조적 정확성（단계 순서·판단 분기）이 더 중요하므로 Mermaid가 더 적합하다.
AI 보조 소프트웨어 특허 생성 실전 프로세스
CNIPA.AI의 AI 작성 기능은 소프트웨어 방법 특허 분야의 특성에 맞게 최적화되었으며, CNIPA 심사지침 제9장과 실제 심사 실무 데이터를 기반으로 다음과 같은 자동화 프로세스를 구현한다：
제1단계：기술 요소 추출——AI가 기술 설명서의 알고리즘 핵심 단계·입출력 데이터 유형·핵심 기술적 특징 및 잠재적 보호객체 리스크 포인트를 식별한다. AI/머신러닝 기술이 포함된 발명의 경우, AI는 2025년 신규 심사지침이 기재를 요구하는 모델 유형·훈련 데이터·모델 구조 등의 정보를 특별히 추출한다.
제2단계：보호객체 적격성 사전 검토——청구범위 생성에 앞서, AI는 기술적 해결수단에 보호객체 리스크가 있는지 검토하고, 알고리즘과 기술 효과 사이의 기능적 상호작용 관계를 구축하기 위해 어떤 기술적 특징을 추가할지 제안한다.
제3단계：4건 세트 자동 생성——방법→장치→기기→저장매체의 순서로 4건의 청구범위를 자동 생성하고, 기술적 특징의 일일 대응 매핑을 확보하며, 3~5건의 종속청구범위를 자동으로 전개한다.
제4단계：도면 계획 및 생성——청구범위에서 식별된 단계·모듈·데이터 흐름에 기반하여 도면 목록（필수 유형+권장 유형）을 계획하고, Mermaid를 우선 사용하여 구조화된 플로우차트를 생성하며, UI류 도면은 AI 이미지 생성을 사용한다.
제5단계：명세서 전문 생성——기술분야·배경기술（효율성/정확도 부족 논거 논리）·발명의 내용（기술적 문제-기술적 해결수단-기술적 효과 3단 구성）·도면의 간단한 설명·발명의 구체적인 실시 형태（복수의 실시예 포함）의 5대 장을 포함한다.
| 공정 | 전통적 수작업（시간） | AI 보조（분） | 절감 |
|---|---|---|---|
| 기술 요소 추출·분석 | 1~2시간 | 5~10분 | ~90% |
| 4건 세트 청구범위 작성 | 2~4시간 | 10~15분 | ~92% |
| 종속청구범위 전개 | 1~2시간 | 5~10분 | ~90% |
| 도면 계획 및 작성 | 2~3시간 | 15~30분 | ~85% |
| 명세서 전문 작성 | 3~5시간 | 15~30분 | ~88% |
| 합계 | 9~16시간 | 50~95분 | ~88% |
AI 생성 초고는 내부 검토 버전（기업 출원인）또는 변리사 검수 원고（특허법인）로 직접 활용할 수 있다. 변리사의 업무 중심은 작성에서 검토로 전환된다. 즉, 기술 요소 추출이 정확한지·보호객체 리스크 포인트가 식별되었는지·청구범위의 보호 범위가 기업 전략에 부합하는지를 검토하는 것이다.
소프트웨어 특허의 빈발 거절 이유와 대응 전략
중국 소프트웨어 특허 심사에서 가장 흔한 4가지 거절 이유 및 대응 전략：
보호객체 문제（특허법 제25조 제1항 제2호）：지적 활동의 규칙과 방법으로 판정되는 경우. 대응：청구범위를 수정하여 구체적인 기술적 특징（입력되는 물리적 신호 유형·사용되는 구체적 알고리즘 모듈·출력되는 기술적 효과）을 추가한다; 알고리즘 특징과 기술적 특징 간의 기능적 상호작용 관계를 강조한다; 의견서를 통해 기술적 해결수단이 해결하는 기술적 문제와 달성되는 기술적 효과를 설명한다.
진보성 부족（특허법 제22조 제3항）：알고리즘 개선이 해당 기술 분야의 통상적 기술 수단으로 인정되는 경우. 대응：명세서에 성능 비교 데이터（처리 속도·정확도·자원 소비）를 제공하여, 알고리즘 개선이 비자명한 기술적 효과를 가져왔음을 데이터로 증명한다; 의견서에서 대비 문헌의 기술적 문제가 상이하거나 핵심 기술적 특징을 공개하지 않았음을 지적한다.
명세서 공개 불충분（특허법 제26조 제3항）：알고리즘 기술이 지나치게 추상적이고 구체적인 구현 세부사항이 부족한 경우. 대응：명세서에 의사 코드(pseudo code)·알고리즘 플로우의 상세 단계 기술을 보충한다; AI/머신러닝류의 경우, 모델의 계층 구조·훈련 데이터 유형·파라미터를 보충한다; 이 유형의 문제는 원시 출원 시 의견서로 해결할 수 없으므로 반드시 초고 단계에서 예방하여야 한다.
청구범위가 명세서에 의해 뒷받침되지 않음（특허법 제26조 제4항）：청구범위의 기능적 개괄 범위가 명세서에 기재된 구체적인 실시 형태를 초과하는 경우. 대응：초고 단계에서 각 종속청구범위에 대응하는 구체적인 실시예를 명세서에 준비한다; 독립청구범위의 상위 개괄은 명세서에 충분한 실시예의 뒷받침이 있는 것을 전제로 하여야 한다.
이 4가지 거절 이유에 대한 대응 전략을 숙달하고, AI 보조 초고 생성과 결합하는 것이 현대 소프트웨어 특허 실무의 표준 워크플로우다.