KR20200070082A - 가상 비서 도메인 선택 분석 - Google Patents

Abstract

가상 비서 플랫폼은, 앱 개발자가 가상 비서에 대한 도메인의 인에이블화를 구성하기 위한 유저 인터페이스를 제공한다. 테스트 질의의 세트가 업로드될 수 있고, 각각의 선택된 도메인에 의해 서빙되는 테스트 질의의 수 및 각각의 도메인의 사용량에 대한 비용에 대한 통계적 분석이 디스플레이될 수 있다. 비용은 복잡한 가격 책정 모델에 따라 변할 수 있다. 유저 인터페이스는, 가상 비서 유저 경험에 대한 이점으로 비용을 절충하는 결정을 통지하기 위해, 테이블, 비용 누계 차트, 및 히스토그램의 디스플레이 뷰를 제공한다. 플랫폼 인터페이스는, 개개의 질의에 대해, 상이한 도메인으로부터 가능한 응답을 나타낸다. 플랫폼 공급자는 소정의 선택된 도메인을 홍보한다.

Description

가상 비서 도메인 선택 분석{VIRTUAL ASSISTANT DOMAIN SELECTION ANALYSIS}

점점 더 많은 사람들이 SoundHound Hound(사운드하운드 하운드), Google Assistant(구글 어시스턴트), Amazon Alexa(아마존 알렉사), 百度度秘(바이두 두미), Apple Siri(애플 시리), Line/Naver Clova(라인/네이버 클로바), Microsoft Cortana(마이크로소프트 코타나), KT Giga Genie(케이티 기가 지니), SK Telecom NUGU(에스케이 텔레콤 누구), 및 오픈 소스 Mycroft(마이크로프트)와 같은 가상 비서를 사용한다. 1 세대 가상 비서는, 가상 비서 성능을 제공하는 회사에 의해 브랜드화된 컴퓨터, 스마트폰, 또는 홈 스피커 디바이스에서만 이용 가능하였다. 그들은 구성 가능하지 않았으며, 회사가 내부적으로 개발한 맞춤 성능(custom capability)만을 지원하였다.

현재의 가상 비서는 텍스트 대응일 수도 있다. 그들은 쓰여진 자연어 텍스트를 이해할 수 있고 자연어로 쓰여진 응답을 작성할 수 있다. 몇몇 실시형태는 음성 대응이다. 그들은 발화된(spoken) 자연어를 이해하고, 텍스트, 합성된 음성, 이미지, 그래픽 애니메이션, 오디오 및 비디오 클립, 및 등등과 같은 양식으로 응답할 수도 있다.

가상 비서(virtual assistant; "VA")를 포함하는 자동차, 로봇, 쇼핑 키오스크, 및 어플라이언스와 같은, 애플리케이션(앱) 또는 디바이스를 만들고 판매하는 회사가 "처음부터" 그들 자신의 힘으로 VA를 창출하는 것에 투자하기를 반드시 원하는 것은 아니다. 그들은 기존의 자연어 기능성(pre-existing natural language functionality)을 그들 자신의 맞춤형 가상 비서(custom virtual assistant)의 일부로서 유연하게 통합하기를 원한다. 그들은 그들 자신의 요건에 맞게 가상 비서를 구체적으로 구성할 수 없다는 것이 답답하다는 것을 알게 되었다.

도메인은 자연어 기능성의 단위이다. 그들은, 그들이 해석할 수 있는 문장의 세트에 의해, 그리고 인식된 문장의 해석에 응답하고 그에 따라 행동하는 그들의 능력에 의해 특성 묘사된다. 예시적인 도메인은, 날씨에 관한 질문에 답하는 날씨 도메인 및 유저가 약속을 잡고 관리하는 것, 즉, 액션을 요청하는 것뿐만 아니라 질문을 하도록 허용하는 캘린더 도메인을 포함한다.

예를 들면, SoundHound Houndify(사운드하운드 하운디파이)와 같은 몇몇 VA 개발 플랫폼("플랫폼")은, 개발 플랫폼에서 이용 가능한 도메인의 메뉴를 제공함으로써, 가상 비서의 개발자("VA 개발자")를 지원한다. 그러한 플랫폼에서, VA 개발자는, 플랫폼에 이미 알려진 도메인의 어레이를 비롯한 그들 고유의 설계의 맞춤형 가상 비서에 포함시키기 위한 도메인을 선택한다. 몇몇 실시형태는 가상 비서를 구성하기 위해 그러한 플랫폼을 사용하는 것을 가능하게 한다. 몇몇 실시형태는 그러한 플랫폼을 포함한다. 몇몇 실시형태에서, 플랫폼은, 가상 비서에 통합하기 위해 도메인 공급자가 그들의 도메인을 제공할 인터페이스를 제공한다. 도메인 공급자에 의해 제공되는 정보는, 도메인을 선택하는 가상 비서에서 도메인의 기능성을 지원하기에 충분하다. 몇몇 실시형태에서, 몇몇 도메인은 무료이다. 몇몇 실시형태에서, 제공된 도메인은 그 사용에 대한 관련 요금을 갖는다. 다양한 실시형태에서, 지불은, 플랫폼 공급자에 의해, 또는 플랫폼 공급자를 통해 VA 개발자, 유저, 또는 VA 개발자와 같은 다른 당사자(party)에 의해, 도메인 공급자에게 이루어진다. 몇몇 실시형태에서, 플랫폼 공급자는 다른 도메인보다 소정의 도메인을 홍보한다(promote).

몇몇 실시형태는 VA 개발자가 가상 비서에 대한 테스트 질의를 입력하는 것 및 가상 비서가 이들 질의에 응답하여 어떻게 거동(behavior)할지를 테스트하는 것을 가능하게 한다. 몇몇 실시형태는, 도메인의 메뉴로부터 선택되는 상이한 도메인의 상이한 조건 하에서 가상 비서의 거동을 보여주고 비교하는 것을 가능하게 한다.

몇몇 실시형태는 VA 개발자가 테스트 질의의 많은 세트를 입력하는 것을 가능하게 한다. 몇몇 실시형태는 테스트 질의의 세트에 그리고 도메인의 선택에 응답하여, 가상 비서의 거동의 분석의 뷰를 디스플레이한다. 몇몇 실시형태는 세트 내의 모든 질의에 응답하는 것과 관련되는 비용 분석을 가능하게 한다. 몇몇 실시형태는, 가상 비서가 해석할 수 있는 세트 내의 테스트 질의의 일부의 분석을 가능하게 한다.

몇몇 실시형태는 도메인의 상이한 선택의 조건 하에서 세트 내의 질의의 성공적인 해석의 레이트 및 비용을 분석하기 위한 디스플레이 뷰를 제공한다. 몇몇 실시형태는 도메인 결과의 테이블 형식의 뷰(tabular view)를 제공한다. 몇몇 실시형태는 각각의 도메인에 대한 가격 책정 모델(pricing model)을 제공한다. 몇몇 실시형태는 각각의 도메인에 의해 인식되는 통상적인 질의를 제공한다. 몇몇 실시형태는 테스트 질의의 세트 및 테스트 질의의 세트로부터의 질의에 응답하기 위한 총 비용을 제공한다. 몇몇 실시형태는 테스트 세트 내의 질의에 응답하기 위한 각각의 도메인에 대한 비용의 비용 누계 뷰(cost stack view)를 제공한다. 몇몇 실시형태는 도메인당 응답된 질의의 히스토그램 뷰를 제공한다. 몇몇 실시형태는, 몇몇 도메인이 무료이고 다른 도메인이 비용이 있다는 것을 나타낸다.

몇몇 실시형태는 포인터 아이콘(pointer icon)을 갖는 그래픽 유저 인터페이스를 제공한다. 그러한 몇몇 실시형태에서, 포인터가 디스플레이 뷰의 소정의 부분 위에 위치되는 경우, 대응하는 정보가 팝업 메시지에서 디스플레이된다.

몇몇 실시형태는 유용한 기준에 따라 도메인의 메뉴를 소팅(sorting) 또는 필터링하는 것을 가능하게 한다. 몇몇 실시형태는, 배경 컬러, 텍스트 컬러, 폰트, 및 타입스타일과 같은 상이한 방식으로 상이한 도메인을 메뉴에서 디스플레이하는 것을 가능하게 한다.

몇몇 실시형태는 선형 가격 책정 모델(linear pricing model), 구분적 선형 가격 책정 모델(piecewise linear pricing model), 또는 수식 기반의 가격 책정 모델(formula-based pricing model)과 같은, 도메인에 대한 파라미터화된 가격 책정 모델을 가능하게 한다. 몇몇 그러한 실시형태는 도메인의 비용 효율적인 선택을 행함에 있어서 VA 개발자를 지원하기 위한 도구를 제공한다.

몇몇 실시형태는 컴퓨터 판독 가능 매체이다. 몇몇 실시형태는 클라우드 서버이다. 몇몇 실시형태는 모바일 디바이스이다. 몇몇 실시형태는 클라우드 서버와 통신하는 디바이스의 시스템이다. 몇몇 실시형태는, 플랫폼에 의해 구성되는 자연어 가상 비서를 구현하는 독립형(self-contained) 디바이스이다.

도 1은, 한 실시형태에서의, 도메인 공급자로부터, 플랫폼 공급자를 통해, VA 개발자를 통해, 유저에게 이르는 정보 흐름을 도시한다.
도 2는 테스트 질의의 세트를 도시한다.
도 3은, 한 실시형태에서의, 도메인, 플랫폼, 및 가상 비서의 클라우드 기반의 시스템을 도시한다.
도 4는, 한 실시형태에서의, 도메인의 단일 디바이스 시스템, 및 플랫폼으로부터 구성되는 가상 비서를 도시한다.
도 5는, 한 실시형태에서의, 질의를 해석하고 도메인에 따라 응답을 제공하는 가상 비서와 상호 작용하는 유저를 도시한다.
도 6은, 한 실시형태에서의, 도메인을 홍보하는 플랫폼을 통해 자연어 가상 비서의 구성을 안내하는 테스트 질의를 사용하는 VA 개발자를 도시한다.
도 7은, 한 실시형태에서의, 질의하는 유저, 구성하는 VA 개발자, 및 정보를 유저에게 제공하는 도메인 공급자를 갖는 완전한 시스템을 도시한다.
도 8은, 한 실시형태에서의, 어떤 도메인을 인에이블할지를 선택하는 것을 가능하게 하는, 테스트 질의의 세트 중 얼마나 많은 것이 각각의 도메인에 의해 응답될 것인지를 나타내는, 그들의 가격 책정 모델, 및 테스트 세트 내의 질의에 응답하기 위한 도메인당 비용을 나타내는 도메인의 메뉴의 디스플레이를 도시한다.
도 9는, 한 실시형태에서의, 테스트 질의의 세트에 대한 인에이블된 도메인의 선택을 위한 비용 누계 차트(cost stack chart)를 도시한다.
도 10은, 한 실시형태에서의, 테스트 질의의 세트에 대한 인에이블된 도메인의 선택을 위한 비용 누계 차트를 도시한다.
도 11은, 한 실시형태에서의, 인에이블된 도메인의 선택의 각각에 의해 응답되는 테스트 질의의 세트로부터의 질의의 히스토그램을 도시한다.
도 12는, 한 실시형태에서의, 호버링 포인터 아래에서 강조 표시되고(highlighted) 도메인 고유의 정보를 나타내는 도메인마다의 질의 응답의 히스토그램을 도시한다.
도 13은, 한 실시형태에서의, 홍보 도메인이 현저하게 도시된 도메인의 메뉴의 디스플레이를 도시한다.
도 14는, 테스트 질의를 입력하기 위한 그리고 질의에 응답할 수 있는 도메인의 필터링된 메뉴 및 그들의 응답을 보기 위한 디스플레이를 도시한다.
도 15(a)는 선형 가격 책정 모델을 도시한다.
도 15(b)는 구분적 선형 가격 책정 모델을 도시한다.
도 15(c)는 수식 기반의 가격 책정 모델을 도시한다.
도 16(a)는 회전식 비일시적 컴퓨터 판독 가능 매체를 도시한다.
도 16(b)는 패키지화된 솔리드 스테이트 비일시적 컴퓨터 판독 가능 매체를 도시한다.
도 17(a)는 서버의 랙을 도시한다.
도 17(b)는 서버의 블록도를 도시한다.
도 18(a)는 패키지화된 시스템 온 칩(packaged system-on-chip)을 도시한다.
도 18(b)는 시스템 온 칩의 블록도를 도시한다.

다음은 다양한 피쳐를 예시하는 본 발명의 다양한 실시형태를 설명한다. 일반적으로, 실시형태는 설명된 피쳐를 임의의 조합으로 사용할 수 있다.

많은 회사가 가상 비서를 통합하는 것에 의해 향상될 수 있는 디바이스 또는 앱을 만들거나 또는 판매한다. 많은 가상 비서는 음성 기반이다. 음성 대응 디바이스(speech-enabled device)의 예는, 자동차, 로봇, 쇼핑 키오스크, 어플라이언스, 및 스마트폰이다. 그들 모두는 통합된 가상 비서를 구비할 수 있다. 유저는, 일반적으로 정보에 대한 요청 또는 액션에 대한 요청 중 어느 하나인 자연어 질의를 발행하는(issuing) 것에 의해 가상 비서와 통신한다. 질의는 발화될 수도 있거나 또는 쓰일 수도 있다. 가상 비서로부터의 응답은, 음성, 텍스트, 그래픽, 오디오, 또는 비디오 녹화뿐만 아니라 액션을 포함할 수도 있다.

지능형 다기능 가상 비서의 개발은 복잡하며, 일반적인 아키텍쳐 외에, 가상 비서가 핸들링할 수 있는 모든 도메인에 대한 투자 및 전문 지식을 필요로 한다. 가상 비서를 개발할 때, 개발자가 가상 비서 개발 플랫폼 공급자로부터 도메인 소프트웨어를 구매하거나 라이센스를 취득하는 것이 합리적이다. 이것은, 플랫폼 공급자가 충분한 전문가를 고용하여 우수한 플랫폼을 구축하는 것 및 다양한 VA 개발자가 비용을 공유하는 것을 허용한다.

그러한 생태계에서, 가상 비서를 구현하기 위한 로직 또는 소프트웨어는, 플랫폼 공급자에 의해 운영되는 네트워크 연결 서버 내에서 또는 네트워크에 연결될 필요가 없는 디바이스 내에서 컴퓨터 판독 가능 매체 상에 저장되는데, 디바이스 로직 또는 소프트웨어는 플랫폼을 사용하여 구성되었다. 통상적인 네트워크 연결 실시형태에서, 클라이언트 앱 또는 원격 디바이스는, 인터넷을 통해, 애플리케이션 프로그래밍 인터페이스(application programming interface; "API")를 사용하여, 서버에 액세스한다. 몇몇 단일 디바이스 가상 비서는 자율적으로 작동하고, 몇몇은 네트워크 액세스를 통해서만 작동하고, 몇몇은 로컬 및 원격 가상 비서 성능을 결합하는 것에 의해 간헐적인 네트워크 액세스를 통해 작동한다. 네트워크에 연결되든 또는 연결되지 않든, 가상 비서는 유저로부터 자연어 질의를 받고, 질의를 해석하고, 응답을 유저에게 제공한다. 제로(zero) 개 또는 하나 이상의 도메인이 각각의 질의를 인식할 수도 있다. 모호성이 있는 경우, 가상 비서는 경쟁 도메인 중 하나를 선택하여 그것의 응답을 결정한다.

가상 비서 개발자는, 가상 비서를 회사의 특정한 디바이스 및 앱에 통합하는 회사를 위해 일하는 사람들(대부분의 경우, 숙련된 엔지니어)이다. VA 개발자는, 그들의 특정한 요건에 맞게 가상 비서를 구성하기 위해 플랫폼을 사용한다. 가상 비서는 통상적으로 다수의 도메인을 지원한다. 몇몇 도메인은, 날씨, 뉴스, 일반상식(trivia), 레스토랑 검색, 간단한 수학, 및 위키피디아 조사와 같은 정보를 제공한다. 몇몇 도메인은, 온도 조절 장치 또는 조명의 제어, 음악의 스트리밍, SMS 텍스트 메시지의 전송, 및 캘린더 약속의 관리와 같은 서비스를 제공한다. 몇몇 도메인은 단지 시간을 알려주는 것처럼 간단할 수 있다. 몇몇 도메인은, 여행사 서비스를 제공하는 것과 같이, 복잡할 수 있고, 몇몇은, 아이의 위치를 찾는 능력과 같이, 유저에게 고도로 가치가 있다. 많은 도메인은 웹 API에 액세스하여 특정한 정보 또는 동적 정보에 액세스하거나 또는 요청된 액션을 야기한다. 몇몇 도메인은 지불에 대한 대가로 써드파티 공급자로부터의 정보 및 서비스를 제공한다. 예를 들면, 몇몇 날씨 도메인은 날씨 통보 정보(weather report information)를 획득하기 위해 전국 날씨 서비스 API에 액세스한다.

플랫폼은, 다른 기능 중에서도, VA 개발자에게, 그들의 가상 비서에 포함시키기 위한 도메인을 선택하는 방식을 제공한다. 도메인은 일반적으로 도메인 공급자 엔티티에 의해 제공된다. 몇몇 플랫폼은 수천 개의 써드파티 도메인 공급자를 지원한다. 몇몇 도메인 공급자는 소규모 회사이거나 또는 심지어 개인 프로그래머이다.

몇몇 실시형태에서, 도메인에 의해 인식되는 질의의 세트는 의미론적 문법 코드(semantic grammar code)에 의해 정의된다. 그러한 문법 코드는, 질의를, 정보에 대한 특정한 요청으로서 또는 액션에 대한 특정한 요청으로서 해석하기 위한 규칙을 생성하는 도메인 개발자(대부분의 경우, 숙련된 엔지니어)에 의해 각각의 도메인에 대해 구체적으로 생성된다. 그러한 실시형태에서, 자연어 해석은 도메인 문법 코드에 기초한다. 도메인 문법은, 질의를 파싱하기 위해 자연어 프로세싱 시스템에 의해 사용되는 구문 규칙을 포함한다. 도메인 문법에서, 구문 규칙은 의미론적 확장(semantic augment)에 의해 보강된다. 확장은, 제로 개 이상의 하위 구성 요소(sub-constituent)의 해석으로부터 구성 요소(constituent)의 해석을 구성하는 기능인데, 여기서 하위 구성 요소는 구문 파싱에 의해 결정된다. 몇몇 실시형태에서, 도메인 문법은 도메인에 대한 질의를 인식 및 해석하기 위해 사용된다. 몇몇 실시형태에서, 인터프리터의 적어도 일부는, 머신 러닝을 사용하여 트레이닝되는 신경망(neural network)을 포함한다. 어느 경우든, 질의의 해석은, 질의로부터의 정보에 기초하여, 의미론적 슬롯(semantic slot)에 값을 할당한다. 몇몇 실시형태는, 미팅의 스케줄링 또는 비행편의 예약과 같은, 질의에 대한 유저의 전반적인 의도를 표현하는 의도 슬롯을 인코딩한다.

예시적인 실시형태에서, 날씨 통보를 요청하기 위한 의미론적 문법은, (1) 자신의 구문 컴포넌트가, Location(위치)이라는 이름의 대응하는 의미론적 슬롯을 갖는 <location>으로 명명되고, 자신의 값이 모든 인스턴스에서 위치로서 자격을 얻어야만 하는 구성 요소; 및 (2) 자신의 구문 컴포넌트가, Time(시간)이라는 이름의 대응하는 의미론적 슬롯을 갖는 <time>으로 명명되고, 자신의 값이 시간으로서 자격을 얻어야만 하는 다른 구성 요소를 구비할 수도 있을 것이다. 유저가, "내일 Timbuktu(팀북투)의 날씨가 어때"라고 묻는 경우, 이 실시형태는 <location> 및 <time> 성분을 갖는 날씨 도메인 문법을 사용할 수 있고, Intent(의도) 슬롯을, 값 "weather_info"로, Location(위치) 슬롯을 값 "Timbuktu"로, 그리고 Time(시간) 슬롯을 값 "내일"로, 또는 어쩌면 대응하는 캘린더 날짜로 채울 수 있다.

마찬가지로, 유저가 "적어도 4 개의 별을 받은 가장 가까운 프랑스 레스토랑이 어디야"라고 말하면, 시스템은 <cuisine_type> 및 <star rating> 컴포넌트에 대한 구문 규칙을 갖는 레스토랑 도메인 문법을 사용할 수 있고, CuisineType 및 StarRating에 대한 대응하는 슬롯은, "프랑스 요리" 및 "적어도 4 개의 별"을 각각 전달하는 값으로 채워질 것이다. 다른 예를 들면, 유저가 "엄마에게 사랑해요라고 문자 보내줘"라고 말하면, 시스템은 SMS 문자 보내기(texting) 도메인 문법을 사용하여 질의를 인식할 수 있고, 의도 슬롯을 "Send_Text"로, Recipient(수신측) 슬롯을, 유저의 연락처 목록에서 "엄마"에 대응하는 연락처에 대한 조회 내용(reference)으로, 그리고 Message(메시지) 슬롯을 "사랑해요"로 채울 수 있다. 질의의 해석은 이들 슬롯을 사용하여 구성될 것이고, 의도에 의해 명시되는 질의의 해석의 이행은, 메시지의 텍스트 내용을 수신측의 이동 전화로 전송하는 것일 것이다. 유저가 "고양이가 얼마나 많은 발톱을 가지고 있지"라고 말하면, 시스템은 지식 도메인 질의를 인식할 수도 있을 것이고, 의도 슬롯을 (예를 들면) "WikipediaLookup(위키피디아룩업)"으로, Species(종) 슬롯을 "고양이"로, Attribute(속성) 슬롯을 "발톱"으로, 그리고 Question(질문) 슬롯을 "얼마나 많이"로 채울 수도 있을 것이다. 자연어에 대한 다른 접근법도 가능하다.

몇몇 질의는 다수의 도메인에서 해석될 수 있다. 상이한 도메인 공급자가 동일한 도메인 기능성을 제공하기 위해 경쟁하는 경우 그러한 중첩하는 문법을 갖는 것이 일반적이다. 예를 들면, 플랫폼은 호텔 예약을 하기 위한 네 개의 경쟁 도메인을 제공할 수도 있을 것인데, 그들 모두는 질의 "파리에 있는 호텔을 보여줘"를 해석할 수 있다. VA 개발자가 이러한 상황을 처리하는 것을 돕기 위해, 플랫폼은, 가상 비서의 성능에 소정의 도메인은 포함하고 다른 도메인은 포함하지 않도록 또는 소정의 도메인을 다른 도메인보다 우선적으로 선택하도록 가상 비서를 구성할 수 있다. 그러한 선택은 "하드(hard)" 방식으로 또는 "소프트(soft)" 방식으로 이루어질 수 있다.

하드 선택(hard choice)은 구성시 이루어진다. 몇몇 도메인이 가상 비서에서 인에이블되고, 모든 나머지 도메인이 디스에이블된다. 이 구성 단계는, VA 개발자가, 런타임시 질의의 해석에 어떤 도메인이 참여될지를 제어하는 것을 허용한다. 생산시, 질의 해석은 인에이블된 도메인만을 고려한다.

소프트 선택은 런타임시에 이루어진다. (도메인 모두가 인에이블되는) 질의의 경쟁하는 도메인 해석 사이의 선택은, 통상적으로, 득점 스킴(scoring scheme)에 기초하여 최고 득점 해석을 선택하는 것에 의해 이루어진다. 득점 기술은 도메인에 우선 순위를 부여하기 위해 사용될 수 있다. 즉, 인에이블된 도메인 A 및 B가 질의를 해석하기 위해 경쟁하는 경우, 도메인 A는 B에 비해 항상 우선 순위를 부여받을 수 있다. 득점은 또한, 관련이 없는 도메인 사이의 모호성의 경우를, 비록 그러한 의미론적 충돌이 덜 빈번하지만, 해결할 수 있다. 예를 들면, 질의 "Denver(덴버)가 얼마나 높지"는, 도시의 고도를 알고 있는 지리적 사실 도메인에 의해 해석될 수 있지만, 그러나, 그것은, "높은"이 온도를 가리키는 날씨 도메인에 의해서도 또한 해석될 수 있다. 맥락이 없으면 두 번째 해석은 불가능 수도 있지만, 그러나, "시카고의 날씨가 어때? [대답: 56 도] 덴버는 얼마나 높지?"와 같은, 대화 중 날씨 및 온도의 맥락에서는 꽤 가능성이 있다. 파싱 및 해석 점수는 문맥에 민감할 수도 있고, 득점은, 이들 모두뿐만 아니라, 도메인 우선 순위도 고려할 수 있다.

효과적인 구성의 선택을 위해, 플랫폼은 현명한 결정을 내림에 있어서 VA 개발자를 지원하도록 의도되는 경험적 도구(empirical tool)를 제공할 수 있다. 몇몇 실시형태에서, 도메인의 비용 효율성(cost effectiveness)은 테스트 세트와 관련하여 다음의 관점에서 측정될 수 있다: (1) 커버리지, 즉, 도메인에 의해 인식되는 질의의 비율; (2) 정확성, 즉, 도메인에 의해 정확하게 해석되는 인식된 질의의 비율; (3) 비용 고려 사항(cost consideration).

비용에 관하여, 몇몇 실시형태에 따르면, 플랫폼은 각각의 도메인과 관련되는 가격 책정 모델을 알고 있고 가격 책정 정보를 VA 개발자에게 제공할 수 있다. 많은 플랫폼은, 시간을 알리거나 또는 간단한 수학 문제를 푸는 도메인과 같은 소정의 도메인을 무료로 제공한다. 그러나, 많은 도메인 공급자는, 높은 가치의 도메인을 제공하며 그들의 데이터 및 서비스를 사용하는 것에 대한 보상을 받기를 원한다. 예를 들면, 주식 거래를 위한 도메인은, 유저에 의해 요청되는 각각의 주식 거래에 대한 수수료를 과금할 수 있다. 몇몇 가상 비서에서, 유저는 도메인을 사용하는 것에 대해 VA 개발자에게 비용을 지불하고, VA 개발자는 도메인 공급자에게 직접적으로 또는 플랫폼을 통해 비용을 지불한다. 몇몇 경우에, 플랫폼은 그들이 추가하는 가치를 만회하기 위해 도메인의 비용을 올릴 수도 있다.

실제로, 플랫폼 또는 VA 개발자는, 더 많은 고객을 유인하기 위해, 소정의 도메인을 할인할 수도 있거나 또는 보조금을 지급할 수도 있다. 가격 책정 모델에서, 질의당 가격은 종종 대량 매입 할인의 대상이 된다. 그러한 모든 고려 사항은 도메인에 대한 가격 책정 모델의 일부일 수 있다.

커버리지 및 정확성은, VA 개발자로부터 플랫폼에 의해 수신되는 테스트 질의의 세트에 기초하여 측정된다. 인에이블된 도메인이 질의를 인식하면 "적중(hit)"이 등록된다. 테스트 질의가 적어도 하나의 인에이블된 도메인에 적중하면, 그것은 "커버"된다. 커버리지는, 커버되는 테스트 질의의 수에 의해 (절대적으로), 또는 테스트 질의의 대응하는 부분에 의해 (상대적 의미에서) 측정된다. 정확성은, 정확하게 핸들링되는 테스트 질의의 수에 의해 (절대적으로), 또는 커버된 테스트 질의의 대응하는 부분에 의해 (상대적인 의미에서) 측정된다. 테스트 세트가 질의 해석 데이터를 포함하는 경우, 또는 그것이 질의 데이터를 포함하는 경우, 정확성이 측정될 수 있다.

몇몇 실시형태에서, 테스트 정확성은, 생산시 유저 질의에 대해 수행될 것처럼, 테스트 질의를 해석하는 것을 요구하지만, 그러나 테스트 질의가 실행(이행)되는 것을 요구하지는 않는다. 정확성은, 해석(이것은 질의의 의미의 내부 표현임)의 동등성(또는 매치하는 호환성)에 기초한다. 몇몇 실시형태에서, 테스트 정확성은 테스트 질의를 해석하는 것 및 이행하는 것 둘 모두를 요구한다. 그 다음, 정확성은 응답의 동등성(또는 매치하는 호환성)을 기초한다.

몇몇 실시형태에서, VA 개발자는, 마치 유저로부터 수신된 것처럼, 테스트 질의를 입력할 수 있고, 플랫폼은 VA 개발자에게 다음 중 하나 이상을 나타낼 수 있다: (1) 어떤 도메인이 질의를 인식할 수 있는지; (2) 질의의 해석; (3) 해석을 이행하고 질의에 응답하는 데 필요한 정보, 및 (4) 응답 제공의 비용.

몇몇 실시형태에서, VA 개발자는 테스트 질의의 큰 세트를 입력하고, 플랫폼은, 질의의 세트가 적중할 도메인 및 테스트 세트에 대한 누적 비용에 관한 통계 정보를 제공한다. 몇몇 실시형태에서, 질의는 다수의 도메인에 적중할 수도 있다. 다른 실시형태에서, 시스템은, 질의당 단지 하나가 적중되는 것을 보장한다. 통계 정보의 하나의 타입은, 질의의 세트에 걸친 도메인당 적중의 히스토그램이다. 다른 타입의 통계 정보는 다음 중 하나 이상을 갖는 테이블이다: 도메인 이름; 각각의 도메인이 가상 비서에 대해 인에이블되는지의 여부; 각각의 도메인에 액세스하기 위한 가격 책정 모델(예컨대 질의당 단순 비용); 각각의 도메인에 적중하는 테스트 세트 내의 질의의 수; 가상 비서에서 도메인이 인에이블되게 한 것에 기인하는 결과적으로 나타나는 비용; 인에이블된 도메인 중 적어도 하나와 적중할 테스트 세트 내의 질의의 부분; 및 인에이블된 도메인을 사용하여, 테스트 세트 내의 모든 질의를 핸들링하기 위한 총 비용.

몇몇 질의가 하나보다 더 많은 도메인에게 정보를 요구하는 것이 가능하다. 예를 들면, 질의 "마지막 슈퍼 볼 게임에서 우승한 팀의 홈 시티(home city)의 날씨가 어때"는, 가상 비서가, 스포츠 정보 도메인을 사용하여 마지막 슈퍼 볼 게임에서 어떤 팀이 우승했는지 및 그들의 홈 시티를 찾는 것을 필요로 할 것이고, 그 다음, 날씨 도메인을 사용하여 날씨 정보를 조사하기 위해 도시 정보를 사용할 것이다. 그러므로, 테스트 질의의 세트에 응답하는 가상 비서에 의해 적중되는 도메인 수는, 질의의 수보다 더 클 수 있고, 각각의 테스트 질의가 단지 하나의 도메인에만 적중하는 경우보다 질의의 비용이 더 높을 수 있다.

몇몇 질의는 어떠한 도메인에 의해서도 인식되지 않는다. 몇몇 실시형태에서, 그러한 실패한 질의는, 웹 검색의 결과와 같은 디폴트 정보와 함께 응답된다. 결과적으로, 적중의 수도 또한 질의의 수보다 더 적을 수 있다.

일반적으로, 가상 비서가 더 많은 도메인을 가질수록, 그것은 만족스러운 방식으로 더 많은 질의에 응답할 수 있다. 가상 비서에 만족하는 유저가 더 많을수록, 더 많은 유저가 그것을 사용할 것이다. 더 많은 유저가 가상 비서를 사용할수록, 도메인 공급자는 더 많은 인센티브를 창출해야 하고 도메인을 개선해야 한다. 이것은, 유저에게 유익하고 모든 참여 회사에 이익을 창출하는 계속 향상하는 도메인 및 가상 비서의 선순환을 창출한다.

다음은, 도면에서 예시되는 소정의 대표적인 실시형태의 설명이다.

당사자

도 1은 가상 비서 생태계 및 그 동작의 다이어그램을 도시한다. 상이한 도메인 공급자는 그들의 정보 및 서비스를 플랫폼(12)에 제공한다. 구체적으로, 날씨 정보 도메인 공급자는 날씨 도메인(11a)을 제공하고; 맵 정보 도메인 공급자는 맵 도메인(11b)을 제공하고; 텍스트 메시징 도메인 공급자는 텍스트 메시징 도메인(11c)을 플랫폼(12)에게 제공한다. 도메인 문법 외에도, 플랫폼에 제공되는 정보는, 가격 책정 모델 및 테스트 데이터를 포함할 수도 있다.

VA 개발자는 플랫폼(12)을 사용하여, 어플라이언스(13a), 이동 전화(13b), 및 자동차(13c)와 같은 가상 비서를 생성하는데, 이들 모두는 복수의 유저(14)에게 VA 성능을 제공한다. 몇몇 유저는 하나보다 더 많은 종류의 가상 비서를 사용한다. 정보 및 서비스는, 일반적으로, 좌측에서 우측으로 흘러 도메인으로부터, 플랫폼을 통해, 그리고 VA를 통과하여 유저에게 도달한다.

일반적으로, 지불은 반대 방향으로 흐른다. 다양한 실시형태에서, 유저는 VA 개발자, 플랫폼 공급자, 또는 도메인 공급자에게 직접적으로 지불한다. 다양한 실시형태에서, VA 개발자는 플랫폼 공급자 또는 도메인 공급자에게 직접적으로 지불한다. 몇몇 실시형태에서, 플랫폼 공급자는 도메인 공급자에게 지불한다. 몇몇 실시형태에서, 플랫폼 공급자는 가상 비서 개발자에게 할인을 제공하거나 또는 사업에 성공하기 위해 또는 전체적인 사용을 증가시키기 위해, 몇몇 도메인에 대한 액세스를 손실을 보면서 제공한다. 몇몇 실시형태에서, 도메인 공급자는, 플랫폼 공급자가 그들의 도메인을 홍보하는 것을 대가로 플랫폼 공급자에게 비용을 지불하거나 또는 할인을 제공한다. 본원에서 개시되는 기술은, 프레임워크를 사용하여 가능한 비즈니스 관계를 제한하지 않는다.

몇몇 실시형태에서, 회사는 도메인 공급자 및 가상 비서 개발자 둘 모두이다. 예를 들면, 자동차의 가상 비서는, 자동차의 연료 레벨과 같은, 자동차에 대한 상태 질의에 응답하기 위해, 또는 헤드 라이트를 켜는 것과 같은 액션을 요청하기 위해, 그 자신의 로컬 도메인을 필요로 한다. 이것은, 어쩌면, 날씨 정보를 갖는 도메인과 같은 외부 도메인을 포함하는 것에 추가한 것이다. 다른 예를 들면, 특정한 비디오 콘텐츠 공급자에 의해 판매되는 비디오 플레이어 셋탑 박스는, 자신의 맞춤형 가상 비서의 일부로서, 자신의 비디오 콘텐츠를 취출하기(retrieving) 위한 도메인에 액세스하는 것을 필요로 한다. 이 도메인은 로컬일 수도 있거나 또는 외부에 있을 수도 있다. 몇몇 실시형태에서, 몇몇 도메인은 몇몇 가상 비서에만 독점적이며 다른 가상 비서는 이용 불가능하다.

도 2는, 범용 가상 비서에 대해 통상적인 질의의 세트의 예를 도시한다. 날씨에 대한 질의가 가장 빈번하지만, 그러나, 다른 일반적인 질의는, 지역 업체(local business), 맵 방향 및 교통 상황에 대한 검색, 뉴스 또는 스포츠에 대한 질의, 사소한 사실에 대한 질의, 및 다양한 다른 타입의 질의이다. 각각의 질의가 테스트 세트에서 다수 회 나타날 수 있고, 순서는 중요하지 않기 때문에, 백(bag)으로 공지되는 대안적인 표현은, 각각의 고유한 질의를 카운트와 관련시키는 것이다. 예를 들면, 질의 "날씨가 어때"는 세트에서 3의 카운트를 갖는다. 이것을 한 단계 더 진척시키면, 각각의 질의는, 다른 질의와 비교하여, 실험자에 대한 자신의 중요성을 나타내는 (단지 빈도 카운트가 아닌) 실제 값의 가중치를 부여받을 수 있다. 그러한 가중치는 1의 합계를 가지도록 정규화될 수 있다.

클라우드 및 디바이스

도 3은 제1 앱(32) 및 제2 앱(33)과 통신하는 유저(31)를 도시한다. 앱은 네트워크(34)를 통해 플랫폼(35)과 통신한다. 앱 개발자(36)는 이전에는 플랫폼(35)을 사용하여 제1 앱(32)에 대한 제1 가상 비서 및 제2 앱(33)에 대한 제2 가상 비서를 구성하였다. 몇몇 실시형태에서, 상이한 개발자는 각각의 앱을 구성한다.

플랫폼(35) 상에서, 구성에서의 선택을 위해 다수의 도메인이 이용 가능하다. 이용 가능한 도메인의 수는, 수백 개, 수천 개 또는 훨씬 더 많을 수 있다. 도메인은 도메인 공급자에 의해 제공된다. 그들은 플랫폼 상에서 도메인 등록 또는 수집 프로세스(domain registration or ingestion process)를 통해 이용 가능하게 만들어진다. 등록 동안, 도메인에 대해 공급되는 정보는, 고유 ID, 간단한 이름, 설명, 인식된 질의의 예, 및 실행 가능한 또는 해석 가능한 형태의 도메인, 예컨대 소스 코드, 오브젝트 코드, 신경망, 또는 의미론적 문법을 포함할 수도 있다. 본 개시에서, 용어 "문법" 또는 "의미론적 문법"은, 일반적으로, 질의를 파싱 또는 인식하기 위해 실행될 수 있는, 소스, 오브젝트, 신경망 또는 임의의 데이터 구조 인스턴스와 같은 코드의 설명을 나타낸다.

개발자(36)에 의해 생성되는 가상 비서 구성은, 제1 도메인(37) 및 제2 도메인(38)의 선택을 포함한다. 유저(31)가 어느 하나의 앱에 질의를 하면, 그것은, 제1 도메인(37) 또는 제2 도메인(38) 중 어느 하나로부터, 웹 API를 사용하여, 질의를 해석하고 적절한 정보를 취출하는 플랫폼(35)으로 질의를 전송한다.

도 4는, 플랫폼(45)과는 독립적으로 동작하는 디바이스(44) 내에 통합되는 앱(42)과 통신하는 유저(41)를 도시한다. 도면은 일정한 비율로 묘사되는 것은 아니다. 앱 개발자(46)는 이전에는 플랫폼(45)을 사용하여 앱에 대한 가상 비서를 구성하였다. 플랫폼은 앱 통합기가 구성된 가상 비서를 앱(42)에 통합하는 데 필요한 소프트웨어를 제공하였다.

앱(42)이 유저(41)로부터 질의를 수신하면, 그것은 통합된 인터프리터를 사용하여 그들을 해석하고, 그에 따라, 로컬 정보 도메인(47)에게 정보를 요청하거나 또는 로컬 서비스 도메인(48)에게 서비스 액션을 요청한다. 예를 들면, 자동차 디바이스에서, 정보 도메인(47)은 문법을 가질 것이며, "얼마나 많은 배터리 전력이 남았는가" 및 "이것은 어떤 무선국인가"와 같은 질의에 대한 정보를 제공한다. 자동차에서, 서비스 도메인(48)은 문법을 가질 것이고, "선루프 열기" 및 "라디오 켜기"와 같은 서비스를 제공한다. 이들 예시적인 정보 소스 및 서비스는 자동차에 국한되며 네트워크에 대한 액세스를 필요로 하지 않는다.

몇몇 실시형태는, 네트워크 액세스를 필요로 하는 도메인 및 그렇지 않은 도메인의 혼합을 가능하게 하는 구성을 갖는다. 그러한 실시형태는, 네트워크 액세스가 이용 가능할 때 도메인이 성공적으로 응답하는 것 및 네트워크 액세스가 이용 가능하지 않을 때 성공적이지 않게 응답하는 것을 가능하게 한다.

정보 흐름 및 구성

도 5는, 실시형태에 따른, 런타임시 플랫폼을 통한 데이터 흐름의 다이어그램을 도시한다. 유저(51)는 플랫폼이 프로세싱할 자연어 질의를 발행한다. 인터프리터(52)는 질의를 해석하고 유저(51)에게 응답을 제공한다. 질의에 따라, 응답은, 인터프리터(52)가 질의를 해석할 수 없다는 간단한 표시일 수 있다. 몇몇 실시형태에서, 인터프리터(52)는, 자신이 성공적으로 해석하는 질의에 대한 응답만을 제공할 수 있다.

도메인 공급자는, 음악 소스와 같은 그들 고유의 서버 또는 다른 소스 예컨대 날씨 센서 또는 서비스 예컨대 메시지 전송 또는 차량 제어로부터의 데이터를 제공한다. 일반적으로, 그러한 데이터 또는 서비스는 도메인(53b)으로서 알려져 있다. 유저가 도메인을 언제 호출하려고 의도하는지를 알기 위해, 그들은 대응하는 문법 코드(53a)를 가질 수 있다. 문법 코드는, 도메인을 호출하는 표현법(phrasing) 및 유저 표현으로부터의 단어로 채워질 수 있는 슬롯을 포함한다. 예를 들면, 표현법 "날씨가 어때"를 갖는 문법 코드는 날씨 도메인을 호출하고, 도메인 코드는 날씨 예보를 취출한 위치 및 시간에 대한 슬롯을 포함한다. 날씨 도메인의 슬롯 및 표현법에 대한 코드는, 어구 "내일의 Timbuktu 날씨가 어때"는 Timbuktu의 내일 날씨에 대해 도메인 공급자에게 요청을 수행해야 한다는 것을 인터프리터가 아는 것을 가능하게 한다. 도메인과 관련되는 코드는, 많은 실시형태에서, 플랫폼에 의해 등록, 수집 및 저장된다.

인터프리터(52)가 도메인(53b)과 관련되는 문법 코드(53a)에 따라 질의를 해석하고 질의가 도메인(53b)에게 정보를 요청한다는 것을 결정하면, 인터프리터(52)는 다수의 도메인 공급자 중 하나에 의해 제공되는 적절한 도메인(53b)에게 정보를 요청한다. 인터프리터(52)는 그 정보를 사용하여 유저(51)에 대한 자신의 응답을 형성한다.

도 6은, 실시형태에 따른, 구성시 플랫폼을 통한 데이터 흐름의 다이어그램을 도시한다. 많은 앱 통합기(app integrator) 중에서, 개발자(66)는 하나 이상의 테스트 질의 입력(64)을 플랫폼에 제공한다. 개발자(66)는 또한 하나 이상의 도메인(65)의 선택을 제공한다. 인터프리터(62)는 선택된 도메인(63b)의 문법 코드(63a)에 따라 테스트 질의를 해석하여, 선택된 도메인(63b) 중 임의의 것이 질의를 해석할 수 있는지의 여부를 결정한다. 디스플레이는 인터프리터(62)로부터의 결과를 개발자(66)에게 디스플레이한다(67). 다양한 실시형태에 대해 많은 디스플레이 뷰가 적절하고 유용하다. 몇몇 디스플레이 뷰는 하기에서 예시 및 설명될 것이다.

도 6의 실시형태는, 인터프리터(62)의 결과에 기초하여 하나 이상의 도메인(68)을 홍보하는 것을 더 포함한다. 예를 들면, 테스트 질의가 홍보 도메인(promotional domain)에 따라 성공적으로 해석될 수 있는 경우, 플랫폼은, 홍보 도메인이 인에이블되는 경우 인터프리터가 유저에게 보여줄 결과를 개발자(66)에게 보여준다. 몇몇 실시형태는, 심지어 홍보 도메인이 인에이블되지 않은 경우에도, 그들의 이름을 보여준다. 몇몇 실시형태는, 가장 높은 등급의 대안적인 도메인으로부터의 정보를 가지고 생성될 응답에 대한 대안으로서, 홍보 도메인으로부터의 정보를 가지고 생성될 응답을 보여준다.

예를 들면, 더 정확하고 자세한 정보를 갖는 날씨 도메인 공급자가 더 높은 가격을 과금할 수도 있을 것이고 홍보 도메인으로 그 자신을 제공할 수도 있을 것이다. 디폴트 날씨 도메인이 일반적으로 날씨 질의에 응답할 수도 있을 것이다. 실시형태에 따른 플랫폼은 디폴트 날씨 도메인으로부터의 정보에 따라 응답을 보여줄 것이고, 홍보 날씨 도메인으로부터의 정보를 가지고 생성될 응답을 보여줄 것이다. 이것은, 홍보 도메인을 선택하라는 제안 및 심지어 가상 비서에 포함시키기 위한 홍보 도메인을 선택하는 수단, 예컨대 버튼 아이콘과 함께 행해질 수 있다.

도 7은 플랫폼을 통한 데이터 흐름의 다이어그램을 도시한다. 개발자(76)는 하나 이상의 테스트 질의 입력(74)을 플랫폼에 제공한다. 개발자(76)는 또한 하나 이상의 도메인(75)의 선택을 제공한다. 인터프리터(72)는 선택된 도메인(73b)의 문법 코드(73a)에 따라 테스트 질의를 해석하여, 선택된 도메인 중 임의의 것이 질의를 해석할 수 있는지의 여부를 결정한다. 디스플레이는 인터프리터(72)의 결과를 개발자(76)에게 디스플레이한다(77). 도 7의 실시형태는, 인터프리터(72)의 결과에 기초하여 하나 이상의 도메인(78)을 홍보하는 것을 더 포함한다. 구성 시간 이후, 런타임 동안, 유저(71)는 인터프리터(72)가 해석하여 응답을 유저(71)에게 제공할 질의를 발행한다.

도 7의 실시형태에서, 도메인(73)으로부터 정보를 수신하는 것에 응답하여, 플랫폼은 요금(79)을 계산한다. 요금은 가격 책정 모델에 따라 계산된다. 가격 책정 모델은 도메인 사용량에 기초하는 함수이다. 몇몇 실시형태는 각각의 정보 액세스에 대한 단일의 요금과 같은, 간단한 가격 책정 모델을 갖는다. 그러한 요금은 일반적으로 1 US 달러의 작은 부분이다. 몇몇 실시형태는, 액세스된 정보의 타입 또는 시간의 윈도우 내에서의 이전 정보 액세스의 회수에 기초하는 함수인 더 복잡한 가격 책정 모델을 지원한다. 동등하게, 다른 도메인이 정보를 제공할 때, 몇몇 도메인은 서비스 제공에 대해 과금한다.

도 7의 실시형태에서, 플랫폼은, 유저에 대한 응답을 구성하도록 가상 비서에게 정보를 제공하는 각각의 도메인 공급자에게 지불액을 제공한다. 이것은, 도메인 공급자가, 가상 비서에 포함시키기 위한 그들의 도메인을 개발자가 선택해 주기를 원하게 할 인센티브, 따라서, 플랫폼 공급자가 친밀한 비즈니스 관계를 갖는 도메인 공급자의 도메인을 플랫폼 공급자가 홍보하게 할 인센티브를 생성한다.

도메인 테이블

도 8은 실시형태에 따른 도메인 테이블(80)의 디스플레이 뷰를 도시한다. 테이블(80)은 도메인당 하나의 행(row)을 갖는다. "인에이블된" 열(column)은 도메인 인에이블화(enablement)의 상태를 나타낸다. 몇몇 실시형태에서, 이 열 내의 셀은 대응하는 도메인을 인에이블 또는 디스에이블하기 위해 사용될 수 있다. 클릭을 위한 마우스, 화살표 키 또는 단축 키를 갖는 키보드, 터치스크린, 또는 유저 인터페이스 내의 오브젝트의 선택을 행하기 위한 다른 적절한 수단과 같은, 도메인을 선택 또는 선택 해제하기 위한 다양한 입력 수단이 가능하다.

많은 상이한 그래픽 레이아웃이 가능하다. 일반적으로, 도메인에 대한 정보의 관련된 단편(piece), 예컨대, 그들의 이름, 그들이 인에이블되는지의 여부, 그들이 (테스트 세트 중에서) 해석할 수 있는 질의 수 또는 비율, 및 그들의 가격 책정 모델(예컨대 가장 간단한 경우에서 질의당 비용)을 디스플레이하기 위해 많은 수의 도메인을, 행, 및 상대적으로 적은 수의 열로서 시각적으로 편제하는 데 그리드가 유용하다. 그리드에 정렬되는 도메인을 나타내는 직사각형과 같은, 관련된 정보를 보여주는 시각적 오브젝트도 또한 작동한다. 예컨대 퍼스널 컴퓨터의 바탕 화면 상에서 오브젝트가 임의적으로 드래그 앤 드랍되는 것도 또한 가능하다.

테이블(80)은, 가상 비서에 포함시키기 위해 도메인의 메뉴로부터 어떤 도메인이 선택되어 있는지를 VA 개발자에게 보여주기 위한 디스플레이 뷰를 갖는다. 디스플레이 뷰(80)는 5 개의 열을 갖는다. 표제(heading) 행은 각각의 열에 그 사용에 의해 표제를 단다. 열은 다음의 것이다: 이용 가능한 도메인의 메뉴로부터 나열되는 각각의 도메인의 이름; 가상 비서에 대해 도메인이 인에이블되는지의 여부; 도메인이, 테스트 세트 내의 각각의 질의를 해석할 수 있는 모든 인에이블된 도메인 중에서 인터프리터가 선택할 도메인인 질의의 수의 카운트; 질의에 응답하기 위한 가격 책정 모델; 및 테스트 세트 내의 각각의 질의에 응답하도록 도메인이 선택될 때 가상 비서가 응답을 제공하는 데 필요한 정보를 도메인이 제공하기 위한 총 비용.

표제 행 다음에는, 메뉴 내의 각각의 도메인에 대한 행이 있다. 테이블(80)은 메뉴 내에 7 개의 도메인을 포함한다. 몇몇 실시형태는 훨씬 더 많은 수의 도메인, 가변 개수의 도메인, 및 신규 및 현존하는 도메인 공급자가 그들의 공급을 생성 또는 제거함에 따라 동적으로 변하는 도메인을 지원한다. 제1 열은 메뉴의, 메뉴 내의 각각의 도메인의 이름을 갖는 텍스트 문자열을 나타낸다. 나타내어지는 도메인은, 날씨, 음식, 스포츠, 맵, 사실, 타이머, 및 수학이다.

제2 열은, 가상 비서에 포함시키기 위한 도메인이 선택되는 경우 체크 표시(tick mark)가 가시화되는 각각의 도메인에 대한 셀을 구비한다. 도 8은 터치스크린 상에서 마우스 또는 손가락에 의해 제어될 수 있는 포인터를 도시한다. 마우스 버튼의 클릭 또는 더블 클릭 또는 손가락의 탭 또는 더블 탭 또는 길게 누르기(long press)는, 포인터 위치에 있는 도메인이 선택되는지 또는 그렇지 않은지의 여부의 상태를 변경한다. 상태는, 셀 내의 체크 마크의 존재 또는 부재에 의해 나타내어진다.

제3 열은, 각각의 도메인에 대한 셀을 나타내는데, 그 셀은, 선택된 도메인이 주어지면 도메인으로부터의 정보를 사용하여 응답되는 질의의 수에 대한 카운트를 포함한다. 몇몇 실시형태에서, 정확한 질의 응답이 알려져 있는 경우, 인식된 질의의 카운트 및 정확하게 응답된 질의의 카운트에 대해 상이한 열이 사용된다. 몇몇 실시형태에서, 추가적인 열을 사용한 절대 수치 대신, 또는 그에 부가하여, 백분율이 디스플레이된다. 게다가, 몇몇 질의는, 선택되는 도메인의 세트에 대해 모호한다, 즉, 그들은 하나보다 더 많은 도메인에 의해 해석될 수 있다. 이것은 짧은 질의의 경우에 가장 일반적이다. 예를 들면, 질의 "칠면조"는, 날씨 도메인, 음식 도메인, 스포츠 도메인, 맵 도메인, 사실 도메인에 의해 해석될 수 있다. 몇몇 실시형태는, 질의의 모든 모호한 해석에 대해 라벨링된 응답을 제공하는 것에 의해 모호한 질의를 핸들링한다.

다른 실시형태는, 도메인 우선 순위를 사용하여 그리고 질의와 매치하는 가장 높은 우선 순위 도메인을 선택하여, 모호성을 더욱 강력하게 제거한다. 다른 변형예에서, 질의 해석 점수가 사용되고, 자신의 대응하는 문법으로부터 가장 높게 득점하는 해석 점수를 갖는 도메인이 우승하고 응답을 위한 기초를 형성한다. 두 가지 아이디어는 결합될 수 있다. 모든 경우에, 단일 도메인의 카운트에 기여하는 하나의 또는 적은 수의 해석을 더 강력하게 선택하는 것에 의해 모호성이 제거된다. 도메인의 선택의 상태가 변경되면, 이것은 다른 도메인이 응답할 질의의 수를 변경할 수 있다. 몇몇 실시형태는, 도메인의 선택이 수정될 때마다 질의 카운트 수를 동적으로 재계산한다. 도 8의 질의 카운트 열에 대안적으로, 또는 추가적으로, 몇몇 실시형태는, 각각의 도메인이 정보를 제공할 수 있는 테스트 질의의 총 수 및 인에이블된 도메인을 사용하여 정확하게 응답될 수 있는 테스트 질의의 증분 개수(incremental number) 둘 모두를 나타낸다.

제4 열은 도메인 질의에 대한 회계를 위한 가격 책정 모델을 나타낸다. 테이블(80)은, 질의당 고정 가격 기반의, 간단한 종류의 가격 책정 모델을 나타낸다. 나타내어진 가격은, 질의당 0(무료 도메인의 경우)에서부터 5￠($ .05 US 달러)까지의 범위에 이른다. 몇몇 실시형태는, 시간 윈도우 내에서의 적중의 수의 함수로서의 구분적 선형 또는 공식 기반의 모델과 같은, 더 복잡한 가격 책정 모델을 지원한다. 반복 시간 윈도우(예를 들면, 캘린더 달(month)) 뿐만 아니라, 슬라이딩 시간 윈도우(예를 들면, 지난 30일)가 사용될 수도 있다. 더 복잡한 가격 책정 모델을 지원하는 실시형태는, 가격 책정 모델 열에 가격 책정 모델 그 자체를 나타내지 않을 수도 있다; 대신, 도메인에 대한 가격 책정 모델 셀에 대한 클릭 또는 탭이, 도메인의 가격 책정 모델을 나타내며 그것을 편집하는 것을 허용하는 상이한 디스플레이 뷰, 예컨대 팝업 윈도우에 대한 액세스를 부여할 수도 있다.

제5 열은, 각각의 도메인에 대한, 질의의 테스트 세트 내의 모든 질의에 대한 응답에 기초하여, 대응하는 도메인 공급자에게 지불될 금액의 양을 나타낸다. 과금은, 자신의 정보가 응답에서 사용되는 모든 도메인에 대해 이루어진다. 테이블(80)에서 나타내어지는 간단한 가격 책정 모델의 경우, 각각의 도메인에 대한 도메인 비용은, 질의 카운트와 질의당 비용을 곱한 값이다. 복합 질의를 허용하는 실시형태에서, 단일의 질의는 다수의 도메인에 적중할 수도 있다. 예를 들면, "미국 대통령의 나이는 얼마이지"는, 정치 정보를 제공하는 도메인 및 개인 정보를 제공하는 도메인 둘 모두에 적중할 수도 있을 것이다. 응답에서 모호성을 허용하는 실시형태에서, 단일의 질의는 상이한 이유 때문에 다수의 도메인에 적중할 수도 있다. 경쟁하는 해석에 따라 다수의 응답이 주어진다. 도메인이 선택되거나 또는 선택 해제될 때마다 질의 카운트가 변할 수 있다는 동일한 이유 때문에, 도메인 비용도 또한 그에 따라 변할 수 있다.

테이블(80)에서 가장 아래쪽의 완전한 행은, 어떠한 도메인과도 매치하지 않는 질의의 수를 나타낸다. 그러한 질의는 카운트될 수 있지만, 그러나, 다른 열은 적용 불가능하다.

그 아래에서, 행은 두 개의 집계(tally)를 나열한다. 첫 번째는, 도메인의 현재 선택에서 응답을 수신하는 질의의 비율을 나타낸다. 테이블(80)에서, 음식 도메인 및 맵 도메인은 인에이블되지 않는다. 그들 각각은, 각각, 1955 및 764 개의 질의에 응답할 수 있었다. 그들, 및 임의의 도메인에 의해 해석될 수 없는 633 개의 질의와 함께, 테스트 질의의 73 %가 응답을 성공적으로 수신한다.

마지막 집계 셀은, 인에이블된 도메인에 대한 총 도메인 비용을 디스플레이한다. 이 숫자는, VA 개발자가 도메인을 인에이블 또는 디스에이블함에 따라 동적으로 변한다. 일반적으로, VA 개발자가 더 많은 도메인을 인에이블할수록, 질의는 더 많이 성공할 것이고 총 비용은 더 높아질 것이다. 더 높은 질의 성공률이 일반적으로 만족스러운 유저 경험을 제공하기 때문에, 그러한 동적으로 정보를 주는 디스플레이 뷰는, VA 개발자가, 유저 만족도와 도메인 사용량에 대한 예산 사이에서 정보에 근거한 절충(informed trade-off)을 행하는 것을 허용한다.

상기의 모든 방법에서, 테스트 질의 또는 테스트 질의의 그룹은 다중성(multiplicity)을 부여받을 수 있다. 테스트 질의의 세트를 보여주는 도 2로 돌아가서, 예를 들면, 질의 "날씨가 어때"가 3 번 발생한다는 것을 유의한다. 생산 환경에서, VA 개발자는 훨씬 더 많은 데이터의 세트에 대한 현장 통계치(field statistics)에 액세스할 수도 있을 것이고, "날씨가 어때"에 대한 월별 카운트는 수백만 개가 될 수 있다. 동일한 도메인에 대해 많은 수의 질의를 갖는 것은, 비선형 대량 매입 할인(volume discount)을 합리적인 비즈니스 협정(business arrangement)으로 만든다. 이것은, 플랫폼이 정적인 또는 낮은 빈도로만 변하는 데이터에 대한 결과를 캐시하는 경우 특히 그렇다. 대안적으로, 현장으로부터의 본격적인 통계치(full-blown statistics)가 없는 경우, 작은 테스트 세트는 다음에 기초할 수도 있을 것이다: (1) 질의의 작은 샘플로부터의 통계치; 또는 (2) 아마도, 현장으로부터의 데이터로부터 부분적으로 영감을 받는, 질의의 큐레이팅된 세트(curated set). 어느 경우든, 테스트 세트 카운트는, VA 개발자가 비선형 대량 매입 할인의 효과를 관찰하기 위해 변경할 수 있는 가변 인자에 의해 승산될 수 있다.

몇몇 실시형태, 특히 많은 수의 도메인을 갖는 실시형태는, VA 개발자가 제한된 디스플레이 공간 내에서 상이한 도메인을 보는 것을 허용하는 스크롤 바를 제공한다. 몇몇 실시형태는 VA 개발자가 도메인의 목록을 하나 또는 임의의 수의 열의 기준에 따라 소팅하는 것을 허용한다. 그렇게 하기 위한 하나의 방식은, 목록이 소팅되게 하는, 열에 대한 클릭 또는 탭을 수신하는 것에 의한다. 더구나, 목록이 이미 소팅된 열에 대한 클릭은, 목록으로 하여금 반대 순서로 소팅되게 한다. 몇몇 실시형태는, 각각의 도메인이 인에이블되는지 또는 아닌지의 여부; 가격 책정 모델의 범위; 도메인 비용의 범위:에 의해 도메인의 목록을 필터링하는 것과 같은, 필터 기준을 VA 개발자가 입력할 박스를 제공한다.

모든 가상 비서는 VA 개발자에 대한 상이한 프로젝트이다. 몇몇 실시형태에서, 각각의 프로젝트는 개별적으로 열리거나 열람될 수 있고, 특정한 가상 비서에 대한 도메인 테이블을 구체적으로 디스플레이할 것이다. 플랫폼의 몇몇 실시형태는, VA 개발자가, 계정을 만들고 로그인하여 그들의 가상 비서 프로젝트를 구성하는 것을 허용한다. 플랫폼 관리자는, 상이한 VA 개발자에게 어떤 도메인이 보일지를 그리고 계정의 조건의 함수로서 프로젝트에 대해 작업하기 위해 VA 개발자가 어떤 제어 및 도구에 액세스할 수 있는지를 제어할 수 있다.

비용 누계 차트

도 9는 실시형태에 따른 비용 누계 차트(90)의 디스플레이 뷰를 도시한다. 차트는, 타이틀 "도메인당 소비되는 누적 금액"을 갖는다. 차트는 비용에 대한 수직 축 및 도메인에 대한 수평 축을 갖는다. 몇몇 실시형태는 수직 축을 따라 도메인을 그리고 수평 축을 따라 비용을 도시한다. 전자는 일반적으로, 적은 수의 도메인이 비용의 대부분을 떠맡는 가상 비서의 경우에 더 좋고, 후자는 일반적으로, 많은 수의 도메인을 갖는 가상 비서의 경우에 더 좋다.

시각적 데이터를 제시하는 많은 유용한 방식이 있다. 예를 들면, Edward Tufte의 저서, 예컨대 Envisioning Information 및 The Visual Display of Quantitative Information은, 그 주제에 대한 정보를 제공한다. 흑색 및 백색 라인 묘화가 이상적이지는 않지만 예시를 하기에는 충분할 수 있다. 도 9의 흑색 및 백색 라인 묘화에서 도시되는 실시형태에서, 일곱 개의 도메인이 수평 축 상에서 묘사된다. 중첩하는 단어 없이 판독 가능성을 향상시키기 위해, 도메인의 이름은 비스듬히 쓰이고, 축과 우측 정렬된다. 인에이블된 도메인의 이름은 굵은 글꼴로 나타내어지고 디스에이블된 도메인의 이름은, 괄호 사이에서 나타내어지며 더 작은 글꼴로 쓰여진다. 무료인 도메인은, 도메인 이름 다음에 "(f)"가 나타내어진다. 외부 동적 정보에 대한 액세스가 필요 없는 도메인은 통상적으로 무료인데, 그 이유는 플랫폼 공급자가 정보를 캐시하고 저렴한 비용으로 그것을 취출할 수 있기 때문이다.

각각의 도메인에 대한 열에서, 테스트 질의의 세트에 응답하기 위한 도메인 비용에 비례하는 높이를 가진 막대(bar)는, 세트 내의 모든 질의에 응답하는 총 비용에 대한 도메인의 기여도를 나타낸다. 각각의 도메인에 대한 막대의 하부는, 이전 도메인의 막대의 상부의 높이에 배치된다. 비용이 들지 않는 도메인은, 수평선으로 나타나는 제로 높이의 막대를 갖는다. 수직 축은 누적 비용의 값 및 각각의 막대의 상부의 높이에 있으며, 수직 축으로부터 라벨의 높이에 있는 막대까지 연장하는 수평의 점선으로 라벨링된다. 플랫폼은, VA 개발자가, 이용 가능한 도메인을, 다양한 기준에 의해, 예컨대 알파벳 순서의 이름에 의해; 그들이 매치시키는 질의 수에 의해; 질의당 그들의 비용에 의해; 또는 그들의 총 비용에 의해, 자동적으로 소팅하는 것에 의해, 도메인의 순서를 변경하는 것을 쉽게 만든다. 또한, 플랫폼의 인터페이스는 유저가 특정한 소팅으로부터의 순서를 고정하는 것을 허용하지만, 선택은 변하고, 그렇지 않으면 순서가 변할 것이다. 도메인을 수동으로 재정렬하는 것도 또한 가능하다. 몇몇 실시형태는 또한, 다양한 기준에 의해, 예컨대 인에이블된 도메인, 또는 선택된 디스에이블된 도메인만을 나타내는 것에 의해, 도메인의 목록을 필터링하는 것을 가능하게 한다.

도 9의 디스플레이 뷰는 또한, 클릭되거나 또는 탭되거나 또는 달리 적절하게 활성화되면, 도메인이 인에이블되는지의 여부의 상태를 토글하는 포인터를 포함한다. 따라서, VA 개발자는 도메인을 빠르고 쉽게 인에이블 및 디스에이블하여 테스트 세트 내의 질의에 응답하기 위한 총 비용에 대한 자신의 효과를 확인할 수 있다. 도 10은, ((음식)) 상에서 포인터를 사용하여 클릭하는 것에 의해 디스에이블된 음식 도메인이 인에이블된 이후, 도 9의 것과 동일한 가상 비서에 대한 비용 누계 차트(100)의 디스플레이 뷰를 도시한다.

도 10에서, 도메인은 도메인에 적중한 질의의 수에 의해 소팅된다. 비록 음식 도메인이 (그것이 더 높은 비용 가격 책정 모델을 가지기 때문에), 날씨 도메인보다, 테스트 세트에 응답하기 위한 총 집성 비용에 대한 더 큰 기여자이지만, 테스트 세트가 날씨 질의보다 더 적은 음식 질의를 가지기 때문에, 그것은 목록에서 두 번째로 도시된다.

몇몇 실시형태는 비용 축을 선형 스케일로 디스플레이하고 몇몇 실시형태는 그것을 대수적으로(logarithmically) 나타낸다. 몇몇 실시형태는, 인에이블된 도메인에 의해 응답되는 질의의 누적 개수(또는 테스트 세트의 분율 또는 백분율)를 나타내는 축을 차트의 우측에서 나타낸다. 그러한 축은, 비용 스케일이 규칙적(선형 또는 대수)인 경우, 반드시 불규칙한 스케일을 가질 것이다. 대안적으로, 응답되는 질의의 규칙적(선형 또는 대수)인 디스플레이는, 불규칙한 간격을 갖는 비용에 대해 대응하는 평행 축을 가질 수 있다.

질의 적중 히스토그램

도 11은, 실시형태에 따른, 도메인당 질의 적중의 히스토그램(110)을 갖는 디스플레이 뷰를 도시한다. 히스토그램은, 적중의 수직 축 및 도메인을 나타내는 수평 축을 가지면서 타이틀 "도메인에 적중하는 질의의 히스토그램"을 갖는다. 도메인 적중은, 도메인으로부터의 정보를 가지고 응답되는 질의를 가리킨다. 도 11의 히스토그램(110)은, 도메인 축을 도메인의 이름으로 라벨링하지 않는데, 그 이유는, 이름에 적합할 수 있는 도메인이 너무 많기 때문이다. 대안적으로, 도메인이 수직 축 상에서 나타내어질 수 있고 적중이 수평 축 상에서 나타내어질 수 있다. 히스토그램 차트가 충분히 길거나 또는 VA 개발자가 그것의 엔트리를 스크롤하는 것을 허용하는 경우, 도메인 이름을 나열하고 적중의 수를 나타내는 것이 가능하다.

히스토그램(110)은 원활한 라인을 가지지만, 도메인에 걸쳐 계단식 표현도 또한 작용할 것이다. 히스토그램(110)이 도메인의 이름으로 수평축을 라벨링하지 않지만, 임계치를 초과하는 가격 책정 모델을 갖는 도메인을 나타내기 위해 "$" 심볼을 나타낸다. 몇몇 실시형태에서, 임계치는 제로(무료 및 선불 도메인을 나타냄)이다. 몇몇 실시형태는, 적절한 가격의 도메인 대 고가의 도메인을 보기 위해 VA 개발자가 임계치를 구성하는 것을 가능하게 한다.

몇몇 경우에, 심지어 적은 수의 적중을 갖는 도메인이 유저 경험에 불균형한 이익을 제공할 수 있다. 예를 들면, 분실한 전화기의 위치를 찾을 수 있는 자동차 가상 비서에서 이용 가능한 도메인은 거의 사용되지 않을 것이지만 그러나, 그것이 필요로 되는 드문 경우에 유저가 아주 많이 고마워할 것이다. 그것은 차에 대한 강력한 판매 포인트가 될 것이다. 그 도메인 정보에 액세스하는 것이, VA 개발자에 대해, 사용량당, 아주 고가이더라도, 그것은, 더 많은 차를 판매하기 위해, 비용의 충분한 가치가 있을 것이다.

몇몇 실시형태는, VA 개발자가, 유저 경험에 특히 높은 가치를 갖는 것으로, 소정의 도메인을, 예컨대, 스타 심볼로 태깅하는 것을 허용한다. 몇몇 실시형태는 도 11에서와 같은 히스토그램을 나타내는데, 높은 가치의 도메인은 눈에 띄는 컬러 또는 아이콘으로 강조 표시된다.

많은 질의가 하나보다 더 많은 도메인에 의해 해석될 수 있기 때문에, 단일의 도메인을 인에이블 또는 디스에이블하는 것은, 모든 다른 도메인으로부터의 정보를 가지고 응답되는 질의의 수를 변경할 수 있다. 그것은 히스토그램 내에서 도메인을 재정렬하는 효과를 가질 수 있다. 예를 들면, 두 개의 경쟁하는 날씨 도메인이 인에이블되고 제1의 것이 기압을 포함하는 모든 날씨 정보를 제공할 수 있고 제2의 것이 모든 날씨 질문에 대한 디폴트 정보 소스이지만 그러나 그 당시에 기압 정보를 제공할 수 없으면, 도메인 둘 모두가 인에이블된 상태에서는, 제1의 것은 아주 적은 수의 적중을 가질 것이지만(그리고 히스토그램(110)의 우측 근처에 도시될 것이지만) 그러나 제2 도메인이 디스에이블된 상태에서는 제1의 것은 아주 큰 수의 적중을 가질 것이다.

도 12는 도 11에서와 같은 그러나 포인터를 갖는 히스토그램(110)의 디스플레이 뷰를 도시한다. 히스토그램 내의 도메인의 열 위에서 호버링하는 경우, 이동 없이 1초 이후, 플랫폼은 도메인의 이름, 테스트 질의의 세트에 대해 그것이 갖는 적중의 수, 및 테스트 세트의 질의에 응답할 때 도메인을 인에이블되게 하기 위한 총 비용을 나타내는 정보 박스를 팝업한다.

도메인 홍보

도 13은 실시형태에 따른 도메인 테이블(130)을 갖는 디스플레이 뷰를 도시한다. 도 8의 도메인 테이블(80)과 마찬가지로, 도 13의 도메인 테이블(130)은 도메인을 나열한다. 차이점은, 도메인 테이블(130)이, 하나의 이름은 "맵"이고 다른 하나 이름은 "mapPRO"인 두 개의 맵 도메인을 나타낸다는 것이다. 후자는 홍보 도메인이다. 적어도 그것이 테스트 세트에 대한 764 개의 질의 대신 805 개의 질의에 대한 정보를 제공할 수 있기 때문에, 그것은 맵 도메인보다 더 우수한 유저 경험을 제공할 가능성이 있다. 플랫폼은 mapPRO 도메인 및 그 라인의 텍스트를, 그것의 인에이블화 체크 마크 박스 주위에서 강조 표시를 가지면서, 굵은 글꼴로 나타낸다. 이것은 홍보 도메인을 VA 개발자에게 눈에 띄게 나타나게 하여 고려하게 한다.

도 13의 실시형태가 굵은 글꼴 및 강조 표시 박스를 사용하지만, 홍보 도메인을 강조 표시하기 위한 다양한 방법이 가능하다. 예를 들면, 하나 이상의 홍보 도메인은: 개별적으로 나열될 수 있거나; 목록의 상부에 있도록 소팅될 수 있거나; 상이한 컬러 또는 음역을 사용하여 나타내어질 수 있거나; 별과 같은 아이콘을 가지고 나타내어질 수 있거나; 회사 로고와 같은 이미지를 가지고 나타내어질 수 있거나; 또는 애니메이션화될 수 있다. 도메인을 강조 표시하는 이들 수단 중 일부는 조합하여 사용될 수 있다.

도 14는 실시형태에 따른 특정한 테스트 질의를 입력하고 결과를 보기 위한 디스플레이 뷰(140)를 도시한다. 디스플레이 뷰(140)는 텍스트 입력 박스(141)를 포함한다. 가상 비서 개발자는, 물리적 키보드 또는 가상 키보드 또는 다른 적절한 텍스트 입력 박스를 사용하여 텍스트를 입력할 수 있다. 입력된 텍스트는 커서 위치 표시기(142)의 위치에 나타난다. 마이크를 갖는 유저 인터페이스 디바이스의 경우, VA 개발자는 마이크 버튼(143)을 탭 또는 클릭하여 테스트 질의를 말할 수 있다. "질의 말하기(speak your query)"가 가능하다는 것을 VA 개발자에게 통지하기 위해 그것이 처음 호출될 때 안내 항목이 디스플레이에 상에 나타난다.

디스플레이 뷰(140)는 또한 업로드 버튼(144)을 포함한다. 활성화되면, 그것은 유저가 파일을 브라우징하고 플랫폼으로 업로드되도록 그것을 선택하기 위한 대화 박스를 호출한다. 파일에는 단일의 질의 또는 전체 테스트 세트를 포함하는 임의의 수의 질의의 구분된 목록을 포함할 수 있다. 몇몇 실시형태는 VA 개발자가 그들의 그래픽 오퍼레이팅 시스템 또는 브라우저 디스플레이로부터 질의 박스 안으로 파일을 드래그 앤 드랍하는 것 및 파일이 플랫폼으로 자동적으로 업로드되게 하는 것을 가능하게 한다. 업로드 버튼 및 드래그 앤 드랍 업로드의 다양한 구현예는 널리 공지되어 있으며 Javascript(자바스크립트)와 같은 언어의 브라우저 클라이언트 측 스크립트 템플릿에서 쉽게 이용 가능하다.

디스플레이 뷰(140)는 결과 박스(145)를 더 포함한다. 주어진 단일의 입력 질의의 경우, 결과 박스는, 질의에 응답하는 데 필요한 정보를 제공할 수 있는 도메인의 목록을, 도메인의 이름, 가격 책정 모델("Cost(비용)"으로 라벨링됨), 및 도메인이 인에이블된 상태에서 그 질의에 대해 가상 비서가 유저에게 제공할 응답에 대한 열과 함께 디스플레이한다. 몇몇 실시형태에서, 다수의 도메인 공급자는 소스 정보 및 문법을 제공하여 질의에 대해 매우 상이한 응답을 형성할 수 있다. 결과 박스(145)는 네 개의 여행 도메인 공급자의 각각으로부터의 문법 및 정보를 사용하는 가상 비서 응답을 나타낸다. "Trip Booker(트립 부커)" 도메인은 상대적으로 저렴한 비용(질의당 단 1￠을 가지지만, 그러나, 그것이 그 고유의 이름인 "Trip Booker"를 언급하고 정확히 하나의 브랜드의 호텔을 추천한다는 점에서 매우 자기 잇속만 차리는 응답을 갖는다. 아마도, Trip Booker 도메인 공급자 및 호텔 브랜드는 유료 비즈니스 관계를 맺고 있을 것이다. "Travel Mate(트래블 메이트)"도메인은 중간 범위의 비용(질의당 3￠을 가지며 이용 가능한 많은 수의 결과 및 상위 다섯 개의 가장 가능성이 높은 흥미로운 결과의 합리적인 목록을 나타내는 상당히 유용한 응답을 제공한다. "TravelHound(트래블하운드)"도메인은 높은 비용(질의당 8￠을 가지지만, 그러나 발견된 특정한 수의 호텔, 몇몇의 목록, 및 직관적인 음성 인터페이스를 사용하여 목록을 소팅 또는 필터링하는 것에 의해 유저가 훨씬 더 만족스러운 결과를 얻도록 하는 안내를 갖는 단연코 가장 유용한 결과를 제공한다. "Chee-po-tels(치 포 텔스)" 도메인은 값 싼 비용(질의당 단 1￠을 가지지만, 그것의 문법은, 단어 Paris(파리)가 프랑스의 큰 도시를 가리킬 가능성이 가장 높다는 것을 인식하는 대신, 아무런 호텔도 없는 Idaho(아이다호)의 미국 시골 주(state)의 엉뚱한 작은 도시를 가정한다.

도메인의 소팅 순서(예컨대, 가격 책정 모델, 질의 적중의 수, VA 개발자에 의한 별 선택, 질의 응답 타입, 등등)에 관계없이, 플랫폼은 결과를 두 섹션에서 나타낼 수 있다. "Editor's Picks - Sponsored(편집자 추천 - 후원 받음)"이라는 이름의 부제(sub-heading)(146)에 의해 나타내어지는 제1 섹션은, VA 개발자가 선택하면 플랫폼 공급자가 좋아할 하나 이상의 도메인을 나타낸다. 일반적으로, "Editor's Picks(편집자 추천)" 도메인은 도메인 공급자에 의해 후원되는 또는 플랫폼 공급자에 의해 선택되는 도메인인데, 그 이유는 그들이 가상 비서에 의한 더 많은 사용 또는 만족스러운 결과를 권장하기 때문이다. 테스트 질의에 대한 응답을 완료하기 위한 정보를 제공할 수 있는 도메인의 나머지는, "Other(기타)"라는 이름의 부제(147)에 의해 나타내어지는 섹션에서 나타내어진다.

가격 책정 모델

상기에서 사용되는 예는 정보 요청당 1 또는 수 US 센트의 선형 요금의 일반적이지 않은 단순한 가격 책정 모델을 나타낸다. 몇몇 실시형태에서, 획득 및 전달하기에 저렴한 정보에 대한 요청당 비용은, 요청당 1 US 센트보다 훨씬 더 낮을 수 있다. 도 15(a)는 요청당 $ .0005(요청당 .05 ￠와 등가)의 가격을 갖는 예시적인 선형 가격 책정 모델을 보여준다.

업계에서는, 도메인이 가장 높은 해석 점수를 갖는 질의의 수와 관련하여 비선형인 가격 책정 모델을 사용하는 것이 일반적이다. 비선형 타입의 가격 책정 모델의 하나의 예는 등급화된 가격 책정 모델(graduated pricing model)이다. 도 15(b)는 그러한 가격 책정 모델을 나타낸다. 요청당 비용은, 요청의 수가 임계치를 넘어가면 감소한다. 구체적으로는, 한 달 내에 처음 10,000 개의 질의에 경우, 비용은 질의당 $ .0010이다. 요청 수량 10,001 내지 50,000 개의 경우, 비용은 요청당 $ .0005이다. 요청 수량 50,001 내지 250,000의 경우, 비용은 요청당 $ .0002이다. 요청 수량 250,001 및 임의의 다른 것의 경우, 비용은 요청당 $ .0001이다. 질의 카운트는 한 달에 한 번 리셋된다.

몇몇 실시형태에서, 도메인 공급자는, 서빙된(served) 정보 요청에 대한 월별 송장을 플랫폼 공급자에게 전송한다. 몇몇 실시형태에서, 플랫폼 공급자는 정보 요청의 크레디트를 미리 구매한다. 크레디트에 대한 요금은 구매한 수량에 따라 등급화된 가격 책정 구간에서 설정된다. 다양한 실시형태에서, 가입하는 유저, 플랫폼 공급자 또는 도메인 공급자로부터 크레디트를 구매하는 앱 통합기, 송장에 따라 지불하는 임의의 수신측, 또는 서비스에 대해 지불하는 임의의 다른 적절한 방법의 다양한 조합이 존재할 수 있다.

도 15(c)는 비선형 수식 기반의 가격 책정 모델을 도시한다. 많은 수의 정보 요청의 등급화된 구간 대신, 요청당 가격 책정은 수식에 기초한다. 많은 수식이 가능하지만, 도 16의 수식은 다음과 같다.

플랫폼 공급자 또는 도메인 공급자 또는 둘 모두는 지난 30일 동안의 슬라이딩 윈도우를 통해 서빙된 정보 요청의 카운트를 유지한다. 요청당 가격은 요청당 $ .0001의 최소값에, 요청의 수와 역 대수적으로 변하는 비용을 합한 것이다. 이것은, 빈번한 유저에게 대량 매입 할인을 효과적으로 제공한다.

비즈니스 계약을 협상하는 자의 창의력에 의해서만 제한되는, 다양한 다른 비선형 가격 책정 모델이 가능하다.

CRM

도 16(a)는, 회전하는 자기 디스크인 예시적인 비일시적 컴퓨터 판독 가능 매체(161)를 도시한다. 데이터 센터는 일반적으로 자기 디스크를 사용하여 서버 프로세서에 대한 명령어를 포함하는 코드 및 데이터를 저장한다. 비일시적 컴퓨터 판독 가능 매체(161)는, 하나 이상의 컴퓨터에 의해 실행되는 경우, 컴퓨터로 하여금 본원에서 설명되는 방법의 단계를 수행하게 할 명령어를 포함하는 코드를 저장한다. 회전하는 광학 디스크 및 기타 기계적으로 움직이는 저장 매체가 가능하다.

도 16(b)는, 플래시 랜덤 액세스 메모리(random access memory; RAM) 칩인 예시적인 비일시적 컴퓨터 판독 가능 매체(162)를 도시한다. 데이터 센터는 일반적으로 플래시 메모리를 사용하여 서버 프로세서에 대한 코드 및 데이터를 저장한다. 모바일 디바이스는 일반적으로 플래시 메모리를 사용하여 시스템 온칩 디바이스 내의 프로세서에 대한 코드 및 데이터를 저장한다. 비일시적 컴퓨터 판독 가능 매체(162)는, 하나 이상의 컴퓨터에 의해 실행되는 경우, 컴퓨터로 하여금 본원에서 설명되는 방법의 단계를 수행하게 할 명령어를 포함하는 코드를 저장한다. 리드 또는 솔더 볼을 사용하여 패키지화되는 다른 움직이지 않는 저장 매체도 가능하다.

다양한 실시형태에 따른 명령어를 포함하는 코드를 저장하기에, 임의의 타입의 컴퓨터 판독 가능 매체가 적합하다.

서버

서버는 플랫폼 메뉴에서 VA 개발자에게 제공되는 도메인의 데이터베이스를 저장한다. 서버는 또한, 도메인과 관련되는 문법에 대한 코드의 데이터베이스를 저장한다. 서버는 또한, 도메인과 관련되는 가격 책정 모델의 데이터베이스를 저장한다.

도 17(a)는 몇몇 실시형태에 따른 랙 장착형 서버 블레이드 멀티 프로세서 서버 시스템(170)을 도시한다. 그것은, 소프트웨어를 병렬로 실행하는 다수의 네트워크 연결 컴퓨터 프로세서를 포함한다.

도 17(b)는 서버 시스템(170)의 블록도를 도시한다. 그것은, 컴퓨터 프로세서(CPU) 코어(171)의 멀티코어 클러스터 및 그래픽 프로세서(GPU) 코어(172)의 멀티코어 클러스터를 포함한다. 프로세서는, 프로그램 코드 및 데이터 저장을 위해, 보드 레벨 인터커넥트(board-level interconnect)(173)를 통해 랜덤 액세스 메모리(RAM) 디바이스(174)에 연결된다. 서버 시스템(170)은 또한, 프로세서가 인터넷에 액세스하는 것을 허용하기 위한 네트워크 인터페이스(178)를 포함한다. RAM 디바이스(174)에 저장되어 있는 명령어를 실행하는 것에 의해, CPU(171) 및 GPU(172)는 본원에서 설명되는 바와 같은 방법의 단계를 수행한다.

SoC

도 18(a)는 인쇄 회로 기판에 대한 표면 실장 솔더링을 위한 볼 그리드 어레이를 갖는 패키지화된 시스템 온 칩 디바이스(180)의 하부 면을 도시한다. 다양한 칩 구현을 위해, 다양한 패키지 형상 및 사이즈가 가능하다. 시스템 온 칩(System-on-chip; SoC) 디바이스는 본원에서 설명되는 바와 같은 많은 임베딩된 시스템 및 IoT 디바이스 실시형태를 제어한다.

도 18(b)는 시스템 온 칩(180)의 블록도를 도시한다. 그것은, 컴퓨터 프로세서(CPU) 코어(181)의 멀티코어 클러스터 및 그래픽 프로세서(GPU) 코어(182)의 멀티코어 클러스터를 포함한다. 프로세서는, 네트워크 온 칩(183)을 통해, 휘발성 프로그램 및 데이터 저장을 위해 오프 칩 동적 랜덤 액세스 메모리(DRAM) 인터페이스(184)에 그리고 플래시 RAM 비일시적 컴퓨터 판독 가능 매체에서의 컴퓨터 프로그램 코드의 불휘발성 저장을 위해 플래시 인터페이스(185)에 연결된다. SoC(180)는 또한, GUI를 디스플레이하기 위한 디스플레이 인터페이스(186) 및, 상이한 주변장치 디바이스에 대해 필요로 될 때, 다양한 I/O 인터페이스 디바이스에 연결하기 위한 I/O 인터페이스 모듈(187)을 구비한다. I/O 인터페이스는, 다른 것들 중에서도, 터치스크린 센서와 같은 센서, 지오로케이션 수신기, 마이크, 스피커, 블루투스(Bluetooth) 주변장치, 및 USB 디바이스, 예컨대 키보드 및 마우스를 인에이블한다. SoC(180)는 또한, 프로세서가, Wi-Fi, 3G, 4G 롱 텀 에볼루션(long-term evolution; LTE), 5G, 및 다른 무선 인터페이스 표준 라디오뿐만 아니라 이더넷 연결 하드웨어와 같은 유선 또는 무선 연결을 통해 인터넷에 액세스하는 것을 허용하기 위한 네트워크 인터페이스(188)를 포함한다. 인터페이스(184)를 통해 RAM 디바이스에 또는 인터페이스(185)를 통해 플래시 디바이스에 저장되어 있는 명령어를 실행하는 것에 의해, CPU(181) 및 GPU(182)는 본원에서 설명되는 바와 같은 방법의 단계를 수행한다.

추가 고려 사항

기술분야에서 능숙한 실무자는 많은 수정예 및 변형예를 인식할 것이다. 수정예 및 변형예는 개시된 피쳐의 임의의 관련 조합을 포함한다.

다양한 실시형태는 사람 및 머신 중 어느 하나 또는 이들의 조합의 거동을 사용하는 방법이다. 방법 실시형태는, 대부분의 구성 단계가 발생하는 곳이면 어디서나 완료된다. 몇몇 실시형태는 본원에서 설명되는 방법을 위한 그러한 명령어를 저장하도록 배열되는 하나 이상의 비일시적 컴퓨터 판독 가능 매체이다. 머신이 보유하는 것이 무엇이든, 필요한 코드 중 임의의 것을 포함하는 비일시적 컴퓨터 판독 가능 매체가 완전한 실시형태를 유지한다. 몇몇 실시형태는 반도체 칩과 같은 물리적 디바이스; 그러한 디바이스의 논리적 또는 기능적 거동의 하드웨어 기술 언어 표현(hardware description language representation); 및 그러한 하드웨어 기술 언어 표현을 저장하도록 배열되는 하나 이상의 비일시적 컴퓨터 판독 가능 매체이다.

원리, 피쳐, 및 실시형태를 언급하는 본원에서의 설명은, 그들의 구조적 및 기능적 등가물 둘 모두를 포괄한다. 커플링되는 것으로 본원에서 설명되는 엘리먼트는, 하나 이상의 개재하는 엘리먼트와의 직접적인 연결에 의해 또는 그들과 간접적으로 실현 가능한 유효한 관계를 갖는다.

도시되고 설명되는 예는 소정의 발화된 언어(spoken language)를 사용한다. 다양한 실시형태는, 마찬가지로, 다른 언어 또는 언어의 조합에 대해서 동작한다. 도시되고 설명되는 예는 지식의 소정의 도메인을 사용한다. 다양한 실시형태는 다른 도메인 또는 도메인의 조합에 대해 마찬가지로 동작한다.

몇몇 실시형태는 디스플레이 스크린을 갖지 않는 스크린리스(screenless)인데, 예컨대 이어피스(earpiece)이다. 몇몇 실시형태는 자동 판매기와 같이 고정되어 있다. 몇몇 실시형태는 자동차와 같이 이동 가능하다. 몇몇 실시형태는 이동 전화와 같이 휴대형이다. 몇몇 실시형태는 키보드 또는 터치스크린과 같은 수동 인터페이스를 포함한다. 몇몇 실시형태는, 인간 생각을 자연어 표현의 한 형태로서 사용하는 신경 인터페이스(neural interface)를 포함한다.

Claims (17)

1. 장치로서,
   프로세서와,
   상기 프로세서에 연결된 메모리를 포함하되,
   상기 메모리는 자연어 가상 비서(natural language virtual assistant)를 구성하기 위한 플랫폼을 구현하도록 구성된 명령어를 저장하고,
   상기 플랫폼은,
   테스트 질의를 입력하는 수단과,
   다수의 도메인의 세트를 복수의 가능 도메인(plurality of able domains) - 각각은 상기 테스트 질의를 해석할 수 있음 - 으로 필터링하는 수단과,
   도메인의 목록을:
   다수의 홍보 도메인(promoted domain) - 각각의 홍보 도메인은 관련된 가격 책정 모델(pricing model)을 가짐 - 에서 상기 복수의 가능 도메인의 각각을 검색하는 것과;
   상기 다수의 홍보 도메인에서 적어도 하나의 가능 도메인을 찾는 것과;
   상기 홍보 도메인을 포함하여, 상기 도메인의 목록 - 상기 홍보 도메인은 상기 목록 내에서 강조 표시됨 - 을 제시하는 것;
   에 의해 제시하는 수단을 포함하되,
   앱 개발자는 상기 자연어 가상 비서에 포함시키기 위한 홍보 도메인을 식별할 수 있는
   장치.
2. 제1항에 있어서,
   상기 플랫폼은,
   유저 질의를 수신하는 수단과,
   상기 홍보 도메인에 따라 상기 유저 질의를 해석하고 응답을 제공하는 수단과,
   상기 응답을 제공하는 것과 관련되는 요금 - 상기 요금은 상기 홍보 도메인과 관련되는 상기 가격 책정 모델에 따라 계산됨 - 을 계산하는 수단을 더 포함하는
   장치.
3. 앱에서 가상 비서 도메인의 통합을 제공하는 방법으로서,
   앱 통합기(app integrator)로부터, 테스트 질의를 수신하는 단계와,
   복수의 도메인 - 상기 복수의 도메인 중 적어도 하나는 상기 앱 통합기에 대한 비용을 가짐 - 에서 상기 테스트 질의를 해석하는 단계와,
   앱 개발자에게, 상기 테스트 질의를 해석할 수 있는 도메인의 서브세트를 나타내고, 각각의 나타내어진 도메인에 대해, 상기 테스트 질의에 응답하기 위해 상기 나타내어진 도메인을 사용하기 위한 상기 비용을 상기 앱 통합기에게 나타내는 단계를 포함하는
   앱에서 가상 비서 도메인의 통합을 제공하는 방법.
4. 제3항에 있어서,
   상기 앱 통합기로부터, 제2 테스트 질의를 수신하는 단계와,
   상기 복수의 도메인에서 상기 제2 테스트 질의를 해석하는 단계와,
   비선형 가격 책정 모델에 따라 상기 테스트 질의 및 상기 제2 테스트 질의에 응답하는 데 각각의 도메인을 사용하기 위한 비용을 계산하는 단계를 더 포함하는
   앱에서 가상 비서 도메인의 통합을 제공하는 방법.
5. 앱에서 가상 비서 도메인의 통합을 제공하는 방법으로서,
   앱 통합기로부터, 다수의 테스트 질의를 수신하는 단계와,
   상기 다수의 테스트 질의로부터의 각각의 테스트 질의를 복수의 도메인 - 상기 복수의 도메인 중 하나 이상의 도메인은 가격 책정 모델에 따른 상기 앱 통합기에 대한 비용을 가짐 - 의 각각에서 해석하여, 각각의 테스트 질의에 대해, 각각의 테스트 질의가 가장 높은 해석 점수를 갖게 되는 도메인을 결정하는 단계와,
   상기 다수의 테스트 질의에 대한 총 집성 비용을 계산하기 위해, 비용을 갖는 도메인이 가장 높은 해석 점수를 가졌던 상기 질의에 상기 가격 책정 모델을 적용하는 단계를 포함하는
   앱에서 가상 비서 도메인의 통합을 제공하는 방법.
6. 제5항에 있어서,
   도메인당 비용을 계산하는 단계를 더 포함하는
   앱에서 가상 비서 도메인의 통합을 제공하는 방법.
7. 제5항에 있어서,
   특정한 도메인에 대한 상기 가격 책정 모델은, 상기 특정한 도메인이 가장 높은 해석 점수를 갖는 질의의 수에 대하여 비선형적인
   앱에서 가상 비서 도메인의 통합을 제공하는 방법.
8. 자연어 가상 비서에 포함시키기 위한 도메인을 구성하기 위한 플랫폼 시스템으로서,
   다수의 테스트 질의를 입력하기 위한 수단과,
   상기 자연어 가상 비서에 포함시키기 위한 도메인의 선택을 입력하기 위한 수단과,
   상기 자연어 가상 비서에 포함시키기 위해 도메인의 메뉴로부터 어떤 도메인이 선택되는지를 보여주는 디스플레이 뷰와,
   집성 비용 중, 상기 자연어 가상 비서에 포함시키기 위해 선택되는 상기 도메인을 사용하여 상기 다수의 테스트 질의에 응답하기 위해 상기 자연어 가상 비서에 대해 과금될 비용 성분 - 각각의 비용 성분은 상기 도메인의 메뉴로부터 선택되는 도메인에 기인함 - 을 보여주는 디스플레이 뷰를 포함하되,
   상기 자연어 가상 비서에 포함시키기 위한 도메인의 조합의 선택은 상기 테스트 질의에 응답하기 위한 상기 집성 비용이 원하는 예산 내에 있도록 구성가능한
   플랫폼 시스템.
9. 제8항에 있어서,
   상기 자연어 가상 비서에 포함시키기 위해 선택되는 각각의 도메인에 의해 상기 테스트 질의 중 몇 개가 대답을 받을 것인지를 나타내는 히스토그램을 보여주는 디스플레이 뷰를 더 포함하는
   플랫폼 시스템.
10. 제8항에 있어서,
    상기 자연어 가상 비서에 포함시키기 위해 상기 도메인의 메뉴로부터 어떤 도메인이 선택되는지를 보여주는 상기 디스플레이 뷰는 적어도 하나의 홍보 도메인을 다른 도메인과 상이한 방식으로 디스플레이하는
    플랫폼 시스템.
11. 제8항에 있어서,
    상기 자연어 가상 비서에 포함시키기 위해 상기 도메인이 선택되면, 적어도 하나의 도메인의 비용 성분이 상기 도메인이 응답할 테스트 질의의 수에 대하여 비선형적으로 변하는
    플랫폼 시스템.
12. 컴퓨터 실행가능 명령어를 포함하는 컴퓨터 판독가능 저장 매체로서,
    상기 컴퓨터 실행가능 명령어는, 프로세서에 의해 실행되는 경우, 상기 프로세서로 하여금, 가상 비서를 구성하기 위한 플랫폼 시스템을 구현하게 하되,
    상기 플랫폼 시스템은,
    상기 가상 비서에 포함시키기 위한 도메인을 선택하기 위한 서버 호스팅 플랫폼(server-hosted platform)과,
    선택 가능한 다수의 도메인 및 도메인 공급자에게 요청을 하기 위한 문법과,
    상기 플랫폼 시스템과는 독립적인 임베딩된 시스템 내의 프로세서에 의해 실행될 때, 인터프리터 기능으로 하여금, 로컬 도메인에 대한 질의에 응답하게 하는 코드를 내보내는(export) 수단을 포함하는
    컴퓨터 판독가능 저장 매체.
13. 제12항에 있어서,
    상기 플랫폼 시스템은,
    테스트 질의의 세트를 수신하는 수단과,
    정해진 도메인의 선택에 대해 상기 테스트 질의의 세트 내의 상기 질의에 응답하기 위한 비용을 나타내도록 인에이블되는 디스플레이 뷰를 더 포함하는
    컴퓨터 판독가능 저장 매체.
14. 제12항에 있어서,
    상기 플랫폼 시스템은 선택 가능한 상기 도메인과 관련되는 다수의 가격 책정 모델을 더 포함하는
    컴퓨터 판독가능 저장 매체.
15. 컴퓨터로 구현되는 방법으로서,
    플랫폼에 의해, 도메인을 수신하는 단계와,
    상기 플랫폼에 의해, 상기 수신된 도메인 내의 문법적 표현법(grammatical phrasing)을 식별하는 제1 도메인 문법을 생성하는 단계와,
    가상 비서에 포함시키기 위해 상기 도메인이 선택되기 이전에, 상기 플랫폼에 의해, 상기 도메인 문법을 상기 도메인에 관련시키는 단계를 포함하는
    컴퓨터로 구현되는 방법.
16. 제15항에 있어서,
    상기 도메인을 사용하기 위한 질의당 비용을 식별하는 가격 책정 모델을 상기 도메인과 관련시키는 단계를 더 포함하는
    컴퓨터로 구현되는 방법.
17. 제15항에 있어서,
    테스트 질의의 세트를 수신하는 단계와,
    상기 가상 비서에 포함시키기 위한 도메인의 선택을 수신하는 단계와,
    상기 도메인의 선택이 주어지면, 상기 세트 내의 상기 질의에 응답하기 위한 비용을 보여주는 디스플레이 뷰를 생성하는 단계를 더 포함하는
    컴퓨터로 구현되는 방법.

Images