BM특허의 기술적 구성과 거절이유 점검
BM 발명은 사업 규칙이 새롭다는 사실만으로 등록되는 것이 아닙니다. 컴퓨터·네트워크에서 구체적으로 구현되는 정보처리와 선행기술과 구별되는 기술적 구성이 청구항과 명세서에 나타나야 합니다.
순수한 사업 규칙
구매에 따라 포인트를 부여하고 등급별 혜택을 제공한다는 내용은 사업 규칙을 설명합니다. 특허 명세서에는 거래 검증, 계정 식별, 포인트 원장, 중복 적립 방지와 등급 갱신이 서버와 데이터베이스에서 어떻게 수행되는지 기재해야 합니다.
통상적인 전산화
사람이 수행하던 예약, 쿠폰, 정산 또는 매칭을 일반적인 서버로 옮긴 것만으로는 진보성을 인정받기 어려울 수 있습니다. 데이터 동기화, 부정거래 검출, 권한 통제, 장애 복구 또는 부하 분산과 같이 기존 방식과 구별되는 처리 관계를 확인합니다.
형식적인 서버 구성
서버가 단말에서 정보를 수신해 데이터베이스에 저장하고 결과를 전송한다는 구성은 대부분의 플랫폼에 공통됩니다. 저장하는 데이터 구조, 연산 조건, 갱신 시점과 예외 처리를 구체적으로 기재합니다.
AI 기능의 기재 부족
“AI가 추천하거나 위험도를 산출한다”는 기능만 기재하면 입력과 출력의 관계를 확인하기 어렵습니다. 학습·추론 데이터, 전처리, 특징값, 출력값, 후처리와 서비스 반영 조건을 설명합니다.
효과의 구분
매출 증가, 거래 활성화와 사용자 만족은 사업상 효과입니다. 특허 명세서에서는 서버 부하, 검증 속도, 부정거래 탐지, 네트워크 전송량, 인증 보안, 오류율과 처리 지연의 변화를 구체적 구성과 연결합니다.
기술문서로의 전환
서비스 기획서와 IR 자료에는 시장 문제, 고객 편익과 수익모델이 중심이 됩니다. 특허 명세서에는 시스템 구성, 데이터 흐름, 판단 조건, 예외 처리, 실시예와 기술적 효과가 필요합니다.
| 기획 자료 | 명세서에서 추가할 내용 |
|---|---|
| 서비스 흐름 | 장치별 입력·처리·출력과 메시지 |
| 고객 편익 | 기술적 문제와 측정 가능한 효과 |
| AI 추천 | 데이터, 모델 입력·출력과 후처리 |
| 정산 규칙 | 원장 구조, 검증과 오류 복구 |
| 플랫폼 구성 | 테넌트·권한·API·데이터 격리 |
출원 전 점검사항
- 사업 규칙과 기술적 처리 방식을 구분합니다.
- 기존 서비스의 단순 자동화인지 확인합니다.
- 데이터 구조, 조건과 예외 처리를 기재합니다.
- 기술적 효과의 비교 조건을 정합니다.
- 실제 서비스 운영 주체에 맞춰 청구항을 구성합니다.
