앱·플랫폼 특허에서 가장 자주 마주치는 문제는 "내 발명을 어떻게 청구항으로 옮길 것인가"입니다. 모바일 앱이나 SaaS 플랫폼의 핵심 가치는 대부분 알고리즘과 데이터 흐름 인데, 이는 본질적으로 기능적("~을 수행한다")이고 구조적("~ 부재로 구성된다")이 아닙니다. 한국 KIPO 와 미국 USPTO 둘 다 기능식 청구를 인정하지만 명확성 판단 기준은 서로 다르고, 잘못 작성된 청구항은 실체 발명이 같아도 거절·무효 위험이 커집니다.
왜 앱 청구항이 어려운가
기계 발명은 "부재 A 와 부재 B 가 ~ 로 결합된 장치" 처럼 구조 청구로 그대로 쓸 수 있지만, 앱은 그 자체가 "~ 동작을 수행하는 코드" 입니다. 그래서 청구항이 자연스럽게 "~ 단계를 수행하는 시스템" 같은 기능식 표현이 되며, 한국 컴퓨터 관련 발명 심사기준 은 "하드웨어를 이용한 정보처리가 구체적으로 실현" 되어 있어야 발명이 인정된다고 명시합니다. 즉 기능만 나열하면 거절, 기능 + 그것을 수행하는 구조 가 함께 있어야 통과입니다.
기능식 vs 구조식 — 두 가지 청구 스타일
기능식은 "~ 하도록 구성된", "~ 을 수행하는" 같이 동작 결과를 중심으로 청구합니다. 권리범위는 넓지만 명세서가 약하면 명확성 거절을 받습니다. 구조식은 "제 1 모듈, 제 2 모듈, 통신부, 저장부" 같이 구체 구성요소를 명시합니다. 권리범위는 좁아질 수 있지만 명확성이 강해 등록 안정성이 좋습니다.
| 관점 | 기능식 (Functional) | 구조식 (Structural) |
|---|---|---|
| 청구 표현 | "~ 을 수행하도록 구성된 시스템" | "제 1 모듈, 제 2 모듈을 포함하는 시스템" |
| 권리범위 | 넓음 (다양한 구현 포섭) | 좁음 (명시 구성요소 한정) |
| 명확성 위험 | 큼 ("단순 기능 나열" 거절) | 작음 |
| 진보성 입증 | 구체 알고리즘 명세 필요 | 구성요소 차이로 입증 용이 |
| 미국 §112(f) 적용 | means-plus-function 으로 해석 | 일반 구조 청구 |
| 한국 KIPO 명확성 | 통상의 기술자가 구체 물건 상정 가능해야 | 명시 구성요소로 판단 |
한국 KIPO — 기능식 청구의 명확성
KIPO 컴퓨터 관련 발명 심사기준은 기능식 청구항에 대해 "통상의 기술자가 출원시 기술상식을 고려하여 청구항에 기재된 물건을 특정하기 위한 사항으로부터 그 기능을 가진 구체적인 물건을 상정할 수 있는지" 로 명확성을 판단합니다. 즉 청구항이 "~ 을 수행하는" 으로 끝나도, 명세서에 그것을 어떻게 수행하는지 구체적 알고리즘·데이터 구조가 기재되어 있으면 명확성이 인정됩니다.
"단순 기능 나열"은 거절
"입력을 받아 적합한 결과를 출력하는 시스템" 처럼 추상적 동작만 나열한 청구항은 명확성 부족·발명 정의 미달로 거절됩니다. 입력의 형식·처리 단계·출력의 형식을 청구항 또는 적어도 명세서에 구체적으로 기재하는 것이 최소 요건입니다.
미국 §112(f) — means-plus-function
미국에서는 35 U.S.C. §112(f) 가 기능식 청구를 별도 규정으로 다룹니다. "~ means for" 또는 그에 상응하는 nonce word(예: "~ module", "~ unit") 가 사용되면 means-plus-function 으로 해석되어, 명세서에 해당 기능을 수행하는 구조 를 명시해야 합니다. 소프트웨어 발명에서 "구조" 는 컴퓨터 부품(프로세서·메모리)이 아니라 수행 알고리즘 그 자체 로 인정됩니다.
즉 미국 청구가 "a module configured to detect anomalies" 라면, 명세서에 "이상치 탐지를 위한 알고리즘은 다음 단계로 구성된다 ① ... ② ... ③ ..." 식으로 알고리즘 단계가 기재되어야 합니다. 알고리즘이 부재하거나 모호하면 §112(b) 부정형(indefiniteness) 으로 무효 위험이 높아집니다.
앱·플랫폼 특허 — 4가지 청구 패턴
- 시스템 청구: "적어도 하나의 프로세서와 메모리를 포함하는 ~ 시스템으로서, 상기 프로세서가 ~ 동작을 수행하도록 구성된 시스템"
- 방법 청구 (HW 명시): "적어도 하나의 프로세서에 의해 수행되는 방법으로서, 1) 입력을 수신, 2) 처리, 3) 출력 ~ 단계를 포함"
- 컴퓨터 프로그램·매체 청구: "컴퓨터로 하여금 ~ 을 수행하도록 하는 프로그램이 기록된 비일시적 기록매체"
- UI·인터랙션 청구: "제 1 입력에 응답하여 ~ 화면을 표시하고, 제 2 입력에 응답하여 ~ 데이터를 처리하는 사용자 인터페이스"
거절 회피 명세서 작성 — 5가지 팁
- 알고리즘 단계를 글머리표로 기재: 명세서에 "단계 1: ... 단계 2: ..." 식으로 구체 절차 풀어쓰기 — 미국 §112(f) 와 한국 명확성 모두 충족
- 입력·출력의 데이터 구조 명시: "JSON 형식의 ~ 객체", "~ 정수 배열" 등 구체 데이터 구조 — 권리범위 명확화
- 기술적 효과를 수치로: "응답 시간 50ms 단축", "메모리 30% 절약" 같은 수치 — 한국 진보성·미국 §101 "실용적 적용" 모두 도움
- 대안 실시예 다수 제공: 클라우드 구현·온디바이스 구현·하이브리드 구현 등 여러 시나리오를 명세서에 — 권리범위 확장 + 회피설계 차단
- 의료·금융 등 특수 분야 표현 분리: 진단·법률 등 산업 응용을 별도 청구로 분리해 한 청구가 거절돼도 다른 청구는 살아남게
한·미 동시 출원 시 — 청구 분리 권장
한국 KIPO 의 명확성 기준은 "통상의 기술자 상정 가능성" 인 반면 미국 §112(f) 는 "명세서 알고리즘 명시" 입니다. 한 명세서로 양국을 모두 노릴 때, 한국용은 기능식 + HW 결합 청구, 미국용은 means-plus-function 회피용 구조식 청구 로 두 세트를 분리해 작성하면 거절 위험이 가장 낮습니다.
자주 묻는 질문
기능식 청구로 권리를 넓히면 무효 위험도 커지나요?
그렇습니다. 권리범위가 넓으면 선행기술과의 거리도 좁아져 무효심판에서 깨질 가능성이 커집니다. 그래서 실무적으로는 독립항을 기능식으로 하고 종속항을 구조식으로 좁혀 두는 "피라미드 청구" 가 표준입니다. 독립항이 무효되어도 종속항이 살아남도록 방어 다층화하는 효과가 있습니다.
한국에서 "~ 모듈" 같은 표현은 안전한가요?
한국 KIPO 는 미국 §112(f) 같은 nonce-word 별도 규정이 없어 "~ 모듈" 자체로 부정형 거절을 받지는 않습니다. 다만 그 모듈이 무엇을 어떻게 하는지 명세서에 기재되어 있어야 합니다. 미국 진출 계획이 있다면 한국 청구도 "~ 모듈" 보다는 "프로세서, 메모리, ~ 부" 같이 더 구체적인 구성요소 표현으로 작성하는 것이 한 명세서로 양국을 다루기 좋습니다.
UI/UX 그 자체는 특허 대상이 되나요?
UI 의 시각적 외관 자체는 특허가 아니라 디자인 등록(화상디자인) 으로 보호됩니다. 다만 UI 의 상호작용 로직 — 예를 들어 "~ 제스처를 감지해 ~ 화면 변경을 트리거" — 은 청구항 형태로 청구하면 특허 대상이 됩니다. 시각적 차별성 + 상호작용 로직 둘 다 보호하려면 디자인 + 특허 동시 출원이 합리적입니다.