KR20060099391A - 개발자가 어플리케이션 내에 상이한 유형의 다이얼로그들을혼합할 수 있게 해 주는 컴퓨터 구현 방법 및 시스템 - Google Patents

Abstract

하나 이상의 컴퓨터 판독가능 매체 상에 구현된 어플리케이션 프로그램 인터페이스가 개시된다. 인터페이스는 어플리케이션 내에서 제1 유형의 다이얼로그의 개발을 용이하게 하도록 구성된 제1 다이얼로그 컨테이너를 포함한다. 또한, 어플리케이션 내에서 제2 유형의 다이얼로그의 개발을 용이하게 하도록 구성된 제2 다이얼로그 컨테이너도 포함된다.

어플리케이션 프로그램 인터페이스, 상태-주도적 다이얼로그, 시멘틱-주도적 다이얼로그

Description

개발자가 어플리케이션 내에 상이한 유형의 다이얼로그들을 혼합할 수 있게 해 주는 컴퓨터 구현 방법 및 시스템{DEVELOPMENT FRAMEWORK FOR MIXING SEMANTICS-DRIVEN AND STATE-DRIVEN DIALOG}

도 1은 본 발명이 실현될 수 있는 하나의 예시적인 환경의 블럭도.

도 2는 시스템 아키텍쳐의 높은 레벨의 특징을 나타낸 개략적인 블럭도.

도 3은 API 프레임워크의 일부분의 개략적인 블럭도.

<도면의 주요 부분에 대한 부호의 설명>

306 : 시멘틱-주도형 다이얼로그 컨테이너

308 : 상태-주도형 다이얼로그 컨테이너

310 : 다이얼로그 요소

본 발명은 일반적으로 개발자가 주어진 어플리케이션 내에서 상이한 다이얼로그 유형들을 능률적으로 혼합할 수 있게 해 주는 개발 프레임워크에 관한 것이다. 더 상세하게는, 본 발명은 시멘틱-주도형 다이얼로그(semantics-driven dialog)와 상태-주도형 다이얼로그(state-driven dialog) 둘다를 통합하는 어플리 케이션의 개발에 관한 것이다.

음성 사용자 인터페이스(VUI)를 통한 사용자 인터랙션을 지원하는 어플리케이션들이 본 기술 분야에 공지되어 있다. 개발 프로세스 동안, 이러한 유형의 어플리케이션들은 기초 자원들로의 액세스를 제공하는 낮은 레벨의 어플리케이션 프로그램 인터페이스(API)의 최상위에서 작성될 수 있다. 예를 들어, 전화 어플리케이션은 (반드시 이들로만 한정되는 것은 아니지만) 전화 기반구조, 음성 인식 자원 및 음성 합성 자원과 같은 자원들에 대한 지원을 포함하는 낮은 레벨의 API 프레임워크의 최상위에서 작성되는 것으로 알려져 있다.

어플리케이션 개발자의 관점에서 볼 때, 상기에 설명된 낮은 레벨의 API 자원들을 직접적으로 목표로 하는 코드를 작성하는 프로세스는 비교적 장황하고 노동 집약적이다. 보다 더 높은 레벨의 구성은 낮은 레벨의 자원들에 대하여 보다 더 직관적인 인터페이스를 제공하는 것으로 알려져 있다. 일부 경우에서, 높은 레벨의 구성은 낮은 레벨의 API 자원들에 대한 인터페이스로서 기능하는 API 프레임워크의 형태로 된 다이얼로그 작성 모델을 생성하기 위한 기초로서 이용됨으로써, 어플리케이션 코드의 생성을 단순하게 해 왔다. 보다 더 높은 레벨의 API 프레임워크에 포함된 객체들은 여러가지 상이한 개발 경험들을 지원하도록 구성되어 왔다.

개발 프로세스의 결과로서, 가능성있는 여러가지 상이한 포맷들 중 하나로 된 사용자-시스템 다이얼로그를 용이하게 하는 어플리케이션이 생성된다. 일부 다이얼로그는 시스템-주도형(시스템-선도형) 다이얼로그일 것이다. 이러한 유형의 다이얼로그의 일례에서, 전화 어플리케이션에 인터페이싱하고 있는 사용자는 "나의 지원 어플리케이션에 오신 것을 환영합니다. 귀하의 제품 식별 번호를 입력해 주세요"라는 음성 문장을 제공받는다. 이 경우, 요청된 태스크가 완료될 때까지는 (즉, 유효한 제품 식별 번호가 입력될 때까지는), 일반적으로 어떠한 동작도 취해지지 않는다. 시스템은 때로는 특정 포맷으로 된 특정 정보를 요구한다. 따라서, 시스템-주도형 다이얼로그는 일반적으로 매우 제한적이다.

일부 다이얼로그는 사용자-주도형(또는 사용자-선도형) 다이얼로그일 것이다. 이러한 유형의 다이얼로그의 일례에서, 전화 어플리케이션을 통해 인터페이싱하고 있는 사용자는 "나의 지원 어플리케이션에 오신 것을 환영합니다. 어떻게 도와드릴까요?"라는 음성 문장을 제공받는다. 이러한 유형의 문장에 응답하여, 사용자는 일반적으로 "내 기계에 문제가 있어요"라던가, "제품을 환불받고 싶어요"와 같이 무엇이든 얘기할 수 있다. 그러면, 시스템은 사용자의 질문의 성질을 식별하여, 그에 따라 "영수증을 갖고 계십니까?"와 같이 응답하도록 구성된다. 시스템은 사용자의 질문 내에서 정보의 핵심 부분이 무엇인지를 판정한 후, 그에 따라 응답한다.

시멘틱-주도형 다이얼로그를 지원하는 개발 프레임워크는 일반적으로 시스템-주도적이기보다 사용자-주도적인 것에 가깝다. 시멘틱-주도형 다이얼로그의 한 섹션을 작성할 때, 개발자는 일반적으로 복수의 필드 중 어느 것이 시스템 사용자로부터 적절한 정보를 획득하여 채워져야 할지를 지정할 수 있다. 일부 방식에서, 시멘틱-주도형 포맷은 사용자에 의해 채워져야 할 소정의 필드들을 갖는 그래픽 사용자 인터페이스(GUI) 내의 한 양식과 유사하다. 필드들을 통한 미리 정해진 경로 (A→B→C 등)를 지정하는 대신에, 소정의 다이얼로그 노드 또는 요소는 다른 필드들의 특정 상태에 의존하여 반응하도록 지정될 수 있다. 예를 들어, 주어진 다이얼로그 노드 A는 필드 C가 빈 경우에 활성으로 되도록 지정된다. 예를 들어, 필드 A, B, C는 비어있지만 필드 E는 채워지고 확인된 경우에 주어진 다이얼로그 노드가 활성으로 지정되는 것과 같이, 여러가지 종속관계가 가능하다. 일부 필드들은 그 내용이 정확한지에 대하여 시스템 사용자의 확인을 요구하도록 설정될 수 있다. 모든 사용자-기계 인터랙션 다음에는, 시멘틱-주도형 다이얼로그 프레임워크 내에서 어느 다이얼로그 노드(들)가 다음에 활성으로 되어야 하는지에 관한 결정이 내려진다.

상태-주도형 다이얼로그를 지원하는 개발 프레임워크는 일반적으로 사용자-주도적이기보다는 시스템-주도적인 것에 가깝다. 상태-주도형 다이얼로그 프로세스 내에서의 인터랙션 흐름은 시멘틱-주도형 다이얼로그 인터랙션에서보다 더 많이 미리 정해진다. 일반적으로, 결정은 한 요소로부터 다음 요소로의 미리 정해진 경로를 따른다. 예를 들어, 제1 특정 정보 항목에 대해 요청이 이루어진다. 이에 응답하여, 사용자로부터 정보가 수신된다. 수신된 정보가 신뢰할 가치가 있는 것인지에 대한 평가가 이루어진다. 신뢰할 가치가 없는 경우, 확인 프로세스가 수행된다. 신뢰할 가치가 있는 경우, 시스템은 미리 정해진 제2 정보 항목을 요청한다.

상태-주도형 다이얼로그에서, 일반적으로 사용자는 시스템이 현재 질문하고 있는 것보다 많은 정보를 제출할 수가 없다. 시스템은 일반적으로 매 단계마다 다 음에 무엇이 행해져야할지를 정한다. 개발자들이 상태-주도형 다이얼로그를 흐름도의 형태로 그래픽 표현하는 것은 흔한 일이다. 시멘틱-주도형 다이얼로그와 달리, 이러한 상태-주도형 다이얼로그는 사용자가 입력으로서 무엇을 제공하였는지에 의존하여 점핑하지 않는다.

상기에서 낮은 레벨의 API 자원들에 대한 인터페이스를 제공하는 것으로 설명된 높은 레벨의 API 프레임워크는 주로 시멘틱-주도형 다이얼로그를 지원하도록 구성될 수 있다. 이에 의해, 개발자는 매우 유연하고 자연스러운 다이얼로그를 작성할 수 있다. 그러한 구성의 단점은 단순한 시스템-주도형 다이얼로그 작성이 상대적으로 어려운 작업으로 된다는 것이다.

대안적으로, 높은 레벨의 API는 상태-주도형 다이얼로그를 주로 지원하도록 구성될 수 있다. 그러면, 다이얼로그 상태들을 조건에 연결시키기가 쉬워진다 (예를 들어, 상태 A를 완료하면, 어느 조건이 참인지를 평가하고, 그 경로를 따라 다음 상태로 간다). 이러한 유형의 다이얼로그 개발은 시각화하고 작성하기가 쉽다. 그러나, 어플리케이션의 사용자에게 있어서, 결과적인 다이얼로그가 자연스럽지고 않고 유연하지도 않다는 단점이 있다.

본 발명의 실시예들은 하나 이상의 컴퓨터 판독가능 매체 상에 구현된 어플리케이션 프로그램 인터페이스에 관한 것이다. 인터페이스는 어플리케이션 내에서 제1 유형의 다이얼로그의 개발을 용이하게 하도록 구성된 제1 다이얼로그 컨테이너를 포함한다. 또한, 어플리케이션 내에서 제2 유형의 다이얼로그의 개발을 용이하 게 하도록 구성된 제2 다이얼로그 컨테이너도 포함된다.

Ⅰ. 예시적인 환경

본 발명의 실시예들을 논의하기 전에, 그 실시예들 및 관련 시스템이 구현될 수 있는 예시적인 컴퓨팅 환경이 설명될 것이다.

도 1은 본 발명의 실시예들 및 그 관련 시스템들이 구현될 수 있는 적합한 컴퓨팅 환경(100)의 일례를 도시한 것이다. 컴퓨팅 시스템 환경(100)은 적합한 컴퓨팅 환경의 일례일 뿐이며, 본 발명의 사용 또는 기능의 범위에 관한 어떠한 한정을 제안하려고 하는 것이 아니다. 또한, 컴퓨팅 환경(100)이 예시된 컴포넌트들 중 어느 하나 또는 조합에 관련된 종속성 또는 요건을 갖는 것으로 해석되어서도 안된다.

본 발명은 다양한 다른 일반목적 또는 특수목적의 컴퓨팅 시스템 환경 또는 구성에서 동작할 수 있다. 본 발명에서 사용되기에 적합한 공지된 컴퓨팅 시스템, 환경 및/또는 구성의 예로는, 퍼스널 컴퓨터, 서버 컴퓨터, 핸드핼드 또는 랩탑 장치, 멀티프로세서 시스템, 마이크로프로세서 기반 시스템, 셋톱 박스, 프로그래밍가능한 소비자 가전장치, 네트워크 PC, 미니컴퓨터, 메인프레임 컴퓨터, 전화 시스템, 상기의 시스템 또는 장치들 중 임의의 것을 포함하는 분산 컴퓨팅 환경 등이 포함되지만, 이에 한정되는 것은 아니다.

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

도 1을 참조하면, 본 발명을 구현하기 위한 예시적인 시스템은 컴퓨터(100)의 형태로 된 범용 컴퓨팅 장치를 포함한다. 컴퓨터(110)의 컴포넌트들은 프로세싱 유닛(120), 시스템 메모리(130), 및 시스템 메모리를 비롯한 다양한 시스템 컴포넌트들을 프로세싱 유닛(120)에 연결하는 시스템 버스(121)를 포함할 수 있지만, 이에 한정되는 것은 아니다. 시스템 버스(121)는 메모리 버스 또는 메모리 컨트롤러, 주변 버스, 및 다양한 버스 아키텍쳐 중 임의의 것을 사용하는 로컬 버스를 포함하는 몇가지 유형의 버스 구조 중 임의의 것일 수 있다. 한정적이지 않은 예를 들면, 그러한 아키텍쳐는 ISA(Industry Standard Architecture) 버스, MCA(Micro Channel Architecture) 버스, EISA(Enhanced ISA) 버스, VESA(Video Electronics Standards Association) 로컬 버스, 및 메자닌 버스(Mezzanine bus)로도 알려져 있는 PCI(Peripheral Component Interconnect) 버스를 포함한다.

일반적으로, 컴퓨터(110)는 다양한 컴퓨터 판독가능 매체를 포함한다. 컴퓨 터 판독가능 매체는 컴퓨터(110)에 의해 액세스될 수 있는 어떠한 이용가능한 매체라도 될 수 있으며, 휘발성 및 비휘발성 매체와 분리가능형 및 분리불가능형 매체 둘다를 포함한다. 한정적이지 않은 예를 들면, 컴퓨터 판독가능 매체는 컴퓨터 저장 매체 및 통신 매체를 포함할 수 있다. 컴퓨터 저장 매체는 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 또는 기타 데이터와 같은 정보의 저장을 위한 임의의 방법 또는 기술로 구현된 휘발성 및 비휘발성의 분리가능형 및 분리불가능형 매체 둘다를 포함한다. 컴퓨터 저장 매체는 RAM, ROM, EEPROM, 플래시 메모리 또는 기타 메모리 기술, CD-ROM, DVD 또는 기타 광 디스크 저장장치, 자기 카세트, 자기 테입, 자기 디스크 저장장치 또는 기타 자기 저장장치, 또는 원하는 정보를 저장하는 데에 사용될 수 있고 컴퓨터(110)에 의해 액세스될 수 있는 임의의 기타 매체를 포함하지만, 그에 한정되지는 않는다.

일반적으로, 통신 매체는 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 또는 기타 데이터를, 반송파 또는 기타 전송 메커니즘과 같은 변조된 데이터 신호로 구현하며, 임의의 정보 전달 매체를 포함한다. "변조된 데이터 신호"라는 용어는 그 특성 중 하나 이상이 신호 내에 정보를 엔코딩하는 방식으로 설정 또는 변경된 신호를 의미한다. 한정적이지 않은 예를 들면, 통신 매체는 유선 네트워크 또는 직접 배선 접속과 같은 유선 매체, 및 음향, RF, 적외선 및 기타 무선 매체와 같은 무선 매체를 포함한다. 상기에 언급한 것들의 임의의 조합도 컴퓨터 판독가능 매체의 범위 내에 포함되어야 한다.

시스템 메모리(130)는 판독 전용 메모리(ROM)(131) 및 랜덤 액세스 메모리 (RAM)(132)와 같은 휘발성 및/또는 비휘발성 메모리 형태로 컴퓨터 저장 매체를 포함한다. 기동시 등에 컴퓨터(110) 내의 구성요소들 간의 정보 전달을 돕는 기본 루틴을 포함하는 기본 입출력 시스템(133)(BIOS)은 일반적으로 ROM(131) 내에 저장된다. RAM(132)은 일반적으로, 프로세싱 유닛(120)이 즉각적으로 액세스할 수 있고/거나 프로세싱 유닛(120)이 현재 실행하고 있는 데이터 및/또는 프로그램 모듈을 포함한다. 한정적이지 않은 예로서, 도 1은 오퍼레이팅 시스템(134), 어플리케이션 프로그램(135), 기타 프로그램 모듈(136) 및 프로그램 데이터(137)를 도시하고 있다.

컴퓨터(110)는 다른 분리가능형/분리불가능형의 휘발성/비휘발성 컴퓨터 저장 매체도 포함할 수 있다. 단지 예로서, 도 1은 분리불가능형 비휘발성 자기 매체에 대한 판독 또는 기입을 행하는 하드 디스크 드라이브(141), 분리가능형 비휘발성 자기 디스크(152)에 대한 판독 또는 기입을 행하는 자기 디스크 드라이브(151), 및 CD-ROM 또는 기타 광 매체와 같은 분리가능형 비휘발성 광 디스크(156)에 대한 판독 또는 기입을 행하는 광 디스크 드라이브(155)를 도시하고 있다. 예시적인 오퍼레이팅 환경에서 이용될 수 있는 다른 분리가능형/분리불가능형의 휘발성/비휘발성 컴퓨터 저장 매체는 자기 테입 카세트, 플래시 메모리 카드, DVD, 디지탈 비디오 테입, 고체 상태 RAM, 고체 상태 ROM 등을 포함하지만, 이에 한정되는 것은 아니다. 하드 디스크 드라이브(141)는 일반적으로 인터페이스(140)와 같은 분리불가능형 메모리 인터페이스를 통해 시스템 버스(121)에 연결되고, 자기 디스크 드라이브(151) 및 광 디스크 드라이브(155)는 일반적으로 인터페이스(150)와 같 은 분리가능형 메모리 인터페이스에 의해 시스템 버스(121)에 연결된다.

상기에 논의되고 도 1에 도시되어 있는 드라이브들 및 관련 컴퓨터 저장 매체는 컴퓨터(110)에 대하여, 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 및 기타 데이터의 저장을 제공한다. 예를 들어, 도 1에서, 하드 디스크 드라이브(141)는 오퍼레이팅 시스템(144), 어플리케이션 프로그램(145), 기타 프로그램 모듈(146) 및 프로그램 데이터(147)를 저장하는 것으로서 도시되어 있다. 이러한 컴포넌트들은 오퍼레이팅 시스템(134), 어플리케이션 프로그램(135), 기타 프로그램 모듈(136) 및 프로그램 데이터(137)와 동일할 수도 있고 다를 수도 있다는 점에 유의해야 한다. 오퍼레이팅 시스템(144), 어플리케이션 프로그램(145), 기타 프로그램 모듈(146) 및 프로그램 데이터(147)에는, 그들이 적어도 상이한 사본들이라는 점을 나타내게 위하여 상이한 번호들이 부여되었다.

사용자는 키보드(162), 마이크로폰(163), 및 마우스, 트랙볼 또는 터치패드 등의 포인팅 장치(161)와 같은 입력 장치를 통하여 컴퓨터(110)에 명령 및 정보를 입력할 수 있다. (도시되지 않은) 다른 입력 장치들로는, 조이스틱, 게임패드, 위성 접시, 스캐너 등이 포함될 수 있다. 여기에 개시된 것과 그 이외의 입력 장치들은 주로 시스템 버스에 연결된 사용자 입력 인터페이스(160)를 통해 프로세싱 유닛(120)에 접속되지만, 병렬 포트, 게임 포트 또는 USB와 같은 기타 인터페이스 및 버스 구조에 의해서도 접속될 수 있다. 모니터(191) 또는 다른 유형의 디스플레이 장치도 비디오 인터페이스(190)와 같은 인터페이스를 통하여 시스템 버스(121)에 접속될 수 있다. 컴퓨터는 모니터 이외에, 출력 주변기기 인터페이스(195)를 통해 접속될 수 있는 스피커(197) 및 프린터(196)와 같은 기타 주변 출력 장치도 포함할 수 있다.

컴퓨터(110)는 원격 컴퓨터(180)와 같은 하나 이상의 원격 컴퓨터로의 논리적 접속을 이용하여 네트워크 환경에서 동작할 수 있다. 원격 컴퓨터(180)는 퍼스널 컴퓨터, 핸드핼드 장치, 서버, 라우터, 네트워크 PC, 피어 장치 또는 기타 공통 네트워크 노드일 수 있으며, 일반적으로 컴퓨터(110)에 관련하여 상기에서 설명한 구성요소들 중 다수 또는 전부를 포함한다. 도 1에 도시된 논리적 접속은 근거리 네트워크(LAN) 및 광역 네트워크(WAN)(173)를 포함하지만, 다른 네트워크들도 포함할 수 있다. 그러한 네트워크 환경은 사무실, 기업규모 컴퓨터 네트워크, 인트라넷 및 인터넷에서 흔한 것이다.

LAN 네트워크 환경에서 사용될 때, 컴퓨터(110)는 네트워크 인터페이스 또는 어댑터(170)를 통해 LAN(171)에 접속된다. WAN 네트워크 환경에서 사용될 때, 컴퓨터(110)는 일반적으로 인터넷과 같은 WAN(173)을 통해 통신을 설정하기 위한 모뎀(172) 또는 기타 수단을 포함한다. 내장형일 수도 있고 외장형일 수도 있는 모뎀(172)은 사용자 입력 인터페이스(160) 또는 기타 적절한 메커니즘을 통해 시스템 버스(121)에 접속될 수 있다. 네트워크 환경에서, 컴퓨터(110)에 관련하여 도시된 프로그램 모듈들 또는 그 일부는 원격 메모리 저장 장치 내에 저장될 수 있다. 한정적이지 않은 예로서, 도 1은 원격 어플리케이션 프로그램(185)이 원격 컴퓨터(180)에 상주하는 것으로 도시하고 있다. 도시된 네트워크 접속은 예시적인 것이며, 컴퓨터들 간의 통신 링크를 설정하기 위한 다른 수단도 이용될 수 있음을 알 것이다.

본 발명은 도 1과 관련하여 설명된 것과 같은 컴퓨터 시스템 상에서 실현될 수 있음에 유의해야 한다. 그러나, 본 발명은 서버, 메시지 핸들링 전용 컴퓨터 또는 분산 시스템에서 실현될 수 있으며, 분산 시스템에서는 본 발명의 상이한 부분들이 분산 컴퓨팅 시스템의 여러 부분들에서 실현될 수 있음에 유의해야 한다.

Ⅱ. 예시적인 시스템 환경

설명을 위하여, 본 발명의 실시예들은 전화 어플리케이션과 관련하여 설명될 것이다. 그러나, 본 발명의 범위는 그렇게 한정적이지 않으며, 실시예들은 어떠한 음성 지향 어플리케이션과 관련하여서도 적용될 수 있다.

전화 어플리케이션은 프리젠테이션 계층 및 논리+데이터 계층을 포함하는 다계층 시스템(multi-tier system)으로 볼 수 있다. 전형적으로, 프리젠테이션 계층은 음성 출력과 음성 입력을 사용하여 최종 사용자와 인터랙션하는 것을 담당한다. 일부 시스템들은 GUI와 같은 추가의 출력 수단, 또는 DTMF(Dual Multi-Frequency) 입력 메커니즘과 같은 추가의 입력 수단을 포함할 것이다. 일반적으로, 프리젠테이션 계층은 음성 사용자 인터페이스(VUI, Voice User Interface)를 제공한다. 전형적으로, 논리+데이터 계층은 기초가 되는 비지니스 규칙 및 데이터의 액세스 및 저장을 담당한다. 논리+데이터 계층에의 인터페이스로서 API들의 세트를 제공하는 것이 알려져 있지만, VUI를 작성하기 위한 유연한 API 프레임워크가 여전히 필요하다.

도 2는 시스템 아키텍쳐(200)의 높은 레벨의 특성을 나타낸 개략적인 블럭도 이다. 아키텍쳐(200)의 가장 높은 레벨은 어플리케이션 또는 사용자 코드(202)를 포함한다. 이것은 실례적으로는 다이얼로그를 실행하기 위해 개발자에 의해 생성된 코드이다. 아키텍쳐(200)의 가장 낮은 레벨은 코어 API 프레임워크(206)이다. 코어 프레임워크(206)는 실례적으로 시스템 자원으로의 액세스를 제공한다. 예를 들어, 코어 프레임워크는 실례적으로 전화 API, 시그널링 API, DTMF API, 음성 인식 API, 음성 합성 API 및/또는 다른 시스템 자원 인터페이스를 포함한다.

화살표(208)로 나타난 바와 같이, 코드(202)는 코어 프레임워크(206)의 컴포넌트들을 직접 호출하도록 구성될 수 있다. 이러한 개발 방법은 개발자의 입장에서 볼 때, 비교적 성가시고 노동 집약적인 것일 수 있다. 개발 부담을 완화하기 위하여, 어플리케이션(202)과 코어 프레임워크(206) 사이에 다이얼로그 API 프레임워크(204)가 배치된다. 프레임워크(204)는 프레임워크(206)보다 높은 레벨의 API 접근 방식을 제공한다. 따라서, 화살표(210, 212)에 따라, 사용자 코드(202)는 호출들을 프레임워크(204)로 지향시키도록 작성될 수 있고, 그러면 프레임워크(204)가 프레임워크(206)의 컴포넌트들에 대한 대응 호출을 행할 수 있다. 이러한 방식에서, 개발자는 보다 생산적인 방식으로 다이얼로그를 작성할 수 있다. 일 실시예에 따르면, (도시되지 않은) 도구가 다이얼로그 API 프레임워크(204)의 최상위에 구축되어, 개발자의 생산성을 더 향상시킬 수 있다. 그 도구는 보다 더 높은 레벨의 API 프레임워크에 비하여 작성하는 사용자의 능력을 촉진하고 향상시킨다.

이와 같이, 아키텍쳐(200)는 2개의 계층 ―다양한 전화 시나리오를 작성하기에 충분한 낮은 레벨의 음성 계층, 및 보다 더 높은 레벨의 추상화를 생성함으로써 개발자의 생산성을 향상시키도록 구성된 높은 레벨의 다이얼로그 계층― 을 갖는 VUI 개발 환경을 제공한다.

Ⅲ. 다이얼로그 API 프레임워크

도 2를 더 참조하면, 다이얼로그 API 프레임워크(204)는 다양한 유형의 다이얼로그 중 임의의 것을 지원하도록 구성될 수 있다. 예를 들어, 프레임워크(204)는 시멘틱-주도형 다이얼로그를 주로 포함하는 어플리케이션(202)의 생성을 용이하게 하도록 구성될 수 있다. 대안적으로, 프레임워크(204)는 주로 상태-주도형 다이얼로그를 포함하는 어플리케이션(202)의 생성을 용이하게 하도록 구성될 수 있다. 그러나, 보다 더 높은 레벨의 개발 인터페이스를 제공하려는 알려진 시도들은, 일반적으로 시멘틱-주도형 다이얼로그와 상태-주도형 다이얼로그 둘다를 포함하는 어플리케이션의 효율적인 생성을 지원하는 데에는 일반적으로 실패해왔다. 본 발명의 한 양태에 따르면, 다이얼로그 API 프레임워크(204)(및 선택적으로는 하나 이상의 관련 개발 도구)는 시멘틱-주도형 다이얼로그와 상태-주도형 다이얼로그를 혼합한 어플리케이션(202)의 효율적인 개발을 용이하게 하도록 구성된다. 시멘틱-주도형 다이얼로그와 상태-주도형 다이얼로그의 개발을 혼합하기 위한 동일한 스킴은, 본 발명의 범위를 벗어나지 않고서, 다이얼로그 유형들의 임의의 조합의 혼합된 개발을 가능하게 하기 위해서도 사용될 수 있음을 알아야 한다.

본 발명의 한 양태에 따라, 도 3은 다이얼로그 API 프레임워크[예를 들어, 도 2의 프레임워크(204)]의 일부분(304)의 개략적인 블럭도이다. 혼합된 다이얼로그 유형 작성 시스템을 지원하기 위하여, 도시된 프레임워크(304)는 시멘틱-주도형 다이얼로그 컨테이너(306) 및 상태-주도형 다이얼로그 컨테이너(308)를 포함한다. 각 유형의 컨테이너가 한개씩만 도시되어 있지만, 특정 개발 스킴에 따라서는 어느 한 유형이 복수개 포함될 수도 있다. 다수의 다이얼로그 컨테이너와 그 내용 간의 기능적 관계는 본 명세서의 후반부로 감에 따라 점점 더 분명해질 것이다.

다이얼로그 컨테이너(306 및 308) 각각은 복수의 다이얼로그 요소(310)를 포함한다. 도시된 다이얼로그 요소들 전부가 동일한 참조 번호로 지칭되고 있지만, 다이얼로그 요소들마다 그 성질이 다를 수 있음을 알 수 있을 것이다. 일 실시예에 따르면, 각각의 다이얼로그 컨테이너는 거기에 포함된 다이얼로그 요소들의 활성화를 제어하도록 구성된다. 컨테이너(306)는 시멘틱-주도형 다이얼로그를 수용 및 실행하도록 구성되는 한편, 컨테이너(308)는 상태-주도형 다이얼로그를 수용 및 실행하도록 구성된다.

일 실시예에 따르면, 임의의 다이얼로그 컨테이너는 다이얼로그 요소의 역할을 받아들이도록 구성된다. 예를 들어, 한 다이얼로그 컨테이너는 다른 다이얼로그 컨테이너 내에서의 다이얼로그 요소로서 기능할 수 있다. 즉, 다이얼로그 컨테이너가 실질적으로 다이얼로그 컨테이너를 포함할 수 있는 것이다. 그러한 배치는 개발 유연성을 제공한다. 본 발명의 한 양태에 따르면, 기술된 프레임워크는 전체 어플리케이션이 개발자의 선호도에 따라 시멘틱-주도적으로, 상태-주도적으로, 또는 혼합되어 설계될 수 있게 해 준다. 일반적으로, 다이얼로그 요소들을 어떻게 조직화하고 연결할지에 관한 결정권은 개발자가 갖고 있으며, 여기에서 다이얼로그 컨테이너는 다양한 이용가능한 다이얼로그 요소들 중 하나의 특정한 요소이다. 이 하에 설명되는 바와 같이, 개발자는 특수화된 API의 형태로 된 광범위한 다이얼로그 요소들을 사용하여, 대응하는 광범위한 특수 기능들을 제공할 수 있다.

본 발명의 한 양태에 따르면, 보다 더 높은 API의 레벨[즉, 도 2의 프레임워크(204)의 레벨]에서, 개별 다이얼로그 요소, 시멘틱 구동 다이얼로그, 및 모든 유형의 다이얼로그를 지원하기 위한 기반구조를 위한 지원이 존재한다. 일 실시예에서, API 레벨은 상태-주도형 다이얼로그에 대한 지원도 포함한다. 그러나 다른 실시예에서는, 개발을 용이하게 하기 위하여, 상태-주도형 다이얼로그에 대한 명시적인 지원은 API 프레임워크의 최상위에 구축된 도구 컴포넌트에 포함될 수 있다. 서로 다른 다양한 특정 구현들 중 임의의 것이 가능하도록 도구와 API 간의 경계를 조절하는 것도 본 발명의 범위 내에 포함된다는 점에 유의해야 한다. 그러한 구성들 모두가 본 발명의 범위 내에 포함된다.

설명된 개발 프레임워크에 관련된 다른 이점은, 다이얼로그 요소들이 일반적으로 상태 또는 시멘틱-주도형 다이얼로그 컨테이너 중 한 컨테이너 내에서, 또는 그와 독립하여 동작하도록 구성된다는 점이다. 상이한 유형의 다이얼로그 요소들에 대한 상세한 설명에 들어가기 전에, 시멘틱-주도형 다이얼로그와 상태-주도형 다이얼로그를 혼합하는 어플리케이션을 개발하는 것이 어떤 것인지에 관한 일례가 이하에 제공될 것이다.

혼합 포맷의 다이얼로그 개발의 일례에 따르면, 개발자는 빈 캔버스에서 시작하여, 순서대로 실행될 연속적인 다이얼로그 컴포넌트들을 표현하는 3개의 노드를 추가한다. 개발자는 제1 노드로 내려가서, "환영합니다"와 같은 문장 (statement)을 삽입한다. 문장은 시멘틱-주도형 다이얼로그의 복잡한 기능을 필요로 하지 않는 단순한 다이얼로그 컴포넌트이다. 제1 노드에 대한 한가지 옵션은 상태-주도형 컨테이너를 생성하고, 거기에 문장 요소를 배치하는 것이다. 일 실시예에서, 개발 플랫폼은 어느 한 유형의 컨테이너를 생성하지 않고서도 문장의 확립을 편리하게 해 주도록 구성된다.

제2 노드는 실례적으로 사용자 정보를 모으는 프로세스를 용이하게 하도록 의도된 것이다. 개발자는 모아질 정보의 성질에 따라 수개의 옵션을 갖는다. 개발자는 상태-주도적인 정보 수집 프로세스를 용이하게 하는 요소들(예를 들면, "제품 ID 번호가 무엇입니까?", …, "이 물품을 언제 구매하셨습니까?" 등)을 갖는 상태-주도형 컨테이너를 생성할 수 있다. 대안적으로, 개발자는 시맨틱-주도적인 정보 수집 프로세스를 용이하게 하는 요소들(예를 들면, "신분을 밝혀주세요",…, "그런데, 성이 무엇입니까?",…, "네, 오늘은 무엇을 하시려고 합니까?"… 등)을 갖는 시멘틱-주도형 컨테이너를 생성할 수 있다.

설계자는 제3 노드를 어떻게 설계할지를 선택하는 데에 있어서도 유사한 옵션들을 가지며, 이는 실례적으로 사용자가 수행할 기능을 선택할 수 있게 해 주는 노드이다. 예를 들어, 사용자는 선택 대상이 되는 옵션들의 메뉴와 같은 상태-주도적인 시나리오를 제공받을 수 있다. 대안적으로, 사용자가 자신의 선택결과를 말하고 시스템이 그에 따라 응답하게 되는 시멘틱-주도적인 방법을 이용하여서도 결정이 이루어질 수 있다.

본 발명의 한 양태에 따르면, 다이얼로그 API 프레임워크는 어플리케이션 개 발자에 의한 개발에 이용가능하게 되는 다이얼로그 요소의 형태로 된 복수의 API 객체를 포함한다. 전술한 바와 같이, 다이얼로그 컨테이너는 다이얼로그 요소의 한 유형이며, 특정 유형의 다이얼로그의 개발 및 실행을 용이하게 하도록 구성된다.

다른 실시예에 따르면, Statement 요소는 프레임워크 내에 제공되는 다이얼로그 요소의 다른 유형이다. Statement 요소는 실례적으로 개발자에 의해 임의의 유형의 컨테이너 내에 배치될 수도 있고, 컨테이너의 외부에서 기능할 수도 있다. Statement 요소는 사용자로부터의 대답을 기대하지 않는 문장이 만들어질 수 있게 해 준다. 예를 들면, "환영합니다" 프롬프트, "안녕히 가십시오" 프롬프트, 또는 "죄송합니다. 오류가 있었습니다" 프롬프트가 포함된다.

다른 실시예에 따르면, QuestionAnswer 요소는 프레임워크 내에 제공되는 다이얼로그 요소의 다른 유형이다. QuestionAnswer 요소는 실례적으로 어떤 유형의 컨테이너 내로부터도 동작할 수 있다. QuestionAnswer 요소의 일반적인 기능은 사용자로부터 응답을 얻으려고 시도하는 것이다. 일 실시예에서, 이 요소는 교환이 성공적이지 않은 경우에 다시 질문하도록 구성된다 (예를 들어, "죄송합니다. 듣지 못했습니다. 다시 말씀해 주십시오"). 다른 실시예에서, QuestionAnswer 요소는 잘못된 인식을 다루기 위해 구비된다 (예를 들어, "죄송합니다. 이해하지 못했습니다. 다시 말씀해 주십시오"). 이 요소는 잘못된 인식이 발생한 경우에, 사용자에게 소정의 가이드를 제공하도록 구성된다 (예를 들어, "죄송합니다. 1 내지 10의 숫자로 답하셔야 합니다").

일 실시예에서, QuestionAnswer 요소는 음성 인식 다음의 후처리를 용이하게 하도록 구성된다. 예를 들어, QuestionAnswer 요소가 시멘틱-주도적인 컨텍스트 내에서 (예를 들어, 시멘틱-주도형 컨테이너 내로부터) 채용되는 경우, 그 요소는 사용자 응답으로부터 핵심 정보를 추출하고 필요에 따라 필드들을 채우는 프로세스를 용이하게 한다. 일 실시예에서, QuestionAnswer 요소가 시멘틱-주도적인 컨텍스트에서 사용될 때, 그 요소의 후처리 기능은 옵션이 아니다. 반대로, 상태-주도적인 컨텍스트에서는 후처리가 옵션일 수 있다.

일 실시예에서, 후처리 기능을 지원하기 위하여 QuestionAnswer 요소 내에 속성들이 설정될 수 있다 (예를 들어, 필드 A, B, C가 채워지면, X 후처리가 발생하는 것 등). QuestionAnswer 요소가 시멘틱-주도적인 다이얼로그 컨텍스트 내에 내장되기 위해서는, 후처리 기능을 지원하기 위하여 소정의 속성값들이 공급되어야만 한다. 일 실시예에서, QuestionAnswer 요소가 상태-주도형 다이얼로그 컨텍스트 내에 내장되는 경우, 개발자가 원한다면 후처리가 이용될 수는 있지만, 필수적인 것은 아니다.

예를 들어, 사용자가 "나가기"라고 말하고, 시스템이 "정말로 그만두기를 원하십니까"라고 응답하는 시나리오를 상상해보자. 사용자가 "네" 또는 "아니오"라고 대답하고 난 후, 아마도 그 응답은 어떠한 나중의 목적을 위하여 저장될 필요가 없을 것이다. 따라서, 그러한 상황 하에서는, 일반적으로 대응 속성을 설정하고 대응 후처리 단계들을 지정할 필요가 없다. 그 대신에, 개발자는 QuestionAnswer 요소를 상태-주도적인 컨텍스트 내에 내장하고, 인식이 완료된 후에 사용자 입력을 캡쳐하고 그에 따라 응답하도록 요소를 구성할 수 있다. 그러한 상태-주도적인 인터랙션을 용이하게 하는 것은 QuestionAnswer 요소의 능력 내에 있다. 그러나, 상태-주도형 다이얼로그 컨텍스트에서도, 후속 다이얼로그의 목적으로 입력을 캡쳐하는 것이 유용할 수 있다. 일 실시예에서, 그러한 경우에, 시스템은 필드를 직접 채우기 위하여 후처리를 활용하도록 구성될 수 있다.

일 실시예에 따르면, QuestionAnswer 요소는 시작시에 MainPrompt를 플레이하고, 음성 및/또는 DTMF를 듣고, 둘 이상의 음성 또는 DTMF 문법을 지원하고, 프롬프트를 플레이하는 동안 듣거나 듣지 않고, 프롬프트의 일부분이 플레이되고 난 후에 듣기 시작하여 표준 DialogElement(나중에 설명됨)와 같이 거동하고, 유효한 인식이 검출될 때까지 프롬프트를 계속하고, Help 및 Repeat 커맨드를 다루도록 프롬프트를 적응시키고, 무음 또는 무인식을 다루도록 프롬프트를 적응시키고, FormFillingDialog를 지원하고, 결과들을 SemanticItems에 바인딩하기 위한 메커니즘을 노출시키고, SemanticItem의 확인을 자동화하고/거나, 시멘틱 바인딩을 보는 것에 의해 FormFillingDialog를 결정하도록 구성된다.

다른 실시예에 따르면, SemanticItem 요소는 프레임워크 내에 제공되는 다른 유형의 다이얼로그 요소이다. SemanticItem 요소는 일반적으로 시멘틱-주도적인 컨텍스트 내에서 양식 필드들을 지원하는 클래스를 제공한다. 이러한 양식 필드들은 시멘틱-주도형 다이얼로그 프로세스 동안 채워지는 필드들이다.

다른 실시예에 따르면, FormFillingDialog 요소는 프레임워크 내에 제공되는 다른 유형의 다이얼로그 요소이다. FormFillingDialog 요소는 시멘틱-주도형 다이 얼로그를 구동하고 필드들을 채우는 관련 프로세스를 지원하는 컨테이너이다.

다른 실시예에 따르면, RecordSound 요소는 프레임워크 내에 제공되는 다른 유형의 다이얼로그 요소이다. RecordSound 요소는 실례적으로 어느 한 유형의 컨테이너 내로부터 또는 독립적으로 동작할 수 있다. RecordSound 요소의 일반적인 기능은 사용자로부터의 레코딩을 (예를 들어 임의의 인식 기능을 수행하지 않고서) 획득하는 것이다. 이러한 요소는 음성 메일 및 기타 유사한 어플리케이션의 컨텍스트에서 유용하다.

다른 실시예에 따르면, Command 요소는 프레임워크 내에 제공되는 다른 유형의 다이얼로그 요소이다. Command 요소는 실례적으로 어느 한 유형의 컨테이너 내로부터 또는 독립적으로 동작할 수 있다. Command 요소의 일반적인 기능은 어플리케이션의 주된 흐름과는 아무런 관련이 없는 사용자 입력의 캡쳐를 지원하는 것이다. 예를 들어, Command 요소는 사용자가 주된 다이얼로그에서 나가기 위한 수단으로서, "오퍼레이터"와 같은 커맨드를 말할 수 있게 하도록 구현될 수 있다. 일 실시예에서, 커맨드는 키를 누르는 것과 같이(예를 들어, "0" 키를 누름), 말에 의한 것이 아닐 수 있다. 일 실시예에서, Command 요소는 보편적으로 적용되도록 다이얼로그 어플리케이션의 최상위에서 작성된다 (예를 들어, 다이얼로그 중의 임의의 시간에서 "오퍼레이터"가 인식되면, 익스텐션 0으로 이동함). 다른 실시예에서, Command 요소는 컨텍스트 내에서 활성이도록, 또는 범위(scope)에 따라 활성이도록 작성될 수 있다. 그 요소는 실례적으로 전범위 또는 제한된 범위(예를 들어, 특정 컨테이너 내에서만) 상에서 활성일 수 있다. 따라서, 범위는 특정 다이얼로 그 요소 정도로 작을 수도 있고, 전체 어플리케이션 정도로 클 수도 있다. 따라서, Command 요소는 일반적으로 다이얼로그 흐름이 아니라 범위 또는 다이얼로그 영역에 의해 활성화된다.

다른 실시예에서, Application 요소는 프레임워크에 의해 제공되는 다른 유형의 다이얼로그 요소이다. Application 요소는 특정 다이얼로그 어플리케이션에 대한 최상위 레벨의 컨텍스트로서 기능한다. 이것은 전형적으로 최상위 레벨의 컨테이너를 인스턴스화한다. Application 요소의 일반적인 기능은 프레임워크 내의 요소들 간에서 발생하는 보다 더 낮은 레벨의 인터랙션들만큼 양호하게, 인터랙션들에 대한 가이드라인을 확립하는 것이다. Application 요소의 의무는 다양한 범위 내에서 변할 수 있지만, 자동 전화 응답, 통화 거부, 통화 종료, 호출 추적 과정, 소정의 내향 및 외향 호출 기능을 특정하게 지원하는 것, 및 접속 오류를 다루는 것을 포함하는 전화 어플리케이션의 다양한 양태들을 지원하기 위한 기본 단계의 구현을 포함한다.

프레임워크 내에는 다른 다이얼로그 기능의 구현을 돕는 추가의 헬퍼 객체들이 존재한다는 점을 알 것이다. 대부분의 요소들은 어느 한 유형의 컨테이너 내로부터, 또는 독립적으로 동작할 수 있다. 몇개의 요소는 무음, 오인식, 인식불가능한 응답(예를 들어, 인식되지 않는 언어로 된 응답), 잘못된 대답 등과 같은 예외를 다루도록 구성된다. 그러한 요소들은 특정 예외의 성질에 따라 어떤 다이얼로그가 실행될 것인지를 설정하기 위해 사용된다.

일 실시예에서, 시스템은 대응하는 텍스트들이 미리 결정되는 한, 프롬프트 선택을 자동으로 (즉, PromptSelection 요소를 이용하여) 지원하도록 구성된다. 런타임 동안 무엇이 발생하고 있는지를 결정하기 위하여, HistoryItem 요소와 같은 요소들이 사용된다. 마찬가지로, Logging 요소는 런타임 동안 무엇이 발생하고 있는지를 추적하는 데에 도움을 준다(예를 들어, API가 확립된 로깅 구조에 데이터를 제공함). HistoryItem 요소는 사용자가 사라질 때(예를 들어, 질문이 4회 행해지는 동안 응답은 없고 무음 또는 인식불가능한 응답만 있었던 경우)와 같이 통상적이지 않은 상황들에 대한 적절한 응답으로서 Bail-Out 요소의 구현을 용이하게 하는 데에 사용될 수 있다.

본 발명의 한가지 독특한 양태에 따르면, 다이얼로그 API 접근방식은 컨테이너 레벨에서 구현된다. 여기에 설명된 것과 그 외의 자식 요소들은 다이얼로그 컨테이너 내에 내장된 논리를 지원하여, 컨테이너들이 자식 요소들에 기능을 위임할 수 있게 한다. 전술한 바와 같이, 다이얼로그 컨테이너 내의 다이얼로그 요소는 실질적으로는 다른 다이얼로그 컨테이너일 수도 있다. 주어진 컨테이너의 컨텐츠에 상관없이, 한정적이지 않은 예로서 시멘틱-주도형 또는 상태-주도형 다이얼로그와 같은 특정 유형의 다이얼로그 유형을 지원하도록 구성된다.

컨테이너는 그 다이얼로그 요소들을 적절한 시퀀스로 활성화하는 데에 필요한 정보를 제공받는다. 시퀀스는 시멘틱-주도형 다이얼로그, 상태-주도형 다이얼로그 또는 다른 전략(strategy)과 같은 미리 정해진 전략을 적용하도록 구성되는지의 여부에 관련하여, 특정 컨테이너의 성질에 의해 적어도 부분적으로 결정된다. 본 발명의 일 실시예에서, 새로운 다이얼로그 컨테이너는 자신의 자식 다이얼로그 요소들에 대해 임의의 다이얼로그 전략을 구현하도록 생성될 수 있다.

일 실시예에 따르면, 설명된 다이얼로그 API 프레임워크는 소정 레벨의 코딩 자동화를 지원하는 도구의 생성을 지원하도록 구성된다. API/도구 쌍은 특히 낮은 레벨의 자원에 대해 직접적으로 코딩하는 것에 비하여, 실례적으로 개발자의 생산성을 향상시킨다.

본 발명의 한 양태에 따르면, 설명된 다이얼로그 API 프레임워크에 따라 개발된 다이얼로그 어플리케이션은 최상위 노드가 어플리케이션 그 자체인 트리로 볼 수 있다. 어플리케이션은 일련의 컴포넌트들로 구축되며, 그 컴포넌트들 간의 흐름을 관리한다. 그리고, 이러한 컴포넌트들은 다른 컴포넌트들 상에 구축될 수 있다. 트리 내의 리프 노드(leaf node)에서는, 가장 작고 가장 기본적인 다이얼로그 컴포넌트들이 발견된다. 설명된 구조는 서브다이얼로그 재사용, 및 사전-패키지화(prepackaging)된 어플리케이션 및 컴포넌트의 생성을 효율적으로 지원한다.

각각의 컴포넌트는 그 자식 컴포넌트들 간의 "흐름"을 관리한다. 흐름은 (시멘틱-주도형 또는 상태-주도형 다이얼로그에서처럼) 비교적 동적일 수도 있고, 본질적으로 비교적 절차적일 수도 있다. 어떠한 경우에서든, 컴포넌트를 활성화하는 것은, 실례적으로 컴포넌트가 "자신의 작업을 하려고" 시도하거나, 작업이 행해졌거나 소정의 오류가 발생된 때에 호출자(부모)에게 보고하도록 하는 것을 포함한다. 그러면, 다른 자식들을 갖는 컴포넌트는 활성화시에 활성화할 첫번째 자식을 찾고, 그것이 행해질 때까지 기다리고, 다음으로 어떤 것을 실행할지를 결정하는 것 등을 행할 것이다.

일부 다이얼로그 시나리오는 "흐름"에 의해 완전하게 작성될 수는 없지만, 컨텍스트 변경에 대해 직접적으로 호출한다. 이러한 인터랙션은 더 양호하게는 흐름의 인터럽션, 및 어플리케이션 내의 다른 태스크로의 점프로 볼 수 있다. 일 실시예에서, 이러한 인터럽션은 사용자가 특정 커맨드를 말하는 것에 의해 트리거된다. 그러면, 그 커맨드의 인식은 컨텍스트 변경 및 새로운 태스크의 실행을 유발한다.

전술한 바와 같이, 다이얼로그 API 프레임워크는 실례적으로 오브젝트들의 2가지 주된 유형의 오브젝트들, 즉 DialogElement 및 DialogContainer를 지원한다. 주된 응용은 실례적으로 DialogContainer이며, 여기에서 새로운 DialogContainer는 유도에 의해 정의되며, 새로운 컨테이너마다 새로운 클래스가 정의된다. 이러한 컨테이너들은 런타임에서 인스턴스화되어 실행된다. 이러한 모델 내의 서브다이얼로그는 (서브루틴 호출 대신) 컴포넌트 재사용으로 볼 수 있다.

일 실시예에서, DialogContainer는 기술적으로는 다른 DialogContainer를 직접 포함하지 않지만, 다른 다이얼로그 컨테이너를 "호출"한다. 이것은 실례적으로 DialogReference 프리미티브 또는 요소의 이용을 통해 달성된다. DialogReference는 실례적으로 임의의 DialogContainer를 참조할 수 있는 속성들을 노출하므로, 런타임에서 인스턴스화될 수 있다. 참조된 DialogContainer는 그 실행을 완료한 때에, 그것을 인스턴스화한 DialogReference에 알려준다. 그러면, 부모 DialogContainer는 통상적인대로 흐름을 재개할 수 있다.

일 실시예에서, DialogElement는 실행을 시작하기 위한 방법을 노출하고, 실 행을 중단/취소하기 위한 방법을 노출하고, 비동기적으로 실행하고, 자신이 더 이상 실행중이 아닐 때에 어플리케이션에 알려주고, 자신이 실행중이지 않은 이유(완료됨, 최소됨, 오류 등)를 어플리케이션에게 알려주고, 자신이 언제 시작되는 때를 어플리케이션에 알려주고, Application 오브젝트(및 관련 시그널링 및 통합된 API들)에 액세스하도록 구성된다. DialogElement는 실례적으로 구성가능(composable)하며, 구성된 때에는 그 부모에 대한 액세스를 가질 것이다.

본 발명의 한 양태에 따르면, 설명된 다이얼로그 API 프레임워크의 기능을 노출시키기 위하여 임의의 작성 환경이 제공될 수 있다. 그러한 작성 환경은 API 단독일 수도 있고, API + 도구일 수도 있고, 도구 단독일 수도 있으며, 본 발명의 범위를 벗어나지 않은 임의의 다른 구현일 수도 있다.

본 발명이 특정 실시예들을 참조하여 설명되었지만, 당업자들은 본 발명의 범위 및 취지를 벗어나지 않고서 형태 및 세부사항에 변경이 이루어질 수 있음을 알 것이다.

본 발명에 따르면, 개발자가 어플리케이션 내에서 상이한 유형의 다이얼로그들을 용이하게 혼합할 수 있게 된다.

Claims (20)

1. 하나 이상의 컴퓨터 판독가능 매체 상에 구현되는 어플리케이션 프로그램 인터페이스로서,

   어플리케이션 내에서 제1 유형의 다이얼로그의 개발을 용이하게 하도록 구성된 제1 다이얼로그 컨테이너, 및

   상기 어플리케이션 내에서 제2 유형의 다이얼로그의 개발을 용이하게 하도록 구성된 제2 다이얼로그 컨테이너

   를 포함하는 어플리케이션 프로그램 인터페이스.
2. 제1항에 있어서, 상기 제1 및 제2 다이얼로그 컨테이너 중 한 컨테이너 내로부터 동작하도록 구성된 적어도 하나의 다이얼로그 요소를 더 포함하는 어플리케이션 프로그램 인터페이스.
3. 제1항에 있어서, 상기 제1 유형의 다이얼로그는 시멘틱-주도형 다이얼로그(semantics-driven dialog) 또는 상태-주도형 다이얼로그(state-driven dialog) 중 하나인 어플리케이션 프로그램 인터페이스.
4. 제1항에 있어서, 낮은 레벨의 시스템 자원들에 대한 인터페이스로서 기능하는 코어 API 프레임워크를 더 포함하는 어플리케이션 프로그램 인터페이스.
5. 제1항에 있어서, 상기 어플리케이션 프로그램 인터페이스와 인터랙션하기 위한 개발 프레임워크를 제공하는 도구를 더 포함하는 어플리케이션 프로그램 인터페이스.
6. 제1항에 있어서, 상기 제1 및 제2 다이얼로그 컨테이너는 상기 컨테이너들 내에 포함된 다이얼로그 요소들의 활성화를 지원하는 정보를 공급받는 어플리케이션 프로그램 인터페이스.
7. 개발자가 어플리케이션 내에 상이한 유형의 다이얼로그들을 혼합할 수 있게 해 주는 컴퓨터 구현 방법으로서,

   상기 어플리케이션 내에서 제1 유형의 다이얼로그의 개발을 용이하게 하도록 구성된 제1 개발 자원을 제공하는 단계, 및

   상기 어플리케이션 내에서 제2 유형의 다이얼로그의 개발을 용이하게 하도록 구성된 제2 개발 자원을 제공하는 단계

   를 포함하는 방법.
8. 제7항에 있어서, 상기 제1 및 제2 개발 자원 중 하나에 관련하여 동작하도록 구성된 적어도 하나의 개발 자원을 제공하는 단계를 더 포함하는 방법.
9. 제7항에 있어서, 상기 제1 개발 자원을 제공하는 단계는, 시멘틱-주도형 다이얼로그의 개발을 용이하게 하도록 구성된 제1 다이얼로그 컨테이너를 제공하는 단계를 포함하는 방법.
10. 제9항에 있어서, 상기 제2 개발 자원을 제공하는 단계는, 상태-주도형 다이얼로그의 개발을 용이하게 하도록 구성된 제2 다이얼로그 컨테이너를 제공하는 단계를 포함하는 방법.
11. 제10항에 있어서, 상기 제1 또는 제2 다이얼로그 컨테이너 중 한 컨테이너 내로부터 동작하도록 구성된 적어도 하나의 다이얼로그 요소를 제공하는 단계를 더 포함하는 방법.
12. 제10항에 있어서, 상기 제1 및 제2 개발 자원을, 상기 제1 다이얼로그 컨테이너의 인스턴스가 상기 제2 다이얼로그 컨테이너의 인스턴스 내로부터 동작할 수 있도록, 또는 상기 제2 다이얼로그 컨테이너의 인스턴스가 상기 제1 다이얼로그 컨테이너의 인스턴스 내로부터 동작할 수 있도록 구성하는 단계를 더 포함하는 방법.
13. 제11항에 있어서, 상기 다이얼로그 요소들은 Statement 요소, QuestionAnswer 요소, SemanticItem 요소, FormFillingDialog 요소, RecordSound 요소, Command 요소 및 Application 요소를 포함하는 집합으로부터 선택된 요소를 포함하는 방법.
14. 제13항에 있어서, 상기 집합으로부터 선택된 적어도 하나의 요소는 상기 제1 개발 자원 및 상기 제2 개발 자원 중 한 자원 내로부터 동작할 수 있는 방법.
15. 제7항에 있어서, 상기 제1 및 제2 개발 자원에, 낮은 레벨의 시스템 자원들에 대한 인터페이스로서 기능하는 코어 API 프레임워크로의 액세스를 제공하는 단계를 더 포함하는 방법.
16. 개발자가 어플리케이션 내에 상이한 유형의 다이얼로그들을 혼합할 수 있게 해 주기 위한 다이얼로그 시스템으로서,

    복수의 제1 다이얼로그 요소를 포함하는 제1 다이얼로그 컨테이너를 포함하고,

    상기 제1 다이얼로그 컨테이너는 제1 다이얼로그 전략(dialog strategy)에 따라 상기 복수의 제1 다이얼로그 요소를 처리하는 것을 용이하게 하도록 구성된 다이얼로그 시스템.
17. 제16항에 있어서, 상기 제1 다이얼로그 컨테이너 내에 포함된 제2 다이얼로그 컨테이너를 더 포함하고,

    상기 제2 다이얼로그 컨테이너는 복수의 제2 다이얼로그 요소를 포함하며, 상기 제1 다이얼로그 전략과는 다른 제2 다이얼로그 전략에 따라 상기 복수의 제2 다이얼로그 요소를 처리하는 것을 용이하게 하도록 구성되는 다이얼로그 시스템.
18. 제17항에 있어서, 상기 제1 및 제2 다이얼로그 전략 중 하나는 시멘틱-주도형 다이얼로그이고, 다른 하나는 상태-주도형 다이얼로그인 다이얼로그 시스템.
19. 제16항에 있어서, 상기 제1 다이얼로그 전략은 커스텀-정의된(custom-defined) 전략인 다이얼로그 시스템.
20. 제16항에 있어서, 상기 제1 다이얼로그 전략의 적어도 일부는 개발자에 의해 구성되는 다이얼로그 시스템.

Images