플랫폼 특허, 앱만 있어도 될까? BM특허 등록 조건 정리

플랫폼 특허(BM특허)란 무엇인가요?

결론부터 말씀드리면, “새로운 영업방식”이라는 아이디어 자체는 특허 대상이 아닙니다. 그 방식이 컴퓨터·인터넷 등 정보통신기술로 구체적으로 구현되어 있어야 합니다.

BM(Business Method)특허는 영업방법이나 사업 아이디어를 정보통신기술을 이용해 구현한 새로운 비즈니스 시스템 또는 방법을 말합니다. BM이라는 용어는 Business Model과 Business Method가 혼용되어 쓰이지만, 국내 특허법이 발명을 물건과 방법으로 구분하고 있기 때문에 방법 발명으로서의 Business Method가 더 정확한 표현입니다.

그래서 “플랫폼 특허”라는 표현을 쓰더라도, 실제 심사 단계에서는 앱이나 웹서비스 자체가 아니라 그 안에서 정보가 처리되는 방식, 즉 소프트웨어 구조가 심사 대상이 됩니다.

순수 아이디어·영업방식만으로는 등록되지 않는 이유

기존에 없던 새로운 영업방법이라 해도, 그 자체만으로는 특허로 등록받을 수 없습니다.

컴퓨터상에서 소프트웨어에 의한 정보처리가 하드웨어를 이용해 구체적으로 실현되어야 발명으로 성립합니다. 예를 들어 “포인트를 이렇게 적립해주면 좋겠다”는 사업 구상만으로는 부족하고, 그 적립 로직이 서버와 단말 간에 어떤 데이터를 주고받으며 처리되는지까지 명세서에 구체적으로 담겨야 합니다.

상담을 하다 보면 “사업계획서에 이미 다 적어놨는데 왜 특허가 안 되냐”고 묻는 경우가 종종 있습니다. 또 “투자자한테 설명한 자료 그대로 내면 되지 않느냐”는 질문도 자주 받습니다.

지금 준비 중인 서비스가 이 기준에 해당하는지 궁금하시다면, 초기 아이디어 단계에서부터 점검받아보시는 것을 권해드립니다.

무료 상담 신청하기

우리 서비스가 특허 대상이 되는지 판단하는 기준

결론부터 말씀드리면, 앱만 있어도 됩니다. 다만 그 앱 안에서 일어나는 정보처리 과정이 구체적이어야 합니다.

발명의 성립성을 판단할 때 가장 먼저 보는 것은 기술적 수단과의 결합 여부입니다. 다음 중 하나에 해당하면 성립성이 부정될 가능성이 높습니다.

• 기술적 수단과 결합 없이 순수한 영업방법만 청구한 경우
• 온라인이 아닌 오프라인 행위를 그대로 출원 대상으로 청구한 경우
• 청구항의 발명 주체나 구성이 불명확한 경우

앱만 있어도 되는 경우 vs 서버·시스템 구성이 필요한 경우

단말(앱)에서 동작이 완결되는 구조라면 앱 단독 청구항으로도 충분할 수 있습니다.

정보가 서버로 전송되어 처리된 뒤 다시 단말로 돌아오는 구조라면, 서버와 단말의 역할을 나누어 청구항을 설계하는 것이 유리합니다. 이 구조는 나중에 침해 대응 시 “누구를 상대로 권리를 주장할 것인가”와 직결됩니다. 그래서 처음부터 서버·단말 역할을 나눠 설계해두는 것이 좋습니다.

BM특허 등록이 어렵다는 게 사실인가요?

결론부터 말씀드리면, 일반 발명보다 등록 문턱이 높은 편인 것은 사실입니다. 다만 이유를 정확히 알면 대비할 수 있습니다.

BM 발명은 형체가 없는 영업방식을 다루기 때문에, 심사관이 “이것이 진짜 기술적 사상인지, 단순한 아이디어인지”를 더 엄격하게 따지는 경향이 있습니다. 특허청은 BM 분야 출원·등록을 별도 통계로 관리합니다. 그만큼 일반 발명과는 다른 기준으로 심사한다는 뜻입니다.

실무에서 자주 나오는 거절 사유는 크게 두 가지입니다.

1. 기존 오프라인 영업방식을 온라인으로 단순히 옮겨온 경우 (진보성 부족)
2. 청구항에 기술적 구성이 충분히 뒷받침되지 않은 경우 (기재불비)

실제 거절이유 통지(OA) 후 대응 흐름

거절이유를 받았다고 사업을 접을 필요는 없습니다. 이런 유형의 사건은 보통 다음 순서로 흘러갑니다.

다만 이 과정에서 권리범위가 좁아질 수 있기 때문에, 처음부터 여유 있는 청구항 구조로 설계해두는 것이 재작업을 줄이는 방법입니다.

등록 가능성을 높이려면 청구항을 어떻게 써야 하나요?

결론부터 말씀드리면, 다양한 실시예와 구체적인 기술 구성을 함께 담는 것이 핵심입니다.

등록 가능성이 높은 BM특허들의 공통점은 기술성 입증이 철저하다는 점입니다. “구독 서비스를 운영한다”는 서술이 아니라, “사용자 요청이 클라이언트에서 서버로 전송되고, 알고리즘 단계별 연산을 거쳐 결제 결과가 자동 처리된다”처럼 컴퓨터 구현 구조를 구체적으로 풀어써야 합니다.

이런 접근은 새로운 것이 아닙니다. 오래전 프라이스라인의 “역경매” 특허나 아마존의 “원클릭 결제” 특허도, 단순한 사업 아이디어가 아니라 결제 식별수단이 서버에 입력되고 처리되는 과정을 구체적인 기술 구성으로 풀어써 등록까지 이어진 사례입니다. 지금 국내 플랫폼 출원에서도 같은 원리가 적용됩니다.

출원 전 선행기술조사를 통해 유사 특허 존재 여부를 확인하고, 겹치는 부분이 있다면 회피설계를 거치는 과정도 필요합니다.

실제 상담에서 자주 발견되는 청구항 설계 실수

가장 자주 보는 실수는 청구항 하나에 모든 것을 다 담으려는 경우입니다.

핵심 로직 하나만 넓게 청구하고, 부가 기능은 종속항으로 단계별로 배치하는 편이 거절 리스크를 낮추면서도 권리범위를 지키는 데 유리합니다. 실제로 이런 구조로 들어온 사건은 종속항을 재배치하고 핵심 청구항의 표현만 다듬는 것으로 거절이유가 해소되는 경우가 많습니다. 반대로 처음부터 너무 좁게 청구항을 잡으면 등록은 쉬워져도 나중에 권리 행사가 어려워지는 경우가 있어, 이 균형을 잡는 것이 실무에서 가장 중요한 부분입니다.

등록만으로 끝일까요?

등록은 끝이 아니라 시작입니다.

플랫폼은 서버 운영자와 사용자(단말)가 역할을 나눠 맡는 구조라서, 침해가 발생했을 때 “이 청구항으로 서버 운영자와 단말 사용자 중 누구를 상대로 권리를 행사할 수 있는가”가 애매해지는 경우가 유독 많습니다. 청구항 주어를 처음부터 하나로 통일해두지 않으면, 등록 후에는 권리범위를 넓히는 방향의 수정이 어려워 실제로 권리를 행사하기 힘들어질 수 있습니다.

이 부분은 청구항 설계 단계에서부터 미리 고려해야 하는 별도의 전문 영역으로, 관련 내용은 플랫폼 특허 청구항, 서버냐 단말이냐 글에서 더 자세히 다루고 있습니다.

비용과 기간은 어떻게 예상해야 하나요?

결론부터 말씀드리면, 출원 절차 자체는 일반 특허와 동일하지만, 심사 대응 단계가 추가될 가능성을 감안해야 합니다.

단계	내용	비고
출원	명세서·청구항 작성 후 출원	관납료 별도
심사 청구	출원 후 심사청구 진행	우선심사 대상 여부 확인 필요
심사 대응	거절이유(OA) 발생 시 보정·의견서 제출	BM 분야는 대응 단계가 추가되는 경우가 상대적으로 많음
등록	등록결정 후 등록료 납부	—

정확한 비용과 기간은 청구항 개수, 심사 대응 횟수에 따라 달라지기 때문에, 지금 준비 중인 아이디어를 바탕으로 상담을 통해 예상 범위를 확인해보시는 것을 권해드립니다.

무료 상담 신청하기

자주 묻는 질문

지금 준비 중인 서비스의 특허 가능성이 궁금하시다면, 구조를 먼저 정리해드리겠습니다.

지금 상담 신청하기