변리사 해설] SaaS 비즈니스의 특허 전략｜서버-클라이언트 간 통신 처리를 가장 강력한 권리로 만드는 방법

비즈니스의 주 무대가 패키지 소프트웨어에서 SaaS(Software as a Service)로 옮겨간 지 오래된 현재, 많은 스타트업이 구독 모델을 통한 사업 확장을 목표로 하고 있습니다. 하지만 SaaS는 그 기술적 특성상 ‘특허를 취득하기가 매우 어렵고 실패하기 쉽다’는 사실은 의외로 잘 알려져 있지 않습니다.

"획기적인 알고리즘을 개발했음에도 불구하고, 특허 침해로 경쟁사를 고소할 수 없었다"

"서버를 해외로 옮겼다는 이유만으로 특허권이 효력을 잃었다"

이러한 사태를 방지하기 위해서는 SaaS 특유의 아키텍처인 ‘서버’와 ‘클라이언트’의 관계를 법적으로 어떻게 정의할지에 대한 고도의 전략이 요구됩니다.

특히, 2025년(레이와 7년) 3월의 도완고 대 FC2 사건·대법원 판결로 인해 SaaS 특허 실무는 극적인 전환점을 맞이했습니다. 이 판결을 모르고 낡은 지식 그대로 출원하는 것은 너무나 위험합니다.

본 기사에서는 IT·소프트웨어 분야에 정통한 변리사의 관점에서, SaaS 비즈니스에서의 특허 전략의 핵심, 그리고 최신 판례를 반영한 ‘승리할 수 있는 권리화’ 노하우를 철저히 해설합니다.

1. 왜 SaaS 특허는 ‘일반 특허’와 다른가?

기존 제조업의 특허(예를 들어 ‘엔진’이나 ‘의자’)는 그 물건이 하나만 존재해도 완결되었습니다. 그러나 SaaS를 포함한 ‘네트워크형 시스템’의 발명은 물리적으로 떨어져 있는 여러 요소가 연계되어야 비로소 기능합니다.

여기서 가장 큰 문제가 되는 것이 특허법상의 ‘다주체(멀티 액터)의 장벽’입니다.

침해 주체가 분산되는 위험(전 구성요건 실시의 원칙)

특허권 침해를 성립시키기 위해서는 원칙적으로 ‘하나의 주체(경쟁사)’가 ‘특허청구범위(클레임)에 기재된 모든 구성요건’을 실시하고 있어야 합니다.

만약 여러분이 ‘서버와 클라이언트 단말로 구성된 채팅 시스템’을 아무 생각 없이 시스템 전체를 특허로 등록해 버린다면 어떻게 될까요?

・서버를 관리하는 것은 ‘경쟁사(SaaS 벤더)’입니다.

・클라이언트 단말기를 조작하는 것은 「일반 사용자(고객)」입니다.

이 경우, 경쟁사는 “저는 클라이언트 단말을 조작하지 않습니다(사용자가 제멋대로 하고 있습니다). 시스템 전체 중 절반만 실시하고 있으므로 특허 침해가 아닙니다”라고 반박하여, 침해가 성립되지 않을 위험이 있습니다.

이를 방지하려면, 발명을 적절히 구분하여 누가 무엇을 실시하고 있는지 명확히 한 ‘청구항 설계’가 필수적입니다.

2. 서버·클라이언트 간 통신의 「3가지 구분」 전략

SaaS 특허에서 가장 중요한 것은 ‘발명을 어떤 관점에서 도출할 것인가’입니다. 같은 기술이라 하더라도 다음 3가지 범주로 다층적으로 권리를 확보함으로써, 빠져나갈 틈이 없는 강력한 특허망을 구축할 수 있습니다.

전략 ①: 서버 측 청구항 (가장 중요한 핵심)

SaaS 벤더(경쟁사)를 직접 공략하기 위한 권리입니다. 발명의 구성 요소를 ‘서버가 수행하는 처리’로만 한정하여 기술합니다.

・나쁜 예(다중 주체):

"사용자가 단말기에서 요청을 전송하고, 서버가 이를 수신하여 처리한 후, 결과를 사용자 단말기에 표시하는 시스템."

(※ '표시한다'는 사용자 측의 동작이 포함되어 있습니다)

・좋은 예(단일 주체):

“단말기로부터의 요청을 수신하는 수신부와, 해당 요청에 기초하여 처리를 수행하는 제어부와, 표시용 데이터를 상기 단말기에 전송하는 전송부를 구비한 서버 장치.”

이처럼 주어를 ‘서버’로 통일하면, 사용자가 무엇을 하고 있든 간에 경쟁사가 해당 서버를 가동시킨 시점에서 침해(생산·사용 등)를 주장할 수 있습니다. SaaS 특허에서는 이것이 가장 기본적이면서도 강력한 권리가 됩니다.

전략 ②: 클라이언트 사이드 청구항 (앱 스토어 대상)

전용 앱이나 브라우저상에서 동작하는 JavaScript 처리에 특징이 있는 경우에 유효합니다.

여기서는 ‘프로그램’ 그 자체를 권리화합니다.

Apple Store나 Google Play에서 앱을 배포하고 있는 경쟁사를 배제하고 싶은 경우, ‘서버 특허’만으로는 플랫폼 사업자에게 설명하기 어려워 삭제 조치가 지연될 수 있습니다. 하지만 ‘앱 특허’를 보유하고 있다면, 배포 중인 앱 자체가 침해품이라고 간단히 주장할 수 있어 스토어 측에 대한 삭제 요청(테이크다운)을 원활하게 진행할 수 있습니다.

전략 ③: 시스템 청구항 (대·해외 서버)

과거에는 ‘다중 주체 침해의 위험이 있다’는 이유로 기피되곤 했던 ‘시스템 전체(서버+단말기)’에 대한 청구항이지만, 후술할 최신 판결에 따라 그 중요성이 재평가되고 있습니다.

특히 서버와 클라이언트가 밀접하게 연계되어 있고, 그 상호작용(프로토콜이나 통신 시퀀스)에야말로 발명의 본질이 있는 경우, 시스템 청구항은 매우 유효합니다.

3. 역사를 바꾼 ‘도완고 사건’ 대법원 판결(2025년 3월)

SaaS 비즈니스에서 오랫동안 가장 큰 우려 사항이었던 것은 ‘서버의 해외 설치(크로스보더)’ 문제입니다.

일본의 특허권은 ‘속지주의’라고 하여 일본 국내에서만 효력을 가집니다. 그 때문에 ‘AWS 리전을 미국으로 설정했으므로 일본 특허권은 미치지 않는다’는 ‘특허 회피’가 횡행할 우려가 있었습니다.

이 쟁점에 대해 완전히 결론을 내린 것이 2025년 3월 3일에 내려진 ‘도완고 대 FC2 사건’의 대법원 판결입니다.

'실질적으로 국내'라면 침해로 간주

대법원은 서버가 국외에 있더라도, 다음 요소를 종합적으로 고려하여 시스템을 구축하는 행위가 ‘실질적으로 일본 국내에서 이루어졌다고 평가할 수 있는’ 경우, 일본 특허권 침해(생산)에 해당한다고 판단했습니다.

1. 양도 등의 행위 양상: 일본 국내 사용자를 대상으로 서비스가 제공되고 있는가(일본어 표시, 일본 엔화 결제 등).

2. 효과 발생 장소: 해당 시스템 이용에 따른 효과가 일본 국내에서 나타나고 있는지(국내 사용자가 이용할 수 있는지).

이 획기적인 판결로 인해 SaaS 사업자는 ‘서버를 해외로 옮기는’ 단순한 회피책이 통하지 않게 되었습니다.

반대로 말하면, 일본에서 확실하게 특허를 취득해 두면, 해외 서버를 이용한 모방 서비스에 대해서도 금지명령이나 손해배상을 청구할 수 있다는 점이 대법원 수준에서 확정된 것입니다.

이 판결 이후, 굳이 ‘서버와 단말기를 포함한 시스템’으로 특허를 취득하고, ‘일본 국내의 사용자(단말기)를 포함하고 있으므로 국내에서의 실시이다’라고 주장하는 전략이 매우 유효한 선택지가 되었습니다.

4. ‘보이지 않는 내부 처리’를 어떻게 입증할 것인가?

아무리 훌륭한 특허를 취득하더라도, 경쟁사의 서비스가 그 특허를 사용하고 있다는 사실을 입증하지 못하면(발각되지 않으면) 의미가 없습니다. 이를 ‘침해 발견성(Detectability)’이라고 합니다.

SaaS의 백엔드 처리(AI 알고리즘이나 고속 계산 로직)는 블랙박스입니다. 서버 내에서 어떤 계산이 이루어지고 있는지 외부에서는 알 수 없습니다.

따라서 저는 고객사의 SaaS 특허를 담당할 때 반드시 다음 관점을 반영합니다.

입출력(I/O)으로 권리를 정의한다

내부 로직 그 자체가 아니라, ‘특정 입력에 대해 어떤 출력이 반환되는가’라는 인과관계를 포함하여 청구항을 구성합니다.

× 내부 처리만을 다룬 청구항:

“데이터 A에 대해 알고리즘 X를 사용하여 계수 계산을 수행하고, 메모리 B에 저장하는 처리.”

(※외부에서는 절대 볼 수 없기 때문에 침해 증거를 확보할 수 없음)

○ 입출력에 주목한 청구항:

"단말기로부터 데이터 A를 수신한 것에 응답하여, 특정 파라미터를 포함하는 데이터 B를 생성하고, 이를 단말기로 회신하는 처리."

이렇게 작성해 두면, 경쟁사의 API를 호출하여 응답(JSON 데이터 등)을 확인하는 것만으로도, “자, 이 파라미터가 반환되고 있다. 특허 침해다”라고 증거를 제시할 수 있습니다.

‘강력한 특허’란 기술적으로 수준이 높을 뿐만 아니라, ‘침해를 찾아내기 쉬운 특허’를 말합니다.

5. SaaS 스타트업의 지식재산 로드맵

SaaS 비즈니스는 속도가 생명입니다. 개발 단계에 맞춰 적절한 시기에 특허 출원을 진행해야 합니다.

1단계: MVP 개발 ~ 출시 직전(PMF 전)

이 단계가 가장 중요한 승부처입니다.

특허에는 ‘신규성’이 필요합니다. 베타 버전이라 하더라도 일단 세상에 공개해 버리면 원칙적으로 특허를 받을 수 없게 됩니다(신규성 상실).

반드시 ‘보도자료’나 ‘랜딩 페이지 공개’ 전에 출원을 완료해야 합니다. 이 단계에서는 상세한 코드보다는 ‘비즈니스 모델 × 기술’의 기본 개념을 확립합니다.

1단계: MVP 개발 ~ 출시 직전 (PMF 전)이 단계가 가장 중요한 승부처입니다.특허에는 '신규성'이 필요합니다. 베타 버전이라 하더라도 일단 세상에 공개해 버리면 원칙적으로 특허를 받을 수 없게 됩니다(신규성 상실).반드시 '보도자료'나 '랜딩 페이지 공개' 전에 출원을 완료해 주십시오. 이

사용자가 늘어나고 기능 추가가 진행되는 시기입니다. 여기서는 ‘타사와의 차별화 요인’이 되는 구체적인 UI/UX나 데이터 구조, API 사양의 권리화를 추진합니다.

특히, 향후 IPO(신규 상장)나 M&A를 염두에 둔 경우, 특허 포트폴리오는 기업의 평가액(밸류에이션)을 크게 끌어올리는 자산이 됩니다. 투자자나 인수 기업은 기술 그 자체뿐만 아니라, ‘그 기술을 독점할 수 있는 권리’에 돈을 지불하기 때문입니다.

6. 요약: SaaS에 강한 변리사를 선택하는 중요성

SaaS 비즈니스의 특허는 다음 3가지 요소를 깊이 이해하지 못하면 허점이 많은 권리가 되어 버립니다.

1. 네트워크 기술(HTTP, API, WebSocket, 클라우드 인프라)

2. 최신 법적 논리(도완고 대법원 판결, 다주체 실시, 간접 침해)

3. 비즈니스 모델(수익화 포인트, 경쟁사의 진입 경로)

단순히 ‘엔지니어에게 들은 사양을 문서로 작성하는 것’만으로는 SaaS 특허를 지킬 수 없습니다.

엔지니어와 대등하게 기술 용어로 대화할 수 있으며, 서버와 클라이언트 간의 보이지 않는 처리를 ‘권리’라는 형태로 가시화할 수 있는 전문가의 지원이 필수적입니다.

본 사무소에서는 SaaS/클라우드 비즈니스에 특화된 특허 지원을 제공하고 있습니다.

'자사 서비스가 특허가 될지 모르겠다', '경쟁사가 모방하지 않을까 불안하다'는 분은 개발이 완료되기 전에 서둘러 상담해 주십시오.

SaaS 기술은 코드를 작성하는 순간부터 자산이 됩니다. 그 자산을 ‘독점권’으로 바꾸는 것이 저희의 일입니다.

태그

#SaaS #특허전략 #소프트웨어특허 #비즈니스모델특허 #스타트업 #변리사 #서버클라이언트시스템 #드왕고판결 #크로스보더 #API #UIUX #침해입증 #지식재산전략 #클라우드서비스 #특허출원 #IT특허