RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Application

No. 61/158,305 filed on March 6, 2009.

TECHNICAL FIELD

[0002] Embodiments of the present invention relate to scheduling generally, and more particularly, to the identification of manufacturing equipment that is unavailable to perform a task based on time and equipment constraints.

BACKGROUND OF THE INVENTION

[0003] Constraint programming can be used in a wide variety of constraint problems including job shop and flow shop scheduling, where a scheduling problem involves tasks that can be processed on more than one piece of equipment. The status of equipment introduces a number of constraints in determining a schedule. Constraint programming can be used to find a solution which can satisfy all of the constraints. Constraint programming includes a set of search variables, domains setting boundaries for the possible values for each of the variables, and a set of constraints. Typical scheduling problems involve creating two search variables for each task: one variable to represent the equipment that can process a task and another variable to represent the start time for the task. Unfortunately, the typical creation of two search variables provides limited capability for modeling common situations. For example, if equipment is set up for a certain task type and the task to be scheduled uses a different equipment setup, the current state of the art does not provide a way to update the search variables to indicate that equipment is not configured for a particular task at a certain time.

BRIEF DESCRIPTION OF THE DRAWINGS

[0004] The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which: [0005] Figure IA is a block diagram illustrating a per- station start time scheduling system;

[0006] Figure IB illustrates an exemplary computing environment for generating a station time constraint for identifying a station that is unavailable to perform a task and the time interval during which the station is unavailable to perform the task;

[0007] Figure 2 is a diagram schematically illustrating a station time constraint for identifying a station that is unavailable to perform a task and the time interval during which the station is unavailable to perform the task;

[0008] Figure 3 illustrates one embodiment of a method for generating a station time constraint for identifying a station that is unavailable to perform a task and the time interval during which the station is unavailable to perform the task;

[0009] Figure 4 illustrates one embodiment of a method for identifying a station that is unavailable to perform a task and the time interval during which the station is unavailable to perform the task; and

[0010] Figure 5 illustrates an exemplary computer system.

DETAILED DESCRIPTION

[0011] Embodiments of a method and apparatus are described to identify manufacturing equipment that is unavailable to perform a task and the time interval during which the station is unavailable to perform the task. A per-station start time scheduler identifies a plurality of stations capable of performing a task having a start time. The scheduler generates a station time constraint corresponding to the task based on a station variable and a start time variable. The station time constraint defines which stations are available to perform the task over a given time interval. The scheduler monitors each of the plurality of stations by monitoring the station time constraint for changes. Upon detecting a change in the station time constraint, the scheduler sends a notification specifying a station that is unavailable to perform the task and the time interval during which the station is unavailable to perform the task.

[0012] In one embodiment, the notification is created using a station time constraint associated with the task and a null-allowed search variable (NASV) for each station capable of performing the task. The task has a corresponding station time constraint that monitors start time variables for each station. The station time constraint identifies a station that is unavailable to perform the task and the time interval during which the station is unavailable to perform the task. The station time constraint combines information from a plurality of constraints and a plurality of variables and domains to identify a station that is unavailable to perform the task and the times the station is unavailable to perform the task. The station time constraint determines when the station is unavailable and updates a domain for the null-allowed search variable for the station. The station time constraint can send a notification that the task cannot be performed on the station at a particular time. This method and system identifies both the time during which a task cannot be performed and the station on which the task cannot be performed for that particular time.

[0013] Figure IA is a block diagram illustrating a per- station start time scheduling system 100. System 100 can include a factory system data source (e.g., manufacturing execution system (MES) 101), a dispatcher 103, and a scheduler 105. The MES 101, dispatcher 103, and scheduler 105 can be individually hosted by any type of computing device including desktop computers, laptop computers, handheld computers or similar computing device. Alternatively, a combination of MES 101, dispatcher 103, and scheduler 105 can be hosted on a single computing device including desktop computers, laptop computers, handheld computers or similar computing device. The scheduler 105 obtains data reflecting a current state of a factory managed by per-station start time scheduling system 100. For example, the scheduler 105 receives data identifying all available stations in the factory, the tasks that need to be processed and possible start times for each task. In one embodiment, the scheduler 105 is coupled to a factory system data source (e.g., MES 101 or an enterprise resource planning (ERP) system) to receive lot and equipment status data. The scheduler 105 uses the data to provisionally schedule the times for various tasks to be performed on various stations. The scheduler 105 can create a plurality of constraints, including a plurality of station time constraints 107; one for each task based on the data and the provisional schedule. A constraint defines a set of limitations based on the values of one or more input variables. The station time constraints 107 define which stations are available to perform a task and which stations are unavailable to perform the task based on a set of input variables including the start time and end time of the task. The provisional schedule and any data related to the provisional schedule are also provided to the plurality of constraints, including the station time constraints 107. The constraints perform updates based on the provisional schedule. Additional provisional scheduling may be performed and the constraints may perform additional updates until an entire schedule is constructed. A "station" can refer to manufacturing equipment, a manufacturing tool, a component of manufacturing equipment, or a component of a manufacturing tool. The scheduler 105 can provide the entire schedule to a dispatcher 103. The dispatcher 103 can be integrated through the MES 101 to dispatch, for example, wafer lots accordingly.

[0014] In one embodiment, a mechanism is provided that uses a new programming constraint referred to as a station time constraint (or per- station start time constraint) for identifying a station that is unavailable to perform a task and the time interval(s) during which the station is unavailable to perform the task. In one embodiment, a station time constraint uses a new constraint programming construct referred to as a null-allowed search variable (NASV) for tracking the possible times that the task can be performed on each station.

[0015] Figure IB illustrates an exemplary computing environment 150 for generating a station time constraint (per- station start time constraint) for identifying a station that is unavailable to perform a task and the time interval(s) during which the station is unavailable to perform the task, in accordance with one embodiment. Computing environment 150 can be implemented as a server, client, workstation, desktop, tablet, or any other machine. It can also be implemented in one or more small portable platforms such as a notebook, a PDA (personal digital assistant), or wireless web devices, and other devices. Computing environment 150 can include a programming tool 153, a repository 157, and a user interface 151. [0016] A user interface 151 can receive data defining tasks to be performed on stations. The user interface 151 can also receive data defining a plurality of variables for each task, a domain for each variable, and a plurality of constraints using the variables for the tasks. A domain assigns a set of possible values to a variable. In certain embodiments, the domain may include a discreet list of the possible values or a range of possible values. The user interface 151 can be coupled to a programming tool 153 to define logic using the variables, domains, and constraints. The logic can be referred to as code 159. Examples of a programming tool 153 include tools for programming in Java, C++, Perl and Python. Code 159 can include one or more station time constraints 163. Each station time constraint 163 can include a NASV 165 for each station. Each task has a corresponding station time constraint that monitors the task start time constraints for each station associated with the task. The programming tool 153 can include a compiler 155 to convert the data into operable information. The operable information can be an executable file 161. The programming tool 153 can be coupled to a repository 157 for storing the logic (e.g., code 159) and the operable information (e.g., executable file 161). The repository 157 can be implemented on a main memory (not shown) or other data storage device (not shown).

[0017] Figure 2 schematically illustrates a station time constraint identifying a station that is unavailable to perform a task and the time interval during which the station is unavailable to perform the task, according to one embodiment of the invention. Figure 2 illustrates two tasks, each task having a set of variables (201, 203). Examples of tasks include performing chemical mechanical polishing (CMP) on a CMP tool, plasma etching on multi-chamber cluster tools, etc. The tasks can be performed on one or more stations (not shown). For example, each chamber in a multi-chamber clustering tool may be capable of performing the plasma etching task. However, each chamber may not be available to perform the task.

[0018] Constraint programming search variables (201, 203) are defined for each task. Examples of search variables include a start time variable (205, 231), a station variable (209, 235), and an end-time variable (213, 239). A station variable (209, 235) can represent the equipment (i.e., stations) capable of processing the task. A start time variable (205, 231) can represent a start time for the task. An end time variable (213, 239) can represent an end time for the task.

[0019] Each of the variables has a respective domain. A domain assigns a set of possible values to a variable. In this way, the values within a domain can become constraints in and of themselves. Domains can be expressed as discrete independent ranges for variables or as expressions which include more than one variable. Using the examples of search variables above, a start time variable (205, 231) has a corresponding start time domain (207, 233), a station variable (209, 235) has a corresponding station domain (211, 237), and an end time variable (213, 239) has a corresponding end time domain (215, 241). For example, if Taskl can run only on three stations (Station 1, Station2, and Station3) and start between time 0 and 100, this information determines the values for start time domain (207) and the station domain (211). The station domain (211) has values representing the three stations that can perform Taskl. The start time domain (207) has values representing start time between time 0 and 100 for Taskl.

[0020] Constraints can be created using the variables as inputs. Constraints can be expressed as a set of input variables having some relationship. Constraints can contain several different input variables and can include function calls when expressed in a higher level language such as Java, C++, Perl or Python. A wide range of different constraints can be expressed. Constraints can be stored in a constraint library (not shown). For example, a capacity constraint (253) can use the start time variable for various tasks, the end time variable for various tasks, and the station variable for various tasks as inputs to ensure that equipment processes only one task at a given time. For instance, a capacity constraint (253) can define that Task2 cannot start until Taskl completes. The capacity constraint (253) can use the end time variable (213) of Taskl and the start time variable (231) of Task2 to define that the start time of Task2 is a time not before the end time of Taskl . Other examples of constraints that can use the variables of different tasks as inputs include a station-down constraint (255) and a station-setup constraint (257). [0021] A station time constraint (217, 243) can identify a station that can or cannot perform a task and the time interval during which the station can or cannot perform the task. There can be a station time constraint (217, 243) for each task. The station time constraint (217, 243) uses the start time variable and station variable for a task as inputs. For example, there is a station time constraint (217) for Taskl using the start time variable (205) for Taskl and station variable (209) for Taskl as inputs. There is a station time constraint (243) for Task2 using the start time variable (231) for Taskl and station variable (235) as inputs. A station time constraint (217, 243) watches for and receives notifications indicating changes from other constraints (e.g., station-down constraint (255)) and search variables (e.g., start time variable (205)). Constraints and variables can send out notifications to other constraints and variables indicating there is a change to the constraint, variable, or variable domain sending out the notification. For example, a station- down constraint (255) can enforce that no task run on a particular station while it is unavailable (e.g., a station is down or busy). If Station2 is down between time 0 and 15 and Station3 is busy between time 0 and 20, the station-down constraint (255) can send a notification to other constraints and variables indicating that Station2 and Station 3 are unavailable to perform Taskl at those respective times. Other constraints (e.g., a station time constraint (217, 243)) can receive the notification and update data reflecting the change. In another example, a station-set up constraint (257) can enforce that no task can run on a station that is not configured for the task. For instance, if Station 1 is set up between time 0 and 10 such that Stationl cannot perform Taskl using this particular configuration, the station-set up constraint (257) can send a notification indicating that Stationl cannot perform Taskl between time 0 and 10.

[0022] A station time constraint (217, 243) can combine information received from a number of search variables and domains to determine whether a task can be performed on a particular station at a particular time interval. For example, Taskl may run only on three stations and start between time 0 and 100. The Taskl station time constraint 217 may receive a notification from the station- setup constraint (257) that Taskl cannot run on Stationl between time 0 and 10 because of a setup change that does not support Taskl. The station time constraint (217) may also receive a notification from the station-down constraint (255) that Station2 is down between time 0 and 15 and Station3 busy between time 0 and 20. The station time constraint (217) can track this information to avoid scheduling Taskl on such stations during the indicated times and can update other variables and domains based on the information received.

[0023] In one embodiment, a station time constraint (217) uses a null- allowed search variable (NASV) to store the information for each station. Typically search variables can cause a search to fail if all of the values are removed from its domain. A null-allowed search variable is a search variable that is allowed to not have any values in its domain. A station time constraint (217) can include a NASV for each station that can possibly perform the task. The stations can be defined by the corresponding station domain for the task (211, 237). For example, for Taskl, the station time constraint (217) can include a NASV (219) for Stationl, a NASV (223) for Station2, and a NASV (227) for Station3. Each NASV has a corresponding domain (221, 225, 229). In addition, for Task2, the station time constraint (243) can include a NASV (245) for Stationl and a NASV (249) for Station2. Each NASV may have a corresponding domain (247, 251). The per- station NASVs track the times that the task can or cannot run on each station. [0024] Figure 3 illustrates one embodiment of a method 300 for generating a station time constraint for identifying a station that cannot perform a task and the time interval during which the station cannot perform the task. Method 300 can be performed by processing logic that can comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (e.g., instructions run on a processing device), or a combination thereof. In one embodiment, method 300 is performed using the computing environment 150 of Figure IB. [0025] At block 302, a plurality of stations are identified. A station can include manufacturing equipment, manufacturing tools, components of manufacturing equipment, and components of manufacturing equipment tools to perform a task. At block 304, a plurality of tasks to run on the stations are identified. A task can include a process performed on a station in the manufacture of semiconductors. Examples of tasks include performing chemical mechanical polishing (CMP) on a CMP tool, etching on multi-chamber cluster tools, etc. The plurality of tasks includes at least one task that can be performed by more than one station. For example, Taskl can be performed by any of three stations (e.g., Stationl, Station2, Station3). For instance, each chamber in a multi-chamber clustering tool may be capable of performing an etching process. [0026] At block 306, variables are created for each task. For example, a start time variable and a station variable can be created for Taskl. The station variable can identify the stations capable of performing Taskl (e.g., Stationl, Station2, Station3). The start time variable can identify the start time for Taskl (e.g., between time 0 and 100). A domain is created for each variable. A domain sets boundaries for the possible values for each of the variables. Using the above example, a station domain representing the three stations capable of performing Taskl is created for the station variable and a start time domain is created for the start time variable indicating a time between 0 and 100.

[0027] At block 308, a plurality of constraints is defined, including a station time constraint for each task. The plurality of constraints can use the variables of a task as inputs. For an example, a capacity constraint can define that Task2 cannot start until Taskl completes. The capacity constraint can use the end time variable of Taskl and the start time variable of Task2 as inputs defining that start time of Task2 cannot occur before the end time of Taskl. A station time constraint is created for each task. The station time constraint for a task can use the start time variable corresponding to the task and the station variable corresponding to the task as inputs. The station time constraint can monitor for and receive notifications from other constraints (e.g., station-down constraint, station-setup constraint) and search variables to identify both the station that is unavailable to perform the task and the time interval during which the station is unavailable to perform the task. [0028] At block 310, one or more null-allowed search variables (NASV) are created for each station time constraint. One NASV is created for each station that can possibly perform the task corresponding to the station time constraint. A domain is created for each NASV. For example, for a task than has three stations (e.g., Stationl, Station2, Station3) capable of performing the task, a NASV is created for Stationl, a NASV is created for Station2, and a NASV is created for Station3. Each NASV has a corresponding domain. The per-station NASVs track the time interval during which each station can or cannot perform the task. [0029] At block 312, logic is defined using the plurality of variables and domains and the plurality of constraints, including the station time constraint for each task and the NASVs and domains for each station. The logic can be referred to as non-executable code. At block 314, an executable file is created based on the logic, as described above with respect to Figure IB. [0030] Figure 4 illustrates one embodiment of a method 400 for identifying a station that is unavailable to perform a task and the time interval during which the station is unavailable to perform the task. Method 400 can be performed by processing logic that can comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (e.g., instructions run on a processing device), or a combination thereof. In one embodiment, method 400 is performed by the per- station start time scheduler 105 of Figure IA using a per- station start time constraint generated by computing environment 150 in Figure IB. [0031] In one embodiment, a task, a plurality of stations that can possibly process the task, variables and domains for the task, null-allowed search variables and domains, and constraints using the task variables have been defined. At block 401, processing logic can use the data from the constraints and variables to identify a station that is unavailable to perform the task and the time intervals during which the station is unavailable to perform the task. In one embodiment, at block 403, processing logic stores the data identifying the station that is unavailable to perform the task and the time intervals during which the station is unavailable to perform the task using a null-allowed search variable (NASV) and NASV domain for each station.

[0032] At block 405, processing logic monitors the constraints and variable domains for changes. Processing logic can monitor for changes in domains and changes detected by constraints. For example, processing logic can watch for changes to a start time domain, a station domain, the NASVs domains, and changes detected by a station-down constraint and a station- setup constraint. [0033] At block 407, processing logic determines whether a change is detected in a constraint. The change in a constraint may be caused by a change to the value of a variable that serves as an input to the constraint or by a change to the set of values in the domain of a variable. Processing logic can receive information (e.g., a notification) from a constraint or a variable indicating a change. For example, processing logic can receive a notification from a station-down constraint indicating that Station2 is down between time 0 and 15. In another example, processing logic can receive a notification from a start time variable that the start time variable domain has changed. Processing logic can also directly observe changes. For example, processing logic can observe that a time interval no longer appears in any of the NASV domains as a result of multiple updates made to the NASV domains. If a change is not detected (block 407), processing logic continues to monitor for changes at block 405.

[0034] If a change is detected (block 407), processing logic can update domains reflecting the change at block 409. Using the example above, if processing logic receives a notification from a station-down constraint indicating that Station2 is down between time 0 and 15, processing logic can update the domain for the null- allowed search variable (NASV) for Station2 indicating that the task cannot be performed on Station2 between time 0 and 15. In another example, if processing logic receives a notification from the start variable that its domain has changed, processing logic can update the domains of each NASV so that each has a domain smaller than the start variable domain.

[0035] At block 409, processing logic can also cause the domain of a variable to be updated reflecting a change. For example, if processing logic detects that a NASV domain for a station has changed such that the NASV domain no longer contains any values, processing logic can cause the station variable's domain to remove the station whose NASV domain no longer contains any values. For instance, Taskl may have a start time domain for a start time between 0 and 100 and a station domain indentifying Station 1, Station2, and Station3 as stations that can perform Taskl. Processing logic may have updated the NASV domain for Station2 indicating that Station2 is unavailable to perform Taskl between 0 and 50 because it had a set up change that no longer supports Taskl. Processing logic may also have updated the NASV domain for Station2 indicating that Station2 is also unavailable to perform Taskl between time 40 and 100 because it is busy. In this example, the NASV domain for Station2 no longer contains any values corresponding to the start time domain between time 0 and 100 for the task. Processing logic can cause the station variable to remove Station2 from its domain. In one embodiment, processing logic can monitor all time values in the various variable domains. In another embodiment, processing logic can monitor a minimum and/or maximum value in the variable domains. [0036] In another example, if processing logic detects that a time value does not appear in any of the NASV domains, processing logic can cause the time value to be removed from the start time variable domain. For instance, if processing logic receives a notification from a station-setup constraint that Station 1 is not available to perform Taskl between time 0 and 10, processing logic would remove the time interval from 0 to 10 in the NASV domain for Stationl. Similarly, if processing logic receives a notification from a station-down constraint that Station2 is not available to perform Taskl between time 0 and 15 because Station2 is down, processing logic would remove the time interval from 0 to 15 in the NASV domain for Station2. Lastly, if processing logic receives a notification from a station-down constraint that Station3 is not available to perform Taskl between time 0 and 20 because Station 3 is busy, processing logic would remove the time interval from 0 and 20 in the NASV domain for Station3. In this example, processing logic can observe that the time interval between 0 and 10 is not in any of the NASV domains. Processing logic can cause the start time variable to remove the time between 0 and 10 from its domain. In one embodiment, processing logic can monitor all time values in the various variable domains. In another embodiment, processing logic can monitor a minimum and/or maximum value in the variable domains. [0037] At block 411, processing logic can send a notification reflecting the detected change. A notification may also be referred to as a message or event. A notification can identify both the station that is unavailable to perform the task and the time interval during which the station is unavailable to perform the task. For example, processing logic can send a message to other constraints stating that Taskl cannot start between time 0 and 20 on Station3.

[0038] Figure 5 illustrates a diagrammatic representation of a machine in the exemplary form of a computer system 500 within which a set of instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed. In alternative embodiments, the machine may be connected (e.g., networked) to other machines in a LAN, an intranet, an extranet, or the Internet. The machine may operate in the capacity of a server or a client machine in a client- server network environment, or as a peer machine in a peer-to- peer (or distributed) network environment. The machine may be a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a server, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term "machine" shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein. [0039] The exemplary computer system 500 includes a processing device

(processor) 501, a main memory 503 (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM) or Rambus DRAM (RDRAM), etc.), a static memory 505 (e.g., flash memory, static random access memory (SRAM), etc.), and a data storage device 515 (e.g., drive unit), which communicate with each other via a bus 507. [0040] Processor 501 represents one or more general-purpose processing devices such as a microprocessor, central processing unit, or the like. More particularly, the processor 501 may be a complex instruction set computing (CISC) microprocessor, reduced instruction set computing (RISC) microprocessor, very long instruction word (VLIW) microprocessor, or a processor implementing other instruction sets or processors implementing a combination of instruction sets. The processor 501 may also be one or more special -purpose processing devices such as an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), network processor, or the like. The processor 501 is configured to execute the instructions 525 for performing the operations and steps discussed herein.

[0041] The computer system 500 may further include a network interface device 521. The computer system 500 also may include a video display unit 509 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)), an alphanumeric input device 511 (e.g., a keyboard), a cursor control device 513 (e.g., a mouse), and a signal generation device 519 (e.g., a speaker).

[0042] The data storage device 515 may include a computer-readable storage medium 523 on which is stored one or more sets of instructions 525 (e.g., software) embodying any one or more of the methodologies or functions described herein. The instructions 525 may also reside, completely or at least partially, within the main memory 503 and/or within the processor 501 during execution thereof by the computer system 500, the main memory 503 and the processor 501 also constituting computer-readable storage media. The instructions 525 may further be transmitted or received over a network 517 via the network interface device 521. [0043] The computer-readable storage medium 523 may also be used to store data structure sets that define user identifying states and user preferences that define user profiles. Data structure sets and user profiles may also be stored in other sections of computer system 500, such as static memory 505. [0044] While the computer-readable storage medium 523 is shown in an exemplary embodiment to be a single medium, the term "computer-readable storage medium" should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term "computer-readable storage medium" shall also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies for embodiments of the present invention. The term "computer-readable storage medium" shall accordingly be taken to include, but not be limited to, solid-state memories and optical and magnetic media.

[0045] Some portions of the above detailed description are presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of steps leading to a result. The steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like. [0046] It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussion, it is appreciated that throughout the description, discussions utilizing terms such as "identifying", "receiving," "monitoring," "detecting," "sending," or the like, refer to the actions and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (e.g., electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices. [0047] Embodiments of the invention also relate to an apparatus for performing the operations herein. This apparatus can be specially constructed for the required purposes, or it can comprise a general purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program can be stored in a computer readable storage medium, such as, but not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, and magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, or any type of media suitable for storing electronic instructions.

[0048] The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general purpose systems can be used with programs in accordance with the teachings herein, or it may prove convenient to construct a more specialized apparatus to perform the method steps. The structure for a variety of these systems will appear from the description below. In addition, embodiments of the present invention are not described with reference to any particular programming language. It will be appreciated that a variety of programming languages can be used to implement the teachings of embodiments of the invention as described herein. [0049] A machine-readable storage medium can include any mechanism for storing information in a form readable by a machine (e.g., a computer), but is not limited to, floppy diskettes, optical disks, Compact Disc, Read-Only Memory (CD- ROMs), and magneto-optical disks, Read-Only Memory (ROMs), Random Access Memory (RAM), Erasable Programmable Read-Only memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), magnetic or optical cards, flash memory, or the like.

[0050] It is to be understood that the above description is intended to be illustrative, and not restrictive. Many other embodiments will be apparent to those of skill in the art upon reading and understanding the above description.