AI 요약

  • 이 글은 플랫폼 스타트업 특허에서 경쟁사 침해를 제대로 주장하려면 단일 주체 실시 원칙을 전제로 청구항을 설계해야 한다는 점을 짚는다.
  • 사용자 단말 동작과 서버 동작이 하나의 청구항에 함께 들어가면 경쟁업체 한 곳이 전 구성을 직접 실시했다고 보기 어려워져, 혼합형 시스템 청구항은 침해 입증 리스크가 커진다.
  • ZUZU는 플랫폼 스타트업이 명세서를 검토할 때 주어가 한 운영 주체로 끝까지 통일되는지, 시스템 청구항만 등록돼 있지는 않은지, 침해 타깃을 서버 운영자와 단말 소유자 중 누구로 잡을지 점검할 기준을 정리한다.

플랫폼 기업의 특허에서 자주 생기는 문제가 있습니다. 특허 등록까지 마쳤지만, 막상 경쟁업체와 분쟁이 발생하면 경쟁업체의 침해 행위를 청구항에 정확히 대응시키기 어려운 경우입니다.

문제는 청구항의 주어에서 시작되는 경우가 많습니다. 플랫폼 서비스는 보통 사용자 단말과 서버가 함께 움직입니다. 그래서 특허 청구항에도 사용자 단말의 동작과 서버의 동작이 함께 들어가곤 합니다. 하지만 사용자 단말을 사용하는 주체는 일반 소비자이고, 서버를 운영하는 주체는 경쟁업체입니다.

이렇게 하나의 청구항 안에 여러 주체의 동작이 섞이면, 경쟁업체 한 곳이 청구항의 모든 구성을 실시했다고 보기 어려워질 수 있습니다. 이 경우 특허권자는 경쟁업체가 청구항 전체를 실시했다는 점을 설명해야 하므로 침해 주장이 불필요하게 복잡해집니다.

이번 글에서는 플랫폼 스타트업이 특허를 받을 때 반드시 점검해야 하는 단일 주체 실시 원칙을 정리해 보겠습니다.

1. 다 잡으려다 아무도 못 잡는 단일 주체 실시 원칙

특허 침해가 성립하려면 아주 중요한 대전제가 있습니다. 바로 하나의 침해 주체가 특허 청구항에 적힌 모든 구성요소를 직접 실시해야 한다는 점입니다.

참고

단일 주체 실시 원칙이란, 청구항에 A, B, C 세 가지 기술 구성이 적혀 있을 때 침해를 주장당하는 상대방이 A, B, C를 모두 빠짐없이 직접 수행해야만 비로소 침해가 성립한다는 특허법상의 원칙입니다.

너무나 당연한 이야기 같지만 플랫폼 기업의 특허에서는 이 원칙이 발목을 잡는 덫이 됩니다. 플랫폼의 본질 자체가 공급자(서버)와 수요자(사용자)가 상호작용하는 구조이기 때문입니다.

2. 치명적 오류의 전형: 사용자 단말 + 서버 형태의 청구항

플랫폼 기업의 특허를 검토하다 보면, 청구항이 아래와 같이 작성된 경우를 자주 봅니다.

참고

“~ 정보를 전송하는 사용자 단말; 및 사용자 단말로부터 ~ 정보를 수신하고 ~하는 서버;를 포함하는 시스템”

언뜻 보면 이상이 없어 보입니다. 플랫폼이 원래 단말과 서버가 함께 돌아가는 구조라 시스템 청구항으로 작성한 것이기 때문입니다.

하지만 이 특허로 실제 누구를 잡고 싶은지 떠올려 보면 문제가 보입니다. 특허권자인 스타트업이 침해를 주장하고 싶은 상대는 서버를 운영하는 경쟁업체일 것입니다. 그런데 청구항에서 사용자 단말을 직접 운영하는 주체는 경쟁업체가 아니라 일반 소비자입니다.

결국 이 청구항은 경쟁업체(서버)와 일반 소비자(단말)가 함께 수행해야 모든 구성이 실시되는 구조입니다. 경쟁업체 혼자서는 청구항 전체를 실시하지 않는 상태가 됩니다. 단일 주체 실시 원칙에 따라 침해 성립이 어려워집니다.

물론 특허의 활용처가 경쟁업체 저지에만 있는 것은 아닙니다. IP 담보 대출, NEP·NET·벤처기업 인증, 정부 사업 가점 등 다양한 활용이 가능합니다. 다만 이런 청구항은 침해 입증이라는 핵심 권리 행사 측면에서 실효성이 떨어집니다.

3. 정밀 타격을 위한 해결책: 주어를 분리하고 통일하라

그렇다면 어떻게 작성해야 경쟁사를 제대로 묶어둘 수 있을까요? 핵심은 청구항을 하나의 운영 주체(또는 하나의 하드웨어) 관점으로 분리해 서술하는 것입니다. 앞선 사례라면 이렇게 쪼개는 편이 훨씬 강력합니다.

참고

“~ 정보를 수신하는 동작; 및 수신된 ~ 정보를 ~하는 동작;을 포함하는 서버의 동작 방법.”

이렇게 주어를 통일하면 서버를 운영하는 경쟁업체 한 곳이 청구항의 모든 동작을 직접 수행하게 됩니다. 단일 주체 실시 원칙이 충족되어 권리 행사 가능성이 높아집니다.

여기서 한 발 더 나아간 전략도 있습니다. 동일 기술을 서버 동작 방법 청구항과 사용자 단말 동작 방법 청구항 두 갈래로 나누어 확보하는 방식입니다. 훗날 침해 주체가 서버가 될지 단말이 될지 비즈니스 환경에 따라 달라질 수 있기 때문입니다.

4. 대표님이 당장 명세서에서 점검해야 할 3가지 포인트

플랫폼 비즈니스를 하고 있다면 지금 보유한 특허 명세서나 출원서를 꺼내 아래 세 가지를 점검해 보세요.

  • 처음부터 끝까지 읽었을 때 주어가 서버라면 수신·분석·저장 등 서버 동작으로만 채워져 있는지 확인합니다. 주어가 중간에 서버와 단말 사이를 오가면 수정이 필요합니다.
  • 사용자 단말 + 서버 형태의 시스템 청구항만 등록돼 있다면 실전 분쟁에서 무용지물이 될 가능성이 큽니다.
  • 특허의 침해 타깃이 서버 운영자인지 단말 소유자인지 출원 단계에서 명확히 합의되어야 합니다.

잠깐!

분할출원이나 별도 출원을 통해 서버 동작과 단말 동작 청구항을 추가로 확보하는 전략이 필요합니다.

특허는 쓰임새가 정해진 도구입니다. 우리가 멱살을 쥐고 싶은 주체가 서버 운영자인지 단말 소유자인지, 출원 단계부터 변리사와 명확히 합의해야 총알이 빗나가지 않습니다.

단일 주체 실시 원칙을 설명하는 웹툰 이미지
플랫폼 특허는 청구항 주어를 하나로 통일해야 침해 입증 실효성을 높일 수 있습니다.

FAQ

Q. 이미 등록된 플랫폼 특허도 청구항 구조를 바꿀 수 있나요?

등록이 완료된 뒤에는 원칙적으로 권리 범위를 넓히는 방향의 수정이 어렵습니다. 다만 등록 전 출원 단계라면 보정이나 분할출원으로 청구항 전략을 조정할 여지가 있습니다.

이미 등록된 특허라면 현재 청구항으로 침해를 주장할 수 있는 상대가 누구인지 먼저 분석해야 합니다. 권리 행사가 어렵다고 판단되면 후속 출원으로 서버 동작 방법, 단말 동작 방법, 프로그램 또는 기록매체 청구항을 보완하는 전략을 검토할 수 있습니다.

Q. 복수 주체가 함께 실시한 경우에는 언제나 침해가 성립하지 않나요?

언제나 침해가 부정되는 것은 아닙니다. 복수 주체의 행위를 법적으로 하나의 주체에게 귀속할 수 있는지에 따라 침해 인정 여지가 논의됩니다.

다만 스타트업이 특허를 설계할 때 처음부터 복잡한 법리에 기대는 전략은 위험합니다. 분쟁 단계에서 복수 주체의 행위를 하나로 묶어 입증하는 일은 비용과 시간이 크게 듭니다. 출원 단계에서 최대한 한 주체의 행위만으로 침해가 성립하도록 청구항을 설계하는 편이 안전합니다.

참고

본 글은 ZUZU 콘텐츠 기고처인 ‘윌로특허법률사무소’에서 기고해주신 글입니다. 글을 읽고 특허 전략이나 AI 기술 보호와 관련해 궁금한 점이 생기신다면 링크를 통해 문의를 남겨주세요.
* 본 웹사이트는 코드박스를 소개하고 코드박스가 취급하는 서비스에 관한 일반적인 정보를 제공하기 위한 것일 뿐, 법률적 자문이나 해석을 위해 제공된 것이 아닙니다. 본 웹사이트에 게재된 내용과 관련하여 본 웹사이트의 접속자에게 발생할 수 있는 일체의 직ㆍ간접적 손해에 대하여 코드박스는 어떠한 법적 책임도 지지 아니하며, 본 웹사이트에 게재된 내용에만 기초하여 어떠한 행위를 하는 것은 법률적 위험을 수반할 수 있으므로, 본 웹사이트에 게재된 내용과 관련하여 어떠한 의문이 있을 경우에는 반드시 전문가에게 자문을 구하시기 바랍니다. 본 웹사이트에 게재된 내용들은 코드박스의 사전동의 없이 어떠한 형태로도 재생, 복사, 배포될 수 없음을 유의하시기 바랍니다.