Source: http://www.google.com/patents/US20020077842?dq=patent:4707592
Timestamp: 2016-09-27 05:33:43
Document Index: 249459592

Matched Legal Cases: ['art 5100', 'art 6000', 'art 6200', 'art 6200', 'art 6400', 'art 6400', 'art 6600']

Patent US20020077842 - Methods and systems for integrating process modeling and project planning - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inPatentsMethods and system consistent with the present invention provide a workflow modeling and project planning integration tool that allows a user to model a business process or workflow, to create and activate a project plan based on the workflow, and to track the progress of the activated project plan....http://www.google.com/patents/US20020077842?utm_source=gb-gplus-sharePatent US20020077842 - Methods and systems for integrating process modeling and project planningAdvanced Patent SearchTry the new Google Patents, with machine-classified Google Scholar results, and Japanese and South Korean patents.Publication numberUS20020077842 A1Publication typeApplicationApplication numberUS 09/944,697Publication dateJun 20, 2002Filing dateAug 31, 2001Priority dateSep 1, 2000Also published asUS6938240, US6968343, US7493591, US20020075293, US20020078432, US20020107914, US20050257136, WO2002019224A1, WO2002019226A1, WO2002019228A1, WO2002019272A1Publication number09944697, 944697, US 2002/0077842 A1, US 2002/077842 A1, US 20020077842 A1, US 20020077842A1, US 2002077842 A1, US 2002077842A1, US-A1-20020077842, US-A1-2002077842, US2002/0077842A1, US2002/077842A1, US20020077842 A1, US20020077842A1, US2002077842 A1, US2002077842A1InventorsDietrich Charisius, Jonathan KernOriginal AssigneeDietrich Charisius, Jonathan KernExport CitationBiBTeX, EndNote, RefManPatent Citations (11), Referenced by (96), Classifications (15), Legal Events (10) External Links: USPTO, USPTO Assignment, EspacenetMethods and systems for integrating process modeling and project planning
[0088] As discussed above, the VFS Interface 202 initially sends the requests that the Client Interface 134 directs to the WebDAV Storage 142 to the WebDAV proxy 146. The WebDAV proxy 146 sends these requests to the Management Modules 148. After the Management Modules 148 review these requests, the WebDAV proxy 146 sends the request to the WebDAV server 140 if the Management Modules 148 do not respond to the requests from the Client Interface 134. If the request is to be sent to the WebDAV server 140, the Tool Server 144 directs the request to a URL or network address for the WebDAV server 140. [0089] The Client Interface 134 also includes a module loader 204 to load the Process and Plan modules 136. As one skilled in the art will appreciate, Client Interface 134 may be developed so that the functionality provided by Process and Plan modules 136 is not loaded by a known module loader 204, but integrally incorporated within the element corresponding to the Client Interface 134. The Process and Plan modules 136 produce the requests to store or modify the various client files on the WebDAV storage 142. As further described below, the various types of client files include a condition model, a user profile, a resource profile, a workflow definition file, and a plan definition file. Each of these files has properties defined in accordance with the WebDAV protocol. The various types of client files follow a schema or document type definition that is known to the Tool Server 144 so that the Tool Server 144 can identify the type of client file sent by the Client Interface 134 and intercepted by the WebDAV Proxy 146. In addition, each type of client file has a unique identifier, such as a URL network address, which the Tool Server 144 may use to locate the associated client file for processing. The various types of client files are discussed in context with the general description of the Process and Plan modules 136 and also further discussed with the implementation details of creating a workflow and a project plan from the workflow. Although XML files are used to represent the client files used with methods and systems consistent with the present invention, one skilled in the art will recognize that any file type can be used to represent the client files. [0090] The Process and Plan Modules 136 include a Resource Manager Module 206, an Activity I/O Condition Designer Module 208, a Process Designer Module 210, a Project Plan Manager Module 212, and a Task Tracker Module 214. The Resource Manager Module 206 allows an enterprise affiliate with system administrative privileges or permissions, such as a project manager, to create, modify, and store a user profile for an enterprise affiliate. The user profile identifies the access control rights that are associated with the enterprise affiliate, such as whether the enterprise affiliate may create or edit or delete a project plan based on a workflow or whether the enterprise affiliate is limited to viewing an existing workflow or plan. When the Client Interface 134 sends a request to the WebDAV Server 140 to store the user profile, the Client Interface 134 may specify that the user profile be stored with a unique identifier so that the Tool Server 144 may later locate the user profile for further processing. For example, the Client Interface 134 may request that the unique identifier be a location or URL where the user profile is to be stored on the WebDAV Storage 142. If the unique identifier is stored as a property of the user profile on the WebDAV storage 142, the Client Interface 134 sends a request to the WebDAV Server 140 to set the value of the property. [0091] The Resource Manager Module 206 also allows an enterprise affiliate to create, modify, and store the role profiles that may be assigned to an activity of a workflow that is modeled using the tool 200. The role profile identifies a group of resources that may be assigned to complete a task created from the activity. The role profile is a type of client file that the Client Interface 134 may store on WebDAV storage 142 with a unique identifier (e.g., a URL for the role profile) to locate the role profile at a later time. A role profile may include a Rolename that represents a “capability” or “skill set” for the role. For example, using methods and systems consistent with the present invention, an enterprise affiliate may identify one of the following Rolenames to the Resource Manager Module 206 so that the associated role profiles are later available to assign when defining a software development process: Manager, Analyst, Software Architect, Software Developer, Tester, Hardware Architect, and Editor. [0092] In addition to the above, the Resource Manager Module 206 further allows an enterprise affiliate to create, modify, and store the resource profiles (e.g., the person, equipment, or systems, such as a development facility) that may be assigned to a task of a plan created from a workflow. The resource profile includes a resource ID and a unique identifier for the role profile so that the Client Interface 134 may communicate to the Tool Server 144 that the identified resource has skills or capabilities corresponding to the role profile. For example, when the resource is a person, the Tool Server 144 may recognize that the person can play a given role (e.g., Analyst) in a specific activity (e.g., Requirements Analysis) in a workflow (e.g., Software Development Process) based on the skills or capabilities required by the role assigned to the activity to be performed. [0093] The Activity I/O Condition Designer Module 208 allows an enterprise affiliate, such as a manager, to define a condition model, i.e., an input condition or an output condition, for an activity of a workflow. The Activity I/O Condition Designer Module 208 stores the condition model with a unique identifier so that the Tool Server 144 may later locate the condition model for processing, such as when a task of a plan is created from the activity of the workflow, as explained below. [0094] As discussed above, there are two types of workflows: a document workflow and a task workflow. Similarly, there are two types of conditions: a document-type condition and a logic-type condition. The Activity I/O Condition Designer Module 208 allows the enterprise affiliate to create a condition model based on one of these two condition types. The Activity I/O Condition Designer Module 208 also allows the enterprise affiliate to assign a document-type condition model or a logic-type condition model to an activity when creating the activity in a workflow. Each document-type and logic-type condition model has properties defined by the enterprise affiliate that created the respective condition model using the Activity I/O Condition Designer Module 208. [0095] The properties of the document-type condition model include a location property (e.g., a URL) identifying the location of the document or artifact being monitored. Thus, when executing a task based on an activity, the Client Interface 134 uses the location property to notify the resource responsible for the task where to find the document or artifact so that the resource may complete its task. [0096] Another property of the document-type condition model is a state property that indicates the allowable states of the document or artifact. For example, the document may have the states “DRAFT” and “APPROVED.” When creating the workflow, the enterprise affiliate assigns one of these allowable states as a condition for entry into or exit from the activity (or the task created from the activity). When the task is activated, the Workflow Engine 222 evaluates whether the state property of the document condition satisfies the input or output condition of the activated task before starting or closing the task. [0097] When creating a logic-type condition model, Activity I/O Condition Designer Module 208 allows the enterprise affiliate to define the properties shown in Table 1. TABLE 1 Property Description Name The name used to identify the condition. Description A description of the condition. When to This section identifies when and/or how Check often the condition should be checked. Abs. Time The condition is checked when this absolute time (calendar time) arrives. Period Integer expression in Javascript that defines the periodicity of condition check, where a “1” means once a minute. (If absolute time is also specified, then the condition should be checked when the absolute time arrives and periodically thereafter.) URL The condition is checked after URL Change undergoes a property or content change. Task The condition is checked when the task Change that is specified during plan creation changes its state (e.g., starts, finishes). Any The condition is checked when any HTTP Request request is detected. Script The script to run when the condition is met. The script must return “true” or “false” (a Boolean). Script is an extensible method for users to enter in ad hoc logic. [0098] When a plan is created from a workflow, the Client Interface 134 uses the logic-type condition model to generate a logic-type condition for entry/exit and the script (e.g., logic element) to be performed to determine if the condition is met. For example, the enterprise affiliate may indicate to the Activity I/O Condition Designer Module 208 that the condition is to check if the task is complete and that the logic to be performed is to check the status property of the task. In this case, the user or resource assigned to this task must notify the Client Interface 134 that the task is complete. In another example, the enterprise affiliate may indicate to the Activity I/O Condition Designer Module 208 that the condition is to check if the task is complete and that the logic to be performed is to check for the existence of a file in a specific directory folder on WebDAV Storage 142 in order to determine if the task is complete. In this case, the user or resource assigned to this task must create or move a file into the specific directory folder to indicate that the task is complete. [0099] The Process Designer Module 210 allows an enterprise affiliate to create, modify, and store a workflow. When the enterprise affiliate indicates to Process Designer Module 210 that the modeled process is to be saved, Process Designer Module 210 produces a workflow definition file based on the modeled workflow object. Client Interface 134 then sends as the workflow definition file as a client file to WebDAV Server 140 to be stored on WebDAV Storage 142. Each workflow definition file produced by Process Designer Module 210 includes a unique identifier (e.g., a URL for the workflow definition file) so that Tool Server 144 may later locate the workflow definition file corresponding to the modeled workflow for further processing. [0100] Project Plan Manager Module 212 allows an enterprise affiliate to create and activate a project plan from a workflow definition file. In general, upon request to create a project plan, Project Plan Manager Module 212 sends a query message to the WebDAV Server 140 for the workflow definition files contained in WebDAV Storage 142. As further described below, Project Plan Manager Module 212 receives the workflow definition files, allows the enterprise affiliate to select one of the workflow definition files to create a project plan, and then produces a plan definition file based on the selected workflow definition file. When instructed to save the plan by the enterprise affiliate, Project Plan Manager Module 212 sends the plan definition file as a client file to WebDAV Server 140 to be stored on WebDAV Storage 142. Each plan definition file produced by Process Designer Module 210 includes a unique identifier (e.g., a URL for the plan definition file) so that Tool Server 144 may later locate the workflow definition file corresponding to the modeled workflow for further processing. [0101] The Task Tracker Module 214 allows an enterprise affiliate to view the tasks of an activated project plan that are assigned to a specific resource, to activate or start a task of the project plan (e.g., indicate actual start time to Client Interface 134), to open or check-out a document artifact needed to accomplish the task, to close or check-in the document artifact after accomplishing the task, and to indicate that the task is completed. [0102] The Tool Server 144 includes a module loader 216 to load the Management Modules 148. Similar to the Client Interface 134, the Tool Server 144 may be developed so that the functionality provided by Management Modules 148 is not loaded by a known module loader 216, but integrally incorporated within the element corresponding to the Tool Server 144. Management Modules 148 include a User Authorization Module 218, a Resource/Role Management Module 220, and a Workflow Engine 222. The Workflow Engine 222 includes a Project Plan Management Module 224 and a Project Task Management Module 226. [0103] When the Client Interface 134 requests access to a client file on the WebDAV Storage 142, the User Authorization Module 218 verifies that that the enterprise affiliate making the request has a user profile on the WebDAV Storage 142 with the proper authorization or permission to access the requested client file. The User Authorization Module 218 may be connected to a Light Directory Access Protocol (LDAP) Import Module 228, which follows a known LDAP protocol to allow the User Authorization Module 218 to obtain existing user profiles from another computer on network 108. As known to those skilled in the art, an LDAP protocol is based on “entries,” where an entry is a collection of attributes that have a “distinguished name” (DN). According to the LDAP protocol, directory entries are arranged in a hierarchical tree-like structure that reflects political, geographic, and/or organizational boundaries. For example, entries representing countries may appear at the top of the tree. The entries below the countries may represent states or national organizations. Below the states or national organizations may be entries representing people (e.g., user profiles), organizational units, printers, documents, or any other accessible entity. Each level in the hierarchical tree-like structure for the directory entries may be identified by a known standardized keyword, such as “CN” for the common name of the entry (e.g., user profile), “L” for locality name, “ST” for state or province name, “O” for organization name, “OU” for organizational unit name, and “C” for country name. The LDAP Import Module 228 uses a DN to refer to the entry unambiguously via a concatenation of the hierarchical tree-like structure. After user profiles are retrieved by the User Authorization Module 218 via the LDAP import module 228, the user profiles may then be stored on the WebDAV Storage 142 by a request from the Client Interface 134. [0104] The Resource/Role Management Module 220 reviews requests from an enterprise affiliate to assign a resource to a plan (e.g., to assign a user to a task of the plan). The Resource/Role Management Module 220 may check the resource profile corresponding to the assigned resource on the WebDAV Storage 142 to verify that the resource is not overloaded. For example, the Resource/Role Management Module 220 determines whether a resource is already assigned to another task in another plan during the same time frame, thus preventing it from being able to complete one of the tasks to which it is assigned. The Resource/Role Management Module 220 may also be connected to the LDAP Import Module 228 to allow the Resource/Role Management Module 220 to obtain existing resource profiles from another computer on network 108. The resource profiles may also be stored on WebDAV Storage 142 by a request from Client Interface 134. [0105] The Workflow Engine 222 reviews requests to activate, deactivate, or update a plan. For example, a request to update a plan occurs if the enterprise affiliate who is an owner of a task indicates in its request that the task is complete. The Workflow Engine 222 also manages the execution of the activated plans. High-Level Process [0106] [0106]FIG. 3 depicts a flow diagram illustrating the high-level process performed by the workflow modeling and project planning integration tool in accordance with methods and systems consistent with the present invention. Initially, the tool creates or retrieves a workflow (step 302). The tool then displays the workflow (step 304). The workflow comprises a set of activities that represents the steps to be performed as part of a plan executed from the workflow. Each activity has an activity description and at least one role responsible for the activity. The activity description indicates what step is to be performed by the role. [0107] There are two types of workflows: a document workflow and a task workflow. In a document workflow, the state of one document (or, more generally, any item or artifact) is monitored by the activities of the workflow. Thus, a document workflow cannot usually have parallel activities, which would require the parallel activities to monitor the states of more than one artifact or would require the parallel activities to monitor different states of the same artifact simultaneously. The document is in one state at a time. FIG. 4 depicts an exemplary document workflow 400. As shown, the workflow 400 includes a start element 402, an end element 404, and two activities, “Step 1” 406 and “Step 2” 408. Because “Step 1” 406 occurs directly before “Step 2” 408, “Step 1” 406 is the “predecessor activity” to “Step 2” 408. Similarly, “Step 2” 408 is the “successor activity” to “Step 1” 406. The workflow 400 is used to monitor the state of Artifact 410. In particular, in “Step 1” 406, the state of Artifact 410 is “State 1” 412, in “Step 2” 408, the state of Artifact 410 is “State 2” 414, and at the end 404 of the workflow, the state of Artifact 410 is “Complete” 416. [0108] A task workflow, on the other hand, typically has no limitations regarding the number of artifacts that may be monitored or modified by each activity of the workflow to achieve or contribute to the business process goal, such as an auditing process that determines if multiple accounts are balanced properly. FIG. 5 depicts an exemplary task workflow 500. The task workflow 500 includes a start element 502, an end element 504, two serial activities 506 and 508 and two parallel activities 510 and 512. The workflow also includes two synch bars 514 and 516, which are used to connect the ends of parallel activities. Contrary to the document workflow, the task workflow allows for parallel activities. [0109] Another exemplary workflow 600 is depicted in FIG. 6. The workflow 600 includes a start element 602 and an end element 604. The first activity of the workflow 600 is “Get Parts” 606, which is followed by a logic activity, “L or Rt Handed?” 608. Logic activities have two successor activities: a “default activity” and a “non-default activity.” As the name implies, the workflow generally follows the path of the default activity unless a condition is met in the logic activity, as discussed in detail below. In FIG. 6, the default activity is “Right” 610. The non-default activity is “Left” 612, which is followed by another activity “Left Special” 614. The default path is represented as a solid connector 616 while the non-default path is represented as a dotted connector 618. One skilled in the art, however, will recognize that any visible difference in the connectors, e.g., a change in type, color, shading, labeling, etc., may be used to represent both the default path as well as the non-default path. Both the default activity 610 and the non-default activities 612 and 614 are followed by another activity, “Complete Assembly” 620. In addition, though we show only two paths (616 & 618) out of the decision block 608, there could be any number of exit paths (not shown). [0110] Returning to FIG. 3, the next step performed by the tool is to create a plan from the workflow (step 306). Each activity in the default path of the workflow generally corresponds to a task in the plan. The task identifies the scheduled start and stop times for the task. The tool then displays the plan (step 308). For example, the plan created from the workflow 400 depicted in FIG. 4 is shown in FIG. 7. The plan 700 includes two tasks 702 and 704 that correspond to the two activities 406 and 408 from the workflow 400. The first task 702 is scheduled to begin at 9 a.m. 706 on Aug. 1, 2001 (not shown), and end at 6 p.m. 708 on the same day. The second task 704 is scheduled to begin at 9 a.m. 710 on Aug. 2, 2001 (712) and end at 5 p.m. 714 on the same day. [0111] The plan 800 created from the workflow 500 depicted in FIG. 5 is shown in FIG. 8. The plan 800 includes two serial tasks 802 and 804 that correspond to the two serial activities 506 and 508 from the workflow 500. The plan 800 also includes two parallel tasks 806 and 808 that correspond to the two parallel activities 510 and 512 from the workflow 500. As shown in FIG. 8, “Serial 1” task 802 is scheduled to begin at 9 a.m. 810 on Aug. 1, 2001 (812) and end at 5:30 p.m. 814 on the same day. The parallel tasks 806 and 808 are scheduled to start at the completion of the “Serial 1” task 802, and are scheduled to end at 6 p.m. 816 on Aug. 2, 2001 (818). The “Serial 2” task 804 is scheduled to begin upon completion of the parallel tasks 806 and 808 and is scheduled to end at 6 p.m. 820 on Aug. 3, 2001 (822). [0112] The plan 900 created from the workflow 600 depicted in FIG. 6 is shown in FIG. 9. The plan 900 includes a task 902 corresponding to the activity “Get Parts” 606, followed by a task 904 corresponding to the activity “L or Rt Handed?” 608. The following task 906 corresponds to the activity “Right” 610. The final task 908 corresponds to the activity “Complete Assembly” 620. The plan 900 depicts the default path, and does not include any of the tasks corresponding to the non-default path. Although the start and end times are not depicted in the plan 900 shown in FIG. 9, each task has a scheduled start and stop time. In addition, the tool 200 requires that an enterprise affiliate assign a resource to each task, as described below. [0113] Returning to the high-level process of FIG. 3, the tool then activates the plan (step 310). Next, the tool manages the execution of the activated plan (step 312). The tool also modifies the display of the plan as each task is executed (step 314). The tool then determines whether the execution of the plan is complete (step 316). If the execution of the plan is complete, processing ends. Otherwise, processing continues to step 312. [0114] For the exemplary plan 700 depicted in FIG. 7, upon activation, the first task 702 begins execution. The tool depicts the executing task 1002 by darkening the outer borders of the block representing the task 1002, as depicted in the plan 1000 shown in FIG. 10. After completion of the task, the tool depicts the executed task 1102 as a darkened block in the plan 1100, as shown in FIG. 11. At this point, the second task 1104 begins execution, as indicated by the darkened outer borders of the task 1104. Finally, after both tasks 1102 and 1104 of the plan 1100 have been executed, both tasks 1202 and 1204 are depicted as darkened blocks in the plan 1200, as shown in FIG. 12. In this embodiment, the tool represents an executing task with darkened borders and represents an executed task as a darkened block. One skilled in the art, however, will recognize that any visible change in the blocks representing the tasks, e.g., a change in shape, color, shading, labeling, etc., may be used to represent the tasks in their various states. For example, in another implementation, color may be used to indicate active tasks; for example a gray rectangle may be used behind the task to indicate an actual activity since the actual dates may not coincide with the dates of the planned task. Thus, the representation of the tasks used in the methods, systems, and articles of manufacture consistent with the present invention are not limited to those used in the present embodiment. [0115] The activation and execution of the tasks of the plan 800 depicted in FIG. 8 are shown in FIGS. 13-16. FIG. 13 depicts the state of the plan 1300 while the “Serial 1” task 1302 is executing. FIG. 14 depicts the state of the plan 1400 after execution of the “Serial 1” task 1402, while the “Parallel 1” and the “Parallel 2” tasks 1404 and 1406 are executing. FIG. 15 depicts the state of the plan 1500 after execution of the “Serial 1” task 1502 and the “Parallel 1” and the “Parallel 2” tasks 1504 and 1506, while the “Serial 2” task 1508 is executing. Finally, FIG. 16 depicts the state of the plan 1600 after execution of the tasks 1602, 1604, 1606, and 1608. [0116] As discussed above, FIG. 9 represents a plan 900 created from a workflow 600 having a logic block 608. The activation and execution of the tasks of the plan 900 following the default path are shown in FIGS. 17-21, while the activation and execution of the tasks of the plan 900 following the non-default path are shown in FIGS. 22-27. [0117] [0117]FIG. 17 depicts the state of the plan 1700 while the “Get Parts” task 1702 is executing. FIG. 18 depicts the state of the plan 1800 after the execution of the “Get Parts” task 1802, while the “L Or Rt Handed?” logic task 1804 is executing. The logic task may pop up a dialog (not shown) to prompt the resource assigned to this task to provide an answer for this “left or right-handed” question. In addition, the tool allows the question to be “answered” by running a logic script. This script may examine properties of an indicated artifact or it may execute a separate program on a separate system to compute the answer. Upon selection of the default path, the plan 1900 shown in FIG. 19 depicts both the “Get Parts” task 1902 and the “L Or Rt Handed?” logic task 1904 in executed states, while the “Right” task 1906 is depicted in an executing state. After the execution of the “Right” task 1906 is complete, the state of the plan 2000 is depicted in FIG. 20 with the “Get Parts” task 2002, the “L Or Rt Handed?” logic task 2004, and the “Right” task 2006 in executed states and with the “Complete Assembly” task 2008 in an executing state. Finally, upon completion of the “Complete Assembly” task 2008, the state of the plan 2100 after execution of the tasks 2102, 2104, 2106, and 2108 is complete is depicted in FIG. 21. [0118] Alternatively, if the non-default path is to be chosen, the execution of the plan is initially the same as when the default path is chosen. Thus, as depicted in FIG. 22, the plan 2200 begins with the execution of the “Get Parts” task 2202. After completion of the “Get Parts” task 2202, the plan 2300 shown in FIG. 23 depicts the “Get Parts” task 2302 in an executed state while the “L Or Rt Handed?” task 2304 is shown in an executing state. At this point, the resource assigned to choose the default or the non-default path chooses the non-default path, thus completing the execution of the “L Or Rt Handed?” task 2404, as indicated in FIG. 24. Upon selection of the non-default path, the tool 200 modifies the plan 2400 to correspond to the non-default path of the corresponding workflow. The plan 2400 depicts the tasks included in the non-default path. Thus, the plan 2400 includes the “Left” and “Left Special” tasks 2406 and 2408 rather than the “Right” task 2306, which is depicted in FIG. 23 before the non-default path was chosen. As shown in FIG. 24, the “Left” task 2406 is executing. FIG. 25 depicts the plan 2500 after the “Get Parts” task 2502, the “L Or Rt Handed?” logic task 2504, and the “Left” task 2506 have been executed, while the “Left Special” task 2508 is executing. Continuing with the execution of the plan, FIG. 26 depicts the state of the plan 2600 after the “Get Parts” task 2602, the “L Or Rt Handed?” logic task 2604, the “Left” task 2606, and the “Left Special” task 2608 are done executing, while the “Complete Assembly” task 2610 is executing. Finally, FIG. 27 depicts the state of the plan 2700 after completion of the tasks 2702, 2704, 2706, 2708, and 2710. Retrieving Or Creating A Workflow [0119] FIGS. 28A-C depict a flow diagram illustrating an exemplary process for retrieving or creating a workflow, i.e., step 302 in FIG. 3. Initially, the tool 200 determines whether to use an existing process or workflow group (step 2802). A workflow group is a collection of workflows (e.g., a directory or folder containing the collection of workflows) created by the Client Interface 134 on WebDAV Storage 142. Each workflow group is created by the Client Interface 134 on WebDAV Storage 142 with the “workflow group” property as explained further below. When creating a workflow, the Client Interface 134 allows the enterprise affiliate to store the workflow within an identified workflow group so that any enterprise affiliate using the Client Interface 134 is able to easily identify related workflows using a hierarchical relationship. For example, software-related workflows may be stored within the same workflow group so that an enterprise affiliate is able to quickly locate a desired workflow in order to create a corresponding plan using the Client Interface 134. One skilled in the art will appreciate that Client Interface 134 may store a workflow on WebDAV Storage 142 without associating the workflow with a workflow group. [0120] The tool 200 receives user input from an enterprise affiliate with system administrative privileges or permissions, such as a process designer or a project manager, to determine whether to retrieve an existing workflow group or to create a new workflow group. If the tool 200 determines that it will use an existing workflow group, the tool 200 receives an identification of the workflow group from the enterprise affiliate (step 2804). In one implementation, the Client Interface 134 may retrieve the identifications for the workflow groups on the WebDAV Storage 142 by requesting that the folders or directories on WebDAV Storage 142 having a “workflow” property be returned by the WebDAV Server 140. The Client Interface may use any known method in accordance with WebDAV protocol to request that the WebDAV Server 140 return any directory or folder on WebDAV Storage 142 that corresponds to a workflow group. The tool 200 may then display the available workflow groups to allow the enterprise affiliate to select one of the available workflow groups. For example, as shown on the user interface 2900 depicted in FIG. 29, the tool 200 may display a hierarchical view 2902 of an identified workflow group 2904 stored on the root directory 2906 of WebDAV Storage 142. Alternatively, the enterprise affiliate may enter the identification of the desired workflow group to the tool 200 for retrieval. Using the identification, the tool 200 then retrieves the workflow group (step 2806). [0121] If the tool 200 determines that a new workflow group will be created, the tool 200 receives the name of the workflow group from the enterprise affiliate (step 2808). For example, the enterprise affiliate may request a new workflow group by clicking on “Process Designer” button 2908 of the user interface 2900 depicted in FIG. 29. The enterprise affiliate may, alternatively, use any known data input technique, such as an icon or keyboard input, to indicate the request to the tool 200. Upon selecting the “Process Designer” button 2908, the tool 200 displays an exemplary user interface 3000 depicted in FIG. 30 for receiving a new workflow group identification 3002 via keyboard input from an enterprise affiliate using computer 102 a or 102 n. [0122] After receiving the new workflow group identification, the tool 200 creates a new workflow group in storage (step 2810). For example, the tool 200 may create the workflow group on WebDAV Storage 142. To generate a new workflow group on WebDAV Storage 142, the Client Interface 134 sends the WebDAV Server 140 a request to create a new collection or folder on WebDAV Storage 142 with the same identification as the new workflow group identification 3002. In accordance with WebDAV protocol, the Client Interface 134 receives a response from the WebDAV Server 140 confirming that the new workflow group folder was created on WebDAV Storage 142. As previously discussed, when a new collection or folder is created using the WebDAV protocol, the WebDAV properties (e.g., “date of creation,” “property name” and “lockdiscovery” properties) are created and stored in association with the new directory by the WebDAV Server 140. Thus, when generating the new workflow group, the Client Interface 134 also sets the “property name” of the new workflow group to be “workflow group” so that the Client Interface may subsequently use known WebDAV methods, such as “PropFind,” to retrieve the identification of each workflow group on WebDAV Storage 142. [0123] After retrieving an existing workflow group or creating a new workflow group, the tool 200 determines whether to use an existing workflow (step 2812). The tool 200 receives user input from an enterprise affiliate with appropriate privileges or permissions to determine whether to retrieve an existing workflow or to create a new workflow. If the tool 200 determines that it will use an existing workflow, the tool 200 receives an identification of the workflow from the enterprise affiliate (step 2814). In one implementation, the Client Interface 134 may retrieve the identifications for the workflows in the selected workflow group and display the available workflows to allow the enterprise affiliate to select one of the available workflows. Alternatively, the enterprise affiliate may enter the identification of the desired workflow to the tool 200 for retrieval. Using the identification, the tool 200 then retrieves the workflow (step 2816). [0124] If the tool 200 determines that a new workflow will be created, the tool 200 receives the name of the workflow from the enterprise affiliate (step 2818). For example, the enterprise affiliate may request a new workflow by clicking on the desired workflow group 3102 and selecting the “New Process” option 3104 from a pull-down menu 3106 on the user interface 3100 depicted in FIG. 31. The enterprise affiliate may, alternatively, use any known data input technique, such as an icon or keyboard input, to indicate the request to the tool 200. Upon selecting the “New Process” option 3104, the tool 200 may display the exemplary dialog box 3200 depicted in FIG. 32 to the enterprise affiliate. The enterprise affiliate may then enter the name of a new workflow 3202. After receiving the name for the workflow, the tool 200 creates the workflow in storage (step 2820). [0125] FIGS. 33A-C depict an exemplary workflow definition file 3300 that is produced by the tool 200 when the workflow 600 depicted in FIG. 6 is created. The name 3302 of the workflow, “Logic Branch Project,” is identified in the workflow definition file 3300. Also, as shown in the definition file 3300, the workflow 600 does not have a workflow group 3304. The element 3306 in the workflow definition file 3300 represents the “Get Parts” activity 606. Similarly, the element 3308 (FIG. 33C) represents the “L or Rt Handed?” logic activity 608, the element 3310 represents the “Right” activity 610, the element 3312 represents the “Left” activity 612, the element 3314 represents the “Left Special” activity 614, and the element 3316 represents the “Complete Assembly” activity 620. The start element 602 is represented by the element 3318, and the end element 604 is represented by the element 3320. [0126] The next step performed by the tool 200 is to receive an indication of the type of activity to be created for the workflow (step 2822 in FIG. 28B). As discussed above, the activity may be a standard activity or a logic activity. For example, the workflow 3402 depicted in the user interface 3400 of FIG. 34 includes five standard activities 3404, 3406, 3408, 3410, and 3412. The workflow 3402 also includes one logic activity 3414. The selection of the type of activity may be made by clicking on the icon for a standard activity 3416 or the icon for the logic activity 3418. Alternatively, any known data input technique, such as a pull-down menu or keyboard input, may be used to select the type of activity. [0127] After receiving an indication of the type of activity, the tool 200 receives the name of the activity (step 2824). The names of the activities depicted in the workflow 3402 are included with the activity. Thus, the name of activity 3404 is “Assignment,” the name of activity 3406 is “Analysis,” etc. [0128] Returning to the example workflow 600 depicted in FIG. 6, the name of the first activity 606 is “Get Parts,” which is identified by the element 3322 in the workflow definition file 3300 of FIG. 33. Similarly, the name of the logic activity 608 is “L or Rt Handed?,” which is identified by the element 3324. The name of the activity 610 is “Right,” as identified by the element 3326. The name of the activity 612 is “Left,” as identified by the element 3328. The name of the activity 614 is “Left Special,” as identified by the element 3330. Finally, the name of the activity 620 is “Complete Activity,” as identified by the element 3332. [0129] After receiving a name for the activity, the tool 200 receives an indication of the role responsible for the activity (step 2826). As discussed above, the Client Interface (via Resource Manager Module 206) allows an enterprise affiliate to identify a role or role profile that may be assigned to an activity of the workflow. A role profile includes a Rolename that represents a “capability” or “skill set,” which is needed to perform a task of a plan created from the workflow, where the task corresponds to the activity of the workflow. For example, FIG. 35 depicts a user interface 3500 displayed by the Client Interface to receive a role profile. In the implementation shown in FIG. 35, the Client Interface receives a Rolename 3502 (e.g., “Project Manager”) for the role profile via the enterprise affiliate clicking on an “Add” button 3504 and then entering Rolename 3502 in a dialog box 3506 that is displayed by the Client Interface. In another implementation, the Client Interface may also receive as additional entries (not shown) to dialog box 3506 a skill and an associated skill level for Rolename 3502 as part of this role profile. For example, the enterprise affiliate may indicate to the Client Interface via the additional entries to dialog box 3506 that the Rolename 3502 of “Project Manager” be associated with a skill entitled “Object-oriented software programming” and with a skill strength of “7” on a scale of 10. Assuming an enterprise affiliate is developing a workflow for producing a software development tool, the enterprise affiliate may assign to activities in the workflow the “Project Manager” role profile with this skill and skill level. Thus, when a plan is created from this workflow, a resource having the appropriate skill and skill level will automatically be assigned by the Client Interface to tasks corresponding to the activities with the “Project Manager” role assignment. [0130] The tool 200 stores the role profiles in association with the selected workflow activity on WebDAV Storage 142. The tool 200 saves significant costs in developing multiple workflows by allowing the enterprise affiliate to store the role profiles in association with the selected workflow activity on WebDAV Storage 142 so that the role profiles may be available for the enterprise affiliate to assign to an activity of another workflow that is also related to the selected workflow activity. In one implementation, the Client Interface stores the role profiles in a single role definition file (not shown) on WebDAV Storage 142. In another implementation, the Client Interface stores the role profiles in separate files (not shown) on WebDAV Storage 142. Each separate file has a name that is the same as the received Rolename 3502. In this implementation, using known WebDAV protocol, the Client Interface defines an associated WebDAV property having a common name, such as “role profile,” so that the Client Interface may later retrieve the role profiles stored on WebDAV storage. [0131] The role profiles may also be stored with the workflow definition file. As shown in the workflow definition file 3300 depicted in FIG. 33, the role profile 3334 for the “Get Parts” activity 606 indicates that the role responsible for the activity is “Assembler” 3336. Similarly, the role profile 3338 for the “L or Rt Handed?” activity 608 indicates that the role responsible for the activity is “Assembler” 3340. The role profile 3342 for the “Right” activity 610 indicates that the role responsible for the activity is “Assembler” 3344. The role profile 3346 for the “Left” activity 612 indicates that the role responsible for the activity is “Assembler” 3348. The role profile 3350 for the “Left Special” activity 614 indicates that the role responsible for the activity is “Assembler” 3352. Finally, the role profile 3354 for the “Complete Assembly” activity 620 indicates that the role responsible for the activity is “Assembler” 3356. [0132] The next step performed by the tool 200 is to determine whether the activity has any predecessor activities (step 2828). If the activity does have a predecessor activity, the tool 200 receives an indication of the predecessor activities from the workflow definition file (step 2830). After checking for any predecessor activities and/or receiving the predecessor activities, the tool 200 determines whether the activity has any successor activities (step 2832). If the activity has a successor activity, the tool 200 receives an indication of the successor activities from the workflow definition file (step 2834). In the user interface 3400 of FIG. 34, the “Path” icon 3420 is used to connect the predecessor activity to the successor activity. For example, in the workflow 3402, a path 3422 was drawn from the “Assignment” activity 3404 to the “Analysis” activity 3406. Thus, the “Assignment” activity 3404 is the predecessor activity to the “Analysis” activity 3406, and the “Analysis” activity 3406 is the successor activity to the “Assignment” activity 3404. Alternatively, a “Vertical Fork/Join” icon 3424 or a “Horizontal Fork/Join” activity may be used to connect more than one predecessor activities to a successor activity, or to connect a predecessor activity to more than one successor activities. [0133] In the workflow 600 depicted in FIG. 6, the activity ID 3358 of the “Get Parts” activity 606 is “10.” The predecessor 3360 to the “Get Parts” activity 606 has an ID of “11” 3362, which corresponds to the start element 602. The successor 3364 to the “Get Parts” activity 606 has an ID of “1522” 3366, which corresponds to the “L or Rt Handed?” logic activity 608. The predecessor 3368 to the “L or Rt Handed?” logic activity 608 has an ID of “10” 3358, which corresponds to the “Get Parts” activity 606. Because the “L or Rt Handed?” activity 608 is a logic activity, it has both a default successor and a non-default successor. Thus, the workflow definition file 3300 identifies two paths out of the “L or Rt Handed?” logic activity 608, one path 3370 has an ID of “1525” 3372, which corresponds to the “Right” activity 610, and the other path 3374 has an ID of “1523” 3376, which corresponds to the “Left” activity 612. The element representing the “L or Rt Handed?” logic activity 608 also identifies that the default path 3378 has an ID of “1525” 3372, which corresponds to the “Right” activity 610. The predecessor 3380 to the “Right” activity 610 and the predecessor 3382 to the “Left” activity 612 have an ID of “1522” 3366, which corresponds to the “L or Rt Handed?” logic activity 608. The remaining predecessor and successors follow this convention. [0134] After checking for any successor activities and/or receiving the successor activities, the tool 200 determines whether the activity has any on-entry scripts (step 2836). An on-entry script is a step to be performed by the tool 200 upon entry into the activity. For example, the on-entry script may send an email notifying an interested user about the activity being started. The on-entry script may also send a dialog box to an enterprise affiliate to obtain data in real-time, or send a request to a separate device to gather input, e.g., by sending a message to a computer to receive data files. Other examples of on-entry scripts include checking stock levels and issuing reorder commands, if necessary, or paging the user assigned to perform the activity. If the activity has an on-entry script, the tool 200 receives an indication of the on-entry scripts (step 2838). After checking for any on-entry scripts and/or receiving the on-entry scripts, the tool 200 determines whether the activity has any on-exit scripts (step 2840 in FIG. 28C). An on-exit script is a step to be performed by the tool 200 upon exiting the activity. For example, the on-exit script may send an email notifying an interested user about the end of an activity. Other examples of on-exit scripts include sending a message to another device to have the other device perform enterprise application integration, notifying a downstream consumer about the activity so that the consumer knows what is coming, and placing an activity on a user's personal calendar. If the activity has an on-exit script, the tool 200 receives an indication of the on-exit scripts (step 2842). For example, the “Complete Assembly” activity 620 depicted in FIG. 6 includes both an on-entry script 3384 as well as an on-exit script 3386. Upon entering the task created from the “Complete Assembly” activity, the tool 200 sends an email to the owner indicating that the “Debugging period started” 3388. Prior to exiting the task created from the “Complete Assembly” activity, the tool 200 sends an email to the owner indicating that the “Debugging finished” 3390. [0135] After checking for any on-exit scripts and/or receiving the on-exit scripts, the tool 200 determines whether the activity has any input (i.e., begin or starting) conditions (step 2844). If the activity has an input condition, the tool 200 receives an indication of the input conditions (step 2846). Example input conditions are to expect an artifact required for the task to have a specific status. After checking for any input conditions and/or receiving the input conditions, the tool 200 determines whether the activity has any output (i.e., exit or ending) conditions (step 2848). An example exit condition could be to automatically check the quality of an artifact generated by the task. If the artifact meets quality standards, the task completion occurs; otherwise, the task completion is rejected and the user is informed that more quality is required. If the activity has an output condition, the tool 200 receives an indication of the output conditions (step 2850). The output condition 3391 for the “Get Parts” activity 606 has an ID of “1527” 3392 (FIG. 33B), and is a document-type condition, as indicated by the “linkable1” identity 3393 in the element 3394 representing the condition 3391. In general, based on the condition 3391, the tool 200 (in particular, the Workflow Engine 222) monitors the state of an artifact for an activated “Get Parts” task created from the “Get Parts” activity 606 until the state of the artifact is the “INITIAL” state 3395 before the tool 200 continues with the next task in the plan. Similarly, the output condition 3396 for the “Right” activity 610 has an ID of “1533” 3397. The output condition 3396 for the “Right” activity 610 is also a document-type condition, as indicated by the “linkable1” identity 3398. This condition 3396 signals the tool 200 to monitor the state of an artifact until it is in the “RIGHT” state 3399. [0136] [0136]FIG. 36 depicts an exemplary user interface 3600 displayed by the Client Interface 134 to include either a document-oriented 3602 or a script (or logic)-oriented 3604 condition. As shown in FIG. 36, the Client Interface 134 may receive the request to add a condition to the activity via a pull-down menu selection 3606. The enterprise affiliate may, however, use any known data input technique to request that a condition be added to an activity, such as an icon or keyboard input, to indicate the request to the Client Interface 134. If the enterprise affiliate selects a document-oriented condition, the enterprise affiliate may be presented with the user interface 3700 depicted in FIG. 37 to identify the properties of the condition to the Client Interface 134. The condition properties 3702 include condition-name property 3704 for the document-type condition model. In the example shown in FIG. 37, the Client Interface 134 receives the condition-name property 3704 via a keyboard input by the enterprise affiliate. The Client Interface 134 uses the condition-name property 3704 to distinguish the condition model to be created from other condition models stored on WebDAV Storage 142. The Client Interface 134 may store the document-type condition model file on WebDAV Storage 142 having the same name as the condition-name property 3704. In another implementation, the Client Interface 134 may store the condition-name property 3704 as a WebDAV property stored in association with the document-type condition model file on WebDAV Storage 142. [0137] The Client Interface 134 also receives a link-parameter property 3706 as one of Condition properties 3702 for the document-type condition model to be created by the Client Interface. As shown in FIG. 37, the enterprise affiliate may identify link-parameter property 3706 to the Client Interface via keyboard input. Link-parameter property 3706 may be used by an enterprise affiliate in an activity-related script that is identified to the Client Interface during the creation of a workflow as described below. Thus, when executing the activity-related script in a task of a plan created from the workflow, the Workflow Engine 222 in FIG. 2 is able to locate the corresponding document condition so that the corresponding input or output condition may be evaluated by the Workflow Engine 222. [0138] The Client Interface 134 may also receive a description property 3708 as one of Condition properties 3702 for the document-type condition model to be created by the Client Interface. When creating a workflow as described below, the Client Interface may display description property 3708 in association with condition-name property 3704 to allow an enterprise affiliate to effectively choose whether the document-type condition model should be assigned to an activity of the workflow. [0139] The Client Interface may also receive one or more triggering-event properties 3710 for the document-type condition model. In the example shown in FIG. 37, the Client Interface may receive the triggering-event properties as one of the condition properties 3702 for the document-type condition model to be created by the Client Interface. Triggering-event properties 3710 indicate to the Workflow Engine 222 when to check the state property of a document condition as an entry or exit condition of an activated task. Triggering-event properties 3710 may include a “Write into document” event 3712, a “Change property of document” event 3714, a “Put document into repository” event 3716, a “copy or move into document” event 3718, and a “delete document” event 3720. [0140] Next, the Client Interface 134 receives document state properties 3722 as one of the Condition properties 3702 for the document-type condition model to be created by the Client Interface. Document state properties 3722 identify possible values for a state property of a document condition that is created using the document-type condition model. As further explained herein, an enterprise affiliate who has been identified as the responsible owner of an activated task may change the state property of a document condition (e.g., from “DRAFT” to “APPROVED”) using the Client Interface, which sends a request to WebDAV Server 140 in FIG. 2 to set the state property of the document condition as indicated by the enterprise affiliate. Workflow Engine 222 in FIG. 2 may then check the state property of the document condition on WebDAV Storage 142 when triggering-events 3710 occur. [0141] The Client Interface also receives a location property 3724 as one of Condition properties 3702 identified by the enterprise affiliate for the document-type condition model. [0142] Location property 3724 is a unique identifier or URL for a document template that the Client Interface uses to create the document condition that is then stored by the Client Interface on WebDAV Storage 142. Location property 3724 may be a location on secondary storage device 116 of computer 102 a or a location on WebDAV Storage 142. As described in greater detail below, the document condition is created by the Client Interface 134 when a plan is instantiated or created from a workflow having an activity with an entry or exit condition created using the document-type condition model. Finally, the Client Interface receives application property 3726 as one of Condition properties 3702 identified by the enterprise affiliate for the document-type condition model. Application property 3726 is a unique identifier or URL for an application, such as Microsoft Word, that the Client Interface may run to create an instant of the document template that may be found at the location specified by location property 3724. The Client Interface uses the instant of the document template to create and store the document condition on WebDAV Storage 142. [0143] [0143]FIG. 38 depicts an exemplary user interface 3800 displayed by the Client Interface 134 to receive the condition properties 3802 for a logic-type condition model that is to be created by the Client Interface 134. The condition properties 3802 include a condition-name property 3804 for the document-type condition model. In the example shown in FIG. 38, the Client Interface 134 receives the condition-name property 3804 via a keyboard input by the enterprise affiliate. The Client Interface 134 uses the condition-name property 3804 to distinguish the logic-type condition model to be created from other condition models stored on WebDAV Storage 142. As described below, the Client Interface 134 stores a logic-type condition model file on WebDAV Storage 142 that has the same name as condition-name property 3804. In another implementation, the Client Interface 134 may also store condition-name property 3804 as a WebDAV property stored in association with the logic-type condition model file on WebDAV Storage 142. [0144] In the example shown in FIG. 38, the Client Interface 134 may receive a description property 3806 as one of the Condition properties 3802 for the logic-type condition model to be created by the Client Interface 134. When creating a workflow as described below, the Client Interface 134 may display the description property 3806 in association with the condition-name property 3804 to allow an enterprise affiliate to effectively choose whether the logic-type condition model should be assigned to an activity of the workflow. [0145] The Client Interface 134 may also receive one or more triggering-event properties 3808 for the logic-type condition model as one of the condition properties 3802 for the logic-type condition model to be created by the Client Interface 134. Triggering-event properties 3808 indicate to the Workflow Engine 222 when to check an entry or exit condition of an activated task. Triggering-event properties 3808 include: an “Absolute time” event 3810, a “Period” event 3812, a “URL change” event 3814, a “Task change” event 3816, and “any http request” event 3818. “Absolute time” event 3810 identifies a trigger for a specific data and time from the start time of the activated task. “Period” event 3812 identifies a trigger for a specific unit of time, such as once every minute. “URL change” event 3814 identifies a trigger when the contents of the directory or folder located at the URL changes. “Task change” event 3816 identifies a trigger for any time the activated task definition file or associated property changes. [0146] For example, when an enterprise affiliate that is responsible for the task uses the Client Interface 134 to identify that the task is complete, the Client Interface 134 in response sends a request to the WebDAV Server 140 to set the status property of the activated task to “FINISHED.” As part of the processing for managing an activated plan as described below, the Workflow Engine 222 will receive this request before the WebDAV Server 140 and interpret the request as an example of a “Task change” event 3816. Similarly, “Any http request” event 3818 indicates to the Workflow Engine 222 to check the entry or exit condition of the activated task when any request is received from the Client Interface 134 that pertains to the activated task. For example, the Client Interface 134 may send a request to the WebDAV Server 140 to retrieve the activated task file so that a status of the activated task can be viewed by an enterprise affiliate. Workflow Engine 222 will receive this request before the WebDAV Server 140 and interpret the request as an example of an “Any http request” event 3818. [0147] The Client Interface 134 may also receive a script 3820 as one of the condition properties 3802 for the logic-type condition model to be created by the Client Interface 134. Script 3820 is executed by the Workflow Engine 222 when a triggering-event occurs that corresponds to one of the triggering-event properties 3808 selected by the enterprise user using the Client Interface 134. As shown in FIG. 38, Script 3820 may include a script parameter 3822, a script value 3824 for script parameter 3822, and script content 3826 that may use the script parameter 3822 initialized to the script value 3824. The enterprise affiliate may provide the script content 3826 to the Client Interface 134 via a Script Editor User Interface 3900 in FIG. 39. Script Editor User Interface 3900 is displayed by the Client Interface 134 when the enterprise affiliate actuates button 3828 on user interface 3800 shown in FIG. 38. Script content 3820 may contain any known application program interface (API) script method that would be recognizable by the target processor interpreter on computer 106, such as Java™ Virtual Machine 150 in FIG. 1. [0148] After checking for any output conditions and/or receiving the output conditions, the tool 200 determines whether there are any more activities to add to the workflow (step 2852). If there are more activities, the process continues at step 2822 for the next activity. If there are no more activities to add to the workflow, the tool 200 receives an indication of the starting point for the workflow (step 2854). Next, the tool 200 receives an indication of the ending point for the workflow (step 2856) before the process ends. [0149] [0149]FIG. 40 depicts an exemplary user interface 4000 displayed by the Client Interface 134 to receive the properties of an activity of a workflow. As depicted, the name 4002 of the activity (e.g., “Specs Development”), the duration 4004 of the activity (e.g., 1 unit) and the role 4006 responsible for the activity may be entered by the enterprise affiliate responsible for creating or modifying the workflow. In addition, the enterprise affiliate may enter an on-entry script 4008 as well as an on-exit script 4010. If the activity represents an entire other workflow, the properties of the activity also include the location 4012 of the sub-process defining the workflow. This allows an enterprise to save significant resources by providing a mechanism for reusing workflows within other workflows. Thus, workflows may be modularly built from constituent workflows. For example, the defect tracking workflow depicted in FIG. 34 can be used inside many “outer” or “higher-level” processes for software development. [0150] Creating A Plan From A Workflow [0151] FIGS. 41A-B depict a flow diagram illustrating the process of creating a plan from a workflow, i.e., step 306 in FIG. 3. At this point, the enterprise affiliate has already selected the workflow that will be used to create the plan. Initially, the tool 200 receives an indication of the plan name (step 4102). In selecting the plan name, the Client Interface 134 allows the enterprise affiliate to store the project plan within an identified project plan group so that any enterprise affiliate using the Client Interface 134 is able to easily identify related project plans. A process plan group is a collection of project plans (e.g., a directory or folder containing the collection of project plans) created by the Client Interface 134 on WebDAV Storage 142. For example, the software-related project plans may be stored within the same project plan group so that an enterprise affiliate is able to quickly locate a desired project plan in order to create a corresponding plan using the Client Interface 134. One skilled in the art will appreciate that Client Interface 134 may store a project plan on WebDAV Storage 142 without associating the project plan with a project plan group. FIG. 42 depicts an exemplary user interface 4200 used to receive a project plan group. [0152] In the implementation shown in FIG. 42, the Client Interface 134 receives a dialog box 4202 to enter the name of a new project plan group 4204 (e.g., “Software Projects”) after clicking on a “Create Group” button 4206. Alternatively, if the enterprise affiliate decides to select an existing project plan group, the tool 200 provides the enterprise affiliate with a list 4300 of available project groups from which the enterprise affiliate may choose, as depicted in FIG. 43. The tool 200 then provides the enterprise affiliate with a dialog box 4400 to enter the name 4402 of the project, as shown in FIG. 44. [0153] The next step performed by the tool 200 is to receive an indication of the working hours (step 4104). FIG. 45 depicts an exemplary timetable 4500 which the enterprise affiliate may use to identify the timetable defining a workday. As shown, the enterprise affiliate may select a timetable template 4502 with predefined working hours. The Standard Timetable 4504 includes five Working Days 4506 (Monday through Friday) and Working Hours 4508 from 8 a.m. (4510) through 12 p.m. (4512) and from 1 p.m. (4514) until 5 p.m. (4516). Alternatively, the enterprise affiliate may select a 24 Hour Timetable 4518 or an Intensive Timetable 4520, i.e., more than the Standard Timetable 4504, but less than the 24 Hour Timetable 4518. The tool 200 also receives an indication of the start date and time for the project plan (step 4106). An exemplary dialog box 4600 may be used to select the start date and time 4602 and end date and time 4604. [0154] The tool 200 then retrieves an activity from the workflow (step 4108). The tool 200 sets the start time of the task equal to the start date and time of the project plan (step 4110). Next, the tool 200 sets the end time of the task based on the start time of the task, the duration of the activity from which the task is based, and on the working hours (step 4112 in FIG. 41B). The tool 200 then receives an indication of the resource assigned to the task (step 4114). [0155] For example, FIG. 47 depicts an exemplary workflow definition file 4700 that is produced by the tool 200 when the workflow 500 depicted in FIG. 5 is created. FIG. 48 depicts an exemplary project plan definition file 4800 created from the workflow definition file 4700. The element 4702 in the workflow definition file 4700 represents the “Serial 1” activity 506. As shown, the “Serial 1” activity 506 has a duration 4704 of 9 hours. If the working hours are determined based on the “24 Hour Timetable” 4818 and the start date and time for the project plan is 9 a.m. on Aug. 1, 2001, the start time 4804 for the “Serial 1” task 4802 is 9 a.m. on Aug. 1, 2001. The end time 4806 of the task 4802 occurs 9 hours later, i.e., at 6 p.m. on Aug. 1, 2001. [0156] [0156]FIG. 49 depicts an exemplary user interface 4900 displayed by the Client Interface 134 to assign users or resources to the project and to assign these users specific roles related to the roles required by the project. The tool 200 displays a list of available users or resources 4902 (on the left), a list of the assigned users (central), and a list of the roles 4904 (on the right) in a given workflow. In this embodiment, the enterprise affiliate is allowed to selectively add or remove available resources to the project by highlighting the resource and selecting either the “Add” button 4906 or the “Remove” button 4908, respectively. Alternatively, the enterprise affiliate may add or remove the resources to the project by selecting the “Add all” button 4910 or the “Remove all” 4912 button, respectively. For each resource, the user can selectively indicate (checkboxes) which roles the user should play. Thus, the enterprise affiliate may identify to the tool 200 resources that are capable of performing the role when assigned to a task in the plan. As discussed below, the tool 200 may automatically assign a resource to a role of a task in the plan based on the identified, capable resources for the role. [0157] The properties of an activity may be modified using the exemplary user interface 5000 depicted in FIG. 50. The user interface 5000 displays the name 5002 of the activity, the duration 5004 assigned to the corresponding activity, the start date and time 5006 for the activity, the end date and time 5008 for the activity, the responsible role 5010 assigned to the corresponding activity, the responsible resource or user 5012 assigned to the task, the owners 5014 of the task, the priority 5016 of the task, the on-entry script 5018 of the task, and the on-exit script 5020 of the task. The responsible resource 5012 of the task is the resource with the authority to notify the tool 200 when the task is complete. The owner(s) 5014 of the task, on the other hand, are notified when the task is started or completed, but do not have the authority to modify the tool 200 when the task is complete. [0158] The next step performed by the tool 200 is to determine whether there are any more activities in the workflow (step 4116). If there are no more activities, the process ends. If there are more activities, the tool 200 retrieves the next activity (step 4118). The tool 200 then sets the start time of the task equal to the end time of the predecessor task (step 4120). The process then continues at step 4112. [0159] The next activities that are retrieved by the tool 200 are “Parallel 1” 510 and “Parallel 2” 512. Element 4706 and element 4708 in the workflow definition file 4700 represent these activities 510 and 512. The durations 4710 and 4712 of both of these activities is 24 hours. The start time 4812 and 4814 of these tasks 4808 and 4810 is equal to the end time 4806 of the predecessor task, i.e., 6 p.m. on Aug. 1, 2001. Because the duration 4710 and 4712 of the activities 510 and 512 is 24 hours, the end times 4816 and 4818 of these tasks 4808 and 4810 occur 24 hours later, i.e., at 6 p.m. on Aug. 2, 2001. The next activity retrieved by the tool 200 is “Serial 2” 508. The element 4714 in the workflow definition file 4700 represents this activity. The duration 4716 of the “Serial 2” activity 508 is 24 hours. The start time 4822 of the task 4820 created from the “Serial 2” activity 508 is the end time 4816 and 4818 of the predecessor task, i.e., 6 p.m. on Aug. 2, 2001. Because the duration 4716 of the “Serial 1” activity is 24 hours, the end time 4824 of the task 4820 is 6 p.m. on Aug. 3, 2001. The project plan is displayed in the Gantt chart 5100 depicted in FIG. 51. As shown, the “Serial 1” task 5102 is scheduled to execute from 9 a.m. 5104 on Aug. 1, 2001 (5106) through 6 p.m. 5108 on the same day. The “Parallel 1” task 5110 and the “Parallel 2” task 5112 are scheduled to execute from 6 p.m. 5108 on Aug. 1, 2001 (5106) through 6 p.m. 5114 on Aug. 2, 2001 (5116). Finally, the “Serial 1” task 5118 is scheduled to execute from 6 p.m. 5114 on Aug. 2, 2001 (5116) through 6 p.m. 5120 on Aug. 3, 2001 (5122). Note that an enterprise affiliate using the Client Interface 134 on the computer 102 a may create a plan from the workflow 600 at the same time that a second enterprise affiliate using the Client Interface 134 on computer 102 n creates a second plan from the workflow 600. [0160] After the project plan is created from the workflow, the plan may be activated. As depicted in FIG. 52, the enterprise affiliate may activate the project by selecting the “Activate Project” option 5202 from the pull-down menu 5200. The enterprise affiliate may, however, use any known data input technique, such as an icon or keyboard input, to indicate the request to Client Interface 134. [0161] In one implementation, the Client Interface 134 then sends an activate request to the WebDAV server 140 to change the status of the plan definition file to “Active.” As discussed further below, the Workflow Engine 222 may intercept this request and process the request in preparation for managing the execution of the activated plan. Once the plan is created and stored on WebDAV storage 142, any enterprise affiliate with appropriate privileges (e.g., project manager that “owns” the plan) may activate the plan using the Client Interface 134 from any computer 102 a and 102 n. Adding A Resource [0162] [0162]FIG. 53 depicts a flow diagram illustrating an exemplary process performed by the Client Interface 134 to add a new resource to the list of available resources. The Client Interface 134 may later assign the resource to a plan in accordance with methods and systems consistent with the present invention. Initially, the Client Interface 134 receives a request to add a new resource (step 5302). As shown in FIG. 54, the Client Interface 134 may receive the request to add a new resource via a pull-down menu selection 5402 and 5404 that is chosen by an enterprise affiliate. The enterprise affiliate may, however, use any known data input technique, such as an icon or keyboard input, to indicate the request to the Client Interface 134. [0163] Next, the Client Interface 134 determines whether the request is to import the resource information (step 5304). In the implementation shown in FIG. 54, an enterprise affiliate requests that the Client Interface 134 import a resource profile containing the resource information by choosing the pull-down menu selection 5404. Alternatively, the enterprise affiliate may request that the Client Interface 134 create the resource profile from resource information that the enterprise affiliate provides to the Client Interface 134. Thus, if the request is not to import the resource information, the Client Interface 134 receives the resource information from the enterprise affiliate (step 5306). As shown in FIG. 54, the Client Interface 134 may receive resource information 5404 for an enterprise affiliate (e.g., a user or person) that may later be assigned to a plan by the Client Interface 134 in accordance with processes described in greater detail below. The Resource Information 5404 may include a login name 5408, a resource name 5410 that the Client Interface 134 is to use when assigning the resource to a task of a plan, and an e-mail address 5412 that the Client Interface 134 or the Workflow Engine 222 may use to notify the resource of an assignment or another event. [0164] The Client Interface 134 may also receive other resource information (not shown) for other types of resources (e.g., equipment, facilities, computer systems, or other known entities) that may be assigned to any task of a plan. The other resource information may include: a resource name that the Client Interface 134 is to use when assigning the resource to a task of a plan; a resource owner name that identifies a manager or other enterprise affiliate who is responsible for the named resource; and an e-mail address for the named resource owner, which the Client Interface 134 or the Workflow Engine 222 may notify when the named resource is assigned to a task or for another associated event. [0165] Resource information 5404 may also include one or more skill identifiers that indicate one or more capabilities that a task of a plan may require for the task to be completed. Skill identifiers may include any foreseeable skill for the named resource, including a user, equipment, facilities, computer systems, or other known entities that may be assigned to any task of a plan. For example, when the named resource is an enterprise affiliate, the skill identifiers that may be identified for the enterprise affiliate may include: “Java programming,” “architecture,” or “carpentry.” When the named resource is equipment, the skill identifiers may include “punch-press,” “printing,” or “Windows NT Operating System.” Or, when the resource is another system, skills may involve the ability to execute specific functions (much like distributed or web services, “credit card validation,” “shop for best air freight shipper prices”). Resource information 5404 may also include a skill strength (not shown) for each skill identifier. The skill strength may be used by the tool to differentiate one resource from another resource when matching a resource to a role of a task in a plan. [0166] Resource information 5404 may also include an availability timetable (not shown) that indicates to the Client Interface 134 the calendar days, the hours in a weekday, and the hours in a weekend day that the named resource is available to work. Resource information 5404 may also include an assignment timetable (not shown) that has assigned calendar days. The assigned calendar days indicate to the Client Interface 134 which calendar days the named resource has been assigned to one or more tasks. In addition, the assignment timetable may include unique identifiers or URLs for the one or more tasks to which the named resource has been assigned. Thus, the Client Interface 134 or the Workflow Engine 222 may access the one or more tasks that the named resource has been assigned when performing processing for resource leveling of a plan in accordance with methods and systems consistent with the present invention. [0167] If the request is to import the resource information, the Client Interface 134 receives access information for a “Lightweight Directory Access Protocol (LDAP)” resource directory entry (e.g., a resource profile) on the network 108 of FIG. 1 (step 5308). FIG. 55 depicts an exemplary user interface 5500 showing access information 5502 received by the Client Interface 134. Access information 5502 includes an LDAP Server 5504 (e.g., “Frodo”) on the network 108, an LDAP Port 5506 for the Client Interface 134 to communicate with the LDAP Server 5504, and a resource distinguished name (DN) 5508 identifying the location on LDAP Server 5504 where the resource profile may be found. The access information 5502 may be default access information that the Client Interface 134 retrieves from a configuration file (not shown) on the computer 102 a, or it may be access information entered by an enterprise affiliate. In the implementation illustrated in FIG. 55, the access information 5502 may also include: a security distinguished name (DN) 5510, a password 5512, and a login alias 5514. Security DN 5510 identifies to the Client Interface 134 where a security profile for the enterprise affiliate is located. The Client Interface 134 uses the password 5512 and the login alias 5514 to access the resource information on the LDAP Server 5504 in accordance with privileges identified in the security profile. [0168] Having received the access information for the LDAP directory entry on network 108, the Client Interface 134 retrieves the resource information using the LDAP access information (step 5310). The resource information that the Client Interface 134 retrieves includes resource profiles for a user, equipment, facilities, computer systems, or other known entities that may be assigned to any task of a plan. [0169] After the resource information is received from the enterprise affiliate or is retrieved using LDAP access information, the Client Interface 134 stores the resource information in resource profiles on the WebDAV Storage 142 (step 5312). [0170] [0170]FIG. 56 depicts an exemplary resource file 5600 that the Client Interface 134 may use to store resource profiles 5602, 5604, 5606, and 5608 on WebDAV Storage 142. As shown in FIG. 56, the resource profile 5600 includes a unique identifier or URL 5612 where the resource profile 5600 is to be stored on the WebDAV Storage 142. Each resource profile 5602, 5604, 5606, and 5608 may be stored separately by the Client Interface 134 on WebDAV Storage 142. In the implementation shown in FIG. 56, the resource profile 5602 includes resource information 5610 that corresponds to an enterprise affiliate that may be assigned to a task of a plan. In another implementation, the resource information 5610 may be added as properties rather than as the content of the resource profile 5602 on WebDAV Storage 142. This implementation may be advantageous as the Client Interface 134 or the Workflow Engine 222 may use a known WebDAV method to retrieve resource profiles from the WebDAV Storage 142 that have the same property. For example, the WebDAV “PropFind” method may be used by the Client Interface 134 or the Workflow Engine 222 to retrieve the resource profiles having a skill identifier of “Java Programming” so that an available resource having this skill can be assigned to a task in accordance with processes described below. Managing A Plan [0171] [0171]FIG. 57 depicts a flow diagram illustrating an exemplary process performed by the Workflow Engine 222 to manage the execution of an activated plan. The Workflow Engine 222 may execute the process in FIG. 57 for each activated plan stored on WebDAV Storage 142. Thus, the tool manages the execution of multiple plans simultaneously. [0172] Initially, the tool 200 waits until the current time and date are later than the start time and date (step 5702) of the plan. Alternatively, a plan may not require a start time and date for each plan. Rather, the start time and date may be incorporated as an input condition for each task. At this point, the tool 200 selects the current next task (or tasks in the event of parallel tasks) from the activated project plan created from a workflow (step 5704). Note that the Workflow Engine 222 may retrieve the plan from WebDAV storage. Next, the tool 200 determines whether there is an input condition (step 5706). If there is an input condition, the tool 200 waits to see if the triggering event (described above) is met before it checks to see if the input condition is met (step 5708). If the input condition required monitoring of certain items on a periodic basis, the Workflow Engine 222 will add this event to its “Event Monitoring” log. After the input condition is met or if there is no input condition, the tool 200 stores the actual start time (step 5710). The next step performed by the tool 200 is to determine whether there is an on-entry script to execute, such as a message to send to the resource (step 5712 in FIG. 57B). If there is an on-entry script, the tool 200 performs the on-entry script (step 5714). After performing the on-entry script or if there is no on-entry script, the tool 200 determines whether there is an output condition (step 5716). If there is an output condition, the tool 200 waits to see if the triggering event (described above) is met before it checks to see if the output condition is met (step 5718). After the output condition is met or if there is no output condition, the tool 200 determines whether there is an on-exit script (step 5720). If there is an on-exit script, the tool 200 performs the on-exit script (step 5722). After performing the on-exit script or if there is no on-exit script, the tool 200 stores the actual end time (step 5724). Then the tool 200 determines whether there are any more tasks in the project plan (step 5726). If there are no more tasks, the process ends. Otherwise, the process returns to step 5704 and selects the next task. [0173] The plan 5800 created from the workflow 500 depicted in FIG. 5 is shown in FIG. 58. As shown in FIG. 58, “Serial 1” task 5802 is scheduled to begin at 9 a.m. 5804 on Aug. 1, 2001 (5806) and end at 6 p.m. 5808 on the same day. The parallel tasks 5810 and 5812 are scheduled to start at the completion of the “Serial 1” task 5808, and are scheduled to end at 6 p.m. 5814 on Aug. 2, 2001 (5816). The “Serial 2” task 5818 is scheduled to begin upon completion of the parallel tasks 5814 and is scheduled to end at 6 p.m. 5820 on Aug. 3, 2001 (5822). FIG. 59 depicts an exemplary project plan definition file 5900 corresponding to the plan 5800 of FIG. 58. [0174] Upon activation, the “Serial 1” task 6002 begins execution, as depicted by the task 6004 in the Gantt chart 6000 of FIG. 60. Contrary to the plan, however, the “Serial 1” task ends earlier than planned. As depicted in FIG. 61, the actual properties 6100 of the “Serial 1” task 6102 include the actual-start-date 6104 (i.e., year-2001 month-8 day-1 hour-9) and actual-finish-date 6106 (i.e., year-2001 month-8 day-1 hour-14, i.e., 2 p.m.). The actual execution 6204 of the “Serial 1” task 6202 is shown in the Gantt chart 6200 of FIG. 62. [0175] Because the “Serial 1” task 6202 ended earlier than planned, both the “Parallel 1” task 6206 and the “Parallel 2” task 6208 begin execution at 2 p.m. 6210 rather than waiting until their scheduled start time of 6 p.m. The earlier execution 6212 and 6214 of these tasks 6206 and 6208 is also depicted in the Gantt chart 6200. As depicted in FIG. 63, the actual properties 6300 of the “Parallel 1” task 6302 and the “Parallel 2” task 6304 include the actual-start-date 6306 (i.e., year-2001 month-8 day-1 hour-14) and actual-finish-date 6308 (i.e., year-2001 month-8 day-2 hour-0). The actual execution 6406 and 6408 of the “Parallel 1” task 6402 and the “Parallel 2” task 6404 is shown in the Gantt chart 6400 of FIG. 64. The Gantt chart 6400 also visually indicates that the start time 6410 for the tasks 6402 and 6404 was 2 p.m. on Aug. 1, 2001, while the end time 6412 for the tasks 6402 and 6404 was 12 a.m. on Aug. 2, 2001. [0176] Finally, the execution of the “Serial 2” task 6414 begins at 12 a.m. on Aug. 2, 2001 (6412). As depicted in FIG. 65, the actual properties 6500 of the “Serial 2” task 6502 includes the actual-start-date 6504 (i.e., year-2001 month-8 day-2 hour-0) and actual-finish-date 6506 (i.e., year-2001 month-8 day-2 hour-12). The actual execution 6604 of the “Serial 1” task 6602, the actual execution 6608 of the “Parallel 1” task 6606, the actual execution 6612 of the “Parallel 2” task 6610, and the actual execution 6616 of the “Serial 2” task 6614, are shown in the Gantt chart 6600 of FIG. 66. [0177] While various embodiments of the present invention have been described, it will be apparent to those of skill in the art that many more embodiments and implementations are possible that are within the scope of this invention. Accordingly, the present invention is not to be restricted except in light of the attached claims and their equivalents. Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS5835683 *Jan 12, 1995Nov 10, 1998International Business Machines CorporationSystem and method for authoring an expert systemUS5835758 *Feb 28, 1995Nov 10, 1998Vidya Technologies, Inc.Method and system for respresenting and processing physical and conceptual entitiesUS5848393 *Dec 15, 1995Dec 8, 1998Ncr Corporation"What if . . . " function for simulating operations within a task workflow management systemUS5893123 *Jun 22, 1995Apr 6, 1999Tuinenga; Paul W.System and method of integrating a spreadsheet and external program having output data calculated automatically in response to input data from the spreadsheetUS5926822 *Sep 6, 1996Jul 20, 1999Financial Engineering Associates, Inc.Transformation of real time data into times series and filtered real time data within a spreadsheet applicationUS5970482 *Feb 12, 1996Oct 19, 1999Datamind CorporationSystem for data mining using neuroagentsUS6044218 *Jan 31, 1997Mar 28, 2000Sun Microsystems, Inc.System, method and article of manufacture for creating a live application or applet development environmentUS6115640 *Jan 16, 1998Sep 5, 2000Nec CorporationWorkflow system for rearrangement of a workflow according to the progress of a work and its workflow management methodUS6157934 *Oct 15, 1996Dec 5, 2000Ultimus, L.L.C.Method and apparatus for using distributed spreadsheets in a client/server architecture for workflow automationUS6282531 *Jun 12, 1998Aug 28, 2001Cognimed, LlcSystem for managing applied knowledge and workflow in multiple dimensions and contextsUS20040078373 *May 14, 2003Apr 22, 2004Adel GhoneimyWorkflow system and method* Cited by examinerReferenced byCiting PatentFiling datePublication dateApplicantTitleUS7117480 *Nov 27, 2001Oct 3, 20063M Innovative Properties CompanyReusable software components for invoking computational modelsUS7177859Jun 26, 2002Feb 13, 2007Microsoft CorporationProgramming model for subscription servicesUS7209916Feb 27, 2003Apr 24, 2007Microsoft CorporationExpression and flexibility framework for providing notification(s)US7246074 *Oct 13, 2000Jul 17, 2007International Business Machines CorporationSystem and method for identifying skills and tools needed to support a process utilizing pre-defined templatesUS7360202 *Feb 27, 2003Apr 15, 2008Microsoft CorporationUser interface system and methods for providing notification(s)US7386797 *May 22, 2002Jun 10, 2008Oracle CorporationFramework to model and execute business processes within a collaborative environmentUS7457805 *Mar 6, 2003Nov 25, 2008Microsoft CorporationMethod and system for processing HTTP requests creating a new map for an entire namespace that is associated with the request and that maps the name extension to the further content type within namespaceUS7505998 *Jul 9, 2004Mar 17, 2009Computer Associates Think, Inc.Apparatuses and methods for dynamic creation of phase Gantt chartsUS7509304Feb 24, 2003Mar 24, 2009Microsoft CorporationMessage distribution system and method for providing notification(s)US7657590 *Feb 2, 2010Ubs AgLoad balancing system and methodUS7669177Feb 23, 2010Microsoft CorporationSystem and method for preference application installation and executionUS7685527 *Sep 3, 2002Mar 23, 2010Siebel Systems, Inc.Method and apparatus for controlling view navigation in workflow systemsUS7689564Mar 30, 2010Microsoft CorporationApparatus and computer-readable media for determining whether an existing map specifies a different content type than the content type that is specified for the specified resource name extension in a web distributed authoring and versioning (WebDAV) requestUS7698276Feb 26, 2003Apr 13, 2010Microsoft CorporationFramework for providing a subscription based notification systemUS7730015 *Oct 15, 2004Jun 1, 2010Oracle America, Inc.Stackable storage access mechanism for file systemsUS7797306Feb 26, 2003Sep 14, 2010Microsoft CorporationSystem and method for providing notification(s) in accordance with middleware technologiesUS7853959Feb 7, 2006Dec 14, 2010Sap AgBusiness process extension for productivity suite applicationUS7877327 *Jan 25, 2011Trintuition LlcApparatus and method for creating and using documents in a distributed computing networkUS7890962Feb 15, 2011Sag AgBusiness process extensions to enable alerts and reports within the context of groupwareUS7890964Apr 20, 2006Feb 15, 2011Sap AgMethods and apparatus for contextual awareness in a groupware clientUS7908549 *Dec 8, 2005Mar 15, 2011Microsoft CorporationSpreadsheet calculation as part of workflowUS7979297 *Oct 16, 2002Jul 12, 2011Sprint Communications Company L.P.Order tracking and reporting toolUS8060396Mar 23, 2004Nov 15, 2011Sprint Communications Company L.P.Business activity monitoring toolUS8103720Jan 24, 2012Microsoft CorporationApparatus and computer-readable media for processing HTTP requestsUS8271369Mar 12, 2004Sep 18, 2012Norman GilmoreFinancial modeling and forecasting systemUS8359391Jan 22, 2013Microsoft CorporationApparatus and computer-readable media for processing HTTP requests determine scoping mapping between a mapped resource name extension and a content typeUS8499300 *Nov 21, 2005Jul 30, 2013Bank Of America CorporationSystem and method for task management of rule based tasksUS8583514 *Aug 13, 2004Nov 12, 2013Jeffrey Brian KlemSystem and method for tracking information in a business environmentUS8626557 *Sep 26, 2006Jan 7, 2014International Business Machines CorporationSystem and method of providing snapshot to support approval of workflow changesUS8805805Jun 14, 2012Aug 12, 2014Allstate Insurance CompanyRetail deployment modelUS8938432Aug 1, 2006Jan 20, 2015Allstate Insurance CompanyRetail deployment modelUS9053083Nov 4, 2011Jun 9, 2015Microsoft Technology Licensing, LlcInteraction between web gadgets and spreadsheetsUS9111253 *Apr 20, 2006Aug 18, 2015Sap SeGroupware time trackingUS9171099Aug 8, 2012Oct 27, 2015Microsoft Technology Licensing, LlcSystem and method for providing calculation web services for online documentsUS20020156671 *Nov 7, 2001Oct 24, 2002The Boeing CompanySystem and method for collaborative actionUS20020178037 *Jan 22, 2002Nov 28, 2002Reading Jason AlbertLoad balancing system and methodUS20030097273 *Nov 13, 2002May 22, 2003Carpenter Edward D.System and method for conducting and managing an office moveUS20030100972 *Nov 27, 2001May 29, 20033M Innovative Properties CompanyReusable software components for invoking computational modelsUS20030135507 *Jan 17, 2002Jul 17, 2003International Business Machines CorporationSystem and method for managing and securing meta data using central repositoryUS20030167317 *Mar 6, 2003Sep 4, 2003Deen Brian J.Methods and systems for processing HTTP requestsUS20030233341 *May 5, 2003Dec 18, 2003Taylor Amanda KimSystems and methods for work list predictionUS20040002958 *Jun 26, 2002Jan 1, 2004Praveen SeshadriSystem and method for providing notification(s)US20040002972 *Jun 26, 2002Jan 1, 2004Shyamalan PatherProgramming model for subscription servicesUS20040002988 *Jun 26, 2002Jan 1, 2004Praveen SeshadriSystem and method for modeling subscriptions and subscribers as dataUS20040030992 *Aug 6, 2002Feb 12, 2004Trandafir MoisaSystem and method for management of a virtual enterpriseUS20040162918 *Feb 17, 2003Aug 19, 2004Richard FreidmanSystem and method for invoking WebDAV methods via non-WebDAV communication protocolsUS20040163037 *Feb 17, 2003Aug 19, 2004Richard FriedmanSystem and method for invoking WebDAV methods via non-WebDAV protocolsUS20040163086 *Feb 14, 2003Aug 19, 2004Richard FriedmanWebDAV servletUS20040167983 *Feb 21, 2003Aug 26, 2004Richard FriedmanWebDAV URL connectionUS20040168128 *Feb 21, 2003Aug 26, 2004Richard FriedmanConnecting to WebDAV servers via the Java™ connector architectureUS20040181378 *Mar 12, 2004Sep 16, 2004Norman GilmoreFinancial modeling and forecasting systemUS20040193940 *Feb 21, 2003Sep 30, 2004Snyder Joseph J.WebDAV unit test frameworkUS20050055333 *Sep 30, 2004Mar 10, 2005Microsoft CorporationApparatus and computer-readable media for processing HTTP requestsUS20050160084 *Jul 9, 2004Jul 21, 2005Computer Associates Think, IncApparatuses and methods for dynamic creation of phase gantt chartsUS20050165625 *Jan 24, 2005Jul 28, 2005Ladic Lance A.Method and apparatus for providing a laboratory information management system for use in an e-commerce environmentUS20050246283 *May 3, 2005Nov 3, 2005Trintuition LlcApparatus and method for creating and using documents in a distributed computing networkUS20050262112 *May 21, 2004Nov 24, 2005Moore Dennis BMethod and apparatus to convert project plans into workflow definitionsUS20060036476 *Aug 13, 2004Feb 16, 2006Klem Jeffrey BSystem and method for tracking information in a business environmentUS20060047556 *Aug 31, 2004Mar 2, 2006Lang Torsten IMethod and system for staffingUS20060064335 *Aug 17, 2004Mar 23, 2006International Business Machines CorporationMethod, system, and storage medium for performing business process modelingUS20060136922 *Nov 21, 2005Jun 22, 2006Michael ZimbergSystem and method for task management of rule geverned tasksUS20060139352 *Apr 29, 2005Jun 29, 2006Fujitsu LimitedComputer product, operation-analysis support device, and operation-analysis support methodUS20060241997 *Apr 20, 2005Oct 26, 2006Microsoft CorporationSystem and method for integrating workflow processes with a project management systemUS20060271933 *Feb 7, 2006Nov 30, 2006Agassi Shai EBusiness process extension for productivity suite applicationUS20060277079 *Apr 20, 2006Dec 7, 2006Gilligan Geffrey DGroupware travel itinerary creationUS20060277166 *Apr 20, 2006Dec 7, 2006Iryna Vogler-IvashchankaMethods and apparatus for contextual awareness in a groupware clientUS20060277544 *Apr 20, 2006Dec 7, 2006Bjoernsen Christian GGroupware time trackingUS20060277554 *Apr 20, 2006Dec 7, 2006Iryna Vogler-IvashchankaBusiness process extensions to enable alerts and reports within the context of groupwareUS20070061699 *Sep 9, 2005Mar 15, 2007Microsoft CorporationNamed object view of electronic data reportUS20070136653 *Dec 8, 2005Jun 14, 2007Microsoft CorporationSpreadsheet calculation as part of workflowUS20070136666 *Dec 8, 2005Jun 14, 2007Microsoft CorporationSpreadsheet cell-based notificationsUS20070156656 *Nov 30, 2006Jul 5, 2007Microsoft CorporationProgramming model for subscription servicesUS20070192347 *Aug 1, 2006Aug 16, 2007Allstate Insurance CompanyRetail Deployment ModelUS20070240046 *Sep 3, 2002Oct 11, 2007Heung-Wah YanMethod and apparatus for controlling view navigation in workflow systemsUS20070255677 *Apr 28, 2006Nov 1, 2007Sun Microsystems, Inc.Method and apparatus for browsing search results via a virtual file systemUS20080004925 *Jun 29, 2006Jan 3, 2008Bangel Matthew JMulti-site project managementUS20080077466 *Sep 26, 2006Mar 27, 2008Garrett Andrew JSystem and method of providing snapshot to support approval of workflow changesUS20080109291 *Nov 7, 2006May 8, 2008Montes De Oca Group, Inc.Executing and Tracking Strategic PlansUS20080109467 *Nov 3, 2006May 8, 2008Microsoft CorporationData entity centric approach for designing workflowsUS20080208670 *May 8, 2008Aug 28, 2008International Business Machines CorporationMethod, system, and storage medium for performing business process modelingUS20080215358 *May 13, 2008Sep 4, 2008International Business Machines CorporationMethod, system, and storage medium for implementing business process modulesUS20080243930 *Mar 25, 2008Oct 2, 2008Robert P. WelchSystem and Method for Automated Customization of a Workflow Management SystemUS20090099896 *Oct 15, 2007Apr 16, 2009International Business Machines CorporationSystem and method for workflow delinquency remediationUS20090119114 *Nov 2, 2007May 7, 2009David AlanizSystems and Methods for Enabling Customer ServiceUS20100042418 *Feb 18, 2010Kjell OlssonTechnical tools for complex informationUS20100250666 *Sep 30, 2010Microsoft CorporationApparatus and computer-readable media for processing http requestsUS20100293027 *Apr 8, 2008Nov 18, 2010Eric Denis Du FosseWorkflow engine for media production and distributionUS20110145689 *Jun 16, 2011Microsoft CorporationNamed object view over multiple filesUS20110270641 *Nov 3, 2011Allstate Insurance CompanyRetail Location ServicesUS20120179504 *Mar 22, 2012Jul 12, 2012Hirofumi NakashimaP2p workflow system, information processing apparatus and storage mediumUS20130304531 *May 11, 2012Nov 14, 2013Paul BarberSystem and method for performing detailed planning functionsUS20130304536 *May 10, 2012Nov 14, 2013Ebay, Inc.Harvest Customer Tracking InformationUS20140143001 *Nov 12, 2013May 22, 2014Jeffrey Brian KlemSystem and Method for Tracking Information in a Business EnvironmentWO2005057443A1 *Dec 3, 2004Jun 23, 2005One 2 TeamMan/machine interface and method for creating and managing project-related informationWO2005073893A2 *Jan 24, 2005Aug 11, 2005Siemens Corporate Reserach, Inc.Method and apparatus for providing a laboratory information management system for use in an e-commerce environmentWO2005073893A3 *Jan 24, 2005Jan 26, 2006Lance Anthony LadicMethod and apparatus for providing a laboratory information management system for use in an e-commerce environment* Cited by examinerClassifications U.S. Classification705/1.1, 707/999.001International ClassificationG06T13/00, G06Q30/00, G06Q10/00Cooperative ClassificationY10S707/99943, Y10S707/99942, Y10S707/99945, Y10S707/99944, G06Q10/06, G06Q10/10, G06Q30/06European ClassificationG06Q10/06, G06Q10/10, G06Q30/06Legal EventsDateCodeEventDescriptionJan 14, 2002ASAssignmentOwner name: TOGETHERSOFT CORPORATION, NORTH CAROLINAFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:CHARISIUS, DIETRICH;KERN, JONATHAN;REEL/FRAME:012481/0997;SIGNING DATES FROM 20011011 TO 20011019Jan 4, 2008ASAssignmentOwner name: BORLAND SOFTWARE CORPORATION, CALIFORNIAFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:TOGETHERSOFT CORPORATION;REEL/FRAME:020317/0308Effective date: 20071220Mar 30, 2009FPAYFee paymentYear of fee payment: 4Jul 5, 2013REMIMaintenance fee reminder mailedNov 22, 2013REINReinstatement after maintenance fee payment confirmedNov 22, 2013LAPSLapse for failure to pay maintenance feesJan 14, 2014FPExpired due to failure to pay maintenance feeEffective date: 20131122Apr 6, 2015PRDPPatent reinstated due to the acceptance of a late maintenance feeEffective date: 20150407Apr 7, 2015FPAYFee paymentYear of fee payment: 8Apr 7, 2015SULPSurcharge for late paymentRotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services