專利名稱：用于混合語義驅動和狀態(tài)驅動對話的開發(fā)框架的制作方法
技術領域：
本發(fā)明一般涉及使得開發(fā)者能夠有效地混合給定應用程序內不同類型的對話的開發(fā)框架，尤其涉及結合了語義驅動和狀態(tài)驅動對話兩者的應用程序的開發(fā)。
背景技術：
支持通過語音用戶接口(VUI)的用戶交互的應用程序在本領域中是公知的。在開發(fā)過程中，這些類型的應用程序可以在提供對基本資源的訪問的低級應用程序接口(API)框架上創(chuàng)作。例如，已知電話應用程序是在包括對諸如但不必限于電話基礎結構、語音識別資源和語音合成資源等資源支持的低級API框架上創(chuàng)作的。
從應用程序開發(fā)者的觀點來看，創(chuàng)作直接以所描述的低級API資源為目標的代碼的過程相對繁瑣和勞動密集型是很普通的。已知較高級構造向低級資源提供了更直觀的接口。在某些情況下，較高級構造用作擔當到低級API資源的接口的API框架形式的對話創(chuàng)作模型的創(chuàng)建的基礎，由此允許簡化應用程序代碼的生成。包括在較高級API框架中的對象被配置成支持各種不同的開發(fā)體驗。
該開發(fā)過程的結果是生成便于若干不同可能的格式之一的用戶系統(tǒng)對話的應用程序。某些對話是系統(tǒng)驅動(或系統(tǒng)發(fā)起)的對話。在這一類對話的一個示例中，向與電話應用程序接口的用戶呈現(xiàn)“歡迎來到我的支持應用程序，請輸入您的產品標識號”形式的口頭語句。在這一情況下，在完成所請求的任務之前(即，輸入有效的產品標識號)，一般不會采取任何動作。系統(tǒng)要求特定的信息，有時候該信息是特定的格式。由此，系統(tǒng)驅動的對話一般是很受限的。
某些對話是用戶驅動(或用戶發(fā)起)的對話。在這一類對話的一個示例中，向與電話應用程序接口的用戶呈現(xiàn)“歡迎來到我的支持應用程序，現(xiàn)在我能如何幫助您？”形式的口頭語句。響應于這一類型的語句，用戶一般可說任何話語，諸如“我的機器有問題”或“我希望退貨”。系統(tǒng)然后被配置成標識用戶詢問的特性并相應地應答，例如“您有收據嗎？”。系統(tǒng)確定用戶詢問中的關鍵信息是什么，然后相應地應答。
支持語義驅動的對話的開發(fā)框架一般更多地是用戶驅動而非系統(tǒng)驅動的。當創(chuàng)作語義驅動對話的一部分時，開發(fā)者一般指定多個域中的哪一個要通過從系統(tǒng)用戶獲得適當的信息來填充。以某些方式，語義驅動格式類似于具有要由用戶填充的某些域的圖形用戶界面(GUI)應用程序中的表單。并非指定通過這些域的預定路徑(A→B→C等)，而是指定某些對話節(jié)點或元素以根據其它域的特定狀態(tài)來作出反應。例如，給定的對話節(jié)點A被指定為如果域C為空時則活動。多個依存關系也是可能的，例如，給定對話節(jié)點被指定為如果域A、B和C為空但域E被填充且確認時活動。某些域可被設為要求系統(tǒng)用戶確認其內容是準確的。在每一用戶-機器交互之后，在語義驅動對話框架內確定哪一或哪些對話節(jié)點接著應該是活動的。
支持狀態(tài)驅動對話的開發(fā)框架一般更多地是系統(tǒng)驅動而非用戶驅動的。狀態(tài)驅動對話過程內的交互流程比語義驅動對話交互更為預定。決策一般遵循從一個元素到下一元素的預定路徑。例如，對第一特定信息項作出請求。作為響應，從用戶接收信息。評估所接收到的信息是否值得信任。如果否，則執(zhí)行確認過程。如果是，則系統(tǒng)請求預定的第二信息項。
在狀態(tài)驅動對話中，用戶一般沒有辦法比當前系統(tǒng)正要求的超前更多的信息。在每一步驟，系統(tǒng)一般決定下一步要做什么。通常開發(fā)者以流程圖的形式來圖形地表示狀態(tài)驅動對話。與語義驅動對話不同，該對話不會根據用戶提供什么作為輸入而來回跳轉。
上述提供到低級API資源的接口的較高級API框架可以被配置成主要支持語義驅動對話。這使得開發(fā)者能夠創(chuàng)作非常靈活和自然的對話。這一配置的一個缺點是簡單的、系統(tǒng)驅動的對話創(chuàng)作變?yōu)橄鄬щy的任務。
較高級API可替換地被配置成主要支持狀態(tài)驅動對話?，F(xiàn)在將對話狀態(tài)與條件鏈接(例如，一旦完成了狀態(tài)A，則評估哪一條件為真且跟隨該路徑到下一狀態(tài))變得很容易。這一類對話開發(fā)易于可視化和創(chuàng)作。然而，缺點是所得的對話對應用程序的用戶而言既不自然也不靈活。

發(fā)明內容
本發(fā)明的實施例涉及包含在一個或多個計算機可讀介質中的應用程序接口。該接口包括被配置成便于開發(fā)應用程序內的第一類對話的第一對話容器。還包括了被配置成便于開發(fā)應用程序內的第二類對話的第二對話容器。


圖1是其中可實現(xiàn)本發(fā)明的一個說明性實施例的框圖。
圖2是示出系統(tǒng)體系結構的高級特征的示意框圖。
圖3是API框架的一部分的示意框圖。
具體實施例方式
I.示例性環(huán)境在詳細討論本發(fā)明的實施例之前，將討論其中可實現(xiàn)各實施例及其相關聯(lián)的系統(tǒng)的示例性計算環(huán)境。
圖1示出了適合在其中實現(xiàn)本發(fā)明的實施例及其相關聯(lián)的系統(tǒng)的計算系統(tǒng)環(huán)境100的一個示例。計算系統(tǒng)環(huán)境100僅為合適的計算環(huán)境的一個示例，并非對本發(fā)明的使用范圍或功能提出任何局限。也不應將計算環(huán)境100解釋為對所示的任一組件或其組合具有任何依賴或需求。
本發(fā)明可以使用眾多其它通用或專用計算系統(tǒng)環(huán)境或配置來操作。適用于本發(fā)明的眾所周知的計算系統(tǒng)、環(huán)境和/或配置包括但不限于，個人計算機、服務器計算機、手持式或膝上設備、多處理器系統(tǒng)、基于微處理器的系統(tǒng)、機頂盒、可編程消費者電子設備、網絡PC、小型機、大型機、電話系統(tǒng)、包括任一上述系統(tǒng)或設備的分布式計算環(huán)境等等。
本發(fā)明可以在諸如由計算機執(zhí)行的程序模塊等計算機可執(zhí)行指令的一般上下文環(huán)境中描述。一般而言，程序模塊包括例程、程序、對象、組件、數據結構等等，它們執(zhí)行特定的任務或實現(xiàn)特定的抽象數據類型。本發(fā)明被設計成在分布式計算環(huán)境中實踐，其中，任務由通過通信網絡連接的遠程處理設備來執(zhí)行。在分布式計算環(huán)境中，程序模塊可以位于包括存儲器存儲設備的本地和遠程計算機存儲介質中。由程序和模塊執(zhí)行的任務在下文借助附圖來描述。本領域的技術人員可以將該描述和附圖實現(xiàn)為處理器可執(zhí)行指令，該指令可以被寫入任何形式的計算機可讀介質中。
參考圖1，用于實現(xiàn)本發(fā)明的示例性系統(tǒng)包括計算機110形式的通用計算設備。計算機110的組件可包括，但不限于，處理單元120、系統(tǒng)存儲器130以及將包括系統(tǒng)存儲器在內的各類系統(tǒng)組件耦合至處理單元120的系統(tǒng)總線121。系統(tǒng)總線121可以是若干種總線結構類型的任一種，包括存儲器總線或存儲器控制器、外圍總線以及使用各類總線體系結構的局部總線。作為示例而非局限，這類體系結構包括工業(yè)標準體系結構(ISA)總線、微通道體系結構(MCA)總線、增強ISA(EISA)總線、視頻電子技術標準協(xié)會(VESA)局部總線以及外圍部件互連(PCI)總線，也稱為Mezzanine總線。
計算機110通常包括各種計算機可讀介質。計算機可讀介質可以是可由計算機110訪問的任一可用介質，包括易失性和非易失性介質、可移動和不可移動介質。作為示例而非局限，計算機可讀介質包括計算機存儲介質和通信介質。計算機存儲介質包括以用于儲存諸如計算機可讀指令、數據結構、程序模塊或其它數據等信息的任一方法或技術實現(xiàn)的易失性和非易失性，可移動和不可移動介質。計算機存儲介質包括但不限于，RAM、ROM、EEPROM、閃存或其它存儲器技術、CD-ROM、數字多功能盤(DVD)或其它光盤存儲、磁盒、磁帶、磁盤存儲或其它磁存儲設備、或可以用來儲存所期望的信息并可由計算機110訪問的任一其它介質。
通信介質通常具體化為諸如載波或其它傳輸機制的已調制數據信號中的計算機可讀指令、數據結構、程序模塊或其它數據，并包括任一信息傳送介質。術語“已調制數據信號”指以對信號中的信息進行編碼的方式設置或改變其一個或多個特征的信號。作為示例而非局限，通信介質包括有線介質，如有線網絡或直接連線連接，以及無線介質，如聲學、RF、紅外和其它無線介質。上述任一的組合也應當包括在計算機可讀介質的范圍之內。
系統(tǒng)存儲器130包括以易失性和/或非易失性存儲器形式的計算機存儲介質，如只讀存儲器(ROM)131和隨機存取存儲器(RAM)132?；据斎?輸出系統(tǒng)133(BIOS)包括如在啟動時幫助在計算機110內的元件之間傳輸信息的基本例程，通常儲存在ROM 131中。RAM 132通常包含處理單元120立即可訪問或者當前正在操作的數據和/或程序模塊。作為示例而非局限，圖1示出了操作系統(tǒng)134、應用程序135、其它程序模塊136和程序數據137。
計算機110也可包括其它可移動/不可移動、易失性/非易失性計算機存儲介質。僅作示例，圖1示出了對不可移動、非易失性磁介質進行讀寫的硬盤驅動器141、對可移動、非易失性磁盤152進行讀寫的磁盤驅動器151以及對可移動、非易失性光盤156，如CD ROM或其它光介質進行讀寫的光盤驅動器155。可以在示例性操作環(huán)境中使用的其它可移動/不可移動、易失性/非易失性計算機存儲介質包括但不限于，磁帶盒、閃存卡、數字多功能盤、數字錄像帶、固態(tài)RAM、固態(tài)ROM等等。硬盤驅動器141通常通過不可移動存儲器接口，如接口140連接到系統(tǒng)總線121，磁盤驅動器151和光盤驅動器155通常通過可移動存儲器接口，如接口150連接到系統(tǒng)總線121。
上文討論并在圖1示出的驅動器及其關聯(lián)的計算機存儲介質為計算機110提供了計算機可讀指令、數據結構、程序模塊和其它數據的存儲。例如，在圖1中，示出硬盤驅動器141儲存操作系統(tǒng)144、應用程序145、其它程序模塊146和程序數據147。注意，這些組件可以與操作系統(tǒng)134、應用程序135、其它程序模塊136和程序數據137相同，也可以與它們不同。這里對操作系統(tǒng)144、應用程序145、其它程序模塊146和程序數據147給予不同的標號來說明至少它們是不同的副本。
用戶可以通過輸入設備，如鍵盤162、話筒163和定位設備161(諸如鼠標、跟蹤球或觸摸板)向計算機110輸入命令和信息。其它輸入設備(未示出)可包括操縱桿、游戲墊、圓盤式衛(wèi)星天線、掃描儀等等。這些和其它輸入設備通常通過耦合至系統(tǒng)總線的用戶輸入接口160連接至處理單元120，但是也可以通過其它接口和總線結構連接，如并行端口、游戲端口或通用串行總線(USB)。監(jiān)視器191或其它類型的顯示設備也通過接口，如視頻接口190連接至系統(tǒng)總線121。除監(jiān)視器之外，計算機也可包括其它外圍輸出設備，如揚聲器197和打印機196，它們通過輸出外圍接口195連接。
計算機110可以使用到一個或多個遠程計算機，如遠程計算機180的邏輯連接在網絡化環(huán)境中操作。遠程計算機180可以是個人計算機、手持式設備、服務器、路由器、網絡PC、對等設備或其它常見的網絡節(jié)點，并通常包括許多或所有相對于計算機110所描述的元件。圖1描述的邏輯連接包括局域網(LAN)171和廣域網(WAN)173，但也可包括其它網絡。這類網絡環(huán)境常見于辦公室、企業(yè)范圍計算機網絡、內聯(lián)網以及因特網。
當在LAN網絡環(huán)境中使用時，計算機110通過網絡接口或適配器170連接至LAN 171。當在WAN網絡環(huán)境中使用時，計算機110通常包括調制解調器172或用于通過WAN 173，如因特網建立通信的其它裝置。調制解調器172可以是內置或外置的，它通過用戶輸入接口160或其它適當的機制連接至系統(tǒng)總線121。在網絡化環(huán)境中，相對于計算機110所描述的程序模塊或其部分可儲存在遠程存儲器存儲設備中。作為示例而非局限，圖1示出遠程應用程序185駐留在遠程計算機180上?？梢岳斫?，示出的網絡連接是示例性的，也可以使用在計算機之間建立通信鏈路的其它裝置。
應當注意，本發(fā)明可以在諸如參考圖1所描述的計算機系統(tǒng)上實現(xiàn)。然而，本發(fā)明也可以在服務器、專用于消息處理的計算機或分布式系統(tǒng)中實現(xiàn)，其中本發(fā)明的不同部分在分布式計算系統(tǒng)的不同部件上實現(xiàn)。
II.示例性系統(tǒng)環(huán)境為說明起見，將在電話應用程序的上下文中描述本發(fā)明的實施例。然而，本發(fā)明的范圍不限于此，且各實施例可在任何面向語音的應用程序的上下文中應用。
電話應用程序可被示為包括演示層和邏輯+數據層的多層系統(tǒng)。演示層通常負責使用語音輸出和語音輸入與最終用戶交互。某些系統(tǒng)將結合諸如GUI等附加輸出裝置，或諸如雙音多頻(DTMF)輸入機制等附加輸入裝置。一般而言，演示層提供了語音用戶接口。邏輯+數據層通常負責底層的業(yè)務規(guī)則和數據訪問及存儲。已知提供了一組API作為到邏輯+數據層的接口，但是仍存在對用于創(chuàng)作VUI的靈活API框架的需求。
圖2是示出系統(tǒng)體系結構200的高級特征的示意框圖。體系結構200的最高層包括應用程序或用戶代碼202。這說明性地為由開發(fā)者創(chuàng)建用于實現(xiàn)對話的代碼。體系結構200的最低層包括核心API框架206。核心框架206說明性地提供了對系統(tǒng)資源的訪問。例如，核心框架說明性地包括電話API、信號API、DTMF API、語音識別API、語音合成API和/或任何其它系統(tǒng)資源接口。
如由箭頭208所示的，代碼202可被配置成直接訪問核心框架206的組件。從開發(fā)者的觀點來看，這一開發(fā)方法可能是相對繁瑣且勞動密集型的。為減輕開發(fā)負擔，在應用程序202和核心框架206之間安置了對話API框架204?？蚣?04提供了比框架206更高級的API方法。由此，依照箭頭210和212，用戶代碼202可被編寫為直接調用框架204，框架204然后對框架206的組件作出相應的調用。以此方式，開發(fā)者可以用更有生產力的方式來創(chuàng)作對話。依照一個實施例，一工具(未示出)被構建在對話API框架204之上，以允許對開發(fā)者生產力的進一步提高。該工具促進且增強了開發(fā)者針對較高級API框架來創(chuàng)作的能力。
由此，體系結構200提供了一種具有兩層的VUI開發(fā)環(huán)境足以創(chuàng)作各種電話情形的低級語音層；以及被配置成通過創(chuàng)建較高級抽象來提高開發(fā)者生產力的較高級對話層。
III.對話API框架進一步參考圖2，對話API框架204可被配置成支持各種類型的對話的任一種。例如，框架204可被配置成便于創(chuàng)建主要結合語義驅動對話的應用程序202。或者，框架204可被配置成便于創(chuàng)建主要結合狀態(tài)驅動對話的應用程序202。然而，提供較高級開發(fā)接口的已知的嘗試一般無法支持對結合語義驅動和狀態(tài)驅動對話兩者的應用程序的有效創(chuàng)建。依照本發(fā)明的一方面，對話API框架204(以及可任選的一個或多個相關開發(fā)工具)被配置成便于混合語義驅動和狀態(tài)驅動對話的應用程序202的有效開發(fā)。應當注意，用于混合語義驅動和狀態(tài)驅動對話開發(fā)的相同的方案可用于允許對對話類型的任何組合的混合開發(fā)，而不會脫離本發(fā)明的范圍。
依照本發(fā)明的一方面，圖3是對話API框架(例如，圖2中的框架204)的一部分304的示意框圖。為支持混合對話類型的創(chuàng)作系統(tǒng)，所示的框架304包括語義驅動對話容器306和狀態(tài)驅動對話容器308。盡管僅示出了每一類型的容器中的一個，然而根據特定的開發(fā)方案可以包括任一類型的多個。當繼續(xù)本描述時，多個對話容器及其內容之間的功能關系也會變得顯而易見。
對話容器306和308的每一個包括多個對話元素310。盡管利用了相同的參考標號來指定所有示出的對話元素，然而可以理解，對話元素的特性可在各個對話元素之間不同。依照一個實施例，每一對話容器被配置成控制其包含的對話元素的激活。容器306被配置成容納和實現(xiàn)語義驅動對話，而容器308被配置成容納和實現(xiàn)狀態(tài)驅動對話。
依照一個實施例，任何對話容器被配置成也接受對話元素的角色。例如，一個對話容器可說明性地作為另一對話容器內的對話元素來操作。換言之，一個對話容器可實際上包含一個對話容器。這一安排提供了開發(fā)的靈活性。依照本發(fā)明的一方面，所描述的框架使得整個應用程序能夠被設計成語義驅動的、狀態(tài)驅動的或混合的，取決于開發(fā)者的偏好。如何組織和連接對話元素，使得一個對話容器是一個特定種類的可用對話元素一般是開發(fā)者的判斷。如下文將描述的，有各種各樣的專門API形式的對話元素對開發(fā)者可用，以提供對應的各種范圍的專門功能。
依照本發(fā)明的一方面，在較高API層(即，在圖2中框架204層)，存在對個別對話元素、語義驅動對話以及基礎結構的支持以支持所有類型的對話。在一個實施例中，該API層也包括對狀態(tài)驅動對話的支持。然而，在另一實施例中，對狀態(tài)驅動對話的明確支持被結合到構建在該API框架上的工具組件中以便于開發(fā)。應當注意，操縱工具和API之間的邊界以允許各種不同特定實現(xiàn)中的任一種是在本發(fā)明的范圍之內的。所有這樣的配置都在本發(fā)明的范圍之內。
與所描述的開發(fā)框架相關聯(lián)的另一優(yōu)點是對話元素一般被設計成在語義驅動或狀態(tài)驅動對話容器的任一個中操作或獨立操作。在轉向不同類型的對話元素的詳細描述之前，現(xiàn)在將提供開發(fā)混合語義驅動和狀態(tài)驅動對話的應用程序將會如何的示例。
依照混合格式對話開發(fā)的一個示例，開發(fā)者以空白調研開始，然后添加表示要按序執(zhí)行的連貫的對話組件的三個節(jié)點。開發(fā)者在第一個節(jié)點上向下深入，并插入諸如“歡迎”等語句。語句是不要求語義驅動對話的復雜能力的簡單對話組件。用于第一個節(jié)點的一個選項是創(chuàng)建狀態(tài)驅動容器，并在其中放置語句元素。在一個實施例中，開發(fā)平臺被配置成容納對語句的建立而無需創(chuàng)建任一類型的容器。
第二個節(jié)點說明性地旨在便于收集用戶信息的過程。取決于要收集的信息的特性，開發(fā)者具有若干選項。開發(fā)者可創(chuàng)建具有便于狀態(tài)驅動信息收集過程的元素(例如，“您的產品ID號是什么”……“該物品是何時購買的”……等等)的狀態(tài)驅動容器。或者，開發(fā)者可創(chuàng)建具有便于語義驅動信息收集過程的元素(例如，“請標識您自己”……“但是您的姓是什么”……“OK，您今天希望做什么”……等等)的語義驅動容器。
設計者在選擇如何設計第三個節(jié)點時具有類似的選項，該節(jié)點說明性地為使得用戶能夠選擇要執(zhí)行的功能的節(jié)點。例如，可向用戶呈現(xiàn)狀態(tài)驅動情形，諸如從中選擇的選項菜單?；蛘?，決策可利用語義驅動方法來作出，在該方法中，用戶說出他或她的選擇，且系統(tǒng)相應地應答。
依照本發(fā)明的一方面，對話API框架包括對話元素形式的多個API對象，這些對話元素可由應用程序開發(fā)者有效地利用。如所描述的，對話容器是一種類型的對話元素，且被配置成便于特定類型的對話的開發(fā)和執(zhí)行。
依照另一實施例，Statement(語句)元素是該框架內提供的另一類型的對話元素。Statement元素可以說明性地由開發(fā)者放置到任何類型的容器中，或者可以在功能上位于容器的外部。Statement元素使得能夠作出任何語句，而不期望從用戶返回任何答復。示例包括歡迎提示、再見提示或“對不起，出錯”提示。
依照另一實施例，QuestionAnswer(問題答復)元素是該框架內提供的另一類型的對話元素。QuestionAnswer元素說明性地可從任一類型的容器內操作。QuestionAnswer元素的一般功能是試圖從用戶獲得響應。在一個實施例中，該元素被配置成如果交換不成功則再次詢問(例如，“對不起，聽不到您說的，請重復一次”)。在另一實施例中，配備了QuestionAnswer元素以處理誤識別(例如，“對不起，沒有理解，請重復一次”)。該元素可被配置成如果的確發(fā)生了誤識別則向用戶提供某一指導(例如，“對不起，期望的是1和10之間的數字”)。
在一個實施例中，QuestionAnswer元素被配置成便于后處理隨后的語音識別。例如，當QuestionAnswer元素在語義驅動上下文中使用時(例如，從語義驅動容器內)，它便于從用戶響應中提取關鍵信息并在必要時填充各域的過程。在一個實施例中，QuestionAnswer元素的后處理功能在該元素在語義驅動上下文中使用時不是可任選的。相反，后處理在狀態(tài)驅動上下文中可以是可任選的。
在一個實施例中，可在QuestionAnswert元素中設置屬性以支持后處理功能(例如，如果域A、B和C被填充，則將發(fā)生X后處理等等)。為使QuestionAnswer元素被嵌入在語義驅動對話上下文中，必須提供某些屬性值以支持后處理功能。在一個實施例中，當QuestionAnswer元素被嵌入在狀態(tài)驅動對話上下文中時，如果開發(fā)者選擇后處理，則可充分利用后處理，但這并不是必需的。
例如，想像這樣的情形，用戶說“退出”，且系統(tǒng)響應“您確認您想要掛起嗎”。在用戶響應“是”或“否”之后，響應可能無需儲存以供后續(xù)的目的。由此，在該情況下，一般無需設置對應的屬性并指定對應的后處理步驟。相反，開發(fā)者可在狀態(tài)驅動上下文中嵌入QuestionAnswer元素，并將該元素配置成在識別完成之后捕捉用戶輸入并相應地應答。促進這樣的狀態(tài)驅動交互是在QuestionAnswer的能力范圍之內。但是即使是在狀態(tài)驅動對話上下文中，捕捉輸入用于后續(xù)的對話目的也是有用的。在一個實施例中，在這一情況下，系統(tǒng)被配置成充分利用后處理來直接填充域。
依照一個實施例，QuestionAnswer元素被配置成當開始時播放MainPrompt(主提示)，用以監(jiān)聽語音或DTMF、支持一個以上語音或DTMF語法、在播放提示時監(jiān)聽或不監(jiān)聽、在播放了提示的一部分之后開始監(jiān)聽以與標準DialogElement(對話元素)(后文描述)一樣運作、在檢測到有效識別之前保持提示、適應提示以處理Help(幫助)和Repeat(重復)命令、適應提示以處理無聲或非識別、支持FormFillingDialog(表單填充對話)、展示用于將結果綁定到SemanticItem(語義項)的機制、自動化SemanticItem的確認、和/或通過查看語義綁定來確定FormFillingDialog激活。
依照另一實施例，SemanticItem元素是該框架內提供的另一類型的對話元素。SemanticItem元素提供了一般在語義驅動上下文中支持表單域的類。這些表單域是在語義驅動對話過程中填充的域。
依照另一實施例，F(xiàn)ormFillingDialog元素是該框架內提供的另一類型的對話元素。FormFillingDialog元素是驅動語義驅動對話且支持填充域的相關聯(lián)過程的容器。
依照另一實施例，RecordSound(記錄聲音)元素是該框架內提供的另一類型的對話元素。RecordSound元素說明性地可從任一類型的容器內操縱或可獨立地操作。RecordSound元素的一般功能是從用戶獲得記錄(例如，無需執(zhí)行任何識別功能)。這一元素在語音郵件和其它類似的應用程序的上下文中是有用的。
依照另一實施例，Command(命令)元素是該框架內提供的另一類型的對話元素。Command元素說明性地可從任一類型的容器內操作或可獨立地操作。Command元素的一般功能是支持用戶輸入的捕捉，該用戶輸入一般與應用程序的主要流程沒有關系。例如，可以實現(xiàn)Command元素以使用戶能夠說出諸如“話務員”等命令，作為離開主對話的一種方式。在一個實施例中，該命令可以是非口頭的，諸如按下按鍵(例如，按下“0”鍵)。在一個實施例中，Command元素是在對話應用程序的頂層創(chuàng)作的，使得它可普遍地應用(例如，如果“話務員”在對話的任一時刻被識別，則轉移到分機0)。在另一實施例中，可創(chuàng)作Command元素以在上下文中活動或按照范圍活動。該元素可以說明性地在全局范圍或受限的范圍上活動(例如，僅在特定的容器內活動)。由此，范圍可說明性地如同特定的對話元素那樣小，或如同整個應用程序那樣大。因此，Command元素一般不是由對話流而是由范圍或對話區(qū)域來激活的。
依照另一實施例，Application(應用程序)元素是該框架內提供的另一類型的對話元素。Application元素作為特定對話應用程序的頂層上下文來運作。它通常例示頂層容器。Appication元素的一般功能是為一般的交互以及發(fā)生在該框架內的元素之間發(fā)生的較低級交互建立指導方針。盡管Application元素的職責可以在寬泛的范圍上變化，然而它們可包括用于支持電話應用程序的不同方面的基本步驟的實現(xiàn)，包括自動電話應答、呼叫拒絕、呼叫終止、跟蹤呼叫進度，尤其是支持某些呼入和呼出特征以及處理連接出錯。
可以理解，在該框架內具有協(xié)助其它對話功能的實現(xiàn)的另外的助手對象。大多數元素可從任一類型的容器內操作或可獨立地操作。若干元素被配置成處理如無聲、誤識別、不可識別響應(例如，未識別語言的響應)、錯誤的回答等等。這些元素用于確立取決于特定期望的特性要執(zhí)行什么對話。
在一個實施例中，該系統(tǒng)被配置成自動支持提示選擇(即，利用PromptSelection(提示選擇)元素)，只要預先確定對應的文本。諸如HistoryItem(歷史項)等元素用于確定在運行時發(fā)生了什么。類似地，Logging(日志記錄)元素提供了對跟蹤在運行時發(fā)生什么的協(xié)助(例如，該API向所建立的日志記錄結構提供數據)。HistoryItem元素可用于便于實現(xiàn)Bail-Out(放棄)元素，作為對諸如當用戶消失(例如，詢問了四次問題而沒有任何應答，只有無聲或不可識別的響應)時等非尋常情況的適當響應。
依照本發(fā)明一個獨特方面，對話API方法是在容器層實現(xiàn)的。所描述的和其它子元素支持嵌入在對話容器中的邏輯，使得容器能夠將功能委托給子元素。如所提到的，對話容器內的對話元素甚至可以實際上是另一對話容器。無論給定容器的內容是什么，它都被配置成支持特定類型的對話類型，諸如但不限于，語義驅動或狀態(tài)驅動對話。
向容器提供以正確的順序激活其對話元素所需的信息。順序至少部分地是由特定容器的特性按照它是否被配置成應用預定的策略，如語義驅動對話、狀態(tài)驅動對話或不同的策略來確定的。在本發(fā)明的一個實施例中，可創(chuàng)建新對話容器以實現(xiàn)對其子對話元素的任何對話策略。
依照一個實施例，所描述的對話API框架被配置成支持對支持編碼自動化的某一級別的工具的創(chuàng)建。API/工具對說明性地提高了開發(fā)者生產力，尤其是與直接編碼到低級資源相比。
依照本發(fā)明的一方面，依照所描述的對話API框架開發(fā)的對話應用程序可以被示為其中頂層節(jié)點是應用程序本身的樹。應用程序構建在一系列組件上，且應用程序管理它們之間的流程。這些組件進而可以構建在其它組件上。在樹中的葉節(jié)點處，可以找到最小的、最基本的對話組件。所描述的結構實際上支持子對話重用以及預先打包的應用程序和組件的創(chuàng)建。
每一組件管理其子組件之間的“流程”。流程在本質上可以是相對動態(tài)的(如在語義驅動或目標驅動對話中)或相對過程的。在任一情況下，激活組件說明性地涉及使得組件試圖“完成其工作”且當它完成或發(fā)生某一錯誤時回頭向調用者(父組件)報告。具有其它子組件的組件然后在激活后將找出要激活的第一個子組件，且等待其完成，決定接著要運行哪個子組件等等。
某些對話情形不能完全由“流程”來創(chuàng)建，但是直接要求上下文改變。這些交互可以更好地被視為流程的中斷和至應用程序中不同任務的跳轉。在一個實施例中，這些中斷是通過用戶發(fā)出特定命令的聲音來觸發(fā)的。該命令的識別然后導致上下文改變和新任務的執(zhí)行。
如所描述的，對話API框架說明性地支持兩種主要類型的對象，即DialogElements(對話元素)和DialogContainer(對話容器)。主應用程序說明性地是DialogContainer，而新的DialogContainer是通過導出來定義的，其中每一新容器定義一個新的類。這些容器然后在運行時例示并被執(zhí)行。該模型內的子對話可被視為組件重用(代替子例程調用)。
在一個實施例中，DialogContainer在技術上不直接包含其它DialogContainer，但是它們的確“調用”其它對話容器。這說明性地是通過使用DialogReference(對話引用)原語或元素來實現(xiàn)的。DialogReference說明性地展示了可引用任何DialogContainer的屬性，因此它可在運行時例示。當所引用的DialogContainer完成其執(zhí)行時，它說明性地通知例示它的DialogReference。父DialogContainer然后可照常繼續(xù)進行。
在一個實施例中，DialogElement被配置成展示開始執(zhí)行的方法、展示停止/取消執(zhí)行的方法、異步執(zhí)行、當它們不再運行時通知應用程序、向應用程序通知它們不運行的原因(已完成、已取消、出錯等等)、當啟動時通知應用程序、以及具有對Application對象的訪問(且因此具有對相關聯(lián)的信號和統(tǒng)一API的訪問)。DialogElement說明性地是可組成的，且當被組成時將具有對其父對象的訪問。
依照本發(fā)明的一方面，可提供任何創(chuàng)作環(huán)境來展示所描述的對話API框架的功能。這一創(chuàng)作環(huán)境可以是僅API、API+工具、僅工具或任何其它實現(xiàn)環(huán)境，而不脫離本發(fā)明的范圍。
盡管參考特定實施例描述了本發(fā)明，然而本領域的技術人員可以認識到，可以在形式和細節(jié)上作出改變而不脫離本發(fā)明的精神和范圍。
權利要求
1.一種包含在一個或多個計算機可讀介質上的應用程序接口，包括第一對話容器，它被配置成便于開發(fā)應用程序內的第一類對話；以及第二對話容器，它被配置成便于開發(fā)應用程序內的第二類對話。
2.如權利要求1所述的應用程序接口，其特征在于，還包括至少一個對話元素，所述對話元素被配置成從第一和第二對話容器的任一個內操作。
3.如權利要求1所述的應用程序接口，其特征在于，所述第一類對話是語義驅動對話或狀態(tài)驅動對話的任一個。
4.如權利要求1所述的應用程序接口，其特征在于，還包括擔當對低級系統(tǒng)資源的接口的核心API框架。
5.如權利要求1所述的應用程序接口，其特征在于，還包括提供用于與所述應用程序接口交互的開發(fā)框架的工具。
6.如權利要求1所述的應用程序接口，其特征在于，向所述第一和第二對話容器提供支持所述容器內包含的對話元素的激活的信息。
7.一種用于使得開發(fā)者能夠混合應用程序內的不同類型對話的計算機實現(xiàn)的方法，所述方法包括提供第一開發(fā)資源，它被配置成便于開發(fā)應用程序內的第一類對話；以及提供第二開發(fā)資源，它被配置成便于開發(fā)應用程序內的第二類對話。
8.如權利要求7所述的方法，其特征在于，還包括提供至少一個開發(fā)資源，所述開發(fā)資源被配置成與所述第一和第二開發(fā)資源的任一個相關聯(lián)地操作。
9.如權利要求7所述的方法，其特征在于，提供第一開發(fā)資源包括提供被配置成便于開發(fā)語義驅動對話的第一對話容器。
10.如權利要求9所述的方法，其特征在于，提供第二開發(fā)資源包括提供被配置成便于開發(fā)狀態(tài)驅動對話的第二對話容器。
11.如權利要求10所述的方法，其特征在于，還包括提供至少一個對話元素，所述對話元素被配置成從所述第一和第二對話容器的任一個內操作。
12.如權利要求10所述的方法，其特征在于，還包括配置所述第一和第二開發(fā)資源使得所述第一對話容器的實例可從所述第二對話容器的實例內操作，反之亦然。
13.如權利要求11所述的方法，其特征在于，所述對話元素包括從由Statement元素、QuestionAnswer元素、SemanticItem元素、FormFillingDialog元素、RecordSound元素、Command元素和Application元素構成的集合中選出的元素。
14.如權利要求13所述的方法，其特征在于，從所述集合中選出的至少一個元素可從所述第一和第二開發(fā)資源的任一個內操作。
15.如權利要求7所述的方法，其特征在于，還包括向所述第一和第二開發(fā)資源提供對核心API框架的訪問，所述核心API框架擔當對低級系統(tǒng)資源的接口。
16.一種用于使得開發(fā)者能夠混合應用程序內不同類型的對話的對話系統(tǒng)，所述系統(tǒng)包括包含多個第一對話元素的第一對話容器，所述第一對話容器被配置成便于依照第一對話策略來處理所述多個第一對話元素。
17.如權利要求16所述的對話系統(tǒng)，其特征在于，還包括包含在所述第一對話容器內的第二對話容器，其中所述第二對話容器包含多個第二對話元素，且被配置成便于依照第二對話策略來處理所述多個第二對話元素，所述第二對話策略與所述第一對話策略不同。
18.如權利要求17所述的對話系統(tǒng)，其特征在于，所述第一和第二對話策略中的一個是語義驅動對話，而另一個是狀態(tài)驅動對話。
19.如權利要求16所述的對話系統(tǒng)，其特征在于，所述第一對話策略是客戶定義的策略。
20.如權利要求16所述的對話系統(tǒng)，其特征在于，所述第一對話策略的至少一部分是由開發(fā)者配置的。
全文摘要
揭示了一種包含在一個或多個計算機可讀介質上的應用程序接口。該接口包括被配置成便于開發(fā)應用程序內的第一類對話的第一對話容器。還包括被配置成便于開發(fā)應用程序內的第二類對話的第二對話容器。
文檔編號G06F9/44GK1831762SQ20061000373
公開日2006年9月13日 申請日期2006年2月8日 優(yōu)先權日2005年3月8日
發(fā)明者F·M·佳拉尼斯, R·J·勒寇伊奇, R·H·歐文 申請人:微軟公司