PATENT DOCUMENT

Publication Number: US-9502031-B2
Application Number: US-201414494305-A
Country: US
Kind Code: B2

Title: Method for supporting dynamic grammars in WFST-based ASR

Abstract:
Systems and processes are disclosed for recognizing speech using a weighted finite state transducer (WFST) approach. Dynamic grammars can be supported by constructing the final recognition cascade during runtime using difference grammars. In a first grammar, non-terminals can be replaced with a, weighted phone loop that produces sequences of mono-phone words. In a second grammar, at runtime, non-terminals can be replaced with sub-grammars derived from user-specific usage data including contact, media, and application lists. Interaction frequencies associated with these entities can be used to weight certain words over others. With all non-terminals replaced, a static recognition cascade with the first grammar can be composed with the personalized second grammar to produce a user-specific WEST. User speech can then be processed to generate candidate words having associated probabilities, and the likeliest result can be output.

Claims:
What is claimed is: 
     
       1. A method for recognizing speech, the method comprising:
 at an electronic device:
 receiving user-specific usage data comprising one or more entities and an indication of user interaction with the one or more entities; and 
 receiving speech input from a user; 
 in response to receiving the speech input:
 composing a weighted finite state transducer having a first grammar transducer with a second grammar transducer, wherein the second grammar transducer comprises the user-specific usage data; 
 transducing the speech input into a word and an associated probability using the weighted finite state transducer composed with the second grammar transducer; and 
 outputting the word based on the associated probability. 
 
 
 
     
     
       2. The method of  claim 1 , wherein the one or more entities comprise a list of user contacts. 
     
     
       3. The method of  claim 2 , wherein the indication of user interaction comprises a frequency of interaction with a contact in the list of user contacts. 
     
     
       4. The method of  claim 1 , wherein the one or more entities comprise a list of applications on a device associated with the user. 
     
     
       5. The method of  claim 4 , wherein the indication of user interaction comprises a frequency of interaction with an application in the list of applications. 
     
     
       6. The method of  claim 1 , wherein the one or more entities comprise a list of media associated with the user. 
     
     
       7. The method of  claim 6 , wherein the indication of user interaction comprises a play frequency of media in the list of media. 
     
     
       8. The method of  claim 1 , wherein the weighted finite state transducer comprises a context-dependency transducer and a lexicon transducer. 
     
     
       9. The method of  claim 1 , wherein the first grammar transducer comprises a weighted phone loop capable of generating a sequence of mono-phone words. 
     
     
       10. The method of  claim 1 , wherein the associated probability is based on a likelihood that the word corresponds to the speech input, and wherein the likelihood is based on the user-specific usage data. 
     
     
       11. The method of  claim 1 , wherein outputting the word comprises:
 transmitting the word to a user device. 
 
     
     
       12. The method of  claim 1 , wherein outputting the word comprises:
 transmitting the word to a virtual assistant knowledge system. 
 
     
     
       13. The method of  claim 1 , wherein outputting the word comprises:
 transmitting the word to a server. 
 
     
     
       14. A non-transitory computer-readable storage medium comprising computer-executable instructions for:
 receiving user-specific usage data comprising one or more entities and an indication of user interaction with the one or more entities; and 
 receiving speech input from a user; 
 in response to receiving the speech input:
 composing a weighted finite state transducer having a first grammar transducer with a second grammar transducer, wherein the second grammar transducer comprises the user-specific usage data; 
 transducing the speech input into a word and an associated probability using the weighted finite state transducer composed with the second grammar transducer; and 
 outputting the word based on the associated probability. 
 
 
     
     
       15. The non-transitory computer-readable storage medium of  claim 14 , wherein the one or more entities comprise a list of user contacts. 
     
     
       16. The non-transitory computer-readable storage medium of  claim 15 , wherein the indication of user interaction comprises a frequency of interaction with a contact in the list of user contacts. 
     
     
       17. The non-transitory computer-readable storage medium of  claim 14 , wherein the one or more entities comprise a list of applications on a device associated with the user. 
     
     
       18. The non-transitory computer-readable storage medium of  claim 17 , wherein the indication of user interaction comprises a frequency of interaction with an application in the list of applications. 
     
     
       19. A system for recognizing speech, the system comprising:
 one or more processors; 
 memory; and 
 one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, the one or more programs including instructions for:
 receiving user-specific usage data comprising one or more entities and an indication of user interaction with the one or more entities; and 
 receiving speech input from a user; 
 in response to receiving the speech input:
 composing a weighted finite state transducer having a first grammar transducer with a second grammar transducer, wherein the second grammar transducer comprises the user-specific usage data; 
 transducing the speech input into a word and an associated probability using the weighted finite state transducer composed with the second grammar transducer; and 
 outputting the word based on the associated probability. 
 
 
 
     
     
       20. The system of  claim 19 , wherein the one or more entities comprise a list of user contacts. 
     
     
       21. The system of  claim 20 , wherein the indication of user interaction comprises a frequency of interaction with a contact in the list of user contacts. 
     
     
       22. The system of  claim 19 , wherein the one or more entities comprise a list of applications on a device associated with the user. 
     
     
       23. The system of  claim 22 , wherein the indication of user interaction comprises a frequency of interaction with an application in the list of applications.

Description:
CROSS-REFERENCE TO RELATED APPLICATION 
     This application claims priority from U.S. Provisional Ser. No. 62/003,449, filed on May 27, 2014, entitled METHOD FOR SUPPORTING DYNAMIC GRAMMARS IN WEST-BASED ASR, which is hereby incorporated by reference in its entirety for all purposes. 
    
    
     FIELD 
     This relates generally to speech processing and, more specifically, to dynamically incorporating user-specific grammars in weighted finite state transducer-based automatic speech recognition. 
     BACKGROUND 
     Intelligent automated assistants (or virtual assistants) provide an intuitive interface between users and electronic devices. These assistants can allow users to interact with devices or systems using natural language in spoken and/or text forms. For example, a user can access the services of an electronic device by providing a spoken user input in natural language form to a virtual assistant associated with the electronic device. The virtual assistant can perform natural language processing on the spoken user input to infer the user&#39;s intent and operationalize the user&#39;s intent into tasks. The tasks can then be performed by executing one or more functions of the electronic device, and a relevant output can be returned to the user in natural language form. 
     In support of virtual assistants and other speech applications, automatic speech recognition (ASR) systems are used to interpret user speech. Some ASR systems are based on the weighted finite state transducer (WEST) approach. Many such WEST systems, however, include static grammars that fail to support language changes, introduction of new words, personalization for particular speakers, or the like. In virtual assistant applications—as well as other speech recognition applications—utility and recognition accuracy can be highly dependent on how well an ASR system can accommodate such dynamic changes in grammars. In particular, utility and accuracy can be impaired without the capacity to quickly and efficiently modify underlying recognition grammars during runtime to support such dynamic grammars. 
     Accordingly, without adequate support for dynamic grammars, WFST-based ASR systems can suffer poor recognition accuracy, which can limit speech recognition utility and negatively impact the user experience. 
     SUMMARY 
     Systems and processes are disclosed for recognizing speech. In one example, user-specific usage data can be received that includes one or more entities and an indication of user interaction with the one or more entities. Speech input from a user can also be received. In response to receiving the speech input, a WEST having a first grammar transducer can be composed with a second grammar transducer. The second grammar transducer can include the user-specific usage data. The speech input can be transduced into a word and an associated probability using the WEST composed with the second grammar transducer. The word can be output based on the associated probability. 
     In some examples, the one or more entities can include a list of user contacts, and the indication of user interaction can include a frequency of interaction with a contact in the list of user contacts. In other examples, the one or more entities can include a list of applications on a device associated with the user, and the indication of user interaction can include a frequency of interaction with an application in the list of applications. In still other examples, the one or more entities can include a list of media associated with the user, and the indication of user interaction can include a play frequency of media in the list of media. 
     In addition, in some examples, the WEST can include a context-dependency transducer and a lexicon transducer. Moreover, in some examples, the first grammar transducer can include a weighted phone loop capable of generating a sequence of mono-phone words. Furthermore, in some examples, the associated probability can be based on a likelihood that the word corresponds to the speech input, and the likelihood can be based on the user-specific usage data. 
     In some examples, outputting the word can include transmitting the word to a user device. In other examples, outputting the word can include transmitting the word to a virtual assistant knowledge system. In still other examples, outputting the word can include transmitting the word to a server. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  illustrates an exemplary system for recognizing speech for a virtual assistant according to various examples. 
         FIG. 2  illustrates a block diagram of an exemplary user device according to various examples. 
         FIG. 3  illustrates an exemplary process for recognizing speech. 
         FIG. 4  illustrates an exemplary first grammar employing a phone loop. 
         FIG. 5  illustrates an exemplary second grammar populated with user-specific entities from user sub-grammars. 
         FIG. 6  illustrates a functional block diagram of an electronic device configured to recognize speech according to various examples. 
     
    
    
     DETAILED DESCRIPTION 
     In the following description of examples, reference is made to the accompanying drawings in which it is shown by way of illustration specific examples that can be practiced. It is to be understood that other examples can be used and structural changes can be made without departing from the scope of the various examples. 
     This relates to systems and processes for recognizing speech. In one example, speech recognition can be performed using a WFST approach. Although many WFST-based ASR systems include a static recognition cascade, dynamic grammars can be supported as described in further detail herein by constructing the final recognition cascade of the system on-the-fly during runtime using difference grammars. In a first grammar of the WFST, optionally before runtime, non-terminals (e.g., a class type that can represent a set of words and word sequences) can be replaced with a weighted phone loop that produces sequences of mono-phone words. In a second grammar, on the other hand, at runtime, non-terminals can be replaced with sub-grammars derived from user-specific usage data. In particular, non-terminals in the second grammar can be populated with entities specific to a particular user whose speech is being interpreted. Entities can include, for example, contact lists, media lists, application lists, context, personalized dictionary entries, and the like. In addition, interaction frequencies associated with these entities can be used to appropriately weight certain candidate words over others, thereby providing accurate recognition that is personalized for a particular user. With all non-terminals replaced, the static recognition cascade with the first grammar can be composed on-the-fly with the personalized second grammar to produce a user-specific WFST-based system. User speech can then be processed with the system to generate candidate words having associated probabilities (e.g., likelihoods that the words accurately reflect the user&#39;s speech). The results having the highest probability can then be output. 
     It should be understood that a WFST approach can provide quick and efficient speech recognition. Supporting dynamic grammars according to the various examples discussed herein can further provide accurate recognition. Such quick and accurate speech recognition can provide an enjoyable user experience and significant utility for the system. It should be understood, however, that still many other advantages can be achieved according to the various examples discussed herein. 
       FIG. 1  illustrates exemplary system  100  for recognizing speech for a virtual assistant according to various examples. It should be understood that speech recognition as discussed herein can be used for any of a variety of applications, including in support of a virtual assistant. In other examples, speech recognition according the various examples herein can be used for speech transcription, voice commands, voice authentication, or the like. The terms “virtual assistant,” “digital assistant,” “intelligent automated assistant,” or “automatic digital assistant” can refer to any information processing system that can interpret natural language input in spoken and/or textual form to infer user intent, and perform actions based on the inferred user intent. For example, to act on an inferred user intent, the system can perform one or more of the following: identifying a task flow with steps and parameters designed to accomplish the inferred user intent; inputting specific requirements from the inferred user intent into the task flow; executing the task flow by invoking programs, methods, services, APIs, or the like; and generating output responses to the user in an audible (e.g., speech) and/or visual form. 
     A virtual assistant can be capable of accepting a user request at least partially in the form of a natural language command, request, statement, narrative, and/or inquiry. Typically, the user request seeks either an informational answer or performance of a task by the virtual assistant. A satisfactory response to the user request can include provision of the requested informational answer, performance of the requested task, or a, combination of the two. For example, a user can ask the virtual assistant a question, such as “Where am I right now?” Based on the user&#39;s current location, the virtual assistant can answer, “You are in Central Park.” The user can also request the performance of a task, for example, “Please remind me to call Mom at 4 p.m. today.” in response, the virtual assistant can acknowledge the request and then create an appropriate reminder item in the user&#39;s electronic schedule. During the performance of a requested task, the virtual assistant can sometimes interact with the user in a continuous dialogue involving multiple exchanges of information over an extended period of time. There are numerous other ways of interacting with a virtual assistant to request information or performance of various tasks. In addition to providing verbal responses and taking programmed actions, the virtual assistant can also provide responses in other visual or audio forms (e.g., as text, alerts, music, videos, animations, etc). 
     An example of a virtual assistant is described in Applicants&#39; U.S. Utility application Ser. No. 12/987,982 for “Intelligent Automated Assistant,” filed Jan. 10, 2011, the entire disclosure of which is incorporated herein by reference. 
     As shown in  FIG. 1 , in some examples, a virtual assistant can be implemented according to a client-server model. The virtual assistant can include a client-side portion executed on a user device  102 , and a server-side portion executed on a server system  110 . User device  102  can include any electronic device, such as a mobile phone (e.g., smartphone), tablet computer, portable media player, desktop computer, laptop compute, PDA, television, television set-top box (e.g., cable box, video player, video streaming device, etc.), wearable electronic device (e.g., digital glasses, wristband, wristwatch, brooch, armband, etc.), gaming system, or the like. User device  102  can communicate with server system  110  through one or more networks  108 , which can include the Internet, an intranet, or any other wired or wireless public or private network. 
     The client-side portion executed on user device  102  can provide client-side functionalities, such as user-facing input and output processing and communications with server system  110 . Server system  110  can provide server-side functionalities for any number of clients residing on a respective user device  102 . 
     Server system  110  can include one or more virtual assistant servers  114  that can include a client-facing I/O interface  122 , one or more processing modules  118 , data and model storage  120 , and an I/O interface to external services  116 . The client-facing I/O interface  122  can facilitate the client-facing input and output processing for virtual assistant server  114 . The one or more processing modules  118  can utilize data and model storage  120  to determine the user&#39;s intent based on natural language input, and can perform task execution based on inferred user intent. In some examples, virtual assistant server  114  can communicate with external services  124 , such as telephony services, calendar services, information services, messaging services, navigation services, and the like, through network(s)  108  tier task completion or information acquisition. The I/O interface to external services  116  can facilitate such communications. 
     Server system  110  can be implemented on one or more standalone data processing devices or a distributed network of computers. In some examples, server system  110  can employ various virtual devices and/or services of third party service providers (e.g., third-party cloud service providers) to provide the underlying computing resources and/or infrastructure resources of server system  110 . 
     Although the functionality of the virtual assistant is shown in  FIG. 1  as including both a client-side portion and a server-side portion, in some examples, the functions of an assistant (or speech recognition in general) can be implemented as a standalone application installed on a user device. In addition, the division of functionalities between the client and server portions of the virtual assistant can vary in different examples. For instance, in some examples, the client executed on user device  102  can be a thin-client that provides only user-facing input and output processing functions, and delegates all other functionalities of the virtual assistant to a backend server. 
       FIG. 2  illustrates a block diagram of exemplary user device  102  according to various examples. As shown, user device  102  can include a memory interface  202 , one or more processors  204 , and a peripherals interface  206 . The various components in user device  102  can be coupled together by one or more communication buses or signal lines. User device  102  can further include various sensors, subsystems, and peripheral devices that are coupled to the peripherals interface  206 . The sensors, subsystems, and peripheral devices can gather information and/or facilitate various functionalities of user device  102 . 
     For example, user device  102  can include a motion sensor  210 , a light sensor  212 , and a proximity sensor  214  coupled to peripherals interface  206  to facilitate orientation, light, and proximity sensing functions. One or more other sensors  216 , such as a positioning system (e.g., a GPS receiver), a temperature sensor, a biometric sensor, a gyroscope, a compass, an accelerometer, and the like, can also be connected to peripherals interface  206 , to facilitate related functionalities. 
     In some examples, a camera subsystem  220  and an optical sensor  222  can be utilized to facilitate camera functions, such as taking photographs and recording video clips. Communication functions can be facilitated through one or more wired and/or wireless communication subsystems  224 , which can include various communication ports, radio frequency receivers and transmitters, and/or optical (e.g., infrared) receivers and transmitters. An audio subsystem  226  can be coupled to speakers  228  and microphone  230  to facilitate voice-enabled functions, such as voice recognition, voice replication, digital recording, and telephony functions. 
     In some examples, user device  102  can further include an I/O subsystem  240  coupled to peripherals interface  206 . I/O subsystem  240  can include a touchscreen controller  242  and/or other input controller(s)  244 . Touchscreen controller  242  can be coupled to a touchscreen  246 . Touchscreen  246  and the touchscreen controller  242  can, for example, detect contact and movement or break thereof using any of a plurality of touch sensitivity technologies, such as capacitive, resistive, infrared, and surface acoustic wave technologies, proximity sensor arrays, and the like. Other input controller(s)  244  can be coupled to other input/control devices  248 , such as one or more buttons, rocker switches, a thumb-wheel, an infrared port, a USB port, and/or a pointer device, such as a stylus. 
     In some examples, user device  102  can further include a memory interface  202  coupled to memory  250 . Memory  250  can include any electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, a portable computer diskette (magnetic), a random access memory (RAM) (magnetic), a read-only memory (ROM) (magnetic), an erasable programmable read-only memory (EPROM) (magnetic), a portable optical disc such as CD, CD-R, CD-RW, DVD, DVD-R, or DVD-RW, or flash memory such as compact flash cards, secured digital cards, USB memory devices, memory sticks, and the like. In some examples, a non-transitory computer-readable storage medium of memory  250  can be used to store instructions (e.g., for performing some or all of process  300 , described below) for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, processor-containing system, or other system that can fetch the instructions from the instruction execution system, apparatus, or device, and can execute the instructions. In other examples, the instructions (e.g., for performing process  300 , described below) can be stored on anon-transitory computer-readable storage medium of server system  110 , or can be divided between the non-transitory computer-readable storage medium of memory  250  and the non-transitory computer-readable storage medium of server system  110 . In the context of this document, a “non-transitory computer readable storage medium” can be any medium that can contain or store the program for use by or in connection with the instruction execution system, apparatus, or device. 
     In some examples, memory  250  can store an operating system  252 , a communication module  254 , a graphical user interface module  256 , a sensor processing module  258 , a phone module  260 , and applications  262 . Operating system  252  can include instructions for handling basic system services and for performing hardware dependent tasks. Communication module  254  can facilitate communicating with one or more additional devices, one or more computers, and/or one or more servers. Graphical user interface module  256  can facilitate graphic user interface processing. Sensor processing module  258  can facilitate sensor related processing and functions. Phone module  260  can facilitate phone-related processes and functions. Application module  262  can facilitate various functionalities of user applications, such as electronic messaging, web browsing, media processing, navigation, imaging, and/or other processes and functions. 
     As described herein, memory  250  can also store client-side virtual assistant instructions (e.g., in a virtual assistant client module  264 ) and various user data  266  (e.g., user-specific vocabulary data, preference data, and/or other data such as the user&#39;s electronic address book, to-do lists, shopping lists, etc.) to, for example, provide the client-side functionalities of the virtual assistant. User data  266  can also (as described below) be used in performing speech recognition in support of the virtual assistant or for any other application. 
     In various examples, virtual assistant client module  264  can be capable of accepting voice input (e.g., speech input), text input, touch input, and/or gestural input through various user interfaces (e.g., I/O subsystem  240 , audio subsystem  226 , or the like) of user device  102 . Virtual assistant client module  264  can also be capable of providing output in audio (e.g., speech output), visual, and/or tactile forms. For example, output can be provided as voice, sound, alerts, text messages, menus, graphics, videos, animations, vibrations, and/or combinations of two or more of the above. During operation, virtual assistant client module  264  can communicate with the virtual assistant server using communication subsystem  274 . 
     In some examples, virtual assistant client module  264  can utilize the various sensors, subsystems, and peripheral devices to gather additional information from the surrounding environment of user device  102  to establish a context associated with a user, the current user interaction, and/or the current user input. In some examples, virtual assistant client module  264  can provide the contextual information or a subset thereof with the user input to the virtual assistant server to help infer the user&#39;s intent. The virtual assistant can also use the contextual information to determine how to prepare and deliver outputs to the user. The contextual information can further be used by user device  102  or server system  110  to support accurate speech recognition, as discussed herein. 
     In some examples, the contextual information that accompanies the user input can include sensor information, such as lighting, ambient noise, ambient temperature, images or videos of the surrounding environment, distance to another object, and the like. The contextual information can further include information associated with the physical state of user device  102  (e.g., device orientation, device location, device temperature, power level, speed, acceleration, motion patterns, cellular signal strength, etc.) or the software state of user device  102  (e.g., running processes, installed programs, past and present network activities, background services, error logs, resources usage, etc). Any of these types of contextual information can be provided to virtual assistant server  114  (or used on user device  102  itself) as contextual information associated with a user input. 
     In some examples, virtual assistant client module  264  can selectively provide information (e.g., user data  266 ) stored on user device  102  in response to requests from virtual assistant server  114  (or it can be used on user device  102  itself in executing speech recognition and/or virtual assistant functions). Virtual assistant client module  264  can also elicit additional input from the user via a natural language dialogue or other user interfaces upon request by virtual assistant server  114 . Virtual assistant client module  264  can pass the additional input to virtual assistant server  114 - to help virtual assistant server  114  in intent inference and/or fulfillment of the user&#39;s intent expressed in the user request. 
     In various examples, memory  250  can include additional instructions or fewer instructions. Furthermore, various functions of user device  102  can be implemented in hardware and/or in firmware, including in one or more signal processing and/or application specific integrated circuits. 
     It should be understood that system  100  is not limited to the components and configuration shown in  FIG. 1 , and user device  102  is likewise not limited to the components and configuration shown in  FIG. 2 . Both system  100  and user device  102  can include fewer or other components in multiple configurations according to various examples. 
       FIG. 3  illustrates exemplary process  300  for recognizing speech according to various examples. Process  300  can, for example, be executed on processing modules  118  of server system  110  discussed above with reference to  FIG. 1 . In other examples, process  300  can be executed on processor  204  of user device  102  discussed above with reference to  FIG. 2 . In still other examples, processing modules  118  of server system  110  and processor  204  of user device  102  can be used together to execute some or all of process  300 . At block  302 , user-specific usage data can be received, including entity lists and associated interaction frequencies. In one example, user-specific usage data can include user data  266  in memory  250  of user device  102  discussed above. Such user-specific usage data can include a variety of information that can be useful for personalizing speech recognition (e.g., to ensure accurate recognition). 
     For example, user-specific usage data received at block  302  can include names found in a user&#39;s phonebook or contact list. A user may utter contact names in a, variety of circumstances, such as in voice commands to call, email, message, or otherwise communicate with a contact. A user may also utter contact names when dictating emails, messages, or the like (e.g., referring to friends, coworkers, family members, or the like in communication). In some instances, a contact list can include names that may not be within the standard vocabulary of a speech recognition system. These out-of-vocabulary names can thus be received and used as discussed in further detail below to provide recognition support for such user-specific words. 
     In addition to the contact list, a frequency of interaction with the various contacts in the contact list can be received. For example, data can be received that reflects how often a user interacts with various contacts. In some examples, the frequency of interaction can reflect which contacts a user interacts with the most via email, phone, instant messaging, text messaging, or the like. The frequency of interaction can also reflect which contact names a user tends to utter most when using speech recognition. In other examples, the frequency of interaction can include a ranking of contacts with which the user interacts the most. In still other examples, favorite lists, speed dial lists, or the like can be used to reflect a likely frequency of interaction between the user and various contacts. It should be understood that the frequency of interaction can be represented in any of a variety of ways (e.g., probabilities, percentages, rankings, interaction counts, number of interactions over a particular time period, etc.). 
     In another example, user-specific usage data received at block  302  can include names of applications on a user&#39;s device (e.g., applications on user device  102 ). A user may utter application names in a variety of circumstances, such as in voice commands to launch an application, close an application, direct instructions to an application, or the like. A user may also utter application names when dictating emails, messages, or the like (e.g., recommending an application to a friend, posting to asocial media feed the achievement of a new high score in a gaming application, or the like). In some instances, an application on a user device can have a name that may not be within the standard vocabulary of a speech recognition system. A list of user applications can thus be received and used as discussed in further detail below to provide recognition support for such user-specific application names. 
     In addition to the names of applications on a user&#39;s device, a frequency of interaction with the various applications can be received. For example, data can be received that reflects how often a user interacts with various applications. In some examples, the frequency of interaction can reflect which applications a user interacts with the most (e.g., frequently launched applications, applications used for the longest period of time, etc.). The frequency of interaction can also reflect which application names a user tends to utter most when using speech recognition. In other examples, the frequency of interaction can include a ranking of applications with which the user interacts the most. In still other examples, favorite applications, applications positioned on a home screen, applications positioned in a quick access area, applications made available from a lock screen, or the like can be used to reflect a likely frequency of interaction between the user and various applications. It should be understood that the frequency of interaction can be represented in any of a variety of ways (e.g., probabilities, percentages, rankings, launch counts, usage times, number of launches over a particular time period, etc.). 
     In another example, user-specific usage data received at block  302  can include names of media on a user&#39;s device, media accessible to a user, or media otherwise associated with a user (e.g., media stored in memory on user device  102 , media available via streaming applications, media available via the Internet, media available from cloud storage, media available from a subscription service, etc.). Media names can include song tracks, music album titles, playlist names, genre names, mix names, artist names, radio station names, channel names, video titles, performer names, podcast titles, podcast producer names, or the like. A user may utter media names in a variety of circumstances, such as in voice commands to play a song, play a video, tune to a radio station, play a mix of a particular genre of music, play an album, play an artist&#39;s music, or the like. A user may also utter media names when dictating messages, searching for media, or the like (e.g., recommending an album to a friend, searching for a new song to buy, searching for a video clip to play, etc.). In some instances, media on a user device or available from other sources can have names that may not be within the standard vocabulary of a speech recognition system. A list of media associated with a particular user can thus be received and used as discussed in further detail below to provide recognition support for such user-specific media names. 
     In addition to the names of media associated with a user, a frequency of interaction with the media can be received. For example, data can be received that reflects how often a user listens to, watches, or otherwise consumes media. In some examples, the frequency of interaction can reflect which media a user consumes the most (e.g., frequently played songs, frequently watched videos, frequently consumed podcasts, preferred genres, etc.). The frequency of interaction can also reflect which media names a user tends to utter most when using speech recognition. In other examples, the frequency of interaction can include a ranking of media the user consumes the most. In still other examples, favorite songs, favorite playlists, favorite genres, favorite artists, or the like can be used to reflect a likely frequency of interaction between the user and various media. It should be understood that the frequency of interaction can be represented in any of a variety of ways (e.g., probabilities, percentages, rankings, play counts, play counts over a particular time period, etc.). 
     In other examples, user-specific usage data received at block  302  can include a variety of other entities associated with a user that can be useful for ensuring speech recognition accuracy. Likewise, a variety of context information or other user-specific details can be received for speech recognition purposes. In some examples, such other entities and context information can be accompanied by interaction frequency data similar to that discussed above reflecting, for example, the likelihood that a particular entity will correspond to a user&#39;s similar-sounding utterance. 
     At block  304 , speech input can be received from a user. For example, speech input can be recorded by and received from microphone  230  of user device  102  (e.g., through audio subsystem  226  and peripherals interface  206 ). The speech input can include any user utterances, such as voice commands, dictation, requests, authentication phrases, or the like. 
     At block  306 , a WFST having a first grammar transducer can be composed with a second grammar transducer that includes the user-specific usage data received at block  302 . In one example, the composition can be performed on-the-fly at runtime in response to receiving the speech input from a user at block  304 . 
     ASR systems can involve a variety of component knowledge sources, and the unified mathematical framework of WFSTs can be used to represent, combine, and optimize these various component knowledge sources. In one example, one such knowledge source can include a context-dependency transducer denoted “C,” which can transduce a sequence of context-dependent phones into a sequence of mono-phones. Another knowledge source can include a lexicon transducer denoted “L,” which can transduce sequences of mono-phones into sequences of words. Another knowledge source can include a grammar transducer denoted “G,” which can weigh the sequences of words according to their likelihood (e.g., producing words with associated probabilities). It should be understood that any of the various knowledge sources can incorporate weighting effects based on probabilities for a given language, context, and the like. 
     In some examples, these various knowledge sources can be combined and optimized via the mathematical operations of composition, determinization, and minimization into one static recognition cascade denoted “CLG.” It can be non-trivial to modify such a static recognition cascade to incorporate new words into the lexicon and grammar. In some examples, pre-compiled sub-grammars can be incorporated at runtime, and an enforcement transducer can be added that removes any illegal connections that are related to cross-word context-dependency issues. In other examples, the lexicon transducer can be augmented with all mono-phones to introduce mono-phone words, and the final recognition cascade can be constructed during runtime using on-the-fly composition with a grammar transducer (e.g., CL∘G, where ∘ indicates on-the-fly composition). 
     As further described herein, however, in other examples, difference grammars can be used in constructing the final recognition cascade on-the-fly during runtime, which can provide memory efficient, fast, and accurate speech recognition, which can also provide an enjoyable user experience. In particular, the transducer examples described herein can work with decoders that use the difference grammar (or equivalently difference language model) approach, where a difference grammar can be dynamically (on-the-fly) composed with the static recognition cascade. Grammar modifications can be done efficiently and on-demand in the difference grammar. For example, as described in further detail below with reference to  FIG. 5 , non-terminal symbols included in the difference grammar can be replaced with sub-grammars that may be specific to a user&#39;s personal information. The sub-grammars can be constructed as WFSTs that accept mono-phone words and produce regular words. Dynamic composition with the static cascade can still remain possible, since the static cascade can include phone loops that produce mono-phone words, as described in further detail below with reference to  FIG. 4 . 
     One example, a recognition cascade can be constructed using difference grammars as follows:
 
 CLG   small   ∘G   −small/big   =CLG   small   ∘G   −small   G   big ,
 
where ∘ indicates the mathematical operation of composition performed on-the-fly at runtime, and G −small  includes the same content as G small , hut with likelihoods negated. This approach can allow the static cascade CLG small  to be constructed prior to runtime (providing efficiency and computational time savings), with support for dynamically introducing sub-grammars on-the-fly at runtime that are personalized for a user in a second grammar transducer G big  (e.g., a difference grammar). To achieve this on-the-fly composition, weighted phone loops can be introduced in the first grammar transducer G small  that can produce sequences of mono-phone words. In particular, both the small grammar and big grammar can be built with non-terminal symbols (or class tags) indicating where entities, words, etc. should be populated (e.g., $ContactList where contact names should be inserted, $AppList where application names should be inserted, $MediaList where media names should be inserted, etc.). In the first grammar transducer G small , all non-terminals can be replaced with a weighted phone loop. In the second grammar transducer G big , during recognition (but before doing on-the-fly composition), all non-terminals can be replaced with their respective sub-grammars that can be personalized for a particular user. These replacements are discussed in further detail below with reference to  FIG. 4  and  FIG. 5 .
 
       FIG. 4  illustrates exemplary first grammar G small    420  employing phone loop  428 . In one example, first grammar G small    420  can be constructed with non-terminal symbols as placeholders where user-specific words could be populated. For example, cascade  422  can correspond to a voice command for calling someone in a user&#39;s contact list. A user can utter, for example, “Call Peter” to call a contact having the name Peter. Cascade  422  is illustrated with a single transition from zero to one for “Call,” hut it should be appreciated that “Call” can be broken into constituent phones or the like with multiple transitions. As illustrated, cascade  422  can include a non-terminal “$Contacttist” where the names of a user&#39;s contacts could be populated to generate a personalized grammar. As noted above, however, the static recognition cascade CLG small  can be constructed before runtime (e.g., before at least some user-specific data becomes available). The non-terminal $ContactList in G small  can thus be replaced with a weighted phone loop, such as phone loop  428 . 
     Phone loop  428  can produce mono-phone words using all phones of a language. By looping, phone loop  428  can also produce all types of multi-phone words as well as phonetic sequences that can be similar to how a word may be pronounced. In addition, in some examples, other types of loops can be used that can emit word fragments, syllables, or mixtures of mono-phone words, word fragments, and syllables (or any other sub-word units). As discussed below, the grammars introduced at runtime can be configured to accept whatever output such loops produce, including mono-phone words, mono-phone word sequences, word fragments, syllables, or mixtures of mono-phone words, word fragments, and syllables. Phone loop  428  can also introduce weighting of the words and sequences to cut away unlikely and less likely results (e.g., repeated phones that may not occur in a language). For example, phone loop  428  can be weighted with statistical, phonetic n-gram language models and scaled as desired to arrive at the final weights. The phonetic language models can be trained on relevant data, such as phonetic sequences stemming from person names or the like. The phonetic sequences can be obtained, for example, from a grapheme-to-phoneme tool, acoustic forced alignments, or directly from speech recognition output. In this manner, cascade  422  can be constructed to accommodate most or all of the likely names (or pronunciations of names) that could replace the non-terminal $ContactList. As noted above, this replacement can occur before runtime, allowing static recognition cascade CLG small  to be constructed in advance. 
     In another example, cascade  424  in first grammar G small    420  can correspond to a voice command to launch an application on a user&#39;s device. A user can utter, for example, “Launch calendar” to launch a calendar application. Cascade  424  is illustrated with a single transition from zero to one for “Launch,” but it should be appreciated that “Launch” can be broken into constituent phones or the like with multiple transitions. As illustrated, cascade  424  can include a non-terminal “$AppList” where the names of applications on a user&#39;s device could be populated to generate a personalized grammar. As above, the non-terminal $AppList in G small  can be replaced with a weighted phone loop, such as phone loop  428 . 
     Phone loop  428  in cascade  424  can be the same as or different than phone loop  428  in cascade  422 . In one example, different phones loops having different weightings can be used to replace different non-terminals. In particular, phonetic n-gram language models trained with relevant language for specific non-terminals (e.g., contact names, application names, words associated with media, etc.) can be used to weight different phone loops to replace the respective non-terminals. In another example, a single generic phone loop  428  can be used to replace all non-terminals in first grammar G small    420 . Such a generic phone loop can be weighted with a combined phonetic language model. This language model can be obtained in a variety of ways. For example, one phonetic n-gram language model can be trained for each non-terminal using data sources that are relevant to the respective non-terminal (e.g., contact names, application names, words associated with media, etc.). For instance, one grammar can be trained on person names and another grammar can be trained on application names. All the different phonetic language models can then be interpolated into one generic language model, and the generic phone loop can be weighted using the interpolated generic language model. The generic phone loop can then be used in place of all non-terminals in the grammar. 
     Whether using a particularized phone loop or a generic phone loop, by replacing the non-terminal $AppList with phone loop  428 , cascade  424  can be constructed to accommodate most or all of the likely application names (or pronunciations of application names) that could replace the non-terminal $AppList. 
     In another example, cascade  426  in first grammar G small    420  can correspond to a voice command to play media on a user&#39;s device. A user can utter, for example, “Play classical music” to cause music in the classical genre to be played. Cascade,  426  is illustrated with a single transition from zero to one for “Play,” but it should be appreciated that “Play” can be broken into constituent phones or the like with multiple transitions. As illustrated, cascade  426  can include a non-terminal “$MediaList” where names associated with media on or available to a user&#39;s device could be populated to generate a personalized grammar. As above, the non-terminal $MediaList in G small  can be replaced with a weighted phone loop, such as phone loop  428 . By replacing the non-terminal $MediaList with phone loop  428 , cascade  426  can be constructed to accommodate most or all of the likely names (or pronunciations of names) associated with media on or available to a user&#39;s device that could replace the non-terminal $MediaList. 
     It should be understood that first grammar G small    420  can include many other cascades, some of which can include the same or other non-terminals that can be replaced by one or more weighted phone loops. With the non-terminals in G small  replaced with weighted phone loops, the static recognition cascade CLG small  can be constructed using the mathematical operations of composition, determinization, and minimization, as will be understood by one of ordinary skill in the art. 
     In some examples, in any of the particularized or generic weighted phone loops discussed above, word position-dependent mono-phones can be used. For example, word-begin, word-internal, and word-end mono-phones can be used. In such examples, the amount of words that can be produced by visiting a phone loop during decoding can be limited. For example, each word-end to word-begin transition can be penalized in the phone loop, or such transitions can be disallowed altogether. In the latter case, each visit to a phone loop can produce only one word. When using phone loops that only produce one word, compound words can be used to be able to model certain entities that are made up of multiple words. For example, the application name “App Store” can be modeled as a single compound word “App_Store,” thereby enabling a phone loop to produce the entire entity name even though the phone loop may be limited to producing a single word. 
     In addition, in any of the particularized or generic weighted phone loops discussed above, weight pushing can be performed in the phone loop. While doing so, any non-stochasticity can be distributed evenly along the phone loop. This can be done using standard algorithms. 
       FIG. 5  illustrates exemplary second grammar G big    530  populated with user-specific entities from user sub-grammars. As discussed above, second grammar transducer G big  can be used to dynamically introduce user-specific sub-grammars on-the-fly at runtime. In particular, composition can be performed to combine the personalized grammar transducer G big  with the pre-constructed static recognition cascade CLG small  as follows:
 
 G   small   ∘G   −small/big =CLG small   ∘G   −small   ∘G   big .
 
     As with first grammar G small    420 , second grammar G big    530  can be constructed with non-terminal symbols as placeholders where user-specific words could be populated. For example, cascade  532  can correspond to a voice command for calling someone in a user&#39;s contact list. A user can utter, for example, “Call Peter” to call a contact having the name Peter. As illustrated, cascade  532  can include a non-terminal “$ContactList” where the names of a user&#39;s contacts can be populated to generate a personalized grammar. In particular, the non-terminal $ContactList can be replaced with a user&#39;s sub-grammar that includes user contacts  538  (e.g., a list of contact names associated with the user including Peter, Sarah, and John). For example, the user-specific usage data received at block  302  of process  300  discussed above can include names found in a user&#39;s phonebook or contact list that can form a sub-grammar corresponding to the non-terminal $ContactList. Although not shown, the sub-grammar can also reflect probabilities associated with user contacts  538 , which can be derived from interaction frequency data received at block  302  of process  300  discussed above. The associated probabilities can be used in forming the sub-grammar such that a transducer employing second grammar G big    530  can produce not only appropriate names matching user contacts, but also associated probabilities of the names to ensure the likeliest matching contact can be selected. 
     In another example, cascade  534  can correspond to a voice command to launch an application on a user&#39;s device. A user can utter, for example, “Launch calendar” to launch a calendar application. As illustrated, cascade  534  can include a non-terminal “$AppList” where the names of applications on a user&#39;s device can be populated to generate a personalized grammar. In particular, the non-terminal $AppList can be replaced with a user&#39;s sub-grammar that includes user applications  540  (e.g., a list of applications on a user&#39;s device including App_Store, Calendar, and Mail). For example, the user-specific usage data received at block  302  of process  300  discussed above can include names of applications found on a user&#39;s device that can form a sub-grammar corresponding to the non-terminal $AppList. Although not shown, the sub-grammar can also reflect probabilities associated with user applications  540 , which can be derived from interaction frequency data received at block  302  of process  300  discussed above. The associated probabilities can be used in forming the sub-grammar such that a transducer employing second grammar G big    530  can produce not only appropriate application names matching user applications, but also associated probabilities of the applications to ensure the likeliest matching application can be selected. 
     In another example, cascade  536  can correspond to a voice command to play media on a user&#39;s device. A user can utter, for example, “Play classical music” to cause music in the classical genre to be played. As illustrated, cascade  536  can include a non-terminal “$MediaList” where names associated with media on or available to a user&#39;s device can be populated to generate a personalized grammar. In particular, the non-terminal $MediaList can be replaced with a user&#39;s sub-grammar that includes user media  542  (e.g., a list of media on or available to a user&#39;s device including a “Song,” “Playlist,” and “Movie,” where actual song, playlist, and movie titles would typically be used). For example, the user-specific usage data received at block  302  of process  300  discussed above can include names of media on or available to a user&#39;s device that can form a sub-grammar corresponding to the non-terminal $MediaList. Although not shown, the sub-grammar can also reflect probabilities associated with user media  542 , which can be derived from interaction frequency data received at block  302  of process  300  discussed above. The associated probabilities can be used in forming the sub-grammar such that a transducer employing second grammar G big    530  can produce not only appropriate media names, but also associated probabilities of the media to ensure the likeliest matching media can be selected. 
     In some examples, user-specific sub-grammars used to replace non-terminals in second grammar G big    530  can be presented as transducers that accept mono-phone words (or phone sequences) and produce words with associated probabilities as outputs. In other examples, as noted above, the loop(s) introduced in first grammar G small    420  can produce a variety of other outputs, and the sub-grammars used to replace the non-terminals in second grammar G big    530  can be configured to accept those outputs and produce words and associated probabilities from them. For example, the sub-grammars can be configured to accept mono-phone words, mono-phone word sequences, word fragments, syllables, or mixtures of mono-phone words, word fragments, and syllables from the loop(s) and produce words and associated probabilities from them. In one example, a sub-grammar corresponding to non-terminal $ContactList can be presented as a transducer G sub1  including user contacts  538  and associated probabilities. A sub-grammar corresponding to non-terminal $AppList can be presented as a transducer G sub2  including user applications  540  and associated probabilities. A sub-grammar corresponding to non-terminal $Media List can be presented as a transducer G sub3  including user media  542  and associated probabilities. It should be understood that second grammar G big    530  can include many other cascades, some of which can include the same or other non-terminals. Any other non-terminals can likewise be replaced by sub-grammars associated with a user that can be presented as transducers G subN  including lists of entities and associated probabilities, where N corresponds to the total number of distinct transducers based on particular user-specific sub-grammars. 
     With the non-terminals in G big  replaced with user-specific sub-grammars, the composition at block  306  of process  300  discussed above can be performed to generate a complete WFST for recognizing user speech. The following formula can summarize generating the complete WFST, including replace and composition functions that can occur on-the-fly at runtime:
 
CLG small   ∘G   small ∘replace( G   big   , G   sub1   , G   sub2   , G   sub3   , . . . , G   subN ).
 
In particular, the replace function can be used to replace the non-terminals in G big  with their respective transducers G sub1 , G sub2 , G sub3 , . . . , through G subN  each of which can reflect the user-specific usage data received at block  302  of process  300 ). In addition, in some examples, the replacement operation can be recursive. For example, G sub1  can be constructed during runtime by replacing non-terminals that might exist in G sub1  with other sub-grammars (e.g., G subsub1 ). For example, the following replacement operation can be performed prior to the replacement operation noted above:
 
G sub1 =replace(G sub1 , G subsub1 , G subsub2 , . . . ).
 
With the replacement operations completed, using the composition function, the user-personalized grammar transducer G big  can then be combined with the static recognition cascade with difference grammars including weighted phone loops in place of the non-terminals. The result can thus include a WFST that supports dynamically-incorporated, user-specific grammars.
 
     In some examples, some or all of the various component grammars in the WEST can be sorted. In addition, word level disambiguation labels can be used to disambiguate homophones. In this manner, the sub-grammars can, for example, remain determinizable. In addition, each sub-grammar can have its own weight scale relative to the main grammar, which can be tuned or determined empirically. 
     Referring again to process  300  of  FIG. 3 , at block  308 , the speech input received at block  304  can be transduced into a word and an associated probability using the WEST formed at block  306 . In some examples, the WEST can produce multiple candidate interpretations of the user speech. In addition, the candidate interpretations can include single words or multiple words in sequences. The WFST can also produce associated probabilities of each candidate interpretation. For example, based on the user-specific usage data (including interaction frequencies) received at block  302  and incorporated into the WFST as discussed above, the WEST can produce a user-specific likelihood that a candidate interpretation corresponds to the user speech. For instance, should a user frequently interact with a contact named “Peter,” a candidate interpretation that includes “Peter” (e.g., “Call Peter”) can have a higher likelihood than competing interpretations without a likely contact name. Similarly, should a user frequently issue a voice command to launch a calendar application, a candidate interpretation that includes “Calendar” (e.g., “Launch calendar”) can have a higher likelihood than competing interpretations without a likely application name. The personalized WEST can thus produce interpretations and associated probabilities reflecting likelihoods specific to a particular user and the user&#39;s particular device usage. 
     Referring again to process  300  of  FIG. 3 , at block  310 , a word can be output based on its associated probability. For example, the candidate word or word sequence having the highest associated probability can be output or otherwise selected as the most likely interpretation. In some examples, multiple candidates can be output. In other examples, both a candidate and its associated probability can be output, or multiple candidates and their associated probabilities can be output. In one example, the output word (or words) can be transmitted from a server to a user device (e.g., from server system  110  of system  100  to user device  102  through network  108 ). The output word(s) can then be used on the device for transcription, further processing in a virtual assistant system, execution of a command, or the like. 
     In another example, the output word(s) can be transmitted to a virtual assistant knowledge system (e.g., from user device  102  or some part of server system  110  to virtual assistant server  114 ). The output word(s) can then be used by the virtual assistant knowledge system to, for example, determine a user request. In still other examples, the output word(s) can be transmitted to a server or other device. For example, the output word(s) can be transmitted to a server or other device for use in a virtual assistant system, voice transcription service, messaging system, or the like. 
     In any of the examples discussed herein, there can be multiple approaches for receiving and storing symbols and using symbol tables for a WFST implementation. In one example, a WFST can be configured to use integers as the representative input and output symbols. Such integer symbols can be translated into human readable form using symbol tables, which can, for example, map integers to words. In some examples, symbols for sub-grammars can reside in a pre-defined symbol space that can be kept disjoint from a symbol space associated with a main grammar. For example, symbols in a sub-grammar can reside in the symbol space zero to 1000, while symbols in a main grammar can reside in the symbol space 1001 to N (where N is as large a value as needed to accommodate the main grammar). 
     In addition, in any of the various examples discussed herein, various aspects can be personalized for a particular user. As discussed above, user-specific usage data including lists of entities and associated interaction frequencies can be used to form sub-grammars that are personalized for a particular user. Other user-specific data can also be used to modify various other weighting elements in a WEST (e.g., user speech samples, voice command history, etc.). User-specific data can also be used in a virtual assistant system associated with the WEST approaches discussed herein. The various processes discussed herein can thus be modified according to user preferences, contacts, text, usage history, profile data, demographics, or the like. In addition, such preferences and settings can be updated over time based on user interactions (e.g., frequently uttered commands, frequently selected applications, etc.). Gathering and use of user data that is available from various sources can be used to improve the delivery to users of invitational content or any other content that may be of interest to them. The present disclosure contemplates that in some instances, this gathered data can include personal information data that uniquely identifies or can be used to contact or locate a specific person. Such personal information data can include demographic data, location-based data, telephone numbers, email addresses, home addresses, or any other identifying information. 
     The present disclosure recognizes that the use of such personal information data, in the present technology, can be used to the benefit of users. For example, the personal information data can be used to deliver targeted content that is of greater interest to the user. Accordingly, use of such personal information data enables calculated control of the delivered content. Further, other uses for personal information data that benefit the user are also contemplated by the present disclosure. 
     The present disclosure further contemplates that the entities responsible for the collection, analysis, disclosure, transfer, storage, or other use of such personal information data will comply with well-established privacy policies and/or privacy practices. In particular, such entities should implement and consistently use privacy policies and practices that are generally recognized as meeting or exceeding industry or governmental requirements for maintaining personal information data as private and secure. For example, personal information from users should be collected for legitimate and reasonable uses of the entity and not shared or sold outside of those legitimate uses. Further, such collection should occur only after receiving the informed consent of the users. Additionally, such entities would take any needed steps for safeguarding and securing access to such personal information data and ensuring that others with access to the personal information data adhere to their privacy policies and procedures. Further, such entities can subject themselves to evaluation by third parties to certify their adherence to widely accepted privacy policies and practices. 
     Despite the foregoing, the present disclosure also contemplates examples in which users selectively block the use of, or access to, personal information data. That is, the present disclosure contemplates that hardware and/or software elements can be provided to prevent or block access to such personal information data. For example, in the case of advertisement delivery services, the present technology can be configured to allow users to select to “opt in” or “opt out” of participation in the collection of personal information data during registration for services. In another example, users can select not to provide location information for targeted content delivery services. In yet another example, users can select not to provide precise location information, but permit the transfer of location zone information. 
     Therefore, although the present disclosure broadly covers use of personal information data to implement one or more various disclosed examples, the present disclosure also contemplates that the various examples can also be implemented without the need for accessing such personal information data. That is, the various examples of the present technology are not rendered inoperable due to the tack of all or a portion of such personal information data. For example, content can be selected and delivered to users by inferring preferences based on non-personal information data or a bare minimum amount of personal information, such as the content being requested by the device associated with a user, other non-personal information available to the content delivery services, or publicly available information. In addition, it should be understood that, in some examples, the sub-grammars discussed herein that can be derived from user-specific usage data can be compiled locally on a user&#39;s device and remain there without necessarily being transmitted to a server.  1 . 11  particular, in some examples, the user-specific sub-grammars can be generated and used by a user&#39;s device for speech recognition without necessarily transmitting personal information to another device. 
     In accordance with some examples,  FIG. 6  shows a functional block diagram of an electronic device  600  configured in accordance with the principles of the various described examples. The functional blocks of the device can be implemented by hardware, software, or a combination of hardware and software to carry out the principles of the various described examples. It is understood by persons of skill in the art that the functional blocks described in  FIG. 6  can be combined or separated into sub-blocks to implement the principles of the various described examples. Therefore, the description herein optionally supports any possible combination or separation or further definition of the functional blocks described herein. 
     As shown in  FIG. 6 , electronic device  600  can include an input interface unit  602  configured to receive information (e.g., through a network, from another device, from a hard drive, etc.). Electronic device  600  can further include an output interface unit  604  configured to output information (e.g., through a network, to another device, to a hard drive, etc.). Electronic device  600  can further include processing unit  606  coupled to input interface unit  602  and output interface unit  604 . In some examples, processing unit  606  can include a user-specific data receiving unit  608 , a speech input receiving unit  610 , a weighted finite state transducer composing unit  612 , a speech input transducing unit  614 , and a word outputting unit  616 . 
     Processing unit  606  can be configured to receive user-specific usage data (e.g., through input interface unit  602  using user-specific data receiving unit  608 ). The user-specific usage data can comprise one or more entities and an indication of user interaction with the one or more entities. Processing unit  606  can be further configured to receive speech input from a user (e.g., through input interface unit  602  using speech input receiving unit  610 ). Processing unit  606  can be further configured to, in response to receiving the speech input, compose a weighted finite state transducer (e.g., using weighted finite state transducer composing unit  612 ) having a first grammar transducer with a second grammar transducer, wherein the second grammar transducer comprises the user-specific usage data. Processing unit  606  can be further configured to transduce the speech input into a word and an associated probability using the weighted finite state transducer composed with the second grammar transducer (e.g., using speech input transducing unit  614 ). Processing unit  606  can be further configured to output the word based on the associated probability (e.g., through output interface unit  604  using word outputting unit  616 ). 
     In some examples, the one or more entities (e.g., received using user-specific data receiving unit  608 ) comprise a list of user contacts, and the indication of user interaction comprises a frequency of interaction with a contact in the list of user contacts. In other examples, the one or more entities comprise a list of applications on a device associated with the user, and the indication of user interaction comprises a frequency of interaction with an application in the list of applications. In still other examples, the one or more entities comprise a list of media associated with the user, and the indication of user interaction comprises a play frequency of media in the list of media. 
     In some examples, the weighted finite state transducer comprises a context-dependency transducer and a lexicon transducer (e.g., used in weighted finite state transducer composing unit  612  and speech input transducing unit  614 ). In addition, in some examples, the first grammar transducer (e.g., used in weighted finite state transducer composing unit  612  and speech input transducing unit  614 ) comprises a weighted phone loop capable of generating a sequence of mono-phone words. Moreover, in some examples, the associated probability (e.g., from speech input transducing unit  614 ) is based on a likelihood that the word corresponds to the speech input, wherein the likelihood is based on the user-specific usage data (e.g., received using user-specific data receiving unit  608 ). 
     In some examples, outputting the word (e.g., outputting the word from speech input transducing unit  614  through output interface unit  604  using word outputting unit  616 ) comprises transmitting the word to a user device. In other examples, outputting the word comprises transmitting the word to a virtual assistant knowledge system. In still other examples, outputting the word comprises transmitting the word to a server. 
     Although examples have been fully described with reference to the accompanying drawings, it is to be noted that various changes and modifications will become apparent to those skilled in the art (e.g., modifying any of the systems or processes discussed herein according to the concepts described in relation to any other system or process discussed herein). Such changes and modifications are to be understood as being included within the scope of the various examples as defined by the appended claims.

Metadata:
Filing Date: 20140923
Publication Date: 20161122
Grant Date: 20161122
Priority Date: 20140527
Inventors: PAULIK MATTHIAS
HUANG RONGQING
Assignee: APPLE INC
CPC Classifications: [{"code": "G10L2015/226", "inventive": false, "first": false, "tree": "[]"}, {"code": "G10L15/22", "inventive": true, "first": true, "tree": "[]"}, {"code": "G10L15/19", "inventive": true, "first": false, "tree": "[]"}, {"code": "G06F40/211", "inventive": true, "first": false, "tree": "[]"}, {"code": "G10L15/22", "inventive": true, "first": true, "tree": "[]"}, {"code": "G10L15/197", "inventive": true, "first": false, "tree": "[]"}, {"code": "G10L2015/226", "inventive": false, "first": false, "tree": "[]"}, {"code": "G06F40/211", "inventive": true, "first": false, "tree": "[]"}, {"code": "G10L15/197", "inventive": true, "first": false, "tree": "[]"}, {"code": "G10L2015/223", "inventive": false, "first": false, "tree": "[]"}, {"code": "G06F17/271", "inventive": false, "first": false, "tree": "[]"}, {"code": "G10L15/22", "inventive": true, "first": true, "tree": "[]"}, {"code": "G10L15/19", "inventive": true, "first": false, "tree": "[]"}, {"code": "G10L2015/223", "inventive": false, "first": false, "tree": "[]"}]
Family ID: 54702533