Virtual human interface for conducting surveys6826540Abstract A virtual human interface application for conducting surveys comprises a system and method which include a script file which may include survey question data, response pattern data, advertising data, entertainment data, lobbying data and/or processing instructions. The system and method include an image generator providing a representation of a character communicating data from the script file, and also include script and response processing modules to seek and/or clarify responses from a user as well as to advertise to the user, persuade the user, encourage or reward the user, possibly based on patterns detected in the user's responses. The system and method automate the distribution of survey questions, the collection of survey data and processing and formatting of survey results. Claims What is claimed is: Description BACKGROUND OF THE INVENTION
NAME OF TABLE DESCRIPTION
SPONSOR_TABLE The SPONSOR_TABLE includes entries
(or records) which hold information about
each of potentially many survey sponsors.
Each record includes a unique
SPONSOR_ID field assigned to a particular
sponsor. Each record also includes additional
information (additional database fields)
relating to the survey sponsor such as, for
example, name, contact name, address,
phone number, fax number, e-mail, web site,
billing information, number of surveys
conducted, number of surveys pending, etc.
Those of ordinary skill will appreciate that
each field is of the appropriate type
(e.g., string, integer, etc.) and is an
appropriate length (e.g., 512 characters,
4 bytes, etc.).
PASSWORD_TABLE The PASSWORD_TABLE holds user and
password data which facilitate secure access
to survey information. Each record in the
PASSWORD_TABLE includes a
SPONSOR_ID field, which provides a
cross-reference to a sponsor in the
SPONSOR_TABLE. Each record also
includes a USER field and a PASSWORD
field. Thus, for any given SPONSOR_ID,
the PASSWORD_TABLE may be queried
to determine all valid user/password
combinations, which can, in turn, be used to
validate an entered user name and password
combination. The PASSWORD_TABLE
allows a single survey sponsor to have
multiple user/password combinations with
which to access, for example, survey
result data, or other information in the survey
database.
SURVEY_TABLE The SURVEY_TABLE includes entries
(or records) which keep track of information
about each survey. Each record includes a
unique SURVEY_ID field assigned to
a particular survey. Each record (and thus
each survey) is cross-referenced to one or
more survey sponsors by a SPONSOR_ID
which matches the same-named field in the
SPONSOR_TABLE. Thus, by querying the
SURVEY_TABLE using a SPONSOR_ID
value, all surveys for any sponsor may be
easily located. Each record in the
SURVEY_TABLE also includes additional
information (additional fields) about each
survey such as, for example, name/title of
survey, description of subject matter, number
of questions, date created, geographic
concentration, path to retrieve corresponding
script file(s), full text of script file, URL
for related survey results web page, number
of responding participants, number of
refusing participants, etc.
QUESTION_TABLE The QUESTION_TABLE includes
entries (records) for each question in any
survey. Each record thus includes a unique
QUESTION_ID field which uniquely
references a particular question. Each record
is cross-referenced to one or more surveys
by including a SURVEY_ID field
which matches the SURVEY_ID field
in the SURVEY_TABLE. Thus, by
querying the QUESTION_TABLE using a
SURVEY_ID value, all questions in the
survey may be easily located. Each record
in the QUESTION_TABLE also includes an
ANSWER_FORMAT field which holds a
value indicating how answers for the
question should be processed for presentation
to a survey reviewer (e.g., "top5and%"
indicates that the five responses most
frequently given should be listed along with
the percentage of users providing the
respective response; "listall" indicates
that all answers provided be listed
sequentially). Each record in the
QUESTION_TABLE includes additional
information (fields) about each question
such as, for example, sequential question
number, text of question, etc.
ANSWER_TABLE The ANSWER_TABLE includes entries
(records) for each answer recorded for any
question in a survey. Each record in
the ANSWER_TABLE includes a
SURVEY_ID field identifying the particular
survey for which the answer was provided.
Each record also includes a QUESTION_ID
field which matches the QUESTION_ID
field in the QUESTION_TABLE.
Thus, by using a QUESTION_ID value, the
ANSWER_TABLE may be easily queried to
locate each separate answer provided for a
particular question. Also, each record in the
ANSWER_TABLE includes a
PARTICIPANT_ID field which matches the
PARTICIPANT_ID field in the
PARTICIPANT_TABLE. Using the
PARTICIPANT_ID value to query the
ANSWER_TABLE, all answers provided
by a particular survey participant may be
easily located. Each record of the
ANSWER_TABLE includes addition
information (fields) about each answer,
including the answer data, whether text,
numeric or otherwise, provided by the
participant, the date the answer was
recorded, etc.
ANSWER.sub.-- The ANSWER_FORMAT_TABLE
FORMAT_TABLE includes records which correspond to a type
of format to apply to a group of answers to
present the results. An
ANSWER_FORMAT field provides the
name of an available answer format, and an
ANSWER_FORMAT_DESCRIPTION
field provides a description of the formatting
associated with an answer format. For
example, one record may have "top5and%"
assigned to the ANSWER_FORMAT field,
and, in the ANSWER_FORMAT.sub.--
DESCRIPTION field, the record may have
the text "choose the five responses most
frequently given and show the percentage of
users providing the respective response."
This table may be used, for example, in a
survey design module to retrieve
descriptions of all available answer formats,
display them to a survey designer, allow a
survey designer to choose one, and then
provide the corresponding answer format
name.
PARTICIPANT_TABLE The PARTICIPANT_TABLE includes
entries for each survey participant who has
provided answer data for any survey. Each
record of the PARTICIPANT_TABLE
includes a PARTICIPANT_ID field
uniquely identifying a particular participant.
Each record of the PARTICIPANT_TABLE
includes additional information for each
participant such as, for example, geographic
location, computer configuration, time to
complete survey, average time to complete
survey, number of surveys completed, etc.
In one embodiment of the invention, a survey administrator populates the survey database 122 with information about each survey sponsor that is conducting surveys. A survey database management application permits the survey administrator to interact with the survey database 122 to, for example, browse the existing records in any of the tables, enter new data and create new records in any of the tables, modify data in any existing record in any table, and also delete any record data in any of the tables. Such database management applications are common and supported by existing database applications such as, for example, Microsoft Access, Oracle, Sybase and FoxBase. Those and other database applications provide extensive database management application design tools, simplifying the design of database management applications, and those of ordinary skill understand well how to use the design tools to construct and operate such database management applications. Thus, the present invention is not limited by a particular survey database management application. As is well known in the field of database management applications, the survey database management application permits a survey administrator to select a database table (i.e., SPONSOR_TABLE, PASSWORD_TABLE, SURVEY_TABLE, etc.) for operations and to select the type of operation (e.g., browse records, create new record, modify records, delete records). While the browse, modify and delete functions may retrieve all records in the selected table and allow the administrator to scroll through all of them, possibly to choose one for modification or deletion, the survey database management application also supports query operations. By providing data for one or more fields and issuing a query command, the survey administrator can retrieve a subset of records (or recordset) in the selected table for browsing, modification or deletion. Thus, to enter information for a new survey sponsor using the survey database management application, the survey administrator selects the SPONSOR_TABLE for operations and chooses a create record option. The survey database management application is designed to then query the SPONSOR_TABLE for all records, determine the highest existing value for SPONSOR_ID in any of the fields, increment that value by one and automatically assign it to the SPONSOR_ID field for the new record to be created. Such technique for selecting unique identification values is well known in the art. Next, the survey database management application prompts the survey administrator to fill in text fields on a computer screen, which fields correspond to fields comprising a SPONSOR_TABLE record. The survey administrator enters information about a sponsor such as, for example, the name of the sponsor (e.g., "XYZ Productions, Inc."), contact name, address, phone number, fax number, etc. When the fields are filled in, the survey administrator invokes a CREATE RECORD command, causing a new record to be created for the SPONSOR_TABLE. Those of ordinary skill will appreciate that, using the same process, the survey administrator can create new records for any of the tables in the survey database. Accordingly, the survey administrator may select the PASSWORD_TABLE and the create record option to enter password data for a sponsor. The survey database management application is further designed to provide pull-down menus for fields in a record which are cross-reference fields, that is, fields that are designed to represent a relationship with one or more data records in another table. Such functionality, is, again, well known in the art, and the present invention is not limited by any design for pull-down menus reflecting cross-reference field values. Thus, because the SPONSOR_ID field of each PASSWORD_TABLE record is to be cross-referenced with a SPONSOR_ID value in one of the SPONSOR_TABLE records, the survey database management application presents a pull-down menu next to a field corresponding to the SPONSOR_ID field for the password record. When the administrator activates the pull-down menu, it presents a list of the names of each of the sponsors, those names having been extracted from the SPONSOR_TABLE records. When the administrator selects one of the names, the survey database management application enters the corresponding SPONSOR_ID in the SPONSOR_ID field of the new password record. The administrator then enters a user name and a password in fields corresponding to the USER and PASSWORD fields and invokes a CREATE RECORD command to cause the new record to be added to the PASSWORD_TABLE. Those of ordinary skill in the art will appreciate that, with sponsor information and password information entered into the survey database, a limited survey database management application can be provided to sponsors to allow limited access to the survey database. It will be understood that the limited survey database management application can use the PASSWORD_TABLE to authenticate any sponsor before providing limited access to the survey database. With limited access, a sponsor may advantageously directly provide information about particular surveys and questions, and, also advantageously, may even change password data or add new user and password data for additional persons. As will further be appreciated, the limited survey database management application can restrict access to only the data that corresponds to the sponsor's SPONSOR_ID (which, in one embodiment, the sponsor cannot change) or data cross-referenced thereto. Thus, many sponsors can access the survey database with no capability to view or alter data except that associated with the respective sponsor. Server and Client Configuration FIG. 2 illustrates one embodiment of a survey input client 106 in accordance with the present invention. In the illustrated embodiment, the survey input client 106 comprises a personal computer 200, a monitor 202, and a microphone 204 in addition to a mouse, keyboard and standard I/O ports (not shown). The personal computer 200 also includes a 400 megahertz (MHz) processor, 128 megabytes (MB) of random access memory, a 2 gigabyte (GB) hard drive, a 56 kilobits-per-second (kbps) modem or NIC (network interface card), a duplex sound card, and a video card. The invention, however, does not require all of these components. It will be appreciated by one of ordinary skill in the art that the personal computer 200 of the survey input client 106 can be any of a number of general purpose computers--whether desktop, laptop or palm-top--using one or more microprocessors, such as a Pentium, Pentium II, or Pentium III processor, or a K6 or Athlon processor, a MIPS processor, a Power PC processor or an ALPHA processor. The personal computer 200 of the survey input client 106 can also be a cellular device for internet access. As will be appreciated, the present invention is not limited by any type of processor--and may be used with a processor running at less than 400 MHz--and is also not limited by any particular hard disk drive, memory, sound card or video card. The personal computer 200 of the illustrated embodiment also includes operating system and application software, such as Microsoft Windows 95, Microsoft Internet Explorer 5.0, voice recognition software, voice synthesis software, a Verbot.TM. application, such as, for example, Sylvie.TM. version 3.04 available from Virtual Personalities, Inc., and a virtual human interface application 116. It will be appreciated by those of ordinary skill in the art that the present invention could use other operating system software, such as UNIX, LINUX, OS/2, BE, System 7, Solaris, Mac OS or others. Likewise, the present invention is not limited by particular Internet communication software and, thus, common alternatives, such as Netscape Communicator, Mosaic, Opera, or any of a number of small screen cellular browsers, may be used. In one embodiment, the invention comprises a framework of interfaced software modules, which may retrieve, process, create, format and transmit certain data. In a preferred embodiment, aspects of the invention are controlled and facilitated by the virtual human interface application module that directs certain processes to be carried out by other modules, including a Verbot.TM. application module (such as, for example, Sylvie.TM. version 3.04) and voice recognition and voice output modules. These modules, in turn, interact with other software modules, such as services provided by the operating system or such as Internet connection, communication and transmission functions provided by an Internet browser module. Thus, in the preferred embodiment, the modules are generally comprised of software instructions executable by a microprocessor. As used herein, the word "module" refers not only to logic coded as a collection of software instructions, but also refers to logic embodied in hardware or firmware. In the software context, a module may have entry and exit points and may be coded in a high level language such as C, C++, Java, or Pascal, or may be coded in machine or assembler language. Software modules may be compiled and linked into an executable program or installed in a Dynamic Link Library (DLL). Software modules may also be coded in an interpretive language, such as BASIC. Software modules may be callable from other modules, may be nested within other modules, and/or may be invoked in response to a detected event or interrupt. Instructions of software modules may be coded into firmware, such as an EPROM. In the hardware context, modules may be comprised of connected logic units, such as gates and flip-flops, and/or may be comprised of programmable units, such as programmable gate arrays. A computer configured similarly to the personal computer 200 can be used to carry out the processes of the survey review client 112. Generally and advantageously, any general-purpose computer configured to browse the Internet may be used as the survey review client 112. FIG. 3 illustrates one embodiment of a survey server 300 in accordance with the present invention. The survey server 300 preferably comprises a personal computer 302 including a 400 MHz processor, a 128 MB random access memory, a 2 GB hard drive, and a high speed network connection. As will be appreciated by those of ordinary skill in the art, the personal computer 302 can run multiple application software programs simultaneously. Thus, in a preferred embodiment, the personal computer 302 hosts the processes for the survey script server 104, the survey results collector 108, and the survey results server 110. Alternatively, separate computers could host the processes of the survey script server 104, the survey results collector 108, and the survey results server 110. The personal computer 302 runs operating system software, for example, Microsoft Windows NT, which, as those of ordinary skill in the art understand, is multi-tasking, multi-threading, and preemptive. The personal computer 302 is not, however, limited by any of the services of Microsoft Windows NT, and can use any of the other operating systems mentioned above. The personal computer 302 also runs application program software. In particular, database functions are provided by Microsoft Access database software, and Internet server functions are provided by Microsoft Internet Information Server. Other database software, such as, for example, Oracle, Sybase or FoxBase, capable of storing data based on relationships between data items and capable of performing queries to identify and retrieve the data may be used. Likewise, other internet server software, such as, for example, Apache, could be used to facilitate network-based communication with potentially large numbers of users, to serve HTML-compliant pages upon request, to process scripts, such as, for example, PERL scripts referenced in HTML page files using server side includes (SSI's), and to transfer data and files using other Internet protocols, such as FTP. Thus, the present invention is not limited by any database or Internet server application software. In an on-line embodiment, the personal computer 302 includes a virtual human interface application 116, and a Verbot.TM. application, such as the on-line Sapphire.TM. class Verbot.TM. available from Virtual Personalities, Inc. In this embodiment, the Verbot.TM. can be embedded into the survey sponsor's server environment, such as an Internet server, and accessed by the survey participant 118 using any suitable network access application, such as a web browser. As described in more detail below, Java applets processing user input and script files and also controlling the transmission of voice and animation media may be used to implement the on-line Sapphire.TM. class Verbot.TM.. The operation of the virtual human interface application 116 in the on-line embodiment is similar to the operation of the virtual human interface application 116 in the embodiment described above, except that some of the human interface processing is handled by the survey server 300 rather than locally on the survey input client 106. This embodiment advantageously eliminates the need for a Verbot.TM. application and a virtual human interface application 116 on the survey input client 106. In this embodiment, browser cookies maybe used to track information regarding survey participants 118. It will be appreciated by those of ordinary skill that cookies are routinely used to allow web servers to recognize information about clients who repeatedly browse the server. Also, survey participants 118 can more easily participate in surveys from mobile and remote environments. FIG. 4 illustrates a representation of one embodiment of a survey results report 126 generated by a survey results server 110. The survey results report 126 displays current survey result data in a form that is easy to analyze. For example, in the illustrated embodiment, the survey results report 126 displays statistical information regarding how the survey participants 118 rated the subjects of the survey on a given scale. It will be appreciated that countless other formats for survey result data may be used with the present invention, and the present invention is not limited by any particular format for result data. FIG. 5 illustrates a representation of aspects of a virtual human interface application 116 in accordance with one embodiment of the present invention. In this embodiment, the virtual human interface application 116 includes a Verbot.TM. 500. In one preferred embodiment, the Verbot.TM. 500 is Sylvie version 3.04 available from Virtual Personalities, Inc., which Verbot can be run locally on the survey client 200 The local embodiment of the Verbot 500 advantageously facilitates geographic control over surveys through simple distribution of the Verbot 500. In another preferred embodiment, the Verbot.TM. 500 is an on-line Sapphire class Verbot.TM. available from Virtual Personalities, Inc. The on-line embodiment of the Verbot 500 advantageously simplifies distribution of the Verbot 500 as it is available, in one embodiment, by simply accessing a web page. Those of ordinary skill in the art will understand that the Verbot.TM. 500 includes particular modules, namely a script file parser 502, an image generator 504, and a response parser 506. It will also be appreciated that the Verbot.TM. 500 may carry out or facilitate certain user interface functions such as, for example, synthesizing speech 510 from text data, such as survey question data embedded in a script file 114 (also referred to as a net file), presenting photo-realistic images 512 comprising an animated human face in accordance with facial expression codes embedded in the script file 114, and recognizing all or portions of user input 516 to match one or more anticipated responses coded in a script file 114. The on-line embodiment of the Verbot.TM. 500 performs similar functions. The response parser 506 is implemented as a JAVA applet, and image generation 504 is performed with the use of available web browser plug-ins, now in common use, which deliver animated content to Internet users. In a preferred embodiment, the on-line Verbot 500 uses Flash 4 from Macromedia, but could use Microsoft Agent or Pulse3D. It will be appreciated that the present invention may make use of those technologies as well as other rapidly developing media technologies (including image generation technology handling not only geometry, but also textures) that will permit the presentation of ever more realistic characters in connection with the virtual human interface. The JAVA applet, in one embodiment of the present invention, operates in a web browser environment, receives and parses user responses, and, as necessary, sends requests from the user's web browser to the survey server 300 requesting, for example, specific voice and/or animation data. The survey server 300 responsively transmits a data stream comprising, for example, voice data and graphic frames representing a character communicating information, such as, for example, the movement of lips (lip-synch frames) to simulate a talking human. In one embodiment, the frames may be cached locally on the user's web browser to facilitate a faster response, and, in a further embodiment, the transmitted data stream may include voice data and references to cached frames. In another embodiment where transmission bandwidth is adequate, frames may be transmitted from the server on demand. As will be appreciated by those of ordinary skill, in one embodiment, the JAVA applet runs under JAVA version 1.1, and communicates with Flash 4 via the LiveConnect plug-in extension available from Netscape. Thus, in a preferred embodiment, the on-line version of the Verbot.TM. 500 resides partially on the survey server 300 and partially on the survey client 200 and interacts with a survey participant 118 through a web page. In a preferred embodiment, the Verbot.TM. 500 is interfaced with voice recognition and voice output modules, such as, for example, those available from Lernout & Hauspie. However, the invention could use other voice recognition and voice output modules and is not limited by any particular voice recognition or voice output module. In this embodiment, the Verbot.TM. 500 can verbally present questions to a survey participant 118 and can accept and respond to the spoken responses of the survey participant 118. Those of ordinary skill in the art will understand that the script file parser 502 extracts question text from the script file 114 and presents the question text data as input to the voice output module, which generates sound through a sound card and/or speaker to verbalize the question text. It will be further appreciated that the voice output module can output a recorded human voice or a computer-synthesized voice that can be modified, such as in pitch and speed (e.g., to sound more like a man or a woman). Preferably, the voice output module of the on-line version of the Verbot.TM. 500 outputs a realistic human voice when interacting with the survey participant 118. Like voice output modules, voice recognition modules are now widely available, and thus it will be understood that an application program can be provided with textual input that has been generated by a voice recognition module. Generally, a voice recognition module accepts analog voice input through a microphone, converts the analog signals to digital signals, samples and encodes the signals (such as, for example, by using pulse code modulation) and to convert the voice input to a data stream representing text characters. Often, existing voice recognition modules generate text characters corresponding to the spoken words with an accuracy of better than 90%. The present invention is not, however, limited by voice input or output. In another embodiment, the Verbot.TM. 500 interacts with a survey participant 118, particularly the hearing impaired, by generating text in a user interface window 520 such as those commonly supported by the Microsoft Windows operating system. In this embodiment, the Verbot.TM. 500 generates text characters in a question text box 522. The question text characters are based on the question data parsed from a script file 114 or on response text scripted in the script file 114 to be presented to a survey participant 118 based on his or her input to the Verbot 500. The survey participant 118 reads the question text and responds by entering text via a keyboard into an answer text box 524. Upon striking the `enter` key, the response parser 506 begins processing the entered text characters. Both the local and the on-line embodiments of the Verbot.TM. 500 function in the same manner with respect to the text and voice inputs and outputs described above. For example, in both embodiments, the user has the option to engage both the text and voice outputs of the Verbot.TM. 500 at the same time. In one embodiment, preferably for use at bandwidths below 28.8 kbps, the user can advantageously select a text-only version of the on-line embodiment of the Verbot.TM. 500. FIG. 5E illustrates steps performed in one embodiment of the present invention to load the on-line embodiment of the Verbot 500. In a first step 540, the user, using a web browser, accesses a survey web site hosted by the survey server 300. The survey server 300 transmits a web page, including Verbot 500 setup instructions. In a next step 542, the setup instructions examine the survey client 200 to determine whether it includes an appropriate media plug in, such as, for example, the Flash 4 media player by Macromedia. If, in a step 544, the instructions determine that an appropriate media plug in is available, then, in another step 546, the survey server 300 transmits the JAVA applet, an initial script file 114 and possibly a media stream (including for example initial animation information and/or initial voice information) to the survey client 200. If, in the step 544, the setup instructions determine that a media plug in is not available, the setup instructions, in a step 548, query the user for permission to access and install such a plug in, for example the Flash 4 media player. The Flash 4 media player is widely available, and it will appreciated by those of ordinary skill that it is common for web pages to include instructions to access and install the Flash 4 media player as well as to ask permission for the same. It will be further appreciated that the Verbot 500 of the present invention may interface with other media players and thus the present invention is not limited by a particular media player. If, in the step 548, the user does not grant permission, then, in a step 550, the setup instructions generate a message informing the user that the survey cannot be conducted and the process terminates. If, in the step 548, the user does grant permission, then, in a next step 552, the survey client 200 accesses an appropriate media plug in via the Internet, and downloads and installs the media plug in. Processing proceeds to the step 546 wherein the survey server 300 transmits the JAVA applet, an initial script file 114 and possibly a media stream to the survey participant's computer. It will be further appreciated by those of ordinary skill in the art that the Verbot.TM. 500 can perform predetermined data processing instructions 518 associated with matching all or a portion of user input with an anticipated response coded in a script file 114. The data processing instructions can include basic programming language commands and more sophisticated commands, such as, for example, those permitting file operations (i.e., opening, reading from, writing to, and closing files) and launching other applications and providing command parameters to launched applications. Thus, for example., the Verbot.TM. 500 can perform data processing instructions to create an answer file 120 and to record in the answer file 120 certain responses provided by the survey participant 118 and recognized by the response parser 506. Generally, data processing instructions are combined with question data, expression codes and anticipated response patterns in a single script file 114. The script file 114 thus guides the actions of the Verbot.TM. 500 in conducting a survey. The script file parser 502 of the Verbot.TM. 500 processes a script file 114 to configure the Verbot 500 to recognize and act on the various instructions and commands that can be included therein. As will be appreciated by those of ordinary skill, a script file 114 includes a series of rules. Each rule can have a variety of components. The following is a sample rule:
<start-0>
a:0.3
p.35 How*doing*today*
p.35 *are*feeling*today*
r:I'm doing well today, thank you
Each rule has a title, which is specified between "<" and ">" symbols. Titles can be used to indicate which rules are especially active at any point. The activation level "a:0.3" resolves conflicts with other rules that may be satisfied by an input string. Thus, if a second rule is also satisfied, but has a lower activation level, say "a:0.2", then it would not be fired, or activated. Pattern values are indicated by a command prefix, such as "p:35". The pattern value ("35") attaches a relative importance to a specified pattern. A pattern, such as "How doing today", identifies certain text which could be part of an input string (response) supplied by a survey participant 118. Asterisks, "*", are wildcards that can match any or no text. Note, pattern lines are optional and leaving out a pattern will cause the Verbot.TM. 500 to fire the rule when no matching pattern is found. This can be used to properly respond to input that is not recognized with a statement such as, "I didn't understand what you just said. Can you please re-phrase it for me?" In order to facilitate easy scripting, pattern value macros for affirmative and negative answers have been formulated. Pattern value macros are commands that automatically recognize a wide variety of possible user responses, such as affirmative (AFF) or negative (NEG) input. As will be appreciated, many other additional macros could be created to make scripting more efficient. Response strings are identified by "r:". When a rule fires, that is, when a pattern in the rule matches user input and/or when the activation level of the rule is not superseded by another rule, the response string is presented to the survey participant 118. In a preferred embodiment, the response string is sent to and processed by the voice output module to generate voice output to be heard by the survey participant 118. The rule can then be disabled for a predetermined time period. The following example demonstrates how multiple rules can interact in a script file 114 to advantageously conduct a survey in a conversational and natural way.
<survey-0>
a: 0.7
r: Would you like to take a survey?
+: <survey-0-0><survey-0-1>
<survey-0-0>
a: 0.2
p: 50 AFF
r: That's wonderful. I know you're busy, and I really appreciate your time.
-: <survey-0-1>
+: <newsurvey-0>
<survey-0-1>
a: 0.2
p: 50 NEG
r: Oh, that's too bad, maybe we can talk about it again soon. Talk to you
next time.
-: <survey-0-0><newsurvey-0>
+: <nosurvey-0>
<newsurvey-0>
a: 0.2
r: Lets talk about the TV show, The Z Papers. Did you watch it last
Tuesday?
+: <newsurvey-1>
<nosurvey-0>
a: 0.2
r: It's always good to see you.
In the above excerpt from a script file 114, the "+:" code is used to specify which rules will be particularly active if the present rule fires. Thus, for example, the line "+:<survey-0-0><survey-0-1>" indicates that upon inquiring, "Would you like to take a survey?", the Verbot.TM. 500 will be examining the survey participant's 118 response to look for a match in the patterns specified in the rules titled "<survey-0-0>" and "<survey-0-1>". In this way, the Verbot.TM. 500 determines if the response was affirmative or negative and gives the appropriate verbal response. On the other hand, the "-:" code specifies which rules will not be active after the present rule fires. Thus, the Verbot.TM. 500 can advantageously be scripted to change its sensitivities depending on the survey participant's 118 responses. The on-line version of the Verbot.TM. 500 uses a scripting language similar to that of the local version of the Verbot.TM. 500, as described above. In some embodiments of the on-line version of the Verbot.TM. 500, however, a number of alternative "r:" patterns can be included in a single rule. The following is an example of a rule including several alternative "r:" patterns: p:35 *how*you*doing* r: I'm feeling fine. r: Wow, I feel great. r: Things are going well. Moreover, and further advantageously, the Verbot.TM. 500 can be scripted to control the facial features of a photo-realistic human face to provide the appearance to the survey participant 118 that he or she is conversing with a lively, even entertaining, intelligent entity, which makes the entire survey process more natural, pleasant and enjoyable. The image generator 504 of the Verbot.TM. 500 can render a photo-realistic human face on a display to show any of a number of possible facial expressions 514A, 514B, 514C, 514D. (FIGS. 5, 5A, 5B, 5C, 5D). In one embodiment of the present invention, the face of the Verbot.TM. 500 appears in a face window 526 of the user interface window 520. During presentation of any response string, the image generator 504 moves the lips of the photo-realistic human face to even further simulate conversation. Still further, the image generator 504 causes the eyes of the photo-realistic human face to blink at random times, even when no response is being presented to further advantageously provide the survey participant 118 with the feeling that he or she is conversing with a living entity. An example of a scripted facial expression follows. In some embodiments, expression tags can be used to control the facial expressions of the Verbot.TM. 500. The following are some examples of expression tags: *<mouth # duration> *<eyes # duration> In the above examples, each # represents a different eyes or mouth frame. The duration field controls the time (in milliseconds, for example) that the expression displayed. The following table provides a list of some examples of different possible expressions that the Verbot.TM. 500 can display, together with examples of corresponding mouth and eyes numbers.
Expression Eyes Mouth
Angry 5 45
Misty look right 6 46
Smirk 7 47
Surprise 8 48
Misty look left 9 N/A
Duh 10 N/A
For example, the expression tag *<eyes 5 1000> would make the eyes of the Verbot.TM. 500 look angry for one second (1000 milliseconds). In one embodiment, if the user inputs a -1 in the duration field of the expression tag, then the Verbot.TM. 500 holds the expression until a new one is input. For example, the expression tag *<eyes 6-1> would hold a misty look until some other eye command is given, such as *<blink> Expression macros can be used to ease the process of scripting facial expressions. The following are some examples of expression macro tags: *<smile> *<blink> In one embodiment, a pronunciation file can be created and used to correct the pronunciation of certain words by the Verbot.TM. 500. The following is an example of a list of entries in the pronunciation file:
"win98"=(windows 98)
"winnt"=(windows NT)
"win32"=(win 32)
"email"=(e mail)
"http://"=(h t t p ://)
"www."=(w w w dot)
".com"=(dot com)
".org"=(dot org)
".net"=(dot net)
".edu"=(dot e d u)
".gov"=(dot gov)
".mil"=(dot mil)
".html"=(dot h t m l)
".htm"=(dot h t m)
"@"=(at)
In the above excerpt from a pronunciation file, the text in quotes is intercepted as it is generated by a firing rule. The text is then translated into what the Verbot.TM. 500 would actually say. For example, "@" becomes the word "at." The pronunciation file can also be used to create expression macros. For example, the following entry in the pronunciation file would create an expression macro entitled "frown." "*<frown>":(*<eyes 5 2000>) In the above example, when the frown expression macro is fired, the eyes of the Verbot.TM. 500 go into a frown position and stay for 2000 milliseconds. The following example demonstrates how expression macros can be used in scripting a Verbot.TM. 500. a: 0.3 p: 35 *how*are*you* r: *<smile> I'm really doing well. When the above rule is fired, the Verbot.TM. 500 smiles and says, "I'm really doing well." In the on-line embodiment of the Verbot 500, the script file 114 is preferably transmitted to the survey client 200 with the JAVA applet, which includes the script file processing module. In another embodiment, it is contemplated that the script file 114 may be parsed on the survey server 300 to create a JAVA applet, which is preconfigured to follow all instructions and commands in the script file 114. Thus, when the JAVA applet is loaded on the survey participant's 118 computer, it can determine which script rule fires as a result of his or her response. FIG. 5F illustrates steps performed in one embodiment of the present invention to generate character images with the on-line Verbot 500. In a first step 560, the survey server 300 transmits to the survey client 200 all image frames necessary for image generation, such as, for example, for eye blinking, lip synchronization and facial expression changes. In one embodiment, these image frames are transmitted to and locally cached at the survey client 200 along with the initial transmission of the JAVA applet and the initial script file 114. In a next step 562, the on-line Verbot 500 identifies information to be communicated to the survey participant 118. In one embodiment, voice data representing the information to be communicated resides on the survey server 300, and, in a further step 564, the survey client 200 issues a request for a media stream including the voice data. The media stream may be a key framed sound file. In a next step 566, the survey server 300 transmits the key framed sound file including commands to match certain frames, for example lip-synch frames, to the voice output represented in the sound file. To display the image frames in sequences which create desired animation, the sequential display of frames is controlled using hide and unhide operations. Thus, for example, the Verbot 500 generates a character image whose lips may be synchronized to spoken words by sequentially hiding a current frame, unhiding a next frame, hiding that frame, unhiding a further frame, and so on until the desired animation is complete. Preferably, key framed sound files requested by the JAVA applet from the survey server 300 streams commands that match the lip-synch frames to voice output provided in the sound file. In a step 568, the survey client 200 performs hide/unhide operations at around, in one embodiment, 13 operations per second to match locally cached lip-synch frames. In the step 568, the survey client 200 also simultaneously generates sound by processing the sound file, which processing will be familiar to those of ordinary skill in the art. Those of ordinary skill will further appreciate that existing browser plug-ins, for example Flash 4, may be directed to perform such hide and unhide operations. The on-line Verbot 500, thus, in one embodiment, generates a character image appearing to communicate information to a user. When the on-line embodiment of the Verbot 500 uses voice output, the JAVA applet requests pre-recorded voice sequences to be transmitted from the survey server 300 to the survey client 200 on demand. In another embodiment, the Verbot 500 may transmit digital data sequences representing text characters to a voice synthesis module, which renders analog audio output in a form approximating a human voice speaking words corresponding to the text characters. In some embodiments of the present invention, the image generator 504 generates faces likely to be known to the survey participant 118. Thus, for example, in conducting a survey for a television show, the image generator 504 could advantageously generate the face of a character from the television show. Furthermore, the voice output module could be modified to produce a voice like that of the character. In this manner, the survey participant 118 more easily identifies with the survey process, is more interested, and the entire process is rendered more entertaining and enjoyable. In turn, this advantageously increases:both the attention that each survey participant 118 will give the survey as well as the number of participants that will take the survey. In some embodiments, a branded character, such as a famous animated cartoon character, can be simulated using Verbot.TM. technology. When possible, the character's actual voice can be used and the Verbot.TM. 500 could be scripted to act in a manner consistent with the original character. It is contemplated by the inventors that, in still other embodiments, the image generator 504 generates fictitious, historic, legendary or fantasy character images, such as, for example, Huckleberry Finn, Abraham Lincoln, Michelangelo, Hercules or Bugs Bunny. In even further embodiments, the image generator 504 generates character images representing animals, which may include any life form, such as, for example, dogs, cats, mice, or other mammals, reptiles, amphibians, fish, mollusks, crustaceans, birds, spiders, insects and even microscopic and invertebrate life forms. In still further embodiments, the image generator 504 generates character images representing inanimate objects, such as, for example, toys, cars, computers, rocks, clouds, etc. As will be appreciated, the present invention is not limited by a type of character that can be generated by the image generator 504. The inventors contemplate further that images representing two or more characters may be generated to provide participants with the experience of communicating with two or more characters in a single conversational episode. The inventors further contemplate that the image generator 504 generates images representing a character signing in sign language to communicate with hearing impaired survey participants 118. Operation of System and Method FIG. 6 illustrates a flow chart describing the overall operation of one embodiment of a survey system 100 in accordance with the present invention. In a first step 602 of a first series 600 of steps, a survey administrator populates the survey database 122 with information about one or more sponsors and provides initial user and password data for each sponsor as described above. In a preferred embodiment, a survey sponsor uses a limited survey database management application to enter new survey and question data for a new survey. After authenticating the sponsor by password and determining the SPONSOR_ID for the sponsor, the limited survey database management application offers the sponsor a choice of table subject matter on which to perform operations, such as, for example, to browse, modify, add or delete (1) Survey Information, (2) Survey Question Information, (3) Answer Information, (4) Answer Format Information, or (5) Survey Participant Information. Using techniques described above, a survey sponsor can add survey and question data to the survey database 122. In a preferred embodiment, a specialized application called a survey entry application is designed to simplify the introduction of a new survey into the survey database 122. After authenticating the sponsor as described above, the survey entry application, which is operatively connected to the computer hosting the survey database 122 (directly or by network), prompts the survey sponsor to enter a survey title in a survey title text field and to enter a brief description of the purpose of the survey in a survey description field. When the survey sponsor selects an OK button, the survey entry application creates a new record in the SURVEY_TABLE, incrementing the highest number already used to identify a survey and assigning it to the SURVEY_ID field, assigning the SPONSOR_ID value for the sponsor to the SPONSOR_ID field, the entered title text to the SURVEY_TITLE field, and the entered description to a SURVEY_DESCRIPTION field. The survey entry application then prompts the sponsor to enter question data for the survey. The survey sponsor then enters the text for a survey question in a question text field. Then, to specify a format to present the collected answers, the survey sponsor activates a pull-down menu presenting a list of answer format descriptions extracted from the ANSWER_FORMAT_TABLE. The survey sponsor chooses one the sponsor believes will best format the group of answers collected for the question. For example, one description may read "place all answers in a sequential list" and another may read "choose the five responses most frequently given and show the percentage of users providing the respective response." It will be understood that the best way of representing answer data may differ depending on the nature of the answer data, for example, numeric answer data, text answer data, true/false answer data. When the sponsor selects an answer format, the survey entry application places the associated ANSWER_FORMAT name in the answer format field. Upon selecting an OK button, the survey entry application creates a new record in the QUESTION_TABLE by calculating and assigning a new question identifier (e.g., "Q0001" for the first question in a survey, "Q0002" for the next question, and so on) to the QUESTION_ID field, assigning the answer format name to the ANSWER_FORMAT field, assigning the SURVEY_ID to the SURVEY_ID field, assigning the entered question text to a QUESTION_TEXT field. The survey entry application prompts the sponsor to enter another question or finish. The sponsor enters as many questions as desired for the survey and, when done entering questions, selects finish. The survey entry application generates a new survey report showing the title of the new survey, the newly generated survey ID, and, for each question entered, the question ID followed by the text of the question. In a next step 604, a survey scripter uses the new survey report to encode the survey questions into a script file 114. To facilitate automated processing of answers provided by survey participants 118, the survey scripter also includes commands in the survey script file 114 to cause participants' answers to be recorded in an answer file along with the QUESTION_ID of the corresponding question. Also, the survey scripter includes in the script file 114 commands which cause the SURVEY_ID to be written at the beginning of the answer file. Such a command might be *<input=[SURVEY_ID=01123]>. The scripter may also add some initial scripting to ask the survey participant 118 whether he or she would mind providing some personal information such as, for example, name, geographic location, computer configuration, how many surveys he or she has completed, etc. The scripter may add commands that cause the participant data to be written to the answer file 120. Additionally and advantageously, the survey scripter in a next step 606, either alone or collaboratively with the survey sponsor, adds expression, entertainment, lobbying and/or advertising elements to the script file 114. In another step 608, the scripter posts the script file 114 to the survey script server 104. When the local embodiment of the Verbot.TM. 500 is used, the Verbot.TM. 500 can be preprogrammed with a specific URL address from which to obtain new script files 114 from the survey script server 104. When several different surveys are run at the same time, each script file 114 can be assigned a unique URL address. Furthermore, each script file 114 can be annotated with information regarding the survey to which it is targeted. In this way, the script file 114 is advantageously unlikely to be posted to the wrong URL address and, hence, be transmitted to the wrong survey participant 118. When the on-line embodiment of the Verbot.TM. 500 is used, the Verbot.TM. 500 and the script file 114 are available via a URL address, which the survey participant 118 can access from any location having a suitable Internet browser. In the on-line embodiment of the Verbot 500, or alternatively in the local embodiment of the Verbot 500 running on the survey client 200 which has a current network connection with the survey server 300, the Verbot 500 can immediately access and load a new script file 114 in response to a predetermined event. For example, if, during a survey conducted using an initial script file 114, the user indicates some interest in a different program, the Sapphire.TM. class Verbot.TM. can immediately download a new script file which provides information about or even conducts another survey about the different program. This process is initiated with a command such as *<loadscript=premiumprogram.script>. This new script file 114 may advantageously contain intelligence (rules) addressing the user's indicated interests and, thus, provide a more dynamic and enjoyable experience for the user. When the new script file 114 loads, the Verbot 500 can say: "I've loaded some new information about the information you requested. Go ahead and ask your questions now." When this portion of the interaction is complete, the Verbot 500 can reload the original script file 114 and continue or load a third or additional script file 114 requested by a rule. The following example illustrates rules which accomplish the loading of a script file dynamically:
<premium-1>
a:0.3
p:35 *what*tell*premium*
p:35 *can*about*premium*
p:35 *premium*progra*
r:I can tell you all about the new premium program, but wait a second
while I check the latest. *<loadscript=premiumprogram.script>
r:I'm glad you asked, let me check with my server for the latest, then I'll
answer your questions. *<loadscript=premiumprogram.script>
r:We do have a premium program, I need to check in with my server to
see what the latest information is.
*<loadscript=premiumprogram.script>
Rules in the premiumprogram.script could be coded as follows:
<return-1>
a:0.5
r:Does that answer your questions?
+:<retyes-1><retno-1>
<retyes-1>
a:0.0
p:35 AFF
r:Good, lets get back to where we were then.
*<loadscript=original-r.script> (note that original-r is the same as
the
original script but starts with a comment designed to reorient the user)
<retno-1>
a:0.0
p:35 NEG
r:Okay, ask me anything you like about the premium program and I'll do
my best to answer you.
Thus, dynamic script file 114 loading may be used to facilitate adapting to a user's interests during a survey. Those of ordinary skill will further appreciate that the ability to load script files 114 dynamically provides the additional advantage of breaking a larger script into multiple component scripts to keep any single script relatively small, which, in turn, may reduce script download times. It will be appreciated that reduced download times provided a better user experience, particular in circumstances -where transmission bandwidth is limited. When the local embodiment of the Verbot.TM. 500 is used, a second series 610 of steps is performed independently of the first series 600 of steps. In a first step 612 of the second series 610 of steps, a user installs a virtual human interface application 116 on the survey input client 106. In a next step 614, the virtual human interface application 116 obtains permission from the user to periodically log on to the survey script server 104 and automatically download the latest script file 114. The virtual human interface application 116 also obtains permission to automatically return answer files 120 to the survey results collector 108 upon completion of future surveys. After the first series 600 and second series 610 of steps are completed, the survey system 100 proceeds to a third series 615 of steps. When the local embodiment of the Verbot.TM. 500 is used, the survey input client 106, in a first step 616 of the third series 615 of steps, loads the latest script file 114 from the survey script server 104. As described above, when the on-line embodiment of the Verbot.TM. 500 is used, the Verbot.TM. 500 does not need to load the script file 114 from the survey script server 104; rather, in the step 616, the survey server 300 simply loads a JAVA applet on the survey input client 106 when the survey participant 118 accesses the web page associated with the survey. The JAVA applet interfaces the survey participant 118 to the Verbot 500 hosted by the survey server 300. In a next step 618, the Verbot.TM. 500 processes the script file 114 to conduct a survey with the survey participant 118, during which the Verbot.TM. 500 advantageously entertains, lobbies with, and advertises to the survey participant 118 in accordance with scripting in the script file 114 and records responses in an answer file 120. In another step 620, the virtual human interface application 116 closes the answer file 120 to thereby collect all the responses of the survey participant 118 in the answer file 120. The survey input client 106, in a step 622, transmits the answer file 120 to the survey results collector 108 over the network 102. In a further step 624, the survey results collector 108 parses the answer file 120, extracts the answer data, and stores the data in the survey database 122. In another step 626, a survey reviewer 124 requests a survey results report 126 from a survey results server 110. In a next step 628, the survey results server 110 extracts answer data for the requested survey from the survey database 122, dynamically generates the survey results report 126, and transmits it to the survey reviewer 124. FIGS. 7A through 7E are a series of flow charts representing the operation of a survey system 100 in accordance with one embodiment of the present invention using the local version of the Verbot.TM. 500. In a first step 702, a user loads a virtual human interface application 116 on the survey input client 106. In a next step 704, the user invokes a virtual human interface setup application. In another step 706, the virtual human interface setup application can determine whether the survey input client 106 has sufficient resources to support the virtual human interface application 116. If the survey input client 106 lacks sufficient resources to support the virtual human interface application 116, then, in a step 708, the virtual human interface setup application generates a message announcing and explaining the insufficiency of resources to the user. Otherwise, the virtual human interface setup application, in another step 710, installs the virtual human interface application 116 and an initial script file 114 on the survey input client 106. In a step 712, the user invokes the virtual human interface application 116. In a next step 714, the virtual human interface application 116 launches a Verbot.TM. 500 and directs the Verbot.TM. 500 to open the initial script file 114. In a next step 716, the Verbot.TM. 500, in accordance with the scripting contained in the initial script file 114, introduces itself and interactively seeks permission from the user to periodically download new script files 114 and upload answer files 120 automatically. In a further step 718, the Verbot.TM. 500 determines whether the user grants permission. If the user does not grant permission, then the Verbot.TM. 500, in a next step 720, advantageously lobbies the user to grant permission according to the scripting contained in the initial script file 114. In a step 722, the Verbot.TM. 500 determines whether the user grants permission after the lobbying. The following is an example of lobbying: Verbot.TM.: May I download the latest intelligence now? User: No, I don't want you to. Verbot.TM.: Why not? User: Because I'm concerned about the expense. Verbot.TM.: The intelligence file downloads very quickly. On your connection, it should take no more than 18 seconds. Besides, my current script is very limited. I think you'll enjoy the new stuff. User: I'm not sure. Verbot.TM.: One more thing to consider is that I'm giving you direct access to the programming department at Galaxy Network. That is power most people wish they had. User: Well, okay, then. But don't stay on-line any more than you have to. Verbot.TM.: Excellent, I know you'll be pleased with your decision. Those of ordinary skill will appreciate that the lobbying, such as that illustrated above, can be facilitated by rules coded in a script file 114, which anticipate and respond to certain user responses. If the user grants permission after the initial request or after the lobbying, then, in a next step 724, the virtual human interface application 116 sets a permission flag. Otherwise, the virtual human interface application 116 proceeds to a step 730 without setting the permission flag. In a preferred embodiment, the permission flag is implemented in the software of the virtual human interface application 116. When the permission flag is set, the virtual human interface application 116 can bypass the permission request for each individual access. Thus, the virtual human interface application 116 can automatically download new script files 114 on a regular basis. The automatic download can be set to occur at some predetermined repeating time interval or can be set to trigger upon the detection of some triggering event, such as a user log on. An appropriate method can be selected based on the user's individual circumstances. For example, for workstations and PCs that remain turned on most of the time, the automatic download is preferably set to occur at some predetermined repeating time interval. If the user grants permission, then, after completing step 724, the virtual human interface application 116, in a next step 726, directs the survey input client 106 to download a new script file 114 from a survey script server 104 over the network 102. In one embodiment, this is done by launching an Internet browser and providing it with a command line instruction to access a script file 114 from a site hosted by the survey script server 104. It will be appreciated that a script file 114 may be downloaded via FTP, or other file transfer protocol. The virtual human interface application 116 stores the script file 114 in a predetermined directory on the survey input client 106 once the script file 114 is received. In a next step 728, the new script file 114 replaces the initial script file 114 on the survey input client 106. In a further step 752, as described in more detail below, the Verbot.TM. 500 invites the user to participate in a survey. If, in the step 722, the user does not grant permission, then the virtual human interface application 116, in the step 730, waits in a noninteractive "sleep" mode without setting the permission flag. While in the noninteractive sleep mode, the virtual human interface application 116, in a step 732, monitors a wake-up trigger to determine whether the trigger has been activated. Alternatively, a timer is set and monitored by the operating system with the virtual human interface application 116 set to be launched upon the detection of the timer expiration event. Either way, the wake-up trigger may be configured to activate automatically at recurring intervals of some predetermined time period. Alternatively, the wake-up trigger may be configured to activate in response to some predetermined user input or activity, such as a mouse or keystroke event. If the wake-up trigger has not been activated, the virtual human interface application 116 remains in the noninteractive sleep mode of step 730. In another embodiment, the virtual human interface application 116 generates a scaled-down version of the human-like face displayed by the Verbot.TM. 500, and displays the scaled-down face, for example, in a corner of the display. Further, the virtual human interface application 116 advantageously uses the voice output module to generate teaser statements, enticing the user to take a survey. Any user input activity, such as a mouse or keystroke event may activate the wake-up trigger. Once the wake-up trigger is activated, the virtual human interface application 116, in a step 734, determines whether the permission flag has been set. If the permission flag has not been set, then the Verbot.TM. 500, in a next step 736, requests permission from the user to download a new script file 114 from the survey script server 104. If the user does not grant permission, then the virtual human interface application 116 returns to the noninteractive sleep mode of step 730. If the user grants permission, then the virtual human interface application 116, in a next step 740, directs the survey input client 106 to attempt to download a new script file 114 from the survey script server 104. In a next step 742, the virtual human interface application 116 determines whether the attempted download was successful. In some embodiments, the virtual human interface application 116 determines the success of the download by comparing the content of the old script file 114 with that of the newly downloaded script file 114. If the contents of the two script files 114 differ, then the virtual human interface application 116 determines that the download of the new script file 114 was successful. If the download was not successful, then the virtual human interface application 116, in a step 744, generates and displays a message indicating that a survey is not available. This can be used to encourage the user to actively download the new script file 114. The virtual human interface then returns to the noninteractive sleep mode of step 730. If the download was successful, then processing continues to a step 750. If, during step 734 the virtual human interface application 116 determines that the permission flag has been set, then the virtual human interface application 116, in a next step 745, determines whether the user has already completed the survey included in the current script file 114 by checking a flag that is set at completion of each survey and is reset at the loading of a new script file 114. If the user has not completed the survey, then the virtual human interface application 116, in a step 746, determines whether the survey included in the current script file 114 is too old to conduct by referencing its last date and checking the current system date. When the difference between the dates exceeds a predetermined period of time, for example, two weeks, the current script file 114 is determined to be too old If the survey included in the current script file 114 is too old or if the user has already completed the survey included in the current script file 114, then the virtual human interface application 116 proceeds to the step 740, as discussed above. In the step 750, the virtual human interface application 116 determines whether the new script file 114 is different than the previous script file 114. If the new script file 114 is the same as the previous script file 114, then the virtual human interface application 116 generates and displays a message indicating that a survey is not available in the step 744, as described above. The virtual human interface application 116 then returns to the noninteractive sleep mode of step 730. If the new script file 114 is different than the previous script file 114 or if, during step 746, the virtual human interface application 116 determines that survey included in the current script file 114 is not too old to conduct, then the Verbot.TM. 500, in a next step 752, invites the user to participate in a survey. In a step 754, the Verbot.TM. 500 determines whether the user accepts the invitation. If the user does not accept the invitation, then, in a next step 756, the Verbot.TM. 500 lobbies the survey participant 118, preferably reminding her of the importance of the survey, and offers to show her information about the program. In another step 758, the Verbot.TM. 500 determines whether the survey participant 118 wants program information. If the survey participant 118 does not want program information, then processing returns to the noninteractive sleep mode of step 730. If, in the step 758, the user accepts the offer, then, in a next step 760, the virtual human interface application 116 displays the offered program information by opening a regularly updated web page containing the information of interest. Processing then returns to step 752, where the Verbot.TM. 500 again invites the user to participate in the survey. If, during step 754, the Verbot.TM. 500 determines that the user accepts the invitation to participate in the survey, then the virtual human interface application 116, in a further step 762, directs the survey input client 106 to open the current script file 114. In one embodiment, the Verbot.TM. 500, in an optional step 764, prompts the survey participant 118 to input his or her name. In alternative embodiments, the survey participant 118 will preferably remain anonymous, being identified only by certain demographic information. In an optional step 766, the Verbot.TM. 500 determines whether the survey participant 118 has input a name. If the survey participant 118 has not input a name, then, in a next step 768, the Verbot.TM. 500 determines whether a time out has occurred. In one embodiment, a time out occurs if the user has not entered a response in 90 seconds. Those of ordinary skill in the art will appreciate that other time out time periods may be used with the present invention. If a time out has occurred, then processing returns to the noninteractive sleep mode of step 730. If, during the optional step 766, the Verbot.TM. 500 determines that the survey participant 118 has input a name, then the Verbot.TM. 500, in an optional step 770, stores the name as a text string variable. In a next step 772, the virtual human interface application 116 parses the current script file 114 for the next survey question. In a preferred embodiment, each survey question is associated with one or more rules in a script file 114, and the content of the question may correspond to a response line in a script file 114. The following is an example of a rule containing survey question information: a: 0.6 r: What is your favorite coffee? *<input=[Q0001]$> In a step 77 | ||||||
