Caching apparatus for serving phonetic pronunciations (2024)

This application claims priority from U.S. Provisional Ser. No. 62/058,084, filed on Sep. 30, 2014, entitled A CACHING APPARATUS FOR SERVING PHONETIC PRONUNCIATIONS, which is hereby incorporated by reference in its entirety for all purposes.

This relates generally to natural language processing and, more specifically, to a pronunciation lexicon for natural language processing.

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's intent and operationalize the user'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.

Conventional virtual assistants use pronunciation lexicons to recognize words contained in a spoken user input. These pronunciation lexicons typically include one or more phonetic pronunciations for a predetermined set of commonly used words. Thus, when a spoken user input is received, the virtual assistant can compare the input to the phonetic pronunciations in the pronunciation lexicon to identify the word(s) in the lexicon that most closely match the spoken user input.

While conventional pronunciation lexicons can be used to effectively recognize many of the words encountered by a virtual assistant, it can be difficult to use conventional pronunciation lexicons to identify named entities, such as the name of a person, restaurant, city, movie, or the like. This is because it can be impractical for conventional pronunciation lexicons to include all possible named entities. For example, conventional pronunciation lexicons typically require each pronunciation to be entered manually by a phonetician. Entering all possible named entities in this way can be prohibitively time-consuming. Moreover, even if all named entities were added to conventional pronunciation lexicons, the large number of pronunciations may lead to confusion between similarly pronounced words. As a result, the virtual assistant may often incorrectly recognize words in the user's spoken input.

Thus, improved processes for generating, managing, and using a pronunciation lexicon are desired.

Systems and processes for generating a shared pronunciation lexicon and using the shared pronunciation lexicon to interpret spoken user inputs received by a virtual assistant are provided. In one example, the process can include receiving pronunciations for words or named entities from multiple users. The pronunciations can be tagged with context tags and stored in the shared pronunciation lexicon. The shared pronunciation lexicon can then be used to interpret a spoken user input received by a user device by determining a relevant subset of the shared pronunciation lexicon based on contextual information associated with the user device and performing speech-to-text conversion on the spoken user input using the determined subset of the shared pronunciation lexicon.

FIG. 1 illustrates an exemplary environment in which a virtual assistant can operate according to various examples.

FIG. 2 illustrates an exemplary user device according to various examples.

FIG. 3 illustrates an exemplary process for operating a virtual assistant using a shared pronunciation lexicon according to various examples.

FIG. 4 illustrates an exemplary process for generating a shared pronunciation lexicon according to various examples.

FIG. 5 illustrates an exemplary process for performing speech synthesis using a shared pronunciation lexicon according to various examples.

FIG. 6 illustrates a functional block diagram of an electronic device configured to operate a virtual assistant using a shared pronunciation lexicon according to various examples.

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 generating a shared pronunciation lexicon and using the shared pronunciation lexicon to interpret spoken user inputs received by a virtual assistant. In one example, the process can include receiving pronunciations for words or named entities from multiple users. The pronunciations can be tagged with context tags and stored in the shared pronunciation lexicon. The shared pronunciation lexicon can then be used to interpret a spoken user input received by a user device by determining a relevant subset of the shared pronunciation lexicon based on contextual information associated with the user device and performing speech-to-text conversion on the spoken user input using the determined subset of the shared pronunciation lexicon.

System Overview

FIG. 1 illustrates exemplary system 100 for implementing a virtual assistant according to various examples. The terms “virtual assistant,” “digital assistant,” “intelligent automated assistant,” or “automatic digital assistant” can refer to any information processing system that interprets natural language input in spoken and/or textual form to infer user intent, and performs 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'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'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' 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 one or more user devices 102 or 103, and a server-side portion executed on a server system 110. User device 102 or 103 can include any electronic device, such as a mobile phone, tablet computer, portable media player, desktop computer, laptop computer, PDA, television, television set-top box, wearable electronic device, or the like, and 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 or 103 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 or 103.

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's intent based on natural language input, and 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 for 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 the assistant 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.

User Device

FIG. 2 is a block diagram of a 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 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, are also 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 a 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 touch screen controller 242 and/or other input controller(s) 244. Touch-screen controller 242 can be coupled to a touch screen 246. Touch screen 246 and the touch screen 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 processes 300, 400, and 500, 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 execute the instructions. In other examples, the instructions (e.g., for performing some or all of processes 300, 400, and 500, described below) can be stored on a non-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, the 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's electronic address book, to-do lists, shopping lists, etc.) to provide the client-side functionalities of the virtual assistant.

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 224.

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's intent. The virtual assistant can also use the contextual information to determine how to prepare and deliver outputs to the user.

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 the virtual assistant server 114 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 the virtual assistant server 114. 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'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.

While not shown, user device 103 can include components similar or identical to user device 102, shown in FIG. 2.

Shared Pronunciation Lexicon

FIG. 3 illustrates an exemplary process 300 for operating a virtual assistant using a shared pronunciation lexicon according to various examples. In some examples, process 300 can be performed by a virtual assistant system similar or identical to system 100.

At block 302, one or more servers (e.g., server system 110) can generate a shared pronunciation lexicon. Generally, the shared pronunciation lexicon can be a dynamic lexicon containing any number of pronunciations for any number of words or named entities. Some or all of the pronunciations in the shared pronunciation lexicon can be received from users (e.g., users of user devices 102 and 103) supported by the one or more servers. As discussed in greater detail below, the shared pronunciation lexicon can be used by the one or more servers to recognize words or names contained in user speech from any of the supported users.

FIG. 4 illustrates an exemplary process 400 that can be performed at block 302 to generate the shared pronunciation lexicon. At block 402, one or more servers (e.g., server system 110) can receive a pronunciation for a named entity, such as a name in a contact list, a restaurant, a city, a person of interest, or the like. In some examples, the pronunciation received at block 402 can include an audio recording of a user speaking the name of the named entity as captured by a user device (e.g., user device 102 or 103). In these examples, block 402 can further include processing the audio recording to generate an acoustic model representing the pronunciation of the named entity. In other examples, the user device (e.g., user device 102 or 103) can both capture the audio recording of the user speaking the name of the named entity and can generate the acoustic model representing the pronunciation of the named entity. In these examples, receiving the pronunciation of the named entity at block 402 can include receiving the acoustic model representing the pronunciation of the named entity.

At block 404, the one or more servers can optionally determine one or more context tags for the pronunciation for the named entity received at block 402. The context tags can include textual or other descriptions regarding the applicability of the pronunciation for the named entity, such as a location, a subject matter domain, language, or the like, in which the pronunciation applies. For example, a pronunciation for a name can be tagged with a location tag identifying a country or region in which the pronunciation should be applied. This tag can advantageously be used to correctly identify the appropriate pronunciation for a word or named entity that varies depending on the location of the speaker. In another example, a pronunciation for a named entity can be tagged with a domain tag identifying a subject matter domain (e.g., sports, restaurants, etc.) in which the pronunciation should be applied. This tag can advantageously be used to correctly identify the appropriate pronunciation for a word or named entity that varies depending on the subject matter domain. For example, the name of a sports athlete can be pronounced differently than the name, spelled the same way, of a restaurant. In yet another example, a pronunciation for a named entity can be tagged with a language tag identifying a language (e.g., English, French, Italian, etc.) in which the pronunciation should be applied. This tag can advantageously be used to correctly identify the appropriate pronunciation for a word or named entity that varies depending on the language in which it is spoken. For example, the name “Jean” can be pronounced one way in English and another in French.

In some examples, the one or more context tags can be determined based at least in part on contextual information received from the user device that provided the pronunciation at block 402. The contextual information can include any type of contextual information, such as sensor information, from the device, 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 the user device (e.g., device orientation, device location, device temperature, power level, speed, acceleration, motion patterns, cellular signal strength, etc.) or the software state of the user device (e.g., running processes, user settings, user preferences, installed programs, past and present network activities, background services, error logs, resources usage, previously received user input, recently generated/received text or email messages, etc.). These and other types of contextual information can be used to determine a location, domain, language, or the like that is likely associated with the pronunciation received at block 402. For example, information currently being viewed by the user, a type of application running on the user device, contents of the user's recent email or SMS messages, or the like, can be used to determine a subject matter domain that the user likely regards as currently being relevant. In other examples, the location of the user device (e.g., as determined using a GPS or other positioning sensor) can be used to determine a location that the user likely regards as currently being relevant. In yet other examples, the user's language settings, the language used in recent emails or SMS messages, or the like, can be used to determine a language that the user likely regards as currently being relevant.

While specific uses of contextual information to determine context tags are provided above, it should be appreciated that other types of contextual information can be used to determine any type of context tag.

At block 406, the one or more servers can store the pronunciation for the named entity received at block 402 and, optionally, the one or more context tags determined at block 404 in the shared pronunciation lexicon. In some examples, the shared pronunciation lexicon can be stored locally at the one or more servers (e.g., in data and model storage 120), or can be stored remotely from the one or more servers. Process 400 can then return to block 402, where additional pronunciations for the same or different words or named entities can be received from the same or different users and user devices.

Referring back to FIG. 3, after generating the shared pronunciation lexicon at block 302, process 300 can proceed to block 304. At block 304, the one or more servers can receive contextual information from a user device (e.g., user device 102 or 103) that represents a context of the user device and/or its user. In some examples, the contextual information can include any type of contextual information, such as sensor information, from the device, 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 the user device (e.g., device orientation, device location, device temperature, power level, speed, acceleration, motion patterns, cellular signal strength, etc.) or the software state of the user device (e.g., running processes, user settings, user preferences, installed programs, past and present network activities, background services, error logs, resources usage, previously received user input, recently generated/received text or email messages, etc.). While specific types of contextual information are provided above, it should be appreciated that any other type of contextual information that represents a context of the user device and/or its user can be received.

At block 306, the one or more servers can determine a subset of the shared pronunciation lexicon that is likely relevant to the user based on the contextual information received at block 304. The subset of the shared pronunciation lexicon can generally include words or named entities from the shared pronunciation lexicon that are likely to be received from the user device based on the context of the user device. For example, if the contextual information received at block 304 includes the user's contact list, the pronunciations for some or all of the names in the contact list can be extracted from the shared pronunciation lexicon and included in the subset determined at block 306 since it may be likely that the user will provide a spoken input containing one of those names.

In another example, the contextual information can include contents of, or information associated with, recent emails or text messages generated or received by the user on the user device. In this example, a subject matter domain (e.g., sports, restaurants, music, etc.) being discussed in those messages can be determined and used to search for words or named entities in the shared pronunciation lexicon associated with those domains. Pronunciations for these words or named entities can be included in the subset of the shared pronunciation lexicon. In some examples, this can include identifying words or named entities having context tags associated with the determined domain and including pronunciations for those words or named entities in the subset of the shared pronunciation lexicon.

In yet another example, the contextual information can include information currently being displayed on the user device, such as a list of search results for nearby restaurants. In this example, the pronunciations for some or all of the restaurant names in the list can be extracted from the shared pronunciation lexicon and included in the determined subset since it can be likely that the user will provide a spoken input containing one of those names.

In another example, the contextual information can include user preferences provided by the user or inferred by the user device and/or the one or more servers about the user. For example, based on the applications loaded in the user device, the user's Internet browsing history, and contents of the user's email and SMS messages, it can be determined that the user is interested in movies, music, and food, but is not interested in sports. In this example, the pronunciations for some or all of the words or named entities associated these types of context tags can be included in the determined subset at block 306 since it may be likely the a spoken input from the user will include one of these words or named entities.

In another example, the contextual information can include information about topics that are currently relevant or of interest. This contextual information can be received from the user device and other user devices supported by the one or more servers (e.g., based on popular search queries performed on the devices), or can be identified by an operator of the one or more systems. These topics can include recent or upcoming movies, a recent or upcoming sporting event, or any other notable local or global event. In these examples, the pronunciations for some or all of the words or named entities associated these types of context tags can be included in the determined subset at block 306 since it may be likely the a spoken input from the user will include one of these words or named entities.

While specific uses of contextual information to determine a relevant subset of the shared pronunciation lexicon are provided above, it should be appreciated that any other type of contextual information that indicates a likelihood that a particular word or named entity will be relevant to the user can be used to determine the subset of the shared pronunciation lexicon.

At block 308, the one or more servers can receive audio data representing an audio input that includes user speech from a user device. For example, the audio input including user speech can be received by the user device. In some examples, the user device can receive the audio input including user speech via a microphone (e.g., microphone 230). The microphone can convert the audio input into an analog or digital representation, and provide audio data representing the audio input to one or more processors (e.g., processor(s) 204) of the user device. The user device can then transmit the audio data (e.g., via network 108) to the one or more servers.

At block 310, the one or more servers can perform speech-to-text conversion on the audio data representing the audio input using the subset of the shared pronunciation lexicon determined at block 306. For example, the one or more servers can compare the received audio data with one or more acoustic models representing pronunciations for one or more words in the subset to identify the word(s) or name(s) that most closely match the audio input. This process can exclude comparing the received audio data with the acoustic models representing pronunciations for the words and named entities that are not included in the subset determined at block 308 to reduce the number of models with which the audio input need be compared. In some examples, block 310 can further include performing the speech-to-text conversion using a common lexicon that is separate from the dynamically generated shared pronunciation lexicon and that contains frequently used words and phrases. As a result of performing block 310, the one or more servers can recognize the one or more words contained in the user speech of the audio input and convert those words to a textual representation.

Using process 300, one or more servers implementing a virtual assistant can dynamically generate a shared pronunciation lexicon (e.g., using process 400) to create a lexicon with numerous pronunciations for any number of words or phrases. Since the pronunciations can be provided by users of the system, the pronunciations can advantageously be made quickly and can include all possible variations for all words and named entities uttered by the users. The use of a shared pronunciation lexicon between multiple (in some examples, all) users of the virtual assistant system provides the benefit that each user can have access to all possible pronunciations of nearly any word or named entity without having to manually enter those pronunciations themselves. Additionally, process 300 provides the benefit of allowing the virtual assistant system to select only a portion of the entire shared pronunciation lexicon for processing a user input based on a context of the user or the user device. This advantageously allows the virtual assistant system to reduce the total number of pronunciations with which the system may compare an audio input when performing a speech-to-text conversion, while still using pronunciations for words and named entities that are most likely to be uttered by the user. This advantageously reduces the amount of time required to make the comparison and reduce the likelihood that an erroneous match will be made between similarly pronounced words or named entities.

While the blocks of process 300 are shown in a particular order, it should be appreciated that they can be performed in any order or can be performed simultaneously. For example, block 302 can continue to be performed to update the shared pronunciation lexicon with pronunciations received from users while blocks 304, 306, 308, and 310 can be performed to perform a speech-to-text conversion on a spoken user input. Additionally, it should be appreciated that the blocks of process 300 can be repeated any number of times to perform speech-to-text conversion on any number of spoken user inputs. In some examples, when processing multiple spoken user inputs from the same user device, blocks 304 and 306 may only be performed once to initially determine the appropriate subset of the shared pronunciation lexicon. Subsequently received spoken user inputs can be processed by repeating blocks 308 and 310. However, if the context of the user changes, the one or more servers can request updated contextual information and/or the user device can push updated contextual information to the one or more servers, causing blocks 304 and 306 to again be performed.

In some examples, the shared pronunciation lexicon can alternatively or additionally be used by the one or more servers to perform speech synthesis. FIG. 5 illustrates an exemplary process 500 for performing such a function. In some examples, process 500 can be performed after block 310 of process 300.

At block 502, the one or more servers can determine a response to the user speech of the audio input received at block 308 of process 300. In some examples, this can include performing natural language processing, as described above, on the textual representation of the user speech generated at block 310 to determine information (e.g., search results) or a message that is to be presented to the user in spoken form. For example, in response to a user speech requesting the name of a nearby Italian restaurant, the one or more servers can infer a user intent of the user wanting the names of Italian restaurants near the user's current location, can perform a search query to identify such restaurants, and determine a conversation string containing the name of one or more nearby Italian restaurants that conveys the requested information in natural language form.

At block 504, the one or more servers can determine a pronunciation for one or more words or named entities included in the response determined at block 502. In some examples, this can include searching the shared pronunciation lexicon or the subset of the shared pronunciation lexicon determined at block 306 of process 300 for the textual representation of the word or named entity in the determined response. In some examples, if the matching word or named entity icon includes more than one pronunciation, block 504 can include selecting one of the pronunciations that is most likely to be the correct pronunciation of that word or named entity. This determination can be made based at least in part on contextual information associated with the response determined at block 502. For example, a subject matter domain associated with the response (e.g., the restaurant domain) can be used to filter pronunciations for the word or named entity that do not relate to the relevant domain. Location, language, or other tags can similarly be used to identify the appropriate pronunciation for a word or named entity.

At block 506, the one or more servers can transmit the response determined at block 502 and the pronunciation for one or more words or named entities contained in the response determined at block 504 to the user device.

Using process 500, one or more servers implementing a virtual assistant can use a shared pronunciation lexicon to synthesize speech that is to be provided back to the users. Since the shared pronunciation lexicon can be generated from input from multiple (e.g., all) users of the virtual assistant system, the one or more servers can advantageously have access to all possible pronunciations of nearly any word or named entity. Additionally, process 500 provides the benefit of allowing the virtual assistant system to use only a portion of the entire shared pronunciation lexicon that was determined to likely be relevant to input received from the user for synthesizing speech to be provided back to the user in response. This advantageously allows the virtual assistant system to perform speech synthesis using pronunciations for words and named entities that are most likely to be provided back to the user (since the response is likely related to the contents of the user input), thereby reducing the total number of pronunciations with which the system may select from. This advantageously reduces the amount of time required to identify the appropriate pronunciation.

In some examples, the shared pronunciation lexicon can be limited in size due to storage constraints and/or limitations imposed on the shared pronunciation lexicon for performance reasons. In these examples, words and named entities (and their associated pronunciations) can be removed from the shared pronunciation lexicon to provide space for newly received pronunciations for words and named entities. In some examples, the words and named entities (and their associated pronunciations) can be selected for removal based on how recent the word or named entity was accessed (e.g., had a pronunciation added at block 406, included in a subset at block 306, used to perform speech-to-text conversion at block 310, used to perform speech synthesis at block 504, or the like). In these examples, the words or named entities that have not been accessed in the greatest amount of time can be selected for removal.

It should be appreciated that the blocks of processes 300, 400, and 500 can be performed on user device 102 or 103, server system 110, or a combination of user device 102 or 103 and server system 110. For instance, in some examples, all blocks of processes 300, 400, and 500 can be performed on user device 102 or 103. In other examples, some blocks of processes 300, 400, and 500 can be performed at user device 102 or 103, while other blocks of processes 300, 400, and 500 can be performed at server system 110. In yet other examples, all blocks of processes 300, 400, and 500 can be performed at server system 110.

Electronic 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 a touch screen display unit 602 configured to display a user interface and to receive touch input, and a sound receiving unit 604 configured to receive sound input. In some examples, electronic device 600 can include a speaker unit 606 configured to generate sound. Electronic device 600 can further include a processing unit 608 coupled to touch screen display unit 602 and sound receiving unit 604 (and, optionally, coupled to speaker unit 606). In some examples, processing unit 608 can include first pronunciation receiving unit 610, first pronunciation storing unit 612, second pronunciation receiving unit 614, second pronunciation storing unit 616, third pronunciation receiving unit 618, third pronunciation storing unit 620, context receiving unit 622, subset determining unit 624, audio data receiving unit 626, speech-to-text unit 628, response determining unit 630, pronunciation determining unit 632, transmitting unit 634, and deleting unit 636.

Processing unit 608 can be configured to receive (e.g., using first pronunciation receiving unit 610), from a first user device, a pronunciation for a first named entity. First pronunciation storing unit 612 can be configured to store the pronunciation for the first named entity in a shared pronunciation lexicon. Second pronunciation receiving unit 614 can be configured to receive, from a second user device, a pronunciation for a second named entity. Second pronunciation storing unit 616 can be configured to store the pronunciation for the second named entity in the shared pronunciation lexicon.

In some examples, first pronunciation storing unit 612 can be configured to store the pronunciation for the first named entity in the shared pronunciation lexicon by determining one or more context tags for the pronunciation for the first named entity; and storing the pronunciation for the first named entity in association with the determined one or more context tags.

In some examples, the one or more context tags include a location tag identifying a location associated with the pronunciation for the first named entity.

In some examples, the one or more context tags include a domain tag identifying a subject matter domain associated with the pronunciation for the first named entity.

In some examples, the one or more context tags include a language tag identifying a language associated with the pronunciation for the first named entity.

In some examples, third pronunciation receiving unit 618 can be configured to receive, from a third user device, a second pronunciation for the first named entity. In some examples, third pronunciation storing unit 620 can be configured to store the second pronunciation for the first named entity in the shared pronunciation lexicon.

In some examples, context receiving unit 622 can be configured to receive, from a fourth user device, a context of the fourth user device. In some examples, subset determining unit 624 can be configured to determine a relevant subset of the shared pronunciation lexicon based on the context of the fourth user device. In some examples, audio data receiving unit 626 can be configured to receive, from the fourth user device, audio data representing user speech. In some examples, speech-to-text unit 628 can be configured to perform speech-to-text conversion on the audio data using the determined relevant subset of the shared pronunciation lexicon to generate a textual representation of the user speech.

In some examples, speech-to-text unit 628 can be configured to perform speech-to-text conversion on the audio data using the determined relevant subset of the shared pronunciation lexicon without the use of portions of the shared pronunciation lexicon not included in the determined relevant subset of the shared pronunciation lexicon.

In some examples, subset determining unit 624 can be configured to determine the relevant subset of the shared pronunciation lexicon based on the context of the fourth user device by determining to include, in the relevant subset of the shared pronunciation lexicon, one or more pronunciations for named entities in the shared pronunciation lexicon that are associated with a context tag related to the context of the fourth user device.

In some examples, the context of the fourth user device includes a contact list stored on the fourth user device. In these examples, subset determining unit 624 can be configured to determine the relevant subset of the shared pronunciation lexicon based on the context of the fourth user device by determining to include, in the relevant subset of the shared pronunciation lexicon, one or more pronunciations for named entities in the contact list that are also in the shared pronunciation lexicon.

In some examples, response determining unit 630 can be configured to determine a response to the user speech, wherein the response comprises a named entity. In some examples, pronunciation determining unit 632 can be configured to determine a pronunciation for the named entity using the determined relevant subset of the shared pronunciation lexicon. In some examples, transmitting unit 634 can be configured to transmit the response and the pronunciation for the named entity to the fourth user device.

In some examples, deleting unit 636 can be configured to delete one or more pronunciations for a named entity in the shared pronunciation lexicon that has least recently been accessed.

In some examples, the pronunciation for the first named entity includes an audio recording of a user associated with the first user device speaking the first named entity. In these examples, first pronunciation storing unit 612 can be configured to store the pronunciation for the first named entity in the shared pronunciation lexicon by: generating an acoustic model representing the pronunciation for the first named entity based on the audio recording, and storing the acoustic model in the shared pronunciation lexicon.

In some examples, the pronunciation for the first named entity includes an acoustic model representing the pronunciation for the first named entity generated by the first user device.

As described above, one aspect of the present technology is the gathering and use of data available from various sources 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 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 advertisem*nt 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 to not 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 lack 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.

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. Such changes and modifications are to be understood as being included within the scope of the various examples as defined by the appended claims.

Caching apparatus for serving phonetic pronunciations (2024)
Top Articles
Latest Posts
Article information

Author: Geoffrey Lueilwitz

Last Updated:

Views: 5675

Rating: 5 / 5 (80 voted)

Reviews: 95% of readers found this page helpful

Author information

Name: Geoffrey Lueilwitz

Birthday: 1997-03-23

Address: 74183 Thomas Course, Port Micheal, OK 55446-1529

Phone: +13408645881558

Job: Global Representative

Hobby: Sailing, Vehicle restoration, Rowing, Ghost hunting, Scrapbooking, Rugby, Board sports

Introduction: My name is Geoffrey Lueilwitz, I am a zealous, encouraging, sparkling, enchanting, graceful, faithful, nice person who loves writing and wants to share my knowledge and understanding with you.