같은 예약 변경 안내가 반복되는 문제에서 출발해, 처리 기록을 확인하는 아이디어를 청구항으로 옮깁니다. 독립항 하나에 종속항 두 개를 어떻게 붙이는지 쉬운 설명과 예시로 살펴봅니다.
예약 시간을 한 번 바꿨는데 같은 안내 문자가 두 번 온다면 어떨까요? 받는 사람은 예약이 또 바뀐 건지, 앞서 온 안내가 잘못된 건지 헷갈릴 수 있습니다.
여기서 출발한 아이디어는 알림을 보내는 서버가 같은 예약 변경을 여러 번 처리하지 않도록, 처리 기록을 확인하자는 것입니다. 아래는 이 가상 아이디어를 청구항으로 옮겨 보는 학습용 예시입니다.
먼저 중복 작업을 줄이는 방법을 살펴본 뒤, 기본 구조를 청구항 1에 적고 두 가지 추가 조건을 청구항 2와 3에 붙여보겠습니다.
1. 같은 예약 변경인지 어떻게 알아볼까요?
예약번호만 같다고 무조건 중복은 아닙니다. 같은 예약의 시간을 다시 바꿨다면 새 안내가 필요하기 때문입니다. 그래서 예약번호, 몇 번째 변경인지, 받는 사람, 문자·이메일 중 어떤 방식으로 보낼지를 함께 구별하기로 합니다.
이 네 정보를 묶은 구별 표식을 처리 키라고 부르겠습니다. 서버는 이 표식과 함께 알림의 처리 상태를 기록합니다. 그 기록이 전송 이력입니다.
처리 방법은 다음과 같습니다.
예약 변경 정보를 받으면 구별 표식을 만듭니다.
같은 표식의 새 기록은 하나만 만들 수 있게 합니다. 여러 작업이 동시에 시작돼도, 기록을 만드는 데 성공한 작업만 최초 발송을 시작합니다.
같은 표식의 기록이 남아 있고 이미 보내는 중이거나 발송 완료라면, 뒤늦게 들어온 중복 요청은 새 발송을 시작하지 않습니다.
두 번째 규칙처럼 같은 표식의 기록이 중복 생성되지 않게 하는 저장 규칙을 아래 청구항에서는 유일성 제약이라고 표현합니다. 단순히 기록을 확인한 뒤 보내는 것에서 그치지 않고, 동시에 여러 작업이 생기는 경우도 구분한 설계입니다.
이 예시가 다루는 것은 서버 내부에서 발송 작업을 시작하는 조건입니다. 외부 문자 서비스나 고객 휴대전화까지 정확히 한 번 전달된다는 보장은 아닙니다.
2. 기본 구조와 추가 조건을 나눕니다
독립항은 다른 청구항을 인용하지 않고 기술의 구성을 적는 항입니다. 종속항은 앞의 청구항을 인용해 그 구성을 모두 이어받으면서 조건을 더합니다. 특허법 시행령 제5조도 종속항을 독립항을 한정하거나 부가하여 구체화하는 항으로 설명합니다.
이번 예시는 이렇게 나눕니다.
청구항 1: 같은 변경 건을 구별하고, 기록과 처리 상태에 따라 최초 발송을 제어하는 기본 구조
청구항 2: 1의 구조에 더해, 보냈는지 확실하지 않으면 바로 다시 보내지 않는 조건
청구항 3: 1의 구조에 더해, 실패가 확인돼 다시 보낼 때도 한 작업만 재시도를 시작하는 조건
청구항 2와 3은 각각 1을 인용하며, 서로를 인용하지 않습니다.
아래 청구항 문장은 길지만, 먼저 각 항 위의 설명으로 동작을 이해한 뒤 읽으면 연결 관계를 찾기 쉽습니다.
청구항 1: 중복 처리를 막는 기본 구조
기본 구조에는 세 역할이 필요합니다. 예약 변경 정보를 받는 부분, 처리 기록을 보관하는 부분, 그 기록을 보고 발송을 시작할지 판단하는 부분입니다. 여기서는 별도 장치 세 대가 아니라 한 서버 안의 소프트웨어 구성으로 가정합니다.
청구항 1
예약 변경 이벤트를 수신하고, 상기 예약 변경 이벤트에 포함된 예약 식별자, 변경 버전, 수신자 식별자 및 알림 채널에 기초하여 처리 키를 생성하는 이벤트 수신부;
상기 처리 키에 유일성 제약을 적용하여 상기 처리 키 및 처리 상태를 포함하는 전송 이력을 저장하는 전송 이력 저장부; 및
상기 처리 키에 대응하는 최초 전송 이력의 생성에 성공한 요청에 대해서만 최초 알림 전송을 시작하고, 상기 처리 키에 대응하며 처리 중 또는 전송 완료 상태인 전송 이력이 저장되어 있는 경우 중복 수신된 예약 변경 이벤트에 따른 새로운 알림 전송을 시작하지 않는 전송 제어부를 포함하는,
예약 알림의 중복 전송 방지 서버.
문장 속 이벤트 수신부 → 전송 이력 저장부 → 전송 제어부가 각각 정보를 받기, 기록을 보관하기, 발송을 제어하기에 해당합니다. “중복 문자를 막는다”는 목표만 적는 대신, 어떤 구성이 어떤 조건으로 동작하는지 연결해 쓴 것입니다.
청구항 2: 보냈는지 모르겠다면 바로 다시 보내지 않기
문자 서비스에서 답이 명확하게 오지 않았다고 해서 발송이 실패했다고 단정할 수는 없습니다. 이미 발송됐는데 응답만 확인하지 못했을 수도 있습니다. 이 예시는 그런 경우를 ‘확인 필요’로 기록하고 자동 재전송을 보류하는 조건을 더합니다.
청구항 2
청구항 1에 있어서,
상기 전송 제어부는 외부 알림 서비스의 응답만으로 알림 전송의 성공 여부를 확정할 수 없는 경우, 상기 처리 상태를 확인 필요 상태로 저장하고 해당 알림의 자동 재전송을 보류하는,
예약 알림의 중복 전송 방지 서버.
“청구항 1에 있어서”는 1의 기본 구조를 모두 포함한다는 뜻입니다. 여기에 보냈는지 불명확한 경우의 처리 조건을 추가한 것이 청구항 2입니다. 무엇을 확인해 이 상태를 해소할지는 실제 설계에서 더 정해야 합니다.
청구항 3: 실패했다면 한 작업만 다시 보내기
이번에는 발송 실패가 명확히 확인된 경우입니다. 여러 작업이 동시에 다시 보내려고 하면 중복이 생길 수 있으므로, 기록을 ‘재시도 가능’에서 ‘처리 중’으로 바꾸는 데 성공한 작업만 재전송을 시작하게 합니다. 이것이 아래 문장의 ‘조건부 변경’입니다.
청구항 3
청구항 1에 있어서,
상기 전송 제어부는 명확한 전송 실패 응답을 받으면 대응하는 전송 이력의 처리 상태를 재시도 가능으로 설정하고, 상기 처리 상태를 재시도 가능에서 처리 중으로 조건부 변경하는 데 성공한 작업에 한하여 알림 전송을 재시도하는,
예약 알림의 중복 전송 방지 서버.
청구항 2와 3은 각각 청구항 1을 인용합니다. 따라서 3이 2의 추가 조건까지 자동으로 포함하는 것은 아닙니다. ‘기본 구조 + 불명확한 결과에 대한 조건’과 ‘기본 구조 + 재시도 조건’을 따로 적은 것입니다.
내 아이디어에 적용할 때 확인할 것
청구항을 쓸 때는 해결하고 싶은 문제만 적기보다 다음 세 가지를 점검해보세요.
어떤 구성이 어떤 일을 하고, 서로 어떻게 연결되는가?
기본 구조와 별도로 덧붙일 조건은 무엇인가?
청구항에 적은 구성과 동작을 명세서의 설명에서도 찾을 수 있는가?
특허법 제42조 제4항은 청구항이 발명의 설명으로 뒷받침되고 명확하고 간결하게 적힐 것을 요구합니다. 또한 특허법 제97조에 따라 보호범위는 청구범위에 적힌 사항으로 정해집니다. 조건을 더하는 것은 같은 설명을 반복하는 일이 아니라 청구범위를 달리 정하는 일이기도 합니다.
이 예시는 청구항의 연결 구조를 배우기 위한 문장입니다. 실제 출원에 그대로 사용하기보다는 자신의 기술 내용과 선행기술에 맞춰 검토해야 하며, 이 예시로 등록 가능성을 판단할 수는 없습니다.
같은 가상 아이디어를 IPMAKER에 입력해 명세서 초안을 만들고 고친 과정은 AI 특허 명세서 초안 검토 사례에서 볼 수 있습니다. 두 글은 각각 청구항의 구조를 읽는 연습과 실제 문서 작성 도구의 실행 기록을 다룹니다.
기초 용어는 특허 청구항 가이드, 명세서 전체 구성은 특허 명세서 작성 방법에서 이어서 확인할 수 있습니다.