Source: http://www.google.com/patents/US20040133457?dq=6,044,471
Timestamp: 2016-06-29 01:05:13
Document Index: 121419465

Matched Legal Cases: ['art 1500', 'art 1500', 'art 1500', 'art 300', 'art 300', 'art 1500', 'art 1800', 'art 1900', 'art 2100', 'art 2100', 'art 2100']

Patent US20040133457 - Flexible workflow management - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inPatentsA flexible workflow is described that includes a pocket of flexibility. The pocket of flexibility may include workflow fragments that may be joined together, subject to pre-defined constraints. In implementing the flexible workflow, a user may encounter the pocket of flexibility, and select from the...http://www.google.com/patents/US20040133457?utm_source=gb-gplus-sharePatent US20040133457 - Flexible workflow managementAdvanced Patent SearchPublication numberUS20040133457 A1Publication typeApplicationApplication numberUS 10/671,876Publication dateJul 8, 2004Filing dateSep 29, 2003Priority dateJan 7, 2003Also published asUS7885840, WO2004060038A2, WO2004060038A8Publication number10671876, 671876, US 2004/0133457 A1, US 2004/133457 A1, US 20040133457 A1, US 20040133457A1, US 2004133457 A1, US 2004133457A1, US-A1-20040133457, US-A1-2004133457, US2004/0133457A1, US2004/133457A1, US20040133457 A1, US20040133457A1, US2004133457 A1, US2004133457A1InventorsShazia Sadiq, Wasim Sadiq, Maria OrlowskaOriginal AssigneeShazia Sadiq, Wasim Sadiq, Orlowska Maria E.Export CitationBiBTeX, EndNote, RefManPatent Citations (8), Referenced by (61), Classifications (13), Legal Events (3) External Links: USPTO, USPTO Assignment, EspacenetFlexible workflow management
[0113] Specifically, FIG. 12 illustrates that a fork 1210 may lead to the fragment A 1202 and/or the fragment C 1206, while a fork 1212 may lead to the fragment C 1206, the fragment B 1208, and/or the fragment D 1208. A fork 1214 may lead to the fragment A 1202, the fragment C 1206, and/or the fragment D 1208. Finally in FIG. 12, a fork 1216 may lead to the fragment A 1202 and/or the fragment D 1208. [0114] Execution according to the fork constraint of FIG. 12 does not necessarily imply parallel execution, since activities present on the multiple outgoing branches of a fork may be activated in any order. Furthermore, the fragments may appear in fork structures together with other workflow activities. [0115] An example of the fork constraint of FIG. 12 may include a situation in which a number of study activities are designed within a course. In such a case, a student may be expected to undertake at least three of the activities during a given period of time. [0116] In the following discussion, the fork constraint may be referred to as F(Fm) where Fm is a non-empty subset of F. Thus F(Fm) may be represented as F({f1, f2, . . . fn}); fiεFm for i=1, . . . n. Using this terminology, the Fork constraint F(Fm) may be defined such that, for a given F(Fm), Fk is a subset of Fm, such that all fragments in Fk are present in T. Then ∀fi, fjεFk, there does not exist a path between them in T. As with the serial and order constraints discussed above, a choice of fragments in Fk may be user-driven. [0117] The constraints discussed above may be considered “structural” constraints, in that they refer to how a given set of fragments may be composed within a template. A second type of constraint may be considered to be “containment” constraints, which refer to whether a particular fragment(s) may be included (contained) within a template. [0118] [0118]FIG. 13 is a block diagram illustrating an action of an inclusion type of a containment constraint. FIG. 13 includes a first set 1302 of fragments, a second set of fragments 1304, and a third set of fragments 1306, where the third set 1306 of fragments represents a pocket of flexibility that has been concretized based on fragments within the first set 1302 and/or the second set 1304 (i.e., a template). The first set 1302 of fragments includes a fragment A 1308, a fragment B 1310, a fragment C 1312, and a fragment D 1314. The second set 1304 of fragments includes a fragment E 1316 and a fragment F 1318. [0119] In FIG. 13, the inclusion constraint identifies a dependency between the fragment A 1308 and the fragments E 1316 and the fragment F 1318, such that inclusion of the fragment A 1308 within the third set 1306 necessitates inclusion of the fragment E 1316 and the fragment F 1318. In other words, generally speaking, a presence (or absence) of fragments from one set imposes a restriction on the fragments of the second set. The inclusion constraint can be supplemented with a serial/order or fork constraint that imposes an additional restriction on how the included fragments must be composed. [0120] An example of the inclusion type of containment constraint exists in travel booking, where a customer making a booking for both flight and accommodation will be provided by free transport from/to the airport. That is, inclusion of the “flight booking” fragment and the “accommodation” fragment necessitates inclusion of the “transport” fragment. [0121] In the following discussion, the inclusion constraint may be referred to as I(Fp, Fm) where Fp and Fm are two non-empty subsets of F. Thus I(Fp, Fm) may be represented as I({fl, . . . fq}, {fl . . . fn}); fiεFp for i=1, . . . q; fjεFm for j=1, . . . n. Using this terminology, at least two cases may occur. Specifically, if all fragments from Fp are present in T then all fragments from Fm must appear in T; conversely, if not all the fragments from Fp are present in T then no rule is enforced on Fm. [0122] [0122]FIG. 14 is a block diagram illustrating an action of an exclusion type of a containment constraint. In FIG. 14, the exclusion constraint acts on the same sets 1302 and 1304 of fragments as in FIG. 13, and achieves a set 1402 of fragments that includes the fragment A 1308 and the fragment E 1316. [0123] More specifically, the exclusion constraint acts to identify a dependency between the sets 1302 and 1304 of fragments, such that a selection of one (or more) fragment(s) (here, the fragment A 1308 and the fragment E 1316) prohibits selection of another fragment(s) (here, the fragment F 1318) for inclusion in the resulting set (i.e., template) 1402. In FIG. 14, the fragment E 1316 is selected based on selection of the fragment A 1308; however, the fragment E 1316 may be selected (and fragment F therefore excluded) without being based on an earlier selection of another fragment. [0124] An example of the exclusion constraint may be seen in company travel reimbursements. For example, such reimbursements may be made in at least two ways: by check or by direct deposit. In a particular instance, inclusion of one should exclude the other, so that the reimbursement recipient is not paid twice for the same expense. [0125] In the following discussion, the exclusion constraint may be referred to as E(Fp, Fm) where Fp and Fm are two non-empty subsets of F. Thus E(Fp, Fm) may be represented as E({fl, . . . fq}, {fl . . . fn}); fiεFp for i=1, . . . q; fjεFm for j=1, . . . n. Using this terminology (and similarly to the inclusion constraint), at least two cases may occur. Specifically, if all fragments from Fp are present in T, then all fragments from Fm must not appear in T. Conversely, if not all the fragments from Fp are present in T, then no rule is enforced on Fm. [0126] In addition to the five constraints (i.e., serial, order, fork, inclusion, exclusion) introduced and defined above, many other constraint type variations also may be used. For example, although the serial and order constraints, as defined above, do not require consecutive placement, an additional (or alternative) constraint might include such a requirement. Similarly, the fork constraint does not require parallel execution, yet an additional (or alternative) constraint might include such a requirement. [0127] Moreover, entirely different types of constraints may be used, in addition to (or instead of) the various constraint types discussed above. For example, “minimum/maximum” constraints may be used to impose a restriction on how many fragments must be included in a template. For example, if F(Fm) is given and |Fm|=n, then any k≦n fragments may be included. However, it may be necessary to more precisely specify the parameter k for certain processes. [0128] A constraint type to capture such a restriction may be defines as a max constraint, defined as X (Fm, k), where at most k elements from Fm must be included. Somewhat similarly, a min constraint may be defined as N (Fm, k), where at least k elements from Fm must be included. [0129] Another example of a constraint is a “multiple” constraint, designed to deal with workflows having multiple iterations and/or executions. For example, workflow graphs may contain “arbitrary cycles,” in which a sub process may be encapsulated in a typical do-while/repeat-until construct, with a given condition for iteration. As another example, “multiple executions” may refer to a situation in which a sub process may be required to be concurrently executed any k number of times, for example to fulfill the constraint “Perform a fragment k number of times,” where k is instance-dependent. [0130] In cases where the allowable number of multiple executions of an activity (sub-process) is known, the activity may be represented multiple times in the fragment set, but with unique identification parameters. For example, if a document can be reviewed up to 3 times, then a fragment set may be given as F={f1, f2, . . . Review1, Review2, Review3, . . . fn}, where the embedded task logic for all three of Review1, Review2, and Review3 is the same. A fork (or serial) constraint may then be defined, such as F({f1, . . . Review1, Review2, Review3, . . . }), thus allowing multiple executions of the same activity. [0131] When the number of allowable multiple executions is unknown, a new constraint type may be introduced. Such a constraint type may be defined as M (Fm), such that ∀fi,εFm for i=1, 2, . . . n, multiple executions of fi are permissible in T. [0132] [0132]FIG. 15 is a flowchart 1500 illustrating techniques for optimizing a use of constraints in implementing a pocket of flexibility. Such constraints may include, for example, the various constraints set forth above, including the serial and order constraints discussed with respect to FIG. 11, the fork constraint discussed with respect to FIG. 12, the inclusion constraint discussed with respect to FIG. 13, and the exclusion constraint discussed with respect to FIG. 14. [0133] In FIG. 15, a minimal specification of the constraints is obtained (1502). More specifically, a first constraint “n” of the various types of constraints to be considered (e.g., a structural constraint type such as the order constraint type, or a containment constraint, such as the inclusion or exclusion constraint type) is selected (1504). The constraint type “n” is then examined for any properties such as, for example, transitivities and/or redundancies (1506). Using these properties, constraints of the constraint type are expressed, or specified, in a concise manner. Techniques for detecting and considering properties for ensuring minimal specification are discussed in more detail below. [0134] In ensuring a minimal specification, conflicts between individual constraints of the constraint type “n” are resolved (1506). In other words, for example, if two order constraints (such as “A must follow B” and “B must follow A”) conflict with one another, then such conflicts are resolved. Such resolution may be gained either by way of a pre-determined criteria, and/or by way of user input as to which constraint should take precedence and/or which should be eliminated. Examples of techniques for resolving intra-constraint type conflicts, and how these techniques may be facilitated by use of transitivities and redundancies within the constraint types, are discussed in detail below. [0135] If the constraint type “n” is not the final constraint type to be considered (1510), then a next constraint type is selected (1504) and processed accordingly. Otherwise, redundancies/transitivities between the various constraint types may be considered (1512). Subsequently, the minimal specification may be completed (1502). [0136] It should be understood that the flowchart 1500 of FIG. 15, as with other flowcharts and processes described herein, is intended merely as an example, and does not imply, for example, a requirement of the described order of operations of the various processes. For example, consideration of inter-constraint type transitivities and redundancies (1512) need not be performed after all the constraint types have been individually considered, and could be performed in conjunction with, for example, consideration of intra-constraint type transitivities, redundancies, and/or conflicts. [0137] Once a minimal specification has been reached for each of the constraint types individually (i.e., a concise, intra-constraint type conflict-free specification), conflicts between the different constraint types are considered (1514). For example, a conflict between an order constraint and a fork constraint could occur, in the case where the order constraint specifies “B follows A,” while the fork constraint specifies “A forks with (e.g., is in parallel with) B.” Similarly, a conflict could occur between a fork and serial constraint, and well as between an inclusion and an exclusion constraint. [0138] Once all intra and inter-constraint conflicts are resolved, then it may be said that every fragment within the associated pocket of flexibility may be included in at least one valid template, and the pocket of flexibility is fully specified within a (presumably otherwise) valid process model. Thus, the operations of flowchart 1500 just described (1502-1514) may be thought to exist as part of designing the process model in flowchart 300 of FIG. 3 (304). [0139] Even though such a process model is considered valid and every fragment may appear in at least one valid template, these facts do not necessarily imply that a particular template, composed of various fragments, is itself valid. Therefore, a template, once compiled from various fragments as described above with respect to the flowchart 300 of FIG. 3 (314), is subsequently checked for validity (1516). This check may be performed automatically, and/or may require user input for resolution. [0140] Various aspects of the flowchart 1500 of FIG. 15 are discussed in more detail below. Further, various examples for implementing the operations described with respect to FIG. 15 also are described in more detail below. [0141] For example, as mentioned above, part of obtaining a minimal specification for each constraint type (1502) may involve consideration of properties of transitivity within the relevant constraint type (1506). For example, the Inclusion, Exclusion and Order Constraints all have a transitivity property. This property can be seen in the Order constraint, in that O({A, B}) and O({B, C}) imply that there is an order constraint on {A, B, C} such that O({A, B, C}) can replace the first two. [0142] Similarly for the Inclusion constraint, I({A}, {B, C}) and I({B}, {D, E}) imply that B, C, D, and E must all be present when A is present. Unlike the Order constraint, however, I({A}, {B, C, D, E}) does not imply I({B}, {D, E}), and as such cannot replace the above two inclusion constraints. [0143] [0143]FIGS. 16A and 16B are block diagrams illustrating a non-transitivity property of a serial and fork constraint, respectively. That is, for a serial constraint, S({A, B}) and S({B, C}) does not necessarily imply S({A, C}). For example, in FIG. 16A, a fragment B 1602a leads to a fork 1604 a, which splits into a task A 1606 a and a task C 1608 a, which are then synchronized at a task 1610 a. In this case, the fragment A 1606 a and the fragment C 1608 a are not serial. Nonetheless, the two constraints S({A, B}) and S({B, C}) are satisfied by this construct of FIG. 16A. Thus, transitivity is not implied for the two constraints. [0144] Similarly for the fork constraint, F({A, B}) and F({B, C}) does not imply F({A, C}). This is shown in FIG. 16B, in which a fork task 1604 b leads to a fragment A 1606 b in series with a fragment C 1608 b, which together are in parallel with a fragment B 1602 b. The fragment C 1608 b and the fragment B 1602 b are then joined at a synchronizing task 1610 b. In this case, fragment A 1606 b and fragment C 1608 b are in series with one another, and not subject to a Fork constraint. Nonetheless, the two constraints F({A, B}) and F({B, C}) are satisfied by the construct of FIG. 16B. Thus, transitivity is not implied for the two constraints. [0145] By using transitivities between constraints, where possible, a specification of constraints may be optimized by re-stating the constraint specification in a more concise manner. Similarly, and in addition to analyzing such transitivities, analyzing redundancies between constraints also may be useful in optimizing a given set of constraints, i.e., in obtaining a minimal specification for the constraint type(s) (1502). [0146] For example, in the two order constraints O({A, B, C}) and O({A, B}) are given, O({A, B, C}) subsumes O({A, B}), making the latter constraint redundant. Table 1 below identifies examples of where potential redundancies may exist. Redundancy may exist within constraint types, or it may exist across constraint types (for example, in the case of order and serial constraints). TABLE 1 Order Serial Fork Inclusion Exclusion Order ✓ ✓ Serial ✓ ✓ Fork ✓ Inclusion ✓ Exclusion ✓ [0147] In a more formal example of redundancies between order and serial constraints, if O(Fm) and S(Fn) are given and |Fm∩Fn|>1, then there is potential redundancy in S(Fn). A trivial case is when Fn ⊂Fm, in which case the entire constraint, S(Fn), is redundant. Thus the stronger constraint of Order will subsume the Serial constraint. [0148] Similarly, within the order constraint, if O(Fm) and O(Fn) are given and |Fn∩Fm|1>1, then there is potential redundancy within these constraints. A trivial case is when Fn ⊂Fm, in which case O(Fn) is redundant. Similarly, there can be redundancy between serial and fork constraints. [0149] With regard to Inclusion and Exclusion constraints, if I(Fp, Fm) and I(Fq, Fn) are given and Fp=Fq, then there is redundancy within these constraints. Thus, I(Fp, Fm) can be changed to I(Fp, Fm∪Fn), making I(Fq, Fn) redundant. Another trivial case of redundancy also exists when Fp∩Fm≠�. Thus I(Fp, Fm) can be changed to I(Fp, Fm−(Fp∩Fm)) without any loss. Similarly, there can be redundancy between exclusion constraints. [0150] Although properties such as transitivity and redundancy may be used to optimize constraints for a particular pocket of flexibility, they may not generally prevent fragments from within the pocket from being combined with one another. However, and as referred to above, where intra-constraint conflicts exist, one or more fragments within a pocket of flexibility (e.g,. build activity) may be prevented from being included in any valid instance template for the build activity in question. [0151] For example, O({A, B}) and O({B, A}) are conflicting constraints, since both can not be true simultaneously. Thus, any given template containing A and B will not be verified (although a graph containing one of A or B could be verified). [0152] Similar comments apply to the constraints S({A, B}) and F({A, B}), since the serial constraint requires that a path be present between A and B. and the fork constraint requires that a path not be present. Nonetheless, there may be a template constructed that does not contain either A or B that may be verified in spite of the conflict. However, if an additional constraint I({A}, {B}) is included, then together the three constraints will not allow any template containing A to be built. [0153] Table 2 identifies examples of conflicting constraint types. As shown, conflicts can arise within a constraint type (e.g., order, inclusion, exclusion) as well as between constraint types (e.g., fork/serial, fork/order, inclusion/exclusion). This result is consistent with FIG. 15 above, in which both intra-constraint type conflicts (1508) and inter-constraint type conflicts (1514) are considered. TABLE 2 Order Serial Fork Inclusion Exclusion Order ✓ ✓ Serial ✓ Fork ✓ ✓ Inclusion ✓ ✓ Exclusion ✓ ✓ [0154] With respect to intra-constraint type conflicts, the order constraint type may exhibit a conflict between two order constraints if any pair of fragments is present in both, but in conflicting order. That is, given O(Fm) and O(Fn), there will be a conflict when ∃fi, fjεFm such that fi precedes fj in Fm and ∃fs, ftεFn such that fs precedes ft in Fn and fi=ft and fj=fs. [0155] With respect to the inclusion (exclusion) constraint type, an inclusion (exclusion) constraint may exhibit a conflict when, for example, I(Fp, Fm) and I(Fq, Fn) are given, and Fp ⊂Fq and Fm ⊂Fn. [0156] Discussion of the inter-conflict type constraints. i.e. how they may exist and how they may be resolved, is provided in more detail below. For example, discussion is provided regarding serial/fork conflicts, order/fork conflicts, and inclusion/exclusion conflicts, and how these conflicts may be resolved with user input. [0157] Using the descriptions above of techniques for understanding and identifying transitivities and redundancies (1504, 1512), and for understanding and identifying intra- constraint type conflicts (1508), the following describes how these concepts may be used to arrive at a minimal specification for a given pocket of flexibility. [0158] Specifically, for example, due to transitivity and redundancy which may exist in constraints, it may not be possible to identify conflicts from an original constraint specification. For example, given a set of order constraints: O1({A, B, C}), O2({A, C, D, G}) and O3({A, G, B}), there is potential redundancy since |{A, B, C}∩{A, C, D, G}|>1. There also is transitivity in constraints O1 and O2, since A must precede B, and B must precede C according to O1, and, in turn, C must precede D (and D must precede G) according to O2, indicating an ordering constraint on {A, B, C, D, G}. [0159] Moreover, {A, B, C, D, G} and {A, G, B} are in conflict, due to the conflicting orders of the parameters B and G. A resolution of this conflict may rest on the user, since the ordering represents a semantic dependency between B and G. Nonetheless, an identification of this conflict by the system may be necessary to alert the user to the issue (for a corresponding correction) in the first place. [0160] In short, although small sets of constraints and fragment pairs may easily permit identification of intra-constraint type conflicts, the presence of transitivity and redundancy in larger constraint/fragment sets may make conflicts between order constraints difficult to detect. This potential difficulty leads to the minimal specification techniques referred to above with respect to FIG. 15 (1502), as discussed in more detail below. [0161] Specifically, using transitivity and eliminating redundancies, along with constraint- type specific techniques as described below, a minimal, conflict-free constraint set may be specified. In the context of FIG. 15, for example, this implies that, for constraint type “n,” n=order, serial, fork, inclusion, and exclusion constraint types. [0162] Beginning with the order constraint type, FIG. 17 is a diagram of a directed graph 1700 representing a set of order constraints. More specifically, the set of order constraints is referred to herein as C(O), and is defined on a number of fragments F1, F2, . . . Fn, where Fi ⊂F for i=1, 2, . . . n. Further, FOrder={F1, F2, . . . Fn}. Each set of order constraints C(O) may be associated with a directed graph such as the directed graph 1700, referred to generically as OG. [0163] An example of a set of order constraints might be: C(O)={O({A, B, C}), O({A, K, J}), O({A, C, J}), O({A, B, F, G}), O({F, H, I}), O({C, D, E}), and O({B, F, H})}. These seven order constraints within the set C(O) may be represented as the directed graph OG 1700, which may be used in generating a minimal specification for the set of order constraints C(O), as described above with respect to FIG. 15 (1502). [0164] By way of definition, a graph is considered to be a set of items connected by edges, where each item is called a vertex or node, and an edge is a connection between two vertices. In a directed graph, an edge goes from one vertex, the source, to another, the target, and thus makes a connection in only one direction. Thus, the set of order constraints C(O) may be represented by representing fragments as nodes and specifying edges therebetween. [0165] For example, in the directed graph OG 1700, a vertex or node A 1702 is connected to a node B 1704 which is connected to a node C 1706, which is connected to a node D 1708, which is connected to a node E 1710. The node B 1704 also is connected to a node F 1712, which is connected to a node G 1714. The node F 1712 also is connected to a node H 1716, which is connected to a node I 1718. The node C also is connected to a node J 1720, while the node A 1702 also is connected to a node K 1722. [0166] The OG 1700 can be seen to be a directed graph as defined above, since all nodes are connected by an edge going from one (source) node to another (target) node. Moreover, the OG 1700 can be seen to be acyclic, since no path (i.e., list of nodes, each having an edge from it to the next node) forms a cycle (i.e., no path starts and ends at the same node). [0167] Based on the above definitions, a cycle in the OG 1700 represents a conflict within the set of ordering constraints C(O), since, for example, such a cycle may represent a closed loop of fragments that cannot validly be included within a pocket of flexibility. As described below, a directed acyclic graph (DAG) such as the OG 1700 represents a conflict free set of order constraints, and further, may be used to determine C(O)min, which is defined as a minimal specification for C(O). That is, in C(O)min, all transitivity has been captured and redundancies eliminated, resulting in a more concise specification for the same set of order constraints. [0168] [0168]FIG. 18 is a flowchart 1800 illustrating a process used in determining a minimal specification for a set of order constraints. In FIG. 18, as referred to above, a directed graph OG for a set of order constraints C(O) may be referred to as a “cover” (i.e., specification) for multiple sets of order constraints C(O)1, 2, . . . . As long as the OGs for each C(O) within the multiple sets are equal to one another, then the various sets of order constraints C(O)1, 2, . . . may be considered to be equivalent to one another. Thus, the same OG may be generated by many different C(O)s, and such C(O)s are considered equivalent covers. [0169] Thus, a minimum cover C(O)min is the set C(O) having the smallest number of elements (order constraints), so that a plurality of minimum covers may exist for a given set of order constraints C(O). The minimal cover C(O)min is used in the constraint validation procedure that is described above with respect to FIG. 15 (1514) and discussed in more detail below. [0170] In finding a minimum cover for a given set of order constraints C(O), redundant order constraints are eliminated and transitivities are removed (1802); in particular, trivial or obvious redundant order constraints and transitivities are removed. For example, an order constraint that is subsumed within another order constraint(s), as described above with respect to FIG. 15, may be eliminated. This may be represented by stating that, for any Fm, FnεFOrder, then if Fn ⊂Fm, then C(O)=C(O)−{O(Fn)}. [0171] Then, the set C(O) is mapped onto a directed graph OG, such as the OG 1700 (1804). [0172] As seen with the OG 1700, a set of nodes for OG is given by the union of all subsets contained in FOrder, that is F1∪F2∪ . . . ∪Fn. Thus, each node represents a fragment, and an edge between any two nodes fi and fj is defined if fi and fj are elements of the same subset Fn, that is, an order constraint O(Fn) exists in C(O). [0173] Superfluous edges between two nodes are then removed (1806), where such superfluous edges exist when there exists another path in the same direction, between the same two nodes. This eliminates any redundant specification within the order constraints that was not earlier removed. [0174] If any conflicts exist within the directed graph OG (1808), i.e., if any cycles are observed with the directed graph OG, then these conflicts are resolved through user input (1810). For example, a user may be given the option to specify which conflicted order constraint(s) should be retained, and which should be eliminated or modified, based on underlying business logic. [0175] Once conflicts (if any) are resolved (1810), then the resulting directed graph should (may) map to a directed acyclic graph (DAG). If this is not the case (1812), then the above-described procedures may be repeated to remove any redundancies or conflicts that may have earlier been missed. [0176] The OG 1700 of FIG. 17 represents this stage during the process of determining a minimum cover for the set of order constraints represented by the OG 1700. That is, the OG 1700 represents a DAG having all redundancies removed. [0177] In the OG 1700, or a similar DAG, a minimal cover C(O)min may be determined (1814) simply by traversing the OG 1700 to find all maximal non-branching paths of the OG 1700 or other DAG, such that no two paths have an edge in common. In FIG. 17, then, C(O)min would include {O({A, B, C, D, E}), O({A, K, J}), O({C, J}), O({B, F, G}), O({F, H, I})}. [0178] [0178]FIG. 19 is a flowchart 1900 illustrating a process used in determining a minimal specification for a set of serial constraints. As shown in Table 2 above, a serial constraint set will not typically have intra-constraint type conflicts in the sense that order constraint sets may. Also, a serial constraint set will not typically exhibit transitivity. Therefore, with reference to FIG. 15, finding a minimal specification for a set of serial constraints (1502) typically involves, for example, eliminating redundancies (1506), but may not require eliminating intra-constraint type conflicts (1508). Nonetheless, finding the minimal specification (1502) may still be useful in during, for example, later determinations of inter- constraint type conflicts (1514). [0179] In FIG. 19, it is assumed that C(S) is a set of serial constraints defined on F1, F2, . . . Fn, where Fi ⊂F for i=1, 2, . . . n. Further, FSerial={F1, F2, . . . Fn}. Then a fully connected graph SG is to be associated with the set of serial constraints C(S), as a cover for the set. It should be understood that the graph SG should not be a directed graph, since the serial constraint does not impose or require an ordering on the relevant fragments. [0180] As seen above with respect to sets of order constraints, C(S)1 and C(S)2 are considered equivalent if and only if SG1=SG2. Similar to the minimal cover defined above for order constraints, a minimum cover C(S)min for a given C(S) is defined as the smallest set C(S)i that is equivalent to C(S). Again, there may be several minimum covers, all with the same number of elements (serial constraints), but with different arguments. [0181] As shown in FIG. 19, then, finding a minimum cover for a given C(S) may thus include first eliminating all redundant serial constraints (1902), that is, for any Fm, FnεFSerial, if Fn ⊂Fm, then C(S) C(S)−{S(Fn)}. Then, C(S) may be mapped onto SG (1904). The set of nodes for SG is given by the union of all subsets contained in FSerial, that is, F1∪F2∪ . . . ∪Fn, where each node represents a fragment. An edge between any two nodes fi and fj is defined if fi and fj are elements of the same subset Fn, that is, if a serial constraint S(Fn) exists in C(S). [0182] Finally, SG is traversed to determine C(S)min(1906). The determination of C(S)min from SG can be related to the problem of determining all (maximal) cliques within a graph, where a clique in a graph is a set of vertices, any two of which are adjacent. [0183] [0183]FIG. 20 is a diagram of a connected graph 2000 representing a set of serial constraints, referred to as the graph SG 2000. More specifically, the SG 2000 is defined with respect to a node A 2002, a node B 2004, a node C 2006, a node D 2008, and a node E 2010. The various nodes are subject to a set of serial constraints C(S)={S({A, B, D}), S({B, D, C}), S({A, C}), S({D, C}), S({B, D, E})}. The SG 2000 represents a mapping of these constraints onto a connected graph (1904), subsequent to a removal of any redundancies from the constraint set (1902). [0184] C(S)min may thus be extracted from the SG 2000 by finding all maximal cliques within the graph 2000. Thus, C(S)min comprises {S({A, B, C, D}) and S({B, D, E})}. As already described with respect to FIG. 15, C(S)min eliminates all redundancies found within the original specification, leading to a minimal specification (1502). [0185] Finding a minimal specification for a set of fork constraints C(F) is very similar to the process just described for a set of serial constraints C(S). Specifically, a set of fork constraints C(F) may be defined on F1, F2, . . . Fn where Fi ⊂F for i=1, 2, . . . n, where FFork={F1, F2, . . . Fn}. Then, a characterization of fork constraints can be made very similarly to serial constraints, except that the semantics of the two constraints are different, in that an edge in a fully connected graph FG representing C(F) represents an absence of a path between the corresponding fragments in any valid template, rather than a presence of such a path. Nonetheless, since fork and serial constraint sets have the same properties (i.e., no transitivity, no conflict, but potential redundancy), the minimal specification can be determined in a similar way. [0186] Specifically, sets of fork constraints C(F)1 and C(F)2 are equivalent if and only if cover FG1=cover FG2. Similar to minimal cover for order and serial constraints, for a given C(F), a minimum cover C(F)min is defined as the smallest set C(F)i that is equivalent to C(F). Again, there may be several minimum covers, all with the same number of elements (fork constraints), but with different arguments. [0187] An example procedure for finding a minimum cover C(F)min for a given C(F), is the same as for serial constraints, as it is described above with respect to FIG. 19. Specifically, redundant serial constraints are eliminated, that is, for any Fm, FnεFSerial, if Fn ⊂Fm, then C(F)=C(F)−{F(Fn)}. Then, C(F) is mapped onto FG, and FG is traversed to determine C(F)min. [0188] [0188]FIG. 21 is a flowchart 2100 illustrating a process used in determining a minimal specification for a set of containment constraints. The containment constraints may include, for example, inclusion and/or exclusion constraints. FIGS. 22A, 22B, and 23 are truth tables for various containment constraints. [0189] As described above with respect to FIG. 15, a minimal specification may be determined (1502) for a particular type of constraint (e.g., serial, order, or fork), by, for example, eliminating redundancies (1506) and eliminating intra-constraint type conflicts (1508). Then, inter-constraint type conflicts may be resolved (1514). [0190] In the following discussion of containment constraints, however, techniques are described which resolve conflicts both within constraint types (e.g., within inclusion or within exclusion constraint sets) and between constraint types (e.g., between inclusion and exclusion constraint sets). As a result, conflicts may be resolved and a minimal specification may be obtained for a set of containment constraints in a convenient and expeditious manner. [0191] In FIG. 21, a truth table TT is formulated for each inclusion/exclusion constraint within sets of inclusion and exclusion constraints (2102). The truth table is a representation of the logical relation between constraint arguments. Although not explicitly shown in FIG. 21, truth table formulation may include eliminating any redundant constraints within a given constraint set, as described above. [0192] For example, for an Inclusion constraint I({A}, {B}), a truth table 2202 of FIG. 22A illustrates that inclusion of constraint A necessitates inclusion of constraint B, whereas non-inclusion of constraint A implies that constraint B may or may not be included. Conversely, for an Exclusion constraint E({A}, {B}), a truth table 2204 of FIG. 22A illustrates that inclusion of constraint A necessitates non-inclusion of constraint B, whereas non-inclusion of constraint A implies that constraint B may or may not be included. [0193] Next, two containment constraints (and their associated truth tables) are selected for conflict analysis (2104). Specifically, a conflict is indicated if the two tables have common columns (2106) and, if so, if the two tables have a different collection of rows within those common columns (2108). If so, then a conflict is determined to exist between the two constraints (2110), and may be resolved through user input (2112). If the two selected constraints represent a final set of constraint pairs (2114), then the process ends (2116). Otherwise, the next constraint pair is selected (2104). [0194] For example, in the tables 2202 and 2204 of FIG. 22A, a column 2206 of table 2202 is common with a column 2208 of the table 2204. Moreover, a row 2210 of the table 2202 and a row 2212 of the table 2204 are conflicting, i.e., non-common. Therefore, a conflict exists between the two constraints I({A}, {B}) and E({A}, {B}). [0195] In the example of FIG. 22B, a table 2214 represents a truth table for the inclusion constraint I({A}, {B, C}), while a table 2216 represents a truth table for the exclusion constraint E({B}, {C}). As can be seen, columns 2218 and 2220 of the table 2214 have elements in common with columns 2222 and 2224, respectively, of the table 2216. However, the rows 2226 of the table 2214 conflict with rows of the table 2216, since the rows 2226 do not exist in the table 2216. Therefore, a conflict exists between the constraints represented by the tables 2214 and 2216. [0196] Although FIGS. 22A and 22B each represent an Inclusion and an Exclusion constraint, the process of the flowchart 2100 is equally applicable to two Inclusion constraints, and/or two Exclusion constraints. Thus, the process of the flowchart 2100 is capable of resolving intra-constraint type and inter-constraint type conflicts for sets of containment-type constraints. [0197] Furthermore, in the process of FIG. 21, truth tables with common columns but no conflicting rows can be combined, such that a single truth table can be constructed for all constraints with common elements. For example, FIG. 23 illustrates a truth table 2302 for the Inclusion constraint I({A}, {B}), a truth table 2304 for the Inclusion constraint I({B}, {C}), and a truth table 2306 for the Exclusion constraint E({C}, {D}). The tables 2302, 2304, and 2306 have common columns 2310, 2312, and 2314, but no rows directly conflict with one another. As a result, the table 2308 may be formed that combines the tables 2302, 2304, and 2306, and that effectively provides a list of allowable combinations of fragments. [0198] With respect to FIG. 15, the above discussion has provided examples of techniques for finding a minimal specification for a set(s) of constraints (1502). Specifically, algorithms for generating a minimal cover for each set of constraints of a given constraint type are discussed above, which include, as needed, elimination of transitivities/redundancies (1506) and resolution of intra-constraint type conflicts (1508). [0199] Once a minimal specification has been generated, inter-constraint type conflicts may be resolved (1514). For example, types of inter-constraint type conflicts discussed above and shown in Table 2 include fork/order, fork/serial and inclusion/exclusion conflicts. As already explained, the generation of minimal specification may involve eliminating (inter-constraint type) conflicts between inclusion and exclusion constraints, or conflicts between inclusion and exclusion constraints may be resolved separately from intra-constraint type conflicts. The remaining conflicting constraints, e.g., fork/order and fork/serial, may be determined, for example, as discussed below. [0200] Specifically, with respect to inter-conflict type constraints, a conflict exists between a fork and serial constraint if they have any 2 or more fragments in common. That is, given S(Fm) and F(Fn), there will be a conflict when |Fm∩Fn|>1. Similarly, with respect to fork and order constraints, a conflict exists between a fork and order constraint if they have any two or more fragments in common. That is, given O(Fm) and F(Fn), there will be a conflict when |Fm∩Fn|>1. [0201] With respect to inclusion and exclusion constraints, an inter-constraint type conflict may exist inasmuch as a constraint set cannot have inclusion and exclusion constraints on the same fragment. That is, given I(Fp, Fm), E(Fq, Fn), there will be a conflict when Fp=Fq and Fm∩Fn≠�. [0202] Additionally, the constraint set of: I(Fp, Fm), E(Fq, Fn), and Fq∪Fn ⊂Fm or Fp∪Fm ⊂Fn provides a conflict. This can be seen by considering the constraint set of: I({A}, {B, C}) and E({B}, {C}), because any template containing A will not be verified against the above constraints. That is, a conflict results from that fact that any template containing A must contain B and C, while at the same time, any template containing B must not contain C. [0203] After identifying such conflicts, actual resolution of the conflicts may be dependent on the user. For example, of two conflicting constraints O({A, B, C}) and F({A, B, D}) are given, the inter-constraint type conflict is identified since |{A, B, C}∩{A, B, D}| is not less than two. A resolution of this conflict may result in the fork constraint being changed to F({A, D}) and F({B, D}), while the order constraint remains the same. Similarly, the order constraint may be changed to O({A, C}) and O({B, C}), with the fork constraint remaining the same. Another possible conflict resolution may involve dropping the order constraint altogether. Many such possibilities may exist for resolving a given conflict, and, as described above, a given resolution will typically be selected based on the business logic or user needs/preferences in the given situation. [0204] Although not discussed in detail above, it should be understood that, as a result of choices made during conflict resolution, the constraint set may be changed. These changes made may need to be validated by iterating through the above procedures, eventually generating a minimal and conflict free constraint set. Thus, Cmin leads to Cvalid, where Cvalid represents the minimal and conflict-free set of constraints. [0205] Such a minimal and conflict-free constraint set ensures that every fragment within a given pocket of flexibility may be included in at least one valid composition of the fragments (i.e., template). Nonetheless, this fact does not imply that every fragment may validly be included in any template, particularly given the objective that a relatively small set of fragments enables a relatively large number of processes. As a result, and as described above with respect to FIG. 15, a given template may require verification of the fact that selected fragments actually comply with the applicable constraint set(s) (1516). [0206] In one implementation, a user may construct a template from a set of fragments within a pocket of flexibility, and then the constructed template may thereafter be validated. In another implementation, and as referred to above with respect to FIGS. 7 and 8, a user may progressively construct a template by selecting from among a set of fragments, where the available set of fragments is reduced after each selection to include only those remaining fragments that may validly be included within the template being formed. In the latter implementation, a simply user interface may be designed that permits the user to easily select from among available fragments. Moreover, when a given selection of the user results in only a single combination of remaining fragments remaining to be validly selected, then these remaining fragments may be automatically combined into a completed, valid template. [0207] FIGS. 24A-24K are block diagrams of examples of valid templates composed from a given sets of fragments and constraints. Conversely, FIGS. 25A-25C are block diagrams of examples of invalid templates composed from the sets of fragments and constraints of FIGS. 24A-24K. [0208] Specifically, FIGS. 24A-24K and 25A-25C assume a set of fragments defined as: F={f1, f2, f3, f4, f5, f6, f7, f8, f9, f10}. Additionally, FIGS. 24A-24K and 25A-25C assume a minimally-specified, conflict-free constraint set of process requirements defined as: O({f1, f3, f5}); F ({f2, f3, f4, f7}); and I({f7}, {f2, f3}). [0209] In FIGS. 24A-24K and 25A-25C, a begin command 2402 and an end command 2404 bound the various templates. The fragments are referred to as a fragment f1 2406, a fragment f2 2408, a fragment f3 2410, a fragment f4 2412, a fragment f5 2414, a fragment f6 2416, a fragment f7 2418, a fragment f8 2420, a fragment f9 2422, and a fragment f10 2424. Finally, a fork task 2426 and a corresponding synchronizer task 2428 are available for enacting the fork constraint. [0210] The templates of FIGS. 24A-24K and 25A-25C may be individually checked to verify that they do (or do not) comply with the various constraints. For example, it can be seen that the fragment f1 2406 is in violation of the relevant Order constraint in FIG. 25A, and that fragment f2 2408 is in violation of the Inclusion constraint in FIG. 25B. FIGS. 24A-24K and 25A-25C, of course, do not represent all possible valid/invalid templates that may be constructed with the given fragments and constraints, but rather represent just a few examples of the many possibilities that may exist. [0211] In the cases of FIGS. 24A-24K and 25A-25C, verification of the applicable constraints may be determined by visual inspection. Once the number of constraints increases and/or the template built is large and complex, however, this visual verification may not be sufficient. Thus, algorithms for verifying these constraints may be utilized. [0212] Plausible algorithms are presented below for each constraint type as corresponding code sections. These algorithms are based on the set of validated constraints Cvaild, as determined by the constraint validation procedure given in the previous section. Generally speaking, the algorithms ensure that a given constraint type is met by a given set of fragments. For example, that an order limitation specified in an Order constraint is met, and similarly for Fork, Serial, Inclusion, and Exclusion constraint sets. [0213] For the order constraint of a set of fragments Fm, i.e., O(Fm), an algorithm to verify the order constraint may be used as demonstrated in Code Section 1: Code Section 1 Verification of Order Constraint O (Fm) GraphNodes: Set of Nodes in the workflow graph OrderFrags: Set of fragments in Fm Check: Set of Nodes //Where the sets GraphNodes, OrderFrags, and Check have elements of the //same type, i.e. a fragment will be a node in the graph //InDownPath (X, Y) returns true when a path from X to Y can be found in the //workflow graph //Count (S) returns the number of elements in the set S Begin Check := OrderFrags Intersect GraphNodes If Check = {} then Return (“No Constraint Violation”) For i = 1 to Count (Check) −1 If InDownPath (Check[i], Check[i+1]) <> TRUE Then Return-Error (“Order Constraint Violated”) End-If End-For Return (“No Constraint Violation”) End [0214] For the serial constraint of a set of fragments Fm, i.e., S(Fm), an algorithm to verify the serial constraint may be used as demonstrated in Code Section 2: Code Section 2 Verification of Serial Constraint S (Fm) GraphNodes: Set of Nodes in the workflow graph SerialFrags: Set of fragments in Fm Check: Set of Nodes //Where the sets GraphNodes, SerialFrags, and Check have elements of the //same type, i.e. a fragment will be a node in the graph //InPath (X, Y) returns true when a path between X and Y can be found in the //workflow graph. InPath (X, X) returns true. //Count (S) returns the number of elements in the set S Begin Check := SerialFrags Intersect GraphNodes If Check = {} then Return (“No Constraint Violation”) For i = 1 to Count (Check) For j = 1 to Count (Check) If InPath(Check[i], Check[i]) <> TRUE Return-Error (“Serial Constraint Violated”) End-If End-For End-For Return (“No Constraint Violation”) End [0215] For the fork constraint of a set of fragments Fm, i.e., F(Fm), an algorithm to verify the fork constraint may be used as demonstrated in Code Section 3: Code Section 3 Verification of Fork Constraint F (Fm) GraphNodes : Set of Nodes in the workflow graph ForkFrags: Set of fragments in Fm Check: Set of Nodes //Where the sets GraphNodes, ForkFrags, and Check have elements of the //same type, i.e. a fragment will be a node in the graph //InPath (X, Y) returns true when a path between X and Y can be found in the //workflow graph. InPath (X, X) returns true. //Count (S) returns the number of elements in the set S Begin Check := ForkFrags Intersect GraphNodes If Check = {} then Return (“No Constraint Violation”) For i = 1 to Count (Check) For j = 1 to Count (Check) If InPath(Check[i], Check[j]) = TRUE Return-Error (“Fork Constraint Violated”) End-If End-For End-For Return (“No Constraint Violation”) End [0216] For the inclusion constraint of a set of fragments Fp, Fm, i.e., I(Fp, Fm), an algorithm to verify the inclusion constraint may be used as demonstrated in Code Section 4: Code Section 4 Verification of Inclusion Constraint I (Fp, Fm) GraphNodes : Set of Nodes in the workflow graph Present: Set of fragments in Fp Include: Set of fragments in Fm //Where the sets GraphNodes, Present, Include have elements of the same //type, i.e. a fragment will be a node in the graph Begin If Present Subset GraphNode Then If Include Subset GraphNodes Then Return (“No Constraint Violation”) Else Return-Error (“Inclusion Constraint Violated”) Else Return (“No Constraint Enforced”) End-If End [0217] For the exclusion constraint of a set of fragments Fm, i.e., E(Fp, Fm), an algorithm to verify the exclusion constraint may be used as demonstrated in Code Section 5: Code Section 5 Verification of Exclusion Constraint E (Fp, Fm) GraphNodes: Set of Nodes in the workflow graph Present: Set of fragments in Fp Exclude: Set of fragments in Fm //Where the sets GraphNodes, Present, Exclude have elements of the same //type, i.e. a fragment will be a node in the graph Begin If Present Subset GraphNode Then If Exclude Intersect GraphNodes = {} Then Return (“No Constraint Violation”) Else Return-Error (“Exclusion Constraint Violated”) Else Return (“No Constraint Enforced”) End-If End [0218] Once a template has been verified, the concretized fragments from within the pocket of flexibility may be released for use. The template may be used once, or may be saved for future use. In this way, users may have access to a large number of templates, while still being assured of the validity of all of the templates. [0219] As described above, a flexible workflow may be provided by designing a process model that includes one or more pockets of flexibility. The process model also may include various pre-defined tasks having pre-defined relations therebetween (i.e., a core of the process model), in addition to the pocket(s) of flexibility. The pocket of flexibility may include workflow fragments that may be joined together into multiple instances of sub- workflows or (instance) templates, subject to various pre-defined constraints. The pocket of flexibility also may include a set of pre-defined tasks having pre-defined relations therebetween (i.e., a core template of the pocket of flexibility). [0220] In implementing the process model, a user may encounter a pocket of flexibility, and may select from, for example, the various fragments, so as to construct an instance template that is consistent with the user's current needs. The fragments may be incrementally presented to the user on a user interface, perhaps based on (previous) user selections, such that only those fragments determined to be combinable in a valid way may be selected by the user. [0221] In this way, a user who may have little or no experience with, for example, workflow languages or terminology, may easily be able to construct a needed instance template, and be confident that the template is valid for distribution and implementation by workflow performers. As a result, difficulties in dealing with change in workflow systems, which has been a factor in limiting deployment of workflow technology in some settings, may be mitigated. Moreover, this mitigation may be achieved without compromising the simplicity and genericity of a workflow specification language. [0222] A number of implementations have been described. Nevertheless, it will be understood that various modifications may be made. Accordingly, other implementations are within the scope of the following claims. Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS5734837 *Jan 14, 1994Mar 31, 1998Action Technologies, Inc.Method and apparatus for building business process applications in terms of its workflowsUS5937388 *Mar 21, 1997Aug 10, 1999Hewlett-Packard CompanySystem and method for performing scalable distribution of process flow activities in a distributed workflow management systemUS5999911 *Jun 2, 1995Dec 7, 1999Mentor Graphics CorporationMethod and system for managing workflowUS6041306 *Mar 21, 1997Mar 21, 2000Hewlett-Packard CompanySystem and method for performing flexible workflow process execution in a distributed workflow management systemUS6081268 *Sep 3, 1997Jun 27, 2000Digital Equipment CorporationMethod for ignoring redundant constraints in a graphic editorUS7184967 *Mar 6, 2001Feb 27, 2007Microsoft CorporationSystem and method utilizing a graphical user interface of a business process workflow scheduling programUS20030204429 *May 31, 2002Oct 30, 2003Martin BotscheckProcessing life and work eventsUS20030225607 *Jun 4, 2002Dec 4, 2003Dragan KopunovicCommoditized information management system providing role aware, extended relationship, distributed workflows* Cited by examinerReferenced byCiting PatentFiling datePublication dateApplicantTitleUS7580911 *Aug 7, 2006Aug 25, 2009Xerox CorporationWorkflow auto generation from user constraints and hierarchical dependence graphs for workflowsUS7739080 *Apr 19, 2004Jun 15, 2010Versata Development Group, Inc.Consolidation of product data modelsUS7836002Jun 27, 2006Nov 16, 2010Microsoft CorporationActivity-centric domain scopingUS7848942 *Dec 7, 2010Sap AktiengesellschaftDistribution of integrated business process modelsUS7970637Jun 28, 2011Microsoft CorporationActivity-centric granular application functionalityUS8103536Aug 13, 2010Jan 24, 2012Microsoft CorporationUnified model for authoring and executing flow-based and constraint-based workflowsUS8170901May 1, 2012Microsoft CorporationExtensible framework for designing workflowsUS8275647 *Sep 25, 2012Genesys Telecommunications Laboratories, Inc.Method for assembling a business process and for orchestrating the process based on process beneficiary informationUS8326864 *Dec 4, 2012International Business Machines CorporationMethod, system, and computer program product for implementing automated worklistsUS8332806 *Nov 30, 2009Dec 11, 2012International Business Machines CorporationStepwise template integration method and systemUS8364514Jan 29, 2013Microsoft CorporationMonitoring group activitiesUS8407150 *Mar 26, 2013Fujitsu LimitedReliability evaluation device, reliability evaluation method, and computer program productUS8413150 *Apr 2, 2013Sap AgSystems and methods for data aware workflow change managementUS8429668 *Dec 7, 2007Apr 23, 2013Sap AgWorkflow task re-evaluationUS8442852Nov 14, 2007May 14, 2013Xerox CorporationWorkflow auto generation from user constraints and hierarchical dependence graphs for workflowsUS8683436 *Dec 19, 2007Mar 25, 2014Sap AgTimer patterns for process modelsUS8744903 *Apr 29, 2008Jun 3, 2014Sap AgEvent resolutionUS8943461Sep 14, 2012Jan 27, 2015International Business Machines CorporationStepwise template integration method and systemUS8949834 *Apr 7, 2010Feb 3, 2015Yahoo! Inc.Modeling and scheduling asynchronous incremental workflowsUS9052879Feb 18, 2005Jun 9, 2015International Business Machines CorporationMapping assurance method and apparatus for integrating systemsUS9082109Sep 24, 2012Jul 14, 2015Genesys Telecommunications Laboratories, Inc.Method for assembling a business process and for orchestrating the process based on process beneficiary informationUS20040177139 *Mar 3, 2003Sep 9, 2004Schuba Christoph L.Method and apparatus for computing priorities between conflicting rules for network servicesUS20050171833 *Oct 28, 2004Aug 4, 2005Wolfram JostSystems and methods for acquiring time-dependent data for business process analysisUS20060074704 *Jan 31, 2005Apr 6, 2006Microsoft CorporationFramework to model cross-cutting behavioral concerns in the workflow domainUS20060074730 *Jan 31, 2005Apr 6, 2006Microsoft CorporationExtensible framework for designing workflowsUS20060074735 *Feb 23, 2005Apr 6, 2006Microsoft CorporationInk-enabled workflow authoringUS20060074737 *Jun 17, 2005Apr 6, 2006Microsoft CorporationInteractive composition of workflow activitiesUS20060143611 *Dec 28, 2004Jun 29, 2006Wasim SadiqDistribution of integrated business process modelsUS20060190931 *Feb 18, 2005Aug 24, 2006Scott George MMapping assurance method and apparatus for integrating systemsUS20060195494 *Feb 9, 2006Aug 31, 2006Process Path, Inc.Compiler, system and method for defining, assigning, executing and monitoring processes and tasks in process management applicationsUS20070006123 *May 18, 2006Jan 4, 2007Yoshiro MatsuiWork flow system, work flow processing method and work flow processing programUS20070094211 *Aug 7, 2006Apr 26, 2007Xerox CorporationWorkflow auto generation from user constraints and hierarchical dependence graphs for workflowsUS20070283206 *Jan 16, 2007Dec 6, 2007Fujitsu LimitedReliability evaluation device, Reliability evaluation method, and computer program productUS20070297590 *Jun 27, 2006Dec 27, 2007Microsoft CorporationManaging activity-centric environments via profilesUS20070299712 *Jun 27, 2006Dec 27, 2007Microsoft CorporationActivity-centric granular application functionalityUS20070299713 *Jun 27, 2006Dec 27, 2007Microsoft CorporationCapture of process knowledge for user activitiesUS20070299949 *Jun 27, 2006Dec 27, 2007Microsoft CorporationActivity-centric domain scopingUS20070300174 *Jun 27, 2006Dec 27, 2007Microsoft CorporationMonitoring group activitiesUS20070300185 *Jun 27, 2006Dec 27, 2007Microsoft CorporationActivity-centric adaptive user interfaceUS20070300225 *Jun 27, 2006Dec 27, 2007Microsoft CoporationProviding user information to introspectionUS20080065455 *Nov 14, 2007Mar 13, 2008Xerox CorporationWorkflow auto generation from user constraints and hierarchical dependence graphs for workflowsUS20080313090 *Jun 18, 2007Dec 18, 2008Leonid PortmanInteraction-management methods and platform for client-agent interaction-related environmentsUS20090013085 *Sep 18, 2008Jan 8, 2009Hadas Liberman Ben-AmiInteraction-management methods and platform for client-agent interaction-related environmentsUS20090150900 *Dec 7, 2007Jun 11, 2009Marek KowalkiewiczWorkflow task re-evaluationUS20090165001 *Dec 19, 2007Jun 25, 2009Baeuerle Stefan ATimer Patterns For Process ModelsUS20090171729 *Dec 27, 2007Jul 2, 2009Anisimov Nikolay AMethod for Assembling a Business Process and for Orchestrating the Process Based on Process Beneficiary InformationUS20090271232 *Oct 29, 2009Sap Agdietmar-Hopp Allee 16 WalldorfEvent resolutionUS20090281777 *Nov 12, 2009Stefan BaeuerleWorkflow Modeling With Flexible BlocksUS20100010853 *Jan 14, 2010Fujitsu LimitedMethod and apparatus for analyzing business process flowUS20100114926 *Oct 21, 2008May 6, 2010International Business Machines CorporationMethod, system, and computer program product for implementing automated worklistsUS20100293027 *Apr 8, 2008Nov 18, 2010Eric Denis Du FosseWorkflow engine for media production and distributionUS20100306000 *Aug 13, 2010Dec 2, 2010Microsoft CorporationUnified model for authoring and executing flow-based and constraint-based workflowsUS20110029983 *Feb 3, 2011Sap AgSystems and methods for data aware workflow change managementUS20110054970 *Nov 9, 2010Mar 3, 2011Steven MinskyRelational logic management systemUS20110131545 *Nov 30, 2009Jun 2, 2011Vasile PatrascuStepwise template integration method and systemUS20110252427 *Apr 7, 2010Oct 13, 2011Yahoo! Inc.Modeling and scheduling asynchronous incremental workflowsUS20120078677 *Dec 9, 2011Mar 29, 2012Microsoft CorporationUnified model for authoring and executing flow-based and constraint-based workflowsUS20130297340 *Dec 9, 2011Nov 7, 2013Koninklijke Philips Electronics N.V.Learning and optimizing care protocolsUS20150254679 *Mar 7, 2014Sep 10, 2015Genesys Telecommunications Laboratories, Inc.Vendor relationship management for contact centersCN103384886A *Dec 9, 2011Nov 6, 2013皇家飞利浦电子股份有限公司Learning and optimizing care protocols.WO2007077091A1 *Dec 7, 2006Jul 12, 2007Siemens AktiengesellschaftData transmission method between a first data processing unit and a second data processing unit* Cited by examinerClassifications U.S. Classification705/7.13, 705/7.26, 705/7.27International ClassificationG06Q10/06, G06Q10/10Cooperative ClassificationG06Q10/06311, G06Q10/06316, G06Q10/0633, G06Q10/10European ClassificationG06Q10/10, G06Q10/06311, G06Q10/0633, G06Q10/06316Legal EventsDateCodeEventDescriptionFeb 10, 2004ASAssignmentOwner name: SAP AKTIENGESELLSCHAFT, GERMANYFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:SADIQ, SHAZIA;SADIQ, WASIM;ORLOWSKA, MARIA E.;REEL/FRAME:014326/0034;SIGNING DATES FROM 20040106 TO 20040116Owner name: SAP AKTIENGESELLSCHAFT, GERMANYFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:SADIQ, SHAZIA;SADIQ, WASIM;ORLOWSKA, MARIA E.;SIGNING DATES FROM 20040106 TO 20040116;REEL/FRAME:014326/0034Jul 28, 2014FPAYFee paymentYear of fee payment: 4Aug 26, 2014ASAssignmentOwner name: SAP SE, GERMANYFree format text: CHANGE OF NAME;ASSIGNOR:SAP AG;REEL/FRAME:033625/0334Effective date: 20140707RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services