KR101560600B1

KR101560600B1 - 통합 메시징 상태 기계

Info

Publication number: KR101560600B1
Application number: KR1020107005922A
Authority: KR
Inventors: 토마스 더블유. 밀레트; 스리니바사 만다
Original assignee: 마이크로소프트 테크놀로지 라이센싱, 엘엘씨
Priority date: 2007-09-24
Filing date: 2008-09-17
Publication date: 2015-10-16
Anticipated expiration: 2028-09-17
Also published as: US20090083709A1; KR20100059878A; CN101809609A; EP2193492A4; US8074199B2; WO2009042456A1; RU2010111118A; RU2470364C2; BRPI0815183A2; EP2193492A1; CN101809609B; JP5228053B2; JP2010541387A

Abstract

UM(unified messaging) 애플리케이션은 XML(eXtended Markup Language)의 플랫폼 독립성 및 인간 이해도로부터 이익을 얻는다. UM 소프트웨어 컴포넌트에 기초하여 유효 메뉴 상태를 생성하기 위해 XML 특징을 이용하여 UM 애플리케이션의 FSM(finite state machine)이 생성된다. UM 애플리케이션의 컨텍스트 또는 설정인 UM 소프트웨어 컴포넌트에 대하여, XML 조건 속성(conditional attribute)은 UM FSM의 프롬프트, 천이 또는 문법 노드를 결정(condition)한다. XML 스니핏(snippet)인 UM 소프트웨어 컴포넌트에 대하여, XML 가져오기(importation) 엘리먼트는 컴파일 시에 XML 스니핏을 복제하여, 수동 코드 복제에 대한 시간 소모적이고 오류를 범하기 쉬운 요건들을 피한다. 외부 메서드, 함수, 변수 또는 액션과 같은 UM 소프트웨어 컴포넌트에 대하여, 함수 래핑(function wrapping) XML 도구가 작성 시간에 그러한 외부 UM 소프트웨어 컴포넌트의 존재의 유효성을 검사하고 실행시에 동일한 버전의 이용 가능성을 확인하기 위해 버전 정보를 캡처한다.

Description

통합 메시징 상태 기계{UNIFIED MESSAGING STATE MACHINE}

본 발명은 일반적으로 컴퓨터 시스템에 관한 것이고, 더 상세하게는, 본 발명은 메뉴 활동들(menu activities), 프롬프트들(prompts), 또는 천이들(transitions)을 융통성 있는(flexible) 입상의(granular) 명백한(explicit) 방식으로 특정하고, 하드 코딩된 상태 기계들 또는 문서 서버들의 영역 밖에 있는 파일 선언들을 통해 메뉴 구동형의(menu driven) 통신 애플리케이션들의 동적인 구성을 용이하게 하는 시스템들 및 방법들에 관한 것이다.

통신 기술은 정보 시대의 빠르게 변화하는 요건들의 선두에 있다. 불과 몇 년 전만 해도, 팩스 기계 기술은 콘텐트를 전자적으로 인코딩하고 전화선을 통하여 메시지를 전달함으로써 우편으로 정보를 수신하는 전통적인 방식을 위협하였다. 이 기술은 수백 년 동안 비즈니스가 수행된 방식에 혁명을 일으켰다. 거의 팩스 기계가 보편화되자마자, 전자 메일 또는 이메일로 알려진 새로운 기술이 이전에 배타적으로 팩스 기계의 영역에 있던 많은 애플리케이션들을 따라잡기 시작하였다. 이메일 애플리케이션들이 성장했을 때, 인스턴트 메시징 서비스와 같은 또 다른 통신 기술들이 발전하였고 이들은 다시 다른 형태의 통신들을 위협하였다. 이메일 및 팩스 기계와 같은 텍스트 구동형의 기술들과 함께, 음성 통신도 배선에 의한(hard wired) 접속들로부터 오늘날의 항상 인기 있고 성장하는 무선 기술들로 변화하였다.

많은 사용자들이 이용할 수 있는 매우 다양한 통신 옵션들을 관리하기 위하여, 사용자들이 이용할 수 있는 다수의 통신 옵션들을 처리하기 위한 서비스를 제공하는 통합 메시징(UM; Unified Messaging) 애플리케이션들이 나타나기 시작하였다. 통합 메시징은 일반적으로 음성, 팩스, 이메일 등의 통합을 함축하는 것으로 사용자가 임의의 선택 단말기로부터 언제든 어디서든 이들 메시지들 중 임의의 것에 액세스할 수 있게 한다. 통합 메시징 시스템의 한 가지 목표는 회사 또는 다른 단체 내에서 시간과 비용 절약을 달성하기 위해 통신 프로세스들을 단순화하고 능률을 올리는 것이다.

현대의 통신 시스템들의 한 가지 공통된 특징은 사용자들이 일반적으로 이들 시스템들을 특정 통신 선호에 맞추기 위하여 상이한 스타일 메뉴들로부터 다양한 구성 옵션들을 제공받는다는 것이다. 따라서, 음성 메일, 통합 메시징 및 다른 지능형 음성 인식(IVR; Intelligent Voice Recognition) 애플리케이션들은 전형적으로 메뉴 구동형인 사용자 인터페이스들을 갖는다. 메뉴는, 예를 들면, 전화 상의 최종 사용자에게 플레이(play)될 수 있는 하나 이상의 프롬프트로 구성된다. 사용자는 하나 이상의 방법에 의해 예컨대 DTMF(dual tone multi frequency) 키패드를 이용하는 것에 의해 메뉴 선택을 행한다. DTMF 내비게이션 기법들은 다수의 입력 옵션들이 존재하는 경우에 성가신 것으로 판명될 수 있다. 더욱이, 핸즈프리(hands-free) 통신 장치들의 사용이 증가함에 따라, DTMF 키패드 입력은 편리하거나 적절하지 않을 수 있다.

최근, UM 메뉴 애플리케이션들을 더욱 사용하기 쉽게 하기 위해 그 애플리케이션들에서 어느 정도까지는 자동 음성 인식(ASR; automatic speech recognition)이 채용되었다. 그러나, 언어, 방언, 음성 패턴, 및 개인 성향에 큰 변화가 있으면, ASR은 높은 실패율을 피하기 위해 많은 수의 가능한 음성 시나리오들을 처리해야 한다. 그러므로, 종래의 상태 기계들과 같은 하드 코딩된 해법들은 부담이 되는 코드 개발 및 테스트 없이는 새로운 UM 특징들을 수용할 수 없기 때문에 비현실적인 것이 된다.

다음은 본 발명의 일부 양태들에 대한 기초적인 이해를 제공하기 위하여 본 발명의 간략화된 개요를 제공한다. 이 개요는 본 발명의 광범위 개관은 아니다. 이것은 본 발명의 중요한/결정적인 요소들을 식별하거나 또는 본 발명의 범위를 서술하기 위한 것이 아니다. 이것의 유일한 목적은 뒤에 제공되는 보다 상세한 설명의 서문으로서 간략화된 형태로 본 발명의 일부 개념들을 제공하기 위한 것이다.

본 발명은 통합 메시징(UM) 애플리케이션의 프로그래밍을 위한 시스템들 및 방법들에 관한 것이다. 특히, 사용자 프롬프트들에 의해 정의되는 메뉴 상태들 및 사용자 응답에 따른 다른 메뉴 상태로의 천이들의 유한 상태 기계(FSM; finite state machine)를 생성하기 위해 프로그래밍 환경에 의해 XML(eXtended Markup Language)의 플랫폼 독립성 및 인간 이해도(human intelligibility)의 이익들이 이용된다. 하나의 양태에서, 상기 프로그래밍 환경은 상기 UM 소프트웨어 컴포넌트에 기초하여 유효한 메뉴 상태를 생성하기 위해 XML 특징을 이용한다. 그에 의해, 증가된 복잡도의 메뉴가 생성될 수 있다.

전술한 및 관련된 목적들을 달성하기 위하여, 본 발명의 특정한 예시적인 양태들이 다음의 설명 및 첨부 도면들과 관련하여 여기에 설명된다. 이들 양태들은 본 발명이 실시될 수 있는 다양한 방식들을 나타내고, 그들 전부는 본 발명에 의해 커버되도록 의도되어 있다. 본 발명의 다른 이점들 및 신규한 특징들은 도면들과 함께 고찰될 때 본 발명에 대한 다음의 상세한 설명으로부터 명백해질 수 있다.

도 1은 본 발명의 양태에 따른 구성 가능한 메시징 시스템에 대한 프로그래밍 환경의 개략 블록도를 도시한다.
도 2는 도 5의 메시징 시스템의 예시적인 메뉴 옵션의 블록도를 도시한다.
도 3은 도 2의 메뉴 옵션의 확장에 대한 예시적인 묘사를 도시한다.
도 4는 도 3의 메시징 시스템에 따른 메뉴 계층의 예시적인 묘사를 도시한다.
도 5는 도 1의 프로그래밍 환경에 대하여 디렉터리 검색 메뉴들의 가져오기(importation)에 의해 생성된 메뉴 계층의 블록도를 도시한다.
도 6은 도 1의 프로그래밍 환경의 이용에 의해 용이하게 되는 메뉴 계층의 예시적인 블록도이다.
도 7은 본 발명의 양태에 따른 문법 엔진에 의해 강화된 호출 세션(call session)의 블록도이다.
도 8은 도 1의 프로그래밍 환경에 의해 생성된 구성 가능한 메시징 시스템을 예시하는 개략 블록도를 도시한다.
도 9는 본 발명의 양태에 따른 예시적인 구성 파일을 예시하는 블록도를 도시한다.
도 10은 본 발명의 양태에 따른 예시적인 통합 메시징 시스템의 블록도를 도시한다.
도 11은 메시지 프롬프트들의 지역화를 갖는 예시적인 통합 메시징 시스템의 블록도를 도시한다.
도 12는 본 발명의 양태에 따른 적합한 운영 환경을 예시하는 개략 블록도를 도시한다.
도 13은 본 발명과 상호작용할 수 있는 샘플-컴퓨팅 환경의 개략 블록도를 도시한다.

본 발명은 통합 메시징(UM) 애플리케이션의 일부로서 전자 통신 대화의 동적인 프로그래밍 및 실행을 가능하게 하는 시스템들 및 방법들에 관한 것이다. 특히, 사용자 프롬프트들에 의해 정의된 메뉴 상태들 및 사용자 응답에 따른 다른 메뉴 상태로의 천이들의 유한 상태 기계(FSM)를 생성하기 위해 프로그래밍 환경에 의해 XML(eXtended Markup Language)의 플랫폼 독립성 및 인간 이해도(human intelligibility)의 이익들이 이용된다. 상기 프로그래밍 환경은 상기 UM 소프트웨어 컴포넌트에 기초하여 유효한 메뉴 상태를 생성하기 위해 XML 특징을 이용한다. 그에 의해, 증가된 복잡도의 메뉴가 생성될 수 있다. 하나의 양태에서, UM 애플리케이션의 컨텍스트 또는 세팅(예를 들면, 특정 사용자에 대한 UM 서비스의 이용 가능성)인 UM 소프트웨어 컴포넌트에 대하여, 프로그래밍 환경은 UM FSM의 프롬프트, 천이 또는 문법 노드를 결정(condition)하기 위해 XML 조건 속성(conditional attribute)을 이용한다. 그에 의해, 맞춤형 응답을 위한 메뉴 구조에 하이 레벨 결정들이 도입될 수 있다. 다른 양태에서, XML 스니핏(snippet)의 UM 소프트웨어 컴포넌트에 대하여, 프로그래밍 환경은 컴파일 시에 XML 스니핏을 복제하기 위해 XML 가져오기 엘리먼트(importation element)를 이용하여, 수동 코드 복제에 대한 시간 소모적이고 오류를 범하기 쉬운 요건들을 피할 수 있다. 또 다른 양태에서, 외부 메서드, 함수, 변수 또는 액션과 같은 UM 소프트웨어 컴포넌트에 대하여, 프로그래밍 환경은 작성 시간(build-time)에 그러한 외부 UM 소프트웨어 컴포넌트들의 존재의 유효성을 검사하기 위해 함수 래핑(function wrapping) XML 도구를 이용하고 실행시에 동일한 버전의 이용 가능성을 확인하는 데 도움이 되는 버전 정보를 캡처한다. 그에 의해, 시스템 무결성이 확보된다.

이 출원에서 사용될 때, "컴포넌트", "파일", "시스템", "개체", "컨트롤러" 등의 용어들은 컴퓨터 관련 엔티티, 하드웨어, 하드웨어와 소프트웨어의 조합, 소프트웨어, 또는 실행중인 소프트웨어를 나타내도록 의도되어 있다. 예를 들면, 컴포넌트는 프로세서에서 실행하는 프로세스, 프로세서, 개체, 실행 파일(executable), 실행 스레드(thread of excution), 프로그램, 및/또는 컴퓨터일 수 있지만, 그것에 제한되지 않는다. 예시로서, 서버에서 실행하는 애플리케이션 및 서버는 둘 다 컴포넌트일 수 있다. 하나 이상의 컴포넌트들이 프로세스 및/또는 실행 스레드 내에 존재할 수 있고 컴포넌트는 하나의 컴퓨터에 국한(localize)되거나 및/또는 2개 이상의 컴포넌트들 사이에 분산될 수 있다. 또한, 이들 컴포넌트들은 다양한 데이터 구조들이 저장되어 있는 다양한 컴퓨터 판독 가능한 매체로부터 실행할 수 있다. 컴포넌트들은 예컨대 하나 이상의 데이터 패킷들에 따라서 로컬 및/또는 원격 프로세스들을 통해 통신할 수 있다(예를 들면, 로컬 시스템, 분산 시스템에서 다른 컴포넌트와, 및/또는 인터넷과 같은 네트워크를 가로질러 신호를 통해 다른 시스템들과 상호작용하는 하나의 컴포넌트로부터의 데이터).

도 1에서, 통합 메시징(UM) 구현 시스템(12)의 UM 프로그래밍 환경(10)은 융통성 있는 프로그래밍 구성들, 현존하는 프로그램 엘리먼트들의 재사용, 및 프로그래밍 환경(10)에 의해 생성되고 UM 실행 기계(16) 상에서 이용되는 생성된 UM 애플리케이션(14)의 무결성의 확인을 용이하게 한다.

예시적인 버전에서, 에디터(18)는 UM 애플리케이션들의 빠르게 변화하는 요구들을 만족시킬 수 있는 UM 메뉴 유한 상태 기계(FSM)(20)를 생성한다. 메시지들을 처리하기 위한 제어 엘리먼트들 및 하드 코딩된 특성의 부담들을 경감하기 위하여, FSM(20)을 생성하는 데 XML(eXtensible Markup Language)이 이용된다. XML은 그의 사용자들이 그들 자신의 태그들을 정의할 수 있게 하기 때문에 확장 가능한 언어로서 분류된 범용 표시 언어(markup language)이다. XML은 상이한 정보 시스템들을 가로질러, 특히 인터넷을 통해, 구조화된 데이터의 공유를 용이하게 한다. 따라서 그것의 사용은 문서 인코딩 분야 및 데이터 직렬화 분야 양쪽 모두를 망라한다.

문서(또는 애플리케이션이라 불리는 관련 문서들의 세트)는 대화형 UM 유한 상태 기계(20)를 형성한다. 사용자는 항상 한 번에 하나의 대화형 상태, 즉 대화(dialog) 중에 있다. 각 대화는 천이할 다음 대화를 결정한다. 천이들은 사용할 다음 문서 또는 대화를 정의하는 식별자들에 의해 특정된다. 사용자는 사용자 인터페이스(도시되지 않음)를 통하여 에디터(18)와 상호작용하여 UM 프롬프트들(22), 및 천이들(24)로서 도시된 대화들/상태들을 어셈블한다. 유리하게도, 사용자는 UM XML 정의 파일들(26)로서 도시된 XML 스니핏들을 재사용할 수 있다. 이는 프로그래밍 환경(10)이 XML 서브루틴들 및 파일 포함들에 대한 지원을 제공하기 때문이다. 예를 들면, DTMF 스펠링을 이용하여 '사용자를 찾는(find a user)' 코드는 매우 복잡한 시퀀스의 메뉴들이다(예를 들면, 처음 것은 스펠링을 묻고, 두 번째 것은 확인하고, 다른 것은 사용자가 다시 시작하게 하고, 다른 것은 어떤 결과도 발견되지 않은 것을 말하는 등). 또한, '사용자를 찾는' 특징은 다수의 위치들에서 이용될 수 있다(예를 들면, 그를 호출할 목적으로 콘택트를 조회하고, 음성 메일을 전송할 사람의 주소를 찾고, 회의 요청을 전송할 사람의 주소를 찾는 등). 그 결과, 각 컨텍스트에 대하여 정확히 XML 스니핏들을 복제할 필요가 자주 일어난다.

그 때문에, 28에 도시된 <FsmImport>라 불리는 XML 언어 엘리먼트가 상태 기계 정의에 포함된다. 이 엘리먼트는 'FsmModule'의 이름 및, 옵션으로, 파일 참조를 포함한다. 시스템 시동시에, FsmImport 태그들은 그들의 참조된 모듈들로 확장될 수 있다. 예를 들면, 다음 태그는 파일 'Common.fsm' 내의 'SearchMenus'라 불리는 코드의 XML 블록에 의해 대체될 것이다:

도 2는 가져오기(import) 특징으로부터 이익을 얻지 않는 애플리케이션(32)의 묘사이다. 애플리케이션(18)이 당신이 각종의 상이한 교환 항목들을 사용자에게 "전달(forward)"할 수 있게 한다고 생각해보자. 예를 들면, 이메일 메시지, 음성 메일 메시지, 또는 캘린더 항목이 전달될 수 있다. 모든 이들 옵션들은 XML 정의들에서 상이한 "메뉴 상태들"을 통해 표현된다. 이는 각각이 많은 점에서 실제로 서로 완전히 다르고 고유의 프롬프트들 및 천이들을 필요로 하기 때문이다. 그러나, 전달된 메시지를 누가 수신해야 하는지를 생각해내는 데에 이르면, 각각은 이에 관하여 동일하지는 않을지라도 매우 유사하다. 전달에 대한 예시적인 대화는 다음과 같을 수 있다:

시스템: "who do you want to forward this to?"

사용자: "Tom"

시스템: "I think you said John, is that right"

사용자: "No, I said Tom"

시스템: "Oh, OK. Tom, right"

사용자: "Yes"

그러한 대화는 실제로는 매우 복잡할 수 있고, 상이한 방식으로 상호작용하는 다수의 상이한 메뉴들을 필요로 할 수 있다. 각 디렉터리 검색 메뉴는 도 2에 도시된 각 전달 구조에서 각각 디렉터리 검색 메뉴(directory search menu)(36)를 거쳐서 이메일 전달된 문(email forwarded statement)(38)으로 가는 이메일 전달 문(email forwarding statement)(34)으로서 복제되어야 한다. 음성 메일 전달 문(40)은 디렉터리 검색 메뉴(42)의 제1 복제를 거쳐서 음성 메일 전달된 문(44)으로 간다. 캘린더 전달 문(46)은 디렉터리 검색 메뉴(48)의 제2 복제를 거쳐서 캘린더 전달된 문(50)으로 간다.

도 3의 묘사는 실행 시간에 서브루틴들을 "가져오기" 위한 메커니즘을 갖는 것이 어떻게 그러한 XML 스니핏들을 복제할 필요를 피하는지를 예시한다. XML 구성 파일들에 나타나는 FsmImport 용어는 XML FsmModule들을 소비한다. 따라서 이메일 전달 문(34)을 이메일 전달된 문(38)에 연결하고, 음성 메일 전달 문(40)을 음성 메일 전달된 문(44)에 연결하고, 캘린더 전달 문(46)을 캘린더 전달된 문(50)에 연결하여 검색 메뉴(32')를 형성하기 위해 디렉터리 검색 메뉴(36)의 단일 사본이 재사용될 수 있다. 검색 메뉴(32')에 대한 XML 코드는 샘플 1로서 작성될 수 있다:

10번째 라인은, XML 정의들을 소비하는, 유한 상태 기계 엔진에게 Search.fsm이라는 이름의 파일을 들여다보고 그 메뉴 정의들을, 인라인으로, EmailManager 컨텍스트 내에 가져올 것을 요구한다. 그것은 ID EmailForwardStatement를 갖는 메뉴가 SearchMenuStart라는 이름의 메뉴를 참조할 수 있게 하는 것이고, 그렇지 않다면 SearchMenuStart라는 이름의 메뉴는 참조되는 파일에만 있기 때문에 EmailManager 컨텍스트에서 나타나지 않는다.

에디터(18)는 또한 FSM(20)의 프로그래밍의 용이함 및 추가적인 복잡도를 용이하게 하기 위해 상태 기계 메뉴 정의들에 조건 속성들(60)의 추가된 XML 엘리먼트를 이용할 수 있다. 도 4에서 메뉴(70)는 사용자에게 플레이할 명령들("프롬프트들")의 세트 및 사용자 입력에 기초하여 다음 상태가 되어야 하는 것("천이들")에 의해 생성된 4개의 상태들만으로 구성된다고 생각해보자. 예시적인 예에서, 메인 메뉴 상태(72)는 사용자에게 음성 메일을 위해서는 "1"을, 이메일을 위해서는 "2"를, 또는 캘린더를 위해서는 "3"을 누를 것을 요구한다. 사용자가 누르는 것에 따라서(사용자가 74에서 "1"을 누르고, 76에서 "2"를 누르고 또는 78에서 "3"을 누르는 것으로 도시되어 있음), 대화는 음성 메일 서브시스템(80), 이메일 서브시스템(82) 또는 캘린더 서브시스템(84)의 각각의 상태로 이동한다.

XML을 이용하여 이 정보를 인코딩하는 것은 이 특정 메뉴(70)에 대하여 샘플 2에서 다음과 같을 수 있다:

각 메뉴 상태(72, 80, 82, 84)는 "컨텍스트"에서 존속한다는 것을 이해해야 한다. 메인 메뉴 상태(72)는 이 특정 메뉴에 관련된 어떤 정보를 저장하는, GlobalManager라 불리는, 메모리 내의 개체가 존재한다는 점에서 "글로벌 매니저 컨텍스트(global manager context)"에서 존속한다. GlobalManager에 대한 코드의 예는 샘플 3에서 다음과 같을 수 있다:

도 5에서, UM 메뉴(86)는 유리하게도 조건 XML 엘리먼트 속성들을 포함한다. 특징 설계는 이메일 옵션이 호출자가 그것에 액세스할 수 있게 하는 플래그를 관리자가 특정한 경우에만 플레이하도록 요구한다고 생각해보자. 이것은 메인 메뉴(72)가 시작하기도 전에, 이메일 가능 조건(email enabled conditional)(88)으로서 도시된, 최상위 레벨 판정을 도입하는 것으로 간주될 수 있다. 만일 조건(88)으로부터의 천이(90)에서 "Yes" 플래그가 존재한다면, 전술한 바와 같이 메인 상태(72)가 달성된다. 그러나, 만일 조건(88)으로부터의 천이(92)에서 "No" 플래그가 존재한다면, 단축된 메인 메뉴 상태(94)에 들어간다. 사용자에게 음성 메일을 위해 "1"을 또는 캘린더를 위해 "3"을 입력하도록 프롬프트되고, 그것들은 각각 96에서 "1"에 대하여 음성 메일 서브시스템 상태(80)로의 천이로 및 98에서 "3"에 대하여 캘린더 서브시스템 상태(84)로의 천이로 귀결된다. 만일 100에서 "2"에 대한 천이에 있다면, "오류! 옵션 이용 불가(error! Option not available)"에 대한 상태(102)에 들어간다. 그에 의해, 조건(88)은 더 성가시고 오류를 범하기 쉬운 메뉴 구조를 피한다.

UM 메뉴(86)를 인코딩하는 것은 샘플 4에서와 같이 달성될 수 있다:

이 예를 연장하여, 관리자가 또한 캘린더 액세스를 조건부로 불가능하게 하기로 결정하는 경우에 일어나는 것을 생각해보자. 통상적으로, MainMenuAllOptions, MainMenuNoEmail, MainMenuNoCalendar, 및 MainMenuNoEmailNoCalendar와 같은, 4개의 메뉴가 요구될 것이다.

대조적으로, 조건의 사용은 샘플 5에서와 같이, 프롬프트들 및 천이들이 조건부로 적용되게 하는 XML 정의에 대한 연장을 제공함으로써 더 세련된 접근법을 생성한다.

변수 이름 "IsEmailEnabled"는 글로벌 매니저 컨텍스트에서 존속하는 부울(참/거짓)이다. 실행 시간에, XML 상태 기계 엔진은 XML을 보고 실행 시간 값 그들의 조건 속성들에 기초하여 어느 엘리먼트들이 "활성"인지 아닌지를 결정할 것이다.

조건 속성 언어는 상당히 로버스트(robust)하여, 컨텍스트 변수들을 조합하기 위해, 논리 연산자들 AND, OR, NOT, GT(greater than), LT(less than), 및 어떤 다른 것들을 지원한다. 예를 들면, 프롬프트는 condition="IsEmailEnabled AND IsVoicemailEnabled"와 같은 것으로 태그가 붙을 수 있다. 그 표현식은 간단한 시프트-감소 구문 분석기(shift-reduce parser)를 이용하여 구문 분석 트리로 구분 분석되고 실행 시간에 평가될 것이다.

조건 속성은 프롬프트들 및 천이들에 적용될 뿐만 아니라, 문법 노드에도 적용된다. 따라서, 당신은 음성 메뉴의 반복 중에 어떤 명령 문법들을 조건부로 활성이 되게 할 수 있다. 자동 음성 인식(ASR)의 일반적인 개념은 공동으로 소유되고 동시 계류중인 미국 특허 출원 번호 11/238,521(공개 번호 2007/0073544 A1)에 설명되어 있고, 그 명세서는 온전히 그대로 본원에 참고로 통합된다. 따라서 도 1의 110에 도시된 ASR의 이용은 조건들에 의해 보다 용이하게 구성될 뿐만 아니라 음성 메뉴의 각 적절한 부분에 이 미니-상태 기계를 쉽게 가져오는 능력에 의해 강화된다.

ASR(110)과의 상호작용의 예인, 도 6에서, 메인 상태(112)에 들어가면, 사용자로부터 어떤 음성 응답이 기대된다. ASR(110)의 이 부분은 의미 있는 응답을 얻을 수 없는 때를 도시한다. 침묵(Silence)1 상태(114)에서는, 프롬프트가 사용자가 침묵인지를 플레이한다(예를 들면, "Sorry, I didn't hear you."). 만일 침묵2 상태(116)가 다음에 일어나면, 프롬프트가 사용자가 연속적으로 두 번 침묵인지를 행에 플레이한다(예를 들면, "sorry, I still didn't hear you."). 만일 사용자가 침묵1 상태(114) 후에 중얼거렸다면, 중얼거림(Mumble)1 상태(118)에서, 프롬프트가 플레이한다(예를 들면, "sorry, I didn't catch that."). 만일 사용자가 침묵이 아니라 메인 상태(112) 후에 중얼거렸다면, 다른 중얼거림1 상태(120)가 개시된다. 만일 이것 다음에 침묵이 뒤따르면, 침묵1 상태(122)가 호출된다. 만일 대신에 다른 중얼거림이 뒤따르면, 중얼거림2 상태(124)가 프롬프트로 하여금 사용자가 연속적으로 두 번 침묵인지를 행에 플레이하게 한다(예를 들면, "sorry, I still didn't understand you. Here's what you can say..."). 그 후 도움말(help) 상태(126)가 이 메뉴에 대한 도움말 프롬프트들을 제공한다. 대안적으로, 사용자로부터의 응답이 이해될 수 있지만 이 메뉴에 대하여 부적절하여, 무효명령(InvalidCommand) 상태(128)가 프롬프트를 제공하게 한다(예를 들면, "we understand what the user said, but what they said isn't a valid option at the moment", "sorry, I can't cancel this meeting because you're not the organizer", 사용자가 마지막으로 말한 것을 반복함). 너무 많은 시도가 실패한 후에는(예를 들면, 어떤 일련의 3번의 침묵 또는 중얼거림), 음성오류(SpeechError) 상태(130)가 사용자에게 이 실패를 알리고 복구 액션을 취한다(예를 들면, "sorry I couldn't help you. Returning to the main menu").

도 7에서, 만일 중얼거림 또는 침묵이 아니라 사용자로부터 의미 있는 응답이 얻어졌다면, 가져오기 및 조건들에 의해 강화되는 다른 양태는 사용자의 음성이 어떻게 상태 기계 층에 전달되고 메뉴 레벨에서 소비되는가이다. 예를 들면, "yes"를 말하는 많은 방법들이 있다. 당신은 "yeah, yep, yup, yessir, OK, sure" 등을 말할 수 있고, 이들은 모두 의미론적으로 "yes"와 동등하고, 132, 134, 136에 도시되어 있다. "SML" 의미 표시 언어(semantic markup language)를 채용함으로써, 문법 엔진(138) 내의 명령 문법들은, 대화(Dialog) A(142)로 RecoYes에 응답하고 대화 B(144)로 RecoNo에 응답하는 Yes/No 메뉴(140)로서 도시된 상태 기계에 전달되는 "의미 이벤트(semantic event)"에 대한 값을 정의한다. 이 메뉴는 사용자가 실제로 무엇을 말했는지를 결코 알지조차 못한다.

도 1로 되돌아가서, 가져오기 및 조건 특징들의 도움으로, ASR(110), XML 코드(146), 미디어 파일들(148), 클래스 정의들(150) 및 리소스 파일들(152)을 포함하는 UM FSM(20)이 생성된다. XML에 의한 코딩은 다수의 이점들을 갖지만, 종종 변수들 또는 참조되는 파일들이 누락되는 경우가 생길 수 있다. 그러한 누락들은 UM 애플리케이션(14)을 처리(fielding)하는 과정 중에 상당히 늦게 검출될 것이다. 따라서, 액션/변수 래핑 도구(action/variable wrapping tool)(156)는 작성 시간 컴파일러(build time compiler)(158)로서 도시된 C# 컴파일 단계(compilation phase)의 일부이다. 래핑 도구(156)는 상태 기계 XML 파일들을 소비하고, 그들의 관련된 관리자들에 대하여 현존하는 C# (코드) 정의들(161)에서 정의되는 메서드들 및 함수들을 참조하는, UM 작성 시간 바이너리(UM build time binary)(160)로서 도시된 래퍼들(wrappers)을 생성한다. 예를 들면, 문자열(string)을 반환하는 NextMessage라 불리는 메서드를 갖는 EmailManager라 불리는 클래스가 주어지면, 이 메서드에 대한 예시적인 래퍼는 샘플 6에서 다음과 같을 수 있다:

라인 1의 "string NextMessage" 및 라인 3의 "NextMessage"의 부분들은 XML 정의 파일들에서 선언되고 상기 래퍼를 생성하기 위해 이용되기 때문에, 상기 래퍼의 라인 3은 통상의 컴파일 단계 동안에 클래스 EmailManager가 실제로 NextMessage라 불리는 메서드를 갖는 것을 보증한다. 또한, 상기 래퍼의 라인 3은 메서드 NextMessage는 문자열을 반환하는 것을 보증한다. 만일 양쪽 체크들이 만족되지 않으면, 상기 래퍼는 컴파일 오류가 발생하게 한다.

따라서, 래핑 도구(156)의 이용은 XML 정의 파일들이 또한 컴파일되는 코드(161)에 실제로 존재하지 않는 메서드 또는 변수를 참조할 수 없다는 것과, 그 메서드들 및 변수들이 정확한 타입(예를 들면, 부울)을 갖는다는 것을 보증한다. 만일 XML 정의 파일이 존재하지 않는 메서드 또는 변수를 참조한다면, 래핑 도구(156)는 이들 래퍼들을 생성하고 그 후, "컴파일" 단계에서, 작성 중단(build break)을 생성한다. 일단 성공적으로 컴파일되면, UM 정의 파일들(162)과 함께 프로그래밍 환경(10)으로부터 내보내기(export) 위한 작성 시간 UM 바이너리(160)가 생성된다.

예를 들면, 만일 EmailManager 클래스가 NextMessage라 불리는 메서드를 포함하고 XML 정의가 그것을 NextMessageItem이라 불리는 것으로 식별하고, 도구가 코드 래퍼들을 적절히 생성한다면, C# 컴파일 단계는 작성 중단을 생성할 것이다. 그 후, "ERROR: class EmailManager does not contain a definition for NextMessageItem"과 같은 컴파일 시간 오류가 생성될 것이다. 그러한 구현의 예는 샘플 7로서 제공된다:

확인의 제2 부분은 UM 애플리케이션(14)이 설치되고 UM 실행 기계(16) 상에서 실행중일 때 일어난다. UM 애플리케이션(14)이 시동할 때, 그것은 XML 구성 파일(162)을 판독한다. UM 애플리케이션(14)이, EmailManager 클래스 상의 어떤 메서드를 호출하는, 예를 들면 EmailManager 내의, XML 정의를 가로지를 때, MICROSOFT.Net 플랫폼에 의해 제공되는 .NET 리플렉션(reflection)(164)이 UM 바이너리(160)에서 생성된 래퍼를 찾는다. 다른 무엇보다도 특히, .NET 리플렉션(164)은 C#로 작성된 프로그램이 C#로 작성된 다른 프로그램의 프로그램 구조를 검사하도록 허용한다. 예를 들면, 프로그램은 다른 프로그램의 바이너리 콘텐트를 철저히 조사하여 모든 그것의 함수들 및 그들의 이름들을 열거할 수 있다. 만일 그 래퍼가 존재하지 않는다면, XML 파일은 래퍼들을 생성하기 위해 작성 시간에 이용된 것이 아니었고 버전 불일치 오류가 제공된다. 그렇지 않다면, 166에 도시된, 유효 XML 및 바이너리가 실행하도록 허용된다.

.NET 리플렉션의 이용은 래핑 및 컴파일 단계들 동안에 래핑 도구(156)에 의해 가능하게 되는 확인들을 보완한다. 양쪽 모두의 경우에, 샘플 6의 래퍼 코드의 예를 들면, EmailManager라 불리는 클래스가 NextMessage라 불리는 메서드를 갖는다는 것을 결정하기 위해 FSM 정의들이 검사된다. 작성 기간에 행해지는 래핑 단계에서, 이 확인 코드가 생성된다. 실행 시간에 행해지는 리플렉션 단계에서, .NET 리플렉션(164)은 래퍼 함수가 실제로 UM 바이너리(160)에 존재한다는 것을 보증한다. 따라서 부정확하거나 손상된 버전을 이용하려는 시도들을 피할 수 있다.

도 8에서는, 구성 가능한 메시징 시스템(200)이 프로그래밍 환경(10)에 의해 생성될 수 있다. 시스템(200)은 다양한 통신 애플리케이션들의 처리를 용이하게 하기 위해 하나 이상의 사용자들 및/또는 자동화 애플리케이션들(220)과 상호작용하는 메시징 컴포넌트(210)를 포함한다. 메시징 컴포넌트(210)는 통합 메시징 애플리케이션들, 음성 메일 처리, 또는 실질적으로 임의의 유형의 음성 인식 애플리케이션과 같은 다양한 애플리케이션들과 관련될 수 있다. 전형적으로, 메시징 컴포넌트(210)와의 상호작용들은 DTMF(dual tone multi frequency) 입력들을 통하여 행해지지만 음성 또는 텍스트 입력들과 같은 다른 유형의 입력들도 작용할 수 있다.

일반적으로, 구성 파일(230)은 사용자 또는 애플리케이션들(220)과의 인터페이스 대화 세션(240)을 구동하는 명령어들 또는 명령들의 그룹들을 저장한다. 그러한 명령어들 또는 명령들은 대화 세션(240)으로 하여금, 사용자 또는 애플리케이션들(220)과의 상호작용들을 집합적으로 제어하는, 예를 들면 메뉴의 하나 이상의 항목들을 생성하고 처리하게 할 수 있다. 예를 들면, 제1 항목은 세션을 식별하는 인사말(greeting)에 관련될 수 있고, 제2 항목은 암호 입력을 요청할 수 있고, 제3 항목은 음성 메일 메시지가 메시징 컴포넌트(210)와 관련된 파일에 기록될 것을 요청할 수 있다. 아래에 더 상세히 설명되는 바와 같이, 구성 파일은, 대화 세션(240)을 제어하고 결국 메시징 컴포넌트가 사용자들 또는 애플리케이션들(220)과 어떻게 상호작용하는지를 제어하는, 활동들, 프롬프트들, 또는 천이들을 특정할 수 있다.

구성 파일(230)은 일반적으로 대화 세션(240)에서 어떤 활동들이 달성될 것인지 및, 예를 들면, 주어진 활동이 완료되거나 중지된 후에 어느 상태로 천이할지를 특정한다. 상태들은 메시지 처리 컴포넌트(260)(또는 서비스와 같은 컴포넌트들)에게 시스템(200)에서 어떤 활동을 수행하도록(예를 들면, 음성 메일을 기록하고, 메시지를 재생하고, 사용자 입력을 검사하는 등) 지시하는 상태 컨트롤러(250)에 의해 관리된다. 구성 파일(230)은 관리자들이 복수의 다양한 통신 애플리케이션들에 대하여 메시징 컴포넌트(210)의 기능을 동적으로 적응시킬 수 있게 한다. 이것은 메시징 컴포넌트(210)의 상태를 제어하기 위해 협력하는 XML(Extensible Markup Language) 또는 다른 유형의 언어로 대화 상호작용들 또는 명령들을 특정하는 것에 의해 달성된다. 이 경우, 구성 파일(230) 내의 명령어들은 상태 컨트롤러(250)로부터 하드 코딩된 상태 구현들을 제거하고 관리자들이 변경들을 행한 후에 상태 컨트롤러를 또한 수정할 필요 없이 변화하는 상황들에 적응할 수 있게 한다.

다른 상태들로의 천이들이 구성 파일(230) 내에 포함되기 때문에, 대화 제어는 시스템(200)의 적절한 상태들 또는 액션들을 결정하기 위한 다른 컴퓨터들/컴포넌트들과의 상호작용들을 경감하면서 주어진 대화 세션(240)에 대하여 입상의 레벨로(on a granular level) 동적으로 특정될 수 있다(예를 들면, 외부 문서로가 아니라 파일 내의 그룹으로서 천이들을 특정한다). 따라서, 본 발명은 대화 세션(240)에 대한 메뉴들 및 그의 천이들을 상태 컨트롤러(250)에 하드 코딩하는 것이 아니라 이들 양태들을 XML 파일(또는 다른 유형)로 구성하는 것을 용이하게 한다. 이 특징은, 메시징 컴포넌트(210)에 대한 변경 없이 새로운 메뉴들 및 천이들이 추가될 수 있는, 확장성을 용이하게 한다. 또한, 구성 파일(230)은 애플리케이션 개발 시간을 감소시키고 사용자 지정(customization)을 허용하고 그에 따라 관리자 및 최종 사용자가 잠재적으로 새로운 메뉴들을 추가하고 현존하는 메뉴 천이들을 그들의 필요에 맞도록 변경할 수 있다. 다른 양태들은 메시징 시스템(200)의 기초를 이루는 애플리케이션 구현은 변하지 않은 채로 있을 수 있으면서 단지 구성 파일(230)(또는 파일들)을 수정하는 것에 의해, 다른 언어들(예를 들면, 독어, 불어, 영어, 등)로 프롬프트들, 메뉴들 및 천이들을 추가하는 언어 지원을 포함한다. 예시적인 구성 파일의 추가적인 양태들은 공동으로 소유되고 동시 계류중인 미국 특허 출원 번호 11/068,691(공개 번호 2007/0055751 A1)에 설명되어 있고, 그 명세서는 온전히 그대로 본원에 참고로 통합된다.

이제 도 9를 참조하면, 본 발명의 양태에 따른 예시적인 구성 파일(270)이 예시되어 있다. 일반적으로, 구성 파일(270)은 280에 예시된 하나 이상의 대화 명령 그룹들(예를 들면, 그룹 101, 102, 103, 등)에 배열되는 활동(activity) 엘리먼트들, 프롬프트(prompt) 엘리먼트들, 및 천이(transition) 엘리먼트들을 포함하고, 그러한 그룹들은 통신 또는 메시징 시스템과 상호작용하기 위한 사용자 인터페이스 또는 메뉴의 동작들을 특정한다. 예를 들면, 통합 메시징 예에 대한 TUI(telephony user interface)가 XML 구성 파일로 기술된다. "id" 속성을 갖는 엘리먼트들은 활동을 기술한다. 예를 들면, 메뉴(Menu), 기록(Record) 등은 활동들의 예이다. 프롬프트 엘리먼트들은 최종 사용자에게 플레이될 프롬프트들인 반면, 천이 엘리먼트들은 수행될 다음 활동 및 천이 전에 취해질 액션을 기술한다.

일반적으로, 대화 애플리케이션의 하나의 가능한 구현은 구성 파일(270) 내의 활동에 각 상태가 매핑되는 상태 기계를 포함한다. 상태 천이들은, 예를 들면, XML의 천이 엘리먼트에 매핑될 수 있다. 액션 속성들은 상태 천이 바로 전에 수행될 액션들을 나타낸다. 또한, 서브-상태 기계 천이들도 이 모델에서 지원된다. 예를 들면, 음성 메일 기록(Record Voicemail)은 메뉴 및 기록을 포함하는 다수의 서브-활동들을 갖는 부모 활동일 수 있다. 예를 들면, 통합 메시징 애플리케이션은 최종 사용자로부터 호출(call)을 수신하고, (메모리에 사전 로딩된) 그 호출에 관한 XML 구성이 채용될 수 있고 전체 활동 상태 기계가 그 호출을 위하여 실행된다. 구성을 로딩하는 이 호출마다의 입도(per-call granularity)는 관리자들 및 최종 사용자들이 확장하고, 사용자 지정하고 다른 언어들을 지원하는 데에 엄청난 융통성을 제공한다.

도 10을 참조하면, 본 발명의 양태에 따른 예시적인 통합 메시징 시스템(300)이 예시되어 있다. 이 예에서, 시스템(300)은 통합 메시징 시스템(300)이 PBX(310) 및 SIP(Session Initiation Protocol) 게이트웨이(320)의 상황에서 어떻게 협력하는지를 도시한다. 게이트웨이(320)는 호출들(330)(유선 또는 무선)을 SIP 프로토콜을 이용하여 IP 네트워크(340)를 통하여 통합 메시징 시스템(300)에 라우팅할 수 있다. 이것은 통합 메시징 시스템(300)이 PBX(310)와 한 곳에 배치되지 않도록 허용한다. 다른 컴포넌트들은 메시지들을 저장하기 위한 사서함 서버(mailbox server)(350) 및 메시지들을 관리하기 위한 액티브 디렉터리(360)를 포함할 수 있다. 예시된 바와 같이, 통합 메시징 시스템(300)은 착신되는 호출들(330)을 처리하기 위한 TTS(Text-to-Speech) 및 음성 인식 엔진(370)과 같은 컴포넌트들을 포함할 수 있지만, DTMF 컨트롤과 같은 다른 유형의 컴포넌트들이 제공될 수도 있다. 본 명세서의 도움으로 호출들(330)을 생성하는 사용자들(또는 애플리케이션들)과 상호작용하기 위한 인터페이스 세션을 생성하는 구성 파일을 로딩하고 실행하는 통합 메시징 서비스 또는 서비스(도시되지 않음)가 제공될 수 있다는 것을 이해해야 한다. 이것은 시스템(300)의 상태 동작들을 관리하는 다양한 개체들 및 클래스들의 동작을 포함할 수 있다.

도 11에서, 도 1의 프로그래밍 환경(10)은 유리하게도 공동으로 소유되고 동시 계류중인 미국 특허 출원 번호 11/238,521(공개 번호 2007/0073544 A1)에서 설명된 바와 같이 메시지 프롬프트들의 지역화(localization)를 지원하고 강화한다. 상기 미국 특허 출원의 명세서는 온전히 그대로 본원에 참고로 통합된다. 시스템(400)은 컴퓨터(402), 컴퓨터 실행가능한 코드(404), 클래스 정의 테이블(406), 리소스 파일들(408), 및 지역화된 미디어 파일들(410)을 갖는다. 컴퓨터(402)는 프롬프트들을 렌더링하는(예를 들면, 구두의(spoken) 프롬프트들을 나타내는 오디오 파일들을 플레이하는) 방법을 특정하는 코드(404)를 실행한다. 시스템(400)은 유리하게도 코드(404)에 어떤 변경도 주지 않고 리소스 문자열들 및 미디어 파일들이 따로따로 개별적으로 지역화된 언어로 변경되거나 번역될 수 있게 한다. 이 현저한 이점은 다수의 상이한 지역화된 언어들에서 사용하기 위해 프로그래머들에 의해 코드(404)가 일단 작성되게 한다. 일단 코드(404)가 생성되고 리소스 문자열들이 특정한 언어(예를 들면, 영어)로 생성되면, 번역자들은 리소스 문자열들을 검토하고 리소스 문자열들의 지역화된 번역들(예를 들면, 불어)을 제공할 수 있다. 그 후 번역들은 불어에 대한 지역화된 리소스 파일들에 저장된다. 마찬가지로, 번역자들은 리소스 문자열들 및 리소스 문자열 단편들의 구두의 미디어 클립들을 지역화된 언어(예를 들면, 불어)로 녹음하고 그 녹음들을 지역화된 미디어 파일들로서 저장할 수 있고 그 지역화된 미디어 파일들은 코드(404)에 의해 호출된 지역화된 미디어 클립들을 플레이할 때 컴퓨터(402)에 의해 액세스된다.

예를 들면, 코드(404)는 KEY 변수에 할당된 값에 기초하여 VariableName에 할당된 이름(예를 들면, "Messages")을 생성하는 것을 특정한다. 컴퓨터(402)는 KEY 변수의 값에 대응하는 문법 변수(예를 들면, "_Plural")를 식별하기 위해 클래스 정의 테이블(406)에 액세스한다. 코드(404)는 새로운 이름(예를 들면, "Messages_Plural")을 생성하고, 그 새로운 이름을 VariableName에 할당하고, 컴퓨터(402)에게 그 VariableName(즉, "Messages_Plural")에 대응하는 미디어 파일들을 식별하도록 지시한다. 컴퓨터(402)는 리소스 파일들(408)에 액세스하고 VariableName에 대응하는 리소스 문자열을 찾아낸다. 컴퓨터(402)는 그 리소스 문자열을 분석하고 리소스 문자열에 대응하는 미디어 파일(들) 및 리소스 문자열 내의 미디어 파일(들)의 순서를 결정한다. 컴퓨터(402)는 지역화된 미디어 파일들(410)로부터 리소스 문자열에 대응하는 미디어 파일(들)에 액세스한다. 코드(404)는 그 후 컴퓨터(402)에게 그 지역화된 미디어 파일들을 리소스 문자열에서 식별되는 문법적으로 정확한 순서로 렌더링하도록 지시한다.

하나의 버전에서, 클래스 정의 테이블(406)은 접두사(prefix), 접미사(suffix), 또는 그의 조합일 수 있는 문법적 변수(grammatical variable)를 포함한다. 그 문법적 변수는 그 후 KEY의 수치 값과 관련된 문법적으로 정확한 리소스 문자열 리소스 파일에 대응하도록 VariableName에 할당된 이름에 추가된다. 예를 들면, KEY의 값이 "1"이면, 관련된 리소스 문자열은 단수(singular) 값에 대하여 문법적으로 정확한 문자열일 것이다(예를 들면, "You have 4 new message"). 만일 KEY의 값이 "5"이면, 관련된 리소스 문자열은 복수 값에 대하여 문법적으로 정확한 문자열일 것이다(예를 들면, "You have 5 new messages"). 대안적으로, KEY의 값이 "0"이면, 관련된 리소스 문자열은 제로 또는 널(null) 값에 대하여 문법적으로 정확한 문자열일 것이다(예를 들면, "You have no new messages").

다른 버전에서, 리소스 파일들(408)에 있는 리소스 문자열들은 코드(404)와 별개이고 코드(404)가 수정되거나 다시 컴파일될 필요 없이 지역 언어 번역자들에 의해 영어가 아닌 언어로 번역될 수 있다. 번역 중에, 리소스 문자열 및 수치 변수들은 지역 언어로 번역될 수 있고 리소스 문자열 및 수치 값들은 번역된 언어에 대하여 문법적으로 정확한 순서로 재배열될 수 있다. 예를 들면, 영어 리소스 문자열, "You have" {0} "new messages"에 대한 문법적으로 정확한 순서 및 시제(tense)는 2개의 텍스트 단편들 "You have" 및 "new messages"를 포함하고 이 예에서 "{0}"은 복수의 수치 값이다. 그러나, 만일 리소스가 불어로 번역된다면, 하나의 문법적으로 정확한 순서 및 시제는, {0} "nouveau messages sont arrives"일 수 있고, 여기서 수치 변수는 2개 이상의 메시지들이 수신된 것을 말하고 있는 문장의 처음에 위치한다.

또 다른 버전에서, 미디어 파일들은 리소스 문자열들 및 그 리소스 문자열들에 대응하는 리소스 문자열 단편들의 지역화된 기록들(recordings)을 포함한다. 미디어 파일들은 또한 코드(404)가 수정되거나 다시 컴파일될 필요 없이 코드(404)에 의해 기록되고 이용될 수 있다.

따라서, 전술한 명세서의 도움으로 양태들은 그에 따라 DTMF만의 UM 애플리케이션들, ASR만의 UM 애플리케이션들, 또는 하이브리드 DTMF/ASR UM 애플리케이션들을 포함할 수 있다는 것을 이해해야 한다.

도 12를 참조하면, 본 발명의 다양한 양태들을 구현하기 위한 예시적인 환경(910)은 컴퓨터(912)를 포함한다. 컴퓨터(912)는 처리 장치(914), 시스템 메모리(916), 및 시스템 버스(918)를 포함한다. 시스템 버스(918)는 시스템 메모리(916)를 포함하지만 이에 제한되지 않는 컴포넌트들을 처리 장치(914)에 연결한다. 처리 장치(914)는 다양한 이용 가능한 프로세서들 중 어떤 것이라도 될 수 있다. 듀얼 마이크로프로세서 및 기타 멀티프로세서 아키텍처도 처리 장치(914)로서 채용될 수 있다.

시스템 버스(918)는 메모리 버스 또는 메모리 컨트롤러, 주변 버스 또는 외부 버스, 및/또는 임의의 각종의 이용 가능한 버스 아키텍처를 이용하는 로컬 버스를 포함하는 몇몇 유형의 버스 구조 중 어느 것이라도 될 수 있으며, 이용 가능한 아키텍처는 11-비트 버스, ISA(Industry Standard Architecture), MCA(Micro-Channel Architecture), EISA(Extended ISA), IDE(Intelligent Driven Electronics), VLB(VESA Local Bus), PCI(Peripheral Component Interconnect), USB(Universal Serial Bus), AGP(Advanced Graphics Port), PCMCIA(Personal Computer Memory Card International Association bus), 및 SCSI(Small Computer Systems Interface)를 포함하지만 이에 제한되는 것은 아니다.

시스템 메모리(916)는 휘발성 메모리(920) 및 비휘발성 메모리(922)를 포함한다. 시동 중과 같이 컴퓨터(912) 내의 엘리먼트들 사이에 정보를 전송하는 기본 루틴들을 포함하는 기본 입력/출력 시스템(BIOS)은 비휘발성 메모리(922)에 저장된다. 제한이 아니라 예로서, 비휘발성 메모리(922)는 ROM(read only memory), PROM(programmable ROM), EPROM(electrically programmable ROM), EEPROM(electrically erasable ROM), 또는 플래시 메모리를 포함할 수 있다. 휘발성 메모리(920)는 외부 캐시 메모리로서 역할을 하는 RAM(random access memory)를 포함한다. 제한이 아니라 예로서, RAM은 SRAM(synchronous RAM), DRAM(dynamic RAM), SDRAM(synchronous DRAM), DDR SDRAM(double data rate SDRAM), ESDRAM(enhanced SDRAM), SLDRAM(Synchlink DRAM), 및 DRRAM(direct Rambus RAM)와 같은 많은 형태로 이용 가능하다.

컴퓨터(912)는 또한 이동식/비이동식, 휘발성/비휘발성 컴퓨터 저장 매체를 포함한다. 도 12는 예를 들면 디스크 저장 장치(924)를 예시한다. 디스크 저장 장치(924)는 자기 디스크 드라이브, 플로피 디스크 드라이브, 테이프 드라이브, 재즈(Jaz) 드라이브, 집(Zip) 드라이브, LS-100 드라이브, 플래시 메모리 카드, 또는 메모리 스택과 같은 장치들을 포함하지만 이에 제한되는 것은 아니다. 또한, 디스크 저장 장치(924)는 CD-ROM(compact disk ROM device), CD-R 드라이브(CD recordable drive), CD-RW 드라이브(CD rewritable drive) 또는 DVD-ROM(digital versatile disk ROM drive)과 같은 광학 디스크 드라이브를 포함하지만 이에 제한되지 않는 다른 저장 매체와 별도로 또는 다른 저장 매체와 함께 저장 매체를 포함할 수 있다. 디스크 저장 장치들(924)을 시스템(918)에 접속하는 것을 용이하게 하기 위해, 전형적으로 인터페이스(926)와 같은 이동식 또는 비이동식 인터페이스가 이용된다.

도 12는 사용자들과 적합한 운영 환경(910)에서 기술되는 기본 컴퓨터 리소스들 사이에 매개물로서 역할을 하는 소프트웨어를 기술한다는 것을 이해해야 한다. 그러한 소프트웨어는 운영 체제(928)를 포함한다. 디스크 저장 장치(924)에 저장될 수 있는 운영 체제(928)는 컴퓨터 시스템(912)의 리소스들을 제어하고 할당하는 역할을 한다. 시스템 애플리케이션들(930)은 시스템 메모리(916)에 또는 디스크 저장 장치(924)에 저장된 프로그램 모듈들(932) 및 프로그램 데이터(934)를 통하여 운영 체제(928)에 의한 리소스들의 관리를 이용한다. 본 발명은 다양한 운영 체제들 또는 운영 체제들의 조합들로 구현될 수 있다는 것을 이해해야 한다.

사용자는 입력 장치(들)(936)를 통하여 컴퓨터(912)에 명령 또는 정보를 입력한다. 입력 장치들(936)은, 마우스, 트랙볼, 스타일러스, 터치 패드와 같은 포인팅 장치, 키보드, 마이크, 조이스틱, 게임 패드, 위성 안테나, 스캐너, TV 튜너 카드, 디지털 카메라, 디지털 비디오 카메라, 웹 카메라 등을 포함하지만 이에 제한되는 것은 아니다. 이들 및 기타 입력 장치는 인터페이스 포트(들)(938)를 통해 시스템 버스(918)를 통하여 처리 장치(914)에 접속된다. 인터페이스 포트(들)(938)는, 예를 들면, 직렬 포트, 병렬 포트, 게임 포트, 및 USB(universal serial bus)를 포함한다. 다른 장치(들)(940)는 입력 장치(들)(936)와 동일한 유형의 포트들 중 일부를 이용한다. 따라서, 예를 들면, USB 포트가 컴퓨터(912)에 입력을 제공하고, 컴퓨터(912)로부터 출력 장치(940)로 정보를 출력하기 위해 이용될 수 있다. 출력 어댑터(942)는, 출력 장치들(940) 중에서도, 특수한 어댑터들을 필요로 하는, 모니터, 스피커, 및 프린터와 같은 어떤 출력 장치들(940)이 있다는 것을 예시하기 위해 제공된다. 출력 어댑터들(942)은, 제한이 아니라 예로서, 출력 장치(940)와 시스템 버스(918) 사이의 접속 수단을 제공하는 비디오 및 사운드 카드들을 포함한다. 원격 컴퓨터(들)(944)와 같은 다른 장치들 및/또는 장치들의 시스템들이 입력 및 출력 양쪽 모두의 능력들을 제공한다는 것에 유의해야 한다.

컴퓨터(912)는 원격 컴퓨터(들)(944)와 같은 하나 이상의 원격 컴퓨터로의 논리적 접속을 이용하여 네트워크화된 환경에서 동작할 수 있다. 원격 컴퓨터(들)(944)는 퍼스널 컴퓨터, 서버, 라우터, 네트워크 PC, 워크스테이션, 마이크로프로세서 기반 가전, 피어 장치 또는 다른 공통 네트워크 노드 등일 수 있고, 전형적으로 컴퓨터(912)와 관련하여 설명된 엘리먼트들의 다수 또는 그 전부를 포함한다. 간결함을 위하여, 원격 컴퓨터(들)(944)와 함께 메모리 저장 장치(946)만 예시되어 있다. 원격 컴퓨터(들)(944)는 네트워크 인터페이스(948)를 통하여 컴퓨터(912)에 논리적으로 접속되고 그 후 통신 접속(950)을 통해 물리적으로 접속된다. 네트워크 인터페이스(948)는 LAN(local-area networks) 및 WAN(wide-area networks)과 같은 통신 네트워크들을 포함한다. LAN 기술들은 FDDI(Fiber Distributed Data Interface), CDDI(Copper Distributed Data Interface), 이더넷/IEEE 802.3, 토큰 링(Token Ring)/IEEE 802.5 등을 포함한다. WAN 기술들은, 포인트-투-포인트 링크(point-to-point links), ISDN(Integrated Services Digital Networks)와 같은 회선 교환 네트워크(circuit switching networks) 및 그의 변형들, 패킷 교환 네트워크, 및 DSL(Digital Subscriber Lines)을 포함하지만 이에 제한되는 것은 아니다.

통신 접속(들)(950)은 네트워크 인터페이스(948)를 버스(918)에 접속하기 위해 이용되는 하드웨어/소프트웨어를 나타낸다. 통신 접속(950)은 설명의 명료함을 위하여 컴퓨터(912) 내에 도시되어 있지만, 그것은 컴퓨터(912)의 외부에 있을 수도 있다. 네트워크 인터페이스(948)에의 접속을 위해 필요한 하드웨어/소프트웨어는, 단지 예시를 위하여, 통상의 전화 등급 모뎀, 케이블 모뎀 및 DSL 모뎀을 포함하는 모뎀들, ISDN 어댑터들, 및 이더넷 카드들과 같은 내부 및 외부 기술들을 포함한다.

도 13은 본 발명과 상호작용할 수 있는 샘플-컴퓨팅 환경(1000)의 개략 블록도이다. 시스템(1000)은 하나 이상의 클라이언트(들)(1010)를 포함한다. 클라이언트(들)(1010)는 하드웨어 및/또는 소프트웨어(예를 들면, 스레드, 프로세스, 컴퓨팅 장치)일 수 있다. 시스템(1000)은 또한 하나 이상의 서버(들)(1030)를 포함한다. 서버(들)(1030)도 하드웨어 및/또는 소프트웨어(예를 들면, 스레드, 프로세스, 컴퓨팅 장치)일 수 있다. 서버들(1030)은, 예를 들면, 본 발명을 이용함으로써 변환들을 수행하는 스레드들을 수용할 수 있다. 클라이언트(1010)와 서버(1030) 사이의 하나의 가능한 통신은 2개 이상의 컴퓨터 프로세서들 사이에 송신되도록 적응된 데이터 패킷들의 형태를 가질 수 있다. 시스템(1000)은 클라이언트(들)(1010)와 서버(들)(1030) 사이의 통신을 용이하게 하기 위해 이용될 수 있는 통신 프레임워크(1050)를 포함한다. 클라이언트(들)(1010)는 클라이언트(들)(1010)에 로컬인 정보를 저장하기 위해 이용될 수 있는 하나 이상의 클라이언트 데이터 스토어(들)(1060)에 동작 가능하게 접속된다. 유사하게, 서버(들)(1030)는 서버들(1030)에 로컬인 정보를 저장하기 위해 이용될 수 있는 하나 이상의 서버 데이터 스토어(들)(1060)에 동작 가능하게 접속된다.

위에 설명된 것은 본 발명의 예들을 포함한다. 물론, 본 발명을 설명하기 위해 생각할 수 있는 컴포넌트들 또는 방법들의 모든 조합을 다 설명하는 것은 불가능하지만, 통상의 기술을 가진 당업자라면 본 발명의 다수의 추가적인 조합들 및 치환들이 가능하다는 것을 알 수 있다. 따라서, 본 발명은 첨부된 청구항들의 정신 및 범위 내에 있는 모든 그러한 변경들, 수정들 및 변형들을 망라하도록 되어 있다. 또한, 용어 "includes"가 상세한 설명 또는 청구항에서 사용되는 한은, 그러한 용어는 용어 "comprising"가 청구항에서 전환 단어(transitional word)로서 이용될 때 해석되는 것과 유사한 방식으로 포괄적(inclusive)이도록 되어 있다.

여기에 참고로 통합된다고 하는 임의의 특허, 공개, 또는 다른 개시 자료는, 전부 또는 일부에서, 그 통합된 자료가 현존하는 정의들, 진술들, 또는 여기에 제시된 다른 개시 자료와 모순되지 않는 정도까지만 통합된다는 것을 이해해야 한다. 그러므로, 필요한 정도까지, 여기에 명시적으로 설명된 개시 내용은 여기에 참고로 통합된 임의의 모순되는 자료를 대체한다. 여기에 참고로 통합된다고 하는, 그러나 현존하는 정의들, 진술들, 또는 여기에 제시된 다른 개시 자료와 모순되는 임의의 자료, 또는 그의 일부분은 통합된 자료와 현존하는 개시 자료 사이에 모순이 일어나지 않는 정도까지만 통합될 것이다.

Claims

UM(unified messaging) 애플리케이션을 프로그래밍하기 위한 컴퓨터 구현 시스템으로서,
사용자 인터페이스;
상기 사용자 인터페이스를 통해 액세스되고 적어도 하나의 컴퓨팅 장치상에서 동작하는 프로그래밍 환경 - 상기 프로그래밍 환경은, 복수의 사용자 프롬프트들(prompts) 및 사용자 프롬프트들 사이의 천이들(transitions)에 의해 정의되는 메뉴 상태들을 포함하는 UM FSM(finite state machine)을 XML(eXtensible Markup Language)로 구성하며, 각 천이는 프롬프트에 대한 특정한 사용자 응답에 의해 정의됨 - ;
상기 UM FSM에 의해 호출되는 외부 소프트웨어 컴포넌트를 포함하는 UM 소프트웨어 컴포넌트;
상기 UM 소프트웨어 컴포넌트에 기초하여 유효 메뉴 상태를 생성하도록 상기 프로그래밍 환경에 의해 이용되는 XML 특징(feature) - 상기 XML 특징은 상기 프로그래밍 환경에 의해 이용되는 함수 래퍼(function wrapper)를 포함하며, 상기 함수 래퍼는 상기 외부 소프트웨어 컴포넌트가 존재하는 경우에는 컴파일 단계(compilation phase) 중에 상기 외부 소프트웨어 컴포넌트의 유효성을 검사(validate)하여 바이너리 UM FSM을 생성하며, 상기 외부 소프트웨어 컴포넌트가 존재하지 않는 경우에는 상기 컴파일 단계 중에 오류를 발생시킴 - ; 및
상기 바이너리 UM FSM의 실행 도중에 호출되는 확인 도구(verification tool) - 상기 확인 도구는 컴파일 단계 중에 존재하는 상기 외부 소프트웨어 컴포넌트의 버전이 실행시에 이용 가능한 상기 외부 소프트웨어 컴포넌트의 버전과 동일함을 확인함 -
를 포함하는
컴퓨터 구현 시스템.
제1항에 있어서,
상기 UM 소프트웨어 컴포넌트는 상기 UM 애플리케이션의 설정을 포함하고,
상기 XML 특징은 상기 UM FSM의 천이를 사전 결정하는 조건 속성(conditional attribute)을 포함하는
컴퓨터 구현 시스템.
제2항에 있어서,
상기 조건 속성은 컨텍스트 변수로 구성된 속성을 포함하는
컴퓨터 구현 시스템.
제3항에 있어서,
상기 조건 속성은 구문 분석 트리(parse tree)로 구문 분석하기 위한 적어도 하나의 논리 연산자에 의해 조합되는 복수의 컨텍스트 변수들로 구성되는 속성을 포함하는
컴퓨터 구현 시스템.
제2항에 있어서,
상기 UM 소프트웨어 컴포넌트는 문법 노드(grammar node)를 포함하고,
상기 XML 특징은 명령 문법(command grammar)을 선택적으로 활성이 되게 하는 조건 엘리먼트 속성을 포함하는
컴퓨터 구현 시스템.
제1항에 있어서,
상기 UM 소프트웨어 컴포넌트는 XML 스니핏(snippet)을 포함하고,
상기 XML 특징은 컴파일 시에 상기 XML 스니핏을 복제하도록 상기 프로그래밍 환경에 의해 이용되는 가져오기 엘리먼트(importation element)를 포함하는
컴퓨터 구현 시스템.
제6항에 있어서,
상기 XML 스니핏은 비반응 사용자 발성(nonresponsive user utterance)에 응답하여 프롬프트들 및 천이들을 정의하는 음성 메뉴(speech menu)를 포함하는
컴퓨터 구현 시스템.
제7항에 있어서,
상기 비반응 사용자 발성은 침묵(silence), 중얼거림(mumble), 및 현재의 컨텍스트에서 적용할 수 없는 단어(word)로 이루어지는 그룹으로부터 선택된 하나 이상의 응답들인
컴퓨터 구현 시스템.
제1항에 있어서,
상기 외부 소프트웨어 컴포넌트는 메서드(method), 함수, 변수 및 액션으로 이루어지는 그룹 중 하나인
컴퓨터 구현 시스템.
제1항에 있어서,
상기 사용자 프롬프트들과 의미론적으로 동등한 복수의 사용자 응답들 중 하나로 의미 이벤트(semantic event)를 정의하기 위한 자동화된 음성 인식 메뉴를 더 포함하고,
상기 천이들은 특정한 의미 이벤트에 좌우되는
컴퓨터 구현 시스템.
제1항에 있어서,
DTMF(dual tone multi frequency) 키패드 입력으로 의미 이벤트를 정의하는 DTMF 인터페이스를 더 포함하는
컴퓨터 구현 시스템.
UM(unified messaging) 시스템에 대한 사용자 인터페이스를 개발하는 방법으로서,
적어도 하나의 컴퓨팅 장치를 이용하여 FSM(finite state machine)을 생성하는 단계 - 상기 FSM은 사용자에게 프롬프팅하는 메뉴 상태들 및 사용자 응답에 따른 다음 메뉴 상태로의 천이들로 구성됨 - ; 및
XML(eXtensible Markup Language) 특징을 이용하여, 존재하는(existing) 외부 UM 소프트웨어 컴포넌트에 기초하여 유효 메뉴 상태를 생성하는 단계를 포함하되,
상기 유효 메뉴 상태를 생성하는 단계는,
상기 XML 특징에 대한 함수 래퍼를 생성하는 단계;
컴파일 단계(compilation phase) 중에, 상기 외부 UM 소프트웨어 컴포넌트가 존재하면 상기 함수 래퍼를 사용하여 상기 외부 UM 소프트웨어 컴포넌트의 유효성을 검사하고, UM FSM의 바이너리(binary)를 생성하는 단계;
상기 UM FSM의 바이너리의 실행 중에, 상기 컴파일 단계 중에 존재하는 상기 외부 소프트웨어 컴포넌트의 버전이 실행시에 이용 가능한 상기 외부 UM 소프트웨어 컴포넌트의 버전과 동일함을 확인하는 단계; 및
적어도 하나의 사용자 프롬프트를 포함하는 상기 사용자 인터페이스의 상기 유효 메뉴 상태를 생성하는 단계를 포함하는
사용자 인터페이스 개발 방법.
제12항에 있어서,
상기 유효 메뉴 상태를 생성하는 단계는 XML 가져오기 엘리먼트(importation element)에 의해 상기 FSM에서 복제되는 XML 스니핏에 기초하는
사용자 인터페이스 개발 방법.
제12항에 있어서,
상기 유효 메뉴 상태를 생성하는 단계는 프롬프트 또는 천이를 정의하는 XML 엘리먼트의 XML 조건 속성에 의해 참조되는 컨텍스트 변수에 기초하는
사용자 인터페이스 개발 방법.
제12항에 있어서,
상기 유효 메뉴 상태를 생성하는 단계는 외부 UM 소프트웨어 컴포넌트에서 참조하는 상기 FSM의 변수들 및 호출된 액션들(called actions)을 래핑하고 찾을 수 없는 경우에는 작성 시간 오류(build time error)를 발생시킴으로써 유효성이 검증되는
사용자 인터페이스 개발 방법.
제15항에 있어서,
상기 FSM의 컴파일된 버전에 의해 참조되는 외부 UM 소프트웨어 컴포넌트는 유효성이 검증된 경우와 실행시에 동일함을 검증하는 단계를 더 포함하는
사용자 인터페이스 개발 방법.