System and Method to Graphically Facilitate Speech Enabled User Interfaces

CROSS-REFERENCE TO RELATED APPLICATIONS

0001This application is related to concurrently filed, co-pending, and commonly assigned U.S. application Ser. No. ______, Attorney Docket No. 47524/P128US/10204305, entitled “ENHANCED GRAPHICAL DEVELOPMENT ENVIRONMENT FOR CONTROLLING MIXED INITIATIVE APPLICATIONS;” commonly assigned U.S. application Ser. No. 09/687,296, filed Oct. 13, 2000, entitled “GRAPHICAL PROGRAMMING LANGUAGE FOR REPRESENTATIONS OF CONCURRENT OPERATIONS;” and commonly assigned U.S. application Ser. No. 09/603,334, filed Jun. 26, 2000, entitled “ENHANCED GRAPHICAL DEVELOPMENT ENVIRONMENT FOR CONTROLLING PROGRAM FLOW,” the disclosures of which are hereby incorporated herein by reference.

TECHNICAL FIELD

0002This invention relates to interactive voice response systems and more particularly to systems and methods for facilitating speech recognition code generation into applications.

BACKGROUND OF THE INVENTION

0003Interactive voice response (IVR) systems have been in use for some time now. Typically, such systems operate such that a calling (or called) user is asked a series of questions and is prompted to give a response. At first, these responses were accomplished by the user touching a keypad number. In such systems the calling (or called) user would be prompted as follows: “Please touch one for today's flights and touch two for all other flight information.”

0004More recent system allow the user to answer verbally. Thus the user prompts for such systems would be: “Please say one for today's flights and say two for all other flight information.” An alternate prompt would be: “Please say yes if you are flying today and no if you are flying any other day.” Another alternate prompt would be: “Say the time you would like to fly.” The user would be expected to respond with, “this morning” or “five p.m.”

0005The designer of such systems must code each application such that it follows a specific script, or call flow. Tools, including graphical tools using icons, are typically used for such application call flow coding. One example of such a tool is shown in U.S. Pat. No. 5,946,485, dated Aug. 31, 1999; and U.S. Pat. No. 6,131,184, dated Oct. 10, 2000, both of which are incorporated by reference herein.

0006In such prior art call flow tools, icons are used to illustrate for the designer the pertinent details of the call flow so that the designer could rearrange the call flow, or insert other paths or options into the call flow. Thus, in the prior art there is a single icon such as icon <b>80</b>, shown in <figref idref="DRAWINGS">FIG. 8</figref>, that a user places in the call flow that represents the entire event recognition call flow. The designer could supply several parameters that are used in defining the particular event to be recognized. However, in order to change the event recognition format, a designer would have to add code to vary the structure or process which is to be followed by the standard event handled icon. In the prior art, a single icon represents a single recognition event including all actions leading to resolution of that recognition event.

0007Recently, IVR systems have begun to incorporate more complex caller voice recognition events, so that the caller might now hear the following prompt: “Please tell me your flight date and destination city.” These more complex types of recognition events are more difficult to program and to represent by a single icon.

0008Caller (talker) directed systems rely on the recognition of various responses from the calling (or called) user and can be as free-flowing as desired. Thus, a prompt could be: “Please tell me what I can do for you today.” A more typical prompt would be more specific, such as: “Please tell me what day you are flying and what flight number you are asking about.”

0009With the current state of the art, the application designer would code each of these scenarios to respond to the talker's answers. Speech recognition is then used to determine what the talker has responded. The graphical icon application tools do not work well for speech recognition applications. Today in the industry, a recognition event is handled by defining everything inside a single icon. All events that control a recognition event are packaged into a single icon. Although these icon tools exist today to provide macro level directed dialogue snipped graphically, the user does not have control to vary or supplement those singular events, except through extensive supplemental coding.

0010The call flow in speech recognition applications relies on the generation and ultimately the recognition of certain grammars. Each grammar is a collection of phrases that are passed to a system component. The system component then “listens” to the user input to determine if the user spoke one of the defined phrases. If the user speaks one of those phrases, that phrase is passed back to the application for subsequent processing within the call flow. However, the calling (or called) user could respond with a word or phrase which is out of context. Or in multiple response situations (such as “what day and time are you flying?”) the system must know and process both responses before the next step is achieved. Establishing the code and call flow processing for situations such as this, is difficult and time consuming, and would have to be repeated for each application and for any changes required in an application.

0011In the state of the art today, the user can code for the return of specific words or responses. <figref idref="DRAWINGS">FIGS. 9A and 9B</figref> show such coding for a simple situation for single-slot returns and multi-slot returns, respectively. As shown in <figref idref="DRAWINGS">FIGS. 9A and 9B</figref>, there are carats surrounding code words, and the designer must parse through the code in order to understand the operation of the call flow so that desired changes can be made. This coding is graphically cumbersome and the applications become formidable. In existing graphic packages, the prompts which hold onto the grammar definition, including the prompts, the timers, the possible behavioral responses, are woven tightly into what is called the ‘tool kit,’ and graphical constructs to represent such alternative coding is not available.

SUMMARY OF THE INVENTION

0012The present invention is directed to a system and method which incorporates into a graphical call flow tool the ability to establish call flow routines which utilize voice recognition. By representation of each individual element or step of the event handling process as individual icons, the system allows the designer to customize the call flow without extensive modification to the existing code. In essence, the prior art single, all-inclusive icon has been opened up into multiple, individual icons that represent each step of the event handling process. It is a “reverse” abstraction, bringing a higher degree of detail to the user for a higher degree of ultimate control and customization.

0013Our system and method, in one embodiment, relies on what we call a multi-slot return and how that multi-slot return is graphically illustrated to a system designer. Included in the graphical process is a loop to ensure that each response has been returned properly and that the responses to a specific question have been returned

0014A single-slot return occurs when a single response is expected from a question and a multi-slot response occurs when more than one item is to be determined from a single question.

0015In one embodiment, we graphically define the recognition event as well as the grammar definition event in a manner that exposes the call flow by showing the behaviors associated with the recognition events. The system and method allows the user the freedom of coding all the behaviors and actually displaying the behaviors that they code in the graphical drawing space.

0016By glancing at the graphical display, as opposed to reading through all of the code, the designer can see the call flow and thereby understand the call flow behavior. The system and method also facilitates modifications because the changes become simple changes to the graphical illustration. A designer then can easily add make slight changes to a message, or change a loop so that it processes three times instead of four times.

0017The foregoing has outlined rather broadly the features and technical advantages of the present invention in order that the detailed description of the invention that follows may be better understood. Additional features and advantages of the invention will be described hereinafter which form the subject of the claims of the invention. It should be appreciated by those skilled in the art that the conception and specific embodiment disclosed may be readily utilized as a basis for modifying or designing other structures for carrying out the same purposes of the present invention. It should also be realized by those skilled in the art that such equivalent constructions do not depart from the spirit and scope of the invention as set forth in the appended claims. The novel features which are believed to be characteristic of the invention, both as to its organization and method of operation, together with further objects and advantages will be better understood from the following description when considered in connection with the accompanying figures. It is to be expressly understood, however, that each of the figures is provided for the purpose of illustration and description only and is not intended as a definition of the limits of the present invention.

BRIEF DESCRIPTION OF THE DRAWINGS

0018For a more complete understanding of the present invention, reference is now made to the following descriptions taken in conjunction with the accompanying drawing, in which:

0019<figref idref="DRAWINGS">FIG. 1</figref> show an embodiment of the concept of the invention;

0020<figref idref="DRAWINGS">FIG. 2</figref> shows a single slot graphical display of a ‘no match’, ‘no input’ loop;

0021<figref idref="DRAWINGS">FIG. 3</figref> shows a multi-slot graphical display of match conditions;

0022<figref idref="DRAWINGS">FIG. 4</figref> shows the validation loop;

0023<figref idref="DRAWINGS">FIGS. 5, 6</figref>, and <b>7</b> show examples of graphical forms used to establish and control call flows;

0024<figref idref="DRAWINGS">FIG. 8</figref> shows a representation of a prior art icon; and

0025<figref idref="DRAWINGS">FIGS. 9A and 9B</figref> show existing methods of coding single- and multi-slot grammar returns.

DETAILED DESCRIPTION OF THE INVENTION

0026In the discussion that is to follow the term grammar is used to mean a phrase, or collection of phrases, that is stored in anticipation of a calling (or called) user uttering one of those phases in response to a question presented to the calling (or called) user. Thus, if the presented question is “What is your favorite color?”, the ‘grammar’ would consist of a list of colors. In response to the question: “What is your favorite color?” the user could name a color. The speech containing the color utterance would then be passed to the component that matches the received utterance (grammar) with the prestored grammar. If the answer matches any of the items in the prestored grammar then a valid indication is passed back to the application together with the color response in coded form. Also passed back to the system, is a code representing the level of confidence the system has in knowing which color was uttered. If the answer does not match the presented question (i.e., the talker said “hot”), or if the confidence level is below an acceptable threshold, then a mismatch condition occurs. The mismatch could be because the talker answered by naming a color not on the list, or the talker could have spoken a word or phase out of context, or a no-input condition could have occurred if the talker did not speak at all.

0027<figref idref="DRAWINGS">FIG. 1</figref> shows one embodiment of a system and method in which the icons are broken into smaller individual elements so that they can be “phased” where desired to form any call flow form.

0028Icon <b>11</b> would be a main icon which would control the question presented to a calling (or called) user (sometimes herein referred to as the talker). This icon will control the response from the talker. Any such response is fed to action icon <b>12</b> for processing in accordance with a grammar established for icon <b>11</b>.

0029Icons <b>101</b>, <b>1102</b>, <b>1103</b>, <b>1104</b> form a loop such that each such icon controls, for example, one of the responses expected from a user. These responses (words) can be, for example, day, time, city, etc. Each leg of the loop, such as legs <b>101</b>, <b>102</b>, <b>103</b> can have sub loops, such as sub loops <b>13</b>, <b>14</b>. Each of the such loops, in turn, can have icons controlling different responses or actions, such as no-input, no-match, etc.

0030Validation leg <b>1104</b>, as will be discussed, forces all of the legs to obtain responses before going to a next phase of the call flow.

0031The operation of the system and method of <figref idref="DRAWINGS">FIG. 1</figref> will now be discussed with reference to <figref idref="DRAWINGS">FIGS. 2, 3</figref> and <b>4</b>.

0032Turning now to <figref idref="DRAWINGS">FIG. 2</figref>, icon <b>21</b> shows what the prompt would be for one branch, branch <b>20</b>, of the call flow. <figref idref="DRAWINGS">FIG. 2</figref> shows primarily the no match, no input portions of the call flow in a graphical manner.

0033Icon <b>21</b> is a user prompt asking the user to state the desired account number two digits at a time. The spoken response from the talker is passed to voice recognition components (not shown) over path <b>202</b>. At this point, for this presented question, the grammar has been preset, and consists of numbers.

0034The system graphically displays the processing of the call flow when a word outside of the grammar is spoken, which is the no-match situation. The no-match display shows two possibilities; a mismatch <b>22</b> and a no-input <b>23</b>. As discussed above, when the talker responds with a word outside of the grammar, as shown by icon <b>22</b>, there is a mismatch condition. When no input is detected, as shown by icon <b>23</b>, there is a no-input condition. In each of these conditions, the designer can define the subroutines that will be followed.

0035Icon <b>24</b> establishes how many times the user will be prompted to restate his/her account number for the no match condition. This number can be different than for the no input condition, if desired. The designer can change the retry from three (for example) to any desired number of retries. If the maximum number of retries has occurred, the system returns an error, via icon <b>2401</b>, to the application.

0036If the set number of retries has not been met, then icons <b>2402</b> and <b>2403</b> control the message that is replayed to the talking party. These messages can be changed, if desired, each time so that the calling party does not repeatedly receive the same message. Again, the designer can modify the call flow, since the routine being followed is not buried within a single icon but is separately identified and available. For example, the message played to the caller can be based on the number of retries or on some other factor, and could include the use of databases and other table lookups.

0037Icon <b>23</b> handles the timeout condition where no input is received. The display shows the processing that could occur if the user does not respond at all to the recognition event, i.e. the user prompt.

0038Path <b>201</b> is a looping construct. The display shows lines that represent the behavior of looping which is back around to prompting icon <b>21</b>. The designer, using the system and method discussed, may, if desired, break the loop. This break could result in a call going to an operator, or a simple hang-up, or by a message being played to the caller telling the caller that the session is being terminated.

0039The no-input process call flow follows the same general approach as does the no-match call flow. Icon <b>25</b> receives a no-input signal from the underlying components (not shown) and in response thereto either timeouts, icon <b>2501</b>, if the number of tries exceeds the set limit, or plays a message via icons <b>2502</b> and <b>2503</b> as discussed above.

0040Turning now to <figref idref="DRAWINGS">FIG. 3</figref> there is shown call flow display <b>30</b> which is an example of a multiple slot call flow. In the multiple slot call flow there is defined a set of grammars which together can return to the application more than one piece of information. <figref idref="DRAWINGS">FIG. 3</figref> shows a funds transfer recognition event using a compound question having multiple portions to be answered. Icon <b>32</b> might ask: “Please say the amount of funds to be transferred, the account from which you want the funds taken, and the account into which you want the funds placed.” In response to this compound question, the caller (talker) might answer all portions of the question by saying: “I want to transfer $500.00 from my checking account to my savings account.”

0041The application, when it hears such a sentence, would need to extract the portions, such as ‘amount’, the ‘from’ account, and the ‘to’ account. So multiple pieces of information need to come back from the grammar recognizer when that sentence is received.

0042<figref idref="DRAWINGS">FIG. 3</figref> graphically displays an example of the legs that would be used. Each leg, shown by icons <b>3201</b>, <b>3202</b> and <b>3203</b> is essentially a single-slot call flow as discussed in <figref idref="DRAWINGS">FIGS. 1 and 2</figref>.

0043For example, assume the talker said, “I want to transfer from my checking account to my savings account,” but did not say the amount portion. In this situation, the speech recognizer would return the word “checking” to icon <b>3202</b>, the word “savings” to icon <b>3203</b>, and slot <b>3201</b> would remain empty. The system would come down the amount leg where it would encounter the single slot recognition event icon <b>3201</b> that asks: “What dollar amount would you like to transfer?” Assuming the caller then says the amount, the system progresses. If the caller does not answer, or answers with a word outside of the grammar, then, depending upon the repeat number, the system would timeout and terminate the call as discussed above with respect to <figref idref="DRAWINGS">FIG. 2</figref>.

0044Again, it should be noted that this is a looping construct, so the system would not leave call flow <b>30</b> until all of the values are filled. This system and method then saves the programmer from writing code because the code to control the desired routines is included in the icons that are positioned by the designer in accordance with that call flow.

0045<figref idref="DRAWINGS">FIG. 4</figref> shows call flow <b>40</b> which illustrates the validation process. Call flow <b>40</b> is essentially the same as call flow <b>10</b> (<figref idref="DRAWINGS">FIG. 1</figref>), except that a leg has been added starting with icon <b>41</b> and including icons <b>42</b>, <b>43</b>, and <b>44</b>. Call flow <b>40</b> follows the form shown in <figref idref="DRAWINGS">FIG. 1</figref>.

0046Within leg <b>41</b>, a slot is defined that is never filled by the talker since it actually is used only when the legs are all filled. Icon <b>41</b> will repeat to the caller what the caller has requested, by saying, “Do you want to transfer $500 from account XXXX to account YYYY?” Icons <b>42</b> and <b>43</b> verify that the caller has answered with the proper grammar, such as “yes”, “okay,” or an equivalent affirmative response. If the transfer is validated, icon <b>44</b> controls the flow of information to the proper location so as to control the transfer. If the transaction is not verified, then the system loops back and restarts.

0047<figref idref="DRAWINGS">FIGS. 5 and 6</figref> show one graphical representation of the implementation of <figref idref="DRAWINGS">FIGS. 1-4</figref>. <figref idref="DRAWINGS">FIG. 5</figref>, shows form <b>50</b> which deals with single fields and allows a user to indicate an initial prompt, such as “Say your account number,” <b>51</b>. The variable <b>52</b> is identified that will hold the recognition results. Field <b>53</b> allows the user to pick a grammar that is going to be active for the recognition instance defined by the form, or, if desired, the user can write his/her own grammar(s). There is a list on the form to support customizations and there can be as many grammars active as desired for this recognition instance. In the example, “number” grammar <b>503</b> is selected.

0048Form <b>50</b> also provides field <b>54</b> to hold the detail recognition results when necessary. The detail recognition results allow the user to obtain as much information as possible about the result. For example, the confidence scores for a particular recognition event and other details are available to allow the user specific processing. Thus, for any particular recognition event, the user can take the high road and trust the recognizer to provide the right piece of information or the user can take the detail road and base his/her next action on the level of detail (for example, confidence level).

0049In addition, form <b>50</b> will allow specific properties <b>55</b> to be passed to the recognizer. For example, when an account number is being requested, the recognition engine could be told the length of the number to expect.

0050Events field <b>56</b> is used to control selected events, such as, for example, time out. The user can determine the type of processing desired when a time out occurs. Also, the user can invoke a global definition, (time period), or can provide a specific period for this instance of recognition.

0051Sometimes a responding user (talker) says something that does not fit into the grammar. This is a no-match condition. The programming user might want to do something specific for a no match, such as providing a prompt with an example in it. The programming user might want to continue the answer. For example, if the recognizer believes it understood what was said, but is only 50% certain, the application can then play back the perceived value and then “listening” for a ‘yes’ or ‘no.’

0052Another type of property is confirmation thresholds themselves. What percentage of certainty is going to cause the confirmed leg to be executed as a recognition? Thus, a programmer can at every instances of speech recognition indicate what percent certainty will be tolerated at that point. For example, it is harder to recognize 123ABC, than it is to recognize Sally, a prompt name. The programmer might raise the confirmation thresholds when recognizing certain types of grammars. That is a benefit of having these properties and having them be instance related.

0053<figref idref="DRAWINGS">FIG. 6</figref> shows from 60 which is used for multiple fields which are essentially complex prompts where the application is expecting multiple pieces of information to come back from the talker. This is shown in <figref idref="DRAWINGS">FIGS. 1-4</figref> graphically. Form <b>60</b> gives the programmer the ability to define the initial prompt <b>61</b> and to define the variable <b>62</b> that is going to hold the phrase. This associates the phrase result with the slot value <b>63</b> inside a grammar because there is one grammar file that understands the entire phrase that is expected. When the event recognizer understands multiple pieces of information, it passes back that information to the application, using slots. Column <b>64</b> is called Initial Value and is used when the application already knows a particular value. Column <b>62</b> is empty on the form but let's assume a variable is put there called “My Money.” When the application is being executed and My Money has a value, then the system need not try to interpret what is said, and need not even ask the question. This is a programming construct that simplifies the amount of code needed. If the field is populated with a specific value instead of having the system say, “speak the amount for funds transfer,” the system begins by saying, “What account would you like to transfer $XX dollars from?”

0054<figref idref="DRAWINGS">FIG. 7</figref> shows confirmation form <b>70</b> which controls as validation icons <b>41</b> and <b>43</b> (<figref idref="DRAWINGS">FIG. 4</figref>). The legs on it are Yes, No and Unknown. Form <b>70</b> contains parameters that define the time out value <b>71</b>, and the units for the time out <b>72</b>, and the results <b>73</b>, which is the string of Yes, No, or an Unknown value. The reason for using a confirmation form is that the form forces the automatic changing of the grammar for further processing. For example, if an answer has been received and the question asked in return is, “Did you say, 1, 2, 3, 4, 5?”. Then, if the talker says no, the system knows that 1, 2, 3, 4, 5 is an invalid answer and those numbers (or words or phrases) are removed form the grammar for the next try. So what it means is that by using this form, the next recognition event should have improved results. This process can be applied, for example, to a ‘name’ grammar. Assume the grammar contains a bunch of names, including Mabel, Mildred, Manny. Assume also that in response to the question, “Who are you calling?”, the talker says, “mumble, mumble.” The system then says, “Did you say Mabel?”. The talker's response is “No.” The system could then remove Mabel from the grammar and ask the talker to repeat the name.

0055The selection of grammars, or the elimination of certain words from a grammar, can be very helpful. For example, assuming name recognition and assuming a male name grammar, a female name grammar and a generic name grammar. In response to a received name the recognizer returns a low confidence score, but reports that it is more confident that it was a female name and not a male name.

0056In this situation, the caller can be asked to repeat the name, but this time the male and generic grammars are off. Also, it could be that the name with the highest confidence score is Sam, but the recognizer indicates that it has a high confidence (perhaps based on other characteristics or other information) that the speaker name is a female name. Then the system would accept the female name with the highest confidence score, even though a male name (Sam) had a higher absolute score. The male-female confidence level could come from many sources, including a database of expected results dependant on other known results, or the speech itself could yield clues. Examples of such clues could be a speech pattern or power, or frequency components of the speech.

0057Although the present invention and its advantages have been described in detail, it should be understood that various changes, substitutions and alterations can be made herein without departing from the spirit and scope of the invention as defined by the appended claims. Moreover, the scope of the present application is not intended to be limited to the particular embodiments of the process, machine, manufacture, composition of matter, means, methods and steps described in the specification. As one of ordinary skill in the art will readily appreciate from the disclosure of the present invention, processes, machines, manufacture, compositions of matter, means, methods, or steps, presently existing or later to be developed that perform substantially the same function or achieve substantially the same result as the corresponding embodiments described herein may be utilized according to the present invention. Accordingly, the appended claims are intended to include within their scope such processes, machines, manufacture, compositions of matter, means, methods, or steps.