Source: http://www.google.com/patents/US7096222?dq=5,410,344
Timestamp: 2013-12-10 15:48:20
Document Index: 261679158

Matched Legal Cases: ['Application No. 60', 'Application No. 60', 'Application No. 60', 'Application No. 60', 'art 6000', 'art 6200', 'art 6200', 'art 6400', 'art 6400', 'art 6600']

Patent US7096222 - Methods and systems for auto-instantiation of storage hierarchy for project plan - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Advanced Patent Search | Sign inAdvanced Patent SearchPatentsMethods and systems consistent with the present invention allow a user to create a storage hierarchy definition in association with a workflow that models a process, to generate a plan from the workflow that reflects an instance of the process, and to generate a container in accordance with the storage...http://www.google.com/patents/US7096222?utm_source=gb-gplus-sharePatent US7096222 - Methods and systems for auto-instantiation of storage hierarchy for project planPublication numberUS7096222 B2Publication typeGrantApplication numberUS 10/165,530Publication dateAug 22, 2006Filing dateJun 7, 2002Priority dateSep 1, 2000Fee statusPaidAlso published asUS20020184250Publication number10165530, 165530, US 7096222 B2, US 7096222B2, US-B2-7096222, US7096222 B2, US7096222B2InventorsJonathan Kern, Mikhail OkruginOriginal AssigneeBorland Software CorporationExport CitationBiBTeX, EndNote, RefManPatent Citations (14), Non-Patent Citations (3), Referenced by (15), Classifications (17), Legal Events (3) External Links: USPTO, USPTO Assignment, EspacenetMethods and systems for auto-instantiation of storage hierarchy for project planUS 7096222 B2Abstract Methods and systems consistent with the present invention allow a user to create a storage hierarchy definition in association with a workflow that models a process, to generate a plan from the workflow that reflects an instance of the process, and to generate a container in accordance with the storage hierarchy definition when the plan is generated from the workflow. The container may then be used to store an artifact that is used or produced by the plan in accordance with methods and systems of the present invention.
CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of the filing date of U.S. Provisional Application No. 60/296,707, entitled �Development Tool For Modeling Workflow,� filed on Jun. 7, 2001, and U.S. Provisional Application No. 60/367,430, entitled �Development Tool For Modeling Workflow,� filed on Mar. 25, 2002; and is a continuation-in-part of U.S. patent application Ser. No. 09/944,697, entitled �Methods And Systems For Integrating Process Modeling And Project Planning,� filed on Aug. 31, 2001, now U.S. Pat. No. 6,968,343, which claims the benefit of the filing date of U.S. Provisional Application No. 60/230,054, entitled �Development Tool For Modeling Workflow,� filed on Sep. 1, 2000, and U.S. Provisional Application No. 60/296,707, entitled �Development Tool For Modeling Workflow,� filed on Jun. 7, 2001; all of which are incorporated herein by reference.
U.S. patent application Ser. No. 09/945,081, entitled �Methods and Systems for Improving a Workflow Based on Data Mined from Plans Created from the Workflow,� filed on Aug. 31, 2001;
U.S. patent application Ser. No. 09/944,696, entitled �Methods and Systems for Animating a Workflow and a Project Plan,� filed on Aug. 31, 2001;
U.S. patent application Ser. No. 09/944,847, entitled �Methods and Systems for Optimizing Resource Allocation Based on Data Mined from Plans Created from a Workflow,� filed on Aug. 31, 2001; and
U.S. patent application Ser. No. 10/165,405, entitled �Methods And Systems For Linking Tasks To A Workflow,� and filed on the same date herewith.
SUMMARY OF THE INVENTION Methods and systems consistent with the present invention provide a workflow modeling and project planning integration tool that overcomes the limitations of conventional tools. Contrary to conventional tools that do not allow a user to integrate a business process or workflow with a project plan, the integration tool, in accordance with methods and systems consistent with the present invention, allows a user to model a business process or workflow, to create and activate or start a project plan based on the workflow, to manage the execution of the activated plan, and to track the progress of the activated project plan. In addition, the tool may include a Web-based �Distributed Authoring and Versioning� server that operates as a virtual file system to allow more than one user to view the same workflow or project plan, to provide persistent storage, to monitor the progress of an activated project plan, to simultaneously create plans from the same workflow, and to have essentially unlimited access to the power of the tool through the ubiquity of the Internet. �Versioning� is a term well-known in the art for capturing the state of an entity at given points in time.
FIGS. 10�12 depict the execution of the plan depicted in FIG. 7;
FIGS. 13�16 depict the execution of the plan depicted in FIG. 8;
FIGS. 17�21 depict the execution of the plan depicted in FIG. 9 following the default path;
FIGS. 22�27 depict the execution of the plan depicted in FIG. 9 following the non-default path;
FIGS. 28A�C depict a flow diagram illustrating the creation or retrieval of a workflow by the tool of FIG. 2;
FIGS. 33A�C depict an exemplary workflow definition file produced by the tool of FIG. 2 for the workflow depicted in FIG. 6;
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.
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.
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 21 00 after execution of the tasks 2102, 2104, 2106, and 2108 is complete is depicted in FIG. 21.
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 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.
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.
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.
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, wich 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.
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 �linkablel� 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 �linkablel� identity 3398. This condition 3396 signals the tool 200 to monitor the state of an artifact until it is in the �RIGHT� state 3399.
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.
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.
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.
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.
FIGS. 67A�B depict a flow diagram illustrating an exemplary process performed by the tool 200 for defining a storage hierarchy in association with a workflow. Initially, the tool 200 creates or retrieves a workflow (step 6702). The tool 200 then displays the workflow (step 6704). The processing performed by the tool 200 for creating or retrieving a workflow is described above in reference to step 302 in FIG. 3 and further described in greater detail in reference to FIGS. 28A�C. FIG. 68 depicts an exemplary workflow 6800 that the enterprise affiliate may create or retrieve using the tool 200. The workflow 6800 includes an activity 6802 called �Task A.� In accordance with methods and systems consistent with the present invention as discussed above, the tool 200 may generate a task for a plan from the activity 6802 of the workflow 6800. FIG. 69 depicts an exemplary workflow definition file 6900 that is produced by the tool 200 when the workflow 6800 depicted in FIG. 68 is created. The name 6902 of the workflow, �SampleForStorageHierarchy,� is identified in the workflow definition file 6900. The element 6904 in the workflow definition file 6900 represents the �Task A� activity 6802 in FIG. 68. To define a storage hierarchy in association with the workflow 6800 using the tool 200, the enterprise affiliate need not have completed the creation of the workflow 6800. Thus, in this example, the tool 200 allows the enterprise affiliate to create activity 6802 in FIG. 68 and its corresponding element 6904 in the workflow definition file 6900 in FIG. 69 after defining a storage hierarchy to be associated with the workflow. This flexibility of the tool 200 advantageously allows the enterprise affiliate, such as a manager with knowledge of the enterprise strategy for organizing the storage of artifacts in association with a plan created from the workflow 6800, to define the storage hierarchy to be associated with the workflow 6800 before other affiliates complete the creation of the workflow 6800. The other affiliates may then use the tool 200 to create activities for the workflow 6800 with links to the storage hierarchy as described in greater detail below. Thus, the enterprise affiliate may use the tool 200 to define a storage hierarchy at any point during the creation of the workflow 6800 so long as the enterprise affiliate has identified the workflow 6800 to the tool 200 before the creation of a plan from the workflow 6800.
If the tool 200 receives an indication to define a storage hierarchy, the tool 200 then determines whether the workflow is already associated with a storage hierarchy definition (step 6708). In one implementation, the tool 200 searches for a storage hierarchy definition file stored in the same location as the workflow definition file 6900. In another implementation, the tool 200 may search for a storage hierarchy definition file that has the same name 6902, �SampleForStorageHierarchy,� as the workflow definition file 6900 in FIG. 69 but that has a unique extension, such as �.sh.� In this implementation, the storage hierarchy definition file may be located on any computer 102 a, 102 n, 104, or 106 of the data processing system 100. In yet another implementation, the tool 200 may search the workflow definition file 6900 in FIG. 69 for a URL 6906 designating the location of the associated storage hierarchy definition file on the data processing system 100. In still another implementation, the tool 200 may use the URL 6904 as a pointer to a root container of a hierarchy of containers that serves as a template for the storage hierarchy definition associated with the workflow 6800. In this implementation, the tool 200 replicates the hierarchy of containers for each plan created from the workflow 6800. The containers may be physical file folders stored on a network storage medium, such as secondary storage device 116, 118, or 120 of FIG. 1, or virtual file folders stored using a virtual file system server (e.g., WebDAV server 140 of FIG. 1) on a database system, such as WebDAV storage 142.
The storage hierarchy definition may include roles 7010 associated with a selected container identification 7008 and permissions 7012 associated with a selected role 7014. As discussed above, the tool 200 (via Resource Manager Module 206 in FIG. 2) allows an enterprise affiliate to identify a role or role profile (representing a �capability� or �skill set�) that may be assigned to an activity of the workflow and to identify a resource or user profile that may be associated with the role to indicate that the resource or user is capable of handling the role. As further discussed below, the tool 200 uses the role or roles associated with a container generated for a plan to manage access to the artifacts stored in the container.
In the implementation shown in FIG. 70, the tool 200 displays container identifications 7002 under the root container 7004 (�Project Root�) to indicate that the container(s) generated in accordance with the storage hierarchy definition for each plan created from the workflow 6800 are located subordinate to the same root container 7004 on the network storage medium (e.g., WebDAV storage 142 in FIG. 2). Thus, if multiple plans are created from the workflow 6800, an enterprise affiliate is able to locate and easily access artifacts from any of the multiple plans for quality control evaluation or for other purposes. For an empty storage hierarchy definition, the tool 200 may just display root container 7004 in pane 7001 as shown in FIG. 71 to indicate that containers have yet to be defined for the storage hierarchy associated with the workflow 6800.
The next step performed by the tool 200 is to determine whether to create a new container for the storage hierarchy associated with the workflow 6800 (step 6716 of FIG. 67A). As shown in FIGS. 70 and 71, the enterprise affiliate may indicate to the tool 200 to create a container by selecting the �Create new folder� button 7006.
If the tool 200 does not receive an indication to create a new container, or after displaying a representation of the modified storage hierarchy definition following the addition of a new container, the tool 200 then determines whether to remove a container from the storage hierarchy associated with the workflow 6800 (step 6724). As shown in FIGS. 70 and 71, the enterprise affiliate may indicate to the tool 200 to remove a container by selecting the �Remove folder� button 7016. If the tool 200 receives an indication to remove a container, the tool 200 then receives an indication of an existing container to remove (step 6726). In the example shown in FIG. 70, the enterprise affiliate may indicate the existing container to remove by selecting one of the container identifications 7002 displayed in pane 7001. The tool 200 then modifies the storage hierarchy definition to reflect the removal of the existing container (step 6728). To reflect the removal of the existing container selected by the enterprise affiliate, the tool 200 removes the selected container and any of the container identifications 7002 that are subordinate to the selected container. The tool 200 then displays a representation (not shown in figures) of the modified storage hierarchy definition (step 6730).
Referring to FIG. 67B, the tool 200 next receives an indication of a selected container (step 6732). The tool 200 also performs this step if at step 6724 it does not receive an indication to remove a container. The enterprise affiliate may use any known data input technique, such as a mouse click, to indicate the selected container from among the container identifications 7002. The tool 200 then displays roles associated with the selected container (step 6734). In the example shown in FIG. 70, the enterprise affiliate selects the container identification 7008 (�documentation�) and the tool 200 subsequently displays the roles 7010 in pane 7017 that have been previously associated with the container identification 7008. In the example shown in FIG. 71 for the initially empty storage hierarchy definition, the enterprise affiliate selects the root container 7004 (�Project Root�) and the tool 200 subsequently displays pane 7017 empty to indicate that no roles have been associated with the root container 7004.
Next, the tool 200 receives an indication of a selected role (step 6736 in FIG. 67B). The tool 200 then displays permissions for the selected role (step 6738). As shown in FIG. 70, the enterprise affiliate may use any known data input technique, such as a mouse click, to indicate the selected role 7014 (�author�) from among the roles 7010. In this implementation, the tool 200 displays a check next to each of the permissions 7012 that the enterprise affiliate has previously indicated are to be associated with the selected role 7014. Thus, any affiliate or user with the same role (�author�) will be allowed to access the contents of the selected container 7008 (�specification�) in accordance with the permissions 7012. Hence, the tool 200 allows the enterprise affiliate defining the storage hierarchy definition to carefully control access to the artifacts in each container subsequently generated by the tool in accordance with the storage hierarchy definition.
If a permission is not to be added or deleted, the tool 200 next determines whether to add a new role to the selected container (step 6744). FIG. 73 depicts an exemplary user interface 7300 used to display the storage hierarchy definition associated with workflow 6800 after the tool 200 has added container identification 7302 (�specifications�) as specified by the enterprise affiliate. In this example, container identification 7302 represents the selected container. The enterprise affiliate may then indicate to the tool 200 to add or associate a role to the container identification 7302 (�specifications�) by selecting the �Add new role� button 7304 in FIG. 73.
If the tool 200 determines that a new role is to be added to the selected container, the tool 200 receives the new role (step 6746). In the implementation shown in FIG. 73, the tool 200 receives the new role 7306 (�spec writer�) from the enterprise affiliate via dialog box 7308. The enterprise affiliate, however, may identify the new role 7306 to the tool 200 using any known data input technique, such as pull down menu selection of roles. Next, the tool 200 modifies the storage hierarchy definition to reflect the new role associated with the selected container (step 6748). The tool 200 then displays the roles associated with the selected container to reflect the addition of the new role (step 6750). In the example shown in FIG. 74, the tool 200 displays the new role 7306 (�spec writer�) in association with the container identification 7302 (�specifications�), which represents the selected container in this example.
The next step performed by the tool 200 is to determine whether the definition of the storage hierarchy is completed (step 6758). The enterprise affiliate may use any known data input technique, such as an �Ok� button 7402 on user interface 7400, to provide an indication to the tool 200 that the definition of the storage hierarchy associated with the workflow 6800 is completed. If the definition of the storage hierarchy is not completed, the tool 200 continues processing at step 6716 to again determine if a new container is to be created in the storage hierarchy associated with the workflow.
If the definition of the storage hierarchy is completed, the tool 200 stores the storage hierarchy definition in association with the workflow (step 6760) before the process ends. FIG. 75 depicts an exemplary file 7500 produced by the tool 200 to store the storage hierarchy definition shown in FIG. 70 associated with the workflow 6800. To reflect that the storage hierarchy definition file 7500 is associated with the workflow 6800, the tool 200 may store in the storage hierarchy definition file 7500 the name 7502 of the workflow 6800 (�SampleForStorageHierarachy�), which corresponds to the name 6902 in workflow definition file 6900 of FIG. 69. To reflect the hierarchy of the container identifications 7002 in FIG. 70, the tool 200 stores corresponding XML type commands 7504. Each of the commands 7504 contains a �createFolder� identifier 7506 to indicate that the respective command represents the path and name of a container to be generated by the tool 200 for a plan created from the workflow 6800. To reflect the roles associated with each of the container identifications 7002 in FIG. 70 (e.g., roles 7010 associated with container identification 7008 �documentation�), the tool 200 stores corresponding XML type commands 7508 with an �addRole� identifier 7510. The �addRole� identifier 7510 indicates to the tool 200 that a role 7512 with the respective command is to be added to the container 7514 identified within the command when the tool 200 generates the container 7514 for a plan created from the workflow 6800. The tool 200, however, may also store the storage hierarchy definition associated with the workflow 6800 in other structures known in the art, such as in a flat file with known delimiters between container identifications 7002, a database, or as an object serialized to a file on a network storage medium.
As discussed above, the enterprise affiliate using the tool 200 may define the storage hierarchy associated with the workflow 6800 during or after the creation of the workflow 6800. For example, to define the storage hierarchy after the creation of the workflow or after the storage hierarchy definition file 7500 is completed and stored by the tool 200, the enterprise affiliate may select the activity 6802 �Task A� on user interface 7600 in FIG. 76 in order to prompt the tool 200 to display user interface 7604 to edit the properties of the activity 6802. In order to identify the location for artifact 7605 �Specification� used by a task created from the activity 6802 by the tool 200, the enterprise affiliate may select the parent folder pop-up browser button 7606 to prompt the tool 200 to display the storage hierarchy definition (e.g., container identifications 7610) associated with workflow 6800 and stored in file 7500 of FIG. 75 by tool 200. The enterprise affiliate may select next one of the container identifications 7610 (e.g., container identification 7612 �specifications�) to be the parent folder or container where the artifact 7605 �specification� is to be stored for a plan created from the workflow 6800. As shown in FIG. 77, a copy of the container identification 7612 is stored in association with the activity 6802 as the location property 7702 (�Parent folder�) for the artifact 7605 �Specification.� When the enterprise affiliate later prompts the tool 200 to create a plan from the workflow, a task created from the activity 6802 by the tool 200 is able to store or use the artifact 7605 �Specification� within the container generated by the tool 200 that corresponds to the container identification 7612.
Having generated and stored the storage hierarchy definition in association with the workflow 6800, the tool 200 is able to automatically generate container(s) for each plan created from the workflow 6800 in accordance with the storage hierarchy definition (e.g., file 7500 of FIG. 75). FIG. 78 depicts a flow diagram illustrating an exemplary process performed by the tool 200 for generating and managing container(s) for a plan on a network storage medium in accordance with the storage hierarchy definition when the plan is generated from the workflow. Initially, the tool 200 creates a plan from a selected workflow (step 7802). The processing performed by the tool 200 for creating a plan from a selected workflow was previously described in reference to step 306 in FIG. 3 and further described in greater detail in reference to FIGS. 41A�B. At this point, the enterprise affiliate has already selected the workflow and the plan has or is in the process of being created by the tool 200. Thus, the tool 200 may perform the remaining steps of this process in conjunction with performing the process for creating a plan from the selected workflow. To provide clarity in the discussion to follow, it is assumed that the enterprise affiliate has selected to create a plan from the workflow 6800 depicted in FIG. 68, which has the workflow definition file 6900 shown in FIG. 69. A detailed explanation of the plan created from the workflow 6800 is not necessary for an understanding of the functionality associated with the process depicted in FIG. 78.
The next step performed by the tool 200 is to determine whether the workflow is associated with a storage hierarchy definition (step 7804). In one implementation, the tool 200 searches for a storage hierarchy definition file stored in the same location as the workflow definition file 6900. In another implementation, the tool 200 may search for a storage hierarchy definition file that has the same name 6902, �SampleForStorageHierarchy,� as the workflow definition file 6900 in FIG. 69 but that has a unique extension, such as �.sh.� In this implementation, the storage hierarchy definition file may be located on any computer 102 a, 102 n, 104, or 106 of the data processing system 100. In yet another implementation, the tool 200 may search the workflow definition file 6900 in FIG. 69 for a URL 6906 designating the location of the associated storage hierarchy definition file on the data processing system 100. In still another implementation, the tool 200 may use the URL 6906 as a pointer to a root container of a hierarchy of containers that serve as a template for the storage hierarchy definition associated with the workflow 6800. In this implementation, the tool 200 replicates the hierarchy of containers for each plan created from the workflow 6800. The containers may be physical file folders or virtual file folders stored in a database system, such as WebDAV storage 142 of FIG. 1.
After modifying the storage hierarchy definition to reflect the edit, the tool 200 continues processing at step 7810 to determine if the storage hierarchy definition for the plan is to be edited again. If the storage hierarchy definition for the plan is not to be edited, the tool 200 then generates a storage hierarchy structure on a network storage medium of the data processing system 100 (e.g., WebDAV storage 142 in FIG. 2) in accordance with the storage hierarchy definition for the plan (step 7818). The storage hierarchy structure includes one or more containers generated by the tool 200 to correspond hierarchically on a one-to-one basis with the container identifications 7902. For example, FIG. 80 depicts the storage hierarchy structure 8002 generated by the tool 200 on WebDAV storage 142 in accordance with the storage hierarchy definition shown in FIG. 79 for the plan identified as �AutoInstantiate Project 1� 7912. As shown in FIG. 80, the storage hierarchy structure 8002 has container(s) 8004 (graphically depicted) that correspond to the container identifications 7902. In this implementation, the tool 200 has generated the container(s) 8004 to be subordinate to a root container 8006 for the plan that has the same name (�AutoInstantiate Project 1�) as the plan.
Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS5551028Feb 28, 1995Aug 27, 1996Mentor Graphics CorporationDesign data management system and associated methodUS5764902Sep 29, 1995Jun 9, 1998Intel CorporationConditional insert or merge in a data conferenceUS6006193 *Dec 18, 1996Dec 21, 1999Gibson; Kenneth U.Computer executable workflow control systemUS6011917 *Aug 23, 1995Jan 4, 2000International Business Machines CorporationMethod and computer system for generating process management computer programs from process modelsUS6014673 *May 13, 1997Jan 11, 2000Hewlett-Packard CompanySimultaneous use of database and durable store in work flow and process flow systemsUS6028997 *May 30, 1997Feb 22, 2000International Business Machines CorporationMethod of generating an implementation of reusable parts from containers of a workflow process-modelUS6065009 *Jan 20, 1998May 16, 2000International Business Machines CorporationEvents as activities in process models of workflow management systemsUS6067548 *Jul 16, 1998May 23, 2000E Guanxi, Inc.Dynamic organization model and management computing system and method thereforUS6182080Sep 12, 1997Jan 30, 2001Netvoyage CorporationSystem, method and computer program product for storage of a plurality of documents within a single fileUS6308188 *Jun 19, 1998Oct 23, 2001International Business Machines CorporationSystem and method for building a web site with automated workflowUS6308224 *Mar 28, 1997Oct 23, 2001International Business Machines CorporationMethod of generating an implementation of a workflow process model in an object environmentUS6892376 *Mar 20, 2001May 10, 2005International Business Machines CorporationFlexible infrastructure for managing a processUS20020035593Jan 19, 2001Mar 21, 2002Salim Mohammad S.Method and apparatus for implementing an active information modelUS20040078373 *May 14, 2003Apr 22, 2004Adel GhoneimyWorkflow system and method* Cited by examinerNon-Patent CitationsReference1 *Ailamaki et al., Scientific workflow management by database management, Jan. 7, 1998, IEEE, 1-10.2 *Gruhn et al., Workflow management based on process model repositories, Apr. 19, 1998, IEEE, 379-388.3 *Schuster et al., A Configuration Management Approach for Large Workflow Management Systems, 1999, ACM, 177-186.* Cited by examinerReferenced byCiting PatentFiling datePublication dateApplicantTitleUS7302483 *Sep 27, 2002Nov 27, 2007At&T Bls Intellectual Property, Inc.Job analysis and workflow applicationUS7386797 *May 22, 2002Jun 10, 2008Oracle CorporationFramework to model and execute business processes within a collaborative environmentUS7610549 *May 20, 2004Oct 27, 2009Sap AgMethod and system for Java Gantt/bar chart renderingUS7610576 *Jan 19, 2005Oct 27, 2009Sap AgSystem and method for simultaneous display of processes and associated filesUS7644390Aug 14, 2007Jan 5, 2010Payman KhodabandehlooDesign tool and methodology for enterprise software applicationsUS7734491 *Jun 15, 2004Jun 8, 2010Microsoft CorporationHierarchical projects in a computer-enabled project management method and systemUS7814457 *Jan 19, 2005Oct 12, 2010Sap AgSystem and method for revising flow diagrams displaying a processUS7853931Jan 19, 2005Dec 14, 2010Sap AgSystem and method for automatically generating flow diagramsUS7962889Jul 31, 2007Jun 14, 2011Novell, Inc.Techniques for instantiating and configuring projectsUS8131668May 28, 2008Mar 6, 2012Sap AgUser-experience-centric architecture for data objects and end user applicationsUS8250169Dec 13, 2007Aug 21, 2012Sap AgBusiness context data companion toolUS8370792May 16, 2011Feb 5, 2013Novell, Inc.Techniques for instantiating and configuring projectsUS8402514Nov 17, 2006Mar 19, 2013Network Appliance, Inc.Hierarchy-aware role-based access controlUS8527313May 15, 2007Sep 3, 2013Sap AgDocument instantiation triggering a business actionUS20120179504 *Mar 22, 2012Jul 12, 2012Hirofumi NakashimaP2p workflow system, information processing apparatus and storage medium* Cited by examinerClassifications U.S. Classification1/1, 717/104, 707/999.1, 707/999.001, 707/999.104, 707/999.01International ClassificationG06Q30/00, G06F17/30, G06Q10/00Cooperative ClassificationY10S707/99945, Y10S707/99931, G06Q10/10, G06Q30/06, G06Q10/06European ClassificationG06Q10/10, G06Q10/06, G06Q30/06Legal EventsDateCodeEventDescriptionAug 20, 2010FPAYFee paymentYear of fee payment: 4Aug 20, 2010SULPSurcharge for late paymentMar 29, 2010REMIMaintenance fee reminder mailedRotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services©2012 Google