미국 특허법 제112조(f)(35 U.S.C. § 112(f)) 기능식 청구항 작성 전략: 적용 기준부터 명세서 대비까지

미국 특허법 제112조(f)(35 U.S.C. § 112(f))는 구성요소를 구조 대신 기능으로 적은 청구항을 허용하지만, 그 범위를 명세서에 기재된 구조와 균등물로 좁혀 해석하는 조항입니다. 'means'라는 단어를 쓰지 않아도 '모듈', '유닛', '~부' 같은 표현만으로 적용될 수 있어, 한국 출원을 번역한 청구항이 의도치 않게 좁아지는 일이 잦습니다. 이 글에서는 112(f) 기능식 청구항의 적용 기준과 소프트웨어 발명의 알고리즘 기재 요건, 의도치 않은 적용을 피하는 작성법, 의도적으로 활용할 때의 명세서 전략까지 기업 IP 실무자의 시각에서 정리합니다.

112(f) 기능식 청구항, 넓어 보이지만 좁게 해석되는 청구항

한국 명세서에서 가장 흔하게 보는 청구항 형식 중 하나가 "~를 판단하는 제어부", "~를 산출하는 처리부"처럼 구성요소를 기능으로 정의하는 방식입니다. 한국에서는 이런 표현이 비교적 넓은 권리로 받아들여지는 편이라, 연구소에서도 별다른 고민 없이 씁니다.

그런데 같은 청구항을 영어로 옮겨 미국에 출원하면 사정이 달라집니다. 미국에서는 이런 구성요소가 112(f) 기능식 청구항(Means-plus-Function Claim)으로 해석될 수 있고, 그 순간 "판단하는 모든 수단"이 아니라 명세서에 적힌 구체적인 구조와 그 균등물만을 가리키게 됩니다. 넓게 쓴 줄 알았던 청구항이 실제로는 실시예 몇 개에 묶이는 셈입니다.

제가 이 조항을 처음 실감한 것은 경쟁사 제품에 대한 침해 검토를 하던 때였습니다. 우리 특허 청구항의 '처리 유닛'이 기능식으로 해석되면서, 명세서에 적힌 회로 구성과 다른 방식으로 동작하는 경쟁사 제품이 범위 밖으로 빠져나갔습니다. 소프트웨어 발명이라면 위험은 더 큽니다. 명세서에 알고리즘이 충분히 적혀 있지 않으면 청구항 자체가 불명확하다는 이유로 무효가 될 수도 있습니다. 아래에서 112(f)가 언제 적용되는지, 어떻게 피하고 어떻게 활용하는지 차례로 살펴보겠습니다.

112(f)의 조문과 법적 효과

112(f)는 결합 발명의 구성요소를 구조, 재료, 행위를 적지 않고 특정 기능을 수행하는 수단(means) 또는 단계(step)로 표현할 수 있다고 정합니다. 대신 그렇게 표현한 구성요소는 명세서에 기재된 대응 구조·재료·행위와 그 균등물을 포함하는 것으로 해석해야 한다고 덧붙입니다. 2013년 미국 개정 특허법(AIA) 시행 전에는 112조 제6단락이라고 불렀습니다.

이 조항의 효과는 세 가지로 정리할 수 있습니다. 첫째, 권리 범위가 명세서의 실시예로 좁혀집니다. 청구항 문언이 아무리 포괄적이어도 해석은 명세서에 묶입니다. 둘째, 심사 단계에서도 똑같이 적용됩니다. USPTO는 1994년 In re Donaldson 판결 이후 기능식 구성요소를 가장 넓은 합리적 해석으로 읽지 않고 112(f) 방식으로 해석해야 합니다. 셋째, 명세서에 대응 구조가 제대로 적혀 있지 않으면 청구항은 112조(b)의 명확성 요건 위반으로 불명확하다는 판단을 받습니다.

여기서 말하는 균등물은 침해 소송의 균등론과는 조금 다릅니다. 112(f)의 균등물은 청구항에 적힌 기능과 동일한 기능을 실질적으로 같은 방식으로 수행해 실질적으로 같은 결과를 내는 구조여야 하므로, 기능 자체가 다르면 균등 범위에 들어오지 않습니다. 한국 특허법에는 이처럼 기능식 청구항의 범위를 명세서 구조로 좁히는 명시적 규정이 없어, 한국 실무자에게 가장 낯선 부분이기도 합니다.

112(f)가 적용되는 기준: 3요건 테스트와 Williamson 판결

USPTO 심사기준서(MPEP 2181)는 다음 세 요건을 모두 충족하면 112(f)가 적용된다고 봅니다.

요건	판단 내용	해당하기 쉬운 표현
① 수단 또는 대체 용어 사용	'means', 'step' 또는 구조를 특정하지 않는 포괄적 용어	module, unit, mechanism, device, element, component
② 기능적 수식	그 용어가 기능을 나타내는 문구로 수식되는가	for ~ing, configured to, so that, operable to
③ 충분한 구조의 부재	청구항 안에 기능을 수행할 구조가 충분히 적혀 있지 않은가	구성요소 간 연결이나 내부 구조 설명이 없는 경우

'means'를 쓰면 112(f)가 적용된다고 추정되고, 쓰지 않으면 적용되지 않는다고 추정됩니다. 다만 두 추정 모두 뒤집힐 수 있습니다. 2015년 연방순회항소법원의 Williamson v. Citrix 전원합의체 판결은 'means'가 없을 때의 추정이 '강한' 추정이라는 종래 입장을 버리고, 통상의 기술자가 그 용어를 충분히 확정된 구조의 이름으로 이해하는지를 기준으로 판단하도록 했습니다. 그 사건의 '분산 학습 제어 모듈'은 'means'와 다를 바 없는 대체 용어로 판단되었습니다.

반대로 '회로(circuit)', '프로세서(processor)', '밸브', '스프링'처럼 업계에서 구조의 이름으로 통하는 용어는 대체로 112(f)가 적용되지 않는 쪽으로 판단됩니다. 다만 법원 판단이 사건마다 엇갈리는 경우도 있으므로, 용어 하나만 믿기보다 청구항 안에 연결 관계와 동작 구조를 함께 적어 두는 것이 안전합니다.

소프트웨어 발명과 알고리즘 기재 요건

112(f) 문제가 가장 치명적으로 나타나는 분야는 컴퓨터로 구현되는 발명입니다. 하드웨어 발명이라면 명세서에 적힌 회로나 기계 부품이 대응 구조가 되지만, 소프트웨어 기능을 수행하는 구성요소의 대응 구조는 범용 컴퓨터만으로는 부족합니다. 연방순회항소법원은 1999년 WMS Gaming 판결과 2008년 Aristocrat 판결 등을 통해, 이런 경우 대응 구조는 그 기능을 수행하도록 프로그래밍된 컴퓨터와 그 알고리즘이라고 보았습니다.

따라서 "데이터를 분석하는 처리 모듈"이 112(f)로 해석되면, 명세서에 그 분석을 어떤 순서와 방식으로 수행하는지 알고리즘이 구체적으로 적혀 있어야 합니다. 알고리즘은 수식, 흐름도, 단계별 문장 등 어떤 형식이든 상관없지만, "적절한 소프트웨어로 구현할 수 있다", "통상의 기술자가 프로그래밍할 수 있다" 같은 문장만으로는 부족합니다. 알고리즘이 없으면 청구항은 112조(b) 위반으로 불명확하다는 판단을 받고, 등록 후 소송에서는 무효 사유가 됩니다.

USPTO도 2019년 1월 컴퓨터 구현 발명의 기능적 구성요소에 대한 심사 지침을 내놓아, 심사관이 112(f) 적용 여부와 알고리즘 기재 여부를 적극적으로 점검하도록 했습니다. 실무에서 소프트웨어 청구항의 112조 거절이 늘어난 배경입니다. 한국 명세서는 기능 설명은 충실해도 처리 단계를 흐름도 수준까지 풀어 쓰지 않는 경우가 많으므로, 미국 출원 전에 이 부분을 보강해 두는 것이 가장 효과적인 대비입니다.

의도치 않은 112(f)를 피하는 청구항 작성법

대부분의 경우 기업이 원하는 것은 112(f)를 피해 문언 그대로의 넓은 범위를 확보하는 것입니다. 이를 위해 제가 번역 단계에서 대리인과 함께 점검하는 표현은 다음과 같습니다.

한국 원문	위험한 직역	권장 표현 방향
~를 판단하는 제어부	a control unit for determining ~	a processor; and a memory storing instructions that cause the processor to ~
신호를 생성하는 신호처리 모듈	a signal processing module configured to generate ~	a signal processing circuit coupled to ~ and comprising ~
부재를 고정하는 고정 수단	a fixing means for fixing ~	a clamp having ~, 또는 구체적 부품명 사용

핵심은 구조의 이름을 쓰고, 그 구조가 다른 구성요소와 어떻게 연결되어 어떤 방식으로 동작하는지를 청구항 안에 함께 적는 것입니다. 방법 청구항은 "~하는 단계(step for)" 대신 실제 행위를 동사로 적으면 112(f)를 피할 수 있습니다. 또한 장치 청구항 하나에만 의존하지 말고 방법 청구항과 컴퓨터 판독 가능 저장매체 청구항을 함께 두어, 한 형식이 좁게 해석되더라도 다른 형식으로 보호받을 수 있도록 청구항 세트를 구성하는 것이 좋습니다.

112(f)를 의도적으로 활용할 때의 명세서 전략

112(f)가 항상 피해야 할 대상만은 아닙니다. 선행기술이 많아 넓은 청구항이 무효 공격을 받기 쉬운 분야에서는, 명세서의 구조로 범위가 한정되는 기능식 청구항이 오히려 무효 공격에 버티는 청구항이 될 수 있습니다. 또 구조를 일일이 특정하기 어렵지만 기능은 분명한 기계 발명에서는 간결한 청구항을 쓰는 수단이 됩니다. 일부 기업은 청구항 세트를 다양화하는 차원에서 기능식 청구항을 하나쯤 일부러 넣어 두기도 합니다.

의도적으로 활용한다면 승부는 명세서에서 납니다. 첫째, 각 기능마다 대응 구조를 명확히 연결해 적어야 합니다. "~하는 수단은 도 3의 회로(102)로 구현될 수 있다"처럼 기능과 구조를 직접 잇는 문장이 있어야 법원과 심사관이 대응 구조를 찾을 수 있습니다. 둘째, 균등 범위를 넓히기 위해 여러 대안 구조를 함께 적어 둡니다. 하나의 실시예만 있으면 범위도 그 하나로 좁아집니다. 셋째, 소프트웨어 기능이라면 알고리즘을 흐름도와 단계별 설명으로 빠짐없이 기재합니다.

반대로 명세서가 이런 준비 없이 기능 설명만 담고 있다면, 기능식 청구항은 권리 범위가 좁아지는 수준을 넘어 불명확성 무효로 이어질 수 있습니다. 따라서 112(f) 활용 여부는 청구항을 쓸 때가 아니라 명세서를 설계할 때 결정해야 합니다.

심사 단계 대응과 사내 체크포인트

USPTO 심사관은 112(f)가 적용된다고 판단하면 거절이유통지에 그 사실과 해당 구성요소를 명시합니다. 거절이 아니라 '해석 통지'에 가까운 경우도 있지만, 대응하지 않고 넘어가면 그 해석이 출원 경과 기록에 그대로 남습니다. 문제는 이 기록이 등록 후 침해 소송에서 청구항 해석의 근거가 된다는 점입니다.

대응 방법은 두 가지입니다. 하나는 해당 용어가 통상의 기술자에게 충분히 확정된 구조로 이해된다고 반박하는 것이고, 다른 하나는 청구항에 구조나 연결 관계를 추가하는 보정입니다. 반박할 때는 업계 표준 문서나 기술 사전처럼 객관적 근거를 붙이는 편이 설득력이 있습니다. 112(f) 해석을 받아들이기로 했다면, 심사관이 지목한 대응 구조가 명세서상 정확한지 확인하고 필요하면 의견서에서 바로잡아 두어야 합니다.

사내에서는 미국 출원 전에 다음을 확인합니다. 청구항에 'unit', 'module', 'means' 같은 대체 용어가 기능 문구와 함께 쓰였는지, 그렇다면 피할지 활용할지, 활용한다면 명세서에 대응 구조와 알고리즘이 기능별로 연결되어 있는지입니다. 참고로 2026년 7월 20일부터 미국 밖에 주소를 둔 출원인은 보정서와 의견서 등 대부분의 서류를 USPTO 등록 대리인의 서명을 받아 제출해야 하므로, 예비 보정 일정도 미국 대리인과 함께 계획해야 합니다.

112(f) 기능식 청구항 작성 전략 핵심 정리

미국 특허법 제112조(f)(35 U.S.C. § 112(f))는 기능으로 표현한 구성요소를 허용하되, 그 범위를 명세서에 기재된 대응 구조와 균등물로 좁혀 해석하는 조항입니다. 'means'나 'step'뿐 아니라 'module', 'unit' 같은 대체 용어가 기능 문구와 결합하고 청구항에 충분한 구조가 없으면 적용될 수 있으며, Williamson 판결 이후 그 범위가 넓어졌습니다. 소프트웨어 기능이 112(f)로 해석되면 명세서에 알고리즘이 있어야 하고, 없으면 불명확성 거절이나 무효로 이어집니다.

넓은 권리가 목표라면 구조의 이름과 연결 관계를 청구항에 적고, 방법과 저장매체 청구항을 함께 구성해 112(f)를 피하는 것이 기본입니다. 반대로 112(f)를 의도적으로 활용한다면 기능별 대응 구조, 대안 구조, 알고리즘을 명세서에 빠짐없이 연결해 두어야 합니다.

112(f)는 번역 한 줄에서 시작되는 문제입니다. 미국 출원을 앞둔 한국 출원이 있다면, 청구항의 '~부'와 '수단' 표현을 하나씩 짚어 보고 각 기능에 대응하는 구조와 알고리즘이 명세서에 적혀 있는지부터 점검해 보시기 바랍니다.