As with all types of patterns, we do not claim the designs or analyses behind these patterns are novel -- rather, we have identified each of these patterns in at least three separate systems: systems that were completed before we began investigating patterns systematically. We hope that none of these patterns will come as any surprise to those experienced with writing any form of use cases. We have, however, found that these simple patterns extremely useful to people have identified an interaction as a potential use case, but do not known how best to actually write the essential use case to represent that interaction.
None of these patterns are specific to essential use cases -- there are obvious analogues for conventional forms of use cases. We do not claim that these patterns could not be developed by examining conventional use cases, although no such patterns have yet been identified to our knowledge. We do believe, however, that these patterns would not be anywhere nearly as obvious written with a conventional use cases forms, because the amount of information and the length of the more conventional forms would make analysis significantly harder than with essential use cases.
In terms of identifying patterns, the key advantage of essential use cases is precisely that they focus on the essential, abstract nature of the interaction between an actor and a system, and characterize a system's interface without describing the implementation of that interface in detail. This is clearly useful for user interface design: this paper argues that this is useful in object-oriented design more generally. This is precisely the kind of information that you need to recognize or use patterns: to quote Gamma et. al.: ``A design pattern names, abstracts, and identifies the key aspects of a common design structure .... The design pattern identifies ...the distribution of responsibilities.''. In the same way, an essential use case abstracts and identities the key aspects of an interaction between an actor and a system -- the sequence of user intentions and system responsibilities. The presentation of these use case patterns is simplified by having to only discuss the minimal details associated with essential use cases, making the patterns easier to understand, in much the same way that the presentation of a design pattern concentrates primarily on objects, their relationships, and their important responsibilities, rather than the low-level details of the code that will be needed to implement the pattern.