AI 특허, 미국에서 무엇이 문제가 되나

AI 발명을 미국에 출원하면 대부분 두 가지 거절을 만나게 된다. 하나는 특허 대상이 아니라는 35 U.S.C. §101 거절이고, 다른 하나는 선행기술로부터 쉽게 생각해 낼 수 있다는 §103 거절이다. 특히 AI 분야는 인코더, 어텐션, BERT 같은 구성요소가 이미 공개된 논문과 오픈소스에 널려 있어서 §103 대응이 쉽지 않다.

최근(2026.10.20) 등록된 구글의 음성인식 특허 US 12,770,614 B2(Context-Aware End-to-End ASR Fusion of Context, Acoustic and Text Representations)는 이 두 거절을 모두 받았지만, 보정서 한 번으로 청구항 22개 전부를 등록받았다. 어떤 기술인지, 그리고 심사관을 어떻게 설득했는지 순서대로 살펴보자.

앞 문장을 기억하는 음성인식

회의를 받아 적는 속기사를 떠올려 보자. 실력 있는 속기사는 지금 들리는 소리만 듣고 적지 않는다. 방금 적은 단어를 보고 다음 단어를 짐작하고, 회의가 어떤 흐름으로 흘러왔는지도 기억한다. 그래서 발음이 애매한 단어가 나와도 대부분 맞게 적는다.

그런데 기존 음성인식은 긴 음성을 짧게 잘라 토막마다 따로 인식한다. 문장이 끝날 때마다 앞 내용을 잊어버리는 속기사인 셈이다. 우리말로 예를 들면 "결재"와 "결제"는 소리가 같다. 바로 앞에서 "카드로 계산할게요"라고 했다면 결제가 맞고, "부장님께 서류 올렸어요"라고 했다면 결재가 맞다. 소리만으로는 가를 수 없고 앞 문장을 알아야 한다. 명세서에도 Cal(버클리 대학의 애칭)이 발음이 비슷한 Kyle로 잘못 인식되는 사례가 나온다.

본 특허는 음성인식 모델이 다음 글자를 고를 때 세 가지 정보를 함께 보도록 했다. 지금 들리는 소리(음향 정보), 이번 문장에서 방금까지 인식한 단어(텍스트 정보), 그리고 앞 문장들과 AI 비서가 앞서 했던 대답을 요약한 정보(문맥 정보)다. 앞의 두 가지는 기존 RNN-T 음성인식 모델에도 있던 것이고, 새로 붙인 것은 문맥 정보다. 앞서 인식한 문장을 BERT로 읽어 문맥 임베딩을 만들고, 이를 마지막에 단어를 고르는 조인트 네트워크에 직접 넣는 구조다.

그림 1을 보면 왼쪽 아래 문맥 인코더(300), 가운데 오디오 인코더(210), 오른쪽 예측 네트워크(230)의 출력이 모두 조인트 네트워크(240)로 모이는 것을 확인할 수 있다. 명세서에는 문맥 정보를 오디오 인코더 단계에 넣는 실시예(FIG. 2A)도 있는데, 이 경우 소리와 문맥이 박자를 맞춰 들어와야 해서 속도가 느려질 수 있다고 적고 있다. 등록된 청구항은 그림 1의 방식이다.

핵심은 세 정보를 섞는 방법이다. 가장 쉬운 방법은 세 정보를 이어 붙여 더하는 것이다. 예를 들어 "결제"의 소리 점수가 0.9, 맥락 점수가 0.9이고 "결재"는 소리 0.9, 맥락 0.1이라고 해 보자(이해를 돕기 위한 단순화한 예다). 더하면 1.8 대 1.0으로 차이가 2배도 나지 않는다. 그런데 곱하면 0.81 대 0.09로 9배 차이가 난다. 소리와 맥락이 동시에 맞아야만 점수가 크게 오르기 때문이다. 본 특허는 이렇게 세 정보를 곱해서 섞는 방식을 3-way tensor fusion이라고 부르며, 계산량을 줄이기 위해 각 정보를 작은 차원으로 줄인 뒤 곱하는 저랭크 근사까지 명세서에 기재하고 있다.

§101 거절, 생각보다 단순했다

AI 특허의 §101 거절이라고 하면 보통 Alice 판례의 추상적 아이디어 판단을 먼저 떠올린다. 그런데 이 사건은 그 단계까지 가지도 않았다. 심사관은 장치 청구항 1~10만 거절했는데, 청구항이 "An ASR model comprising…(음성인식 모델로서…)"으로 시작해 프로세서나 메모리 같은 물리적 구성이 하나도 없으니 프로그램 그 자체(program per se)를 청구한 것이라는 이유였다.

미국 §101 판단은 크게 두 관문으로 이루어진다. 첫 관문(Step 1)은 청구항이 기계, 방법, 제조물, 조성물 중 하나에 해당하는지를 묻고, 두 번째 관문(Step 2A, 2B)은 추상적 아이디어나 수학적 개념에 그치지 않는지를 묻는다. 이 사건은 첫 관문에서 걸렸다. 요리 레시피만 적어 내면 특허 대상이 아니지만, 그 레시피가 저장된 조리기계라고 적으면 물건이 되는 것과 같은 이치다. 실제로 같은 내용을 "하드웨어에서 실행되는 방법"으로 적은 청구항 11~20은 처음부터 §101 거절을 받지 않았다.

대리인의 대응도 간단했다. 청구항 1의 첫 줄을 아래와 같이 바꿨다.

[그림 2 : 청구항 1 보정 (밑줄 부분 추가)]

"음성인식 모델로서"를 "데이터 처리 하드웨어와 명령어를 저장한 메모리 하드웨어를 포함하고, 그 명령어가 실행되면 음성인식 모델을 구현하는 시스템으로서"로 바꾼 것이다. 근거는 명세서의 컴퓨팅 장치 설명(FIG. 5)이었고, 심사관은 이후 §101을 다시 문제 삼지 않았다.

§103, 연결이 다르면 다른 발명

§103 거절은 훨씬 까다로웠다. 심사관이 주 인용문헌으로 든 Kai 논문(Attentive Contextual Carryover for Multi-Turn End-to-End SLU, 2021)에는 소리를 처리하는 오디오 인코더, 앞 문장을 BERT로 읽는 문맥 인코더, 예측 네트워크, 조인트 네트워크가 모두 있었다. 부족한 부분(확률분포 생성)은 Zhao(US 2020/0357388)로 보충했다. 구성요소를 하나씩 맞춰 보는 방식으로는 반박할 틈이 거의 없는 거절이었다.

그래서 대리인은 구성요소가 있느냐 없느냐를 다투지 않았다. 대신 문맥 정보를 언제, 어떻게 섞느냐가 다르다는 쪽으로 논점을 옮겼다. 

그림 3을 보면 차이가 분명하다. Kai는 문맥 정보를 맨 처음 오디오 인코더 단계에서 음향 정보에 섞어 버린다. 조인트 네트워크에 닿을 때는 이미 음향 정보 안에 녹아 있어서, 조인트 네트워크가 받는 정보는 결국 두 가지뿐이다. 미리 섞어 버린 셈이다. Zhao는 모델 바깥에서 문맥 점수를 따로 계산해 최종 점수에 더한다. 본 특허는 마지막 단계에서 세 정보를 동시에 곱해서 섞는다.

대리인은 이 주장과 함께 청구항도 고쳤다. 명세서 [0034]~[0039]에 실시예로 적혀 있던 융합 방식을 독립항으로 끌어올린 것이다. 청구항 1의 조인트 네트워크 부분은 아래와 같이 바뀌었다.

[그림 4 : 청구항 1의 §103 대응 보정 (밑줄 부분 추가)]

우리말로 옮기면 "조인트 네트워크는 문맥 임베딩, 음향 표현, 텍스트 표현을 입력받고, 출력 단계마다 이 세 가지를 3-way tensor fusion으로 융합해 하나의 융합 표현을 만든 뒤, 그 융합 표현을 바탕으로 확률분포를 생성한다"는 내용이다. 보정 전에는 세 정보를 "입력받는다"는 데서 그쳤다. 보정 후에는 그 세 정보를 "어떻게 합치는지"까지 청구항에 들어갔다. 

여기에 종속항 21, 22를 새로 추가했다. BERT가 앞서 인식한 문장뿐 아니라 AI 비서가 이전 차례에 했던 대답까지 입력받아 임베딩을 만든다는 내용이다. Kai는 비서의 대답을 "REQUEST(Quantity)", 즉 "수량을 물어봄" 같은 짧은 꼬리표로 바꿔 쓸 뿐, 대답 문장을 그대로 BERT로 읽지는 않는다. 독립항이 흔들리더라도 따로 버틸 수 있는 두 번째 방어선을 마련해 둔 것으로 보인다.

심사관의 허여 이유가 흥미롭다. 심사관은 NOA에서 여전히 "Kai의 조인트 네트워크도 세 가지 정보를 받는다"고 적었다. 그러면서도 "세 정보를 tensor fusion으로 융합하는 구성은 어느 문헌에도 없다"며 등록을 허락했다. 무엇을 넣느냐가 아니라 어떻게 섞느냐가 등록을 가른 것이다.

다만 아쉬운 점도 있다. 이 명세서에는 "얼마나 더 정확해졌다"는 실험 수치가 없다. 미국에서는 구조 차이만으로 충분했지만, 기술적 효과를 엄격하게 따지는 유럽에서는 약점이 될 수 있다. 또한 심사 중에 "곱해서 섞는 것이 다르다"고 강하게 주장했기 때문에, 향후 분쟁에서는 권리범위가 그만큼 좁게 해석될 여지도 있다.

AI 특허, 이렇게 준비하자

이 사건에서 얻을 수 있는 시사점을 정리하면 다음과 같다.

• 첫째, 청구항 첫 줄은 하드웨어로 시작하자.
  "AI 모델로서…"로 시작하면 프로그램 자체로 거절된다. 처음부터 "프로세서와 메모리를 포함하는 시스템", "하드웨어에서 실행되는 방법", "프로그램이 저장된 기록매체"로 청구항 세트를 구성하면 이런 거절은 피할 수 있다.
   
• 둘째, "좋아진다"가 아니라 "어떻게"를 쓰자.
  결과만 적으면 추상적 아이디어로 판단될 여지가 크다. 어떤 정보를 어디에 넣고 어떻게 처리하는지를 청구항에 담아야 기술 개선으로 인정받을 수 있다. 명세서에는 기존 방식이 실패하는 구체적인 사례를 남겨 두는 것이 좋다.
   
• 셋째, 부품이 같아도 연결이 다르면 다른 발명이다.
  AI 분야 선행기술에는 웬만한 부품이 이미 다 있다. 구성요소의 유무로 싸우기보다 어느 단계에서 합치는지, 어떤 연산으로 합치는지에서 차별점을 찾는 것이 현실적이다.

마치며

AI 특허는 받기 어렵다는 이야기를 자주 듣는다. 이 사건을 보면 꼭 그렇지만은 않다. 형식 요건은 처음부터 챙기고, 선행기술과 같은 부품을 쓰더라도 그것을 어떻게 연결하고 결합하는지를 청구항과 명세서에 분명히 적어 두면 길이 열린다.

AI 기술이 빠르게 보편화되면서 부품 자체로 차별화하기는 점점 어려워지고 있다. 앞으로 AI 특허의 경쟁력은 무엇을 쓰느냐보다 어떻게 엮느냐에서 나올 것으로 보인다. 국내 기업들도 이런 관점에서 AI 특허 포트폴리오를 설계해 나가기를 기대해본다.

참고: US 12,770,614 B2 명세서 및 심사경과(거절이유통지 2025.12.18, 보정서 2026.03.17, 허여통지 2026.06.02).

필자 소개
박기현 변리사는 카이스트 전기 및 전자공학부를 졸업하고 2015년 52기 변리사 시험에 합격했습니다.
국내 대기업의 기술 권리화, 특허 분쟁 대응 및 컨설팅 경험을 보유하고 있으며, 자율 주행, 영상 처리, 의료기기, 기계학습, 디스플레이, 단말 UI/UX, IP 포트폴리오 설계 및 IP 심판 소송 분야를 담당하고 있습니다.

특허법인 BLT
누군가는 특허를 만들 때, BLT는 당신의 사업의 성공을 만들어 냅니다. The Only Firm for Your Success!!

원문 보러가기

#구글 #음성인식 #특허 #미국특허 #미국특허심사 #청구항 #명세서 #보정서 #거절이유통지서 #인공지능 #ai #ai특허 #발명 #하드웨어 #아이디어 # 특허법인 #변리사