Methods, systems, and computer program products for facilitating user choices among complex alternatives using conjoint analysis6826541Abstract Methods, systems, and computer program products for facilitating user choices among complex alternatives utilize conjoint analysis to simplify choices to be made by the user. A selector tool presents a user with a first and second series of choices relating to attributes of products or services available to the user. A utilities calculation engine calculates the relative utility of each of the products or services to the user and presents output to the user, which indicates the relative utility of each of the products or services. The user can then select the product or service that has the highest utility value for the user based on the calculated relative utility values. Claims What is claimed is: Description TECHNICAL FIELD
Keyword or Key Phrase Definition
"user" A person going through the software exercise
to gain help in making a choice
"alternative" A single product or service (among a set of
products or services) the "user" can potentially
choose
"choice set" All the "alternatives" the "user" is eligible to
choose from
"attribute" One of numerous variables, each defined as
the continuum between its worst "setting" and
best "setting," used to define the "alternatives"
"setting" (or "attribute The value a particular hypothetical or actual
setting") "alternative" has for a particular "attribute"; the
hypothetical "alternatives" studied during the
data-gathering phase of the algorithm are all
specified in terms of the worst "setting" vs the
best "setting" for each "attribute," whereas
actual "alternatives" available to the "user"
may be specified by "settings" anywhere
along each "attribute's" continuum
"importance" A measure that the user gives directly via the
importance-of-the-difference (between worst
and best "settings") screens of the relative
importance of a single "attribute"
"difference in A measure that the user gives directly via the
importance" trade-off screens of the (mathematical)
difference in the "importance" of two
"attributes"
"final computed A final estimate of the true relative importance
importance" of an "attribute" to a "user"
"setting utility" The relative (relative to all "attribute settings")
(or "attribute worth or utility of a particular
setting utility") "attribute setting"
(anywhere along the "attribute" continuum) to
a particular "user"
"total utility" The total relative (relative to all "alternatives"
available to that user) worth or utility of a
particular "alternative"; defined as the simple
sum across "attributes" of the "setting utilities"
To ensure these keywords and phases are understood, the following example is given. A person is trying to make a choice between a medium-quality bicycle priced at $250 and a high-quality bicycle priced at $375. The person is given a tool that assists the person in the selection. The tool requires the person to state on a 1-to-5 scale the relative importance of quality and price. For purposes of this example, it is assumed that the person selects 5 and 4, respectively. The values "5" and "4" are "importance" measures as defined above. The tool also asks the person to rate to what degree the person would prefer a high-quality, $500 bicycle to a low-quality, $100 bicycle. In this example, it is assumed that the person indicates a preference for the higher quality, more expensive bicycle, a "+1" on a -4-to-+4 scale. The value +1 is a "difference in importance" value as defined above. The tool then computes that the true importance (on a 1-to-5 scale) of quality and price for this person is a 4.7 and a 4.1, respectively. The values 4.7 and 4.1 are "final computed importance" values, as defined above. These values are used in turn to compute that high-quality is worth 25 (unitless) points to the person whereas medium quality is worth 15 points. The values "15" and "25" are "setting utilities" for the quality and price attributes. Similarly, the tool computes that $250 is worth 15 points to the person and $375 is worth 10. Thus, the tool computes that the total worth of the medium-quality bicycle priced at $250 is 30 points (15+15) and that the total worth of the high-quality bicycle priced at $375 is 35 points (25+10). The 30 and 35 point values are "total utility" values as defined above. Because 35 is higher than 30, the tool has computed that the medium-quality bicycle priced at $250 is worth slightly less to the person, all things considered, than the high-quality bicycle priced at $375. Thus, the tool recommends that the person should choose the high-quality bicycle priced at $375. The following table provides a summary of examples of each keyword or key phrase from the above example.
Keyword or Key Phrase Example
"user" The person shopping for a bicycle
"alternative" The medium-quality bicycle priced at $250
and the high-quality bicycle priced at $375 are
the actual "alternatives"; the high-quality, $500
bicycle and the low-quality, $100 bicycle are
the hypothetical "alternatives" used in the
data-gathering phase
"choice set" The medium-quality bicycle priced at $250
and the high-quality bicycle priced at $375
together form the actual choice set for the
"user"; the high-quality, $500 bicycle and the
low-quality, $100 bicycle form a hypothetical
"choice set" to which the "user" is asked to
react.
"attribute" Quality is an "attribute" as is price
"setting" (or $375 is an actual "setting" of price; $100 is a
"attribute setting") hypothetical "setting" for price
"importance" The "5" given for quality
"difference in The "+1"
importance"
"final computed The "4.7" for quality
importance"
"setting utility" The "25" for the high-quality
(or "attribute "setting" of quality
setting utility")
"total utility" The "30" for the medium-quality bicycle priced
at $250 "alternative"
One goal in developing the present invention was two-fold. First, create an adaptation of conjoint that is as user friendly as possible (keep it short and easy to understand). Second, go beyond the end of traditional conjoint (developing "utilities") and apply these utilities to the performance of a set of products, presenting the user with a sorted list of how well each product meets their stated preferences. In adapting a research statistical technique, traditionally used to study group preferences, and using it to match individual consumer preferences to actual products or services, the present invention application has established a highly useful product in the marketplace. As mentioned above, conjoint has been in use since the 1970's. While there are a variety of implementations of the conjoint algorithm in the market the design chosen for implementation of the present invention is exceptionally simple, and yet robust. In addition, the way the present invention has been developed makes it unique. For example, features of real products are evaluated and levels are created, so that all products can be compared by the application in a purely objective basis. The feature attribute descriptions are made as simple and as straightforward as possible. In addition, after the user completes the process of selecting attributes features of the product, making importance of difference decisions, and then trade-off decisions, the application presents results to the user in very simple bar-chart form. The application shows all products available to the user in priority order, based on how well each product matches the preference utility of that individual. The algorithm utilized by the present invention is unique, in that it provides for paired trade-offs (two by two comparisons of end-point "attribute" characteristics) instead of the usual more complicated trade-offs involving more than two "attributes" defined not only by their end-points (best and worst "settings") but by numerous "settings" along their entire continuum. As used herein, the term "endpoints" refers to the best and worst settings of an attribute. For example, in the bicycle example discussed above, $100 and $500 are endpoints for the price attribute; whereas "high" and "low" are endpoints for the quality attribute. According to another aspect of the invention, an "X" matrix utilized to estimate "attribute" "utilities". An "X matrix", as described herein, is a configuration of explanatory variable data, or numbers, in a mathematical format. The "X matrix" designates the independent variable values used in the ordinary least squares matrix set, whereas the "Y Matrix" designates the dependent variable values. Examples of X and Y matrices and their use in calculating utilities for attributes will be discussed in more detail below. Yet another aspect of the invention is the way in which the results of a user's interaction with the tool are "fed back" to the user. For example, each individual's alternative choices of products, services or concepts are ranked in declining order of "total utility." This way of "reporting" back to each user on how their priorities and decision criteria "value" each alternative clearly indicate the "best fit" choices among all the alternatives in an individual's "choice set." While one use of the present invention is "attribute" preference-based decision support tool, the software also simultaneously creates databases of user-level "preference data" (i.e. "final computed importance" and "setting utility" data) and other descriptive data. This data has value in the marketplace to producers and middleman organizations as conjoint research and can be used for developing analyses of market share "attribute" importance, and other outcomes of the decision-making process. The creation and merchandizing of this data is very much a fundamental aspect of the tool's value. Currently, the focus of use for the present invention is in the selection of health plans by consumers or employees of medium-sized or large employers. The fringe benefits of most employers of any size typically include health care financing, and it is not unusual to find medium and large employers offering 3, 4 or more health plans to its employees. An employee of those companies uses the present invention to help him/her select that plan from among the alternatives offered which is best suited to him/her. As discussed above, employees are left by their employers to their own resources in selecting a health plan. The major barrier to a more activist policy by employers is one of liability for employee choices. Another barrier is an economic one since uncertain employees commonly consume huge amounts of human resources staffer time seeking guidance in making their choices among health plans. Left to their own devices, employees will seek advice from other employees or may select a plan based on one or a few criteria--such as premium cost, type of plan or perhaps two or three features of a plan. The present invention alleviates these problems by applying conjoint analysis to facilitate user choices among a large array of complex alternatives. While the present invention is suitable for assisting employees choose health plans, it has been developed to be generic/flexible enough to be applied to any complex decision. For example, the algorithms described herein are suitable for facilitating user choices among a variety of complex alternative, supplemental insurance, 401k plans/mutual funds, and other product or service categories. Prototypes of this application have been developed, for instance, to assist consumers in choosing computers, and businesses and consumers to choose energy companies. There are many other uses of this application currently being planned. BRIEF DESCRIPTION OF THE DRAWINGS Preferred embodiments of the invention will now be explained with reference to the accompanying drawings, of which: FIG. 1 is a block diagram illustrating an exemplary operating environments for embodiments of the present invention; FIG. 2 is a block diagram of a selector tool server according to an embodiment of the present invention; FIG. 3 is a block diagram illustrating the relationship between screens presented to the user by the selector tool server according to an embodiment of the present invention; FIG. 4 is a screen shot of attribute selection page 302 illustrated in FIG. 3; FIG. 5 is a screen shot of importance page 304 illustrated in FIG. 3; FIG. 6 is a screen shot of paired trade-off page 306 illustrated in FIG. 3; FIG. 7 is a screen shot of results page 308 illustrated in FIG. 3; FIG. 8 is a screen shot of details page 310 illustrated in FIG. 3; and FIG. 9 is a block diagram of a layered selector tool server according to an embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION Overview A method for facilitating user choices among complex alternatives according to an embodiment of the present invention is comprised of three main steps followed by results and detailed product comparisons. Each of these steps through the exercise are interactive--that is, they engage the "user" and require the "user's" input. In addition, each step relies on the previous step. How the "user" responds in one step will affect what the user is asked to do in subsequent steps. At the end of these steps the user is provided with results. The main components of the tool are: 1. "Attribute" Selection--branded on the site displayed as "Attribute Selection" 2. "Importance" Ratings--branded on the site displayed as "Importance of Difference" 3. "Difference in Importance" Ratings--branded on the site displayed as "Trade-Offs" 4. Results 5. Detailed "Alternative" Comparisons Software for implementing each of these steps will be discussed in more detail below following a discussion of the operating environment for the software. Exemplary Operating Environment Turning to the drawings, wherein like reference numerals refer to like elements, the invention is illustrated as being implemented in a suitable computing environment. Although not required, the invention will be described in the general context of computer-executable instructions, such as program modules, being executed by a personal computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Moreover, those skilled in the art will appreciate that the invention may be practiced with other computer system configurations, including hand-held devices, multi-processor systems, microprocessor based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, and the like. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices. With reference to FIG. 1, an exemplary system for implementing the invention includes a general purpose computing device in the form of a conventional personal computer 20, including a processing unit 21, a system memory 22, and a system bus 23 that couples various system components including the system memory to the processing unit 21. The system bus 23 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. The system memory includes read only memory (ROM) 24 and random access memory (RAM) 25. A basic input/output system (BIOS) 26, containing the basic routines that help to transfer information between elements within the personal computer 20, such as during start-up, is stored in ROM 24. The personal computer 20 further includes a hard disk drive 27 for reading from and writing to a hard disk, not shown, a magnetic disk drive 28 for reading from or writing to a removable magnetic disk 29, and an optical disk drive 30 for reading from or writing to a removable optical disk 31 such as a CD ROM or other optical media. The hard disk drive 27, magnetic disk drive 28, and optical disk drive 30 are connected to the system bus 23 by a hard disk drive interface 32, a magnetic disk drive interface 33, and an optical disk drive interface 34, respectively. The drives and their associated computer-readable media provide nonvolatile storage of computer readable instructions, data structures, program modules and other data for the personal computer 20. Although the exemplary environment described herein employs a hard disk, a removable magnetic disk 29, and a removable optical disk 31, it will be appreciated by those skilled in the art that other types of computer readable media which can store data that is accessible by a computer, such as magnetic cassettes, flash memory cards, digital video disks, Bernoulli cartridges, random access memories, read only memories, and the like may also be used in the exemplary operating environment. A number of program modules may be stored on the hard disk, magnetic disk 29, optical disk 31, ROM 24 or RAM 25, including an operating system 35, one or more applications programs 36, other program modules 37, and program data 38. A user may enter commands and information into the personal computer 20 through input devices such as a keyboard 40 and a pointing device 42. Other input devices (not shown) may include a microphone, touch panel, joystick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to the processing unit 21 through a serial port interface 46 that is coupled to the system bus, but may be connected by other interfaces, such as a parallel port, game port or a universal serial bus (USB). A monitor 47 or other type of display device is also connected to the system bus 23 via an interface, such as a video adapter 48. In addition to the monitor, personal computers typically include other peripheral output devices, not shown, such as speakers and printers. With regard to the present invention, the user may use one of the input devices to input data indicating the user's preference between alternatives presented to the user via monitor 47. The personal computer 20 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 49. The remote computer 49 may be another personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the personal computer 20, although only a memory storage device 50 has been illustrated in FIG. 1. The logical connections depicted in FIG. 1 include a local area network (LAN) 51, a wide area network (WAN) 52, and a system area network (SAN) 53. Local- and wide-area networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Internet. System area networking environments are used to interconnect nodes within a distributed computing system, such as a cluster. For example, in the illustrated embodiment, the personal computer 20 may comprise a first node in a cluster and the remote computer 49 may comprise a second node in the cluster. In such an environment, it is preferable that the personal computer 20 and the remote computer 49 be under a common administrative domain. Thus, although the computer 49 is labeled "remote", the computer 49 may be in close physical proximity to the personal computer 20. When used in a LAN or SAN networking environment, the personal computer 20 is connected to the local network 51 or system network 53 through the network interface adapters 54 and 54A. The network interface adapters 54 and 54A may include processing units 55 and 55A and one or more memory units 56 and 56A. When used in a WAN networking environment, the personal computer 20 typically includes a modem 58 or other means for establishing communications over the WAN 52. The modem 58, which may be internal or external, is connected to the system bus 23 via the serial port interface 46. In a networked environment, program modules depicted relative to the personal computer 20, or portions thereof, may be stored in the remote memory storage device. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used. In the description that follows, the invention will be described with reference to acts and symbolic representations of operations that are performed by one or more computers, unless indicated otherwise. As such, it will be understood that such acts and operations, which are at times referred to as being computer-executed, include the manipulation by the processing unit of the computer and/or the processing units of I/O devices of electrical signals representing data in a structured form. This manipulation transforms the data or maintains it at locations in the memory system of the computer and/or the memory systems of I/O devices, which reconfigures or otherwise alters the operation of the computer and/or the I/O devices in a manner well understood by those skilled in the art. The data structures where data is maintained are physical locations of the memory that have particular properties defined by the format of the data. However, while the invention is being described in the foregoing context, it is not meant to be limiting as those of skill in the art will appreciate that the acts and operations described hereinafter may also be implemented in hardware. In FIG. 1, exemplary application programs 36 used to implement the present invention include a selector tool server 36A implemented on local computer 20 and a selector tool client 36B implemented on remote computer 49. Selector tool server 36A may communicate with selector tool client 36B over local area network 51, system area network 53, or wide area network 52. Exemplary communication protocols that may be used for communication between selector tool server 36A and selector tool client 36B over LAN 51 or SAN 53 include HTTP over TCP/IP. Exemplary communication protocols that may be used to communicate between selector tool server 36A and selector tool client 36B over WAN 52 include the point-to-point protocol (PPP). Selector tool server 36A preferably performs the functions of presenting the user with a series of choices relating to complex alternatives, calculating relative utility scores of the alternatives based on the choices, and feeding back to the user an indication of which of the complex alternatives has the highest utility for that user. Selector tool client 36B may establish a connection with selector tool server 36A in order to provide communications between the user and selector tool server 36A. In a preferred embodiment, selector tool client 36B comprises a web browser, such as Internet Explorer available from Microsoft Corporation of Redmond, Wash., or Netscape Navigator available from America Online Corporation of Reston, Va. The present invention is not limited to a selector tool that is implemented as a selector tool server and a selector tool client connected via a network. For example, in an alternative embodiment, the present invention may be implemented entirely on a local machine wherein the selector tool comprises an application program that presents the user with a series of choices relating to complex alternatives, calculates the relative utility of the complex alternatives, and feeds the relative utility information back to the user entirely on the local machine. However, a networked environment is preferred so that multiple users can access the selector tool server. For example, for company health plan selection, selector tool server 36A may be resident on a server accessible by company employees. In this manner, all employees may access selector tool server 36A using a web browser that is common on most personal computers. In addition, when the health plans offered by a company change, it is easier to update a server or a set of servers than it is to update software on each individual user's personal computer. FIG. 2 is a block diagram of selector tool server 36A. In the illustrated embodiment, selector tool server 36A includes a user interface generator 200 and a utilities calculation engine 202. User interface generator 200 may be a web server. User interface generator 200 preferably presents a series of input screens to the user relating to choices between complex alternatives. User interface generator 200 also receives input from the user and delivers that input to utilities calculation engine 202. Utilities calculation engine 202 calculates a total relative utility value for each of the complex alternatives, based on the user choices. Utilities calculation engine 202 outputs the total utilities calculations to user interface generator 200. User interface generator 200 then outputs the total utilities values to selector tool client 36B. FIG. 3 is a block diagram of exemplary screens that may be presented by user interface generator 200 illustrated in FIG. 2. In FIG. 3, selector tool instruction page 300 provides an overview of how the selector tools works, steps required to be performed by the user in using the tool, and the length of time required to complete the selection. Because selector tool instruction page 300 does not provide an functionality important to describing the invention, further description relating thereto will not be presented herein. Attribute selection page 302 provides a listing of attributes, allows the user to select attributes that are of importance to the user, and links each attribute to terms to know. FIG. 4 is a screen shot of an exemplary attribute selection page 302. In FIG. 4, attribute selection page 302 includes an instruction portion 400 that provides the user with instructions on how to use attribute selection page 302. In the illustrated example, instruction portion 400 instructs the user that the user must select at least four attributes in order for the tool to work. Attribute selection page 302 also includes an attribute selection portion 402 that allows the user to select attributes that are of importance to the user and that allows the user to access definitions of terms. In the illustrated example, attribute selection portion 402 includes a table containing attribute categories relating to employer-sponsored health plans, such as cost and access. Each attribute category includes a series of attributes. In the illustrated example, the "cost" attribute category includes attributes such as monthly employee contribution, annual deductible, separate per-admission hospital deductible, etc. Similarly, the "access" attribute category includes attributes such as coverage of brand name prescription drugs of choice and the ability to self-refer to a specialist. In order to select an attribute of importance, the user clicks on the appropriate box using an input device, such as a mouse. The attributes selected by the user will be used in calculating the relative utilities of health plans. Referring back to FIG. 3, once the user has selected attributes that are of importance to the user, the user is presented with importance page 304, which allows the user to rate the importance of each attribute. FIG. 5 is a screen shot illustrating an exemplary embodiment of importance page 304. In FIG. 5, importance page 304 includes an instructions portion 500 that explains to the user the mechanics of using importance page 304. Importance page 304 also includes an importance of difference portion 502 that presents the user with two hypothetical values that a plan could possess for each attribute: a high value and a low value. A scale is provided that requires the user to rate how important the difference is to the user between the two possible alternatives. In the illustrated example, the attribute being evaluated is monthly employee contribution to a health plan. The user is asked to rate the importance of the difference between a plan with an employee contribution of $38 per month versus a plan with an employee contribution of $90 per month. A scale is provided below the choice that allows the user to rate the degree of importance between the two settings for each variable selected: a best setting and a worst setting. In the illustrated example, the user may indicate that the difference between an employee contribution of $38 per month and an employee contribution of $90 per month is very important. Importance page 304 stores a value indicative of the relative importance of the difference to the user and passes this value to utilities calculation engine 202 (illustrated in FIG. 2). The user is preferably presented with a series of preference pages 304 that require the user to rate the relative user's preference between best and worst settings of variables relating to an attribute. Once the user has completed the importance of difference rating step, referring back to FIG. 3, the user is presented with a series of paired trade-off pages 306. Each paired trade-off page 306 requires the user to rate paired sets of attributes. In particular, the user is presented with the best setting of one attribute and the worst setting of another attribute versus the worst setting of the first attribute and the best setting of the second attribute and the user is asked to rate the relative degree of importance of the best and worst settings of the different attributes. FIG. 6 illustrates an exemplary paired trade-off page 306 according to an embodiment of the present invention. In FIG. 6, paired trade-off page 306 includes instructions portion 600 that instructs the user on how to select between the alternatives presented on page 306. Paired trade-off page 306 also includes a trade-off selection portion 602 which presents the user with two pairings of two different attributes. In a preferred embodiment, the user is presented with a first pairing that includes a highest setting of one attribute and a lowest setting of another attribute and a second pairing that contains the highest setting of one attribute and the lowest setting of another attribute. For example, if the attributes are A1 and A2, the first pairing would be high(A1) AND low(A2), and the second pairing would be low(A1) AND high(A2). In the example illustrated in FIG. 6, the pairings of attributes are as follows: an annual deductible of $0 and an employee contribution of $90 per month versus an annual deductible of $500 and an employee contribution of $38 per month. The represent combinations of high and low settings of the illustrated attributes--monthly contribution and annual deductible. The user is required to rate the user's preference between the pairings using discreet values on the scale provided below the pairings. For example, if the user strongly prefers an annual deductible of $500 and an employee contribution of $38 per month versus an annual deductible of $0 and an employee contribution of $90 per month, the user may select one of the circles on the right side of pair trade-off page 306. The user is presented with a series of paired trade-off screens 306 and is required to rate the user's preference for each of the pairings. Values indicative of each of the user-selected ratings are provided to utilities calculation engine 202 illustrated in FIG. 2. Once the user has completed all of the importance pages 304 and paired trade-off pages 306, the selector tool performs the following steps: 1. Using utilities calculation engine 202, a "final computed importance" is calculated for each "attribute" used in the exercise. This is a measure of the relative importance of the "attribute" with respect to the "settings" of that "attribute" presented as well as to the relative importance of all the other "attributes." 2. Utilities calculation engine 202 gathers the performance levels (actual "settings") for each "alternative" available to the "user," for each "attribute." 3. For each "alternative" and "attribute" utilities calculation engine 202 creates a "setting utility" score for each "alternative" available to the "user." Details of this calculation are described below. The sum of the "setting utility" scores for all the "attributes" for an "alternative" become the "alternative's" "total utility" score. This value is unique to each "alternative"/"user" combination. 4. The "user" is then presented with a list of all the "alternatives" available to them with a graphical representation of the relative "total utility" scores of the "alternatives." With this information, the user can ascertain how well each "alternative" matches their stated importance. Referring back to FIG. 2, results page 308 presents the results from the utilities calculation to the user. The utilities are measured in terms of a preference value that indicates the relative utility of each choice to that particular user. Alternative choices may be sorted in any order, such as descending order. FIG. 7 illustrates an exemplary results page 308 according to an embodiment of the present invention. In FIG. 7, results page 308 includes a description portion 700 that describes the contents of results page 308. Importance indicator portion 702 includes a table having a bar graph that graphs the importance indicator value for each of the complex alternatives. In the illustrated example, the bar graph indicates that PSC test plan 2 more closely matches the user's preferences than PSC test plan 1. Accordingly, based on results page 308, the user should select PSC test plan 2 as the user's health plan. Referring back to FIG. 3, a details page 310 can be accessed from any of the other pages 300, 302, 304, 306, and 308. Details page 310 explains the feature of the page from which details page 310 was accessed. For example, if details page 310 is accessed from results page 308, a more comprehensive explanation of the results will be presented. FIG. 8 illustrates an example of details page 310 accessed from results page 308. Referring to FIG. 8, details page 310 includes an explanation portion 800 that explains the content of details page 310. Details page 310 includes a content table 802 that compares the attributes of two choices presented to the user. In the illustrated example, the choices are employer-sponsored health plans. The attributes include features of the health plans, such as annual deductible, employee contribution, and out-of-pocket costs for prescriptions. Thus, as illustrated above, the present invention provides a user-friendly graphical user interface that simplifies complex choices for users. The users are presented with two series of simple choices. Based on the user's responses to the simple choices, the utilities calculation engine of the present invention calculates the relative utility of complex choices for the user. By breaking the complex choices into series of simple choices, the present invention greatly facilitates user selection among complex choices. Detailed Description of Calculations Performed by Utilities Calculation Engine The statistical algorithm implemented by utilities calculation engine 202 involves the calculation of "regression" coefficients (u.sub.k) for the equation: y.sub.i =.alpha..sub.i +u.sub.1 *a.sub.1i +u.sub.2 *a.sub.2i + . . . +u.sub.k *a.sub.ki +e.sub.i where y.sub.i is a variable with i possible observations per tool user, representing the quantitative values chosen by a individual to measure his or her judgment of the importance of the difference between some best value of each important "attribute" and some worst value of the "attribute", as well as values input by that individual to measure his degree of attraction to either of two two-"attribute" alternatives (or choices) (in which the key characteristic of those two-"attribute" alternatives is that the first "attribute" has its best possible value while the second has its worst possible value, and the other alternative's two "attributes" have the characteristic that the first "attribute" has its worst possible value while the second "attribute" has its best possible value). It is important to note that while the "user" provides the relative degree to which he/she prefers one "best/worst" "alternative" (i.e. product) to the other, the algorithm for deriving "final estimated importances" (i.e. the regression analysis) interprets these responses as the mathematical difference in the "importances" of the two "attributes." This unique property of the algorithm is so important that the following example is warranted to clearly illustrate the mechanics. Assume the two "attributes" of a trade-off screen 306 are price and quality and assume the "alternatives" are bicycles. Thus, the trade-off screen might look like the following:
$500 $100
High Quality vs. Low Quality
-4 -3 -2 -1 0 +1 +2 +3 +4
The user is asked to respond with a number between -4 and +4, with a -4 meaning he/she strongly prefers the High Quality, $500 bicycle and a +4 meaning he/she strongly prefers the Low Quality, $100 bicycle. Values between +4 and -4 indicate less strong preferences, with 0 (zero) indicating the user prefers the two bikes equally. Because all "attributes" are studied in the trade-off screens only in terms of their best and worst "settings" and also because exactly two "attributes" are studied in each trade-off screen 306, any value on the +4 to -4 continuum has a second interpretation, besides the relative preference of one "alternative" vs. the other, which is the mathematical difference in the "importance" of the two "attributes" being studied (where the "importance" values are on a +1 to +5 scale). Thus, if a user states a "+3" in the above trade-off, that can be interpreted to mean that price is more "important" than quality and precisely that the "importance" of price is 3 more "importance" points than the "importance" of quality. In other words, the user may have "importance" values for price and quality of +4 and +1 respectively, or +5 and +2 or +4.5 and +1.5 (the actual importance magnitudes are gauged elsewhere (not in the trade-off screens), in the "importance" (i.e. importance of difference) screens). Other trade-off values have similar interpretations (e.g. a "0" is interpreted as the "importance" of price and quality being equal; a "-4" is interpreted as the "importance" of price being 4 "importance" points less than the "importance" of quality (e.g. price "importance"=1 and quality "importance"=5). Another way to view this is that while the user is responding (with respect to moving from -4 to +4) in terms of left-of-screen "alternative" vs. right-of-screen "alternative," the software algorithm interpretation is bottom-of-screen "attribute" vs. top-of-screen "attribute"." This property (interpretation) of the algorithm may indeed be the single most unique aspect of utilities calculation engine 202. The present invention is not limited to using any particular scale for rating user preferences with regard to difference in importance or trade-offs. The size and increments in the scale depend on the desired granularity and the algorithm used to generate the total utility value. As described above, two types of data are gathered from users: 1. The importance of a single "attribute" (defined as the importance of the difference between the best and worst "settings" of that "attribute"), measured on a 1-to-5 scale (using importance pages 304). 2. The difference in the importance of two "attributes. Since the "importance" of each "attribute" is measured on a 1-to-5 scale (see 1 above), the "difference in importance" is measured on a -4-to-4 scale (since the minimum value is a 1 minus a 5 which equals -4 and the maximum value is a 5 minus a 1 which equals 4) (using paired trade-off pages 308). Via regression analysis, both types of data are analyzed together as a single set of information. The result of this regression analysis is a single number for each "attribute" indicating the final estimate of how important the user feels the "attribute" is (on the original "importance" scale). The way the data is coded is as follows: Dependent Variable Vector Y Type 1 "importance" data is simply bottom-augmented with the type 2 "difference in importance" data. Thus, if a user had been asked about 5 "attributes" and had given "importance" scores of 5, 4, 3, 2, and 1, the Y "importance" data would equal:
5
4
3
2
1
Similarly, if the user had seen 6 pairs of "attributes" and had given "difference in importance" ratings of -4, 3, 0, 1, 0, and -2, the Y "difference in importance" data would equal:
-4
3
0
1
0
-2
Thus, the final Y vector would equal:
5
4
3
2
1
-4
3
0
1
0
-2
The number of rows equals the number of observations of data used in the regression analysis and are equal to the number of separate data values supplied by the user for "importance" and for "difference in importance" questions. Independent Variable Matrix X The X matrix associated with Type 1 "importance" data is made of rows that are "dummy" coded with a "1" indicating the "attribute" the user is referring to and 0's otherwise. Thus, assuming the "importance" scores of 5, 4, 3, 2, and 1 given above were in the order of first, second, third, fourth, and fifth "attributes, the X "importance" data would equal:
1 0 0 0 0
0 1 0 0 0
0 0 1 0 0
0 0 0 1 0
0 0 0 0 1
Note that it is not necessary that the order is first, second, third, fourth, and fifth, however. If the data had been in, say, order of second, first, third, fourth, and fifth attributes, then the X matrix would have looked like:
0 1 0 0 0
1 0 0 0 0
0 0 1 0 0
0 0 0 1 0
0 0 0 0 1
For this example, the former order is assumed. In addition to determining an X-matrix for the importance data entered through importance pages 304, utilities calculation preferably also determines an X-matrix for difference of importance data collected through paired trade-off screens 306. The X matrix associated with the "difference of importance" responses is made of rows that are coded as "1" if the "attribute" is one of the pair being traded off and is the "attribute" shown either at the top or the bottom of the screen, "-1" if the "attribute" is one of the pair being traded off and is the "attribute" shown opposite the other "attribute" (at bottom if former is at top of screen and vice versa), and "0" if the "attribute" is not one of the pair being traded off. For example, assuming that the "top-bottom" pairs of "attributes" are first-second, second-third, third-fourth, fourth-fifth, fifth-first, and fourth-second, and the top "attribute" has its best "setting" on the right side of the screen and bottom "attribute" has its best "setting" on the left side of the screen (though this may be interchanged), the X matrix associated with the "difference of importance" data equals
1 -1 0 0 0
0 1 -1 0 0
0 0 1 -1 0
0 0 0 1 -1
-1 0 0 0 1
0 -1 0 1 0
The above X matrix is given only as an example. Pairings of "attributes" may be random or a systematic approach may be used to pair the attributes, as in an orthogonal or near-orthogonal design. As before with the Y vector, the final X matrix is created by bottom-augmenting the "importance" data with the "difference in importance" data. Thus the final X matrix equals
1 0 0 0 0
0 0 0 0 0
0 1 0 0 0
0 0 1 0 0
0 0 0 1 0
1 -1 0 0 0
0 1 -1 0 0
0 0 1 -1 0
0 0 0 1 -1
-1 0 0 0 1
0 -1 0 1 0
Thus, the final set of data to be analyzed is as follows:
Y vector X matrix
5 1 0 0 0 0
4 0 1 0 0 0
3 0 0 1 0 0
2 0 0 0 1 0
1 0 0 0 0 1
-4 1 -1 0 0 0
3 0 1 -1 0 0
0 0 0 1 -1 0
1 0 0 0 1 -1
0 -1 0 0 0 1
-2 0 -1 0 1 0
2 0 0 0 1 0
1 0 0 0 0 1
-4 1 -1 0 0 0
3 0 1 -1 0 0
0 0 0 1 -1 0
1 0 0 0 1 -1
0 -1 0 0 0 1
-2 0 -1 0 1 0
In summary, each row (of both the Y vector and the X matrix) represents a single response the "user" has given, the actual response being recorded in the Y vector. Each column of the X matrix represents an "attribute" the "user" has chosen as important (where rows with only 1's and 0's have a 1 in the column of the "attribute" that is the subject of the "importance"-of-difference screen and rows with 1's, 0's, and -1's have a 1 or -1 in a column to identify which attribute was at the top of and which attribute was at the bottom of the trade-off screen. From this type data set, the B regression coefficients are calculated via B=(X'X).sup.-1 X'Y, where .sup.-1 indicates the matrix inversion transformation and the single quote (') indicates the matrix transpose transformation, are directly interpretable as importance (on the 1-to-5 "importance" scale) scores for the "attributes" they modify. Each B coefficient is paired with and thus modifies one "attribute." A slight variation of this form is to include an additional column of ones ("1"s) in the leftmost position of the X matrix. The extra B coefficient in that instance is not associated with an "attribute" but is a measure of the intercept of the regression model, which theoretically equals zero. That is, in the absence of predicting anything about importance (e.g. an "importance" by plugging in a "1" or a "difference in importance" by plugging in a "1" and a "-1"), that is, only a series of zeros are plugged in, the model predicts zero. That is to say that the null condition of using the model to do nothing "predicts" a "0" (zero) "importance." Each user chooses which m or more "attributes" he/she actually uses in making a selection, where m is a variable threshold and is set in advance. If this number exceeds n then the top n (based on the user's "importance" scores (and predetermined expert judgments of the importance of "attributes" if a tie-breaker is needed)) are used and it is only these that have "final computed importances" calculated via the above formula. Again, n is a variable threshold that is set in advance. For excluded "attributes, the "final computed importance" is set to zero. Thus, the number of "attributes" for which "final computed importances" are calculated varies from user to user. Currently, the software is written to allow for "importance" scores to be calculated for anywhere from four to fifteen "attributes" (that is, m=4 and n=15). While it would be sufficient to simply use the (direct) "importance" scores for each "attribute" to help users select products/services, it is believed that the augmented data, the "difference in importance" data, greatly improves "final computed importances" and thus recommendation results. This is so because users are not actually told they are providing "difference in importance or trade-off" scores, but rather are told to gauge their preference for the best "setting" of one "attribute" paired with the worst of the other versus the worst "setting" of the one "attribute" paired with the best of the other. In this way, the user is actually comparing two products or services. Because only the best and worst "settings" are ever shown and because only two "attributes" are shown at a time, the interpretation of the responses is precisely "the mathematical difference in the importance of the two `attributes` (each on a 1-to-5 scale)." This indirect way of obtaining information on the relative impact importance of "attributes" by comparing a series of hypothetical "alternatives" is a more realistic task for the "user" and is believed to enhance relative importance measurement. With "final computed importances" estimated/calculated, the algorithm moves to using that data to calculate "total utility" scores for each product or service the user is in the market to buy and is eligible to buy. For each "attribute", the "final computed importance" (i.e. the B coefficient from the "attribute") is taken as the value of the worst "setting" of the "attribute" and five times the "final computed importance" is taken to be the value of the best "setting" of the "attribute". Then, using linear interpolation, the "setting" or specification of each product or service is transformed to a value to be presented to the user. For example, if the "final computed importance" of price is 3.2 and the worst price "setting" is $50, and the best price "setting" is $10, then a product with a price of $23.33 would have a "setting utility" for price of 3.2+(5*3.2-3.2)*((23.33-50)/(10-50))=11.7344. The utility numbers are "unitless"; 10.6656 is not 10.6656 dollars or anything else. They are relative numbers that allow for comparing specifications on different "attributes" for a given user. A "setting" on an "attribute" that has a "10" value for user is worth more than a "setting" on the same or another "attribute" that has a value of, say, "7." Individual "attribute" values are summed across the "attributes" making up the products or services, yielding a "total utility" score for each product or service for each user. Utilities calculation engine 202 then rank orders the products or services for the user, in descending order of "total utility." The top product or service in this list is the best recommendation for the product or service the user should choose, given the relative importance the user places on the various "attributes" that make up the products or services and the actual specifications of the products or services. Although the present invention can be used to calculate relative total utilities of products or services based on any number of attributes and attribute pairings, the following examples illustrate exemplary numbers of attributes and corresponding attribute pairings suitable for use with the present invention.
(1) 4 "attribute" engine
Pairs Interpretation
1,4 This array of paired integers describes the comparisons
2,3 of combinations of "attributes" made by utilities
3,4 calculation engine 202. The pairings listed here are for 4
4,2 attributes and are believed to be unique. The remaining
3,1 pairings listed herein are for 5 to 15 attributes and are
1,2 pairings listed herein are for 5 to 15 attributes and are
also believed to be unique.
(2) 5 "attribute" engine
1,2
2,4
5,3
3,1
1,4
3,4
1,5
5,2
(3) 6 "attribute" engine
1,2
2,4
5,3
3,1
6,4
1,6
3,4
2,5
(4) 7 "attribute" engine
1,2
2,4
5,2
6,7
3,1
7,3
1,6
3,4
4,5
(5) 8 "attribute" engine
1,2
5,8
2,4
5,2
6,7
3,1
7,3
1,6
3,4
8,6
4,5
(6) 9 "attribute" engine
1,2
9,7
2,4
7,3
4,5
6,1
5,2
8,6
3,1
8,9
4,3
(7) 10 "attribute" engine
1,2
9,7
2,4
7,3
4,5
10,9
6,1
5,2
4,3
8,6
3,1
8,10
(8) 11 "attribute" engine
1,2
9,7
2,4
7,3
4,5
10,11
6,1
5,2
4,3
11,9
8,6
3,1
8,10
(9) 12 "attribute" engine
1,2
9,7
2,4
10,12
7,3
4,5
12,11
6,1
5,2
11,9
4,3
8,6
3,1
8,10
(10) 13 "attribute" engine
11,13
1,2,
9,7
2,4
10,12
7,3
4,5
12,11
6,1
5,2
11,9
4,3
8,6
3,1
8,10
13,9
(11) 14 "attribute" engine
1,13
1,2
9,7
2,4
10,12
7,3
4,5
12,11
6,1
5,2
14,12
11,9
4,3
10,14
8,6
3,1
8,10
13,9
(11) 15 "attribute" engine
11,13
1,2
8,15
9,7
2,3
10,12
7,3
4,5
12,11
6,1
14,12
11,0
4,3
10,1
8,6
15,14
3,1
8,10
13,9
In all the above, the numbers in the pairs (e.g. "13,9") signify the two attributes in terms of the rank order of their "importance" ratings by the user. For instance, "13,9" signifies the 13.sup.th most important attribute and the 9.sup.th most important attribute. Criteria Matching Heuristic According to another aspect, the present invention includes a criteria matching heuristic for determining alternatives available to a user based on information received from the user. One of the critical issues in applying a decision tool to the selection of an "alternative" is ensuring the "user" is presented with those "alternatives" that are available to him/her in the marketplace. Especially within the realm of health care plan choice, plans are often times available only based on specific, and sometimes complicated criteria (zip code, employment status, etc). In addition, not only does the "user" need to be "matched" to those product "alternatives" available to them, but they must also be presented with the "attributes" and "attribute settings" that apply to them. For example, users" looking for health plan coverage for a family will need to see a different set of premiums than do users looking for self-coverage. These two pre-requisites, match users to the appropriate "alternatives" and "attribute settings," are critical to the goal of providing the "user" with an accurate and useful end product. The present invention, in attempting to solve these requirements, includes a unique criteria matching solution. This solution relies on a data driven mechanism that automates and "genericizes" the process of matching "users" to "alternatives" and "attribute/attribute settings," regardless of the "alternative" category and "attributes" involved. The criteria matching system works as follows: 1) Specific criteria, which may be used to link a "user" to an "alternative" or "attribute," are created. This could include such things as "single" or "family" or "full time," etc. These criteria are populated in a database table. 2) The "attributes" to be used in the project are also populated in a separate database table. 3) A "join" table is created that links which criteria apply to each of the "alternatives." 4) An "alternative" can have multiple criteria associated with it, while a criteria can be associated with multiple "alternatives." 5) The "alternatives" to be used in the project are populated in a separate database table. 6) A "join" table is created that links the criteria that apply to each of the "attributes." 7) An "alternative" can have multiple criteria associated with it, while criteria can be associated with multiple "attributes." Part of the selector tool described above is the "registration." This is the initial step that requires the user to input criteria determining questions, such as "What is your zip code," etc. These registration questions are also data driven--that is, the questions and the responses are drawn from one data table and are written to another data table. The answers to these registration questions are linked, via another join table, to the criteria that have been established for the project. Once the user answers registration questions, the responses trigger a look up of which criteria apply to the user. Using this criteria and the criteria-"alternative" and criteria-"attribute" join tables, the user is automatically matched with the "alternatives" and "attributes" that are applicable to them. One example would be the question, "are you a member of any of the following unions? APWU, Mailhandlers or Postal Workers. If the user answers "yes," and selects APWU, then the application would only match the user's preferences to plans which are available to members of this union and with the benefit structure of that plan which is only available to members of that union. Another example might be a user's answer to the questions, 1) what is your age, and 2) are you eligible for Medicare? Again, if the user answers "Yes," the user will only be shown plans to which that user is eligible and at the rates that are applicable to person's eligible for Medicare. This structure has been developed so that it is "alternative"-category and "attribute" in-specific; it is a highly flexible methodology for meeting the purpose of joining users to "alternatives" and "attributes." Criteria Matching Heuristic Example The following is an abbreviated example of how the criteria matching heuristic works for a health plan selection tool according to an embodiment of the present invention. In this example, the following assumptions are made: There are 2 types of employees, Union 1 and Union 2. For any given plan, premium varies by coverage level as well as the union to which the employee belongs. Employees can choose from 2 types of coverage levels--individual coverage and family coverage. There are 6 possible health plans: 2 available in NY zip codes (Plan A, Plan B) 2 available in NJ (Plan C, Plan D) 1 available nationally (Plan E) 1 available regardless of coverage area, but the employee must belong to Union 1 (Plan F) The following questions can be presented to each employee through a graphical user interface: Question 1: What Union do you belong to? 1. Union 1 2. Union 2 Question 2: What type of coverage level are you looking for? 1. Individual 2. Family Question 3: What is your zip code? The following tables are used by the selector tool to match users with attributes and products. Each of these tables may be stored in a computer-readable medium, such as a memory device.
TABLE 1
Criteria - Defines the criteria needed for the
project to match users with attributes and
products (such as health plans). Note the
ZipCodeExclusive flag may be used to prevent
certain user groups from being matched to
products based on coverage area (zip code) if need.
The ZipCodeExclusive flag is not used in this example.
Criteria_ID Description CriteriaType ZipCodeExclusive
1 All Users Ubiquitous N
2 Union 1 Ubiquitous N
3 Union 2 Ubiquitous N
4 Union 1, Individual Attribute N
5 Union 1, Family Attribute N
6 Union 2, Individual Attribute N
7 Union 2, Family Attribute N
8 Individual Attribute N
9 Family Attribute N
Steps for Performing Criteria Matching Heuristic 1. The user is asked to answer the registration questions. Depending on how the user answers the questions, criteria are associated with each user type. 2. Once users are associated with criteria, joins are done to determine which products are available to the user. This is a 2-step process. In step 1 users are matched with plans that are only associated by criteria (not coverage area (zip code)). The ProductCriteria table (Table 2) is used for this purpose. In step 2 users are matched to products by coverage area (zip code). The ProductCoverage table (Table 6) is used for this purpose. 3. In addition, to joining the user with products, users are also matched to their appropriate attributes; that is, the attributes that are available and pertinent to their decision, based on the registration questions. 4. Once these joins have been done, the user can proceed with using the tool. Sample Answers and Results 1. The user answers Q1 "Union 1," Q2 "individual" and Q3 as a New Jersey zip code. 2. 4 criteria are associated with the user: 1, 2,4 and 8 3. Step 1 of matching the user with the products available to the user is to see if any of the user's criteria meet the ProductCriteria conditions. In this case, the user would be eligible for product_id 6 (Plan F) since the user's criteria of 2 matches a record in the ProductCriteria table (Table 2). 4. Step 2 of matching the user with the products available to the user is to see which plans, if any, are available to the user due to the user's zip code. In this case product_ids 1 (Plan A), 2 (Plan B) and 4 (Plan E) would be available to the user based on the zip code that the user entered. 5. Now the user is matched with attributes. Given the user's criteria, the user would be matched with the ProductAttribute_id/Criteria_id combinations of 1,4 (Premium, Union 1, Individual) 2, 8 (Annual deductible, Individual) and 3, 1 (Chiropractic, all users). With this identified, the tool can ensure the user trades off between the relevant attributes, and that the attribute values used for each plan are appropriate for the user. Other Applications Although the invention has been described above with regard to health plan selection, the present invention is not limited to such an embodiment. The selector tool software according to the present invention can be modified to assist users in almost any complex decision. Examples of additional applications of the selector tool software are discussed in detail below. At the core of the selector tool software are seven steps: 1. Create a list of product or service attributes, which can be objectively collected for all products or services offered. Create levels for these attributes so their values can be compared. 2. Allow users of the software to simply click on those attributes or features, which are important to them. 3. For each attribute selected, show the high and low levels for each, and ask the user to determine how important the difference between the extremes are in their selection process. 4. Using the algorithms discussed above, present the user with unique combinations (paired comparisons) of attributes which they have indicated as very important, and force them to make trade-off decisions between hypothetical plans/products which contain these features. 5. Present the results of their preference exercise by showing them all products available to them in priority order, based on how well each product fits the user's profile 6. Allow the user to access a "Compare" feature, which allows the user to compare any four plans or products; side-by-side, feature-by-feature 7. Allow the user to purchase or enroll in whatever they choose. One additional application of the invention is to assist patients and physicians in making complex medical decisions. For instance, the selector tool can be used to help patients choose between angioplasty or bypass. It can be used to help patients choose between radical mastectomy or lumpectomy or choosing between drugs. Another application for the present invention is a virtual on-line brokerage firm, initially offering health plans to small businesses nationwide. Another application of the invention is for a company which can broker energy company services in de-regulated states. There are already more than 15 states which are deregulated and more are moving in this direction. The selector tool will allow businesses and consumers to click on what is important to them, make trade-offs (for instance between cost, comfort, green-power, other bundled services, etc.) and have the software tell them which plan fits their needs best. Yet another application for the selector tool is for an Internet-based recruiting business. Such a business would be tremendously empowered through use of the selector tool technologies. With monster.com, for instance, searching is done based on simple questionnaires. The results are simply a list, in no priority order, of resumes or positions that fit a simple set of criteria. With selector tool technology, both the employers looking for employees, and consumers looking for positions, would be asked to fill out a detailed profile, which would be databased. Then, when either party is doing a search, they would go through the attribute selection, importance of difference and trade-off exercises; and the system would list all possibilities, in priority order as to how well they fit the preference profile. This would be much more efficient than currently available systems. Yet another application of the invention is selection of assisted living facilities. The parents of millions of "baby boomers" are now at a time in their lives when they are considering full-care retirement centers, rest and nursing homes. There is no good source for them to search for centers which fit their needs economically, geographically and in terms of life-style needs. A web-based retirement home selection application would be a perfect use of the selector tool set. The company managing such a tool will database information on every retirement center and rest-home in America (or the world) and allow the users to click on what is important to them and make trade-offs. The tool would then list all centers which fit the preference profile of the user, in priority order as to how well they fit that person's desires. Yet another application for the present invention is home selection. The MLS system has an existing database and an individual or couple could click on attributes ranging from price, distance from work and schools, style, etc. and quickly match their desires with homes that are available in any region they wish to explore. The selector tool would allow the user to select attributes that are important to the user, go through the importance and trade-off screen, and present th | ||||||