KR20080032052A - 대화 분석 - Google Patents

Abstract

분석적 프로세스가 데이터를 로깅하고, 대화 차례(사용자-시스템 교환) 정보와 같은 대화 이동 정보를 이용하는 데 적용되어, 애플리케이션 내에서 가장 가능성 있는 문제들을 노출 및/또는 진단한다.

분석적 프로세스, 로깅된 데이터, 대화 차례, 대화 이동 정보

Description

대화 분석{DIALOG ANALYSIS}

이하의 설명은 단지 일반적인 배경 정보를 위해 제공된 것에 불과하며, 청구된 발명의 범위를 정하는 데 보조 수단으로 사용하기 위한 것이 아니다.

PDA(personal digital assistant), 장치 및 휴대 전화 등의 소형 컴퓨팅 장치가 일상 활동에서 사람들에 의해 점점 더 빈번하게 사용된다. 이들 장치를 동작시키는 데 사용되는 마이크로프로세서의 현재 이용가능한 처리 능력의 증가에 따라, 이들 장치의 기능이 증가되고 있으며, 어떤 경우에, 병합되고 있다. 예를 들어, 많은 휴대 전화는 이제 인터넷에 액세스하여 브라우징하는 데 사용될 수 있는 것은 물론 주소, 전화 번호, 기타 등등의 개인 정보를 저장하는 데도 사용될 수 있다.

따라서, 이들 컴퓨팅 장치가 점점 더 빈번히 사용되고 있는 것을 고려할 때, 사용자가 컴퓨팅 장치에 정보를 입력하기 쉬운 인터페이스를 제공하는 것이 필요하다. 불행히도, 이들 장치를 간편하게 가지고 다니기 위해 가능한 한 작게 유지하려는 바램으로 인해, 알파벳의 모든 문자를 분리된 버튼으로 갖는 종래의 키보드는 통상적으로 컴퓨팅 장치의 하우징 상의 이용가능한 제한된 표면 면적으로 인해 가능하지 않다. 소형 컴퓨팅 장치의 예가 아니더라도, 모든 유형의 컴퓨팅 장치에 대한 보다 편리한 인터페이스를 제공하는 데 관심이 있다.

이 문제를 해결하기 위해, 컴퓨팅 장치에서 로컬적으로든지, 근거리 통신망을 통해서든지 인터넷 등의 원거리 통신망을 통해서든지, 목소리 또는 음성을 사용하여 정보에 액세스하는 것에 대한 관심 및 그의 채택이 증가되었다. 음성 인식에 있어서, 대화 상호작용(dialog interaction)은 일반적으로 사용자와 컴퓨팅 장치 사이에서 수행된다. 사용자는 일반적으로 소리로(audibly) 및/또는 시각으로(visually) 정보를 수신하는 반면, 프롬프트 또는 발행 명령에 대해 소리로(audibly) 반응을 한다. 하지만, 종종 이것이 이용된 이후 또는 이용 동안에 애플리케이션의 성능을 확인하는 것이 바람직할 수 있다. 특히, 애플리케이션을 이용하여 사용자의 이용성 및/또는 성공률을 확인하는 것이 요망된다. 이런 정보로, 개발자는 애플리케이션의 사용자의 요구를 보다 충족시키기 위해 애플리케이션을 "조정"(즉, 조정을 행하는 것)할 수 있다. 예를 들어, 문제가 가장 일어날 것 같은, 애플리케이션과 사용자 간의 대화의 일부를 식별하는 것이 도움이 될 수 있다. 이런 방식으로, 대화의 이런 일부는 혼란을 경감시키도록 조정될 수 있다.

그럼에도 불구하고, 이용된 애플리케이션의 로그 데이터(예컨대, 음성 및 DTMF)로부터 대화 문제를 판정하는 것은 어렵다. 대화 문제는 본질적으로 상호작용의 흐름에 있어서의 사용자 경험의 문제이다. 그것들이 통상적으로 사용자 좌절을 초래하고, 중단(hang-up) 또는 조작자 도움에 대한 요청이 뒤따른다. 또한, 대화 문제는 비용 지원뿐만 아니라 고객의 나쁜-의도(ill-will)에 의해서 애플리케이션을 이용하는 엔티티에게는 비용이 많이 들게 한다.

대화 문제의 증상(낮은 작업 완료율 및 중단 또는 기타 취소의 증가)은 상당 히 분명하고, 이런 문제들의 원인은 찾아내기란 매우 어렵다. 통상적인 대화 문제는 시스템과 가까운 사용자 간의 작업에 대한 이해의 불일치의 결과인 경향이 있다. 그것들은 일반적으로 (시스템 에러 또는 사용자의 잘못된 이해에 의해) 잘못 취해지는 경로, 또는 혼란스럽게 하는 프롬프트와 같은 저 수준의 애플리케이션 문제로부터 발생한다.

다량의 세션 데이터는 통상적으로 진단을 수행하는 데 요구되지만, 다량의 세션 데이터는 이런 데이터의 수동 분석이 장황하고 지루한 프로세스임을 의미한다. 예를 들어, 장황하게 늘어난 대화는 일반적으로 혼란의 전체 전경을 표면화하기 위해 순서대로 요구되고, 이는 사용자에 걸쳐 일반화되어야 한다. 또한, 문제의 소스 위치(혼란이 시작되는 대화의 상태)를 지적하는 것은 어렵고; 임의의 주어진 중단 또는 다른 사용자 취소가 있는 경우, 문제의 소스 위치는 취소 이전에 수개의 차례일 수 있기 때문이다. 또한, 음성 애플리케이션은 자동화된 분석의 구현이 일반적으로 애플리케이션 특정되고, 확장성에 제한되는 그들의 사용자 상호작용 모델에서 매우 폭넓게 달라지는 경향이 있다. 최근의, 음성 인식 애플리케이션의 경우, 음성 인식기의 불완전성은 사용자 거동의 진정한 분석이 일반적으로 사용자 입력의 수동 필사 - 보조적이고 통상적으로 비용이 드는 프로세스 - 상에 기초해야 한다는 것을 의미한다.

이 요약은 이하의 상세한 설명에서 더 기술되는 몇몇 개념을 간단화된 형태로 소개하기 위해 제공된다. 이 요약은 청구된 발명의 주요 특징 또는 필수적인 특징을 확인하기 위한 것이 아니며, 청구된 발명의 범위를 정하는 데 보조 수단으로서 사용하기 위한 것도 아니다.

사용자/시스템 상호작용의 대화(예컨대, 음성, DTMF(dual tone modulated frequency) 등에 제한되지 않음) 분석은 각종 애플리케이션에 일반적인 가능성 있는 대화 문제를 식별하는 자동화된 기술을 제공하고, 응답/발화의 필사에 대한 요구를 제거할 수 있다. 분석적 프로세스는, 애플리케이션에서 가장 가능성 있는 문제를 노출 및/또는 진단하기 위해서, 데이터를 로깅하고, 대화 차례 (사용자-시스템 교환) 정보와 같은 대화 이동 정보를 이용하는 데 적용되며, 이는 예를 들어, 차례의 유형(새로운 정보를 요청하는 것, 값의 확인을 요청하는 것, 정보 문장을 제시하는 것, 기타), 및 프롬프트 유형(질문을 하는 것, 문장을 제시하는 것, 도움말을 제공하는 것, 정보 콘텐츠를 반복하는 것, '인식 없음'에 응답하는 것, 기타)를 포함하며, 이에만 제한되지 않는다.

예를 들어, 일주일에 수천개의 호출을 취하는 (음성 인식 또는 DTMF 입력을 갖는) 전화 시스템이 주어지면, 일주일의 호출에 대한 로그들 상에 데이터 분석이 실행될 수 있고, 그것은 애플리케이션의 모든 사용자에 의해 만족되는 가능성 있는 문제 영역을 하이라이트할 것이다. 데이터 분석은, 또한 문제의 유형의 표시를 제공할 수 있으며, 이는 예컨대, '실행 하에 있는(under-performing)" 진단 (작업), 즉 이것의 이유 및 그것들의 성공/실패율과는 상관없이 저 수준의 이용도를 나타내는 것; 프롬프트가 사용자를 혼란스럽게 하는 대화 상태; 상당한 수의 사용자에 대한 문제가 표면화되기 시작하는 대화 상태를 포함하며, 이에만 제한되지 않는다.

이런 데이터 분석의 결과로서, 애플리케이션을 조정하고 있는 개발자는 신속하게 분석을 수행하여, 많은 데이터 또는 호출을 분석할 필요 없이 필요한 상태 및 작업을 수리하고(fix), 및/또는 이들 문제의 유효성을 검증한다. 이는 상당한 시간 절감, 및 애플리케이션 유지 관리 및 조정의 상당한 비용 절감을 나타낸다.

도 1은 컴퓨팅 장치 동작 환경의 제1 실시예의 평면도.

도 2는 도 1의 컴퓨팅 장치의 블록도.

도 3은 범용 컴퓨터의 블록도.

도 4는 클라이언트/서버 시스템의 아키텍처의 블록도.

도 5는 클라이언트측 마크업(markup)에 인식 및 가청 프롬프트(audible prompting)를 제공하는 방법을 나타낸 블록도.

도 6은 부속 컨트롤(companion control)을 나타내는 블록도.

도 7은 음성 지원 애플리케이션을 생성하는 방법의 플로우차트.

도 8은 음성 지원 애플리케이션을 실행하는 방법의 플로우차트.

도 9는 대화 분석 모듈의 블록도.

도 10은 열악한 성능에 대하여 대화 분석을 수행하기 위한 방법의 플로우차트.

도 11은 프롬프트들을 혼란스럽게 하는 것에 대하여 대화 분석을 수행하기 위한 방법의 플로우차트.

도 12는 대화 문제의 소스를 식별하는 것에 대하여 대화 분석을 수행하기 위 한 방법의 플로우차트.

대화 분석(특히 음성 애플리케이션 및 DTMF에 제한되지 않음)을 기술하기 이전에, 음성 애플리케이션에서 사용될 수 있는 컴퓨팅 장치에 대해 전반적으로 기술하는 것이 유용할 수 있다. 이제 도 1을 참조하면, 예시적인 형태의 데이터 관리 장치(PIM, PDA 기타)가 30으로 나타내어져 있다. 그렇지만, 본 명세서에 기술된 개념들이 또한 이하에 논의되는 다른 컴퓨팅 장치들, 특히 입력 버튼, 기타 등등을 위한 제한된 표면 면적을 갖는 그 컴퓨팅 장치들을 사용하여 실시될 수 있는 것도 생각된다. 예를 들어, 전화 및/또는 데이터 관리 장치도 본 명세서에 기술되는 개념들로부터 이득을 보게 된다. 이러한 장치는 기존의 휴대용 개인 정보 관리 장치 및 기타 휴대용 전자 장치와 비교하여 향상된 유틸리티를 가지게 되며, 이러한 장치들의 기능 및 컴팩트한 크기로 인해 사용자가 그 장치를 항상 가지고 다니려고 할 가능성이 더 많다. 그에 따라, 본 명세서에 기술된 출원의 범위가 본 명세서에 설명되는 예시적인 데이터 관리 또는 PIM 장치, 전화 또는 컴퓨터에 대한 개시 내용에 의해 제한되는 것으로 보아서는 안된다.

예시적인 형태의 데이터 관리 모바일 장치(30)가 도 1에 도시되어 있다. 모바일 장치(30)는 하우징(32)을 포함하고, 스타일러스(stylus)와 함께 접촉 감응 디스플레이 화면(contact sensitive display screen)을 사용하는 디스플레이(34)를 포함하는 사용자 인터페이스를 갖는다. 스타일러스(33)는, 필드를 선택하기 위해, 커서의 시작 위치를 선택적으로 이동시키기 위해, 또는 제스처 또는 필기 등을 통 해 다른 방식으로 명령 정보를 제공하기 위해, 지정된 좌표에서 디스플레이(34)를 누르거나 만지는 데 사용된다. 다른 대안으로서 또는 그에 부가하여, 하나 이상의 버튼(35)이 내비게이션을 위해 장치(30) 상에 포함될 수 있다. 그에 부가하여, 회전가능 휠(rotatable wheel), 롤러(roller), 기타 등등의 다른 입력 메카니즘도 제공될 수 있다. 그렇지만, 유의할 점은 본 발명이 이들 형태의 입력 메카니즘에 의해 제한되는 것으로 보아서는 안된다는 것이다. 예를 들어, 다른 형태의 입력은 컴퓨터 시각(computer vision) 등을 통한 시각 입력(visual input)을 포함할 수 있다.

이제, 도 2를 참조하면, 블록도는 모바일 장치(30)를 구성하는 기능 컴포넌트를 나타낸 것이다. 중앙 처리 장치(CPU)(50)는 소프트웨어 제어 기능을 구현한다. CPU(50)는, 제어 소프트웨어에 따라 발생되는 텍스트 및 그래픽 아이콘이 디스플레이(34) 상에 나타나도록, 디스플레이(34)에 연결되어 있다. 스피커(43)는 가청 출력을 제공하기 위해 디지털-아날로그 변환기(59)를 사용하여 CPU(50)에 연결될 수 있다. 사용자에 의해 모바일 장치(30)로 다운로드 또는 입력되는 데이터는 CPU(50)에 양방향 연결되어 있는 비휘발성 판독/기록 랜덤 액세스 메모리 저장 장치(54)에 저장된다. 랜덤 액세스 메모리(RAM)(54)는 CPU(50)에 의해 실행되는 명령어의 휘발성 저장 및 레지스터 값 등의 일시적인 데이터의 저장을 제공한다. 구성 옵션 및 기타 변수에 대한 기본값(default valut)은 판독 전용 메모리(ROM)(58)에 저장된다. ROM(58)은 또한 모바일 장치(30)의 기본 기능 및 기타 운영 체제 커널 기능(예를 들어, 소프트웨어 컴포넌트를 RAM(54)에 로딩하는 것)을 제어하는 장치의 운영 체제 소프트웨어를 저장하는 데도 사용될 수 있다.

RAM(54)은 또한 애플리케이션 프로그램을 저장하는 데 사용되는 PC 상의 하드 드라이브의 기능과 유사한 방식으로 코드의 저장 장치로서도 기능한다. 유의할 점은 비휘발성 메모리가 코드를 저장하는 데 사용되지만, 다른 대안으로서 이 코드가 코드의 실행에 사용되지 않는 휘발성 메모리에 저장될 수 있다는 것이다.

CPU(50)에 연결되어 있는 무선 송수신기(52)를 통해 모바일 장치에 의해 무선 신호가 전송/수신될 수 있다. 컴퓨터(예를 들어, 데스크톱 컴퓨터)로부터 직접, 또는, 원하는 경우, 유선 네트워크를 통해 데이터를 다운로드하기 위해 선택적인 통신 인터페이스(60)도 제공될 수 있다. 그에 따라, 인터페이스(60)는 다양한 형태의 통신 장치, 예를 들어, 적외선 링크, 모뎀, 네트워크 카드, 기타 등등을 포함할 수 있다.

모바일 장치(30)는 마이크(29), 아날로그-디지털(A/D) 변환기(37) 및 저장 장치(54)에 저장되어 있는 선택적인 인식 프로그램(음성, DTMF, 필기, 제스처 또는 컴퓨터 시각)을 포함한다. 예로서, 장치(30)의 사용자로부터의 가청 정보(audible information), 지시 또는 명령에 응답하여, 마이크(29)는 음성 신호를 제공하고, 이 음성 신호는 A/D 변환기(37)에 의해 디지털화된다. 음성 인식 프로그램은 디지털화된 음성 신호에 대해 정규화 및/또는 특징 추출 기능을 수행하여 음성 인식 중간 결과를 획득할 수 있다. 무선 송수신기(52) 또는 통신 인터페이스(60)를 사용하여, 음성 데이터가 이하에서 논의되고 도 4의 아키텍처에 도시되어 있는 원격 인식 서버(204)로 전송될 수 있다. 인식 결과는 이어서 모바일 장치(30)로 반환되어 그 상에 렌더링(예를 들어, 시각적 및/또는 청각적)될 수 있으며, 궁극적으로 웹 서버(202)(도 4)로 전송될 수 있고, 여기서 웹 서버(202) 및 모바일 장치(30)는 클라이언트/서버 관계로 동작한다. 유사한 처리가 다른 형태의 입력에 사용될 수 있다. 예를 들어, 필기 입력이 장치(30) 상에서 전처리(pre-processing)를 하거나 하지 않고 디지털화될 수 있다. 음성 데이터와 같이, 이러한 형태의 입력은 인식을 위해 인식 서버(204)로 전송될 수 있으며, 여기서 이 인식 결과는 이어서 장치(20) 및/또는 웹 서버(202) 중 적어도 하나로 반환된다. 이와 마찬가지로, DTMF 데이터, 제스처 데이터 및 시각 데이터가 유사하게 처리될 수 있다. 입력의 형태에 따라, 장치(30)(및 이하에 기술되는 다른 형태의 클라이언트)는 시각 입력을 위한 카메라 등의 필요한 하드웨어를 포함하게 된다.

상기한 휴대용 또는 모바일 컴퓨팅 장치에 부가하여, 본 명세서에 기술되는 개념들이 일반 데스크톱 컴퓨터 등의 수많은 다른 컴퓨팅 장치에서 사용될 수 있다는 것도 잘 알 것이다. 예를 들어, 제한된 물리적 능력을 갖는 사용자는, 완전 영숫자 키보드(full alpha-numeric keyboard) 등의 다른 종래의 입력 장치가 조작하기 너무 어려운 경우, 컴퓨터 또는 기타 컴퓨팅 장치에 텍스트를 입력할 수 있다.

본 발명은 또한 수많은 다른 범용 또는 특수 목적의 컴퓨팅 시스템, 환경 또는 구성에서도 동작한다. 본 발명에서 사용하기에 적합할 수 있는 공지의 컴퓨팅 시스템, 환경 및/또는 구성의 예는 무선 또는 셀룰러 전화, 보통의 전화(화면이 없음), 퍼스널 컴퓨터, 서버 컴퓨터, 핸드-헬드 또는 랩톱 컴퓨터, 멀티프로세서 시스템, 마이크로프로세서-기반 시스템, 셋톱 박스, 프로그램가능 가전 제품, 네트워 크 PC, 미니컴퓨터, 메인프레임 컴퓨터, 상기 시스템들 또는 장치들 중 임의의 것을 포함하는 분산 컴퓨팅 환경, 기타 등등을 포함하지만, 이에 한정되는 것은 아니다.

이하는 도 3에 도시된 범용 컴퓨터(120)에 대한 간략한 설명이다. 그렇지만, 컴퓨터(120)는 다시 말하지만 적합한 컴퓨팅 환경의 일례에 불과하며, 본 발명의 용도 또는 기능성의 범위에 관해 어떤 제한을 암시하고자 하는 것이 아니다. 컴퓨터(120)가 컴퓨터(120)에 도시된 컴포넌트들 중 임의의 하나 또는 그 컴포넌트들의 임의의 조합과 관련하여 어떤 의존성 또는 요구사항을 갖는 것으로 해석되어서는 안된다.

이하의 설명은 일반적으로 컴퓨터에 의해 실행되는 프로그램 모듈과 같은 컴퓨터 실행가능 명령어와 관련하여 제공될 수 있다. 일반적으로, 프로그램 모듈은 특정 태스크를 수행하거나 특정 추상 데이터 유형을 구현하는 루틴, 프로그램, 객체, 컴포넌트, 데이터 구조 등을 포함한다. 본 명세서에 기술된 예시적인 실시예들은 또한 통신 네트워크를 통해 연결되어 있는 원격 처리 장치들에 의해 태스크가 수행되는 분산 컴퓨팅 환경에서 실시될 수도 있다. 분산 컴퓨팅 환경에서, 프로그램 모듈은 메모리 저장 장치를 비롯한 로컬 및 원격 컴퓨터 저장 매체 둘다에 위치할 수 있다. 프로그램 및 모듈에 의해 수행되는 태스크들이 도면을 참조하여 이하에 기술되어 있다. 당업자라면 임의의 형태의 컴퓨터 판독가능 매체 상에 기록될 수 있는 프로세서 실행가능 명령어로서 이 설명 및 도면을 구현할 수 있다.

도 3을 참조하면, 컴퓨터(120)의 컴포넌트들은 처리 장치(140), 시스템 메모 리(150), 및 시스템 메모리를 비롯한 각종 시스템 컴포넌트들을 처리 장치(140)에 연결시키는 시스템 버스(141)를 포함하지만 이에 제한되는 것은 아니다. 시스템 버스(141)는 메모리 버스 또는 메모리 컨트롤러, 주변 장치 버스 및 각종 버스 아키텍처 중 임의의 것을 이용하는 로컬 버스를 비롯한 몇몇 유형의 버스 구조 중 어느 것이라도 될 수 있다. 예로서, 이러한 아키텍처는 ISA(industry standard architecture) 버스, USB(Universal Serial Bus), MCA(micro channel architecture) 버스, EISA(Enhanced ISA) 버스, VESA(video electronics standard association) 로컬 버스, 그리고 메자닌 버스(mezzanine bus)로도 알려진 PCI(peripheral component interconnect) 버스 등을 포함하지만 이에 제한되는 것은 아니다. 컴퓨터(120)는 통상적으로 각종 컴퓨터 판독가능 매체를 포함한다. 컴퓨터(120)에 의해 액세스 가능한 매체는 그 어떤 것이든지 컴퓨터 판독가능 매체가 될 수 있고, 이러한 컴퓨터 판독가능 매체는 휘발성 및 비휘발성 매체, 이동식 및 비이동식 매체 둘다를 포함한다. 예로서, 컴퓨터 판독가능 매체는 컴퓨터 저장 매체 및 통신 매체를 포함할 수 있지만 이에 제한되는 것은 아니다. 컴퓨터 저장 매체는 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 또는 기타 데이터와 같은 정보를 저장하는 임의의 방법 또는 기술로 구현되는 휘발성 및 비휘발성, 이동식 및 비이동식 매체 둘다를 포함하지만, 이에 한정되는 것은 아니다. 컴퓨터 저장 매체는 RAM, ROM, EEPROM, 플래시 메모리 또는 기타 메모리 기술, CD-ROM, DVD(digital versatile disk) 또는 기타 광 디스크 저장 장치, 자기 카세트, 자기 테이프, 자기 디스크 저장 장치 또는 기타 자기 저장 장치, 또는 컴퓨터(120)에 의 해 액세스될 수 있고 원하는 정보를 저장하는 데 사용될 수 있는 임의의 기타 매체를 포함하지만 이에 제한되는 것은 아니다.

통신 매체는 통상적으로 반송파(carrier wave) 또는 기타 전송 메커니즘(transport mechanism)과 같은 피변조 데이터 신호(modulated data signal)에 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 또는 기타 데이터 등을 구현하고 모든 정보 전달 매체를 포함한다. "피변조 데이터 신호"라는 용어는, 신호 내에 정보를 인코딩하도록 그 신호의 특성들 중 하나 이상을 설정 또는 변경시킨 신호를 의미한다. 예로서, 통신 매체는 유선 네트워크 또는 직접 배선 접속(direct-wired connection)과 같은 유선 매체, 그리고 음향, RF, 적외선, 기타 무선 매체와 같은 무선 매체를 포함하지만, 이에 한정되는 것은 아니다. 상술된 매체들 중 임의의 것의 조합이 또한 컴퓨터 판독가능 매체의 영역 안에 포함되는 것으로 한다.

시스템 메모리(150)는 판독 전용 메모리(ROM)(151) 및 랜덤 액세스 메모리(RAM)(152)와 같은 휘발성 및/또는 비휘발성 메모리 형태의 컴퓨터 저장 매체를 포함한다. 시동 중과 같은 때에, 컴퓨터(120) 내의 구성요소들 사이의 정보 전송을 돕는 기본 루틴을 포함하는 기본 입/출력 시스템(BIOS)(153)은 통상적으로 ROM(151)에 저장되어 있다. RAM(152)은 통상적으로 처리 장치(140)가 즉시 액세스 할 수 있고 및/또는 현재 동작시키고 있는 데이터 및/또는 프로그램 모듈을 포함한다. 예로서, 도 3은 운영 체제(154), 애플리케이션 프로그램(155), 기타 프로그램 모듈(156) 및 프로그램 데이터(157)를 도시하고 있지만 이에 제한되는 것은 아니다.

컴퓨터(120)는 또한 기타 이동식/비이동식, 휘발성/비휘발성 컴퓨터 저장매체를 포함할 수 있다. 단지 예로서, 도 3은 비이동식·비휘발성 자기 매체에 기록을 하거나 그로부터 판독을 하는 하드 디스크 드라이브(161), 이동식·비휘발성 자기 디스크(172)에 기록을 하거나 그로부터 판독을 하는 자기 디스크 드라이브(171), 및 CD-ROM 또는 기타 광 매체 등의 이동식·비휘발성 광 디스크(176)에 기록을 하거나 그로부터 판독을 하는 광 디스크 드라이브(175)를 나타내고 있다. 예시적인 운영 환경에서 사용될 수 있는 기타 이동식/비이동식, 휘발성/비휘발성 컴퓨터 저장 매체로는 자기 테이프 카세트, 플래시 메모리 카드, DVD, 디지털 비디오 테이프, 고상(solid state) RAM, 고상 ROM 등이 있지만 이에 제한되는 것은 아니다. 하드 디스크 드라이브(161)는 통상적으로 인터페이스(160)와 같은 비이동식 메모리 인터페이스를 통해 시스템 버스(141)에 접속되고, 자기 디스크 드라이브(171) 및 광 디스크 드라이브(175)는 통상적으로 인터페이스(170)와 같은 이동식 메모리 인터페이스에 의해 시스템 버스(141)에 접속된다.

위에서 설명되고 도 3에 도시된 드라이브들 및 이들과 관련된 컴퓨터 저장 매체는, 컴퓨터(120)에 대한 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 및 기타 데이터를 저장한다. 도 3에서, 예를 들어, 하드 디스크 드라이브(161)는 운영 체제(164), 애플리케이션 프로그램(165), 기타 프로그램 모듈(166), 및 프로그램 데이터(167)를 저장하는 것으로 도시되어 있다. 여기서 주의할 점은 이들 컴포넌트가 운영 체제(154), 애플리케이션 프로그램(155), 기타 프로그램 모듈(156), 및 프로그램 데이터(157)와 동일하거나 그와 다를 수 있다는 것이다. 이에 관해, 운영 체제(164), 애플리케이션 프로그램(165), 기타 프로그램 모듈(166) 및 프로그램 데이터(167)에 다른 번호가 부여되어 있다는 것은 적어도 이들이 다른 사본(copy)이라는 것을 나타내기 위한 것이다.

사용자는 키보드(182), 마이크(183) 및 마우스, 트랙볼(trackball) 또는 터치 패드와 같은 포인팅 장치(181) 등의 입력 장치를 통해 명령 및 정보를 컴퓨터(120)에 입력할 수 있다. 다른 입력 장치(도시 생략)로는 조이스틱, 게임 패드, 위성 안테나, 스캐너 등을 포함할 수 있다. 이들 및 기타 입력 장치는 종종 시스템 버스에 결합된 사용자 입력 인터페이스(180)를 통해 처리 장치(140)에 접속되지만, 병렬 포트, 게임 포트 또는 USB(universal serial bus) 등의 다른 인터페이스 및 버스 구조에 의해 접속될 수도 있다. 모니터(184) 또는 다른 유형의 디스플레이 장치도 비디오 인터페이스(185) 등의 인터페이스를 통해 시스템 버스(141)에 접속될 수 있다. 모니터 외에, 컴퓨터는 스피커(187) 및 프린터(186) 등의 기타 주변 출력 장치를 포함할 수 있고, 이들은 출력 주변장치 인터페이스(188)를 통해 접속될 수 있다.

컴퓨터(120)는 원격 컴퓨터(194)와 같은 하나 이상의 원격 컴퓨터로의 논리적 접속을 사용하여 네트워크화된 환경에서 동작할 수 있다. 원격 컴퓨터(194)는 퍼스널 컴퓨터, 핸드-헬드 장치, 서버, 라우터, 네트워크 PC, 피어 장치 또는 기타 통상의 네트워크 노드일 수 있고, 통상적으로 컴퓨터(120)와 관련하여 상술된 구성요소들의 대부분 또는 그 전부를 포함한다. 도 3에 도시된 논리적 접속으로는 LAN(local area network)(191) 및 WAN(wide area network)(193)이 있지만, 기타 네 트워크를 포함할 수도 있다. 이러한 네트워킹 환경은 사무실, 전사적 컴퓨터 네트워크(enterprise-wide computer network), 인트라넷, 및 인터넷에서 일반적인 것이다.

LAN 네트워킹 환경에서 사용될 때, 컴퓨터(120)는 네트워크 인터페이스 또는 어댑터(190)를 통해 LAN(191)에 접속된다. WAN 네트워킹 환경에서 사용될 때, 컴퓨터(120)는 통상적으로 인터넷과 같은 WAN(193)을 통해 통신을 설정하기 위한 모뎀(192) 또는 기타 수단을 포함한다. 내장형 또는 외장형일 수 있는 모뎀(192)은 사용자 입력 인터페이스(180) 또는 기타 적절한 메커니즘을 통해 시스템 버스(141)에 접속될 수 있다. 네트워크화된 환경에서, 컴퓨터(120) 또는 그의 일부와 관련하여 기술된 프로그램 모듈은 원격 메모리 저장 장치에 저장될 수 있다. 예로서, 도 3은 원격 애플리케이션 프로그램(195)이 원격 컴퓨터(194)에 있는 것으로 도시하고 있지만 이에 제한되는 것은 아니다. 도시된 네트워크 접속은 예시적인 것이며 이 컴퓨터들 사이에 통신 링크를 설정하는 기타 수단이 사용될 수 있다는 것을 이해할 것이다.

예시적인 실시예

도 4는 본 명세서에 기술된 개념들과 함께 사용될 수 있는 네트워크 기반 인식(여기서, 원거리 통신망을 예시함)을 위한 아키텍처(200)를 나타낸 것이다. 그렇지만, 인식기를 포함하는 음성 애플리케이션이 모든 필요한 컴포넌트 또는 모듈이 그 안에 존재하는 단일의 컴퓨팅 장치 상에서 동작할 수 있다는 점에서 원격 컴포넌트와의 상호작용이 일 실시예에 불과하다는 것을 잘 알 것이다.

일반적으로, 웹 서버(202)에 저장된 정보는 모바일 장치(30)(본 명세서에서, 필요에 따라 입력의 형태에 기초하여, 디스플레이 화면, 마이크, 카메라, 터치 감응 패널, 기타 등등을 갖는 다른 형태의 컴퓨팅 장치도 나타냄)를 통해 또는 전화(80)를 통해(이 경우, 정보는 소리로(audibly) 또는 눌러진 키에 응답하여 전화(80)에 의해 발생되는 톤(tone)을 통해 요청되며, 웹 서버(202)로부터의 정보는 단지 소리로만 사용자에게 다시 제공됨) 액세스될 수 있다.

이 예시적인 실시예에서, 아키텍처(200)는, 음성 인식을 사용하여 정보가 장치(30)를 통해 또는 전화(80)를 통해 획득되는지에 상관없이, 단일의 인식 서버(204)가 어느 한 동작 모드를 지원할 수 있다는 점에서 통합되어 있다. 그에 부가하여, 아키텍처(200)는 공지의 마크업 언어(예를 들어, HTML, XHTML, cHTML, XML, WML, 기타)의 확장을 사용하여 동작한다. 따라서, 웹 서버(202) 상에 저장된 정보는 또한 이들 마크업 언어에서 발견되는 공지의 GUI 메서드를 사용하여 액세스될 수 있다. 공지의 마크업 언어의 확장을 사용함으로써, 웹 서버(202) 상에서의 저작(authoring)이 더 쉬우며, 현재 존재하는 레거시 애플리케이션도 음성 또는 기타 형태의 인식을 포함하도록 용이하게 수정될 수 있다.

일반적으로, 장치(30)는 웹 서버(202)에 의해 제공되는 HTML+ 스크립트, 기타 등등을 실행한다. 예로서, 음성 인식이 요구되는 경우, 디지털화된 오디오 신호 또는 음성 특징(여기서, 오디오 신호는 상기한 바와 같이 장치(30)에 의해 전처리되어 있음)일 수 있는 음성 데이터가 음성 인식 동안에 사용할 문법 또는 언어 모델의 표시와 함께 인식 서버(204)에 제공된다. 인식 서버(204)의 구현은 많은 형태(이들 중 하나가 예시됨)를 취할 수 있지만, 일반적으로 인식기를 포함한다. 인식의 결과는 원하는 경우 또는 적절한 경우 로컬 렌더링(local rendering)을 위해 다시 장치(30)에 제공된다. 인식 및, 사용되는 경우, 임의의 그래픽 사용자 인터페이스를 통해 정보를 컴파일할 시에, 장치(30)는, 필요한 경우, 추가의 처리 및 추가의 HTML 스크립트의 수신을 위해 웹 서버(202)로 정보를 전송한다.

도 4에 나타낸 바와 같이, 장치(30), 웹 서버(202) 및 인식 서버(204)는 네트워크(205)(여기에서, 인터넷 등의 원거리 통신망)를 통해 공통으로 연결되어 있고, 개별적으로 주소 지정가능하다. 따라서, 이들 장치 중 임의의 것이 물리적으로 서로에 인접하여 위치될 필요는 없다. 상세하게는, 웹 서버(202)가 인식 서버(204)를 포함할 필요가 없다. 이와 같이, 웹 서버(202)에서의 저작은 저작자가 인식 서버(204)의 복잡한 세부를 알 필요가 없이 그가 목적하는 애플리케이션에 집중될 수 있다. 오히려, 인식 서버(204)는 독립적으로 설계 및 네트워크(205)에 연결될 수 있고, 그에 따라 웹 서버(202)에 추가적인 변경이 필요 없이 갱신 및 개선될 수 있다. 이하에서 기술하는 바와 같이, 웹 서버(202)는 또한 클라이언트측 마크업 및 스크립트를 동적으로 발생할 수 있는 저작 메카니즘을 포함할 수 있다. 다른 실시예에서, 웹 서버(202), 인식 서버(204) 및 클라이언트(30)는 구현하는 기계의 능력에 따라 결합될 수 있다. 예를 들어, 클라이언트가 범용 컴퓨터, 예를 들어, 퍼스널 컴퓨터를 포함하는 경우, 클라이언트는 인식 서버(204)를 포함할 수 있다. 이와 유사하게, 원하는 경우, 웹 서버(202) 및 인식 서버(204)는 단일의 기계 내에 포함될 수 있다.

전화(80)를 통한 웹 서버(202)에의 액세스는 전화(80)의 유선 또는 무선 전화 네트워크(208)에의 연결을 포함하고, 이 네트워크(208)는 차례로 전화(80)를 제3자 게이트웨이(210)에 연결시킨다. 게이트웨이(210)는 전화(80)를 전화 음성 브라우저(telepholy voice browser)(212)에 연결시킨다. 전화 음성 브라우저(212)는 전화 인터페이스(telepholy interface)를 제공하는 미디어 서버(214) 및 음성 브라우저(216)를 포함한다. 장치(30)와 같이, 전화 음성 브라우저(212)는 웹 서버(202)로부터 HTML 스크립트, 기타 등등을 수신한다. 일 실시예에서, HTML 스크립트는 장치(30)에 제공되는 HTML 스크립트와 유사한 형태를 갖는다. 이와 같이, 웹 서버(202)는 장치(30) 및 전화(80)를 따로따로 지원할 필요가 없거나 표준의 GUI 클라이언트조차도 따로 지원할 필요가 없다. 오히려, 통상의 마크업 언어가 사용될 수 있다. 그에 부가하여, 장치(30)와 같이, 전화(80)에 의해 전송되는 가청 신호로부터의 음성 인식은, 네트워크(205)를 통하거나 전용 회선(207)을 통해, 예를 들어, TCP/IP를 사용하여, 음성 브라우저(216)로부터 인식 서버(204)로 제공된다. 웹 서버(202), 인식 서버(204) 및 전화 음성 브라우저(212)는, 도 3에 도시한 범용 데스크톱 컴퓨터 등의, 임의의 적합한 컴퓨팅 환경에 구현될 수 있다.

그렇지만, 유의할 점은, DTMF 인식이 이용되는 경우, 이러한 형태의 인식이 인식 서버(204)에서보다는 일반적으로 미디어 서버(214)에서 수행된다는 것이다. 환언하면, DTMF 문법이 미디어 서버(214)에서 사용된다.

다시 도 4를 참조하면, 웹 서버(202)는 서버측 플러그인 저작 도구 또는 모듈(209)(예를 들어, 마이크로소프트사의 ASP, ASP+, ASP.NET, JSP, Javabeans, 기 타 등등)을 포함할 수 있다. 서버측 플러그인 모듈(209)은 클라이언트측 마크업 및 심지어 웹 서버(202)에 액세스하는 유형의 클라이언트에 대한 특정의 형태의 마크업을 동적으로 발생할 수 있다. 클라이언트/서버 관계의 초기 설정 시에 클라이언트 정보가 웹 서버(202)에 제공될 수 있거나, 웹 서버(202)가 클라이언트 장치의 성능을 검출하는 모듈 또는 루틴을 포함할 수 있다. 이와 같이, 서버측 플러그인 모듈(209)은 각각의 음성 인식 시나리오, 즉 전화(80)를 통한 음성 전용(voice only) 또는 장치(30)에 대한 다중-모드(multimodal)에 대한 클라이언트측 마크업을 발생할 수 있다. 일관된 클라이언트측 모델을 사용함으로써, 많은 서로 다른 클라이언트에 대한 애플리케이션 저작이 상당히 더 쉽다.

클라이언트측 마크업을 동적으로 발생하는 것에 부가하여, 이하에 기술되는 상위 레벨 대화 모듈(high-level dialog module)은 애플리케이션 저작 시에 개발자가 사용하기 위한 저장 장치(211)에 저장된 서버측 컨트롤(server-side control)로서 구현될 수 있다. 일반적으로, 상위 레벨 대화 모듈(211)은 개발자에 의해 지정된 파라미터에 기초하여 음성-전용 및 다중-모드 시나리오 둘다에서 클라이언트측 마크업 및 스크립트를 동적으로 발생한다. 상위 레벨 대화 모듈(211)은 개발자의 요구에 맞도록 클라이언트측 마크업을 발생하는 파라미터를 포함할 수 있다.

클라이언트측 마크업의 발생

상기한 바와 같이, 서버측 플러그인 모듈(209)은 클라이언트 장치(30)로부터 요청이 행해졌을 때 클라이언트측 마크업을 출력한다. 요약하면, 서버측 플러그인 모듈(209)은 웹사이트, 따라서 애플리케이션 및 애플리케이션에 의해 제공되는 서 비스가 정의 또는 구성될 수 있게 해준다. 서버측 플러그인 모듈(209)에서의 명령어는 컴파일된 코드로 이루어져 있다. 이 코드는 웹 요청이 웹 서버(202)에 도달할 때 실행된다. 서버측 플러그인 모듈(209)은 이어서 클라이언트 장치(30)로 전송되는 새로운 클라이언트측 마크업 페이지를 출력한다. 잘 알려진 바와 같이, 이 프로세스는 통상 렌더링이라고 한다. 서버측 플러그인 모듈(209)은 마크업 언어를 추상화 및 캡슐화하는 "컨트롤", 따라서 클라이언트측 마크업 페이지의 코드에 작용한다. 마크업 언어를 추상화 및 캡슐화하고 웹 서버(202)에 작용하는 이러한 컨트롤은, 몇가지를 열거하면, "서블릿(Servelet)", 즉 "서버측 플러그인"을 포함하거나 이와 동등하다.

잘 알고 있는 바와 같이, 종래 기술의 서버측 플러그인 모듈은 시각 렌더링(visual rendering) 및 클라이언트 장치(30)와의 상호작용을 위해 클라이언트측 마크업을 발생할 수 있다. 2004년 6월 17일자로 공개된 발명의 명칭이 "웹 지원 인식 및/또는 가청 프롬프트를 위한 웹 서버 컨트롤(Web Server Controls for Web Enabled Recognition and/or Audible Prompting)"인 미국 특허 출원 공개 제2004/0113908호 및 2004년 11월 18일자로 공개된 발명의 명칭이 "음성 지원 인식을 위한 애플리케이션 컨트롤(Application Controls for Speech Enabled Recognition)"인 미국 특허 출원 공개 제2004/0230637A1호 둘다는 인식 및 가청 프롬프트 확장을 포함시키기 위해 서버측 플러그인 모듈(209)을 확장하는 3가지 서로 다른 방법을 상세히 기술하고 있다. 본 발명의 측면들이 이들 방법 전부에서 사용될 수 있지만, 예시적인 실시예를 설명하기 위해 이하에서 한가지 방법의 상세한 설명이 제공된다.

도 5를 참조하면, 인식/가청 프롬프트 컨트롤(306)은 시각 컨트롤(302)과 분리되어 있지만, 이하에 기술하는 바와 같이 선택적으로 그와 연관되어 있다. 이와 같이, 컨트롤(306)은 시각 컨트롤(302) 상에 직접 구축되지 않고 오히려 시각 컨트롤(302)을 재작성할 필요없이 인식/가청 프롬프트 인에이블(recognition/audible prompting enablement)을 제공한다. 컨트롤(306)은, 컨트롤(302)와 같이, 라이브러리(300)를 사용한다. 이 실시예에서, 라이브러리(300)는 시각 및 인식/가청 프롬프트 마크업 정보를 포함하고 있다.

이 방법에는 상당한 이점이 있다. 첫째, 시각 컨트롤(302)의 내용이 변경될 필요가 없다. 둘째, 컨트롤(306)이 일관성있고 음성-지원 컨트롤(302)의 특성에 따라 변할 필요가 없는 단일의 모듈을 형성할 수 있다. 셋째, 음성 인에이블의 프로세스, 즉 컨트롤(306)을 시각 컨트롤(302)과 명시적으로 연관시키는 것이 디자인 시에 전적으로 개발자의 제어 하에 있는데, 그 이유는 그것이 명시적이고 선택적인 프로세스이기 때문이다. 이것은 또한, 컨트롤(306)에 의해 발생되는 마크업 언어에 의해 제공되는 인식을 통하거나 키보드 등의 종래의 입력 장치를 통하는 등에 의해, 시각 컨트롤의 마크업 언어가 다수의 소스로부터 입력값을 수신하는 것을 가능하게 만들어준다. 요약하면, 컨트롤(306)이 서버측 플러그인 모듈(209)의 시각 저작 페이지의 기존의 애플리케이션 저작 페이지에 추가될 수 있다. 컨트롤(306)은, 시각 컨트롤의 애플리케이션 논리 및 시각 입/출력 기능을 재사용하면서, 클라이언트 장치(30)의 사용자에게 새로운 상호작용 모달리티(modality of interaction)(즉, 인식 및/또는 가청 프롬프트)를 제공한다. 컨트롤(306)이 시각 컨트롤(302)과 연관될 수 있는 반면 애플리케이션 논리가 코딩될 수 있는 것을 고려할 때, 컨트롤(306)은 이후부터 "부속 컨트롤(companion control)(306)"이라고 할 수 있으며, 시각 컨트롤(302)는 "주 컨트롤(primary control)(302)"이라고 할 수 있다. 유의할 점은 이들 언급이 컨트롤(302, 306)을 구분하기 위해 제공된 것이며 제한하려는 것이 아니라는 것이다. 예를 들어, 부속 컨트롤(306)은 음성-전용 웹사이트 등의 시각 렌더링을 포함하지 않는 웹사이트를 개발 또는 저작하는 데 사용될 수 있다. 이러한 경우에, 어떤 애플리케이션 논리가 부속 컨트롤 논리에 구현될 수 있다.

예시적인 일련의 부속 컨트롤(400)이 도 6에 나타내어져 있다. 이 실시예에서, 부속 컨트롤(400)은 일반적으로 QA 컨트롤(402), Command 컨트롤(404), CompareValidator 컨트롤(406), CustomValidator 컨트롤(408) 및 의미 맵(semantic map)(410)을 포함한다. 의미 맵(410)이 개략적으로 나타내어져 있으며 시각 영역 주 컨트롤(402)(예를 들어, HTML)과 부속 컨트롤(400)의 비시각 인식 영역 간에 계층을 형성하는 의미 항목(semantic item)(412)(입력 필드로서 간주될 수 있음)을 포함한다.

QA 컨트롤(402)은 출력 컨트롤의 기능을 수행하는, 즉 사전 녹음된 오디오 파일, 또는 텍스트-음성 변환(text-to-speech conversion)을 위한 텍스트, 마크업에 직접 포함된 또는 URL을 통해 참조되는 데이터의 재생을 통상 포함하는 사람 대화에 대한 "프롬프트하는" 클라이언트측 마크업을 제공하는 Prompt 객체를 참조하 는 Prompt 객체를 포함한다. 이와 유사하게, 입력 컨트롤은 QA 컨트롤(402) 및 Command 컨트롤(404)로서 구현되고, 또한 사람 대화를 따라가며, (Prompt 객체를 참조하는) Prompt 속성 및 적어도 하나의 Answer 객체를 참조하는 Answer 속성을 포함한다. QA 컨트롤(402) 및 Command 컨트롤(404)은 문법을 클라이언트 장치(30)의 사용자로부터의 예상된 또는 가능한 입력과 연관시킨다.

이 시점에서, 각각의 컨트롤에 대한 간략한 설명을 제공하는 것이 도움이 될지도 모른다.

QA 컨트롤

일반적으로, 예시된 속성들을 통한 QA 컨트롤(402)은 이하의 것들, 몇가지를 열거하자면, 출력 가청 프롬프트를 제공하는 일, 입력 데이터를 수집하는 일, 입력 결과의 신뢰도 유효성 검사(confidence validation)를 수행하는 일, 입력 데이터의 확인을 가능하게 해주는 일, 및 웹사이트에서의 대화 흐름의 제어를 돕는 일 중 하나 이상을 수행할 수 있다. 환언하면, QA 컨트롤(402)은 특정의 주제에 대한 컨트롤로서 기능하는 속성들을 포함한다.

QA 컨트롤(402)은, 나머지 컨트롤들과 같이, 웹 서버(202) 상에서 실행되며, 이는 그것이 서버측 마크업 형식(server-side markup formalism)(ASP, JSP 기타)을 사용하여 웹 서버 상에 보유되는 애플리케이션 개발 웹 페이지 상에서 정의되지만 클라이언트 장치(30)에 다른 형태의 마크업으로서 출력된다는 것을 의미한다. QA 컨트롤이 Prompt, Reco, Answers, ExtraAnswers 및 Confirms 속성들 모두로 형성되어 있는 것처럼 도 6에 도시되어 있지만, 이들이 단지 옵션에 불과하며 하나 이상 이 QA 컨트롤에 포함될 수 있다는 것을 잘 알 것이다.

이 시점에서, 애플리케이션 시나리오와 관련하여 QA 컨트롤(402)의 용도에 대해 설명하는 것이 도움이 될지도 모른다. 도 6을 참조하면, 음성-전용 애플리케이션에서, QA 컨트롤(402)은 대화에서의 질문/대답으로서 기능할 수 있다. 질문은 Prompt 객체에 의해 제공되는 반면, 문법은 입력 데이터 및 그 입력에 대한 관련 처리의 인식을 위한 문법 객체를 통해 정의된다. Answers 속성은 인식 결과를 어떻게 처리할지에 관한 정보를 포함하는 Answer 객체를 사용하여 인식된 결과를 의미 맵(410) 내의 SemanticItem(412)과 연관시킨다. 라인(414)은 QA 컨트롤(402)을 의미 맵(410)과 연관시키고 또 그 안의 SemanticItem(412)에 연관시키는 것을 나타낸다. 많은 SemanticItem(412)은, 라인(418)으로 나타낸 바와 같이, 시각 또는 주 컨트롤(302)과 개별적으로 연관되어 있지만, 하나 이상의 SemanticItem(412)이 시각 컨트롤과 연관되어 있지 않을 수 있으며 단지 내부적으로만 사용될 수 있다. 다중-모드 시나리오에서, 클라이언트 장치(30)의 사용자가, 예를 들어, "TapEvent"로 시각 텍스트박스 상에서 터치를 할 수 있는 경우, 가청 프롬프트가 필요하지 않을 수 있다. 예를 들어, 클라이언트 장치의 사용자가 대응하는 필드에 무엇을 입력해야만 하는지의 표시를 형성하는 시각 텍스트를 갖는 텍스트박스를 포함하는 주 컨트롤의 경우, 대응하는 QA 컨트롤(402)은 오디오 재생 또는 텍스트-음성 변환 등의 대응하는 프롬프트를 갖거나 갖지 않을 수 있지만, 인식을 위한 예상된 값에 대응하는 문법(grammar) 및 입력을 처리하는 이벤트 핸들러(event handler)를 가지거나 검출된 음성 없음, 음성 인식되지 않음 또는 타임아웃 시에 실행되는 이벤트 등 의 다른 인식기 이벤트(recognizer event)를 처리한다.

다른 실시예에서, 인식 결과는 인식된 결과가 정확했다는 신뢰도의 수준을 나타내는 신뢰도 수준 척도(confidence level measure)를 포함한다. 확인 임계값(confirmation threshold)도 Answer 객체에 지정될 수 있으며, 예를 들어 ConfirmThreshold는 0.7이다. 확인 수준(confirmation level)이 연관된 임계값을 초과하는 경우, 결과는 확인된 것으로 간주될 수 있다.

유의할 점은, 음성 인식을 위한 문법을 지정하는 것에 부가하여 또는 다른 대안으로서, QA 컨트롤 및/또는 Command 컨트롤이 프롬프트 또는 질문에 응답하여 전화 키 작동을 인식하는 Dtmf(dual tone modulated frequency) 문법을 지정할 수 있다는 것이다.

이 시점에서, 유의할 점은, 의미 맵(410)의 SemanticItem(412)이 인식, 예를 들어, 음성 또는 Dtmf를 통해 채워질 때, 몇가지 조치가 취해질 수 있다는 것이다. 첫째, 값이 "변경"되었음을 나타내는 이벤트가 발행 또는 실행될 수 있다. 확인 수준이 만족되었는지에 따라, 발행 또는 실행될 수 있는 다른 이벤트가 대응하는 의미 항목이 확인되었음을 나타내는 "확인" 이벤트(confirm event)를 포함한다. 이들 이벤트는 대화를 제어하는 데 사용된다.

Confirms 속성은 또한, SemanticItem(412)과 연관되어 있다는 점에서, Answers 속성과 관련하여 상기한 것과 유사한 구조를 갖는 Answer 객체를 포함할 수 있으며, 원하는 경우 ConfirmThreshold를 포함할 수 있다. Confirms 속성은 인식 결과 자체를 획득하기 위한 것이 아니라, 오히려 이미 획득된 결과를 확인하고 사용자로부터 획득된 결과가 올바른지 여부를 확인하기 위한 것이다. Confirms 속성은 이전에 획득된 결과의 값이 올바른지 여부를 나타내는 데 사용되는 Answer 객체의 집합체이다. 내포하는 QA의 Prompt 객체는 이들 항목에 관하여 질문을 하고 연관된 SemanticItem(412)으로부터 인식 결과를 획득하여 "Did you say Seattle?" 등의 질문으로 이를 형성한다. 사용자가 "Yes" 등의 긍정으로 응답하는 경우, 확인된 이벤트가 실행된다. 사용자가 "No" 등의 부정으로 응답하는 경우, 연관된 SemanticItem(412)가 클리어된다.

Confirms 속성은 또한 확인 프롬프트가 사용자에게 제공된 후에 정정을 받을 수 있다. 예를 들어, 확인 프롬프트 "Did you say Seattle?"에 응답하여, 사용자는 "San Francisco" 또는 "No, San Francisco"라고 응답할 수 있으며, 이 경우에 QA 컨트롤은 정정을 수신하였다. Answer 객체를 통해 어느 SemanticItem이 확인되고 있는지에 관한 정보를 갖는 경우, SemanticItem 내의 값은 정정된 값으로 교체될 수 있다. 또한, 유의할 점은, 원하는 경우, 확인이 "When did you want to go to Seattle?" 등의 정보를 위한 추가의 프롬프트에 포함될 수 있다는 것이며, 여기서 시스템에 의한 프롬프트는 "Seattle"에 대한 확인 및 출발일에 대한 추가의 프롬프트를 포함한다. 목적지에 대한 정정을 제공하는 사용자에 의한 응답은 연관된 의미 항목을 정정하기 위해 Confirms 속성을 활성화시키는 반면, 출발일만을 갖는 응답은 암시적인 목적지 확인을 제공한다.

ExtraAnswers 속성에 의해 애플리케이션 저작자는 사용자가 행해진 프롬프트 또는 쿼리에 부가하여 제공할 수 있는 Answer 객체를 지정할 수 있게 된다. 예를 들어, 여행 중심 시스템은 목적지 도시를 얻기 위해 사용자를 프롬프트하지만 사용자가 "Seattle tomorrow"로 응답하는 경우, 최초로 사용자를 프롬프트한 Answers 속성은 목적지 도시 "Seattle"을 검사하고 따라서 이를 해당 SemanticItem에 바인딩하는 반면, ExtraAnswers 속성은 "Tomorrow"를 그 다음 익일(succeeding day)(시스템이 금일(current day)을 알고 있는 것으로 가정함)로서 처리하고 그에 따라 이 결과를 의미 맵 내의 해당 SemanticItem에 바인딩할 수 있다. ExtraAnswers 속성은 사용자가 역시 말할 수 있는 가능한 추가 정보에 대해 정의되는 하나 이상의 Answer 객체를 포함한다. 이상에 제공된 예에서, 출발일에 관한 정보도 검색한 경우, 확인 수준이 대응하는 ConfirmThreshold를 초과한 것으로 가정하여 시스템은 이 정보를 얻기 위해 사용자를 재프롬프트할 필요가 없다. 확인 수준이 대응하는 임계값을 초과하지 않은 경우, 적절한 Confirms 속성이 활성화된다.

Command 컨트롤

Command 컨트롤(404)은 일반적으로 묻는 질문과 관련하여 의미(semantic import)를 거의 갖지 않지만 도움 또는 효과 내비게이션(effect navigation)을 구하는 음성-전용 대화에 통상적인 사용자 발화로서, 예를 들어, 도움말(help), 취소(cancel), 반복(repeat), 기타 등등이 있다. Command 컨트롤(404)은 프롬프트 객체를 지정하는 Prompt 속성을 포함할 수 있다. 그에 부가하여, Command 컨트롤(404)은 인식에 관한 문법(Grammar 속성을 통함) 및 연관된 처리(오히려 결과를 SemanticItem에 바인딩하지 않는 Answer 객체와 같음) 뿐만 아니라 컨텍스트의 "유효범위(scope)" 및 유형을 지정하는 데 사용될 수 있다. 이것은 클라이언트측 마 크업에서 전역적이면서 문맥 의존적인(context-sensitive) 거동을 저작하는 것을 가능하게 해준다. Command 컨트롤(404)은 "help" 명령 또는 클라이언트 장치의 사용자가 웹 사이트의 다른 선택된 영역으로 내비게이션할 수 있게 해주는 명령 등의 부가적인 유형의 입력을 가능하게 해준다.

CompareValidator 컨트롤

CompareValidator 컨트롤은 연산자에 따라 2개의 값을 비교하고 적절한 조치를 취한다. 비교될 값은 정수, 텍스트 문자열, 기타 등등의 임의의 형태를 가질 수 있다. CompareValidator는 유효성 검사될 SemanticItem을 나타내는 SemanticItemtoValidate 속성을 포함한다. 유효성 검사될 SemanticItem은 상수 또는 다른 SemanticItem과 비교될 수 있으며, 여기서 이 상수 또는 다른 SemanticItem은 ValuetoCompare 및 SemanticItemtoCompare 속성에 의해 각각 제공된다. CompareValidator와 연관된 다른 파라미터 또는 속성은 행해질 비교를 정의하는 Operator 및 값의 유형, 예를 들어, 정수 또는 의미 항목의 텍스트를 정의하는 Type를 포함한다.

CompareValidator 컨트롤과 연관된 유효성 검사가 실패하는 경우, Prompt 속성은 획득된 결과가 올바른 것이 아니었음을 사용자에게 알려주는 실행될 수 있는 Prompt 객체를 지정할 수 있다. 비교 시에 유효성 검사가 실패하는 경우, 시스템이 올바른 값을 얻기 위해 사용자를 재프롬프트하기 위해, SemanticItemtoValidate에 의해 정의되는 연관된 SemanticItem은 비어 있는 것으로 표시된다. 그렇지만, 올바르지 않은 값이 올바르지 않은 값을 반복하는 사용자에 대한 프롬프트에서 사 용되어지는 경우, 의미 맵 내의 연관된 SemanticItem의 올바르지 않은 값을 클리어하지 않는 것이 도움이 될지도 모른다. 애플리케이션 저작자의 원하는 바에 따라, 연관된 SemanticItem의 값이 값을 변경하는 경우 또는 이 값이 확인된 경우, CompareValidator 컨트롤이 트리거될 수 있다.

CustomValidator 컨트롤

CustomValidator 컨트롤은 CompareValidator 컨트롤과 유사하다. SemanticItemtoValidate 속성은 유효성 검사될 SemanticItem을 나타내는 반면, ClientValidationFunction 속성은 연관된 함수 또는 스크립트를 통해 커스텀 유효성 검사 루틴을 지정한다. 이 함수는, 유효성 검사가 실패했는지 여부에 상관없이, 부울값 "예" 또는 "아니오" 또는 그의 등가물을 제공한다. Prompt 속성은 에러, 즉 유효성 검사의 실패 또는 에러의 표시를 제공하기 위해 Prompt 객체를 지정할 수 있다. 애플리케이션 저작자의 원하는 바에 따라, 연관된 SemanticItem의 값이 값을 변경하는 경우 또는 그 값이 확인된 경우, CustomValidator 컨트롤이 트리거될 수 있다.

컨트롤 실행 알고리즘

클라이언트측 스크립트 또는 모듈(본 명세서에서 "RunSpeech"라고 함)이 도 6의 컨트롤들을 위해 클라이언트 장치에 제공된다. 이 스크립트의 목적은, 클라이언트 장치(30) 상에서 실행될 때, 즉 컨트롤들에 관한 마크업이 그 안에 포함된 값들로 인해 클라이언트 상에서 실행하기 위해 활성화될 때, 스크립트에 지정되어 있는 논리를 통해 대화 흐름(dialog flow)을 실행하는 것이다. 이 스크립트는 페이 지 요청들 간의 다수의 대화 차례(dialog turn)를 가능하게 해주며, 따라서 전화 브라우저(216) 등을 통한 음성-전용 대화의 제어에 특히 도움이 된다. 클라이언트 스크립트 RunSpeech는, 완성된 형태가 제공될 때까지 또는 새로운 페이지가 클라이언트 장치(30)로부터 다른 방식으로 요청될 때까지, 클라이언트 장치(30) 상에서 루프 방식으로 실행된다.

일반적으로, 일 실시예에서, 이 알고리즘은 음성을 출력하고 사용자 입력을 인식함으로써 대화 차례를 발생한다. 이 알고리즘의 전체적인 논리는 음성-전용 시나리오의 경우 다음과 같다(이상에서 달리 언급하지 않은 속성 또는 파라미터에 대해서는 2004년 6월 17일자로 공개된 발명의 명칭이 "웹 지원 인식 및/또는 가청 프롬프트를 위한 웹 서버 컨트롤(Web Server Controls for Web Enabled Recognition and/or Audible Prompting)"인 미국 특허 출원 공개 제2004/1003908호를 참조한다).

1. 제1 활성(이하에서 정의됨) QA, CompareValidator 또는 CustomValidator 컨트롤을 음성 인덱스 순서로 찾아낸다.

2. 활성 컨트롤이 없는 경우, 페이지를 제공한다.

3. 그렇지 않은 경우, 컨트롤을 실행한다.

QA는 다음의 경우에 활성인 것으로 간주된다.

1. QA의 ClientActivationFunction이 존재하지 않거나 true를 반환하고, AND

2. Answers 속성 집합체가 비어있지 않은 경우, 일련의 Answers가 가리키고 있는 SemanticItem 전부의 상태가 비어있으며, OR

3. Answers 속성 집합체가 비어 있는 경우, Confirm 어레이 내의 적어도 하나의 SemanticItem이 NeedsConfirmation이다.

그렇지만, QA에서 PlayOnce가 true이고 그의 프롬프트가 성공적으로 실행된 경우(OnComplete에 도달한 경우), QA는 활성화의 후보가 되지 않는다.

QA는 다음과 같이 실행된다.

1. 이것이 이전의 활성 컨트롤과 다른 컨트롤인 경우, Prompt 카운트 값을 리셋한다.

2. Prompt 카운트 값을 증가시킨다.

3. PromptSelectFunction이 지정되어 있는 경우, 그 함수를 호출하고 Prompt의 inlinePrompt를 반환된 문자열로 설정한다.

4. Reco 객체가 존재하는 경우, 그를 시작한다. 이 Reco는 임의의 활성 명령 문법을 이미 포함하고 있어야만 한다.

Validator(CompareValidator 또는 CustomValidator)은 다음의 경우에 활성이다.

1. SemanticItemtoValidate가 이 유효성 검사자(validator)에 의해 유효성 검사되고 그의 값이 변경된 경우

CompareValidator는 다음과 같이 실행된다.

1. 유효성 검사자의 연산자에 따라 SemanticItemToCompare 또는 ValueToCompare 및 SemanticItemToValidate의 값들을 비교한다.

2. 테스트가 false를 반환하는 경우, SemanticItemToValidate의 텍스트 필드 를 비우고 프롬프트를 실행한다.

3. 테스트가 true를 반환하는 경우, SemanticItemToValidate를 이 유효성 검사자에 의해 유효성 검사된 것으로 표시를 한다.

CustomValidator는 다음과 같이 실행된다.

1. SemanticItemToValidate의 값으로 ClientValidationFunction이 호출된다.

2. 함수가 false를 반환하는 경우, semanticItem이 클리어되고, 프롬프트가 실행되며, 그렇지 않은 경우 이 유효성 검사자에 의해 다른 방식으로 유효성 검사된다.

Command는 이하의 경우에 활성인 것으로 간주된다.

1. 그것이 Scope(유효 범위)에 있고, AND

2. 유효 범위 트리에서 아래쪽에 있는 동일한 Type의 다른 Command가 없는 경우.

다중-모드 경우에, 이 논리는 이하의 알고리즘으로 간단화된다.

1. 트리거링 이벤트, 즉 사용자가 컨트롤을 두드리는(tap) 것을 기다린다.

2. 예상된 대답을 수집한다.

3. 입력이 있는지 잘 듣는다.

4. 결과를 SemanticItem에 바인딩하거나, 아무 것도 없는 경우, 이벤트를 버린다.

5. 다시 1로 간다.

다중-모드 환경에서, 유의할 점은, 사용자가 결과의 시각 표현과 연관된 텍 스트 박스 또는 다른 입력 필드를 정정하는 경우, 시스템이 그 값이 확인되었다는 것을 나타내기 위해 연관된 SemanticItem을 갱신할 수 있다는 것이다.

다른 실시예에서, 도 6에 나타낸 바와 같이, 애플리케이션 저작자가 전화 트랜잭션(telepholy transaction)을 처리하는 음성 애플리케이션을 생성할 수 있게 해주는 Call 컨트롤(407)은 물론 하나의 컨트롤에서 공통의 음성 시나리오를 래핑하는 수단을 제공하는 Application 컨트롤(430)이 제공된다. Call 컨트롤(407) 및 Application 컨트롤(430)은 본 발명을 실시하는 데는 필요하지 않지만, 완성도(completeness)를 위해 언급된 것에 불과하다. 각각에 대한 추가적인 설명은 2004년 6월 17일자로 공개된 발명의 명칭이 "웹 지원 인식 및/또는 가청 프롬프트를 위한 웹 서버 컨트롤(Web Server Controls for Web Enabled Recognition and/or Audible Prompting)"인 미국 특허 출원 공개 제2004/0113908호 및 2004년 11월 18일자로 공개된 발명의 명칭이 "음성 지원 인식을 위한 애플리케이션 컨트롤(Application Controls for Speech Enabled Recognition)"인 미국 특허 출원 공개 제2004/0230637A1호에 제공되어 있다.

사용자 상호작용 데이터의 기록

예로서 상기 구조를 사용하여, 애플리케이션 개발자는 음성 지원 애플리케이션을 개발할 수 있다. 그렇지만, 본 명세서에 기술된 측면들은 개발자가 사용자 상호작용 데이터를 기록 또는 로그할 수 있게 해준다.

그럼에도 불구하고, 본 명세서에 기술된 개념들이 대화 저작 구조(dialog authoring structure)에 한정되지 않고 오히려 미들웨어, API(application program interface), 기타 등등으로 구현되고 이하에 기술되는 정보의 일부 또는 그 전부를 기록하도록 구성되어 있는 것(이에 한정되지 않음) 등의 대화 모델(dialog model)을 발생하는 임의의 저작 도구에 적용될 수 있다는 것을 잘 알 것이다. 그에 부가하여, 전화 애플리케이션 등의 음성 지원 애플리케이션의 기능적 특성 및 그의 음성 사용자 인터페이스의 상세가 영역 및 애플리케이션 유형에 걸쳐 크게 다를 수 있으며, 따라서 임의의 자동화된 로깅 지원은 일반적으로 발견적 학습에 의할 뿐 결정론적이지 않다. 이 때문에, 이것의 구현은 자동화된 로그 이벤트 속성을, 변경가능하지 않은 속성보다는 오버라이드가능한 기본값(overridable default)으로 구현할 수 있다. 그럼에도 불구하고, 다양한 정보의 로깅을 간단화 및 용이하게 해주는 것은 여전히 수동 및 프로그램적 저작에 의존하는 시스템에 비해 큰 진보이다.

다시 도 4를 참조하면, 대화 컨트롤(dialog control)(211)에 따라 음성 지원 애플리케이션을 실행하는 웹 서버(202)는, 모바일 장치(30)을 통한 또는 전화(80)를 통한 액세스(이에 한정되지 않음) 등 임의의 유형의 사용자에 대해 애플리케이션이 실행될 때, 저장 장치(217)에 사용자 상호작용 로그 데이터를 기록한다.

애플리케이션은 통상적으로(전적으로 그러한 것은 아님) 일련의 계층적 컨트롤(본 명세서에서는 필요에 따라 Command 컨트롤(404), Application 컨트롤(430), Call 컨트롤(407) 및 Validator(406, 408)와 함께 QA 컨트롤(402)로 일반적으로 예시되어 있음)로서 정의 또는 작성된다. 이 계층구조는 완료될 전체적인 작업은 물론 전체적인 작업을 완료하기 위한 그의 서브작업을 정의한다. 계층구조에서의 레 벨의 수는 애플리케이션의 복잡도에 의존한다. 예를 들어, 애플리케이션은 전체적으로 항공편 예약(즉, 최상위의 대부분의 작업)을 하는 것에 관한 것일 수 있는 반면, 2가지 주요 서브작업은 출발 정보 및 도착 정보를 획득하는 것에 관한 것일 수 있다. 이와 마찬가지로, 출발 정보 및 도착 정보를 획득하는 주요 서브작업 각각에 대해 추가적인 서브작업, 구체적으로는 출발/도착 공항 정보, 출발/도착 시각, 기타 등등을 획득하는 것이 정의될 수 있다. 이들 서브작업은 이들의 내포하는 작업 내에 순서대로 나타날 수 있다.

일반적으로, 2가지 유형의 데이터, 즉 작업/대화(Task/Dialog) 데이터 및 차례(Turn) 데이터가 기록된다. 작업/대화 데이터로 시작하여, 이 데이터는, 로그에 나타내어져 있는 바와 같이, 작업 및 서브작업의 관점에서 애플리케이션의 계층적 또는 순서적 구조를 포착해야만 한다. 도 7은 애플리케이션을 생성하는 방법(500) 을 나타낸 것이다. 대화 저작 도구는, 단계(502)에서, 내포된(nested) 또는 순차적(sequential) 작업 단위로 대화의 저작 또는 정의를 가능하게 해주며, 따라서 개발자가 음성 지원 애플리케이션을 작성할 때, 저작자는 일반적으로 이를 모듈 방식으로 작성하게 된다. 즉, 저작자는 개별 차례들을 특정의 작업을 완수하는 세트로 그룹화하고 작업들을 상위 레벨 작업을 완수하는 세트로 그룹화하게 된다. 작업 구조 및 개개의 작업의 유입(flow in) 및 유출(flow out)이 디자인 시에 알려져 있기 때문에, 작업에의 진입(entry) 및 작업으로부터 이탈(exit)의 로깅이 (예를 들어, TaskStart 및 TaskComplete 이벤트를 통해) 가능하게 되는 것은 물론 작업 구조의 시퀀스 및/또는 계층구조의 자동화된 로깅을 제공하기 위해 단계(504)에서 애 플리케이션에 의해 사용되는 입력 필드에 대해 사용자로부터 차례 데이터 및 값이 획득된다. 이것은 대화 흐름, 획득된 값 및 작업 구조가 이벤트 로그로부터 명시적으로 복구 및 작성될 수 있다는 것을 의미한다. 유의할 점은 단계(502, 504)의 특징들 중 일부 또는 그 전부가 다른 순서로 또는 동시에 수행될 수 있다는 점에서 이들 단계가 단지 설명을 위해 따로 도시되어 있다는 것이다.

이 데이터는 또한 임의의 주어진 작업 또는 서브작업의 완료의 성공, 실패 또는 다른(예를 들어, 알려지지 않은) 상태를 정량화한다. 그에 부가하여, 작업/대화 데이터는 작업이 성공하지 못하는 경우, 즉 실패하는 경우의 이유, 또는 그의 완료 상태를 알지 못하는 이유, 또는, 적용가능하다면, 성공에 대한 다수의 이유가 가능한 경우, 성공한 이유를 포함한다. 부가의 데이터는 사용자가 응답을 제공하지 않았는지 또는 음성 인식기가 발화를 인식할 수 없었는지를 나타내는 진행 데이터를 포함할 수 있다. 프롬프트 또는 사용자 응답, 또는 변경된 이들의 상태에 기초한 또는 그와 연관된 값들을 얻기 위해 애플리케이션에 의해 사용되는 입력 필드값 또는 저장 위치의 리스트도 기록될 수 있다.

도 8은 음성 지원 애플리케이션의 실행 방법(520)을 나타낸 것이다. 방법(520)은 하나 이상의 차례를 갖는 작업(들)로 정의되는 음성 지원 애플리케이션을 실행하는 단계(단계 522)를 포함한다. 단계(524)는 작업, 차례 및 의미 항목에 관련된 정보를 기록하는 단계를 포함한다. 유의할 점은 단계(522, 524)의 특징들 중 일부 또는 그 전부가 다른 순서로 또는 동시에 수행될 수 있다는 점에서 이들 단계가 단지 설명을 위해 따로 도시되어 있다는 것이다.

일 실시예에서, 작업/대화 데이터는 이하의 정보 중 일부 또는 그 전부를 포함하고 있다.

작업/대화 데이터

name: 작업/대화에 대한 저작자-정의 문자열 식별자, 예를 들어, "getCredit CardInfo", "ConfirmTravel", 기타 등등. 저작자가 디자인 시에 이름을 제공하지 않는 경우, 기본값 이름, 예를 들어, Dialog1, Dialog2, DialogN,...이 주어진다.

parent: 내포하는 대화의 이름(로그로부터 대화 계층구조를 재구성하기 위한 것임)

TaskStart: 작업/대화에 처음으로 들어갈 때의 시간스탬프

TaskComplete: 작업/대화에서 빠져나올 때의 시간스탬프. 이 이벤트는, 아래에서 위쪽으로, 모든 열려 있는 대화에 대해 애플리케이션의 끝에서 기본값으로 항상 실행되어야만 한다(즉, 로그에 '열려 있는(open-ended)' 대화가 없게 된다).

status: 작업/대화의 완료 상태가 저작자에 의해 설정가능하며, 대화의 수행에 기초하여 자동적으로 추론되거나 저작자 정의 조건에 기초하여 반자동적으로 설정된다. 일 실시예에서, 기본값 상태는 "UNSET"이며, 여기서 후속값들은 이하의 것들 중 하나일 수 있다.

SUCCESS

FAILURE

UNKNOWN

자동적 작업 완료 상태

어떤 경우에, 상기한 바와 같이, 이 상태는 작업 종료의 상태가 성공, 실패, 또는 알 수 없음 중 하나이었는지에 상관없이 그 작업 종료의 특성으로부터 타당한 확신으로 추론될 수 있다. 예를 들어, 에러 또는 예외의 결과로 끝나는 작업은 실패(Failure)의 완료 상태로 자동적으로 로깅될 수 있다. 이와 마찬가지로, 취소된 작업(예를 들어, 작업 객체에 대해 Cancel() 메서드가 호출된 경우)은 실패(Failure)의 완료 상태로 자동적으로 로깅될 수 있다. 이와 유사하게, 어떤 '삼진(strikeout)'(예를 들어, 이하에 기술되는 MaxSilences 또는 MaxNoReco) 카운트에 도달되는 결과로 끝나는 작업은 실패(Failure)의 완료 상태로 자동적으로 로깅된다.

이와 반대로, 그 작업에서 부딪힌 또는 디자인 시에 그 작업에 속하는 것으로 지정된 차례의 모든 의미 항목(즉, 애플리케이션에 대한 입력 필드)이 근거있는(사용자 입력 또는 그로부터 도출된) 값을 갖는, 자연스럽게 끝나는 작업(즉, 취소되지 않은 작업)은 성공(Success)의 완료 상태로 자동적으로 로깅된다.

반자동화된 작업 완료

작업 상태 로깅의 부분 자동화(partial automation)도 유용하다. 임의의 주어진 작업에 대해, 저작자는 작업 성공 또는 실패에 대해 단계(502)에서 일련의 조건을 지정 또는 정의할 수 있으며, 이들 조건은, 만족되는 경우, 임의의 종료점에서의 작업의 상태를 결정한다. 이들 조건은 프로그램적(예를 들어, foo=='bar')일 수 있거나, 저작자가 작업당 하나 이상의 의미 항목(예를 들어, departureCity 및 arrivalCity에 대해 제공되는 값)을 지정하기만 하면 되도록 조건들이 간단화될 수 있으면 더 도움이 되며, 시스템은 그 의미 항목들이 확인된 값을 가질 때 성공(Success)을 자동적으로 로깅하게 되고, 선택에 따라서는, 그 의미 항목들이 확인된 값을 갖지 않을 때 실패(Failure)를 자동적으로 로깅하게 된다.

이 측면은 유용한 시간-절감 메카니즘인데, 그 이유는 이 측면이 작업의 모든 종료 지점에서 작업 상태 로깅이 프로그램적으로 코딩될 필요가 없음을 의미하기 때문이다. 그 대신에, 최종 사용자가 작업을 종료할 때마다 조건들이 자동적으로 평가되고, 추가적인 개발자 코드 없이 상태가 판정되고 로깅된다.

reason: 대화의 종료 이유가 저작자에 의해 설정될 수 있다. 예를 들어,

Command - 대화의 다른 부분으로 변경하기 위해 사용자가 말한 명령 및 명령의 성질(예를 들어, "Cancel", "Operator", "Main Menu", 기타)

userHangup - 사용자가 전화를 끊거나 다른 방식으로 중단 또는 포기함

applicationError - 애플리케이션 에러가 발생함

maxNoRecos - 인식 없이 최대 수의 발화에 도달됨

maxSilences - 최대 수의 침묵하는 사용자 응답에 도달됨

SemanticUpdate:

items: 새로운 값 및 대응하는 상태를 포함하는 값/상태가 변경된 임의의 의미 항목의 리스트. 일반적으로, 이 데이터는, 이하에 기술되는 바와 같이, 각각의 대화 차례(애플리케이션/응답에 의한 프롬프트 또는 사용자에 의한 프롬프트 없음)에서 의미 항목 값 및/또는 상태 중 하나 이상이 변하게 된다는 점에서, 차례 데이 터와 상관되어 있다. 그렇지만, 몇몇 경우에, 애플리케이션은 단독으로 의미 항목을 변경할 수 있다. 예를 들어, 애플리케이션이 신용 카드 번호 등의 값을 유효성 검사할 수 없는 경우, 애플리케이션은 단독으로 그 값을 클리어할 수 있으며, 대화 차례에 반드시 기초해야 하는 것은 아니다. 그럼에도 불구하고, 이러한 변경이 기록된다.

차례 데이터는 애플리케이션과의 직접 상호작용을 포함하며, (응답이 예상되지 않을 때) 애플리케이션에 의해 제공되는 프롬프트 또는 사용자 응답이나 응답의 없음에 상관되어 있는 애플리케이션 프롬프트, 환언하면 프롬프트/응답 교환, 또는 반드시 프롬프트에 응답한 것일 필요는 없는 사용자에 의해 제공되는 명령 또는 적어도 프롬프트에 대한 응답일 것으로 기대되지 않는 응답에 기초하여 구성된다. 그에 따라, 기록될 수 있는 3가지 영역의 데이터는 애플리케이션에 의해 제공되는 프롬프트에 관련된 정보, 사용자에 의해 제공되는 응답(예상된 응답이든 예상되지 않은 응답이든 상관없음) 및 시스템에 의해 판정되는 인식 결과를 포함한다. 일 실시예에서, 차례 데이터는 이하의 정보의 일부 또는 그 전부를 포함한다.

차례 데이터

config

name: 저작자-정의 문자열 식별자. 저작자가 디자인 시에 이름을 제공하지 않은 경우, 기본 이름이 주어질 수 있지만, 동일한 대화/작업 내에의 서로 다른 차례를 명백하고 일관성있게 구분할 필요가 있다. 가능한 기술은 프롬프트의 이름 및 유형의 기반을 갖추는 것이다.

type: 특정의 차례의 목적의 세부 사항은 그와 연관된 의미 항목의 성질로부터 추론될 수 있다. 이상에서의 상기 설명의 경우에, 의미 항목은 Answers, ExtraAnswers 및 Confirms의 개념을 통해 차례와 연관되어 있다.

차례 목적의 예로는 다음과 같은 것이 있다.

새로운 정보를 요청함(차례는 Answers를 인에이블시킴)

Confirms 관련 정보(수락/거부, 차례는 Confirms를 인에이블시킴)

정보 문장(informational statement)을 제공함(차례는 Answers 또는 Confirms를 보유하지 않음)

parent: 내포하는 대화/작업의 이름(로그로부터 대화 계층구조를 재구성하기 위한 것임).

language: 사용되는 언어.

speech grammars: 어느 음성 인식 문법이 사용되고 있는지에 관련된 정보.

DMTF grammars: 어느 DMTF 인식 문법이 사용되고 있는지에 관련된 정보.

thresholds: 값을 거부하고 및/또는 값을 확인하는 신뢰도 임계값(confidence threshold).

timeouts: 프롬프트 다음에 오는 초기 침묵에 허용되는 기간, 응답의 끝을 판정하는 종료 침묵(end silence) 및 쓸데없는 말(babble)인 것으로 간주되는 기간.

prompt

name: 차례 데이터 이름이 사용될 수 있다는 점에서 선택적이며 필요하지 않을 수 있다.

type: 대화 모델이 다수의 미리 정의된 프롬프트 유형을 포함할 수 있으며, 이들 중 임의의 것이 애플리케이션에 의해 선택될 수 있고, 그의 사용으로 인해 시스템이 무엇을 달성하기 위해 하려고 하는 것, 즉 차례의 목적을 기록할 수 있다.

프롬프트 유형의 예는 다음과 같다.

MainPrompt - 질문을 함(또는 문장을 제공함)

HelpPrompt - 도움을 제공함

RepeatPrompt - 정보 내용을 반복함

NoRecognitionPrompt - '인식 없음'에 응답함

SilencePrompt - 침묵에 응답함

EscalatedNoRecognitionPrompt - 다수의 시도 이후에 '인식 없음'에 응답함

EscalatedSilencePrompt - 다수의 시도 이후에 침묵에 응답함

이들 유형이 미리 정의되고 언제라도 선택할 수 있기 때문에, 이들은 유형별로 자동적으로 로깅될 수 있으며, 이는 주어진 프롬프트의 목적이 차례의 목적을 달성하기 위한 것이라는 개념에서 로그 데이터를 자동적으로 풍성하게 해준다.

따라서, 차례 유형과 결합된 프롬프트 유형 - 이들 모두는 대화 저작 모델에서 프리미티브(primitive)를 프로그래밍하며 따라서 애플리케이션과 만나게 될 때 자동적으로 로깅됨 - 은 로그의 임의의 지점에서 시스템의 목적의 풍성한 뷰를 가능하게 해준다.

semantic items: 프롬프트되는 의미 항목(들)(질문/확인 사이클(ask/confirm cycle), 기타 등등을 링크하는 데 사용됨)

대화 모델은 대화 흐름 저작을 간단화하기 위해 의미 항목(각각이 값 및 상태를 가짐)의 개념을 사용한다. 모든 의미 항목의 변하는 값 및 상태를 자동적으로 로깅하고 그것을 작업 및 사용자/시스템 이동 정보와 결합함으로써, 로그가 더욱 풍부해진다.

Answers/ExtraAnswers/Confirms 모델은 의미 항목을 차례, 따라서 작업에 링크시킨다. 따라서, 어느 의미 항목이 어느 시스템 이동(system move) 및 어느 사용자 이동(user move)과 관련되어 있는지 및 어느 것이 어느 작업에 기여하는지를 알게 된다.

textual content of the prompt: 예를 들어, "welcome"

bargein: 온/오프/프롬프트-중간 시간

User Perceived Latency: 사용자의 응답과 그 다음 프롬프트의 실행 사이의 기간. 시스템이 과부하에 있을 때, 이 기간은 더 길어질 수 있으며, 이는 사용자가 애플리케이션이 응답하지 않는 것으로 생각할 수 있다는 점에서 사용자를 혼란케할 수 있다.

TTS: True/False - 프롬프트를 발생하는 데 사용되는 텍스트-음성 변환(text-to-speech).

prompt completion time: 프롬프트가 완료/차단된 시간.

prompt wave file: 제공된 실제 프롬프트.

user iniput:

mode: 사용자가 DTMF/음성을 제공하는지

type: 사용자가 명령(Command)을 제공하는지, 그리고 제공하는 경우 어느 유형(예를 들어, Help/Repeat/기타), 또는 사용자가 응답(Response)을 제공하는지, 그리고 제공하는 경우 어느 유형 (Answer/Confirm/Deny)

대화 모델은 애플리케이션의 문법의 기능들을, 응답을 제공함에 있어서의 사용자의 목적(들), 즉 대답(Answer), 수락(Accept), 거부(Deny), 기타 등등을 나타내는 서로 다른 유형의 사용자 응답으로 분류한다. 이들 유형은 시스템이 생각하기로 사용자가 무엇을 달성하려고 노력하고 있는지의 표시자로서 직접 로깅될 수 있다. 다른 응답 유형의 예는 다음과 같다.

Answer - 사용자가 값을 요청하는 질문에 대한 대답을 제공하였다.

ExtraAnswer - 사용자가 질문의 초점을 벗어난 대답을 제공하였다.

Accept - 사용자가 정보를 확인하였다.

Deny - 사용자가 정보를 반박하였다.

Help Command - 사용자가 도움을 요청하였다.

Repeat Command - 사용자가 정보의 반복을 요청하였다.

Other Command - 사용자가 어떤 다른 형태의 명령을 발행하였다(명확하게 타이핑되지 않았지만, 우리는 그것이 상기 유형들 중 임의의 것이 아니었음을 알고 있다).

Silence - 사용자가 아무것도 말하지 않았다(이것은 때때로 일종의 "암묵적인 수락"으로 사용된다).

이들 유형이 특정의 문법과 연관되어 있기 때문에, 이들은 사용자가 대응하는 문법과 일치하는 무언가를 말할 때마다 자동적으로 로깅될 수 있다. 많은 시스템은 단일의 대화 차례가 다수의 유형 - 예를 들어, 2개 이상의 항목의 수락, 또는 단일의 차례로 하나의 항목을 대답하고 다른 항목을 수락하는 것 - 을 포함할 수 있게 해준다.

Silence: 침묵이 검출되는 경우, 그것이 MaxSilences에 대해 어느 수 또는 카운트인가.

NoReco: 발화에 대해 인식이 검출되지 않은 경우, 그것이 MaxNorecos에 대해 어느 수 또는 카운트인가.

Error: 에러가 발생한 경우, 그것이 애플리케이션 또는 플랫폼에 의해 버려졌는가

result:

Recognition result: 시스템에 의해 반환된 인식 결과. 통상적으로, 인식 결과는 해석된 발화에 대한 SML(semantic markup language) 태그를 포함한다. 그에 부가하여, N개의 최상의 대안적인 해석이 제공될 수 있으며, 적절한 경우 오디오 녹음이 얻어진다.

그에 부가하여, 각각의 해석에 대해,

SML 태그가 없는 발화 텍스트(음성이 제공되는 경우) 또는 키누름(keypress)(DTMF가 제공되는 경우)

confidence: 해석의 신뢰도 수준

semantic mappings: SML 결과의 부분과 의미 항목 사이의 링크. 환언하면, SML 결과로부터의 어떤 값이 어느 의미 항목에 배치되는가.

grammar rule matched: 문법에서의 어느 규칙이 사용자 입력과 일치했는가.

confidence: 전체로서 발화의 신뢰도

bargein: 사용자에 의한 바지-인(barge in)의 타이밍 또는 NULL(바지-인이 존재하지 않는 경우)

recognition wave file: 실제의 기록된 사용자 입력 또는 그에 대한 포인터.

요약하면, 로깅된 사용자 상호작용 데이터는 대화가 관심의 어떤 필드(예를 들어, 폼 필드 또는 슬롯값)에 동작하는 작업의 계층적 또는 순차적 구조로 보일 수 있게 해주고, 작업 내의 각각의 대화 차례는 폼 필드(예를 들어, 값을 요구하는 것, 그것을 확인하는 것, 그것을 반복하는 것, 기타)에 대한 시스템 목적(대화 이동) 및 음성 인식기가 무엇을 사용자 목적인 것으로 생각하는지(예를 들어, 값을 제공하는 것, 그것을 거부하는 것, 도움을 요청하는 것, 기타) 둘다를 로깅한다.

실제적인 이익이 이 구조로 실현된다. 상세하게는, 성공 또는 실패의 작업 완료가 일반적으로 명확하다는 점에서 시스템 성능의 분석이 향상되며, 따라서 트 랜잭션 성공율 보고가 크게 단순화되고, 작업을 완료하기 위해 취해지는 대화 단계들의 성질이 더 잘 이해된다(왜냐하면 각각의 단계 배후의 목적이 저작 시에 알려져 있기 때문이다).

이러한 형태의 데이터 로깅의 구현은 그것이 대화 저작 도구에 포함되는 방식으로 인해 쉽다. 이 수단의 상위 레벨 성질은 광범위한 애플리케이션 유형에 일반적인 것이며, 로깅의 실제 상세가 이 로깅을 개념적으로 또한 로깅 프리미티브에 대해 저작 도구에 통합함으로써 저작 시에 용이하게 된다. 따라서, 애플리케이션 저작자는 작업/서브작업 모델을 사용하여 애플리케이션을 구조화하고 작업으로부터의 어느 전환이 성공적인 완료를 나타내는지를 나타내려고 하며, 저작자가 시스템/사용자 목적 로깅(system/user purpose logging)을 명시적으로 설치할 필요가 없는데, 그 이유는 그것이 대화 차례 저작 모델에 내장되어 있기 때문이다.

대화 분석

하기의 설명은 일반적으로 작업 수준에서 분석을 참조하지만, 모든 원칙이 작업 및 세션 수준(즉, 단일의 작업으로서 세션의 분석 - 하위 수준 작업 구조화는 알 수 없거나, 또는 무시됨)에서 적용된다.

도 9를 참조해 보면, 대화 분석 모듈(600)은 전술된 것과 같은 입력 로깅된 애플리케이션 데이터를 수신하고, 그 분석을 수행한다. 일반적으로, 설명을 위해, 대화 분석 모듈(600)은 열악한 작업 성능 진단 모듈(602), 혼란스럽게 하는 프롬프트 분석 모듈(604), 및 대화 문제의 소스를 식별하기 위한 모듈(606)을 포함한다. 그것들이 조합되어 유용하게 이용될 수 있지만, 각각의 프로세스 또는 모듈이 서로 에 대해 독립적으로 이용될 수 있다. 보고서 또는 기타 적합한 출력이 하기의 척도에 대한 값을 지시하도록 제공될 수 있다. 적용가능하다면, 척도들은 작업 기반으로 제공될 수 있다.

1. 열악한 작업 성능 진단

도 10의 열악한 작업 성능 진단 모듈(602) 및 그 대응하는 프로세스(603)는 분석 및 조정되어야 하는 애플리케이션 중 일부 열악하게 수행되는 것을 식별 또는 노출시키고, 및/또는 열악한 성능의 이유를 제시한다. 이는 단계(605)에서 로깅된 데이터로부터 각각의 세션 또는 작업을 분석하고(하나의 작업은 대화 차례, 서브작업, 또는 이들 양쪽 모두를 포함하는 대화의 구조화된 컴포넌트임), 단계(607)에서 "작업 유용성(usability)"의 척도를 추론한다. 이런 척도, 및 특히 후술된 척도들은 작업을 달성하는 데 이용되는 대화 이동 시퀀스의 패턴(예를 들어, 차례 유형 또는 응답 유형에 의해 지시됨)에 기초하여 사용자 경험의 성공의 표시자이다.

프로세스(603)는 로깅된 데이터에 존재하는 작업 성공/실패, 및 기타 메트릭(metrics)의 표시자들과 함께 또는 이들과 독립적으로 이용될 수 있다. 이들 지시자는 작업의 상태가 그 완료 시에 - 통상적으로, 성공/실패/알 수 없음 값들을 갖고 - 어떻게 로깅되어야 하는지를 판정하는 명시적인 애플리케이션 계측의 결과이고, 전체 작업 완료율에 관한 보고서를 생성하는 데 이용된다. 기타 명시적인 지시자들은 미가공 차례 카운트와 존속 기간을 포함한다. 단독으로 사용된, 명시적인 지시자들은 작업의 사용자 경험에 관한 식견(insight)을 거의 갖고 있지 않지만, 본 명세서에 기술된 분석은 깊은 식견을 제공한다. (저 완료율을 갖는 작업들 에서 고 완료율을 갖는 작업들에 이르기까지) 모든 작업에 걸쳐 작업 성능을 산정하는 것은 가치있는 일인데, 왜냐하면 이것이 작업의 효율성 및 유용성의 척도를 제공하기 때문이다. 이들은 성능을 강화하고, 사용자 경험을 최적화하는 것에 대한 메트릭으로서, 및/또는 전체 작업 성능에 대한 가능성 있는 이유들을 예측하는 데 이용될 수 있다.

다음의 메트릭들 중 일부 또는 전부가 분석에 이용되는 데이터 세트에 걸쳐 주어진 작업의 모든 인스턴스로부터 계산될 수 있다.

확인 평가

모듈(610)은 단계(611)에서 수신된 응답을 요청하는 것에 관한 차례들에 대하여 수신된 응답의 확인에 관한 차례들에 관련된 표시를 획득한다. 예시적 실시예에서, 모듈(610)은 "Asks" 차례들에 대하여 "Confirms" 차례들의 수를 나타내는 값인 확인 평가를 계산한다. 예를 들어, 비율은 "Confirms" 차례들의 수를 합산하고, 이를 "Asks" 차례들의 수로 나눔으로써 계산될 수 있다. 이런 방식으로, 확인 비율 "1"은 작업 내의 Asks 와 Confirms 수가 동일하다는 것을 나타낸다. 일반적으로, (이런 예를 이용하여) 저 비율은 보다 효율적인 대화 상호작용을 나타낼 것이다. (하지만 일부 애플리케이션은 사업상의 이유로 모든 Ask에 대해 명시적인 유효성 검증을 요구할 수 있다). 고 확인 수준(즉, 원하는 것보다 많은 "Confirms"이 생성됨)에 대한 이유는 열악하게 설계된 대화 플로우, 서브-최적화(sub-optimal) 신뢰 임계값 및/또는 문법 문제를 나타낼 수 있다. 당업자에 의해 인식된 바와 같이, "Confirms"과 "Asks"를 비교하기 위한 서로 다른 척도가 사용될 수 있다. 하지만, 일반적으로 정규화(예컨대, 평가를 판정하기 위한 비율의 사용)는 이로울 수 있는데, 왜냐하면 이는 프롬프트 및 대답의 수가 작업 각각마다 상이할 수 있다는 사실에 관계없이 하나의 작업을 다른 한 작업에 대하여 비교할 수 있게 해주기 때문이다.

의미 항목 차례 평가

모듈(612)은 단계(613)에서 데이터에 걸쳐 응답을 요청하는 것이 나타나는 작업 인스턴스에 대하여 수신된 응답을 요청하는 것에 관한 차례들에 관련되는 표시를 획득한다. 도시된 실시예에서, 모듈(612)은 의미 항목 또는 응답 차례 평가를 계산하며, 이는 의미 항목 SI에 대한 Ask 차례들의 수를 합산하고, 이를 데이터에 걸쳐 의미 항목의 요청이 나타나는 작업 인스턴스의 수로 나눔으로써 각각의 의미 항목 SI에 기반하여 계산된다. (본 명세서에 사용된, 의미 항목은 사용자에 의해 제공되는 응답을 기록한다.) 이런 평가를 의미 항목에 기반하여 계산함으로써, 특정 의미 항목에 대한 값을 획득하는 어려움에 관한 식견을 제공한다 - 고 비율은 다수의 시도가 항목을 요청하기 위해 행해졌다는 것을 나타내고; 저 비율 값은 거의 시도가 없음을 나타낸다.

예로서, 이런 프로세스는 사용자가 한 번에 다수의 숫자를 모두 제공해야 하기 때문에 실패 없이 신용 카드 번호를 획득하는 것이 어렵다는 것을 식별할 수 있다. 예를 들어, 애플리케이션에 따라서 이런 프롬프트는 대화 내의 여러 위치들에서 발생할 수 있지만, 동일한 의미 항목이 이용된다. 이것이 그 경우라면, 해법은 사용자에게 신용 카드 번호 중 일부를 요청하는 것일 수 있다.

원한다면, 다수의 SI를 갖는 작업을 위해, 단일의 대표적인 평가는 모든 개개의 SI 차례 평가의 평균으로서 계산될 수 있다.

의미 항목 유효성 평가

모듈(614)은 단계(615)에서 수신된 응답에 기초하여 지정되는 값에 대하여 수신된 응답을 확인하는 것에 관한 차례들에 관련된 표시를 획득한다. 도시된 실시예에서, 모듈(614)은 의미 항목 또는 응답 유효성 평가를 계산하고, 이는 응답별로, 또는 의미 항목 SI에 기초하여 SI에 대한 값이 확인되었던 횟수를 합산하고, 이를 SI에 값이 지정되었던 총 횟수로 나눔으로써, 계산될 수 있다. 이런 평가는 의미 항목을 획득하는 데 이용되는 작업(들)의 효율성에 관한 식견 - 즉, 다른 경우 큰 차례 카운트 또는 확인 평가들에 의해 불분명하게 될 수 있음 -을 제시한다. 의미 항목 유효성 평가에 대한 큰 값은 높은 수락률을 나타내고, 반면 작은 값은 높은 거절률을 나타낸다. 원한다면, (사용자로부터의 응답들) 다수의 SI를 갖는 작업을 위해, 단일의 대표적인 평가가 모든 개개의 SI 유효성 평가의 평균으로서 계산될 수 있다.

사용자-반복 비율

모듈(616)은 단계(617)에서 사용자 요청에 기반하여 차례를 반복하는 사용자에 관련된 표시를 획득한다. 도시된 실시예에서, 모듈(616)은 사용자 반복 평가를 계산하고, 이는 차례에 대해 반복된 입력들의 수를 합산하고(여기서 재입력이 침묵 및 인식 없음과는 대조적으로 사용자 요청으로 인한 것이었던 경우), 이를 차례의 총 발생 수로 나눔으로써 차례별 기반으로 계산된다. 반복하는 사용자 요청은 통 상적으로 모든 명령 도움말(Help), 반복(Repeat), 및 되돌아가기(Go Back)를 포함하지만, 현재 또는 이전 상태에 대한 재입력을 직접적으로 초래하는 모든 명령을 포함할 수 있다. 큰 값은 높은 수준의 재입력을 나타내고, 이는 사용자 혼란이 그 상태에서 시작하는 것을 의미하고, 작은 값은 낮은 수준의 재입력을 나타낸다.

2. 프롬프트를 혼란스럽게 하기

모듈(604) 및 대응하는 프로세스(619)(도 11)는 애플리케이션 내의 어떤 프롬프트가 혼란을 야기하는지의 표시를 획득하는 데 이용된다. 단계(621)에서, 주어진 차례의 프롬프트에 대한 로깅된 데이터가 수신되고, 동시에 프롬프트 표현(wording)이 분명함 또는 간결함을 위해 조정되어야 하는지의 여부를 판정하기 위해 '혼란 등급(confusion rating)'이 단계(623)에서 계산된다. 이런 예에서, 등급이 높을수록, 프롬프트가 조정될 필요가 더 있을 수 있다.

예시적 혼란 등급은 다음의 경우들로부터 계산될 수 있다:

(a) 침묵 카운트: 프롬프트에 뒤따르는, 사용자가 침묵(응답 없음)하는 횟수;

(b) 도움말 카운트: 프롬프트에 뒤따르는, 사용자가 도움을 요청하는 횟수;

(c) 반복 카운트: 사용자가 시스템에게 프롬프트를 반복할 것을 요청하는 횟수;

(d) 거부율: (Type Ask의 차례): 의미 항목 값(Semantic Item value)(즉, 프롬프트에 대한 인식된 응답)이 거부되었거나, 또는 다른 경우 취소되었던 횟수;

이들 개개의 총수는 데이터 내의 프롬프트의 여러 인스턴스들에 걸쳐 합산된 다. 유의할 점은 서로 다른 가중화 계수가 컴포넌트 (a) - (d)에 적용될 수 있다는 것이다. 결과적인 등급은 단독으로 이용될 수 있거나, 또는 응답을 이해하기 위해 사용자의 시간을 반영하는 보다 저 수준의 인식기로부터 계산된 계수와 결합될 수 있다:

(a)응답 대기시간: 예를 들어, 프롬프트의 끝과 사용자 응답의 시작 사이의 평균(또는 기타 척도) 대기시간. (이는 사람이 혼란스럽게 하지 않는 프롬프트 보다 천천히 혼란스럽게 하는 프롬프트에 응답하는 것을 가정한다). 이런 평가는 그것만으로 프롬프트의 혼란 등급의 표시를 제공할 수 있다는 것에 유의해야 한다.

3. 대화 문제의 소스를 식별하기

모듈(606) 및 대응하는 프로세스(631)(도 12)는 사용자가 작업을 포기하도록 야기하는 문제의 가능성 있는 소스인 상태를 찾는 데 이용된다. 작업 포기는 인식의 유형과 관련하여 판정된다. 음성 및 DTMF의 경우, 다음의 조치 중 임의의 하나는 포기로 간주될 수 있다:

- 사용자 중단

- 현재 작업을 취소하는 사용자 명령 (예컨대, "Cancel")

- 에이전트로의 전달을 요청하는 사용자 명령 (예컨대, "Operator")

- 에이전트로의 전달을 요청하는 DTMF 키-누름(key-press) (예컨대, 0)

프로세스, 즉 방법(631)은 사용자가 자동화 시스템과 적어도 한번 상호작용하려고 시도했음(즉, 호출의 시작 시에 포기 조치를 취하지 않았음)으로 알려지는 세션에 적용된다. 프로세스는 마지막으로 알려진 올바른 상태를 찾으려고 시도하 며, 그 올바른 상태로부터 문제 상태가 발견될 수 있다. 프로세스는 다음과 같다:

각각의 사용자 세션 동안, 단계(629)에서 로깅된 데이터를 수신하고, 작업 구조를 평평하게 하며(flatten), 즉(this is): 대화 차례들 및/또는 작업 입력 및/또는 완료 상태들을 상태들의 단차원적 리스트로서, 단계(633)에 지시된 시간 순으로, 취급한다; 그런다음(then):

단계(635)에서 포기의 지점을 찾아내고;

하기의 상태들 중 한 상태를 만날 때까지, 단계(637)에서 대화 차례의 시퀀스를 통해 포기 조치로부터 백-트랙킹함(back-track)(하기의 순서는 변경될 수 있음):

(a) 상태 "성공(Success)"를 갖는 작업 완료를 만날 경우(단계(639)에 의해 지시됨), 즉시 후속 차례 상태가 문제 소스로서 고려되며;

(b) 사용자가 값을 수락하는 경우, 또는 의미 항목이 "확인됨(Confirmed)"의 상태를 달성했던 임의의 차례를 만날 경우(단계(641)에 의해 지시됨), 즉시 후속 차례 상태가 문제 소스로서 고려되며;

(c) 사용자가 값을 거부/정정하는 경우, 또는 의미 항목이 "비어있음(Empty)"의 상태를 초래하거나 그 값을 변경했던 임의의 차례를 만날 경우(단계(643)에 의해 지시됨), 질문 시에 의미 항목이 "Ask" 유형의 차례의 토픽이었던 가장 가까운 이전의 차례 상태가 문제 소스로서 고려되며;

(d) 사용자가 "Go Back" 하는 경우, 또는 세션 내의 사용자의 단계들의 역추적(retracing)을 구현하는 기타 명령을 만날 경우(단계(645)에 의해 지시됨), Go Back 명령(또는 시퀀스에 있다면 다수의 Go Back 명령들) 다음의 차례의 이름을 취하고, 초기의 Go Back 명령 이전의 그 차례의 가장 가까운 인스턴스를 문제 소스로서 고려하며;

(e) 세션의 시작에 도달하면(단계(647)에 의해 지시됨), 세션 내의 최초의 정보-요청 차례 상태(즉, 처음 Ask 또는 Command 인에이블링)가 문제 소스인 것으로 가정하며;

(f) 그렇지 않다면(else), 모든 다른 차례 유형의 경우, 백-트래킹을 유지한다(즉, 단계(637)로 되돌아감)

결과는 세션들에 걸쳐 대조될 수 있고, 작업 포기에 기여할 가능성에 의해서 순서화된 상태들의 리스트로서 제시될 수 있다. 예를 들어, 76개 포기가 발생하는 사용자의 데이터에 걸쳐, 45개는 "TurnA" 상태에, 15개는 "TurnB" 상태에, 14개는 "TurnC" 상태에, 2개는 "TurnD" 상태에 있다.

본 발명이 특정의 실시예를 참조하여 기술되어 있지만, 당업자라면 본 발명의 정신 및 범위를 벗어나지 않고서 형태 및 상세에 여러 변경이 행해질 수 있다는 것을 잘 알 것이다.

Claims (20)

1. 사용자와, 대화 차례(dialog turns)를 갖는 대화형 애플리케이션 간의 대화를 분석하는 컴퓨터 구현 방법(603) -차례는 시스템으로부터의 프롬프트 및 상기 사용자로부터 수신된 응답을 포함함- 으로서,

   상기 시스템과 적어도 하나의 사용자 간의 대화 차례들을 나타내는 정보를 애플리케이션에 수신하는 단계(605) - 상기 차례들은 상기 애플리케이션의 하나 이상의 작업에 관련됨 - ; 및

   상기 하나 이상의 작업에 대하여 상기 애플리케이션의 성능의 표시를 획득하는 단계(607)

   를 포함하는 컴퓨터 구현 방법(603).
2. 제1항에 있어서, 상기 하나 이상의 작업에 대하여 상기 애플리케이션의 성능의 표시를 획득하는 단계(607)는 응답을 요청하는 것에 관한 차례들에 대하여 수신된 응답의 확인(confirmation)에 관한 차례들에 관련된 표시를 획득하는 단계(611)를 포함하는 컴퓨터 구현 방법(603).
3. 제1항에 있어서, 상기 하나 이상의 작업에 대하여 상기 애플리케이션의 성능의 표시를 획득하는 단계(607)는 응답에 대한 요청이 상기 정보에 걸쳐 나타나는 작업 인스턴스와 관련하여 수신된 응답을 요청하는 것에 관한 차례들과 관련된 표 시를 획득하는 단계(613)를 포함하는 컴퓨터 구현 방법(603).
4. 제1항에 있어서, 상기 하나 이상의 작업에 대하여 상기 애플리케이션의 성능의 표시를 획득하는 단계(607)는 상기 수신된 응답에 기초하여 지정되는 값에 대하여 수신된 응답을 확인하는 것에 관한 차례들에 관련된 표시를 획득하는 단계(615)를 포함하는 컴퓨터 구현 방법(603).
5. 제1항에 있어서, 상기 하나 이상의 작업에 대하여 상기 애플리케이션의 성능의 표시를 획득하는 단계(607)는 사용자 요청에 기초하여 차례를 반복하는 사용자에 관련된 표시를 획득하는 단계(617)를 포함하는 컴퓨터 구현 방법(603).
6. 제1항에 있어서, 상기 하나 이상의 작업에 대하여 상기 애플리케이션의 성능의 표시를 획득하는 단계(607)는,

   응답을 요청하는 것에 관한 차례들에 대하여 수신된 응답의 확인에 관한 차례들에 관련된 표시를 획득하는 단계(611);

   작업 인스턴스에 대하여 수신된 응답을 요청하는 것에 관한 차례들에 관련된 표시를 획득하는 단계(613) - 상기 응답의 요청은 상기 정보에 걸쳐 나타남 -;

   상기 수신된 응답에 기초하여 지정되는 값에 대하여 수신된 응답을 확인하는 것에 관한 차례들에 관련된 표시(615)를 획득하는 단계(615); 및

   사용자 요청에 기초하여 차례들을 반복하는 사용자에 관련된 표시를 획득하 는 단계(617)

   중 적어도 둘 이상을 포함하는 컴퓨터 구현 방법(603).
7. 사용자와, 대화 차례를 갖는 대화형 애플리케이션 간의 대화를 분석하는 컴퓨터 구현 방법(619) - 차례는 시스템으로부터의 프롬프트 및 상기 사용자로부터 수신된 응답을 포함함 - 으로서,

   상기 시스템과 적어도 하나의 사용자 간의 대화 차례를 나타내는 정보를 음성 지원 애플리케이션에 수신하는 단계(621) - 상기 차례는 상기 애플리케이션의 하나 이상의 작업에 관련됨 - ; 및

   혼란을 야기하는 상기 애플리케이션 내의 프롬프트들의 표시를 획득하는 단계(623)를 포함하는 컴퓨터 구현 방법(619).
8. 제7항에 있어서, 혼란을 야기하는 상기 애플리케이션 내의 프롬프트들의 표시를 획득하는 단계(623)는 상기 프롬프트에 뒤따르는, 사용자가 침묵하는 횟수의 표시를 획득하는 단계를 포함하는 컴퓨터 구현 방법(619).
9. 제7항에 있어서, 혼란을 야기하는 상기 애플리케이션 내의 프롬프트들의 표시를 획득하는 단계(623)는 상기 프롬프트에 뒤따르는 사용자가 도움을 요청하는 횟수의 표시를 획득하는 단계를 포함하는 컴퓨터 구현 방법(619).
10. 제7항에 있어서, 혼란을 야기하는 상기 애플리케이션 내의 프롬프트들의 표시를 획득하는 단계(623)는 사용자가 상기 시스템에게 상기 프롬프트를 반복할 것을 요청하는 횟수의 표시를 획득하는 단계를 포함하는 컴퓨터 구현 방법(619).
11. 제7항에 있어서, 혼란을 야기하는 상기 애플리케이션 내의 프롬프트들의 표시를 획득하는 단계(623)는 상기 프롬프트에 대한 인식된 응답이 취소되었던 횟수의 표시를 획득하는 단계를 포함하는 컴퓨터 구현 방법(619).
12. 제7항에 있어서, 혼란을 야기하는 상기 애플리케이션 내의 프롬프트들의 표시를 획득하는 단계(623)는 응답 대기시간의 표시를 획득하는 단계를 포함하는 컴퓨터 구현 방법(619).
13. 제7항에 있어서, 혼란을 야기하는 상기 애플리케이션 내의 프롬프트들의 표시를 획득하는 단계(623)는,

    상기 프롬프트에 뒤따르는, 사용자가 침묵하는 횟수의 표시를 획득하는 단계;

    상기 프롬프트에 뒤따르는, 사용자가 도움을 요청하는 횟수의 표시를 획득하는 단계;

    사용자가 상기 시스템에게 상기 프롬프트를 반복할 것을 요청하는 횟수의 표시를 획득하는 단계;

    상기 프롬프트에 대한 인식된 응답이 취소되었던 횟수의 표시를 획득하는 단계; 및

    응답 대기시간의 표시를 획득하는 단계

    중 둘 이상을 포함하는, 컴퓨터 구현 방법(619).
14. 사용자와, 대화 차례를 갖는 대화형 애플리케이션 간의 대화를 분석하는 컴퓨터 구현 방법(631) - 차례는 시스템으로부터의 프롬프트 및 상기 사용자로부터 수신된 응답을 포함함 - 으로서,

    상기 시스템과 적어도 하나의 사용자 간의 대화 차례를 나타내는 정보를 음성 지원 애플리케이션에 수신하는 단계(629) - 상기 차례는 상기 애플리케이션의 하나 이상의 작업에 관련됨 -; 및

    상기 사용자가 작업을 포기하도록 야기하는, 상기 대화 내의 문제의 소스의 표시를 획득하는 단계(635-649)

    를 포함하는 컴퓨터 구현 방법(631).
15. 제14항에 있어서, 상기 사용자가 작업을 포기하도록 야기하는, 상기 대화 내의 문제의 소스의 표시를 획득하는 단계는, 대화 차례 및/또는 작업 입력 및/또는 작업 완료를 나타내는 상태들의 순차적인 리스트에서 포기의 지점을 찾아내는 단계(635)를 포함하는 컴퓨터 구현 방법(631).
16. 제15항에 있어서, 작업 완료는 성공에 대응하는 표시이고, 상기 사용자가 작업을 포기하도록 야기하는, 상기 대화 내의 문제의 소스의 표시를 획득하는 단계는, 성공의 표시를 갖는 작업 완료를 만날 때까지(639) 상기 순차적인 리스트를 통해서 포기의 지점으로부터 백-트래킹(back-tracking)하는 단계(637)를 포함하며, 상기 문제의 소스의 표시는 바로 다음 차례를 포함하는 컴퓨터 구현 방법(631).
17. 제15항에 있어서, 인식된 응답들은 상태들의 순차적인 리스트와 상관되고, 상기 사용자가 작업을 포기하도록 야기하는, 상기 대화 내의 문제의 소스의 표시를 획득하는 단계는 상기 사용자가 인식된 응답을 수락할 때까지, 또는 인식된 응답이 확인됨(641)의 상태를 획득하는 임의의 차례일 때까지, 상기 순차적인 리스트를 통해서 포기의 지점으로부터 백-트래킹하는 단계(637)를 포함하며, 상기 문제의 소스의 표시는 바로 다음 차례를 포함하는 컴퓨터 구현 방법(631).
18. 제15항에 있어서, 인식된 응답들이 상태들의 순차적인 리스트에 기록 및 상관되고, 상기 사용자가 작업을 포기하도록 야기하는, 상기 대화 내의 문제의 소스의 표시를 획득하는 단계는, 기록된 인식 응답을 차례가 거부 또는 정정할 때까지, 또는 인식 응답의 위치가 "비어있음(Empty)"의 상태를 초래하는 차례 또는 기록된 인식 응답이 그 값을 변경하는 차례일 때까지(643), 상기 순차적인 리스트를 통해서 포기의 지점으로부터 백-트래킹하는 단계(637)를 포함하고, 상기 문제의 소스의 표시는, 상기 대응하는 기록된 인식 응답이 차례를 묻는 것(Asking)에 응답하여 수 신되었던 가장 가까운 이전의 차례를 포함하는 컴퓨터 구현 방법(631).
19. 제15항에 있어서, 인식된 응답들은 상태들의 순차적인 리스트에 기록 및 상관되고, 상기 사용자가 작업을 포기하도록 야기하는, 상기 대화 내의 문제의 소스의 표시를 획득하는 단계는, 상기 사용자가 사용자의 단계들을 역추적하는 명령을 제공하여 상기 명령에 이어지는 차례의 표시를 확인할 때까지(645), 상기 순차적인 리스트를 통해서 포기의 지점으로부터 백-트래킹하는 단계(637)를 포함하고, 상기 문제의 소스의 표시는 상기 문제의 소스로서 상기 사용자의 단계들을 역추적하는 명령 이전에, 상기 차례의 표시에 대응하여, 차례의 가장 가까운 인스턴스를 포함하는 컴퓨터 구현 방법(631).
20. 제15항에 있어서, 상기 사용자가 작업을 포기하도록 야기하는, 상기 대화 내의 문제의 소스의 표시를 획득하는 단계는 상기 세션의 시작에 도달할 때까지(647), 상기 순차적인 리스트를 통해서 포기의 지점으로부터 백-트래킹하는 단계(637)를 포함하고, 제1 정보 요청 차례는 상기 문제의 소스로서 여겨지는, 컴퓨터 구현 방법(631).

Images