SYSTEM AND METHOD FOR OPTIMIZATION AND SIMULATION ENVIRONMENT

Abstract: A system and method for optimized decision-making for e-commerce. A system architecture for off-line, proactive decisions also supports performing simulations prior to deploying off-line or on-line decisions. There are four sections to the architecture: experiment design, which provides tools for creating and deploying experiments to test various combinations of decision values in preparation for modeling results; a model-building section provides tools for creating and deploying mathematical models whose purpose is to encapsulate data and results in a form that may be used to make future decisions; a decision-making section which provides tools for creating and deploying optimized decision answers; and a tracking section which provides tools for recording the results of experiments deployed in the experiment design section and the decisions deployed in the decision-making section. The system architecture for on-line, reactive decisions is a modification of the off-line system architecture. On-line applications are usually built to serve other purposes besides decision-making. Therefore, the decision-making process needs to be embedded in the applications. The transforms and rules may be built with the off-line system architecture then deployed to the on-line application. The combination of the off-line and on-line architectures may allow for building closed-loop systems. The off-line system architecture may be used to build a system for executing experiments and decisions. The on-line system architecture may be used to embed the experiment and decision execution in an on-line web application. The combination becomes closed-loop when the results may be captured and used to drive future decisions.

Description: TITLE: SYSTEM AND METHOD FOR OPTIMIZATION AND SIMULATION ENVIRONMENT Background of the Invention 1. Field of the Invention The present invention relates to computer software, and more particularly to optimized decision-making software for an e-commerce enterprise. 2. Description of the Related Art Numerous approaches have been applied to the issue of business decision-making, including decision support, data mining, and optimization Decision support typically utilizes technologies such as On-Line Analytical Processing (OLAP) and Relational On-Line Analytical Processing (ROLAP) to more systemically examine what has happened in the past. With these approaches, a querying process may take place whereby a decision-maker may, for example, analyze all available data associated with transactions and customers, or a marketing manager may query a database to ascertain how well an offer performed with a customer segment over a peπod of time. These tools can be thought of as reporting applications. The decision-maker can create custom reports and can be alerted if a query result falls out of a certain range. Performance can be measured and managed using these tools. Although it may be useful to look to the past before making decisions about the future, these tools are often inaαequate to help the decision-maker look into the future to the see the consequences of the numerous actions at his or her disposal. Another approach, data mining, may enable the decision-maker to look forward. Utilizing technologies such as neural networks and decision trees, data mining tools may be used to analyze large amounts of data and uncover patterns that lead to predictions of what future behavior a customer is likely to exhibit. The best tools in this category may be capable of identifying whom marketers should target based on predicted responses. However, the proactive prescπption of what to do to meet busmess goals is still beyond then capabihnes. It is still up to the manager to determine what action to take. These aforementioned approaches may help decision-makers gain a better understanding of their customers. but it is still the manager who must use his or her expenence and intuition to make the final decision of what to do. If managers are not careful, these tools may only push them into makmg incorrect and costly decisions These tools may not use rigorous scientific approaches to determine at what point something should be done and. more importantly, what should not be done Organizations relying solely on these types of inadequate tools may simply become more efficient at executing status quo decision-making strategies that have histoπcally been followed. Another approach, optimization, may address these problems at least in part. Unlike data mining, which starts with inputs and predicts an output, optimization may start with the output and seek the best acnons to take to change the output to the company's advantage. Data mining may tend to predict the future, but with optimization, the decision-maker may take actions to change the future to the company ' s benefit. In many business environments, the goal of optimization is to enable busmess decision-makers to determine which combinations and levels of treatments under their control should be applied Typically, optimization solves a defined objecπve function, sub j ect to one or more constraints, to select optimal values for one or more decision variables. Decision vaπables are the parameters over which the decision-maker has control For instance, in many business applications, net profit is to be maximized or. if the decisions bemg modeled do not impact revenues, total cost minimized However, optimization mav be hampered by forecasting that ignores long-term considerations In other words, current approaches may not adequately reflect behaviors that do not completely, directly, and empincally manifest themselves, for example, m a 6 or 12-month peπod Furthermore, current tools for decision optimization only provide solutions to individual parts of the enterpπse-wide problems typical of e-commerce operations The integration of such partial solutions from disparate tool sets is itself an extremely difficult problem to solve For at least the foregoing reasons, there is a need for an improved system and method for optimized decision-making for e-commerce SUMMARY OF THE INVENTION The present invention provides vanous embodiments of a method and system for software-based optimizanon and srmulatton for making decisions based on objectives, constraints and πsk factors One embodiment of a system architecture for off-lme, proactive decisions supports the ability to make off-line decisions, and also supports performing simulations pπor to deploymg the off-lme and on-line decisions There are four sections to the architecture design of expeπments, trackmg, model building and decision making The design of expeπments section mcludes an Experiment Database and four modules connected to it Import, Export, Design Experiment and Expeπment Engine The trackmg section mcludes a Trackmg Database which may be connected to an Import module The model-building section mcludes Model Database and two modules connected to it Import and Build Components The decision-making section mcludes Decision Database and six modules connected to it Import, Export, Assemble/Setup Components, Decision Views, Decision Engme and Decision Reports The design of expeπments section provides tools for creating and deploymg expeπments The purpose of the experiments is to test various combinations of decision values in preparation for modelmg the results For example, in a credit card re-pπcmg problem where the decision values concern APR and credit lme values for an account, the expeπment will test combinations of APR and credit lme values with then customers or prospective customers The results may then be used m the tools provided by the tracking and model-building sections of the architecture The model-building section provides tools for creating and deploying mathematical models built from histoπcal data and results from experiments and previous decisions The purpose of the mathematical models is to encapsulate the data and results m a form that may be used to make future decisions An example is a mathematical model calculating lifetime customer value of a credit card decision Such models may be used in the tools provided by the decision-making section of the system Results from the models may also be tracked via the trackmg section The decision-making section provides tools for creating and deploymg optimized decision answers For example, a pharmaceutical decision might mclude decision values concerning number of drug samples and client visits The optimal decision will preferably comprehend finding the right mix of samples and visits for the entire portfolio of clients given budget constraints and risks related to uncertainty of travel costs Results from the decisions may be used m the trackmg section The trackmg section provides tools for recordmg the results of the expeπments deployed m the design of experiment section and the decisions deployed m the decision-making section The results may then be used m all three other sections to evaluate the performance of the expeπments, models and decisions The Import module may be used to load data mto vaπous system databases The Export module may be used to unload data from the vaπous system databases The Expeπment Database contams the data used to formulate the experiment It may be organized by projects, which contam project-related experiments The Expeπment Database also contains the raw data brought in via the Import module, along with transformed data generated via transformaUons m the Import module The Expeπment Database also contams the meta-data associated with the raw data, transformed data, project data, expeπments, transformations and rules The Expeπment Database may be realized as either a relational database, flat ASCII files, object database, tn-memory database or some combination The Design Expeπment module may be used to create, delete, edit, view and track the expeπments This module contams visualization tools that work with the Expeπment Database and Expeπment Engme to create, delete, edit and view the expeπments The Design Expeπment module also mcludes functionality to manage the projects that contam the expeπments The Design Expeπment module mcludes further functionality to create segmentation and sampling rules to guide selection of expeπments The Expeπment Engme module may be used to apply segmentation and samplmg rules agamst the transformed data m the Expeπment Database The Build Components module may be used to build component mathematical models that may be used in the decision making section The components may be of vanous types neural network, logistic regression, lmear regression, genetic algoπthm, table lookup, etc The Trackmg Database contams the expeπment, model and decision data that will be tracked Deploymg a project's expeπment via the Export module saves experiment's data to the Trackmg Database Results from the deployment of the mathematical models are also stored m the Trackmg Database, as are results from the deployment of decisions The Assemble/Setup Components module may be used to perform setup steps required pπor to performing the optimization and simulation Projects may be created m the Assemble/Setup Components module to encapsulate the configuration work for one or more configuration vaπations A configuration vananon may be encapsulated m an abstraction called a question Questions reference a project's objectives, nsk vaπables, and segments, as desired by the user Questions may be of two base types, optimization and prediction An optimization question solves for a set of input vaπables in an objective A. prediction question calculates an objective There may be deπvations of these two base types For example, marginal optimization mcludes an additional objective called the baseline to compare agamst All questions have basic functionality that mcludes creating, copying and deletmg questions The functionality also mcludes selectmg from the project an objective, the nsk vaπables and the segmentation element(s) to use for solving the question Decision vanables are the parameters over which the decision-maker has control For instance, in many busmess applications, net profit is to be maximized or, if the decisions bemg modeled do not impact revenues, total cost minimized Two types of decision vaπables exist, discrete and contmuous Constraints may be expressed usmg terms that consist of data constants, data elements m the Decision Database or expressions contammg data elements and data constants Constraints may be global, regional or local For example, a global constramt could be total net operating mcome over the entire portfolio greater than $15 million, and a regional constramt could be total mail costs m the southwest less than $ 1 million Local constraints are constraints where the terms use facts from the decision-level records For example, a local constramt could be number of mailings greater than 0 The Decision Engme module may be used to perform the calculations for a question, such as the objective and constraints for a decision level record, as well as optimizing a decision in light of the objective and constraints The Decision Views module may be used to perform minor setup changes to a question to start the calcularcns and to view the results of the calculations The Decision Reports module may be used to examine the results of a project's question These reports may be in many forms, including web pages The system architecture for on-lme, reactive decisions is a modification of the off-lme system architecture On-lme applications are usually built to serve other purposes than just to make a decision Therefore, the process of makmg a decision needs to be embedded in those applications The transforms and rules may be built with the off- lme system architecture Once built and tested via simulations, they may be deployed to the on-lme application The combination of the off-lme and on-lme architectures may allow for building closed-loop systems As an example, an architecture for a closed-loop system that makes marketing decisions for an Internet busmess would essentially be the same for other closed-loop systems, where the external systems and on-lme applications may be different The Internet busmess may be makmg decisions and performmg experiments on the content of promotions and incentives delivered via email and the web The off-lme system architecture may be used to build a system for executing expeπments and decisions for the email promotions and mcentives The on-lme system architecture may be used to embed the experiment and decision execution m the on-line web application The combination becomes closed-loop when the results may be captured and used to adapt future decisions For the example software architecture, the Export module may be customized with a set of transforms and a Data Interface sub-module that converts the expeπment and decision data to an email delivery system The combination may create email messages that contam the promotion or incentive tailored to the customer The Import module may be customized with a set of transforms and Data Interface sub-modules that convert the data from 3rd party customer data warehouses and an mtemal Data Collection database The Data Collection database may be used to store the results from the email and web responses Another version of the Import module may be customized with a set of transforms and a Data Interface sub-module that converts the email responses from an email delivery system for the Data Collection database The off-lme modules may also be used to run simulations for the on-lme modules Once the simulations prove satisfactory, the transforms, rules and components used in the simulations may be deployed to the on-lme modules Brief Description of the Drawings Figure 1 is a diagram of an Off-lme System Architecture of the System, according to one embodiment Figure 2 is a block diagram of an Import Module, accordmg to one embodiment, Figure 3 is a block diagram of an Export Module, accordmg to one embodiment, Figure 4 is a block diagram of a Design Experiment Module, accordmg to one embodiment, Figure 5 is a block diagram of an Expeπment Engme Module, accoidmg to one embodiment, Figure 6 is a block diagram of a Build Components Module, accordmg to one embodiment, Figure 7 is a block diagram of an Assemble/Setup Components Module, accordmg to one embodiment, Figure 8 is a block diagram of a Manage Questions Sub-Module, accordmg to one embodiment, Figure 9 is a block diagram of a Manage Optimization Sub-Module, accordmg to one embodiment, Figure 10 is a block diagram of a Manage Margmal Optimization Sub-Module, accordmg to one embodiment, Figure 1 1 is a block diagram of a Decision Engme Module, according to one embodiment, Figure 12 is a block diagram of a Decision Views Module, accordmg to one embodiment, Figure 13 is a block diagram of a Decision Reports Module, accordmg to one embodiment, Figure 14 is a block diagram of an On-lme Expeπment Architecture, accordmg to one embodiment, Figure 15 is a block diagram of an On-lme Decision Architecture, according to one embodiment, Figure 16 is a block diagram of an Internet-based, Closed-loop System Architecture of the System, accordmg to one embodiment, Figure 17 is a network diagram of an illustrative distributed computing environment which is suitable for implementing vaπous embodiments, Figure 18 is illustrates a typical computer system which is suitable for implementing various embodiments of the present mvention, While the mvention is susceptible to vaπous modifications and alternative forms, specific embodiments thereof are shown by way of example m the drawmgs and will herem be descπbed in detail It should be understood, however, that the drawmgs and detailed descπption thereto are not intended to limit the mvention to the particular form disclosed, but on the contrary, the mtention is to cover all modifications, equivalents, and alternatives falling withm the spiπt and scope of the present mvention as defined by the appended claims Detailed Description of several Embodiments Figure 17: A Distributed Computing Environment Figure 17 illustrates a distributed or enterpπse computing environment accordmg to one embodiment A distnbuted computer system or enterprise 1700 includes a plurality of computer systems which may be interconnected through one or more networks Although one particular embodiment is shown in Figure 17, the distnbuted computer system 1700 may include a vaπety of heterogeneous computer systems and networks which may be interconnected m a vaπety of ways and which run a vaπety of software applications and/or operating system software One or more local area networks (LANs) 1704 may be mcluded in the enterpnse 1700 A LAN 1704 is a network that spans a relatively small area Typically, a LAN 1704 is confined to a smgle building or group of buildmgs Each node (I e , mdividual computer system or device) on a LAN 1704 preferably has its own CPU with which it executes programs, and each node is also able to access data and devices anywhere on the LAN 1704 The LAN 1704 thus allows many users to share devices (e g , printers) as well as data stored on file servers The LAN 1704 may be characterized by any of a \ aπety of types of topology (I e , the geomemc arrangement of devices on the network), of protocols (t e , the rules and encodmg specifications for sendmg data, and whether the network uses a peer-to-peer or client/server architecture), and of media (e g , twisted-pair wire, coaxial cables, fiber optic cables, radio waves) As illustrated m Figure 17, the distnbuted computer system 1700 may include one LAN 1704. However, m alternate configurations the distributed computer system 1700 may include a plurality of LANs 1704 which may be coupled to one another through a wide area network (WAN) 1702. A WAN 1702 is a network that spans a relatively large geographical area. Each LAN 1704 includes a plurality of interconnected computer systems and optionally one or more other devices: for example, one or more workstations 1710a, one or more personal computers 1712a, one or more laptop or notebook computer systems 1714, one or more server computer systems 1716, and one or more network printers 1718. As illustrated in Figure 17, an example LAN 1704 may include one of each of computer systems 1710a, 1712a, 1714, and 1716, and one printer 1718. The LAN 1704 may be coupled to other computer systems and/or other devices and/or other LANs 1704 through a WAN 1702. One or more mainframe computer systems 1720 may be coupled to the distnbuted computer system 1700. As shown m Figure 17, the mamframe 1720 may be coupled to the distnbuted computer system 1700 through the WAN 1702, but alternatively one or more mainframes 1720 may be coupled to the distnbuted computer system 1700 through one or more LANs 1704. As shown, the mainframe 1720 may be coupled to a storage device or file server 1724 and mainframe terminals 1722a, 1722b, and 1722c. The mainframe terminals 1722a, 1722b, and 1722c may access data stored in the storage device or file server 1724 coupled to or included in the mamframe computer system 1720. The distnbuted computer system 1700 may also mclude one or more computer systems which may be connected to the distnbuted computer system 1700 through the WAN 1702: as illustrated, a workstation 1710b and a personal computer 1712b. In other words, the enterpπse 1700 may optionally mclude one or more computer systems which are not coupled to the distnbuted computer system 1700 through a LAN 1704. For example, the distnbuted computer system 1700 may mclude computer systems which may be geographically remote and connected to the distnbuted computer system 1700 through the Internet. Figure 18: A Typical Computer System Figure 18 illustrates a typical computer system 1850 which is suitable for implementing vaπous embodiments. Each computer system 1850 typically mcludes components such as a CPU 1852 with an associated memory medium such as floppy disks 1860 The memory medium may store program instructions for computer programs, wherein the program instructions are executable by the CPU 1852. The computer system 1850 may further include a display device such as a monitor 1854, an alphanumeric mput device such as a keyboard 1856, and a directional mput device such as a mouse 1858. The computer system 1850 is operable to execute the computer programs to implement vanous embodiments of the present mvention as descnbed herein. The computer system 1850 preferably mcludes a memory medium on which computer programs accordmg to vaπous embodiments may be stored. The term "memory medium" is intended to include an installation medium, e.g., a CD-ROM, or floppy disks 1860, a computer system memory such as DRAM, SRAM, EDO RAM, Rambus RAM, etc., or a non-volatile memory such as a magnetic media, e.g., a hard dπve, or optical storage. The memory medium may mclude other types of memory as well, or combinations thereof. In addition, the memory medium may be located m a first computer m which the programs may be executed, or may be located m a second different computer which connects to the first computer over a network. In the latter instance, the second computer provides the program instructions to the first computer for execution Also, the computer system 1850 may take vanous forms, mcludmg a personal computer system, mamframe computer system, workstation, network appliance, Internet appliance, personal digital assistant (PDA), television system or other device. In general, the term "computer system" may be broadly defined to encompass any device having a processor which executes instructions from a memory medium The memory medium preferably stores a software program or programs for event-tnggered transaction processmg as descnbed here The software program(s) may be implemented m any of vanous ways, mcludmg procedure-based techniques, component-based techniques, and/or object-oriented techniques, among others For example, the software program may be implemented using ActiveX controls, C++ objects, JavaBeans, Microsoft Foundation Classes (MFC), or other technologies or methodologies, as desired A CPU, such as the host CPU 1852, executmg code and data from the memory medium includes a means for creating and executing the software program or programs accordmg to the methods and/or block diagrams descnbed below The following paragraphs and diagrams descnbe vaπous embodiments of an mvention for a software- based optimization and simulation system that may make decisions based on objectives, constraints and nsk factors An objective is the target goal of a decision A constramt is a qualifier for the objective A nsk factor is an expression of uncertainty regarding elements of the objective The decisions may be made m an off-lme, proactive manner wherem many decisions may be made all together (batch method), or in an on-lme, reactive manner where one decision is made at a time The invention solves the mtegration problems over the entire hfecycle of designmg the decisions, makmg the decisions and trackmg the decisions An example problem suitable for vaπous embodiments of the present mvention is to determine an optimal annual percentage rate (APR) and credit lme for each customer m a portfolio, where that APR and credit lme yields a maximum lifetime customer value with a minimum net operatmg mcome (for the following year) of $15 million, and the cost of capital has the possibility of varying by ±10% over the next 5 years The objective m this decision is to maximize the lifetime customer value There is one constramt, which is to have at least $15 million m net operating mcome for the following year And there is one risk factor, which is the cost of capital varying by ±10% over the next 5 years One approach is to make the decision m an off-line manner with a system that may make customer decisions in a batch manner This method might typically be used to proactively change the APR and credit lme for all customers m the portfolio Another approach is to make the decisions in an on-lme manner with a system that will make the decision for one customer at a time This manner would typically be used to react to some event, such as the customer calling to request a change The mvention disclosed here comprehends both approaches, off- lme and on-lme There are many areas of decision-making in which the present mvention may be used, such as marketing decisions, manufacturing decisions, production decisions, and advertising decisions, or any other type of decisions involving objectives, constraints, and/or nsk assessment There are a number of available tools that may solve various parts of the problems bemg addressed by the optimization and simulation system descnbed herem Examples are Trajecta's dbProphet, modules m Microsoft's Excel, modules m SAS Institute's Base SAS, Palisade's @Rιsk and RER's tsMetnx However, these tools do not solve the mtegration problems inherent in complex constrained optimization problems Furthermore, there may be additional algorithms required which may not be provided by these tools To effectively solve these types of problems a holistic system may be required that comprehends the totality of designmg experiments, modeling from the experiments and historical data, making the optimized decisions, trackmg the results from the experiments/decisions, and embedding the experiments/decisions in on-lme applications Such a system is described below Figure 1: System Architecture for an Off-Line Decision System One embodiment of a system architecture for off-lme, proactive decisions is shown m Figure 1 The architecture not only supports the ability to make off-lme decisions, but also supports performmg simulations pnor to deploymg the off-lme and on-line decisions There are four sections to the architecture- design of expeπments, trackmg, model building and decision makmg. The sections are roughly identified using the modules surrounding four data stores The design of experiments section mcludes Expeπment Database 360 and four modules connected to it: Import 100, Export 150, Design Experiment 300 and Expeπment Engme 340. The trackmg section mcludes a Trackmg Database 400 which may be connected to an Import module 100. The model-building section mcludes Model Database 530 and two modules connected to it: Import 100 and Build Components 500. The decision- makmg section mcludes Decision Database 680 and six modules connected to if Import 100, Export 150, Assemble/Setup Components 600, Decision Views 660, Decision Engme 640 and Decision Reports 670. The design of expeπments section provides tools for creating and deploying expeπments. The purpose of the experiments is to test various combmations of decision values in preparation for modelmg the results. For example, m a credit card re-pricing problem where the decision values concern APR and credit lme values for an account, the expeπment will test combmations of APR and credit line values with their customers or prospective customers. The results may then be used m the tools provided by the trackmg and model-building sections of the architecture. The model-building section provides tools for creating and deploymg mathematical models built from histoncal data and results from expeπments and previous decisions. The purpose of the mathematical models is to encapsulate the data and results in a form that may be used to make future decisions An example is a mathematical model calculating lifetime customer value of a credit card decision. Such models may be used m the tools provided by the decision-making section of the system. Results from the models may also be tracked via the trackmg section. The decision-making section provides tools for creating and deploymg optimized decision answers. For example, a pharmaceutical decision might mclude decision values concerning number of drug samples and client visits. The optimal decision will preferably comprehend findmg the nght mix of samples and visits for the entire portfolio of clients given budget constraints and risks related to uncertainty of travel costs Results from the decisions may be used m the trackmg section. The trackmg section provides tools for recordmg the results of the experiments deployed m the design of expeπment section and the decisions deployed in the decision-making section. The results may then be used in all three other sections to evaluate the performance of the expeπments, models and decisions. Figure 2: Import Module The Import module 100 may be used to load data mto the vanous system databases. Figure 2 shows the sub-modules of the Import module 100 The Data Transformation Engme sub-module 110 may convert the data received from an external database or system to a usable form for vaπous tools usmg the system databases. Visualization Tool sub-modules 140 work with the Data Transformation Engme sub-module 110 to view the data and statistics of the data, and to build the transformations 120 with those views. Example Visualization Tools are XY plots, row number plots, histogram plots, coπelation plots, probability plots. PCA plots, etc The transformations 120 may be built usmg the views and/or usmg an editor to explicitly express the transformations in terms of the data The Import module 100 may be extensible to add and remove Visualization Tool sub-modules 140. The transformations built may be saved m a re-usable form 120. One potential re-use may be in an on-lme application (as shown m Figures 14 and 15), where the transformations 120 may be used to automatically transform the data from the on-lme application The application may use the Data Transformation Engme sub-module 110 to transform the application data The Import module 100 may also contam Data Interface sub-modules 130 for interfacing to the vanous system databases 360, 400, 530, 680 and to the vaπous external databases and systems 200. The Import module 100 may be extensible to add and remove Data Interface sub-modules 130. Figure 3: Export Module The Export module 150 may be used to unload data from the vanous system databases Figure 3 shows the sub-modules of the Export module 150 The Data Transformation Engme sub-module 110 converts the data contamed m the system databases to a usable form for the vanous external systems and databases. The same Data Transformation Engme sub-module 110 may be used for the Export and Import modules. The Export module 150 contams Visualization Tool sub-modules 140 that work with the Data Transformation Engme sub-module 110 to build the transformations. The Export module 150 may be extensible to add and remove Visualization Tool sub- modules The Visualization Tool sub-modules 140 used m the Export module 150 may or may not be the same as those used m the Import module 100 However, all Visualization Tool sub-modules 140 support the same interface to be used m either The transformations built may be saved m a re-usable form 120. One potential re-use may be m an on-lme application (as shown m Figures 14 and 15), where the transformations 120 may be used to automatically transform the data to the on-lme application The application uses the Data Transformation Engme sub-module 110 to transform the data m the Expeπment Database 360 The Export module 150 also contams Data Interface sub-modules 130 for interfacing to the vanous system databases 360, 400, 530, 680 and the vanous external databases and systems 200 The Export module 150 may be extensible to add and remove Data Interface sub-modules 130 The Import 100 and Export 150 modules may share some of the same Data Interface sub- modules 130. The Experiment Database 360 shown m Figure 1 contams the data used to formulate the expeπment. It may be organized by projects. A project may be used to associate a domain-specific term to the data used in designmg an expeπment. For example, m a credit card expeπment, a marketing campaign may be a term used to organize the work bemg done for an experiment. A project could be used to associate the experiment work bemg done for a marketing campaign A project may consist of multiple experiments, each containing some different configuration of the expeπment to be deployed for a project The Expeπment Database 360 also contams the raw data brought m via the Import module 100, along with the transformed data generated via the transformations m the Import module 100 The Experiment Database 360 also contams the meta-data associated with the raw data, the transformed data, the project data, the experiments, the transformations and the rales. The Expeπment Database 360 may be realized as either a relational database, flat ASCII files, object database, in-memory database or some combination Figure 4: Design Experiment Module The Design Expeπment module 300 may be used to create, delete, edit, view and track the experiments Figure 4 shows the sub-modules of the Design Experiment module 300 This module contams visualization tools that work with the Expeπment Database 360 and Expeπment Engme 340 to create, delete, edit and view the expeπments The Create Tool sub-module 310 creates experiments for a project The Delete Tool sub-module 315 deletes expeπments of a project The Edit Tool sub-modules 305 manage the segmentation and samplmg rules 330 used by the Expeπment Engme 340 The View Tool sub-modules 320 mclude vanous visualizations of the expeπments, mcludmg reports and charts showmg the data after the segmentation and samplmg rules may be applied The Track Tool sub-modules 325 include reports and charts compaπng the results of executing the experiment to what was designed The Design Expenment module 300 may be extensible to add and remove Edit Tool 305, View Tool 320 and Track Tool 325 sub-modules The Design Experiment module 300 also includes functionality to manage the projects that contam the experiments. Figure 5: Experiment Engine Module The Experiment Engme module 340 may be used to apply the segmentation and samplmg rules 330 agamst the transformed data m the Expeπment Database 360 Figure 5 shows the sub-modules of the Expeπment Engme module 340 The Segment Engme sub-module 350 encapsulates a segmentation algonthm and performs that algorithm accordmg to the segmentation rules created m the Design Experiment module 300. The segmentation rules may be specific to the segmentation algonthm. Segmentation algonthms may mclude simple cut rales, complicated clustermg algorithms, or other segmentation schemes. The Sample Engme sub-module 345 encapsulates a samplmg algorithm and performs that algonthm accordmg to the samplmg rales created m the Design Experiment module 300 The samplmg rales may be specific to the samplmg algonthm. Samplmg algonthms may consist of simple landom to complicated score-based algorithms. The Experiment Engme module 340 may be extensible to add and remove Segment Engme 350 and Sample Engme 345 sub-modules. The Trackmg Database 400 contams the expeπment, model and decision data that will be tracked. It may be organized by the projects that were created m the design of experiments, model-building and decision-making sections. The vaπous projects may be linked to associate them with one another. Thus, one may be able to know if a model-building project relates to a decision-making project and a design-of-expeπment project. Furthermore, a given project might be associated with another project. For example, a given design-of-expeπment project might be deπved from another design-of-expenment project. Data may be put mto the Tracking Database 400 when a project is deployed. Deploymg a project's expeπment via the Export module 150 causes the experiment's data to be saved to the Trackmg Database 400. Each section has a sub-module that includes tools that use the Trackmg Database 400. Figure 6: Build Components Module The Build Components module 500 may be used to build component mathematical models 510 The components may be used m the decision makmg section. The components may be of various types; neural network, logistic regression, lmear regression, genetic algorithm, table lookup, etc. Figure 6 shows the sub-modules of the Build Component module 500. Projects may be created in the Build Components module 500 to encapsulate the work for one or more components. Each type of component has its own set of Edit Tools 505, Analysis Tools 515 and Track Tools 520. The Edit Tools 505 provide mechanisms for creatmg and edit g component mstances of the corresponding type. For example, an Edit Tool for a neural network component would identify data elements m the Model Database 530 as mputs and outputs for the neural network and then tram the neural network on the corresponding data. The Analysis Tools 515 provide mechanisms for analyzing and viewing the component For example, an Analysis Tool for a neural network might identify the sensitivities of the inputs to outputs. Another Analysis Tool for a neural network might show the internal layers with then corresponding weights. The Track Tools 520 provide mechanisms for compaπng results from deploymg the component mathematical models. The results are stored in the Trackmg Database For example, a Track Tool for a neural network would show predicted versus actual values for the outputs The Build Components module 500 may be extensible to add and remove Edit Tool 505, Analysis Tool 515 and Track Tool 520 sub-modules. Figure 7: Assemble/Setup Components Module The Assemble/Setup Components module 600 may be used to perform setup steps required prior to performing the optimization and simulation. Figure 7 shows the sub-modules of the Assemble/Setup Components module 600. Projects may be created in the Assemble/Setup Components module 600 to encapsulate the configuration work for one or more configuration variations. A configuration variation may be encapsulated in an abstraction called a question. Questions reference objectives managed by the Assemble Objective 610 sub-module, risk variables managed by the Edit Risk 615 sub-module and segments managed by the Edit Segments 620 sub- module. The Assemble Objective sub-module 610 may be used to assemble component mathematical models 510 into objectives for a project. Assembling comprises binding component outputs to component inputs. Assembling also comprises binding component inputs and outputs to data elements in the Decision Database 680. The project may contain many objectives. Questions reference the project's objectives as desired by the user. The Edit Risk sub-module 615 may be used to create and edit the set of risk variables for a project. Risk variables may be selected from the set of component inputs, component outputs and Decision Database 680 data elements. Risk variables may have properties of high and low value. The high and low values may be expressed in relation to the actual value, such as a percentage difference, absolute value, etc. Questions may reference the project's risk variables as desired by the user. The Edit Segments sub-module 620 may be used to define the segmentation to be used for reporting and question solving. The segmentation may be defined according to dimensions, attributes, elements and facts, which are concepts defined in Multi-Dimensional Databases. In addition to these concepts the Data Transformation Engine sub-module 110 may be used in the Edit Segments sub-module 620 to define transformations 120 that build facts for the segmentation. These facts may form the decision-level records to be used when solving the questions. Figure 8: Manage Questions Sub-Module Questions may be of two base types, optimization and prediction. An optimization question solves for a set of input variables in an objective. A prediction question calculates an objective. There may be derivations of these two base types. For example, marginal optimization includes an additional objective called the baseline to compare against. Figure 8 shows a hierarchy of sub-modules that manage questions. All questions have basic functionality provided by the Manage Questions sub-module 605. This functionality includes creating, copying and deleting questions. The functionality also includes selecting from the project an objective, the risk variables and the segmentation element(s) to use for solving the question. The Manage Prediction sub-module 606 adds the functionality of selecting additional objectives. Figure 9: Manage Optimization Sub-Module The Manage Optimization sub-module 607 adds to the Manage Questions functionality, managing decision variables, constraints and reason codes. Figure 9 shows the sub-modules of the Manage Optimization sub-module 607. Decision variables are the parameters over which the decision-maker has control. For instance, in many business applications, net profit is to be maximized or, if the decisions being modeled do not impact revenues, total cost minimized. The Edit Decision Variable sub-module 625 may be used to create and edit the set of decision variables for a project. Decision variables have properties related to their values, and the properties may be specific to the type of variable. Two types of decision variables exist, discrete and continuous. Discrete variables have properties describing the possible values. These values may be expressed as a minimum value, maximum value and increment; or they may be expressed as a set of discrete values. Continuous variables have properties of minimum and maximum value. The Manage Optimization sub-module 607 may manage the subset of project's decision vaπables to solve for m a question The Manage Optimization sub-module 607 may also manage the allowable decision variable value combmations for the question The Edit Constramts sub-module 630 may be used to create and edit the optimization constramts for a project Constramts may be expressed usmg terms that consist of data constants, data elements in the Decision Database 680 or expressions containing data elements and data constants The constramt expression may comprise three parts a left-hand term, a relational operator and a right-hand term Relational operators are the typical numeric relational operators, equal, less than, greater than, etc Constramts may be global, regional or local Global and regional constramts are constramts where the terms use rolled-up facts from the segmentation For example, a global constramt could be total net operating mcome over the entire portfolio greater than $15 million: and a regional constramt could be total mail costs m the southwest less than $1 million Local constramts are constramts where the terms use facts from the decision-level records For example, a local constramt could be number of mailings greater than 0 The Manage Questions sub-module 605 may manage the subset of the project's constramts to use m solvmg the question The Edit Reasons sub-module 635 may be used to create and edit the rales for generatmg reason codes associated with the solved decision variables The rales are expressions that, if true, produce a reason code The expressions may be built usmg terms that consist of data constants, data elements m the Decision Database 680 or results of calculations on those data elements The terms may be put together as relational and logical expressions, e g , BehaviorScore < 600 and CuπentCL > NewCL Figure 10: Manage Marginal Optimization Sub-Module The Manage Marginal Optimization sub-module 608 adds to the Manage Optimization functionality, managing a baselme objective Figure 10 shows the sub-modules of the Manage Margmal Optimization sub- module 608 The Manage Baselme sub-module 636 identifies the objective from the project's list of objectives and initiates the calculation of the baselme objective for the decision records A baselme objective may be of the same structure as the optimization objective, except the behavioral components of the objective represent the normal busmess behavior For example, if the optimization objective is lifetime customer value, the baselme objective is also lifetime customer value And, the difference between the two is the set of components assembled mto each Figure 11: Decision Engine Module The Decision Engme module 640 may be used to perform the calculations for a question Figure 11 shows the sub-modules of the Decision Engme module 640 The Calculation Engme sub-module 645 may be used to calculate the objective, constramts and any miscellaneous equations for a decision level record The objective, constramts and miscellaneous equations may be created in the Assemble/Setup Components module 600 by assemblmg components A decision-level record may either be formed via the segmentation transformations m the Edit Segments sub-module 635 or assume the account-level records brought mto the Decision Database 680. An account-level record represents the data elements for a customer or some entity that is the focus of the decision The Decision Engme module 640 may be configured with multiple Calculation Engme sub-modules, dependmg on the configuration of the Question Engme sub-module 650 The Question Engme sub-module 650 performs the algonthm specific to a question If the question is configured to perform an optimization, the Question Engme 650 may be that optimization algonthm If the question is configured to perform a prediction, the Question Engme 650 may be that prediction algonthm For example, if the question is configured to periorm an optimization of discrete decision vaπables with global constramts and nsk variables, a Question Engme 650 with that ability may be used The Decision Engme module 640 may be extensible to add and remove Question Engme 650 sub-modules It is also conceived that the Decision Engme module 640 could be built to ran calculations m parallel or in a distnbuted manner For example, the Question Engme sub-module 650 could invoke multiple Calculation Engine 645 sub- modules in parallel or across a network (in a distnbuted manner) Figure 12: Decision Views Module The Decision Views module 660 may be used to perform minor setup changes to a question, to start the calculations and to view the results of the calculations Figure 12 shows the sub-modules of the Decision Views module 660 Mmor setup changes mclude selectmg the segment over which the calculations are run and selecting the risk variables There may also be access to the Setup functionality in the Assemble/Setup Components module 600. which allows more major changes Once the setup changes have been made, a mechanism may be provided to start the calculations, which will be run by the Decision Engme module 640 After the calculations have been run, vanous tables and charts may be used to evaluate the decisions The tables and charts may be encapsulated via the View sub-module 665 The tables and charts have direct access to the results of the Decision Engme 640, mcludmg details that might not be persisted in the Decision Database 680 The View sub-modules allow one to compare the scenano simulations generated from the nsk vaπables and look at the robustness of the decisions across those scenanos There may also be access to the reports m the Decision Reports module 670 The Decision Views module 660 may be extensible to add and remove View sub-modules 665 Figure 13: Decision Reports Module The Decision Reports module 670 may be used to examine the results of a project's question from the Decision Database 680 Figure 13 shows the sub-modules of the Decision Reports module 670 The results may be shown as reports via Report sub-modules 675 These reports may be m many forms, mcludmg web pages. All reports show the results within the segmentation The results shown mclude the decision mix, the constramt adherence, the objective values, intermediate calculations and question configuration information. There are also compaπson reports that compare any of the results between projects and between questions And, there may be trackmg reports showmg the actual results versus the predicted results The trackmg reports work off the Trackmg Database 400, which stores the actual results The Decision Reports module 670 may be extensible to add and remove Report sub-modules 675 It is also conceived that these modules may be packaged m many forms For example, they would be packaged as a desktop software product, as a client-server software product that supports multiple users, or as a web software product. Figures 14 and 15: On-Line Experiment and Decision Architecture The system architecture for on-lme, reactive decisions is a modification of the off-lme system architecture and is shown m Figure 14 and Figure 15 Figure 14 shows the system architecture for embeddmg the experiment process Figure 15 shows the system architecture for embeddmg the decision process On-lme applications are usually built to serve other purposes than just to make a decision Therefore, the process of makmg a decision needs to be embedded m those applications To embed the experiment and decision, the application programming mterfaces (APIs) for the Data Transform Engme sub-module 110, the Expeπment Engme module 340 and the Decision Engme module 640 may be provided to the programmer of the on-line application To embed the expeπment, the on-line application may be modified to use the APIs for the Data Transform Engme sub-module 110 and the Expeπment Engme module 340 The transforms 120 and rales 330 may be built with the modules of the off-lme system architecture (see Figure 1) Once built and tested via simulations, they may be deployed to the on-lme application The Experiment Database 360 may be implemented as an in-memory database It may only be required to hold the data elements for one customer or entity To embed the decision, the on-line application may be modified to use the APIs for the Data Transform Engme sub-module 110 and the Decision Engme module 640 The transforms 120 and components 510 may be built with the modules of the off-lme system architecture (see Figure 1) Once built and tested via simulations, the transforms 120 and components 510 may be deployed to the on-lme application If the decision does not mclude global or regional constramts the Decision Database 680 may be implemented as an m-memory database, smce it may only be requned to hold the data elements for one customer or entity However, with global or regional constramts, the Decision Database 680 may hold the data elements for all customers or entities to which the constramts apply Figure 16: Internet-Based Closed-Loop System Module The combination of the off-lme and on-lme architectures may allow for building closed-loop systems As an example, Figure 16 shows the architecture for a closed-loop system that makes marketing decisions for an Internet busmess The architecture would essentially be the same for other closed-loop systems, where the external systems and on-lme applications may be different In the example, the Internet busmess may be makmg decisions and performmg expeπments on the content of promotions and mcentives delivered via email and the web The off-lme system architecture may be used to build a system for executmg expeπments and decisions for the email promotions and mcentives The on-lme system architecture may be used to embed the expeπment and decision execution m the on-lme web application The combination becomes closed-loop when the results may be captured and used to adapt future decisions For the example software architecture, the Export module 150 may be customized with a set of transforms 120 and a Data Interface sub-module 130 that converts the experiment and decision data to an email delivery system The combination creates email messages that contam the promotion or incentive tailored to the customer The Import module 100 may be customized with a set of transforms and Data Interface sub-modules 130 that convert the data from 3rd party customer data warehouses and an mtemal Data Collection database 800 The Data Collection database 800 may be used to store the results from the email and web responses Another version of the Import module 100 may be customized with a set of transforms and a Data Interface sub-module 130 that converts the email responses from an email delivery system for the Data Collection database 800 The off-lme modules may also be used to run simulations for the on-lme modules Once the simulations prove satisfactory, the transforms 120, rules 330 and components 510 used m the simulations may be deployed to the on-lme modules The following process may be used by Web Touch-pomt Application 260 1 The Web Touch-pomt Application 260 calls Web On-lme Interface module 700 to get a promotion or incentive, 2 The Web On-lme Interface module 700 collects the customer data known by the Web Touch-pomt Application 260, 3 The Web On-lme Interface module 700 retπeves additional customer data from the 3rd Party Customer Database 230, 4 The Web On-lme Interface module 700 determines whether an experiment or decision should be done, 5 The Web On-lme Interface module 700 uses the on-lme APIs 110, 640, and 340 to determine the tailored promotion or incentive, 6 The Web On-lme Interface module 700 records the promotion or incentive m the Data Collection database 800, 7 The Web On-lme Interface module returns the tailored promotion or mcentive to the Web Touch-pomt Application 260; 8 The Web Touch-pomt Application 260 calls the Web On-lme Interface module 700 to record response information, 9 The Web On-lme Interface module 700 records the response information in the Data Collection database 800 The Web On-lme Interface module 700 may be implemented such that it and the on-lme APIs reside on the same computer as the Web Touch-pomt Application 260, the modules may reside on a remote computer, connected via a network to the computer runmng the Web Touch-pomt Application 260 The databases 230 and 800 may each be on a remote computer, separate from the computer running the Web On-lme Interface module 700 The data elements collected m the Data Collection database 800 may be used m the off-lme modules to adapt the models and experiments to make further adjustments m the email and web promotions/incentives Vaπous embodiments may further mclude receivmg or storing instructions and/or data implemented m accordance with the foregomg descπption upon a earner medium Suitable earner media may mclude storage media or memory media such as magnetic or optical media, e.g., disk or CD-ROM, as well as signals such as electncal, electromagnetic, or digital signals, conveyed via a communication medium such as networks 1702 and/or 1704 and/or a wireless link Although the system and method of the present mvention have been descnbed m connection with several embodiments, the mvention is not mtended to be limited to the specific forms set forth herem, but on the contrary, it is mtended to cover such alternatives, modifications, and equivalents as may be reasonably mcluded within the spint and scope of the mvention as defined by the appended claims

Claims: What is claimed is: 1 A system for optimization of decision-making, wherem the system compπses a plurality of components, and wherem the components compnse. one or more components for design of expeπments, wherem the one or more components for design of expeπments are operable to create and deploy expeπments, wherem the expeπments compnse one or more combmations of decision variable values, and wherem the one or more components for design of experiments compnse an expeπment database, an expeπment engme, and a component for designmg expeπments; one or more components for model building, wherem the one or more components for model building are operable to create and deploy mathematical models for decision makmg, and wherem the one or more components for model building compnse a model database and a component for building mathematical models; one or more components for decision makmg, wherem the one or more components for decision making are operable to create and deploy optimized decisions, and wherem the one or more components for decision makmg compnse a decision database, components for assemblmg the mathematical models with the decision database, a decision views component, a decision engme, and a decision reports component; and one or more components for trackmg, wherem the one or more components for trackmg compnse a trackmg database, and wherem the one or more components for trackmg are operable to record results of experiments,. 2. A method for optimization of decision-making, wherem the method comprises: a web touch-pomt application calling a web on-lme interface to obtain a promotion or incentive; the web on-lme interface retneving customer data from the web touch-pomt application; the web on-lme interface retneving additional customer data from a third party customer database; the web on-lme interface determining whether an experiment or decision should be performed; the web on-lme interface usmg an on-lme API to determine a tailored promotion or incentive; the web on-lme interface recording the promotion or incentive m a data collection database; the web on-lme interface returning the tailored promotion or incentive to the web touch-pomt application, the web touch-pomt application calling the web on-lme interface to record response information; and the web on-lme interface recording the response information m the data collection database. 3. A method for optimization of decision-making, wherem the method compπses: designmg one or more expeπments; deploymg the one or more experiments; trackmg results of the one or more expeπments; building one or more mathematical models based on the results of the one or more expeπments; designmg a decision, wherem the decision is a function of one or more decision vanables, one or more objectives, zero or more constramts, and zero or more nsk factors, wherem each objective compnses a target goal of the decision, each constramt compπses a limitation on one or more of the decision vaπable values and objectives, and each nsk factor compnses an expression of uncertainty for one of the objectives; deploymg the decision to generate decision results, A method for optimization of decision-making, wherem the method compπses: building one or more mathematical models; and makmg one or more optimized decisions based on the one or more mathematical models to generate decision results. 5. The method of claim 4, further compnsmg tracking the decision results of the one or more optimized decisions, wherem the decision results of the one or more optimized decisions are used to modify the one or more mathematical models. 6. The method of claim 4, further compnsmg: designmg one or more experiments, deploymg the one or more experiments to generate results of the one or more expeπments; and building the one or more mathematical models based on the results of the one or more experiments. 7. The method of claim 6, further compπsmg trackmg the results of the one or more expeπments; 8. The method of claim 7, further compπsmg trackmg the decision results of the one or more optimized decisions, wherem the decision results of the one or more optimized decisions are used to modify the one or more mathematical models. 9. A system for optimization of decision-making, wherem the system compπses a plurality of components, and wherem the components compnse: one or more components for design of expeπments; one or more components for mathematical model building; and one or more components for decision makmg. 10. The system of claim 5, wherem the one or more components for design of experiments are operable to create and deploy expeπments, wherem the experiments compnse one or more combmations of decision vanable values. 11. The system of claim 5 , wherem the one or more components for design of expeπments compnse one or more of an experiment database, an expeπment engme, and a component for designmg experiments; 12. The system of claim 5 , wherem the one or more components for model building are operable to create and deploy mathematical models for decision makmg, 13. The system of claim 5, wherem the one or more components for model building compnse a model database and one or more components for building mathematical models, 14. The system of claim 5, wherein the one or more components for decision making are operable to create and deploy optimized decisions 15. The system of claim 5, wherein the one or more components for decision making comprise a decision database, an assembly component which is operable to assemble mathematical models and the decision database, a decision views component, a decision engine, and a decision reports component. 16. The system of claim 5, further comprising one or more components for tracking. 17. The system of claim 16, wherein the one or more components for tracking are operable to record and view the results of experiments, 18. The system of claim 17, wherein the one or more components for tracking comprise: a tracking database; and one or more tracking tools which are operable to perform one or more of: recording and viewing results of experiments; recording and viewing results of optimized decisions; recording and viewing results of mathematical models; comparing the results of the mathematical models to the results of the optimized decisions; 19. A system for optimization of decision-making, the system comprising: a design experiment component, wherein the design experiment component is operable to create a set of segmentation and sampling rules; and an experiment engine, wherein the experiment engine is operable to use the set of segmentation and sampling rules to select an experiment, wherein the experiment comprises a combination of decision variable values; an application, wherein the experiment engine is embedded in the application, and wherein the application is operable to deploy the experiment. 20. The system of claim 19, wherein the design experiment component creates the set of segmentation and sampling rules off-line; wherein the experiment engine selects the experiment on-line; and wherein the application deploys the experiment on-line. 21. A system for optimization of decision-making, the system comprising: one or more model building components, wherein the one or more model building components are operable to create one or more mathematical models; one or more decision-making components, wherein the one or more decision-making components are operable to assemble one or more mathematical models into an aggregate model; a decision engme, wherem the decision engme is operable to use the aggregate model to select an optimized decision and generate corresponding predicted results; and an application, wherem the decision engme is embedded m the application, and wherem the application is operable to deploy the optimized decision and generate coπesponding decision results. 22. The system of claim 21 , wherem the one or more model building components are operable to create the one or more mathematical models off-lme; wherem the one or more decision-making components are operable to assemble the one or more mathematical models mto the aggregate model off-lme; wherem the decision engme is operable to use the aggregate model to create an optimized decision on-line; and wherem the application is operable to deploy the optimized decision on-lme 23. The system of claim 21 , wherem the application is further operable to collect the decision results and the predicted results; wherem the one or more model building components are further operable to compare the decision results to the predicted results, and to modify the one or more mathematical models to minimize differences between the decision results and new predicted results generated by the modified mathematical models. 24. The system of claim 23, wherem the one or more model building components are operable to create the one or more mathematical models off-lme; wherem the one or more decision-making components are operable to assemble the one or more mathematical models mto the aggregate model off-lme; wherem the decision engme is operable to use the aggregate model to create an optimized decision on-lme; and wherem the application is operable to deploy the optimized decision on-lme. 25. A system for optimization of decision-making, the system compnsing- a design expeπment component, wherem the design expeπment component is operable to create a set of segmentation and samplmg rules; an experiment engme, wherem the expeπment engme is operable to use the set of segmentation and samplmg rules to select an expeπment, wherem the expeπment compnses a first combmation of decision vanable values; one or more model building components, wherem the one or more model building components are operable to create one or more mathematical models, one or more decision-making components, wherem the one or more decision-making components are operable to assemble one or more mathematical models mto an aggregate model; a decision engme, wherem the decision engme is operable to use the aggregate model to select an optimized decision and generate corresponding predicted results, wherem the optimized decision compπses a second combmation of decision vaπable values; an application mterface, wherem the expeπment engme is embedded m the application mterface, and wherem the application mterface is operable to receive the expeπment if the expeπment engme selects the experiment; and wherem the decision engme is embedded m the application mterface, and wherem the application mterface is operable to receive the optimized decision if the expeπment engme does not select the expeπment; an application, wherem the application mterface is embedded m the application, and wherem the application mterface is operable to pass a resultant combmation of decision vanable values to the application, wherem the resultant combmation of decision vanable values compnses the first combmation of decision vanable values if the expeπment engme selects the expeπment, and wherem the resultant combmation of decision vanable values compnses the second combmation of decision vanable values if the experiment engme does not select the experiment; and wherem the application is operable to deploy the resultant combmation of decision vanable values to generate coπesponding decision results. 26. The system of claim 25, wherem the design expeπment component creates the set of segmentation and samplmg rales off-lme; wherem the one or more model building components are operable to create the one or more mathematical models off-line; wherem the one or more decision-making components are operable to assemble the one or more mathematical models mto the aggregate model off-lme; wherem the expeπment engme selects the experiment on-lme, wherem the decision engme is operable to use the aggregate model to create an optimized decision on-lme; wherem the application mterface is operable to receive the experiment on-lme; wherem the application mterface is operable to receive the optimized decision on-lme, wherem the application mterface is operable to pass the resultant combmation of decision vanable values to the application on-lme; wherem the application is operable to deploy the resultant combmation of decision vanable values on-lme 27. The system of claim 25, wherem the application is further operable to collect the decision results and the predicted results; wherem the one or more model building components are further operable to compare the decision results to the predicted results, and to modify the one or more mathematical models to minimize differences between the decision results and new predicted results generated by the modified mathematical models. 28. The system of claim 27, wherem the design expeπment component creates the set of segmentation and samplmg rules off-lme; wherem the one or more model building components are operable to create the one or more mathematical models off-lme, wherem the one 01 more decision-making components are operable to assemble the one or more mathematical models mto the aggregate model off-lme; wherem the expeπment engme selects the experiment on-lme; wherem the decision engme is operable to use the aggregate model to create an optimized decision on-lme; wherem the application mterface is operable to receive the expeπment on-lme; wherem the application mterface is operable to receive the optimized decision on-lme; wherem the application mterface is operable to pass the resultant combmation of decision vaπable values to the application on-lme; and wherem the application is operable to deploy the resultant combmation of decision vaπable values on-lme.

Inventors: ALEXANDER RHONDA, CARUANA FRANK D, HARRIS MATTHEW M, HERSCHAP EDMOND III, HOGAN PATRICK, JOHNS RICHARD P, MAGNUSON TIMOTHY J, SPAULDING KENT A, TRAUGHBER THOMAS J, ALEXANDER, RHONDA, CARUANA, FRANK, D., HARRIS, MATTHEW, M., HERSCHAP, EDMOND, III, HOGAN, PATRICK, JOHNS, RICHARD, P., MAGNUSON, TIMOTHY, J., SPAULDING, KENT, A., TRAUGHBER, THOMAS, J.
Applicants: TRAJECTA INC, TRAJECTA, INC.
Application year: 2000
Main classification: G06F17
IPC codes: G06Q10