DETAILED DESCRIPTION

[0035] FIG. 1 shows a method 100 for managing recipes and other sets of processing information that describe a process flow. A system performing the method 100 receives one or more recipes or other sets of processing information that describe a process flow (step 105 ). The recipe can be, e.g., one or more general recipes, site recipes, master recipes, or combinations thereof. The system can receive the recipes from a user through an input device, or from another computer system. The recipes can be stored, e.g., in a recipe database.

[0036] At least two of the received recipes are variants within a single variant class. Variants are recipes that describe similar process flows but produce slightly different outputs. For example, one recipe can describe a process for producing a polymer with a certain average molecular weight, while a second, variant recipe can describe a similar process for producing the same polymer with a larger average molecular weight.

[0037] Variants can describe different activities, different formulae, or both. A formula is a list of inputs and outputs of a recipe. For example, two different variants can describe two different catalysts that can be input into a single process to achieve two different average molecular weights of a polymer. As another example, two different variants can describe two different reaction temperatures that can be used with a single formula to achieve two different average molecular weights of the polymer.

[0038] The system also receives a characteristic of a variant class for use in classifying the variants (step 110 ). The characteristic can be a generic characteristic of the slightly different outputs of the recipe variants. The information can be received from a user so that the recipes can be categorized in accordance with a user's understanding of the distinguishing characteristics of the outputs of the recipes. For example, a user may wish to classify variants according to a commercial category of the product, or according to a physical property such as the glass transition temperature of the product.

[0039] The system groups the variants of the recipe into variant classes based on the received characteristic of the variant class (step 115 ). For example, if the user identifies that recipes are to be categorized according to the commercial category of the product, the system accesses the received recipes and identifies recipes that yield outputs within the identified commercial category.

[0040] The system then identifies the variants according to variant class (step 120 ). The system can identify the variants outside the semantic key of the variants. A semantic key is a key that has potential values that have an obvious meaning to the user of the key. In order to identify the variants outside a semantic key, for example, the system can identify the variants by assigning the variants a common extension or field. Since the class of the variants-can be identified outside the semantic key, the system can also assign a unique semantic key to each recipe (step 125 ). The semantic key can be, e.g., an recognizable name or recipe ID number.

[0041] Alternatively, the class of the variants can be identified within the semantic key. For example, the semantic key may include a prefix that identifies the class of the recipe.

[0042] In addition to the semantic key, recipes and recipe variants can have several different identifiers for different contexts. For example, recipes can be identified by the physical properties of the products of the recipe, the by-products of the recipe, and the formula of a recipe. By using several different identifiers, the identification of recipes in different business contexts is hastened.

[0043] FIG. 2 shows a table 200 wherein several recipe variants are managed in accordance with method 100 . Table 200 includes recipe records 205 , 210 , 215 , 220 , 225 that each describe a process flow for making a food product. Recipe records 205 , 210 , 215 , 220 , 225 can be variants within one or more variant class. For example, recipe records 205 , 210 , 215 can be variants within the omelet class, while recipe records 220 , 225 can be variants within the pancake class. In particular, recipe record 205 can describe a process flow for making a spinach variant within the omelet class; recipe record 210 can describe a process flow for making a cheese variant within the omelet class; recipe record 215 can describe a process flow for making a ham and cheese variant within the omelet class; recipe record 220 can describe a process flow for making a blueberry variant within the pancake class; and recipe record 225 can describe a process flow for making a strawberry variant within the pancake class.

[0044] Table 200 also includes fields 230 , 235 , 240 , 245 , 260 , 265 . Field 230 can include recipe ID numbers that act as semantic keys for recipe records 205 - 225 . Field 235 can identify the variant class of recipe records 205 - 225 . Field 240 can include information that identifies the difference between the outputs of recipe records 205 - 225 within a variant class. Field 245 can include flags that indicate whether recipe records 205 - 225 are the default versions of those recipes, as discussed further below. Field 260 can include information that describes the formulae for recipe records 205 - 225 . Field 265 can include information that describes the process element hierarchy for recipe records 205 - 225 .

[0045] The classification and management of recipe variants and variants of other sets of processing information that describe a process flow speeds the identification of existing recipes. In particular, since recipes can be classified according to generic characteristics of the outputs of the recipes, a user who is interested in obtaining a product with a particular characteristic can rapidly sort through large numbers of recipes.

[0046] Moreover, the classification of recipes can be performed according to a user's understanding of the distinguishing characteristics of the variant classes. For example, recipes for the production of polymers can be classified according to, e.g., a characteristic of the activities that produce the polymer (e.g., a free-radical reaction vs. a condensation reaction); a characteristic of equipment that performs the activities (e.g., a plug-flow reactor vs. a batch reactor), a characteristic of the formula that produces the polymer (e.g., a glycolic acid reactant vs. a lactic acid reactant) or any other distinguishing characteristic that the user understands as distinguishing the variant classes.

[0047] One particular type of variant is the internal variant. Internal variants are recipes that produce a wide spectrum of outputs based on parameters that are received from a producer during production.

[0048] FIG. 3 shows a method 300 , in accordance with the invention, for managing recipes or other sets of processing information that describe a process flow. A system performing the method 100 receives two or more recipes or other sets of processing information that describe a process flow (step 105 ). At least two of the received recipes are alternatives of the same recipe. Alternatives are recipes that describe different process flows but have the same primary or secondary output. An output is a product or other result of performing the process flow described by the recipe, and a single recipe can have several different outputs. A primary output is the major product or other result of a process flow, whereas a secondary output is a secondary product or other result, such as, e.g., a by-product, of a process flow.

[0049] To achieve the same output, alternatives can describe different activities, different formulae, or both. For example, two different alternatives can describe that different amounts of two different catalysts can be used in two different processes to achieve the same average molecular weight of a polymer. Two alternatives can exist in parallel and can be valid simultaneously.

[0050] The system identifies the received recipes that have the same output (step 310 ) and identifies them as alternatives (step 315 ). The system can identify the alternatives by assigning them a common extension or field, or linking them to an object that identifies a common output.

[0051] The system can also mark a recipe as the default or favored alternative for achieving an output (step 320 ). Since a single recipe can have several different outputs (e.g., by-products of a chemical reaction), a recipe can include several different markings that indicate whether the recipe is the default or favored alternative for achieving each of the different outputs. Moreover, two recipes can be alternatives for one product, but not for a second product.

[0052] Furthermore, alternatives can be ranked on a scale according to appeal. For example, one alternative can be flagged as first choice for a specific output, while a second alternative can be flagged as the second choice, and a third alternative can be flagged as the third choice

[0053] FIG. 4 shows a table 400 wherein several recipe alternatives are managed in accordance with method 300 . Table 400 includes recipe records 205 , 405 , 410 that each describe a process flow for making the same food product. In particular, recipe records 205 , 405 , 410 can each describe a different recipe for making a spinach omelet. Recipe records 205 , 405 , 410 can differ, e.g., in either the process flow described using the element hierarchy in field 265 or in the formula described in field 260 .

[0054] Recipe records 205 , 405 , 410 can be identified as alternatives by the equivalence of fields 235 , 240 in records 205 , 405 , 410 . Moreover, recipe record 205 can be marked as the default recipe record for the output identified in fields 235 , 240 by the flag in field 245 .

[0055] FIG. 5 shows a block diagram of a data structure 500 wherein several recipe alternatives are managed in accordance with method 300 . In particular, data structure 500 includes recipe alternatives 505 , 510 , 515 for producing a same product. In particular, recipe 505 uses a formula 520 , recipe 510 uses a formula 525 , and recipe 515 uses a formula 530 for producing a yogurt output. The yogurt output is identified in a root object 535 that is linked to recipes 505 , 510 , 515 by linkages 540 , 545 , 550 . Linkages 540 , 545 , 550 can be, e.g., pointers and can identify recipes 505 , 510 , 515 as alternatives for producing the yogurt output identified in root object 535 .

[0056] The management and ranking of recipe alternatives and other process flow alternatives speeds the identification of existing recipes. In particular, since recipes can be associated and ranked with other recipes that have the same output, a user who is interested in obtaining a particular output can rapidly sort through large numbers of recipes and easily compare the recipe alternatives to identify the recipe with the most favorable characteristics.

[0057] FIG. 6 shows a method 600 , in accordance with the invention, for managing change in recipes or other sets of processing information that describe a process flow. A system performing the method 600 receives a recipe or other description of a process flow (step 605 ). The system also receives a lifespan of the recipe (step 610 ). A lifespan is a time period for which the recipe is valid.

[0058] The system also receives a second version of the recipe (step 615 ), as well as a lifespan for the second version (step 620 ). Versions are different recipes with the same output or outputs. However, versions are valid for different periods of time. Versions thus have a chronological sequence and describe the recipe as it exists at different times. In other words, two versions of one recipe produce the same output(s), but one version is valid for a first lifespan that is different from the valid lifespan of a second version. The life spans of different versions can follow one another in time without any overlap, or the life spans can overlap for a transition period when both versions are simultaneously valid. Alternatively, a gap when no versions are valid can exist between the life spans of different versions.

[0059] The second version of the recipe can be received by copying the recipe and using the copy as a template for receiving alterations from a user. Alternatively, a user can input the second version from scratch. The name of the original recipe can be maintained, e.g., if a version is created by copying the recipe.

[0060] The system also identifies the recipe and the second version of the recipe according to their predecessor/successor relationship (step 625 ). In other words, the system identifies the recipe and the second version according their life spans, identifying the version with the earlier lifespan as the predecessor and identifying the version with the later lifespan as the successor. Thus, time serves as a one-dimensional parameter that defines the relationship between versions. Aside from the predecessor/successor identification, versions can be independent objects.

[0061] The system can identify the predecessor/successor relationship, e.g., by storing a link from the successor to the predecessor. In this case, versions can also be identified using a customer-specific indicator or a completely different name, since different versions can also be identified by the predecessor/successor link.

[0062] To identify the predecessor/successor relationship, a suffix for the version can also be added to the recipe ID. The version suffix of the new recipe ID can be automatically increased each time a new version is created.

[0063] FIG. 7 shows a table 700 wherein several recipe versions, or versions of other sets of processing information that describe a process flow, are managed in accordance with method 600 . Table 700 includes recipe records 205 , 705 , 710 that each describe a different recipe for making the same food product, but recipes 205 , 705 , 710 are valid for different periods of time. In particular, recipes 205 , 705 , 710 include fields 730 , 735 . Fields 730 and 735 identify the time period for which recipe records 205 , 705 , 710 are valid.

[0064] Recipes 205 , 705 , 710 can differ in either the process flow described using the element hierarchy in field 265 or in the formula described in field 260 . Recipes 205 , 705 , 710 are valid from the date identified in field 730 to the date identified in field 735 . As illustrated, recipe 205 is valid for a lifespan that overlaps with the lifespan of recipe 705 . The lifespan of recipe 705 does not overlap with the lifespan of recipe 710 .

[0065] Recipe records 205 , 705 , 710 can be identified as versions of the same recipe by suffixes 715 , 720 , 725 on the recipe ID in field 230 . In particular, since suffixes 715 , 720 , 725 increment in accordance to the final valid date of recipes 205 , 705 , 710 , the predecessor/successor relationship between recipes 205 , 705 , 710 is identified.

[0066] FIG. 8 shows a method 800 for managing change of recipes or other sets of processing information that describe a process flow. A system performing the method 800 receives a draft recipe or other draft description of a process flow (step 805 ). A draft recipe is a recipe that is used to make proposals during the development or improvement of a recipe or recipe version. A draft recipe can have several change states that are continuously or intermittently updated to reflect the current approaches to improving the recipe. The multiple change states are, however, identified by the same recipe ID. A recipe and a version of a recipe can have multiple drafts that reflect multiple approaches to improving or developing the recipe or the recipe version. Since drafts work with continuously or intermittently updated change states, the data volume on a database that stores drafts can be relatively small.

[0067] The system can receive a draft recipe that is generated from scratch by a user, or the system can receive identification of a recipe or recipe version that is to be copied and used as a template for the draft. The system can identify the received draft recipe by, e.g., adding an additional suffix to the recipe ID to identify the draft. The identifying suffix can be changed, e.g., by a user-exit. If a recipe version is copied to create a new draft, the version identification need not be changed. Instead, an additional draft index can be added so that the version identification still refers to the source version.

[0068] The system also receives changes to the draft (step 810 ) that reflect the development or improvement of the recipe. The changes can alter any portion of the recipe, including the formula and the process flow. At some point the system will receive a command from a user that indicates that a new recipe version is to be created from the current change state of the draft (step 815 ). In response to receipt of this command, the system copies the current change state of the draft to create a new version (step 820 ). The draft can be copied by, e.g., duplicating the process flow and the formula of the draft recipe into the new version of the recipe. The system also receives a lifespan of the new version of the recipe (step 825 ), and identifies the new version of the recipe and the current version of the recipe according to their predecessor/successor relationship (step 830 ).

[0069] At some point the user can indicate to the system that further improvement or development of the draft recipe is no longer desired (decision 835 ). If this is the case, then the system proceeds to end the process flow of method 800 . On the other hand, if further development is desired, then the system receives further changes to the draft that reflect the development or improvement of the recipe as before.

[0070] FIG. 9 shows a draft recipe 900 that can be used to manage change of recipes or other sets of processing information that describe a process flow in accordance with method 800 . Draft recipe 900 describes a process flow for making a food product and includes a description of a process flow at element hierarchy field 265 and a description of the formula in field 260 . A user can change either element hierarchy field 265 of the formula in field 260 to make proposals during the development or improvement of draft recipe 900 .

[0071] Draft recipe 900 includes an ID field 905 that includes a draft recipe ID number that can act as a semantic key for draft recipe 900 . The draft recipe ID number includes a first suffix 910 and a second suffix 915 . First suffix 910 identifies the source version of draft recipe 900 , and second suffix 915 acts as a draft index to identify the approach, particular to draft recipe 900 , for improving or developing the source recipe.

[0072] Draft recipe 900 also includes a field 920 that identifies the last date on which draft recipe 900 was updated. A user can use a date in field 920 to determine if draft recipe 900 is indeed current or to determine if draft recipe 900 is to be copied to create a new version of the source recipe.

[0073] FIG. 10 schematically illustrates the operation of method 800 . The system performing method 800 receives a draft recipe 905 at a time 1010 . The system also receives intermittent changes to draft recipe 905 at times 1015 , 1020 , 1025 . These change states are identified under the same semantic key ID, namely “573.1.1.”

[0074] At times t 1 and t 3 , the system receives a copy command and proceeds to copy draft recipe 905 to create new versions of recipe 205 . In particular, the system creates versions 705 , 710 , as indicated by dashed arrows 1030 , 1035 . The system also receives a definition of the life spans of versions 705 , 710 . The lifespan of version 205 overlaps with the lifespan of version 705 over a period 1037 between time t 1 and time t 2 . The lifespan of versions 705 , 710 follow one another without an overlap or a gap.

[0075] The sequence of the life spans, and the predecessor/successor relationship, can be identified using the semantic key of versions 205 , 705 , 710 . In particular, the semantic key of version 205 can be “573.1,” the semantic key of version 705 can be “573.2,” and the semantic key of version 710 can be “573.3.” The suffixes of the semantic keys indicate the predecessor/successor relationship.

[0076] The system can also link versions 205 , 705 , 710 to identify predecessor/successor relationships. In particular, the system can create a link 1040 between version 705 and version 205 and a link 1045 between version 710 and version 705 . Links 1040 , 1045 can be included in link fields in versions 705 , 710 (not shown).

[0077] Versions 205 , 705 , 710 do not include change states because a complex time dependency would result. Alternatively, versions 205 , 705 , 710 can include change states on one level of the element hierarchy that describes the process flow, such as the application level. However, in some cases, including change states in versions 205 , 705 , 710 may be desirable.

[0078] As shown in FIG. 11, a recipe 1100 need not include a formula field 260 as an inherent portion of the description of the recipe. Rather, recipe 1100 can include a formula link 1105 that identifies a formula record 1110 . Formula record 1110 is independent of recipe 1100 in that changes to formula record 1110 do not necessarily result in the creation of a new version of recipe 1100 . Likewise, changes to recipe 1100 (e.g., changes to the element hierarchy in field 265 ) do not necessarily result in the creation of a new version of formula record 1110 . Rather, changes to formula record 1110 can result in the creation of a new version of formula record 1110 independently of recipe 1100 .

[0079] A formula table 1115 includes formula record 1110 , along with other formula record versions 1120 , 1125 . Formula record versions 1110 , 1120 , 1125 describe the inputs and outputs of recipe 1100 . Formula record versions 1110 , 1120 , 1125 can be versions of the same formula with the same outputs, but different inputs.

[0080] Table 1115 also includes fields 1130 , 1135 , 1140 , 1145 , 1150 , 1155 , 1160 . Field 1130 can include formula ID numbers that act as semantic keys for formula records 1110 , 1120 , 1125 . The formula ID numbers in field 1130 can include suffixes 1165 , 1170 , 1175 that indicate the predecessor/successor relationships between formula records 1110 , 1120 , 1125 . Field 1135 can include information that identifies the output of recipes that link to the formula records. Fields 1140 , 1145 , 1150 can include information that identifies the inputs to recipes that link to the formula records. Field 1155 , 1160 can identify the life spans for which formula records 1110 , 1120 , 1125 are valid.

[0081] The versions of formula records 1110 , 1120 , 1125 can have a chronological sequence and describe the formula of a single recipe as it exists at different times. One formula version can be valid for a first lifespan that is different from the valid lifespan of a second formula version. The life spans of different formula versions can follow one another in time without any overlap, or the life spans can overlap for a transition period when both formula versions are simultaneously valid. Alternatively, a gap can exist between the life spans of different formula versions. A predecessor/successor relationship can also be indicated, e.g., using a separate link between formula records 1110 , 1120 , 1125 .

[0082] FIG. 12 shows a method 1200 , in accordance with the invention, for managing change of recipes or other sets of processing information that describe a process flow. In particular, method 1200 relates to the management of independent recipe versions and formula versions.

[0083] A system performing the method 1200 receives a first version of a formula (step 1205 ) and a second version of the formula (step 1210 ). The first and second versions are independent of a recipe. The system can store the versions in a table, such as table 1115 , if needed. The system also receives the life spans of the versions of the formula, which can be used to identify the predecessor/successor relationship of the versions of the formula (step 1215 ). To identify the predecessor/successor relationship, a suffix can be added to the formula ID. The suffix of the new formula ID can be automatically increased each time a new version is received. Alternatively, the predecessor/successor relationship can be indicated using a separate link between the received formula versions.

[0084] The system also receives a recipe (step 1220 ) that is independent of the versions of the formula. The recipe can be, e.g., a version of an existing recipe or a new recipe that can use the formulae described by the received versions. The system automatically links the received recipe to one of the two versions of the formula by executing rules for selecting the version (step 1225 ). For example, the system can execute a rule that states that the recipe is always to be linked to the most recent version of the formula to identify that the recipe is to be linked to the second version of the formula. Execution and linking can be done without consulting a user.

[0085] FIG. 13 schematically illustrates the operation of method 1200 . The system performing method 1200 receives formula versions 1305 , 1310 , 1315 , 1320 , 1325 . Formula versions 1305 , 1310 , 1315 are joined by links 1330 , 1335 to indicate predecessor/successor relationships, and formula versions 1320 , 1325 are joined by link 1340 to indicate a predecessor/successor relationship. The absence of a link between formula version 1315 and formula version 1320 indicates that formula versions 1315 , 1320 are not versions of the same formula but instead are, e.g., formula alternatives or variants.

[0086] The system performing method 1200 also receives recipe versions 1345 , 1350 . Recipe versions are joined by a link 1355 to indicate predecessor/successor relationships.

[0087] The system automatically links recipe versions 1345 , 1350 to formula versions 1305 , 1310 , 1315 , 1325 using linkages 1360 , 1365 , 1370 , 1375 , 1380 . The system establishes linkages 1360 , 1365 , 1370 , 1375 , 1380 based on a rule that selects formula versions 1305 , 1310 , 1315 , 1325 for linkage and excludes formula version 1320 from linkage. The rule can indicate, e.g., that linkages 1360 , 1365 , 1370 , 1375 , 1380 are to be automatically established to the most recent version of the formula.

[0088] Rules for establishing linkages to independent formulae can also be used to manage versioning of the recipes themselves. For example, when the system links recipe 1345 to formula versions 1310 , 1315 , the version of recipe 1345 does not change. On the other hand, when the system links recipe 1345 to formula version 1320 , recipe version 1350 is created. In particular, the system identifies that formula version 1320 is not a version of formula versions 1305 , 1310 , 1315 , but rather, e.g., an alternative or a variant of formula versions 1305 , 1310 , 1315 . The system then automatically receives recipe version 1350 by copying recipe version 1345 and automatically linking it to formula version 1320 .

[0089] FIG. 14 shows a method 1400 for managing change of recipes or other sets of processing information that describe a process flow. In particular, method 1400 relates to the change management of independent recipe versions and formula versions.

[0090] A system performing the method 1400 receives a first version of a formula (step 1205 ) and a second version of the formula (step 1210 ) that are independent of a recipe. The system can identify a predecessor/successor relationship between the versions of the formula.

[0091] Rather than automatically linking the recipe to a formula, the system queries a user to identify if a formula version is to be linked to a recipe (step 1405 ). The query can be presented to a human user over a monitor or other output device. The system receives user input that identifies that one of the first version of the formula and the second version of the formula is to be linked (step 1410 ). The input can be received from a human user over an input device such as a keyboard or a mouse. Based on the received input, the system creates a new version of a recipe (step 1415 ) and links the new version of the recipe to the identified version of the formula (step 1420 ). The new version of the recipe can be created, e.g., by copying a previous version of the recipe, including the previous process element hierarchy.

[0092] FIG. 15 schematically illustrates the operation of method 1400 . The system performing method 1400 receives formula versions 1505 , 1510 , 1515 , 1520 , 1525 . Formula versions 1505 , 1510 , 1515 are joined by links 1530 , 1535 , and formula versions 1520 , 1525 are joined by a link 1540 to indicate predecessor/successor relationships.

[0093] The system performing method 1400 also receives, from a user, an indication that a recipe is to be linked to one of formula versions 1505 , 1510 , 1515 , 1520 , 1525 . In response to receipt of the indication, the system creates recipes 1545 , 1550 , 1555 , 1560 and links them to the indicated formula versions 1505 , 1510 , 1515 , 1520 , 1525 . For example, the system links recipe 1545 to formula version 1505 using link 1565 , recipe 1550 to formula version 1510 using link 1570 , and recipe 1555 to formula version 1515 using link 1575 .

[0094] The system can link recipe 1560 to formula version 1520 using link 1580 or the system can link to formula version 1525 using link 1585 , depending on the indication received from the user. For example, if formula versions 1520 , 1525 are valid for the same period, then the user can select the formula version to which recipe 1560 is to be linked.

[0095] Method 1400 requires relatively more user input than method 1200 . In particular, method 1400 requires user input to identify the version of formula for linkage. This provides greater oversight to the user and increases the transparency of the resultant recipes.

[0096] The invention can be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. The invention can be implemented as a computer program product, i.e., a computer program tangibly embodied in an information carrier, e.g., in a machine-readable storage device or in a propagated signal, for execution by, or to control the operation of, data processing apparatus, e.g., a programmable processor, a computer, or multiple computers. A computer program can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program can be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communication network.

[0097] Method steps of the invention can be performed by one or more programmable processors executing a computer program to perform functions of the invention by operating on input data and generating output. Method steps can also be performed by, and apparatus of the invention can be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit).

[0098] Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read-only memory or a random access memory or both. The essential elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks. Information carriers suitable for embodying computer program instructions and data include all forms of non-volatile memory, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in special purpose logic circuitry.

[0099] To provide for interaction with a user, the invention can be implemented on a computer having a display device such as a CRT (cathode ray tube) or LCD (liquid crystal display) monitor for displaying information to the user and a keyboard and a pointing device such as a mouse or a trackball by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input.

[0100] The invention can be implemented in a computing system that includes a back-end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front-end component, e.g., a client computer having a graphical user interface or an Web browser through which a user can interact with an implementation of the invention, or any combination of such back-end, middleware, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (“LAN”), a wide area network (“WAN”), and the Internet.

[0101] The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.

[0102] A number of embodiments of the invention have been described. Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of the invention. For example, the method described herein can be combined into a single method and performed on a single system. Accordingly, other embodiments are within the scope of the following claims.