기술표준의 선택사양, 동적 정의, Claim-Level 분석과 작성자 불이익의 원칙
특허 청구항이 충분히 명확하고 유효하다고 인정되더라도, 그 특허가 라이선스 계약의 범위에 포함되는지는 전혀 다른 문제다.
미국 연방항소법원의 Intel Corp. v. VIA Technologies, Inc. 사건은 특허 청구항 해석과 라이선스 계약 해석이 서로 다른 법적 층위에서 작동한다는 점을 잘 보여주는 사례다.
특히 기술표준을 라이선스 범위와 연결하면서 “required”, “must be infringed”와 같은 표현을 사용하거나, 특정 특허번호 대신 여러 단계의 정의를 통해 라이선스 범위를 정하는 계약에서는 문언 하나가 예상보다 훨씬 큰 법적 결과를 가져올 수 있다.
1. 특허의 명확성과 라이선스 범위의 상충
컴퓨터 칩셋 통신 표준인 AGP(Accelerated Graphics Port, 가속 그래픽 포트)를 둘러싸고 벌어진 미국 연방항소법원의 Intel Corp. v. VIA Techs., Inc. (Fed. Cir. 2003) 판결은 특허 라이선스 실무에 중요한 시사점을 던진다.
인텔(Intel)은 비아(VIA)가 자사의 패스트 라이트(Fast Write) 기술이 담긴 ‘291 특허를 침해했다며 소송을 제기했다.
그러나 법원은 비아가 인텔과의 무상 크로스 라이선스 계약에 따라 정당한 실시권을 확보했다고 판단해 비아의 손을 들어주었다.
법원은 ‘291 특허에 구체적인 회로 도면이 없더라도 당업자가 기술을 이해할 수 있어 유효하고 명확하다고 보았다.
반면 해당 특허를 허락한 라이선스 계약의 범위에 대해서는 문언이 모호하다고 판단하여, 작성자 불이익의 원칙 (contra proferentem)을 적용했다.
특허 청구항 기재가 아무리 명확하더라도, 이를 포섭하는 라이선스 계약 조항은 얼마든지 모호해질 수 있다.
2. AGP 규격의 필수성과 선택성 구조
이 사건의 본질을 짚으려면 인텔이 제시한 AGP 기술 규격의 체계와 계약서에 명시된 ‘필수성(Required)’ 요건의 성격을 살펴볼 필요가 있다.
2.1. 기술적 배경과 선택 프로토콜
인텔은 1996년 AGP 1.0 규격을 내놓은 뒤, 1998년 전송 속도를 한층 끌어올린 AGP 2.0 규격을 발표했다.
AGP 2.0에는 ‘4배속 전송(4x transfer)’과 ‘패스트 라이트(Fast Write)’라는 두 가지 프로토콜이 새로 추가되었다.
제조사가 패스트 라이트를 구현하지 않더라도 AGP 2.0 규격을 충족하는 공식 호환 제품으로 인정받는 데 아무런 문제가 없었다.
2.2. ‘Required(필수성)’ 개념의 두 가지 해석
라이선스 계약을 둘러싼 공방은 ‘필수적(required)’이라는 문언을 어떤 기준에 비추어 해석할 것인가에서 출발했다.
쟁점은 크게 두 갈래로 나뉘었다.
2.3. “disclosed in, and required by” 문구를 둘러싼 대립
인텔의 AGP 라이선스 계약은 무상 라이선스 대상을 “AGP 규격서에 공개되고, 그에 따라 요구되는 (disclosed in, and required by) 인터페이스 및 프로토콜”로 규정하고 있었다.
바로 이 조항의 해석을 두고 양측의 입장이 첨예하게 갈렸다.
2.4. 연방법원의 판단: ‘필수 과목 교재’ 비유와 모호성 인정
미국 연방항소법원은 쟁점 조항을 알기 쉽게 설명하기 위해 ‘학교가 요구하는 과목의 교재 (books required by a school)’라는 비유를 들었다.
이 문구는 전교생이 의무적으로 이수해야 하는 필수 과목의 교재를 뜻할 수도 있지만, 특정 선택 과목을 수강할 때 반드시 갖춰야 하는 교재를 의미할 수도 있다.
법원은 인텔의 엄격한 이분법적 논리를 그대로 수용하지 않았다.
인텔이 자체 작성한 AGP 2.0 기술 규격서에서도 선택 프로토콜인 Fast Write의 내부 신호(WBF#)에 ‘Required(R)’라는 표기를 사용하고 있었기 때문이다.
“For example, books ‘required by’ a school could mean books needed for (1) ‘required’ (non-optional) classes; or (2) any class taken, including optional classes.”
“예를 들어, 학교에서 ‘요구되는(required by)’ 책이란 (1) 필수(비선택) 과목에 필요한 책을 의미할 수도 있고, (2) 선택 과목을 포함하여 수강하는 임의의 과목에서 필요한 책을 의미할 수도 있다.”
법원은 결국 인텔과 비아 양측의 해석이 기술적으로나 언어적으로 모두 타당하고 합리적이라고 판단했다.
이에 따라 해당 계약 조항에는 양립 가능한 두 해석이 팽팽히 맞서는 진정한 모호성(ambiguity)이 존재한다고 결론지었다.
3. ‘동적 정의’의 구조와 다단계 연결 작업
인텔의 AGP 라이선스 계약은 특정 특허 번호를 일일이 열거하는 대신, 4단계에 걸친 연쇄적 정의 (chain of definitions) 방식을 취했다.
- 라이선스 부여(License Grant): AGP 인터페이스를 준수하는 제품에 특허 라이선스를 부여한다.
- 인터페이스 청구항(Interface Claims): AGP 인터페이스를 준수하기 위해 불가피하게 침해할 수밖에 없는 (must be infringed) 특허 청구항을 의미한다.
- AGP 인터페이스(AGP Interfaces): 규격서에 공개되고 그에 따라 요구되는 (disclosed in, and required by) 전기적 인터페이스 및 버스 제어 프로토콜이다.
- AGP 규격서(AGP Specifications): 인텔이 발행한 AGP 1.0 및 2.0 기술 규격 문서다.
이러한 동적 정의(dynamic definition) 방식은 기술이 발전하거나 규격이 개정되더라도 매번 계약서를 수정할 필요가 없다는 유연성을 제공한다.
그러나 실제 라이선스의 보호 범위를 확정하려면 ‘기술 규격’에서 출발하여 ‘제품 기능’과 ‘특허 청구항’을 거쳐 ‘라이선스 범위’로 이어지는 다단계 연결 고리를 매번 검증해야 하는 난제를 안게 된다.
3.1. 라이선스 부여 조항(License Grant)
“AGP 인터페이스를 준수하는 제품을 제조, 위탁 제조, 사용, 수입, 판매 제안 및 판매할 수 있도록 인터페이스 청구항(Interface Claims)에 대한 비독점적, 무상, 양도 불가, 재라이선스 불가한 전 세계적 라이선스를 부여한다. 단, AGP 인터페이스를 준수하는 데 요구되지 않는 (not required to comply with) 제품의 기능이나, 특허 침해를 피할 수 있는 실행 가능한 대안이 존재하는 기능에는 본 라이선스가 미치지 아니한다.”
3.2. 인터페이스 청구항 정의(Interface Claims)
“‘인터페이스 청구항’이란 당사자가 소유하거나 통제하는 특허 또는 특허 출원의 청구항으로서 AGP 인터페이스를 준수하기 위해 반드시 침해되어야 하는 청구항을 의미한다. ‘인터페이스 청구항’에는 제조 기술에 관한 청구항, AGP 인터페이스를 준수함에 있어 침해될 것이 요구되지 않는 청구항 (동일 특허 내에 있더라도 제외), 또는 라이선스 부여 시 계열사가 아닌 제3자에게 로열티를 지급해야 하는 청구항은 포함되지 않는다.”
3.3. AGP 규격서 정의
“‘가속 그래픽 포트 인터페이스 규격’이란 인텔이 출판한 ‘가속 그래픽 포트 인터페이스 규격서 Revision 1.0 및 2.0’이라는 제목의 문서에 기술된 규격을 의미한다.”
3.4. 단서 조항(Provided Clause)
“...단, AGP 인터페이스를 준수하는 데 요구되지 않는 제품의 기능이나, 특정 청구항(특허)을 침해하지 않고도 구현할 수 있는 실행 가능한 대안(feasible alternative)이 존재하는 기능에는 본 라이선스가 미치지 아니한다.”
3.5. 실무에서 확인해야 할 다섯 가지 질문
특히 제품 설계가 바뀌거나 새로운 선택 기능이 추가될 때마다 실무진은 다음의 다섯 가지 질문을 검토해야 한다.
- 해당 기술이 표준 준수에 실질적으로 필요한 기술인가?
- 그 기술을 구현할 때 특허권자의 어떤 청구항이 침해되는가?
- 그 청구항은 표준을 준수하기 위해 반드시(must) 침해될 수밖에 없는 성격인가?
- 특허를 우회할 수 있는 실행 가능한 비침해 대안(feasible alternative)이 존재하는가?
- 표준 전체에서는 선택 사양(optional feature)인 기능을 탑재했을 때도 해당 청구항이 라이선스 범위에 포섭되는가?
실행 가능한 비침해 대안이 존재하는지, 표준 준수를 위해 불가피한 필수 기술인지 (essentiality)를 따지는 다층적 필터를 통과해야 비로소 라이선스의 보호를 받을 수 있다.
4. 특허 청구항의 명확성 vs. 라이선스 조항의 모호성
Intel v. VIA 사건은 특허 청구항 해석(claim construction)과 라이선스 계약 해석(contract construction)이 서로 완전히 다른 법적 층위에서 작동한다는 점을 선명하게 보여준다.
4.1. 특허 자체는 명확했다
소송 과정에서 비아는 ‘291 특허 명세서에 구체적인 전자 회로도가 누락되었음을 지적했다.
기술의 범위가 불분명하므로 미국 특허법상 명확성 요건 (35 U.S.C. § 112 ¶ 2)을 결여하여 무효라는 논리였다.
그러나 법원은 이를 받아들이지 않았다.
특허 명세서에 도면 3개와 신호 차트 35개, 버퍼 상태 신호(WBF#) 프로토콜 및 코어 로직 수정 방식이 상세히 기재되어 있어, 해당 기술 분야의 통상 기술자 (person skilled in the art)라면 회로도가 없더라도 기술을 구현하기에 충분하다고 보았기 때문이다.
4.2. 그러나 라이선스 계약은 모호했다
반면 라이선스 계약 해석의 영역에서는 판도가 뒤바뀌었다.
해당 계약이 인텔이 일방적으로 작성하여 상대방에게 수락 여부만을 양자택일하도록 요구한 표준 서식 (take-it-or-leave-it)이었다는 점이 결정적이었다.
법원은 양측의 해석이 모두 합리적이어서 계약상 모호성이 발생한 이상, 준거법인 델라웨어주 법에 따라 작성자 불이익의 원칙 (contra proferentem)을 적용해야 한다고 판단했다.
특허의 권리범위와 계약상 허여범위는 별도로 설계하고 검토해야 한다.
5. 기술 이해에 기반한 특허 라이선스 실무의 교훈
Intel v. VIA 판결은 특허 라이선스 계약을 일반적인 표준 계약 조항(boilerplate) 수준으로 안이하게 다루었을 때 어떠한 법적 위험이 뒤따르는지를 생생하게 보여준다.
특허 라이선싱 협상과 계약서 작성은 단순한 법률 문언 정리를 넘어, 해당 기술의 실제 동작 메커니즘과 청구항 해석(claim construction)에 대한 깊이 있는 이해가 반드시 뒷받침되어야 한다.
즉 특허 라이선싱 협상과 계약 체결은 반드시 특허 발명 기술에 대한 깊은 이해와 청구항 해석(Claim Construction)을 바탕으로 진행되어야 한다.
구체적으로 기업 실무에서는 다음의 세 가지 전략을 계약에 명확히 반영해야 한다.
“선택적 프로토콜 구현을 위한 청구항은 라이선스 대상에서 명시적으로 제외한다”는 식의 직접적인 배제 문언을 명시해야 작성자 불이익의 원칙이 적용되어 특허권 행사가 가로막히는 사태를 방지할 수 있다.
required, necessary, must be infringed, comply with처럼 겉보기에는 평범한 단어도 기술표준의 계층 구조와 결합되는 순간 전혀 다른 의미를 가질 수 있다.
결국 특허 라이선스의 범위를 제대로 설계하려면 계약서만 읽어서는 부족하다. 기술을 이해하고, 제품의 구현방식을 파악하고, 청구항을 해석한 다음, 그 결과를 계약 문언과 다시 연결해야 한다.
