CONFIGURABLE INTERACTIVE ASSISTANT
The present invention employs branded virtual characters across multiple network platforms throughout various stages of complex transactions (eg, selling insurance). These characters initially engage prospective customers on a network platform, such as a social network, and persist over time across other network platforms (eg, university and company websites) to educate consumers until they are ready to purchase—e.g., from their “trusted advisor”—particular products and services offered by various providers. An extensible configuration tool (“Config Tool”) is provided to simplify the continued development of such a system, as well as customization of individual Product Modules (e.g., a Life Insurance Module) by product and service providers (e.g., insurance companies and employers) and other third-party developers (before and during runtime). This Config Tool provides a variety of extension points permitting virtual characters to be added and their appearance and behavior modified, along with the details of the products and services being offered.
Latest Navera, Inc. Patents:
This application is a continuation application of U.S. patent application Ser. No. 13/252,926, filed Oct. 4, 2011, entitled “CONFIGURABLE INTERACTIVE ASSISTANT,” which claims the benefit (pursuant to 35 U.S.C. §119(e) for provisional applications and 35 U.S.C. §120 for nonprovisional patent applications) of (i) U.S. Provisional Patent Application No. 61/289,405, filed Oct. 4, 2010, entitled “Interactive Assistant API,” which is a continuation of (ii) U.S. patent application Ser. No. 12/433,720, filed Apr. 30, 2009, entitled “Persistent Sales Agent for Complex Transactions,” each of which is incorporated herein by reference.
BACKGROUND1. Field of Art
This application relates generally to the field of online sales and distribution systems and, in particular, to an extensible configuration tool permitting third-party customization of an interactive system that facilitates complex transactions by employing branded virtual characters that persist across multiple platforms throughout the various stages of such transactions.
2. Description of Related Art
As discussed in U.S. patent application Ser. No. 12/433,720, filed on Apr. 30, 2009, there is a need to engage consumers throughout the entirety of a complex sales and distribution process. What is needed is a system that can attract prospective customers and retain them throughout the various stages of a long and complex sales cycle. Moreover, there is a need to simplify the development process of such a system, and make it extensible via a user-friendly configuration tool that permits third-party developers to customize individual product modules, including the runtime assets contained therein.
SUMMARYThe present invention employs branded virtual characters across multiple network platforms throughout various stages of complex transactions (eg, selling insurance). These characters initially engage prospective customers on a network platform, such as a social network, and persist over time across other network platforms (eg, university and company websites) to educate consumers until they are ready to purchase—e.g., from their “trusted advisor”—particular products and services offered by various providers. Even after completing transactions, these characters continue to provide various services, such as notifying a customer whose circumstances have changed of a relevant product or service, while remaining available to answer questions and provide information upon demand. By employing a semi-automated model, the system of the present invention can answer many questions via predetermined vignettes and automated answers generated by expert systems, while still utilizing live human experts (often transparently) when necessary.
An extensible configuration tool (“Config Tool”) is provided to simplify the continued development of such a system, as well as customization of individual Product Modules (e.g., a Life Insurance Module) by product and service providers (e.g., insurance companies and employers) and other third-party developers. In one embodiment, this Config Tool provides a variety of extension points that permit individual characters to be added and modified, along with their appearance and behavior (at various levels of abstraction). Moreover, the interaction among these virtual characters can also be customized, including their dialogue and interactive conversations with users, as well as with one another. Online providers of products and services can also customize the information that these virtual characters provide to prospective customers, as well as the manner in which such information is provided. The result is an application that can be highly customized by particular online providers to target specific demographic groups of prospective customers.
One embodiment of the architecture of a system of the present invention is shown in
It should be noted that the present invention can be deployed entirely on a single platform (e.g., a social network such as Facebook, a web server, a company's corporate server, etc.) without departing from the spirit of the present invention. Moreover, the client and server hardware on which the present invention is deployed, and which service providers 110 and their customers 120 utilize to access the system, can include laptops, desktop computers, enterprise servers, mobile phones and a variety of other computing devices.
Beginning with the authoring stage 160, the entire process is predicated upon various principles of cognitive science 162, as discussed in greater detail in U.S. patent application Ser. No. 12/433,720, filed Apr. 30, 2009, entitled “Persistent Sales Agent for Complex Transactions,” which is incorporated herein by reference. Branded virtual characters and other programmable objects can be correlated with concerns of particular customers, based upon demographic/profile or psychographic/behavioral characteristics of those customers. Rather than simply offer prospective customers a selection of choices, the system can associate those choices with branded virtual characters and other programmable objects that represent likely concerns of customers exhibiting a particular demographic or psychographic characteristic.
For example, because younger users naturally question the need for insurance, they are more likely to select the “Why do I need insurance?” question, particularly if that question is associated with a young virtual cartoon character to which they can relate. Moreover, an animated virtual character is more engaging than a simple textual link. Similarly, a user that has already demonstrated a risk-taking tendency (eg, by previously selecting and repeatedly playing a game or other application involving high-risk behavior) is more likely to seek information relating to the consequences of risky behavior (such as the scope of coverage of a disability policy), whereas a more meticulously careful individual is more likely to seek detailed information or ask questions of a live agent.
Whatever correlations the rules dictate, the result is that prospective customers are more likely to be engaged by characters to which they can relate, and which represent associated concerns that they are likely to have, based at least in part upon their particular demographic or psychographic characteristics. Moreover, because cartoon characters mimic the way in which the human mind actually stores information (eg, by exaggerating and simplifying features, and removing extraneous detail that would be present in more “lifelike” images), they are distinctive and readily recognizable, and are thus an effective medium for communicating relatively complex educational concepts (such as insurance). For example, when consumers observe a particular character sustaining various injuries in different types of accidents, they begin to associate that character with the conceptual issue being addressed—eg, “Why do I need insurance?”
Over time, consumers build up a level of trust in these recurring characters that would not be present in a typical physical (or even online) sales scenario, particularly as they obtain information in a low-pressure sales environment. In some embodiments, these cartoon characters age over time, along with the consumer, and otherwise adapt to a particular environment. In certain embodiments, branded cartoon characters are employed intentionally to appear less human than more “lifelike” 3D avatars, which can serve to avoid false expectations of the degree of intelligence expected even from semi-automated systems. Trust can be lost quickly if too much reliance is placed on lifelike characters that are driven solely by artificial intelligence technology, as a character's lack of actual human intelligence can readily become apparent.
This process can in essence become a long-term relationship with a customer over a lifetime, in which multiple products or services are purchased over time. Moreover, one or more trusted advisors as well as other associated characters can persist throughout this long process or relationship.
An authoring tool 165 is employed to assist system developers, as well as third-party service providers and developers, with the process of authoring Product Modules 174. Certain pre-programmed parts 166 and visualization elements 167 are provided to facilitate this process, such as character libraries, standard animations, images and dialogue that pertain to specific types of products (explained in greater detail below). Prospective life insurance customers, for example, may generally have certain attributes in common, regardless of the particular service provider or life insurance policy. Individual workers face similar scenarios, depending upon their age, family situation, employment environment and a host of other demographic and psychographic data. Moreover, the details of the insurance policies themselves often have much in common. Plan templates 168 are therefore provided to facilitate the authoring process, as will also be explained in greater detail below.
Through the use of authoring tool 165, the initial development of customized Product Modules is greatly simplified. However, given the vast array of different types of product offerings that exist across various industries, third-party providers may not have sufficient time or resources to invest in custom development of each Product Module 174, particularly as their products and services evolve over time. Moreover, even after a particular Product Module is developed and deployed, there is often a need to modify the customer experience in interacting with that Product Module (e.g., due to changes in product offerings, regulatory rule changes, customer behavior, etc).
In one embodiment, third-party providers and developers can continually fine-tune and configure individual Product Modules via a Config Tool 175, both before and after deployment of a Product Module 174. Config Tool 175 will be discussed in greater detail below.
Upon deployment 170 of a Product Module 174, the system interacts with customers, seeking their input 171 in order to deliver a personalized experience 172 to each particular customer. Integration 180 with various third-party transaction systems 182, for example, enables customers to enroll in a particular insurance plan. Integration 180 with back-end systems and databases 185 provides both generic and personalized information that can be delivered to customers in many forms, often through vignettes including branded virtual characters.
For example, a trusted insurance agent character might interact with customers regarding a particular insurance plan by speaking audio dialogue, accompanied by textual and visual data, along with animations employing other virtual characters, all in an effort to educate prospective customers regarding various aspects of that insurance plan. By accessing various databases 185, the system will have access not only to a relevant knowledge base 187 (containing, for example, details of a particular insurance plan), but also to behavioral data 186 and actuarial and statistical data 188 relating not only to people generally, but also to people having similar demographic profiles or exhibiting similar behaviors. This information also includes the behavior of prospective and actual customers with respect to the system itself—e.g., which options they select, which products they purchase and a host of other behavioral and statistical data.
Before discussing details of Config Tool 175, and the manner in which third-party providers and developers can configure and customize various components of Product Modules 174, it is helpful to examine the architecture and data model underlying the system itself, and the generation of these components. In one embodiment of the present invention, third-party providers and developers can utilize Config Tool 175 to access, configure and customize various core components used to construct a Product Module 174. Additional custom components can also be added when the Product Module 174 is compiled, or even dynamically at runtime. A consistent syntax in the data formats facilitates the construction of “editors” (e.g., visual editors) used to develop core and custom components.
A Product Module 174 is divided into components which are each composed of smaller units, called “Models”, “Views”, and “Controllers.” The “Model-View-Controller” paradigm is a common way of breaking apart the data representation (Model), the module's user interface (View), and the code which mediates between them and the user (Controller).
Controllers determine how a Product Module 174 progresses over time, passing Events (messages to invoke actions) to other Controllers or to Views, which are the visual elements of a module. Views respond to Events, while Models contain small pieces of data, such as preferences, recent user history and visual settings. Controls are parts of a View, such as a UI (user interface) widget. Forms are special Controls that can contain one or more other Controls and which convey data to users.
A simple diagram of an Element 200 or Plugin of the system is illustrated in
In one embodiment, the following set of six core components are available to third-party providers and developers:
-
- Step
- Dialogue
- Question
- Response
- Overlay
- Form (including NumberForm, TextForm, RadioForm and EmptyForm)
Steps (not shown in
Dialogues 420 are non-interactive sets of animation, audio and text. Dialogues 420 typically are used to illustrate a point or educate the user. Any number of characters may talk during a Dialogue 420, but Harvey (the primary “virtual agent” in this embodiment) usually is the one to talk to the user or narrate. Dialogues 420 may appear before a Question 430 or after a Response. Another example of a simple Dialogue 420 is the following:
Questions 430 prompt users for input (e.g., Responses). In one embodiment, a Form may contain an animation and audio representing an audio cue to the user (e.g., Harvey asking a question). Each Question 430 contains a Form and any number of Responses, such as the following:
A Response represents a potential way a user might respond to a Question 430. A Response can include a range of user responses, or a specific response. If the user fails to respond, a default response can be employed. Each Response ends with a link to a “next” desired Step.
Overlays 440 are animations that can be substituted for the default animations provided by the system—e.g., to allow more customizability, or to add additional characters to a scene without recompiling any code. The use of “layers” allows for Overlays 440 to be placed in front of or behind other objects. Default Overlays 440 are used to place UI elements on the screen. In one embodiment, an Overlay 440 can be displayed for a specified duration of time or number of Steps, or indefinitely. Following is an example of a set of default Overlays 440:
Forms are a set of UI Controls that (in one embodiment) are displayed during a Question 430. They allow the user to input a Response that gets parsed to change the flow of the module. Forms can be customized to allow potential new ways for the user to respond. For example, one could create an “Upload Form” to allow a user to upload a photo or scans of insurance information. Another custom Form could be a “plan calculator” which could allow for a sophisticated multi-Step Question 430 which could calculate premiums for a user.
As will be discussed below with respect to Config Tool 175, the present invention is extensible at a variety of “extension points” including Controllers (e.g., to change the control flow of a module), Views/Controls/Forms (e.g., to add new UI elements and new ways for users to respond), Models (e.g., to store new types of data), Styles (e.g., custom CSS styles), and Tags (e.g., custom XML tags to add new features or simplify data representation). In one embodiment, use of the Parsley Framework also provides various extension points without accessing internal source code.
Plan Templates are employed to facilitate rapid customization of individual aspects of plans (e.g., the amount of the deductible for a particular insurance policy). Module Templates permit configuration and customization of various different component Elements of a Product Module, beyond the design of individual product or service plans. Moreover, “Presets” enable third-party providers and developers to group multiple different configurations (e.g., swappable Elements), thereby further simplifying the process of configuring and customizing a Product Module. Each of these concepts is discussed in greater detail below.
II. Config ToolThe screen snapshot in
Note that an individual Product Module might include one or more of these products or plans, both within and across different product categories 520. Regardless of the grouping of products within a Product Module, Config Tool 175 permits users to customize (in this embodiment) certain aspects of individual products or plans, as well as more global aspects within and across Product Modules. In one embodiment, each product category 520 corresponds to a Product Module. For example, a Medical Module might include one or more medical products selected from among the list of available products 530 (but no products from other non-medical categories, such as dental, vision, etc).
The purpose of UI 500 is to enable a user/provider to determine which products to include for a particular deployment. For example, an insurance provider might offer both HMO and PPO products to employees of one particular company, but only HMO products to employees of another company. In the example illustrated in
Note that the list of selected products 560 also includes other products outside of the Medical category 520a. For example, no products have yet been selected from the Dental category 520b, while Vision Plan A was previously selected from Vision category 520c. Similarly, Term Life was selected from Life category 520d, while Vol STD was selected from Disability category 520e.
Having selected which of the available products 530 across the various product categories 520 to include in a particular deployment, a user/provider may then configure various global presentation-related aspects for one or more Product Modules, as shown in
In the embodiment illustrated in
Turning to
Having selected a particular Product Module 720 and plan 730, a user/provider could then configure a variety of data 740 associated with that plan 730. As noted above, many products or plans (and/or categories of plan designs) have a great deal of similarity with one another. By presenting these common data elements, different providers can easily customize this data to reflect the specific details of their plans.
For example, in one embodiment, data 740 includes not only the Name 741 of the plan, but also the Calculation 743 employed (e.g., via a calculator widget with an overall cap on the coverage amount, as well as a cap on the customer's salary), including its Type 745 (e.g., an “age-banded” calculation offering different costs and benefits based on the age range of the customer). In addition, amounts can be entered for Minimum 747 (e.g., 1000) and Maximum 749 (e.g., 500,000) coverage Caps, Guaranteed amounts 751 (e.g., 250,000), a particular level 753 (e.g., 4) of Salary Caps, and an increment 755 (e.g., 10,000) amount separating the different coverage levels. Finally, similar data 740 can be specified for family members, such as spouses (Maximum 757, Minimum 759, Cap 761 and Increment 763) and children (Minimum 765 and Maximum 767). The structure of Module Templates and Plan Designs will be discussed in greater detail below in order to provide a context in which the configuration and customization of this plan data 740 can be better understood.
Turning to
In addition to branding the characters themselves, a user/provider can also select from among various Company 830 and Character 840 logos that can be incorporated within Product Modules at various points, depending upon the design of Module Templates and their component Elements, as discussed in greater detail below.
Finally, turning to
In this example, Step 1 940 of TOC 930 has been selected, enabling a user/provider to edit or select the Line of text 941 that will be displayed initially when Term Life Module 920 is launched. In addition, the accompanying initial Audio 943 (e.g., an introductory speech by trusted insurance advisor Harvey Keck) and associated Animation 947 (e.g., a bicycle crash animation referenced by Harvey) can be selected from among various choices, with the previously selected Logo either shown or hidden via checkbox 945. Another option might include an extended vignette (via checkbox 949), such as a longer animation with additional audio, text, etc.
Similar configuration of subsequent Steps (e.g., Step 10 950) is also shown, including checkbox 951 to show or hide the previously selected Logo, and dropdown 953 to select the desired Animation (e.g., illustrating the General Benefits of Term Life Module 920). In this manner, a wide variety of different Elements of each Product Module can be configured and customized. Of course, certain levels of customization will require use of Authoring Tool 165 (e.g., creating a completely new Animation), but many of the most frequently desired modifications can be incorporated into Config Tool 175 as required by the demands of third-party providers, corporations and other customers.
III. Configurable Product Modules, Templates and Component ElementsHaving discussed the user interface and various features of Config Tool 175, it is helpful to understand the underlying structure of Product Modules during which these configurable components are developed. As noted above, Module Templates facilitate the development of Product Modules sharing many common Elements, while Plan Designs also include Plan Templates for similar reasons.
Once the Life Module is deployed, prospective customers are authenticated by logging into the system (Login 1001) and selecting a Product Module 1002 (in this case, a Life Module including a particular life insurance plan). A block diagram of a Life Module Template 1010 illustrates key component Elements through which prospective customers can navigate. The interactive flow is determined by the logic of Controllers, shown in this embodiment as multiple Base Script XML Blocks 1012, which include sequential, conditional and event-based logic associated with individual Elements or groups of Elements, and initiated by a “main” Controller (not shown) when the Program Module is launched.
A key Element of Life Module Template 1010 is Plan Design Template 1015 which in this embodiment employs a JavaScript Object Notation (JSON) script 1017 (for representing simple data structures and arrays) to define the various data components of the life insurance plan offered to prospective customers. The components of this plan, including a Plan Template, are discussed in greater detail below with respect to
Intro 1020 is the initial Element with which prospective customers interact. In this example, two different introductory vignettes are included—Intro A 1021 (including two Dialogue components) and Intro B 1022 (including 3 Dialogue components). Each Dialogue component might include one or more lines of spoken dialogue. Referring back to Animation tab 910 of Config Tool 175 shown in
At runtime, the system displays the selected Intro Element 1020, and plays the associated Intro Audio 1023, which in this example includes a choice of a short 1024 or long 1025 version (implemented as MP3 audio files). Note that, in this example, Intro B 1022 also includes the display of an associated Intro Logo 1026, which itself can be tailored to different companies, illustrated here as a Company A Logo 1027 and a Company B Logo 1028. Note that such branding could be selected via Branding tab 810 of Config Tool 175 (see
Following Intro 1020, Life Module Template 1010 causes a menu to be displayed on the screen, offering prospective customers a choice of educational options to explore. These options are illustrated and discussed below (starting with
Another Element in Life Module Template 1010 is Calculator 1035, which in this example offers a choice among a simple 1036, complex 1037 and multi-step 1038 calculator. These calculators (e.g., widgets that implement particular formulas to calculate numeric amounts, percentages, etc. on given data constants and variables) can be associated with certain aspects of Plan Design 1015. For example, Calculator 1035 might be employed to calculate a life insurance benefit based upon variables such as a customer's age, salary or deductible, among other factors. Certain calculations require relative simple formulas, in which case simple Calculator 1036 might suffice, while other calculations require more complex 1037 and even multi-step 1038 Calculators. In other embodiments, Life Module Template 1010 could include multiple different calculators, each selecting from simple, complex, multi-step or other types of Calculators.
Just as Life Module Template 1010 includes an Intro Element 1030, it also includes a Closing Steps Element 1040, which might for example, provide some final summary information (not shown) to facilitate the prospective customer's purchase decision. Note that some or all of the Elements included in Life Module Template 1010 can be configured and customized in Config Tool 175.
In addition, to further simplify the configuration process, the concept of Presets 1050 enables third-party providers and developers to save lists of multiple different configurations. For example, Preset A 1052 (which could be given a more descriptive name) includes 5 different configuration selections: (i) a particular Plan Template (#2), (ii) a particular “What Is It?” Element (long 4-step Element 1034), (iii) simple Calculator 1036, (iv) long Intro Audio 1025, and (v) Company A Logo 1027. This enables a user/provider of Config Tool 175 to select all 5 of these configuration choices with a single selection of Preset A 1052. Similarly, Preset B 1054 includes 4 selections (some of which overlap with Preset A 1052): (i) Plan Template (#2), (ii) short 1-step “What Is It?” Element 1032, (iii) simple Calculator 1036, and (iv) short Intro Audio 1024. Other Presets (e.g., Preset n 1056) may also be selected via Config Tool 175.
Finally, a Character Library 1060 (including a database of character parts) enables third-party providers and developers to configure and customize various different aspects of a virtual character's appearance and behavior. In one embodiment, the ability to customize virtual character attributes is included in Config Tool 175. In others, a separate tool is provided. In the example illustrated in
Turning to the Templates 1100 illustrated in
Plan Design Template 1115 in turn includes variables representing common data components that are utilized to generate various aspects of a particular life insurance plan, such as Minimum and Maximum coverage amounts 1151, an ageTable data structure 1152 (used, for example, to hold different benefit values associated with different age ranges), a Salary Cap data structure 1153, along with certain Guaranteed Salary Cap amounts 1154, a variable number of Annual Pay Periods 1155, values for covering children 1156, and a host of other data variables that are common to particular types of life insurance plans. Where different providers offer significantly different types of plans having fewer common data variables, multiple different Plan Templates can be employed, again allowing a provider to select among them via Config Tool 175.
The Templates 1200 shown in
Moreover, with respect to Plan Design Template 1215, the values of the various different types of data have been filled into the corresponding data structures. For example, data values 1251 include selected amounts for global, “plan-level” minimum, maximum and guaranteed caps (including maximums for children), while data values 1252 include similar amounts for individual plan members. Data values 1253 include similar amounts for spouses (including percentage caps and different array levels for spousal coverage), while data values 1254 include coverage amounts and fee multipliers for children. Finally, data values 1255 include miscellaneous global, “plan-level” values, such as the number of annual pay periods, a decision not to take the spouse's age into account and an age table including coverage multipliers for different age ranges.
IV. Configurable Character LibrariesAs referenced above, Character Library 1300 shown in
In one embodiment, each of the Character Sets 1305 contains certain core components, including (i) Bodies, (ii) Body Parts, (iii) Faces; (iv) Costumes; (v) Clothing and (vi) Expressions. These core components are designed to be combined to enable the creation of individual virtual characters whose identity is retained even when animated exhibiting different appearances and behaviors.
For example, by selecting a particular Body, Body Parts (e.g., hands, legs, etc) and Face, a distinct recognizable virtual character can be created. That virtual character can then be employed to generate multiple different animation sequences, exhibiting different behaviors (talking, walking, running, etc.). Moreover, the appearance of that virtual character can be modified by altering its Costumes, Clothing and facial Expressions.
Upon selecting a virtual Character Set 1340, and customizing its appearance, a provider can then select from among various different behaviors in Animation Library 1350. For example, the selected virtual character can be deployed in different poses surrounded by different props, and exhibiting various different facial expressions. Standard and custom animations can be chosen to enable selected virtual characters to exhibit a wide variety of different behaviors.
In addition, background settings for selected virtual characters can be selected from Background Asset Library 1360, including visual assets such as buildings, trees, mountains, streets, sidewalks and signposts, as well as background animations. Selections from Animation Library 1350 and Background Asset Library 1360 are integrated into vignettes forming Final Scenes 1370 that will be displayed to prospective customers.
In one embodiment, Final Scenes 1370 include only programmatic data, distinct from the actual assets themselves. Such data include script logic (implemented, for example, in ActionScript) and Frame Labels, and controls scene timing as well as the playback of selected animations (including rotations and other translations). A distinct Audio Library 1375 is integrated with multiple Final Scenes 1370 to form Product Modules 1380 that ultimately will be deployed to prospective customers. A Suite 1390 of these Product Modules 1380 is then available for subsequent configuration and customization (before and during runtime) by third-party providers and developers.
Once Product Modules 1380 are completed, they can be deployed on various different platforms, including web-based or corporate server platforms (such as Server Platform 130 in
To illustrate the result of deploying these customized Program Modules 1380, an example scenario of a deployed Life Module is depicted in
Screen 1400 includes a depiction of a virtual character, in this case trusted insurance advisor Harvey Keck 1410, who can interact with and educate the prospective customer regarding a provider's insurance products, and ultimately enable the purchase of such products. Note that Harvey 1410 is the result of a particular selected combination of virtual character parts (face, body, arms, legs, etc), and exhibits a desired appearance (e.g., clothes, glasses, etc) as well as various animated behaviors (movements, gestures, etc), along with background visual elements, such as his desk 1415.
In addition, navigation buttons are displayed to enable the prospective customer to interact with Harvey 1410, and invoke certain functionality. For example, button 1420 will toggle (e.g., mute) the audio, including Harvey's voice and any background sounds. Button 1430 will display a scene Menu that is discussed with respect to
Upon the launch of the Life Module, the Intro Element will be invoked (discussed with respect to
Following this introductory scene, a menu screen 1600 (depicted in
Should a prospective customer select menu item 1620, then a “What Is It?” Element would be invoked, illustrated in screen 1700 of
In this example, the prospective customer enters “25” in text input box 1830, which invokes screens 1910-1950 in
For example, Harvey begins by explaining that younger people don't necessarily have the same financial responsibilities as do older people (
Alternatively, if the prospective customer entered the age of “55,” as shown in input text box 2030 of
Finally, if a prospective customer selects the “How Much Should I Buy?” menu item 1650, then Harvey asks for information in order to provide an estimate of the appropriate amount of coverage. For example, in screen 2400 of
Similarly, if the customer indicated (on screen 2600 of
While particular embodiments of the present invention have been illustrated and described above, it will be apparent to those skilled in the art that various modifications may be made in the arrangement, operation and details of the methods and apparatus disclosed herein without departing from the spirit and scope of the present invention defined in the claims below.
Claims
1. A method for enabling online providers of products and services to customize complex multi-stage transactions with prospective customers, the method including the following steps:
- (a) hosting on a first set of computers a deployed application that is accessible from a second set of computers by prospective customers of a plurality of online providers offering to sell particular products or services;
- (b) enabling the online providers to configure, via a third set of computers, one or more runtime assets utilized by the deployed application to personalize interactions with prospective customers; and
- (c) employing a virtual character in the deployed application on the first set of computers to interact with and educate the prospective customers regarding the characteristics and suitability to the prospective customers of particular products or services offered by the online providers, wherein the interaction is personalized by: (i) the virtual character extracting demographic and behavioral data from the prospective customers; (ii) selecting, based upon the extracted data and configured runtime assets, educational materials as well as particular attributes of the goods and services offered by the online providers; and (ii) presenting the selected educational materials to the prospective customers to facilitate their purchasing decision.
Type: Application
Filed: Jan 10, 2014
Publication Date: Oct 16, 2014
Applicant: Navera, Inc. (San Francisco, CA)
Inventors: MICHAEL HOCH (San Francisco, CA), PETER W. STEVENSON (Burlingam, CA), KEVIN C. DUNN (Roseville, CA), MICHAEL MILLS (Redwood City, CA), ROGER BRADLEY-JUNGEMANN (Half Moon Bay, CA)
Application Number: 14/152,986
International Classification: G06Q 30/06 (20060101);
