Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
  • G06N3/00—Computing arrangements based on biological models
  • G06N3/004—Artificial life, i.e. computing arrangements simulating life
  • G06N3/006—Artificial life, i.e. computing arrangements simulating life based on simulated virtual individual or collective life forms, e.g. social simulations or particle swarm optimisation [PSO]
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
  • G06N20/00—Machine learning

Definitions

• the present invention relates to virtual robots and, in particular, to virtual robots conversing with users in a natural language.
• ELIZA One early attempt at simulating natural language skills included a program called ELIZA.
• An input template might, for example, take a group of related keywords and lump them together for the purposes of responding. Thus, words like "father, mother, brother, sister” might be grouped together for a response that relied on the concept of "family”.
• ELIZA familiar words were recognized while the rest of the sentence was ignored and a response was generated based on the matched keywords.
• ELIZA solved this problem by associating a "rank number" for each keyword. ELIZA would then select the highest ranked word in the sentence for matching. This mechanism for resolving multiple template matches, although very easy to implement, is relatively unsophisticated in adequately capturing the semantic meaning of natural discourse.
• “virtual robots” are software programs that interact and/or communicate with users (human, machine or otherwise) that take actions or make responses according to input from these users. More sophisticated BOTs have since been developed to capture a deeper sense of a particular discourse's meaning. As these BOTs became more sophisticated, more processing work needed to be accomplished to capture an adequate world knowledge (albeit about a limited range of topics) and linguistic knowledge.
• One of the major drawbacks is that early BOTs were written in very specific computer languages, such as C, PASCAL and the like. Thus, in order to create BOTs, its creator would need to author in this programming language. Additionally, modification of such BOTs were just as cumbersome ⁇ any change to a BOT would need to be made to source code in a complex programming language to be subsequently recompiled.
• pronoun Another example is the "pronoun” problem.
• a human user can use the pronoun "it” to refer to an object that has long been discussed, but not immediately. Humans typically look for other semantic clues in the conversation to correctly bind the word "it” to the object meant. Early BOTs lacked adequate features to decipher these semantic clues to glean the correct meaning.
• Mauldin describes "activation networks" that are networks of response nodes that are connected to other responses through weighted edges. Prior to operation, an activation network would be created or instantiated by defining a list of subject-response nodes, whereby any given subject that may be discussed by a human user would elicit a given response as defined by a node. Different, but related, subject-response nodes would be connected via edges having a pre-defined weight. Subject-response nodes would themselves carries an activation numeric value that would vary during the course of operation of the BOT. As the subject discussed by the human user matches a given subject of a node, that node's activation value would increase. Similarly, the activation value of adjacent subject-response node to that first node might also increase or decrease according to the weight given their connecting edge.
• the main drawback with activation networks is their difficulty in creating and maintaining them. For example, in designing the initial network, it is difficult to accurately assign any meaningful activation values for particular nodes and the weights accorded to their edges. Additionally, it is difficult to debug such systems because any adjustment of the weights and values will have unpredictable effects later.
• the problem is that the numerical assignment of natural language topics is a hard task to accomplish with meaningful results.
• the BOT script allows more than one response to match an input, and does not provide any explicit total ordering on the possible responses
• the BOT execution system might present all of the possible responses to the user, either in ordered or unordered form, or it might select one, or several, of the possible responses. In the case where the BOT execution system is either ordering the possible responses or selecting some subset of the responses, the execution system must have an automated way of deciding among the set of possible responses.
• automatic pronoun replacement is very effective for the pronouns "he”, “she”, “him”, and “her”, but does not work effectively in practice for other pronouns such as “it”, “they”, “that”, and “you”, due to the frequency with which these words are used in senses other than as pronouns.
• the focus of attention stack is generally successful at distinguishing among multiple answers to a single question (such as “what is it?") but lacks any effective way of deciding whether such an answer is preferable to a default response such as "I don't know.” For instance, suppose there is one topic that answers the question “where is it?" if the user has been discussing Neuromedia, but no topic that answers the question "where is it?" when “it” refers to San Francisco.
• a BOT is to be deployed in a publicly accessible way such as a web page or chat site
• input refers to any description of a situation the BOT may encounter; although the most common inputs are textual inputs from users, inputs can be actions taken by users, external circumstances, or even events internal to the BOT such as an internal alarm clock.
• the person or organization that is deploying the BOT can be more certain of its likely performance, and errors can be detected in advance that might otherwise result in mistakes that could mislead users interacting with the BOT and/or reflect poorly on the authors or deployers of the BOT. Therefore, there is a need in the art to have a means of automatically verifying the performance of a BOT that allows the creation of the testing information simultaneously with the development of the BOT and that allows the BOT author to easily modify the testing information as the BOT is modified. There is also a need for the verification mechanism to be given sufficient information to provide useful diagnostic output when an error is found, in addition to simply reporting the error.
• a virtual robot as provided according to the principles of the present invention encompasses categories and topics of natural conversation that can be encoded in a natural "script language". During the course of operation, these categories are activated according to the conversation taking place with a user. Different categories are focused at different times according to changes in the conversation.
• the present invention provides both automatic and explicit mechanisms for focusing categories and topics during the course of conversation. Additionally, if more than one category seems appropriate to answer a particular user statement, the present invention provides mechanisms for selecting the most appropriate response. Similarly, the present invention provides mechanisms for verifying the accuracy and appropriateness of the virtual robot's response by encoding test examples into the virtual robot script.
• Figure 1 depicts a suitable operating environment for the purposes of the present invention.
• Figure 2 depicts different operating environments for the purposes of the present invention wherein the connection to user 116 is via an intranet or internet connection.
• FIG. 3 depicts yet another operating environment wherein the BOT processor is merely a client of another server, such as a chat room or virtual world server.
• Figure 4 expands the view of one embodiment of the runtime executive suitable for the purposes of the present invention.
• Figure 5 expands the view of an embodiment of the robot object suitable for the purposes of the present invention.
• Figure 6 describes the content of a category as embodied in a robot object.
• Figure 7 expands the view of user record as shown in Figure 4.
• Figure 8 expands the view of local variables as found in Figure 4.
• Figure 9 shows a view of one embodiment of a program object that is used to select a category given a user input, suitable for the purposes of the present invention.
• Figure 10 expands the view of the structure corresponding to a single condition-action block in the BOT script, as used in Figure 9.
• Figure 11 expands the view of the structure corresponding to a single low-level condition in a BOT script, as used in Figure 10, suitable for use in a category selection system such as that shown in Figure 9.
• Figure 12 shows a view of one embodiment of a compound condition, suitable for use in a category selection system such as that shown in Figure 9.
• Figure 13 expands the view of a tester for user properties shown in Figure 9.
• Figure 14 shows a view of one embodiment of a node in a pattern-matching structure, suitable for efficient parallel pattern-matching in a category selection system such as that shown in Figure 9.
• Figure 15 shows a data structure created from a particular BOT script for pattern- matching in a category selection system.
• Figure 16 shows a hierarchy of conditions and low-level blocks created from a particular BOT script for use in condition evaluation in a category selection system.
• Figure 17 expands the view of one part of the data structure shown in Figure 15, showing details that were simplified in Figure 15.
• Figure 18 depicts one view of an overall process of the use of the verification mechanism.
• Figure 19 depicts the overall behavior of the verification mechanism.
• Figure 20 depicts the detailed behavior of the verification mechanism when applied to a particular input that is to be verified.
• Figure 21 depicts the detailed behavior of the verification mechanism when applied to a special case of conditions that are to be verified in a particular sequence
• Figure 22 depicts the structure that is created for the verification of a particular sequence of conditions discussed below.
• Figure 23 shows the architecture for automatic learning of features in the context of the present embodiment of the present invention.
• Figure 24 shows the feature extractor of the learning mechanism.
• Figure 25 shows the learner module of the learning mechanism.
• Figure 26 shows the report module of the learning mechanism.
• Figure 27 shows the code generation module of the learning mechanism.
• Figure 28 shows the process of feature extraction in greater detail, following the processing of one raw data sample.
• Figure 29 shows the way of computing conditional probabilities of labels on features.
• Figure 30 depicts the data flow of the learning process.
• robot is used interchangeably with “BOT” throughout the remainder of this application.
• BOT refers to any program which interacts with a user in some fashion, and should not be assumed to refer only to physically embodied robots.
• Front end 102 is generally the environment in which a human user 116 consults a virtual BOT interface 114 via a computer 112 that may be connected to the BOT processor via a communications link, such as through a server connected to the Internet or alternatively directly connected to BOT processor 100. It will be appreciated that many other means of connection to BOT processor 100 are well known to those skilled in the art and that the present invention should not be limited to the any particular aspects of the general operating environment as disclosed herein.
• human user 116 connects to a site whose interface of first impression is a virtual BOT interface 114.
• BOT interface 114 is an instantiation of a process that is spawned by BOT processor 100 via connection 110.
• BOT processor 100 itself may comprise connection 110; runtime executive process 106, compiler 107, and a set of BOT programs 108.
• runtime executive 106 executes an interaction routine that guides the discussion that occurs between user 116 and BOT processor 100.
• a two way communications dialogue occurs between user 116 and BOT processor 100 wherein user 116 may ask questions, make declarative statements and other normal communications patterns that humans typify.
• "communications" is to be very broadly interpreted. Indeed, suitable communications could be in the form of written or spoken language, graphics, URL's or the like that may be passed to and from a user to an automatic interface program, such as the present invention.
• runtime executive 106 parses the statements and questions generated by the user and responds according to a set of BOT programs 108.
• BOT programs 108 are typically created at the back end 104 as a set of "scripts" that the BOT processor will tend to engage in with user 116.
• the site using BOT processor 100 is a site for a reseller of personal computers, then BOT processor 100 should be designed to handle questions and discussions concerning personal computers and their peripherals in general.
• the back end 104 will generate scripts that will guide the discussion concerning many computer-related topics.
• These script programs 108 are then compiled by compiler 107 and the compiled code is incorporated into runtime executive 106.
• Supervisor 122 analyzes the information at 118 and 120 with an eye towards optimizing the performance of the runtime executive.
• supervisor 122 could be another human, deciding if the semantics captured by the system needs to be upgraded in response to a dialog transcript that has occurred. If so, supervisor 122 could optionally invoke an editor 124 to edit the Gerbil programs that represent the semantic framework of the runtime executive. These programs would then be re-complied and incorporated into the runtime executive.
• Supervisor 122 could be a software program (as opposed to another human) that would automatically seek to analyze the performance of the runtime executive and make corrections to the runtime executive through the editing process.
• Figures 2 and 3 depict slightly different operating environments for the purposes of the present invention.
• Figure 2 depicts a situation wherein the BOT processor 200 connects to user 116 is via an intranet or internet connection e.g. web connector 210.
• web connector 210 may thus spawn a Java applet 216 inside of an HTML page 214 to provide the two-way communications as discussed above.
• Java applets embedded in HTML pages is well known to those skilled in the art.
• HTML page 214 might communicate directly with web connector 210 via a CGI connection or some other well-known connection protocol.
• the BOT server can accept HTML requests directly. In such cases, persistent state information can be tracked by a "cookie" set in the web browser or other means.
• FIG. 3 depicts a situation wherein the BOT processor 300 is merely a client of another server, such as a chat room or virtual world server, as depicted by server 320.
• BOT processor 300 is connected to server 320 via a chat/virtual world connector 310 in much the same fashion as any client would connect to a server site.
• Users 116 that desire to talk or converse with the BOT processor 300 interact through their client connections 314 in much the same fashion as any client-to-client communications that would be effected on server 320.
• runtime executive 106 embodies the necessary information to maintain a reasonable conversation with human users to answer their inquiries and to carry on a general discourse with them on a set of topics. These topics are created by the back end in the form of script programs 108 that are compiled (or interpreted) and incorporated into runtime executive 106.
• script programs may be written by human designers having little or no formal programming experience. It will be appreciated that script programs can also be written by automated learning programs or through partially automated script creation tools, and that the present invention should not be limited to human-written script programs. Two exemplars of such script programs are given below in Table 1.
• ⁇ Definition> ⁇ PatternDe >
• ⁇ AttributeDef>
• ⁇ CatListType> TopicList
• ⁇ AttributeDel Attribute ⁇ memref>
• Patterns are used to assign a name to a fixed string. The name can then be used in place of the string throughout the program, for readability and ease of modification.
• a PatternList is used to assign a name to a list of strings
• a TopicList, ScenarioList, or CategoryList is used to assign a name to a list of category names (see below.)
• Attribute declarations are used to declare attributes so that information about them can be displayed through various debugging functions. Declaration of attributes is optional; attributes can be used without being declared.
• An attribute declaration can also assign a "specificity" value that is used when the attribute is tested using IfRecall or any matching condition. If an attribute is not declared, or is not given a specificity value in its declaration, it is given the default specificity value of 2000.
• OtherExamples declarations define additional arguments for a particular example statement. These additional arguments are tested whenever the original example is tested using the automatic verification mechanism.
• An OtherExample declaration can also include the keyword WhenFocused to indicate that the arguments are context-sensitive examples.
• a Subjectlnfo declaration is used to assign pronoun replacement pairs to subjects, ordinarily subjects that have been assigned to one or more topics in the BOT script; the Subjectlnfo declaration has no effect for subjects that are not defined.
• the pronoun and replacement can be any string. However, the invention is most commonly used for replacing the values of common English pronouns such as "he”. It is illegal for the same pronoun to be included more than once for a given subject, or to declare subject information for a subject more than once.
• a category is either a topic or a scenario.
• a topic is used to process user statements, while a scenario is used to process user actions.
• the term "category” is used to generically refer to a topic or scenario.
• Categories are divided into four types, priority, standard, default, and sequence, according to the label preceding the word "topic" or "scenario".
• a category that is not labeled is a Standard type.
• All priority categories are executed first, in the order in which they appear in the program.
• All standard categories are executed.
• the order in which standard categories are executed changes dynamically depending on the execution of the program, and is described in the next paragraph.
• all default categories are executed, in the order in which they appear in the program. Sequence categories are executed only when explicitly accessed in a SwitchTo statement.
• Standard categories are executed according to a "best-fit" matching mechanism, in which ties are broken according to an ordered list that initially corresponds to the order in which they appear in the program.
• a standard category is executed, it, and other categories that share at least one Subject, is moved to the front of the standard category list (and so will be executed first on the next input.)
• the order of the standard category list can also be changed by commands within the program, as described below.
• Categories can also be temporarily suppressed, in which case they are not executed at all. If the keyword Suppressed appears in front of the category definition, it is initially suppressed. Category suppression is discussed further below.
• each category is a list of conditional blocks. These conditional blocks are executed in the order found in the category. If the condition of a conditional block is false, execution goes on to the next conditional block in the category, or to the next category if there are no further conditional blocks. If the condition is true, the commands and conditional blocks inside the block are executed, and further behavior of the program is dependent on the keyword which ends the conditional block. If it ends with Done, execution ceases until the next input occurs (unless an InterruptSequence has been executed; see below.) If it ends with Continue, execution continues with the next conditional block in the category, or the next category if there are no further conditional blocks.
• nextScenario If it ends with NextTopic/NextScenario, the rest of the current category is skipped and execution continues with the next category. If it ends with TryAgain, the most recent WaitForResponse within the block is executed (it is an error to end a block with TryAgain if it does not contain a WaitForResponse.) If it ends with SwitchBack, execution resumes immediately following whichever SwitchTo statement switched to the current block. It is an error to end a block with SwitchBack if the block is not inside a Sequence topic.
• Conditional blocks can be combined using the Otherwise keyword; if the first condition is true then the condition block(s) that follow the Otherwise keyword are not executed. This behavior is similar to the behavior of an "else" command in C and similar programming languages.
• the top level of a category may contain one or more MemoryLock statements. Each MemoryLock statement asserts that the value of one or more associative memory elements should only be changed within that category. If an associative memory key ?x is
• the top level of a category may contain one or more Subjects statements. Each asserts that the given subjects are subjects of the topic. If a non-IF command within the body of the topic is executed, all topics which share at least one Subject with the topic are brought to the front of the focus of attention.
• a condition can either be a basic condition (described below) or a Boolean combination of basic conditions.
• a Boolean combination of basic conditions that includes both and and or keywords must use parentheses to prevent possible ambiguity; there is no built-in operator precedence between and and or in GeRBiL.
• the Boolean not operator is implemented within the basic conditions; there is no explicit not keyword that applies to conditions.
• the IfChance condition with no numeric argument is a probabilistic condition that has the same likelihood of being true as all the other argument-less IfChance statements immediately before or after it. Finally, the Always condition is simply always true.
• condition clause There are four basic types of condition clause.
• Negated matching keywords such as DoesNotContain, are given their own special category, in order to prevent "double negative” conditions.
• the Heard and NotHeard keywords are shortcuts equivalent to the commonly used condition "?WhatUserMeant Contains”.
• Second, Recall and DontRecall are used to test whether elements of the user memory have been set or not, and are most commonly used in practice for testing flags that are set by libraries, for instance to indicate the type of question or statement that is being processed.
• ⁇ MatchingListArg> ⁇ patlistobj>
• ⁇ PosMatchingList> ⁇ PosMatchingListArg> [[and
• a matching list is a list of pattern list objects (single expressions evaluating to lists of strings; see below) separated by and, and not, or or. (The keyword and and the ampersand character (&) are interchangeable, as are the keyword or and the comma.)
• a matching list serves as the right-hand-side of a matching expression. Parentheses must be used to prevent ambiguity any time a memory reference list contains both and and or. Finally, a positive-only matching list does not allow the use of and not, in order to prevent double negatives such as "DoesNotContain X and not Y".
• ⁇ MemList> ⁇ MemListArg> [[and
• ⁇ MemListArg> ⁇ memref>
• ⁇ PosMemList> ⁇ PosMemListArg> [[and
• a memory reference list is a list of one or more memory references separated by and, and not, or or. (The keyword and and the ampersand character (&) are interchangeable, as are the keyword or and the comma.) Parentheses must be used to prevent ambiguity any time a memory reference list contains both and and or. Finally, a positive-only memory reference list does not allow the use of and not, in order to prevent double negatives such as "DoesNotContain ?X and not ?Y"
• Focus ⁇ catlist> Focus Subjects ⁇ string> [, ⁇ string>]*;
• SayToConsole is a Say statement whose output is directed to the console window and log file.
• SayToFile is a Say statement whose output is directed to a file specified in the command.
• Trace is a Say statement whose output is directed to the console window and log file, and only appears when the script is being run in various debugging modes.
• ForgetOneOf, RememberOneOf, and Remember... IsOneOf are the nondeterministic equivalents of Forget, Remember, and Remember.. Is, respectively.
• Suppress takes a list of categories as arguments and suppresses each of its argument categories so that they are no longer executed on any input.
• Recover takes a list of categories as arguments and reverses the effect of a Suppress command.
• Focus takes a list of categories as arguments and places them at the front of the ordered category list.
• Focus Subjects takes a list of subjects as arguments and places all categories which cover at least one of those subjects (as defined with a Subjects command in the top level of the category) at the front of the ordered category list.
• WaitForResponse halts execution in the same way as a Done statement but resumes at the same point on the next input.
• InterruptSequence can only be used within a Sequence topic, and temporarily halts execution of the current topic while all of the standard and default topics are executed. When a Done is reached, or when all of the standard and default topics are completed, execution resumes, without waiting for further input, within the Sequence topic.
• a SwitchTo command immediately transfers control of execution to the named category.
• a SwitchToOneOf command chooses one of its arguments at random and executes a SwitchTo on it. Example statements do not have any immediate effect, but are used in automatic verification.
• ⁇ pat> ⁇ string>
• a pattern is anything that evaluates to a string. It can be an explicit string (indicated with quotes), the name of a Pattern object, an associative memory reference, a reference to a "star buffer element" (set according to wildcard characters appearing in template patterns within pattern matching conditional statements), or a concatenation of any of the above.
• ⁇ patlistobj> ⁇ pat>
• a patternlist object is any single expression that evaluates to a list of zero or more strings. It can be a single pattern, the name of a PatternList object, a PatternList enclosed in parentheses (also known as an "implicitly defined PatternList" since it is never explicitly given a name), a PatternList enclosed in curly brackets (indicating that the element or elements included within the brackets are "optional"), or a concatenation of any of the above.
• the value of the concatenation of two lists of strings is a list consisting of the concatenation of each element in the first list with each element of the second list.
• a symbol is a string of alphanumeric or underscore characters, beginning with a letter. Symbols are not case sensitive.
• a pattern list is anything that evaluates to a list of strings. It consists of one or more
• PatternList objects separated by strings. Since each PatternList object may have a value that is a list of strings, the value of the PatternList is the value of all the elements appended together.
• a category reference is either an explicit string containing the name of a category, the keyword This (referring to the category in which it appears) or the name of a CategoryList (or TopicList or ScenarioList) object.
• a category list is simply a list of categories or CategoryList objects separated by commas.
• a reference to the associative memory is normally indicated by a ? followed by the name of the key. Such references are normally particular to the user whose input is being processed.
• a reference to the associative memory for another user can be made by putting a pattern referring to the other user between the ? and the key. The reference to the other user is separated from the key by a colon.
• a memory reference list is simply a list of memory references separated by commas.
• the "star buffer” contains the substring of an input string which matched each *, #, %, or & wildcard character in the template pattern in the most recent successful match. References to this star buffer consist of a symbol (*, #, &, or %) followed by a number. *n refers to the substring which matched the Nth * wildcard character found in the template, and so on. *match refers to the substring of the input string that matched the entire template pattern.
• the index for a SequenceExample statement is an integer followed by zero or more strings of alphanumeric characters, separated by periods.
• the second aspect of the example script programs is that the scripts themselves embody a particular universe of discourse reflective of the subject matter concerning the site itself — e.g. a BOT for a site of a reseller of personal computer should "know” something about computers and their peripherals.
• These script programs are written in an action-response type style wherein the actual language supplied by the user embodies an "action” to which the "response” is written into the script program itself.
• Scripts in the present embodiment are written generally by site administrators (human or otherwise) by defining a list of "categories" in which the site will be well conversant. Categories may comprise "topics” that are recognizable by the runtime executive. Topics, in turn, may comprise patterns or words that are matched against the stream of input communication (in either spoken or written or any other suitable form of communication) from the user.
• script programs are compiled by compiler 107 in Figure 1.
• these script programs may be iteratively tweaked to improve the interaction with human users by a re-edit and re-compile process.
• compiler techniques sufficient to implement the above-listed BNF language description are well known to those skilled in the art and that the present invention should not be limited to any particular compiler techniques.
• Runtime executive 106 comprises local variables 402, robot object 404, and a list of user records 406.
• Robot object 404 is that part of runtime executive 106 that is incorporated by the compilation process described above. Although robot object 404 may be changed via the re-edit and re-compilation process as mentioned, during runtime, robot object 404 typically does not change whilst in conversation with user 116.
• the list of user records 406 is provided because the BOT processor could be in conversation with multiple users simultaneously and therefore needs to maintain the state of each on-going conversation. The state for each such conversation is maintained in a user record 406. Similar user records can also be used to store the state of the robot and as test users for automated testing routines.
• runtime executive 106 maintains local variables 402 that are used during the processing of a single user input.
• TABLE 3 is a listing of the C++ header file that embodies runtime executive 106.
• LPCTSTR Message void ConsoleOutput(OutputLineType MessageType, CConsoleData* MessageData); es output to the console void PushConsoleOutput(ConsoleOutputType OutputType); void ClearConsoleOutputO; void PushConsoleOutputToString(ConsoleOutputType OutputType, CString& OutputString);
• robot object 404 corresponds to ProgramExecutable, which is of type CExeStruct.
• Figure 5 expands the view of robot object 404 as shown in Figure 4.
• Robot object 404 comprises several types of categories. These categories inherently maintain a priority by which runtime executive 106 processes inputs. For example, in Figure 5, four types of categories are depicted: priority categories 510, standard categories 520, default categories 530, and sequence categories 540.
• priority categories 510 When an input comes into the BOT processor, the input is processed through a series of categories. First, the priority categories are processed to determine whether there is a response that will be generated by the current input.
• These priority categories are processed, in the present embodiment, in the order in which they appear in the runtime executive.
• Sequence categories 540 are also included in the robot object 404 but are not executed unless explicitly executed by a SWITCH-TO statement as described below. In the present embodiment, sequence categories are typically employed to perform a number of pre-defined sequential communications with a user to effect a desired result. For example, having the BOT take an order for tickets to an event, how many such tickets, credit card information to purchase such tickets, etc. is readily implemented as a sequence category.
• Such a sequence category would be SWITCHed-TO if prompted by a user inquiry to buy tickets. It will be appreciated that other hierarchies of categories may be defined and order of execution selected. It suffices for the purposes of the present invention that some hierarchy of categories is defined and that one or more of the mechanisms disclosed below be employed using one or more of such categories.
• Figure 5 also contains subject-name to category map 550, which describes the categories associated with each subject found in a SUBJECTS command in one or more categories. This map helps to implement the Focus Subjects command and automatic focus mechanism, as described below.
• Figure 6 describes the content of a category 502.
• Category 502 comprises body 610 and subject names 630.
• Body 610 is a list of pointers to condition-action blocks.
• Such a condition- action block is a representation of an IF-THEN block found a script program.
• Subject names 630 are a representation of a listing of SUBJECTS that may optionally be found in a script program. As will be discussed in greater detail below, subject names 630 are used to focus the attention of the BOT processor on other categories similar to the category being processed.
• Figure 7 expands the view of user record 406 as shown in Figure 4.
• User record 406 comprises category attention focus list 710, category suppress list 720, user attribute memory 730, continuation records 740, and active subject list 750.
• attention focus list 710 is an ordered list comprising the standard categories 520 found in robot object 404. More generally speaking, however, an attention focus list could be implemented as a much broader list of any number of categories, as opposed to any single type of category. Indeed, for the purposes of the present invention, an attention focus list is an ordering of categories that, by virtue of their ordering, may affect the execution of an automatic interface program (i.e. BOT).
• BOT automatic interface program
• lists are implemented as CTypedPtrLists, however, lists can be readily implemented in hash tables, arrays, linked lists, or other known methods.
• the ordering of categories within the attention focus list 710 may be different for different users and reflects the state of the BOT processor's conversation with the particular user.
• the categories at the top of the list 710 represent areas of discourse in which the BOT processor is currently focused.
• the attention focus list 710 for that new user corresponds exactly to the standard categories list 520 — which in turn corresponds to the order in which TOPICS are found in the script program.
• Category suppress list 720 is a list of categories that have been suppressed explicitly in the script program. Suppression of categories can occur a number of ways: suppressed categories may be initially listed as suppressed in the script program or categories may be subsequently suppressed by execution of a particular action in a script program. If the user touches upon a suppressed topic, then the suppressed category is not executed by the BOT processor. This suppress feature allows the BOT creator to have greater control over the BOT's "personality" as presented to the user.
• User attribute memory 730 allows the BOT processor to remember certain attributes of the user that it has learned during the course of the conversation. For example, the gender, the telephone number, the credit card number, the address of the user may be particular fields found in user attribute memory 730.
• Continuation records 740 are used primarily when the BOT processor has interrupted the execution of a category and may eventually wish to resume execution of said category. Such interruptions can occur as a result of a WaitForResponse statement (in which case the BOT processor has made a query of the user and is awaiting a response), an InterruptSequence statement (in which case the BOT processor has temporarily halted processing of the current category), or a SwitchTo statement (in which case the BOT processor may eventually return to the category containing the SwitchTo statement after executing a SwitchBack command.)
• continuation record 740 maintains the location of the execution of the script in memory. Once the interruption is complete, execution continues at such location. It will be appreciated that there are other times in which it is desired to store such execution state.
• List of active subjects 750 is a list of strings containing the names of all the subjects that are currently the "focus of conversation". This set of subjects is the set of all subjects activated during the most recent bot response that activated one or more subjects, either through executing a category associated with one or more subjects (using the SUBJECTS keyword), or executing a FOCUS or FOCUS SUBJECTS command. Further details on the use of the active subjects list for resolving the context of an input are disclosed below.
• Figure 8 expands the view of local variables 402 as found in Figure 4.
• Local variables 402 comprise active user record 810, active continuation record 820, category focus list 830, and activated subjects list 840.
• Active user record 810 is the user record 406 that corresponds to the user that is currently talking to the BOT processor.
• Active continuation record 820 is one of the continuation records 740, if any, that is copied over for the current execution.
• Category focus list 830 provides an intermediate store of recently activated categories and other categories associated with them. Categories are associated if they share at least one subject name as listed in 630 in Figure 6.
• Activated subjects list 840 provides an intermediate store of subjects associated with recently activated categories, or categories focused using a FOCUS or FOCUS SUBJECTS command.
• the session document contains all information about a BOT as it is being executed, including two member variables particularly relevant to the current disclosure:
• the m_pursUsers structure contains information about each user that is presently conversing with the BOT (stored as a map from UserlDs to CUserRec structures), such as any facts remembered about that user and the focus of attention for that conversation.
• the m_ppProgram structure contains all the information about the BOT script itself, including the robot object created by the compilation process described above and various run-time variables needed during script execution.
• the session document also includes a number of other members such as pointers to various display windows and dialogs used during execution, lists of file names used in the BOT script, and so on.
• the ExeProg contains an executable version of the Gerbil script.
• the RunTime structure contains variables that are used when executing the Gerbil script.
• the CExeStruct contains the following relevant member variables:
• Each CCategoryList contains a list of CCategory objects.
• Each CCategory contains a set of CConditionActionBlock objects, each with a condition and a list of CAction objects.
• CConditionActionBlock is a type of CAction, so CConditionActionBlock objects can recursively contain other CConditionActionBlock objects.
• a CCategory also contains a list of all the subjects discussed by the category.
• PriorityCategories DefaultCategories
• SequenceCategories are fixed in ordering and are shared among all users. Each user record contains a copy of the list
• StandardCategories (see below) in which the ordering of categories can dynamically change (according to the focus mechanism).
• the copy of StandardCategories in the CExeStruct is fixed in order and is used to create the initial copy of StandardCategories for each new user.
• the CExeStruct contains a map m_pmspSubjectMap from each subject name to the list of categories that discuss that subject
• the CRunStruct contains three relevant member variables: CUserRec* User;
• FocusList is used to store the list of categories that have been activated by the focus of attention mechanism during the current execution of the Gerbil script. It will be used at the end of the run to modify the focus of attention for the current user, as described below.
• m saActiveSubjects is used to store the list of subjects that have been activated by the focus of attention mechanism during the current execution of the Gerbil script. It will be used at the end of the run to modify the active subjects map for the current user, as described below.
• the CUserRec contains information about the current user and the robot's conversation with the user.
• it contains a CMapStringToPtr containing the contents of the memory for the user, in which each attribute name is mapped to a list of strings representing the value of that attribute, and seven member variables relevant to the present mechanisms:
• AttentionFocus is a copy of the StandardCategories list from the program executable that describes the attention focus for the BOT's conversation with the current user.
• the order of the categories in this list may be different than the order in StandardCategories, due to the functioning of the focus mechanism.
• SuppressList is a list of pointers to the categories that are suppressed in the robot's conversation with the current user.
• SuppressList may include categories from the PriorityCategories, DefaultCategories, and StandardCategories list.
• m_mssReplacements is a mapping from certain words to other words, used in implementation of the pronoun replacement mechanism.
• m_mspActiveSubjects is a mapping from subject names to null pointers, indicating the set of active subjects associated with the current conversation. This mapping is used in implementing the Focused command disclosed below.
• Continuation is NULL unless there is a WaitForResponse command that is currently active. In this case, Continuation points to a CContinuation structure that describes where in the script the WaitForResponse is located and how to resume execution from that point.
• the user record contains stacks of continuations that handle interruptions of a Sequence category and switches back from Sequence categories.
• SwitchContinuations contains a CContinuation for each SwitchTo statement for which a SwitchBack is still possible (much like the call stack in other programming languages), while SequenceContinuations contains a CContinuation for each sequence that has been interrupted by an InterruptSequence command and not yet returned. The functioning of these CContinuation stacks is described further below.
• a sample Focus command might look like ⁇ Focus "dogs", “cats”; ⁇ this command would move the category “dogs” to the front of the attention focus list and the category "cats” immediately following it.
• the Focus command is useful to make certain categories more immediate in the course of conversation and, in particular as to the above example, if the user had recently spoken of "pets".
• the second explicit focus mechanism is similar to the "Focus” command but differs in that it will move a set of unspecified categories, each said category sharing a Subject whereby the Subject is explicitly listed within a "Subjects” command within the category.
• the command Focus Subjects "dogs” could be placed in any category and if said command is executed, then all categories explicitly listing "dogs" as a SUBJECT will be placed to the front of the attention focus list. This command is useful to focus related categories without having to explicitly list them all.
• the focusing of categories is also used to determine a set of "active subjects" associated with the current state of the conversation. Any time an input is processed that leads to one or more categories being "focused", either through explicit or automatic focus methods, and at least one of these categories is associated with one or more subjects, the set of active subjects is cleared and replaced with the set of all subjects associated with any of the categories that were activated (including any subjects explicitly mentioned in a "focus subjects” command.) Further details on the use of the set of active subjects are disclosed below.
• “Suppress” is an explicit command that disables the activation of the categories named in the command for the remainder of the course of conversation with that user. Such categories can be placed back into consideration with the use of the "Recover” command. For example, the command - Suppress “dogs”; ⁇ will suppress the category “dogs” from further discussion, even if an explicit Focus command would purport to move it to the front of the attention focus list.
• each Gerbil command in the present embodiment actually returns a CABlockEnd value that describes what the program should do following the command.
• This value is normally Continue, indicating that the program should continue by executing the next Gerbil command. It can also be one of the values Waiting, Done, NextCategory, Switch, SwitchBack, NotActivated, or RunTimeError.
• Each Focus command in a Gerbil script has as arguments a list of categories. This list is converted by the compiler into a list of pointers to the actual categories. When the Focus command is executed, these pointers are copied to the end of the RunTime->FocusList structure (to later be brought to the front of the attention focus list.) In addition, all subjects associated with each category are added to the list of active subjects.
• the C++ code for CFocus::Execute is straightforward and is shown below.
• the robot executive takes each argument and uses the map m_pmspSubjectMap found in the CExeStruct to determine which categories share that subject.
• Each of the categories contained in the m_pmspSubjectMap under the subject name is appended to the end of RunTime->FocusList.
• the name of the subject is also added to the RunTime->m_slActivatedSubjects list.
• the WaitForResponse command causes execution on the current input to stop, but before that, sets up a CContinuation telling the Gerbil program where to restart when the next input is processed.
• This CContinuation is created by the compiler and stored in the CWaitForResponse statement.
• the code for CWaitForResponse: :Execute is trivial; it simply copies the CContinuation pointer into RunTime->User->Continuation and returns Waiting.
• a TryAgain command is simply a special case of WaitForResponse in which the CContinuation starts from the previous WaitForResponse rather than the TryAgain command.
• a TryAgain command is converted into an appropriate CWaitForResponse by the compiler.
• An InterruptSequence command can only be used within a Sequence category, and causes the execution of the category to be suspended while all of the standard and default categories are executed. (InterruptSequence can only be used after a WaitForResponse, to prevent possible conflicts in which a category might be executed twice.) It is implemented by adding a CContinuation to the top of the SequenceContinuations stack (allowing nested interruptions within interruptions) and returning the value NextCategory.
• Each SwitchTo command in a Gerbil script has the name of a single category as an argument. Again, this category name is converted into a pointer by the compiler. When the SwitchTo command is executed at run-time, this pointer is copied into a member variable
• RunTime-> SwitchToCategory and the value Switch is returned. Furthermore, a CContinuation representing the SwitchTo is copied into User->SwitchContinuations so that the category can be resumed if the target category ends with a SwitchBack.
• the fact that User- > SwitchContinuations is a stack allows arbitrarily deep series of SwitchTo and SwitchBack calls.
• the present embodiment of the program checks to make sure that the category has not already been executed before returning any value. If it has already been executed, the value RunTimeError is returned instead.
• SwitchTo as it will prevent cycles from occurring while processing a single input.
• the C++ code for CSwitchTo::Execute is shown below.
• the SwitchToOneOf command is a straightforward extension of SwitchTo.
• a CConditionActionBlock consists of a condition and a body consisting of a list of commands.
• the condition is first evaluated. If it is false, the block returns NotActivated immediately. Otherwise, the body statements are executed in order (normally starting with the first statement, but starting with a later statement if the block is part of an active Continuation) until one returns a CABlockEnd value other than Continue. When some other CABlockEnd value is returned, it is passed on as the return value of the CConditionActionBlock.
• a CCategory contains an ordered list of CConditionActionBlock objects, and is executed by executing the blocks in succession (normally starting with the first block, but starting with a later block if the CCategory is part of an active Continuation.) If a block returns the value
• CCategory stops and the return value is passed on. If a block returns NotActivated, the next block is executed. If a block returns Continue, the next block is activated unless it is an Otherwise block or unless both the current and next blocks are IfChance blocks, in which case it and all other IfChance blocks immediately following it are skipped. If the last block in the category returns Continue or NotActivated, execution of the category is complete and the value NextCategory is returned. Meanwhile, if the category is a standard category, any output command (currently all variants of "Say" or "Do") will cause a flag to be set in the category.
• This behavior can be overridden by including the command DontFocus in any of the blocks that should not trigger the automatic focus mechanism. Furthermore, if the category is given a list of SUBJECTS in the Gerbil script, when the category is focused using automatic focus, all other categories that share at least one SUBJECT with said category are also appended to the end of RunTime->FocusList and will be automatically moved to the front of the focus of attention list.
• the function CProgram: :Run When a user enters an input, the function CProgram: :Run is called. This function does a number of low-level tasks (such as setting RunTime->User) and then executes the Gerbil program. First, it clears FocusList and m_slActivatedSubjects so that it can keep track of categories that are focused on during the execution. To prevent possible ambiguities in the ordering of category executions, Focusing actions do not have any effect until the script is finished executing on the current input. It will be appreciated that other implementations of an attention focus mechanism might dynamically reorder the attention focus list during the processing of an input.
• the CProgram is executed by repeatedly selecting and executing categories, as shown in the code fragment below from CProgram: :Run. RunTime->ActivePriority and RunTime- >ActiveCatPos are used to keep track of what category is currently being executed. Once execution is complete, RunTime->FocusList is used to move those categories that were activated or focused on during execution to the front of the Focus of Attention, focusing the robot's attention on these categories.
• the function CProgram: :Refocus itself is straightforward, simply going through RunTime->FocusList, and for each element, removing it from its previous position in the attention focus list and placing it at the front of the list. If the list RunTime- >m_saActivatedSubjects is non-empty, CProgram: :Refocus also updates the active subject map for the current user, clearing the map and replacing it with the contents of RunTime-
• RunTime->InitializeForRun() // Execute all of the categories, in order.
• ActiveCategory GetNextCategory(ThisDoc, ThisUser, ExecutionType, ReturnVal);
• GetNextCategory uses RunTime-> ActivePriority, RunTime- >ActiveCatPos, and the ReturnVal from the previous category, and selects the next category to execute. If ReturnVal is NextCategory, the program will simply select the next category from the CategoryList for the current ActivePriority (Priority, Standard, or Default), according to the selection mechanism operative for that category and switching to the next priority level if necessary. (Recall that the Priority and Default categories are found in the CExeStruct, while the standard categories are found in RunTime->User-> AttentionFocus.
• Sequence categories are never executed unless activated with a SwitchTo command, so the list ExeProg- >SequenceCategories is never executed directly.) If there is an active CContinuation remaining from a previous execution (due to a WaitForResponse), it is activated immediately after the Priority categories. CContinuations are activated by returning the appropriate category and setting RunTime->Continuation, which will cause execution of the category to begin at the appropriate place within the category rather than the beginning. If ReturnVal is Switch, the target category (from RunTime->SwitchToCategory) is selected.
• the mouse is a PS/2 type mouse with three buttons
• the Gerbil Script given in Example 1 contains 6 categories: one priority topic, one sequence topic, and four standard topics.
• the "focus of attention” is referred to as the list of all of the topics, in the order in which they are executed. (Note that this should not be confused with the AttentionFocus member variable of a CUserRec.)
• the initial focus of attention for this user is as follows (the position of "Mouse Sales” is arbitrary since it is not executed unless specifically activated.)
• the program begins by executing the categories in ExeProg->PriorityCategories.
• This list contains only one topic, "Swearing Filter.”
• the condition in the IfHeard statement in the topic does not hold, so the commands in the body are not executed, and the topic returns the CABlockEnd value NextCategory.
• the mouse is a PS/2 type mouse with three buttons
• the robot After executing "Swearing Filter” with no effect, the robot checks to see if there is an active continuation. Since there is, it sets RunTime->Continuation, and now checks to see if the continuation is from a sequence topic. Since it is, GetNextCategory selects "Mouse Sales" before any of the categories in RunTime->User-> AttentionFocus.
• the 6SC monitor has a 19 inch full-color screen
• Robot Says How big is its screen? Robot Says: The 5SG monitor has a 14 inch grayscale screen
• Robot Says The 5SG monitor is made by MonitorTech Console Says: What about the XVI 7?
• the auto-focus mechanism that is used to automatically bring categories to the front of the robot's focus of attention can be supplemented by specifying one or more "subjects" for a topic. If subjects are specified for a category C, when C is executed, it will be brought to the front of the focus of attention, and all other categories that share at least one subject with category C will also be brought to the front of the focus of attention.
• This mechanism allows for the automatic execution of behavior that could otherwise only be generated by an explicit "Focus" statement in the Gerbil script listing all of the categories that cover similar subjects.
• the subject-based auto-focus mechanism is useful for handling pronouns (as in the use of
• Subject specifications are included in categories as a CStringArray of subject names.
• the compiler produces a CMapStringToPtr that maps each subject name to a pointer to a CCategoryList that contains all the categories associated with that subject name.
• the compiler uses this map to set up a list of CCategory pointers for each category C that describes all categories that share at least one subject with C.
• all the pointers in this list are added to RunTime->FocusList and will be moved to the front of the focus of attention at the end of execution.
• the CExeStruct also contains a CMapStringToPtr(m_psmpSubjectMap) that maps subject names to categories, for use in executing a "Focus Subjects" command.
• the 6SC monitor has a 19 inch full-color screen
• the input does not contain "XV 17" , "5SG”, or a word beginning with “it” (the "Sit” pattern matches any word beginning with the letters "it”, such as “it” or “it's”.) Therefore, none of the first six topics are activated.
• the seventh topic "Price of 6SC”
• the outer IF block is activated because "6SC” was heard, but the inner IF block is not activated, so the topic returns NextCategory. Since no statement was executed in the topic other than the IF conditions, the flag in the topic indicating activation is not set, and nothing is added to FocusList.
• the topic "Size of 6SC” is executed first.
• the outer IF condition is true, as the input contains the word "it”, but the inner IF statement is not activated. Since no non-IF statement was executed, the topic returns NextCategory and nothing is added to RunTime->FocusList.
• the topic "Price of 6SC” is activated.
• the outer IF condition is true since the input contains "it”, and the inner IF condition is true since the input contains "how much”. Therefore, the robot "knows” that the question is referring to the 6SC monitor, despite the fact that the user's question does not mention the type of monitor. It thus says “The 6SC monitor is now available for $899", and the topic returns Done.
• BOT author to change the BOT scripts in any way.
• the BOT author simply writes routines to respond to inputs in the natural way, and the mechanism handles resolution of situations in which an input matches multiple conditions.
• the BOT author can also add "optional" elements to a condition that do not change whether the condition is true but may affect the automated response selection.
• Priority and Default categories allow the BOT author to implement initial filters and default handlers for the input, as well as any response generation that the BOT author wishes to have handled by conditions that are explicitly ordered. Sequence categories also function as described, being executed if and only if they are explicitly switched to by another executed category.
• the mechanism for automatic response selection functions on all other categories in the BOT script. It would be obvious to one skilled in the art that the automatic response selection mechanism could also be applied to other types of categories, and that the scope of the present invention should not be limited to any particular method of partitioning the set of categories in the BOT script.
• a category "activated” if one or more base-level statements (i.e. statements other than IF conditionals) would be executed if the category were executed.
• the compiler builds a data structure that can be used to map an input and BOT state to the set of all categories that are activated by that input and BOT state.
• this structure is used to generate a list of all activated categories and to assign a numerical measure of appropriateness (variously termed "specificity" throughtout the description or, more generally, a "metric”) to each category.
• the category with the highest appropriateness value is executed; in the current implementation, ties are broken according to some selection function, such as the aforementioned Focus mechanisms.
• this category executes a Done statement, execution is complete, else the process is repeated, excluding any already-executed categories, and a new category is chosen. If at any step of this process (including the first step), no new categories are generated and a Done has not yet been executed, execution switches to the Default categories and proceeds in the standard manner.
• the BOT could apply the numeric measure or metric to each category defined within the BOT without regard to activation of categories.
• the activation status of categories could be computed concurrently with the computation of the measure or metric; or these steps could be performed separately.
• the present invention should not be limited to any one such implementation and the scope of the present invention explicitly includes these obvious implementation variants.
• the present implementation of the invention computes the appropriateness of a particular response based on the estimated likelihood of the condition or conditions that suggested that response.
• the system computes the most specific condition that matched the input. For instance, the condition that looks for the pattern "you* sales bot" is more specific than the condition that looks for the pattern "you*bot".
• the "*" is a wildcard symbol that can match zero or more words.
• This measure known as "specificity”, is based on log(l/j) where /is the estimated likelihood, over all expected inputs to the system, that a condition is true for any particular input. In the present implementation, specificity is multiplied by 1000 to allow the computations to be done using integers.
• This inverse frequency measure correspond to the idea that a "more specific" question is composed of more and/or more unusual words than a "less specific” question. It will be appreciated that other measures of the specificity of a condition, including other formulas based on condition frequency or estimates derived directly from an explicit domain description, could be used and that the present invention should not be limited to the specificity measure described above.
• the frequency of conditions,/ can be estimated in a variety of ways; for instance, words can be considered uniformly likely, a preset dictionary of word frequencies can be used, or word frequencies can be computed based on likely inputs to the BOT script.
• base-level Recall conditions conditions that test whether a boolean attribute is set for the given user record
• base-level matching conditions are assigned a frequency based on the frequency of words in the Example statements found in the BOT script, since these Example statements are intended to represent a reasonable sample of the inputs that the BOT script is expected to handle.
• Example statements are additionally used in the validation and verification of operation of a virtual BOT, as is more fully discussed below. If a matching condition is testing an input for a particular word, the frequency of that condition is the frequency of that word within the set of Examples.
• the frequency is the combined frequency of all words in the set of Example that match the partial word. If it is testing an input for a string of words, the frequency is the product of the frequencies of the individual words; it will be appreciated that other metrics, such as a true count of the frequencies of word pairs, could be used instead.
• compound conditions are assigned specificity values based on the specificity of their child conditions.
• the specificity of a disjunction of one or more conditions is equal to the highest specificity values from among the true children, while the specificity of a conjunction of one or more conditions is equal to the sum of the specificity values of all children, reduced by a fixed constant (currently 1000) for each child beyond the first, reflecting the fact that conditions tested together tend to be correlated.
• a similar method is used in computing the specificity of conditions that involve PattemLists or optional elements.
• the matching of a PatternList has the specificity of the most specific element of the list that actually matched the input, while the specificity of an optional element or condition is zero if it is not true, and its normal specificity if it is. Therefore, the BOT author can include optional conditions that do not affect whether a condition is matched, but make it more likely that the condition will be chosen if the optional condition is true.
• the first step in the compilation process is to compile the BOT script into executable structures, using standard compilation techniques well-known to those skilled in the art. Once the set of executable categories has been created, the standard categories are further compiled into a data structure (CBFMatcher) that is used to compute the set of active categories and select among them.
• CBFMatcher data structure
• each base-level block corresponds to an action (Say or Do) taken by the BOT, although it might instead be some other statement such as Remember.
• the block beginning IfHeard "bot” and the block beginning IfDontRecall are both base-level blocks, as is the block beginning If ?WhatUserSaid Matches "are*", which contains a SwitchTo statement at its top level. The block beginning IfHeard "you " is not a base-level block, as it contains no statements other than another If block.
• An IF block is said to be "active" if its condition is true and the conditions of all IF blocks containing that block are also true; in other words, the statements in the block would be executed if the category containing the block were executed in the standard fashion, and no Done, NextTopic, or SwitchTo statements were executed earlier in the block.
• Each block is made true by some condition, which can be expressed in terms of disjunctions and conjunctions of base-level conditions, where each base-level condition is either the testing of a memory attribute (IfRecall or IfDontRecall) or a single pattern-matching operation.
• IfChance conditions are treated as always true and thus are not included in the condition set.
• Figure 9 illustrates the data structure that is used to compute the set of active categories and select among them.
• Best-Fit Matcher 900 consists of a set of standard base-level blocks 902, a set of base-level blocks 904 that must be evaluated at run time, a set of base-level blocks 906 that contain only negated conditions, a set of matching objects 908 that determine whether conditions are true or false, statistics 910 about the frequency of words in the domain, and a large number of other temporary variables 912 used in compilation and execution.
• the distinction among the sets of blocks 902, 904, 906 will be discussed below.
• Figure 10 expands the view of a block 902, 904, 906.
• Each such block corresponds to a base-level block in the BOT script.
• Each block consists of a pointer 1002 to the category in which it is found in the script, a list 1004 of conditions 1006 that must be true in order for the block to be active, and a negation flag 1008 for each such condition.
• conditions are always non-negated, and negation of conditions is implemented as a flag in the block containing the conditions rather than in the conditions themselves for efficiency reasons. Other implementations of negation of conditions are obvious to those skilled in the art.
• the set of blocks 902, 904, and 906 corresponds to a subset of the base-level blocks in the BOT script. Given that the mechanism ultimately selects categories rather than blocks, it excludes from consideration any blocks that might be active at the time of category selection but may not be active when the category is actually executed. Such blocks can exist because an earlier statement within the category (such as a Remember or Do statement) may change the BOT state, thus causing the block to no longer be active. For instance, in the code fragment shown above, the block beginning IfDontRecall follows a SwitchTo statement, and is thus not considered as a possible activator for the topic "Are you a bot".
• the topic "Are you X” might not execute a SwitchBack command, or might change the value of the flag ?AnsweredQuestion, thus causing the IfDontRecall condition to have a different value at run-time than at category- selection time. Note that the block will only be executed if the block that contains it (the block beginning If ?WhatUser Said Matches) is active, so there is still a base-level condition that will activate the category whenever the Say "I don 't know " action would be taken during category execution.
• any block following a non-IF statement guaranteed to be executed in the same category but before that block is excluded from consideration.
• the behavior of the mechanism might be improved by testing such statements to determine whether they can in fact affect the conditions in the block.
• any block other than the first active block in a particular category is excluded from consideration, as blocks other than the first active block can not be guaranteed to be executed. Therefore, blocks that follow a block consisting only of an Always or IfChance condition can also be excluded from consideration at compile time, as blocks consisting only of Always or IfChance conditions are always active.
• Each condition 1006 corresponds to a condition found in the BOT script.
• Figure 11 illustrates a base-level condition.
• a base-level condition 1100 represents a single condition in the BOT script, either the Recall (or DontRecall) of a single user attribute or the pattern match of a single object to another object.
• Chance conditions are considered to be always true for the purpose of category selection, and are therefore not converted into BaseLevelConditions.
• low-level conditions are often used to activate higher-level conditions that depend on them, or to activate blocks themselves.
• each BaseLevelCondition includes pointers 1102 to any Blocks 902 that it activates, and pointers 1104 to any IntermediateLevelConditions 1106 that it activates.
• the circumstances under which a BaseLevelCondition activates a Block 902 or IntermediateLevelCondition 1106 are disclosed below.
• the value of a condition is set by a matching object described below. This value is assigned by setting a flag 1108.
• there are some conditions whose values, due to efficiency reasons, are not set by an external matching object.
• Such conditions must also include a "run-time matching object" 1110 that can be called when necessary to determine a value for the condition; other conditions merely contain a NULL pointer in place of matching object 1110.
• the representation and implementation of such run-time objects would be well known to one skilled in the art.
• BaseLevelConditions are non-negated conditions; that is, they are true if an attribute is recalled or a matching operation succeeds. If the actual condition found in the BOT is a negated condition, this information is included in the MatcherBlock or IntermediateLevelCondition that contains the BaseLevelCondition.
• BaseLevelConditions can be "optional" if they represent a condition that is not needed in order for a block to be active, but, if true, should be considered when selecting the block that most specifically matches the input. Such optional conditions are indicated through the use of a flag 1112.
• Figure 12 illustrates an intermediate-level condition.
• An intermediate-level condition represents the conjunction or disjunction of one or more conditions, either base-level or intermediate-level, known as "child conditions.” (An intermediate-level condition with only a single child condition could clearly be replaced by its child condition.)
• the intermediate-level condition structure 1106 includes a list 1200 of child conditions 1202. As in Matcher Blocks, the child conditions can be negated; such negated child conditions are indicated by a negation flag 1204. A flag 1206 indicates whether the condition itself is a conjunction or disjunction of the child conditions. Finally, each condition can activate a set 1102 of matcher blocks 902 and a pointer 1208 to at most one other IntermediateLevelCondition 1106. The circumstances under which an IntermediateLevelCondition activates a Block 902 or IntermediateLevelCondition 1106 are disclosed below.
• these conditions correspond closely to the conditions and objects built in the compilation of the BOT script; the matching of a single PatternList is a BaseLevelCondition, while the matching of a list of objects (separated by commas in the BOT script) is represented as an IntermediateLevelCondition disjunction.
• IntermediateLevelConditions form a forest of conditions; BaseLevelConditions may be the children of many IntermediateLevelConditions, but IntermediateLevelConditions have only one parent condition of which they are a child.
• BaseLevelConditions may be the children of many IntermediateLevelConditions, but IntermediateLevelConditions have only one parent condition of which they are a child.
• Figure 13 illustrates the structure of CMatcherProperty Tester objects 908, which serves to set the values of most of the BaseLevelConditions 1100.
• CMatcherProperty Tester objects 908 which serves to set the values of most of the BaseLevelConditions 1100.
• Nearly all of the conditions found in most BOT scripts in our current scripting language consist of either testing the recall of a memory attribute or matching the value of a memory attribute (such as the system-defined attribute ?WhatUserSaid) against a fixed pattern or PatternList. Therefore, for each memory attribute that is used in a condition in some standard category in the BOT script, the truth value of certain BaseLevelConditions 1100 will need to be set.
• Each such memory attribute has a PropertyTester 908 specific to that attribute name 1300.
• Such a property tester includes a pointer 1302 to the BaseLevelCondition 1100, if any, for the recall of that attribute. It also includes a pointer 1304 to the BaseLevelCondition 1100, if any, that corresponds to a condition testing the optional recall of that attribute (such a condition is always true, but may affect the selection of a category as described below.) Finally, the PropertyTester 908 will perform pattern matching for any BaseLevelCondition 1100 that tests that attribute 1300 against a fixed pattern.
• Figure 16 illustrates a block/condition structure created from a particular BOT script to be described in the following section. The details of Figure 16 are discussed in the following section, but the overall structure of the example illustrates the structure of blocks and conditions.
• the blocks 1600, 1602 are base-level blocks in the BOTscript.
• Conditions 1608, 1610, 1612, 1614, 1616, 1618 are base-level conditions 1100 whose values are set by PropertyTesters 908 (not shown in Figure 16).
• Conditions 1620, 1622, 1624, 1626 are intermediate-level conditions 1106.
• the heavy arcs 1604, 1636 leading to the blocks 1600, 1602 correspond to block activation pointers 1102 in the conditions.
• the heavy arcs 1628, 1634, 1638 between base-level conditions and intermediate-level conditions represent condition activation pointers 1104, while the heavy arcs 1630, 1632 between intermediate-level conditions represent parent activation pointers 1208. All arcs directly below an intermediate-level condition represent child pointers 1200.
• the activation value of the block 1600 would be determined by computing the value of the intermediate-level condition 1624 and testing the value of the base-level condition 1616; if both were true, the block would be active.
• the value of intermediate-level condition 1624 would be determined by computing the values of its child intermediate-level conditions 1620 and 1622; if one or both are true, then intermediate-level condition 1624 is true.
• condition 1620 is determined from the values of base-level conditions 1608 and 1612
• condition 1622 is determined from the values of base-level condition 1610 and 1614. (Recall that the values of all base-level conditions were determined earlier.)
• the first step in the selection of a category given an input is to use all of the PropertyTester objects 908 to determine the subset of the ordinary BaseLevelConditions 1100 that are true given the input.
• Any BaseLevelCondition, other than the RunTimeConditions, that is not labeled as true by this process can be assumed to be false. Since in any particular situation there are generally far more conditions in a BOT script that are false than are true, this process is significantly more efficient than testing each BaseLevelCondition individually.
• there are three sets of BaseLevelConditions those known to be true, those known to be false, and the RunTimeConditions, for which no value has yet been determined.
• the values of the IntermediateLevelConditions are determined in a similar "bottom-up" fashion, in which any condition that is not directly labeled as true is known to be false.
• the list 1104 of IntermediateLevelConditions 1106 are marked as activated. If the IntermediateLevelCondition 1106 is a disjunctive condition, it is known to be true once a BaseLevelCondition activates it. If the IntermediateLevelCondition 1106 is a conjunctive condition, the children 1200 (other than the activator BaseLevelCondition, which is already known to be true) must be tested. For any non-run-time BaseLevelConditions among the children, the truth value will already have been computed.
• the run-time matcher object 1110 is called (or potentially, a cached value may be used instead if the matcher object 1110 has already been evaluated.)
• the top-down evaluation algorithm described above is used for any IntermediateLevelConditions among the children. Thus, the truth value for the IntermediateLevelCondition 1106 is computed. If the condition 1106 is true, and its parent activation pointer 1208 is non- null, its parent condition is activated, and the process is repeated.
• the list 1102 of blocks 902 is also activated. Since blocks are conjunctive conditions, if the activated block 902 has more than one child condition 1006, the other children are evaluated using the top-down evaluation procedure described above.
• each conjunctive condition has one of its child conditions selected as "activator"; this child condition is marked so that it activates the parent node. (Recall that IntermediateLevelConditions are the child of only one condition, while BaseLevelConditions may be the child of many conditions.
• Blocks are handled similarly to conjunctive conditions, although since a condition may be shared among several blocks (if the blocks are within a single higher-level if block within the BOT script), both BaseLevelConditions and IntermediateLevelConditions may activate a list 1102 of blocks 902. Like conjunctive conditions, blocks have only a single activator.
• Disjunctive conditions can be activated by any of their children, and thus all children of a disjunctive condition have activator pointers to their parent condition.
• some of the arcs e.g. arc 1628
• These heavy arcs represent activator pointers.
• BaseLevelCondition 1612 is found to be true, it will activate its parent IntermediateLevelCondition 1620.
• the selection mechanism will then check the other children of condition 1620 (in this case, BaseLevelCondition 1608.) If they are all found to be true, condition 1620 will be true, and will activate IntermediateLevelCondition 1624, which will in turn activate MatcherBlock 1600.
• BaseLevelCondition 1616 The other child of the MatcherBlock, BaseLevelCondition 1616, will now be tested; if it is true the MatcherBlock will be true. Note that the other BaseLevelConditions 1608 and 1616 used in the computation are not activator nodes and thus do not activate any IntermediateLevelCondition. If these two conditions 1608 and 1616 were true but the activator condition 1612 were not, no IntermediateLevelConditions would be activated and no computation would be done for this block.
• IntermediateLevelCondition is inappropriate as an activator, for instance because it is negated or depends on a RunTimeCondition, the disjunctive condition will be inappropriate as an activator and should not be chosen as an activator for other IntermediateLevelConditions or MatcherBlocks.
• the selection of activators for IntermediateLevelConditions and MatcherBlocks is discussed in greater detail below.
• the mechanism for category selection will function regardless of the method used for selection of an activator for each MatcherBlock and conjunctive IntermediateLevelCondition. However, the mechanism will function most efficiently if these activators are chosen such that (1) every IntermediateLevelCondition and MatcherBlock is activated as infrequently as possible, and (2) activators that require additional computation beyond that done by the PropertyTesters are not used.
• activators are chosen according to the frequency with which they are likely to be true.
• the frequency estimate of Recall conditions and word matching is the same frequency value used in computing run-time specificity, based on the frequency of words in the BOT script.
• the frequency estimates for PattemLists, optional elements, and compound conditions are computed somewhat differently than the run-time estimates, however.
• the frequency of a condition that tests for a PatternList is equal to the frequency of the most common element of that PatternList; it is also plausible to use other measures, such as the sum of the frequencies of all elements of the PatternList.
• BaseLevelConditions that are negated, optional, or depend on a RunTime computation are arbitrarily assigned a frequency of 1 in order to prevent them from being chosen as activators.
• the frequency estimate for an IntermediateLevelCondition is computed based on the frequencies of its elements.
• the frequency of the condition is estimated to be the frequency of the most frequent child.
• the frequency of the condition is estimated to be the product of the frequencies of all children, multiplied by a constant (currently 2) for each child beyond the first, to represent the fact that the conditions that are tested in a conjunctive condition in a BOT script tend to be correlated.
• the mechanism will function efficiently as long as the frequency estimates are approximately correlated with the true frequencies of the conditions; it is not necessary for the frequency estimates to be close to the true frequencies, nor to be computed using the particular formulas described above.
• the activators for each node are computed by selecting the child with the lowest frequency value for each MatcherBlock or conjunctive IntermediateLevelCondition. This will result in the conditions and blocks being activated as infrequently as possible, while preventing any negated conditions or RunTimeConditions from being chosen (as those conditions are assigned a frequency of 1.) Any MatcherBlock for which all children have frequency value 1 is not assigned an activator and is stored in the list 904 of non-activated MatcherBlocks.
• the pattern-matching system of the PropertyTesters will now be discussed in greater detail.
• the function of the pattern-matching system is to map attribute values (such as the input value ?WhatUserSaid) into the set of pattern-matching BaseLevelConditions that are true given the value.
• the implementation of the pattern-matching system can be viewed as non- deterministic finite state automata (NFA) where each node represents a pattern and each arc represents an element for pattern matching, for instance a word, space, punctuation mark, wildcard character, etc.
• Figure 15 illustrates an NFA pattern-matcher created from a particular BOT script, to be discussed later.
• Figure 14 displays the stmcture of a single node in a pattern-matching NFA.
• Each node 1306 is associated with a partial pattern 1400 that represents some initial substring (or possibly the entire string) of at least one pattern found in the BOT script. When the node is active, this indicates that the input to the pattern-matching NFA, as processed so far, matches the pattern 1400.
• This pattern value 1400 is included in the representation only for debugging and explanation purposes; it is not used in the actual execution. If the pattern 1400 corresponds to a pattern matching condition that is found in the BOT script, there is a pointer to the
• BaseLevelCondition 1100 that corresponds to that pattern matching operation. (Otherwise this pointer is NULL.) If the node is active when the end of the input is reached, the BaseLevelCondition 1100 will be marked as being true.
• Words, spaces, punctuation marks, one-word wildcard characters, and similar objects that match a fixed element of the input are represented as arcs in the NFA. These arcs are represented in a pattern-matcher node 1306 as a map 1402 of associations 1404 of such objects with pointers to other nodes. For example, arc 1542 (representing the word "you") and arc 1568 (representing a space) are such arcs.
• Optional elements are represented by having the element itself be represented by one or more normal arcs 1404 and adding an epsilon-move (an arc that can be taken without processing any input symbol) between the node immediately preceding the optional element and the one at its end.
• This set of all optional-element epsilon-move arcs 1412 from a node 1306 is stored as a list 1410 within the node.
• the category selection mechanism allows for optional elements both within the pattern-matching stmcture and at the level of BaseLevelConditions.
• Optional elements within the pattern-matching stmcture are less efficient but are needed in the case of optional elements within concatenations.
• unlabeled arc 1558 is such an epsilon-move arc.
• PattemLists are represented with a normal arc 1404 for each element of the pattern list, and an epsilon-move arc 1408 between the end node for each element of the pattern list and another node representing that the PatternList itself has been observed.
• Such epsilon-move arcs 1408 are stored in the appropriate node 1306 in a list 1406.
• This representation for PattemLists is used in order to avoid the generation of an exponential number of nodes in the case where two or more PattemLists are concatenated.
• unlabeled arc 1550 is such an epsilon-move arc.
• true wildcard characters that can match zero words or many words are represented an arc 1414 from the node 1306 (preceding the wildcard) to another node.
• This wildcard node contains arcs for any patterns that can follow the wildcard, and also contains an arc that loops to itself on any input. This implementation is needed since other arcs 1404 may leave the original node 1306 that do not allow any other input between the pattem 1400 and the label on the outgoing arc 1404. If there are no such arcs 1404, the extra node can be combined with the original node 1306 and the self-looping arc can be included in the node 1306. All of the wildcard arcs in Figure 15 have been combined in this way.
• Figure 17 illustrates the original (non-combined) form of some of the arcs in Figure 15.
• the techniques used to create an NFA from a set of patterns to be matched are well- known to those skilled in the art.
• a path is added from the start node in the PropertyTester for that attribute to the node corresponding to that pattem, and a link is added from that node to the corresponding BaseLevelCondition 1100.
• a Matches condition is directly represented as a path in the NFA; a Contains condition is represented by including a * wildcard at the beginning and end of the path.
• the start node of the NFA corresponds to the node matching an empty pattem.
• the NFA There is no single terminal node for the NFA; instead, any node that corresponds to a pattem that is actually used in the BOT script has a pointer to the appropriate BaseLevelCondition.
• each BaseLevelCondition 1100 may be an activator for one or more IntermediateLevelConditions 1106.
• Each true BaseLevelCondition 1100 activates each of the IntermediateLevelConditions 1106 in its list 1104 of conditions. If a disjunctive IntermediateLevelCondition is activated, it is guaranteed to be tme; therefore, if it contains an activation pointer 1208 to another IntermediateLevelCondition, that condition is activated (the disjunctive condition is also flagged as being t e so that if it is later activated by another child, the activation process does not need to be repeated.) If a conjunctive
• both BaseLevelConditions and IntermediateLevelConditions can be activators for MatcherBlocks. For each condition found to be tme during the above process, each block 902 in the list 1102 of MatcherBlocks in the condition is activated. As with conjunctive IntermediateLevelConditions, once a MatcherBlock 902 is activated, the other conditions 1006 in the block must be tested using the top-down evaluation process described earlier.
• MatcherBlock 902 If all of the conditions associated with the MatcherBlock 902 are tme, the MatcherBlock is selected as an active block. Finally, those MatcherBlocks 904, 906 that do not have an activator condition (as discussed earlier) must be tested explicitly by performing top-down evaluation of the conditions in each block. For a given input, there will often be more than one active block. Unless the blocks are explicitly given a fixed ordering in the script, the BOT execution mechanism needs an algorithm to select among them. In the present implementation, the block chosen is the one for which the specificity value is highest. Blocks in categories that have already been executed are excluded from the computation.
• the mn-time estimate of the specificity value for a BaseLevelCondition is based on the set of paths that were taken from the start node of the matcher NFA to the node that corresponds to the BaseLevelCondition. If there is only one such path for the given input, the specificity estimate is simply the sum of the specificity of all the arcs in the path. (In fact, if there is only one possible path between the start node and the condition node, the specificity value can simply be computed at compile time.
• the specificity estimate may vary and must be computed at mn-time.) If there is more than one path for the given input (either because there is an optional element that was found, or because two or more elements of a PatternList were found), the highest specificity value is chosen. (It will be appreciated that other heuristics may also be used.) In the present implementation, the specificity values for arcs are based on the frequency of words in the Examples found in the BOT script, but other sources of frequency estimates could also be used, including the possibility of keeping a database of word frequency in the questions that are asked to the BOT as it is executing. The following section includes several examples of specificity computations for various inputs based on the NFA in Figure 15.
• the specificity values for IntermediateLevelConditions are also computed at mn-time based on the BaseLevelConditions that were activated. For each disjunctive IntermediateLevelCondition, the specificity value is simply the highest specificity value from all tme children of the condition. For a conjunctive condition, as above, the specificity value is the sum of the specificity values of all children, reduced by a constant value (currently 1000) for each child beyond the first.
• the specificity value of the MatcherBlocks is estimated in exactly the same way as the specificity value of a conjunctive IntermediateLevelCondition. Negated conditions have a fixed specificity, although they could be assigned a specificity value based on 1 minus the frequency of the unnegated condition.
• the activation mechanism simply selects the block with the highest specificity value for execution, breaking ties according to the Focus of Attention mechanism as discussed above.
• the category containing this block is then executed in the usual way.
• the remaining blocks can also be stored if the user is attempting to debug the BOT script, as the BOT author may need to know all of the blocks that were activated by a particular input. If the category retums a value of Continue or NextTopic, the process can be repeated as long as it finds one or more active blocks that have not already been executed.
• PatternList BOTS is "bot", “virtual robot”; Topic “Are you a bot” is
• BaseLevelCondition 1500 corresponds to the pattem matching condition in the topic "Are you a bot”
• BaseLevelCondition 1502 corresponds to the pattem matching condition in the topic "Are you a sales bot”
• BaseLevelCondition 1504 corresponds to the pattem matching condition in the topic "Are you a complex bot”.
• Circular nodes e.g. start node 1506 correspond to nodes in the pattem matcher object; labeled arcs (e.g. arc 1542) correspond to transitions, unlabeled arcs (e.g.
• arc 1550 correspond to epsilon-moves
• dark-line arcs e.g. activation arc 1572
• the BaseLevelConditions corresponding to the IfRecall questions in the topics are not shown in Figure 15, nor are the MatcherBlocks themselves.
• wildcard arcs e.g. arc 1540
• the script above does not result in any nodes which contain both wildcard and non-wildcard follow-ups. This combination of nodes is discussed below in the explanation of Figure 17.
• the first “*” is the label for the self-looping arc 1540 from start node 1506 to itself; the pattem “you” is the label for arc 1542 from node 1506 to node 1508; the "*” following it is the label for the self-looping arc 1544 from node 1508 for itself; the word “sales” is the label for arc leading from node 1508 to node 1510; the space between "sales” and “bot” is the label for the arc leading to node 1512; the word “bot” is the label for the arc leading to node 1514, and the final “*” is the label for the self- looping arc from node 1514 to itself.
• start node 1506 corresponds to a state in which a "*" has been matched (i.e. any input has been seen); node 1508 corresponds to the pattem "*you”; node 1510 corresponds to the pattem "*you*sales", and so on. Node 1514 corresponds to the entire pattem "*you*sales bot*" and thus is connected via an activator link to BaseLevelCondition 1502.
• the PatternList BOTS is represented by nodes 1530, 1532, 1534, 1536, and 1538, corresponding exactly to nodes 1516, 1518, 1520, 1522, and 1524 respectively. Finally, there is an epsilon move transition 1558 from node 1526 to node 1538 representing the fact that the entire PatternList BOTS is an optional element in matching. Another * wildcard labels the arc from node 1538 to itself, and node 1538 contains an activation arc that activates BaseLevelCondition 1504.
• the matcher is given the input "Are you a bot".
• the only active node is the start node 1506.
• the word “are” matches only the arc 1540 labeled “*”, so 1506 remains the only active node.
• the space between “are” and “you” has the same result.
• the word “you” matches both arc 1540 labeled "*” and arc 1542 labeled "you”, so both node 1506 and node 1508 are active.
• the next space, the word "a”, and the space following "a” all match only the "*" arcs 1540 and 1544, so nodes 1506 and 1508 remain the only active nodes.
• the word “bot” matches the "*" arcs 1540 and 1542 and the arc 1546 labeled “bot”, so nodes 1506, 1508, and 1516 are now active. (None of the other arcs leaving node 1508 represent possible transitions given the word "bot”.)
• the epsilon-move arc 1550 also causes node 1524 to become active without any input processing.
• the matcher has now reached the end of the input string, and nodes 1506, 1508, 1516, and 1542 are active. The only one of these which activates a BaseLevelCondition is 1542, so BaseLevelCondition 1500 is activated. This activation of
• BaseLevelCondition 1500 is assigned a specificity of 7000 based on the specificity values of the labels of the arcs 1540, 1542, 1544, 1546, and 1550 followed on the path from the start node to the activating node 1542. (The * labels on arcs 1540 and 1544 do not have any specificity value.) Eventually, this BaseLevelCondition will activate a MatcherBlock corresponding to the condition in the topic "Are you a bot".
• the specificity value of a BaseLevelCondition is computed as the sum of the specificity values assigned to all arcs on the path to the activating node.
• other methods of combining specificity values would be possible, such as simply taking the maximum specificity value of any arc along the path, and that the scope of the present invention should not be limited to any particular method of such combination.
• Node 1510 is no longer active as no arc leading to 1510 was matched by the space.
• the word “bot” matches arcs 1546 (from node 1508) and 1570 (from node 1512) as well as the "*" arcs 1540 and 1544, so nodes 1516 and 1514 are now active as well as nodes 1506 and 1508.
• Node 1512 is no longer active.
• the epsilon-move arc 1550 also activates node 1524.
• the final "?” is now processed; nodes 1506, 1508, 1514, and 1524 all have "*" arcs leaving them, so all remain active, while node 1516 is no longer active.
• BaseLevelCondition 1500 is assigned a specificity of 7000 for this activation.
• BaseLevelCondition 1502 is assigned a specificity of 13000 based on the fact that the words "you", “sales”, and “bot” on arcs 1542, 1566, and 1570, respectively, were all matched on the path to the activator node 1514.
• the word "virtual” matches arc 1548 (from node 1508), activating node 1518, and arc 1560 (from node 1528), activating node 1532. (Nodes 1506, 1508, and 1538 all remain active for the remainder of the matching process.)
• the space now activates nodes 1520 and 1534, and the word “robot” activates node 1522 and node 1536.
• Epsilon-transition arcs now activate node 1524 (from node 1522) and repeat the activation of node 1538 (from node 1536).
• the matcher has now reached the end of the input string, so nodes 1524 and 1538 activate BaseLevelConditions 1500 and 1504, respectively.
• BaseLevelCondition 1500 is assigned a specificity of 19000 for this activation, based on the words “you”, “virtual”, and “robot” (note that it has a much higher specificity than in its previous activation.)
• the path involving arcs 1542, 1554, and 1558 had a specificity of 11000, while the path involving arcs 1542, 1554, 1556, 1560, 1562, and 1564 has a specificity of 27000, based on the words “you", “complex”, “virtual”, and “robot".
• BaseLevelCondition 1504 is assigned the specificity of the most specific path to its activator node 1538, or 27000, and therefore will cause the topic "Are you a complex bot" to be selected ahead of the topic "Are you a bot". (Note that if the optional element ⁇ BOTS ⁇ had not been included in the pattem in "Are you a complex bot?" the topic "Are you a bot” would have been selected instead.)
• Figure 17 illustrates in more detail the operation of the wildcard arcs in the NFA shown in Figure 15.
• a * wildcard arc is actually implemented as an epsilon-move transition to another node, which contains a self-looping arc that matches any input.
• start node 1700 has an epsilon-move transition 1702 leading to an intermediate node 1704, which contains an arc 1706 (corresponding to * arc 1540 in Figure 15) that loops back to itself.
• the arc 1542 for the word "you” is thus a transition from intermediate node 1704 to node 1708 rather than directly from start node 1506 to node 1508.
• the entire set of start node 1700, epsilon-move transition 1702, intermediate node 1704, and * arc 1706 are equivalent to start node 1506 and * arc 1540 in Figure 15.
• the node 1508 and its self-looping * arc 1544 in Figure 15 is represented by a node 1708, an epsilon-move transition 1710, an intermediate node 1712, and a * arc 1714.
• a pattem such as "you are”
• the "space" transition would leave from node 1708 rather than from node 1712, thus preventing inputs such as "you sure are” from matching the pattem "you are”.
• MatcherBlock 1600 represents condition #1 above, and is the conjunction of IntermediateLevelCondition 1624 and BaseLevelCondition 1616 (the IfHeard "you" condition).
• IntermediateLevelCondition 1624 represents the disjunction of IntermediateLevelConditions 1620 and 1622, representing the two general question types covered by the condition.
• IntermediateLevelCondition 1620 is the conjunction of the recall BaseLevelCondition 1608 and the pattern matching BaseLevelCondition 1612, while IntermediateLevelCondition 1622 is the conjunction of the recall BaseLevelCondition 1610 and the pattem matching BaseLevelCondition 1614.
• MatcherBlock 1602 represents condition #2 above, and is the conjunction of IntermediateLevelCondition 1626 and the recall
• BaseLevelCondition 1610 while IntermediateLevelCondition 1626 is the conjunction of the pattem matching BaseLevelCondition 1614 and the pattem matching BaseLevelCondition 1618.
• the activator links for each non-base-level condition are shown as bold arcs, such as arc 1604, while the non-activator links are shown as plain arcs, such as arc 1606.
• the conjunctive IntermediateLevelCondition 1620 represents the conjunction of the Recall ?FactQuestion condition 1608 and the Heard "expensive" condition 1612.
• the matching condition 1612 has a specificity of 8000, while the recall condition 1608 has a specificity of only 2000. Therefore, condition 1612 is selected as the activator for IntermediateLevelCondition 1620, and
• IntermediateLevelCondition 1620 is assigned a specificity of 9000 (8000 + 2000 minus the "correlation factor” of 1000.)
• condition 1614 that tests for the word "cost” is selected over the recall condition 1610 as the activator for IntermediateLevelCondition 1622, and condition 1622 is assigned a specificity of 7000.
• disjunctive IntermediateLevelCondition 1624 is activated by both of its children, and assigned a compile- time specificity value of 7000, corresponding to the lowest specificity value among its children.
• IntermediateLevelCondition 1624 (specificity 7000) is chosen over BaseLevelCondition 1616 (specificity 3000) as the activator for MatcherBlock 1600.
• BaseLevelCondition 1618 (specificity 8000) is chosen over BaseLevelCondition 1614 (specificity 6000) as the activator for IntermediateLevelCondition 1626, which is assigned a specificity of 13000 (8000 + 6000 - 1000). Finally, IntermediateLevelCondition 1626 (specificity 13000) is chosen over BaseLevelCondition 1610 (specificity 2000) as the activator for MatcherBlock 1602.
• BaseLevelConditions 1610, 1614, and 1618 are active.
• Condition 1614 activates IntermediateLevelCondition 1622
• Condition 1618 activates IntermediateLevelCondition 1626.
• the matcher first checks the other children of IntermediateLevelCondition 1622 (in this case, only condition 1610) and finds that all are tme, so condition 1622 is active, and has specificity 7000, using the same calculation as before.
• Condition 1622 then activates condition 1624, which is now guaranteed to be tme since it is a disjunction. Since no other children of 1624 are tme, Condition 1624 has a specificity of 7000 (it would have a specificity of 9000 if condition 1620 were tme, as the mn-time specificity of a disjunction is equal to the highest specificity of any tme child.) Condition 1624 now activates MatcherBlock 1600. The matcher now checks the other children of MatcherBlock 1600 and finds them tme.
• the block has a specificity of 9000 (7000 + 3000 - 1000) and is an active block.
• condition 1626 activates MatcherBlock 1602.
• the other children of MatcherBlock 1602, in this case condition 1610, are tme, so the block 1602 is active, and has a specificity of 14000 (13000 + 2000 - 1000).
• This block has a higher specificity than block 1600, so MatcherBlock 1602 is selected and condition #2 is chosen as the "best match" to the input.
• a method of direct pronoun replacement can be used to perform pronoun disambiguation more effectively than the automatic attention focus mechanism discussed above.
• Topics in Gerbil can be assigned subjects using the Subjects keyword. These subjects are used to identify the set of related topics that are brought to the front of the attention focus stack whenever a topic is activated. In the present invention, additional information can be given for some subjects such that when such a subject is the focus of the current conversation, pronouns found in the user input can be replaced with appropriate words.
• pronoun replacement information is assigned to subjects using the Subjectlnfo keyword.
• Subjectlnfo declarations appear at the top level of the GeRBiL script, along with PatternList declarations and other declarations.
• Pronoun replacement is implemented by including a CMapStringToString stmcture mjnssReplacements in the CUserRec stmcture for each user, which contains the current mapping from pronouns to replacements. Initially, this mapping is empty.
• each pronoun-replacement pair in the subject information declaration is added to the pronoun replacement map, replacing existing entries in the map when necessary. If a topic that is executed has more than one subject for which subject information has been declared, the map is updated in the reverse of the order in which the subjects are listed in the topic, insuring that the first subject listed has priority over other subjects listed. Pronoun replacement is not done automatically, but occurs upon the execution of a
• the replacement map m_mssReplacements in the user record for the visiting user is empty.
• the BOT first executes priority topic "Replace pronouns". Since the pronoun replacement map is empty, this topic has no effect, and the attribute ?WhatUserMeant (used in IfHeard) is set to "Who is Walter?"
• the BOT now executes the standard topics, and selects the topic "Who is Walter?" as the best match to the input. (The topic "Other questions about Walter” is also activated, but is not considered as good a fit for the question.
• the BOT is given the input "Is he married?”.
• the BOT first executes the priority topic "Replace pronouns.”
• the word “he” is found in the m_mssReplacements map and is thus replaced with “Walter”, while the words “is” and “married” are not found in the map and are thus unchanged.
• the attribute ?WhatUserMeant is assigned the value "Is Walter married?”.
• the BOT selects the topic "Is Walter married?” as the best match to the input (again, "Other questions about Walter” is active but not selected, while the other three topics do not match the input) and the output "Walter is married to Maybellyne.” is produced. Again, this topic has subject “Walter", so a mapping from “he” to "Walter” is added to the m_mssReplacements map.
• the BOT is given the input "Who is Scott?" and the BOT executes the priority topic "Replace pronouns" for this input. None of the words are found in the replacement map, so ?WhatUserMeant is simply assigned the value "Who is Scott?". In this case, the topic "Who is Scott” is selected as the best match to the input, so the output "Scott is the vice president of technology at Neuromedia.” is produced. The topic "Who is Scott?" has subject value "Scott”, so the subject information for "Scott” is added to the replacement map. In this case, the mapping from “he” to “Scott” is added to the map, and overwrites the existing mapping from “he” to "Walter”.
• the BOT is given the input "Is he married?”.
• the BOT executes the priority topic "Replace pronouns”, and this time replaces the word “he” with “Scott”, resulting in the value "Is Scott married?" for ?WhatUserMeant.
• This question activates only the topic “Other questions about Scott” so the output "I don't know the answer to what you are asking about Scott.” is produced.
• the condition Focused can be included in the BOT script by the BOT author, in the same way that other conditions such as Heard and Recall are used.
• the Focused condition is intended to be tme whenever the category in which it is included is relevant to the current conversation. More specifically, the Focused condition can only be tme in categories that have one or more subjects assigned using the Subjects keyword.
• the Focused condition is tme if one or more of the subject keywords associated with the category are "active subjects".
• the set of active subjects is the set of subject keywords associated with the most recent input that was processed and resulted in at least one topic associated with a subject being focused, either automatically or through a FOCUS command, as well as subject keywords focused using a FOCUS SUBJECTS command. All subjects associated with each topic that was focused are included in this set of active subjects. Thus, a topic that does not contain any subject keywords does not change the set of active subjects. For instance, a default response such as "I don't know" might not have any associated subjects, and therefore would not change the subject of the current conversation. Thus, the user can ask a question after such a default response and assume that the bot will "remember" what the context of the question was.
• the user record stmcture for each user conversing with the BOT contains a mapping m_mspActiveSubjects that contains an entry for each currently active subject. These entries actually map to NULL pointers; the map stmcture is used for efficient lookup.
• m_mspActiveSubjects that contains an entry for each currently active subject. These entries actually map to NULL pointers; the map stmcture is used for efficient lookup.
• One element of the Focused condition object is the pointer m_pcCategory to the category that contains it.
• the system examines each of the elements of the array of subject names found in the category m_pcCategory. Each of these names is looked up in the map m_mspActiveSubjects for the current user. If one or more of the names is found in the map, the Focused condition is tme; otherwise, it is false.
• other methods of evaluating Focused conditions would be apparent to one skilled in the art, such as directly maintaining a list of all categories in which a Focused condition is tme, and that the scope of the present invention should not be limited to the particular implementation disclosed above. It will likewise be appreciated that other forms of conditions apart from Boolean conditions, such as fuzzy logic conditions, modal logic conditions, are well known to those skilled in the art and are hereby subsumed by the scope of the present invention.
• each Focused condition is included in the best-fit matching selection stmcture as a mn-time BaseLevelCondition.
• the value of these conditions can be computed using a mn-time matching object, but these values are not computed unless the block containing the Focused keyword is activated by some other condition. Since there may be many topics containing Focused conditions, it is more efficient to compute the values of each such condition only when needed.
• Each Focused BaseLevelCondition includes an array of the subject names associated with the category containing the condition; this array can be used at mn-time to evaluate the condition when needed. It will be appreciated that other methods of incorporating Focused conditions into such a best-fit matching stmcture would be apparent to one skilled in the art and that the scope of the present invention should not be limited to the particular implementation disclosed above.
• Focused conditions in the best-fit matching selection stmcture are given a compile-time specificity of 0, so that they are never chosen as activators for categories.
• a Focused condition is assigned a specificity of 100 times the number of subjects in common between the category containing it and the currently active subjects. Focused conditions are deliberately assigned a low specificity value so that they do not interfere with more specific answers to user questions. It will be appreciated that other ways of assigning specificity values to Focused conditions could also be used. In particular, if an ordered active subjects list is maintained, the specificity of a Focused condition could depend on the position in which the subjects in the category containing appear in the active subjects list.
• the use of Focused conditions may result in two or more answers with identical specificity.
• the focus of attention stack will function as disclosed above to select an appropriate response.
• the list of active subjects includes both "Walter” and “Scott”, and the question “Who is he?" is included in both a "Who is Walter?" and a "Who is Scott?" topic using the Focused keyword in each case.
• both possible answers will have the same specificity, so the topic that is nearer the front of the focus of attention will give the answer.
• the focus of attention stack itself is unaffected by the Focused mechanism.
• Table 6 illustrates a BOT script in the present scripting language, using the Focused condition in several places. This simple script answers several questions about the company Neuromedia and the scripting language Gerbil.
• Robot Says Neuromedia is a small co ⁇ oration that sells bot authoring software
• Gerbil is a bot-scripting language
• Robot Says I don't know what you mean.
• Robot Says Neuromedia is a small co ⁇ oration that sells bot authoring software.
• the script shown in Table 6 contains 6 categories: two discussing the subject "Neuromedia”, three discussing the subject “Gerbil”, and one default topic, with no subject, that simply gives the response "I don't know what you mean.” to any question that isn't answered by any of the other topics. It is assumed here that the same user is talking to the robot throughout this example.
• the active subject map for this user is empty.
• the only topic that is activated is the "What is Neuromedia?” topic.
• the robot gives the response "Neuromedia is a small co ⁇ oration that sells bot authoring software.” Since the topic "What is Neuromedia?" was activated, the subject "Neuromedia" is added to the active subject map for the user. (If the topic included more than one subject, all of these subjects would have been added to the active subject map.)
• Gerbil is a bot-scripting language
• the only condition that is activated by this input is the condition (Focused and (Heard "is*it*easy")) in the topic "Is Gerbil easy?".
• the best-fit matching mechanism now evaluates the Focused condition and determines that it is tme, since the topic "Is Gerbil easy?" is associated with the subject "Gerbil", which is found in the active subject map for the current user. Therefore, the response "Yes, Gerbil is very easy to use.” is given. Since the topic "Is Gerbil easy?" contains only the subject "Gerbil", the active subject map remains unchanged.
• Robot Says Here's a sample of a Gerbil script: > Robot Says: Topic "Hello World” is
• Focused condition is tested and found to be tme, since the topic is associated with the subject
• Robot Says Neuromedia is a small co ⁇ oration that sells bot authoring software.
• Example statements In the present embodiment of the invention, the BOT author enables verification by including verification statements, referred to as "Example statements" in the BOT script. These Example statements are ignored during ordinary execution of the BOT. However, if the BOT author wishes to test the performance of the BOT, these statements are used as test cases for the verification mechanism. Further detail on the stmcture and use of these Example statements is given below.
• FIG 18 gives an overview of one way in which the example verification mechanism might be used.
• the BOT author 122 when creating the BOT script, includes example statements in the BOT script 108.
• the resultant BOT object 106 contains the examples.
• the BOT author 122 desires to test the BOT, they first select the set of examples 1800 which are to be tested, consisting of all or some of the entire set of examples in the BOT script. These examples are tested by the verification mechanism 1802, using the BOT object 106, as will be discussed in greater detail below.
• the result of this testing is a report file 1804 detailing the errors that were found in the BOT object.
• the BOT author 122 can then use this report file 1804 to make corrections 1806 to the BOT script 108.
• the changed BOT script can then be recompiled by the compiler 107 and the process can be repeated as often as desired.
• Example statements are included within the body of a topic. Each Example statement represents a particular input that an end user might give to the BOT. Currently, these Example statements are limited to textual input. It will be appreciated that Example statements can easily be extended to include non-textual input as well, and that the present invention should not be limited to textual Example statements.
• An Example statement is normally included inside an IF block that also contains one or more Say or Do statements.
• the inclusion of an Example statement in such a block indicates that, in response to each of the input strings given in the Example statement, the author intends the BOT to respond by executing the Say and/or Do statements contained in the block.
• the Example statement also serves as a helpful reminder to the BOT author of the input that the Say or Do statement was intended to respond to.
• the BOT author will often want to include multiple Example inputs for a single block. In order to make the script more readable, these additional Example inputs can be placed outside the original topic through the use of the OtherExamples statement.
• An OtherExamples statement associates the original Example input with additional inputs that are intended to have the same response.
• Object 106 in three places. First, they are included along with other actions in the body of the If.Then block where they are found. Second, a list of all the Examples found within the script is included in the CProgram stmcture, for easy access during verification. These Examples are split up into three types: standard examples, used for ordinary inputs; initial examples, used for initialization; and sequence examples, used to test sequential behaviors. These three types of examples are discussed further below. Finally, a mapping is included in the CProgram stmcture that contains all the OtherExamples, if any, associated with each string given as the argument of an Example statement, and information as to whether they are context-dependent examples or not. In the current implementation, OtherExamples can only be specified for a fixed string, although the present invention should not be limited to the use of fixed strings when specifying variations of an Example.
• the BOT author In order to verify the performance of a BOT, the BOT author first includes Example statements in the BOT script, as described in the previous section, while writing and modifying the BOT script. In the course of ordinary execution of the BOT script, these Example statements are completely ignored.
• the BOT author selects a verification command within the BOT development environment and then selects a set of Examples to verify . For instance, the author may select all the Examples within a particular file, or all the examples in the entire BOT script. These Examples are verified, as described below, and a text file report is produced detailing the errors that were found and, optionally, the correct responses that were given. It will be appreciated that there are other plausible interfaces to the Example verification mechanism, such as an interactive presentation of the results or the creation of a database containing the results, and that the present invention should not be limited to the production of a text file report of the results of verification.
• Examples are included within the BOT Executable Program Object in three places: within the body of If.Then blocks, in one of three lists of examples within the CProgram stmcture, according to example type, and in a mapping of OtherExamples in the CProgram stmcture.
• FIG 19 shows the process of example verification in a BOT.
• Example verification begins at 1900.
• the user selects the set of examples to be verified, and may select a number of options for the format of the output from the verification mechanism; for instance, the user may elect not to have each input and response output to the console window, as would be done during ordinary operation of the BOT.
• the verification mechanism then (at 1904) does any necessary initialization of the mn-time environment 106 for the BOT, for instance to correctly set the output options chosen by the user at 1902.
• this step insures that information from the n is stored in an Example report file, makes sure that output from the BOT is not passed on to any external connections the BOT may have with web pages, chat sites, etc., and sets appropriate flags in the execution program so that it will know to generate appropriate error messages when an Example produces incorrect output. It would be obvious to one skilled in the art that other methods of interface for a verification mechanism are possible, and that the scope of the present invention should not be limited to any particular interface for selecting the set of examples to be verified (including the possibility of automatically selecting all examples) or to any particular set of output options or interface for selecting such options.
• the verification mechanism now iterates 1906, 1908 through the Initial Examples as described in the following section.
• Example Once an Example is selected from the list, it is tested 1918 to see whether it is one of the Examples that the user wishes to test - for instance, by examining the name of the file containing the Example. If it is, the Example is verified. The process 1920 of verifying each Example is described in more detail below. Finally, the user state stored at 1909 is restored at 1921, allowing further examples to be tested in the same state. Once iteration is complete, the verification mechanism resets 1922 the mn-time environment 106 to its original settings, and terminates at 1924.
• Figure 20 shows the process of verification of a single Example in the BOT, and corresponds to operation 1920 in Figure 19.
• Execution starts at 2000.
• the verification mechanism first sets (at 2002) flags in all the If statements containing the example. As each command in the present scripting language is inside one or more If blocks, these flags may be used to produce diagnostic error messages if the Example does not produce the correct output. It then evaluates at 2003 the expressions (e.g. ordinarily fixed strings) that are arguments to the Example statement, in the standard way in which expressions are evaluated in the scripting language, producing a list of strings. It then iterates 2004 over each element of this list of strings.
• the expressions e.g. ordinarily fixed strings
• Each iteration starts at 2006 by running the script on the string, in the same way that the script would be run on an external input (although potentially not producing the same external output, due to the flags set at 1904.) Since a BOT script must be run with respect to a particular user, a "test user" record is created, or retrieved if one has already been created, in order to pass to CProgram: :Run. This user record is used to store the Attention Focus List, the User Attribute Memory, and other properties of the hypothetical "conversation" that is taking place between the verification mechanism and the BOT.
• the program handles the input exactly as it would have handled the same input from an external user. However, by default, Examples are verified in a "find all equivalent matches mode" that is different from the mode in which inputs are ordinarily processed. This mode can be turned off by the BOT author in the input selection process at 1902. In this mode, once a Done has been reached in a standard category, the program checks to see if there are any other categories that are active and have the same specificity as the category containing the Done. These categories are then executed, despite the Done that has already been reached. If only one category was selected, it indicates that the answer would have been given regardless of the context in which the input occurred.
• each category is a possible answer that might be given in response to the input in some context, and the set of such categories represents all such possible answers.
• the verification mechanism produces (2008) an error message, if needed, describing any errors that were found. Any time that a Say or Do statement is executed in response to an Example input, it is considered to have produced a response to the input (this includes any Say or Do statements that are executed in categories executed due to "find all equivalent matches mode"). There are three possible cases that can occur in response to an Example input:
• a warning message is produced in the report file.
• This message can include, for instance, information about the other responses that were given and which topic was responsible for them, and the order in which the correct and incorrect responses were given.
• the verification mechanism can deduce that the reason for the failure must have been that a Done or NextTopic was executed earlier in the category.
• a Done must have been executed in some earlier Priority category.
• a Default category that never got executed
• a Done must have been executed by some Priority, standard, or Sequence category, or an earlier Default category.
• the Example was in a Sequence category that never got executed, the Sequence category was clearly never called.
• the Example is in a standard category that never got executed, there are two possible cases.
• Such a category was either not activated by the best-fit mechanism because some If statement within the block surrounding the example was not true, or was activated (i.e. all conditions in some block in the category were tme) but was not selected. If the category was not active, the category containing the Example is executed anyway at 2010. Since the category was not active, there must be at least one If condition surrounding the Example that is not tme, and since a flag was set for each of these If conditions, an error message will be generated when the category is executed explaining why the Example did not produce the correct response. If on the other hand the category was active, the verification mechanism at 2010 executes all remaining categories that are at least as specific as the one containing the Example, producing information as to all the other responses that might be given in preference to the desired response for the Example.
• the verification mechanism first stores the user state at 2012 so that it can be used for testing Examples WhenFocused. It now iterates 2014, 2015, 2016, 2018, 2020 over any other inputs that are included in OtherExamples statements as being equivalent to the original argument. OtherExamples are included in the Program Executable stmcture as a map from input strings to lists of other examples. Therefore, in order to test the other examples associated with an input, the verification mechanism simply needs to look up this input in the Other Example map and test each of the examples found there. In order to remove any dependence of the results on the order in which the OtherExamples are tested, the user state is restored 2015 to the state in which the user was before the original example was n at 2006.
• the mechanism currently assumes that the execution of the original argument at 2006 is enough to make the subject the focus of attention, and thus restores at 2024 the user state that was stored at 2012 (otherwise other topics may inadvertently become the focus of attention in the course of execution of intermediate examples.)
• the "WhenFocused" example is now mn on the script at 2026, generates error messages at 2028, and executes other categories as needed at 2030. However, when the example is mn at 2026, it is n without the "find all equivalent matches mode" described above. This will test if the input produces the correct response when that category is the primary focus of attention ⁇ which is what the user wishes to know ⁇ while not testing what response will be given if the category is not the primary focus of attention.
• the use of the WhenFocused keyword allows context-sensitive examples to be tested without generating spurious error messages warning that these context-sensitive examples might produce other responses.
• the mechanism could instead of restoring a saved user state, directly modify the state of the focus of attention mechanism to make the category containing the original example the focus of attention. This implementation would also allow the "WhenFocused" example to be tested in a state in which said category is the primary focus of attention.
• the verification mechanism retums to 2004 and continues with the next argument. Once it has verified all of the arguments, it resets at 2032 the flags that were set in the If conditions surrounding the Example at 2002, and retums to the caller at 2034 to continue with the next Example.
• Verifying examples is similar to having a new user log in and type in all the Examples. Ordinary Examples are tested in arbitrary order, which can create a problem if a BOT has some kind of intialization routine such as a routine that asks for the user's name when they first log in. For instance, the first Example tested may produce the response "Hi, what is your name?" rather than a response to the example.
• intialization routine such as a routine that asks for the user's name when they first log in. For instance, the first Example tested may produce the response "Hi, what is your name?" rather than a response to the example.
• Example verification mechanism described in the previous section can be extended to cover initialization routines by including a set of examples in the initialization routine that will be tested before any other Examples and will be tested regardless of the subset of Examples chosen for verification by the BOT author.
• InitialExample statements are included in the initialization routines. Each InitialExample is given a non-negative integer (its index), immediately following the keyword InitialExample, that determines the order in which the InitialExamples are executed, and has exactly one argument. Otherwise, InitialExamples are equivalent to regular Examples. It is an error for more than one InitialExample to have the same index, or for an InitialExample to have more than one input string.
• Example verification mechanism described in the previous section is primarily useful for testing inputs in which the order of inputs is irrelevant.
• the mechanism can be easily extended to verify "sequences" of interaction as well.
• Sequence in this case refers to any series of interactions that are order-dependent, such as interactions in which the BOT asks a question of the user and processes one or more possible responses. Sequences are generally more difficult to test, because all of the possible branches of the interaction must be tested.
• the BOT author first determines the input that initiates the interaction, in this case "My screen is blank". For the pu ⁇ ose of testing, we consider the "interaction” to be the set of all possible interactions that can arise directly from that initial input. In the present implementation of the invention, this initial input is assigned an integer as an "index”, but the scope of the invention should not be limited to any particular indexing scheme for the examples that make up a sequence.
• the BOT author considers all the possible user responses that can follow the initial input.
• the robot responds to the initial input by asking "is it tumed on?”, to which there are two possible categories of user responses (discounting responses such as "I don't know” and irrelevant responses).
• Each response is assigned a letter or word that gets appended to the end of the index for that response. For instance, the response “yes” might be given the index “170.yes” or “170.y” while the response “no” might be given the response "170.no” or "170.n".
• the letter or word used in the index is not used directly in testing the examples; only the actual text in the Example statement is used. Again, the scope of the present invention should not be limited to any particular naming scheme for these indices.
• Example 170 My screen is blank.
• Example 170.yes “Yes”;
• sequence Examples are collected into groups according to the initial number in the index of each.
• We define the "original Example” in each group as the Example for which the index consists only of an integer. (As indicated in the above paragraph, there must be such an example for each group.)
• These original Examples are sorted and stored in an array in the ProgramExecutable stmcture.
• Each sequence Example, including the original Examples for each group includes a mapping that includes each possible Example that can immediately follow the Example, according to the definitions above.
• Figure 22 illustrates the Sequence example stmcture that is generated from the code fragment above once the Example statements described above are added.
• the original example 2200 for the group contains the example text "My screen is blank” and pointers to the two follow-up examples 2202 and 2204.
• the first follow-up 2202 has index “170.yes” and input text “yes”, and contains pointers to two follow-ups 2206 and 2208.
• the other follow-up 2204 has index "170.no” and input text “no”, and does not contain any follow-up links.
• the follow-ups 2206 and 2208 to the example "170.yes” do not have any follow-up links.
• the execution of the example set shown in Figure 22 is discussed below.
• Figure 19 shows the execution of the sequence Examples occurring during the iteration 1910, 1912, 1914, 1915 immediately following the InitialExamples.
• the iteration 1910, 1912, 1914, 1915 occurs over only the original sequence example in each group; the remainder of the sequence examples are tested during the execution process 1914.
• the original example is first tested 1912 to see whether it is one of the Examples that the user wishes to test, as was done for the standard examples at 1918. If it is selected, it is executed 1914 by a special execution process described below, and the user state is reset 1915 so that further examples may be tested in the same state.
• sequence Examples could equivalently be tested along with or after the standard Examples, and that the scope of the present invention should not be limited to testing sequences at any particular time.
• Figure 21 illustrates the execution of a single group of Sequence Examples, corresponding to the execution process at 1914.
• Execution starts at 2100, and begins by executing 2102 the original example for the group, using the execution process shown in Figure 20. If test 2104 determines that the example was given an incorrect answer, further testing of the sequence would not produce meaningful results (since further examples in the sequence make the assumption that earlier examples produced the correct result), and execution is terminated at 2106. If instead a correct answer was given, the state of the test user is saved at 2108, so that each follow-up to the Example can be executed in the same context.
• the verification mechanism now iterates 2110, 2112, 2114 over each possible follow-up to the example.
• Each follow-up is executed at 2112 with a recursive call to the same process shown in Figure 21, since the follow- up is itself a Sequence Example and may have its own follow-ups.
• the user state (stored in 2108) is restored at 2114, and iteration continues at 2110. Once iteration is complete, control retums to the caller at 2116.
• Example verification is equivalent to the result that would be generated if all possible sequences of Examples were tested, but without the possibility of having to test a number of inputs that is exponential in the number of Examples given.
• the detailed methods used in the compilation and execution of sequences of Examples would be well known to one skilled in the art.
• the initial statement in each sequence interaction is tested in "Find All Matches" mode; all other statements are not since they are assumed to follow the initial statement.
• the BOT script shown below includes several Example statements.
• the following BOT script contains intentional errors in order to illustrate the testing mechanisms of the present invention.
• the verification mechanism now iterates over all OtherExamples of the input, and begins with the input "Who is Dr. Tackett?".
• the original user state is first restored 2015. in this case producing no relevant changes.
• the script is next mn on the example (at 2016).
• no category is selected as the input does not match any set of conditions in the BOT script.
• the category containing the Example (“Walter") is a standard category, and since no higher priority category was selected, the verification mechanism can deduce that an if condition must have failed. Therefore, as presented in Table 8 above, the verification mechanism runs the category "Walter". Since the IfHeard statement was marked (at 2002), when it is executed it outputs a message saying that the pattem "Who is Dr. Tackett?" did not match any of the patterns.
• the verification mechanism determines that the category containing the Example was not executed. Since in this case, the category is a standard category and some other standard category was executed, the other category must have been selected as a more appropriate answer. As described earlier, the verification mechanism executes the category containing the Example at 2010, and provides appropriate information about both the example category and the category that was executed first instead.
• Example 170 My screen is blank”; Say “Is the monitor tumed on?”; WaitForResponse;
• Figure 22 illustrates the SequenceExample data stmcture created from the above script.
• the initial example in the sequence is Example 170, "My screen is blank".
• This example is stored as sequence example 2200 and is kept in an array in the ProgramExecutable stmcture, indexed by the index 170.
• the sequence example 2200 has pointers to all possible follow-ups, sequence example 2202 (the example 170.yes above) and sequence example 2204 (the example 170.no above.) There are no follow-ups to example 170.no, but example 170.yes has two follow-ups, sequence example 2206 (the example 170.yes.yes above) and sequence example 2208 (the example 170.yes.no above).
• follow-up sequence example 2208 which is equivalent to the execution of sequence example 2206.
• execution on sequence example 2208 terminates and control retums to the execution on sequence example 2200.
• the user state that was saved after the sequence example 2200 was originally executed i.e. the WaitForResponse after the question "Is the monitor tumed on" is restored, and iteration continues with follow-up sequence example 2204.
• the text "no" for this example produces the correct response "The on switch is located on the front”.
• control retums to the execution for sequence example 2200 There are no further follow-ups to sequence example 2200, so execution for this sequence example is complete.
• Robot says: Is it plugged in? User says: No
• Figure 23 shows the architecture for automatic leaming of features in the context of the preferred embodiment of the present invention.
• the leaming mechanism is controlled by the leaming and validation manager 2300, which is a user interface to present input options and summary of progress to the interactive user. It will be appreciated that mechanisms for visual presentation are well known by those skilled in the art.
• the validation manager 2302 is a combination of components previously described which processes an historical sample of inputs using code created by the leaming process in order to estimate and predict the quality of the automatically generated code.
• the Leaming Tool 2301 embodies one mechanism for leaming Gerbil code from a set of example inputs previously categorized by a human operator.
• feature extractor 2303 which reduces an input sample to a set of abstract representations called features
• learner 2304 as shown in Figure 25, which, given an input sample set where each input element has a label, selects a subset of the extracted features so that each feature is contained in many but not all of the input samples, creating a partition of the input sample set into those which either do or do not contain the feature, so that the label of an input sample can be predicted with some confidence based upon which members of the subset of extracted features it contains
• report module 2305 as shown in Figure 26, for generating statistical and diagnostic outputs associated with the automated leaming process
• code generator 2306 as shown in Figure 27, which converts the subset of features selected by the leaming process, along with a representation of the associated labels, into Gerbil source code, via substitution of learned features into the appropriate fields of a preexisting template.
• Figure 28 shows the process of feature extraction 2303 in greater detail, following the processing of one raw data sample.
• the flowchart Figure 24 shows the algorithm for this process.
• a raw data sample 2800 can be but is not limited to a string of text, representing an action or communication from a user, which may have a label associated with it. Without loss of generality, this configuration will be used to describe the feature extraction 2303 and labeling process.
• the feature extraction process Figure 24 begins at 2400, with the most basic form of input is from a user or a historical database 2402 of prior user inputs, containing only alphanumeric characters, spaces, and punctuation.
• the end of the input is typically delimited by a special character such as ⁇ TAB>, immediately followed by a label designating the category, character, or properties of the sample.
• this label is assigned by a human "teacher,” and has a one-to-one correspondence with the action that the teacher wishes for the robot to take in response to input of this category.
• the inputs are processed until reaching end-of-file 2422, at which point there is a control transfer 2424 to the learner module flowchart Figure 25.
• the extraction phase 2801, 2802 for features consists of converting the input 2800, 2420 to a standard form so that its components can be more readily stored and analyzed. Typically, this might consist of converting all characters to a uniform case 2404, and reduction of the text input to a vector of word "tokens" with all spaces and nonessential punctuation removed 2406,
• Feature encoding 2803, 2804 consists of converting textual tokens to a set of symbolic codes, which denote not only the occurrence of the token 2410, but special properties it may have, such as being the leading, trailing, or only token in the input 2412, or co-occurrence with one or more tokens also contained in the current input 2414. For example, there is a unique feature assigned to the word-token "who" occurring at the beginning of a sentence. There may be a second unique feature assigned to the word “who” occurring in a sentence regardless of position, and both features will then be generated in response to one input sentence which has the word "who” at the beginning. Other entries may be formed from compound features comprising multiple words, such as "who is” or "who knows", which may occur within the same sentence frequently.
• Database insertion 2805, 2410, 2412, 2414 consists of entering the encoded representations of the features into a feature dictionary, and creating statistics associated with the features.
• Each unique feature is isomo ⁇ hic to a unique code that represents it in the feature dictionary 2418.
• the feature dictionary 2418 is organized so that there is only one entry for each symbolic code representing feature/ and so that the occurrences and the label(s) associated with them are tabulated in the dictionary entry. In the entry for each label / there is a counter p(lf)
• the feature dictionary 2418 contains one entry for each type of feature that was encountered in the sample set. Each entry has a count 2416 of the number of times the corresponding feature occurred in the input set. Furthermore, this count is broken down further by label for each feature, so that a unique correspondence between features and labels can be identified.
• Figure 25 shows the flowchart for the learner 2304
• Figure 29 shows the associated processing of the feature dictionary 2418 in tabular form 2900 with features represented in the rows by letters A...H (nominally there are thousands, rather than 8), and Label histogram for each feature represented by columns, numbered 1...4 (the number of labels must be at least 2, and can easily range in the hundreds).
• the algorithm for leaming starts at 2500, iterating 2506, 2512, over elements of Feature
• the actual algorithm Figure 25 divides each element p(F,/) 2416 by the sum SumL(F) 2504 to yield the conditional probability p(/
• Figure 25 iterates again 2514, 2522, over the Feature/Label pairs, to yield reliable predictive features 2526.
• Figure 30 depicts the data flow of this process. Two thresholds are chosen: the “row” threshold, Thresh, 3000, 2516, and “column” threshold, Thresh 2 3001, 2518.
• Feature X) 2510 sum to 1.0 for a given row, then any value greater than 0.5 insures that at most one entry in a row can be considered.
• Thresh 2 3001, 2518 is set to insure that a feature occurs frequently enough to be of use.
• Feature Database 2526 to produce an output file 2612.
• the algorithm iterates 2602, 2608, over the Predictive Feature Database 2526.
• Each feature/ in the Predictive Feature Database 2526 is looked up 2604 in the Feature Dictionary 2418, and the Label, ?(f, ⁇ l), and P(/j/) for that entry are written 2606 to the Predictive Feature Report File 2612.
• control is transferred 2610 to Code Generator module 2306 flowchart Figure 27.
• the first column shows a unique serial number generated for each feature.
• the second column shows a representation of the corresponding feature, according to the following legend:
• the Code Generator module 2306 generates corresponding Gerbil source code 2712.
• the algorithm iterates 2702, 2708, over the Predictive Feature Database 2526.
• Each feature/ in the Predictive Feature Database 2526 is looked up 2704 in the Feature Dictionary 2418, and the feature/ for that entry is written as an activation pattem, and an associative memory element isomo ⁇ hic to the Label is remembered as the action corresponding to the activation, and the resulting Gerbil code is written 2706 to the Gerbil File 2712.
• An example of this is shown in Listing below.
• Table 10 can be used to directly generate Gerbil source code, since the features translate directly into Gerbil pattem matching expressions described earlier, and the labels can immediately take the form of Gerbil associative memory patterns.
• the probabilities are not directly used by the Gerbil code, but are included here only as an illustration of typical probability values for this algorithm.
• Listing shows one clause in an automatically generated Gerbil topic, representing the first and last entries in the table (intermediate examples are omitted for brevity):

Landscapes

• Engineering & Computer Science (AREA)
• Theoretical Computer Science (AREA)
• Software Systems (AREA)
• Physics & Mathematics (AREA)
• Mathematical Physics (AREA)
• Artificial Intelligence (AREA)
• Data Mining & Analysis (AREA)
• Evolutionary Computation (AREA)
• Computing Systems (AREA)
• General Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Medical Informatics (AREA)
• Computer Vision & Pattern Recognition (AREA)
• Health & Medical Sciences (AREA)
• Life Sciences & Earth Sciences (AREA)
• Biomedical Technology (AREA)
• Biophysics (AREA)
• Computational Linguistics (AREA)
• General Health & Medical Sciences (AREA)
• Molecular Biology (AREA)
• User Interface Of Digital Computer (AREA)
• Machine Translation (AREA)

Applications Claiming Priority (9)

Publications (2)

Family

ID=27486677

Family Applications (1)

Country Status (4)

Families Citing this family (22)

Citations (4)

Family Cites Families (3)

• 1998
  • 1998-05-22 AU AU76928/98A patent/AU7692898A/en not_active Abandoned
  • 1998-05-22 EP EP98924852A patent/EP1008019A4/de not_active Withdrawn
  • 1998-05-22 WO PCT/US1998/010536 patent/WO1998055903A1/en active Application Filing
  • 1998-05-22 CA CA002290351A patent/CA2290351C/en not_active Expired - Lifetime

Patent Citations (4)

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events