WO2000054199A2

WO2000054199A2 - Methods and systems for performing workflow

Info

Publication number: WO2000054199A2
Application number: PCT/US2000/006264
Authority: WO
Inventors: David B. Black; Michael J. Morgan; Brian G. Beuning
Original assignee: Paysys International, Inc.
Priority date: 1999-03-11
Filing date: 2000-03-10
Publication date: 2000-09-14
Also published as: WO2000054199A3; AU3735400A

Abstract

A declarative approach to programming involves providing a transaction engine and a repository. The transaction engine controls the behavior of an application by routing messages between a pre-defined group of work steps. The repository includes a declaration space within which components are defined as well as the relationship between the components. An administrator includes an Integrated Development Environment (IDE) editor for allowing developers to access and modify portions of the repository. In the preferred embodiment, developers are allowed to define attributes of data elements, define relationships between the data elements, and to organize data elements into messages through the repository. Furthermore, developers are able to define the logical-to-physical mapping in the repository, such as by defining message stores. An application is defined by a workflow comprised of a number of work steps interconnected to each other. The workflow and the work steps are also defined within the repository. The workflow that may be implemented allows for both interactive worksteps requiring user intervention and non-interactive worksteps. A workflow can be dynamic and incorporate champion challenger techniques and may have worksteps executed in parallel to each other.

Description

METHODS AND SYSTEMS FOR PERFORMING WORKFLOW

RELATED APPLICATIONS This patent application claims priority to, and incorporates herein by reference, co- pending provisional patent application Serial No. 60/123,977 filed on March 11, 1999. Also, this application is related to co-pending provisional patent application Serial No. 60/123,976, filed on March 1 1, 1999, co-pending provisional patent application Serial No. 60/123,886, filed on March 11, 1999, to co-pending utility patent application filed on March 10, 2000, entitled "Methods and Systems for Managing Financial Accounts," and co-pending utility patent application filed on March 10, 2000, entitled "Methods and Systems for Developing Applications and for Interfacing with Users."

FIELD OF THE INVENTION

The present invention relates generally to methods and systems for performing workflow and, more particularly, to systems and methods for providing workflow with declarative programming techniques. According to another aspect, the invention relates generally to systems and methods implementing workflow for use in managing financial accounts.

BACKGROUND OF THE INVENTION

Before the advent of computers, workflow in an organization involved routing items from one person to the next. The typical workflow can generally be envisioned as a set of in boxes and out boxes. Personnel within an organization select items from their in- box, perform their assigned task, and then place the completed items in their out box. The items in the out boxes are then collected and distributed to the appropriate in boxes of personnel who need to perform the next item of work on the items.

A possible workflow in organization for purchasing a part from an outside vendor will now be described. The workflow starts with a product engineer who is working on a new product that requires a part from an outside vendor. The established workflow in the company requires the product engineer to complete an order form and then send the completed form to his or her supervisor. The supervisor reviews the request to ensure its legitimacy and, if it is not approved, returns the request to the product engineer who then needs to select a different part, vendor, or otherwise modify the request. If the supervisor approves the request, the supervisor makes the appropriate notation on the request and sends the request to accounting. In the accounting department, a purchasing agent reviews the request and selects an appropriate account from which the vendor will be paid. The purchasing agent returns the request to the supervisor for additional input or, if it is approved, to an ordering department.

The typical workflow within an organization has several limitations. For instance, the workflow is usually rather rigid and inflexible. Each person has assigned tasks and those tasks are usually not modified. After a person finishes the assigned task, the person is required to pass the work item to a designated person. Thus, the work items follow a predefined path along the fixed workflow whereby the same items from one person's in- box are always routed to a certain person's out-box. Workflows often do not permit any variation in the routing, even if such a detour would be in the best interest of the overall workflow. The workflow typically has preset inputs that are allowed by a person and may not accommodate unusual circumstances. Because only preset inputs are allowed, a person may be forced to respond in a way that ensures integrity of the overall process but which is inefficient and can be considered bureaucratic.

In addition to being rigid and inflexible, many workflows are inefficient. As discussed above, work items are often routed along a path and have work performed on them by a plurality of people. Although the work is passed successively from one person to the next person, the work performed by one person does not necessarily need to wait until a person upstream along the workflow works on the item. Nonetheless, some work must wait until preceding unrelated work is performed on the work item, which slows down the overall workflow.

Some computer-implemented systems and methods have been developed to assist in the processing of work within organizations, such as the above-described workflow. These systems have mainly been directed to automating the routing of items from one person's out-box to another person's in-box. With these systems, a person within the organization has a computer-implemented "in-box" which consists of a group of files or documents. The person selects one of these items and performs his or her task, such as by entering data into the file or document. After a person performs his or her assigned task, the item is routed through a network to the next person's computerized "in-box."

The computer-implemented automated workflows still remain relatively rigid and inflexible. The computer-implemented workflow systems may reduce the need to route paper copies from one person to the next person but still require the routing of work along fixed paths. Many computer-implemented workflows therefore remain unable to accommodate variations in the routing of work, even when such detours may be in the best interest of a company. Many computer-implemented workflows therefore merely automate existing workflows, which may not be ideal for the organization. Even though workflows may have some drawbacks, such as those described above, companies can benefit greatly by defining and implementing a workflow. A workflow, for example, provides uniformity within a company. Rather than allowing each person to act in a manner that he or she believes is appropriate, a well-defined workflow is intended to have all personnel within the company respond in a consistent and identical fashion.

A company must be committed to a workflow in order for it to be successful. For some companies, especially for workflows involving customer service, a substantial portion of a company's time and effort is directed to its personnel. In order to implement a workflow, personnel must receive instruction and training on the company's policies, procedures, and required responses that collectively define its workflow. Typically, all new personnel within the company must undergo a period of training on the company's procedures before they are even allowed to work on tasks. After this initial training period, additional training and instruction is required both to refresh and to update the personnel on the company's workflow procedures. This need to train the personnel comes at a sacrifice to a company. In addition to the cost in dollars to the company, the reliance on training prevents the company from quickly changing or altering its workflow since any change to the workflow must be communicated to the personnel through appropriate training sessions. In addition to updating the personnel, existing systems employed by a company also may need updating. These system updates are often more challenging and costly since they usually require modifying software to reflect the desired change. The heavy reliance on training also renders it difficult for a company to efficiently manage work loads and work assignments since personnel may only have training in a limited number of tasks.

Companies are often faced with a dilemma when attempting to implement a workflow at a low cost. On the one hand, companies may opt for computer-implemented systems that instruct users on how to respond and consequently hire less qualified individuals. Although systems that provide instructions may be more expensive, companies can save money by hiring less-expensive personnel and can eliminate some of the training. On the other hand, companies may instead opt for systems that have fewer instructions and hire more expensive and more highly qualified individuals. With this option, the company benefits from having a higher caliber work force and can possibly obtain higher quality, but has less assurances that the desired workflow is followed. After a workflow is implemented, many companies receive very little, if no, feedback on the effectiveness of the workflow. With regard to the personnel, the company can sample conversations with customers or sample performance in other ways, but practically has no way to know the extent to which personnel are complying with the defined workflow. In addition to the personnel, the company may be unable to assess the overall performance of a work path. The company makes assumption and predictions in defining each of the worksteps within a workflow and the interconnection between the worksteps to define the work path. Once the workflow is implemented, the company cannot easily measure whether those assumptions and predictions were accurate and often is reluctant to do so since making any change would be costly.

SUMMARY OF THE INVENTION

The present invention addresses the problems described above by providing systems and methods for implementing workflow. According to one aspect, the invention includes a transaction engine that controls an overall behavior of a system and a repository that has a declaration space containing definitions and relationships of the various components forming an application. A component that forms a building block for an application is a data element. Each data element is defined by a set of attributes that may be inherited or derived from other data elements and plural data elements may be combined into a group. A message type is an abstract representation of a collection of WO 00/54199 PCT/irSOO/06264 data elements and may, for instance, define the relationships between data elements. A message store defines the logical-to-physical mapping such as by specifying that a data file is a VS AM file, DB2 file, or other type of file. The repository also includes a definition of a workflow for an application. A workflow comprises a set of work steps linked to each other with connectors. The transaction engine routes the messages between the work steps according to the defined workflow.

With the declarative approach to programming according to the invention, applications are developed by defining within the repository the various components and their relationships to each other. Applications can therefore be developed and modified by altering the database without requiring the creation of any code. A platform formed of the repository and the transaction engine greatly reduces the cost of developing and maintaining application.

A workflow application can therefore be generated and modified more quickly and with less cost. A workflow application generated according to the invention also provides for both interactive and non-interactive work steps. In other words, the workflow may include work steps that do not require any user interaction or may include work steps that involve some input or action on the part of a user. Workflows according to the invention provide uniformity and consistency within a company, thereby allowing for higher quality results from the company. With the invention, workflows can be designed and implemented which provide instructions and scripts to the users so as to substantially reduce the amount of time needed for training. As a result, more complicated and sophisticated work paths, such as hyper-segmentation and decision tree logic, can be implemented without additional training.

Furthermore, workflow applications according to the invention can be dynamically altered. Because worksteps and work paths are defined in the repository, the worksteps or work flow can be easily changed by altering the definitions within the repository. Traditionally, if an assumption or prediction about a workflow is found to be false, the company is forced either to accept the error or pay an exorbitant amount to alter the existing workflow. With the invention, the workflow can be quickly altered and the users can receive "just in time training" on the changes.

The workflows according to the invention can implement champion challenger routines. For instance, a workflow need not necessarily have a static flow but instead may be altered according to the user, randomly, based on time, according to financial institution, or some other criteria. One advantage of champion challenger and workflow according to the invention is that relatively new personnel can be told what to do while more senior personnel can experiment with the workflow and test out new worksteps or work paths. The newer personnel need less training since they receive instructions and scripts on what to do or say and the more senior personnel are given the challenge to fine- tune a workflow based on their expertise.

Workflows according to the invention also allow for oversight of the users and of the overall process. For instance, workflow methods and systems allow companies to monitor and analyze all aspects of performance, such as the performance of individual customer service representatives. With this oversight, the company can better manage work loads and assignments thereby improving the overall performance of the company.

Accordingly, an object of the present invention is to provide systems and methods for performing workflow that require a reduced amount of code.

Another object of the present invention is to provide systems and methods for performing workflow that can be generated quickly and easily.

A further object of the present invention is to provide systems and methods for performing workflow that allows for both interactive and non-interactive work steps. A still further object of the present invention is to provide systems and methods for performing workflow that allow a greater degree of abstraction.

Yet another object of the present invention is to provide systems and methods for performing workflow that is dynamic.

Another object of the present invention is to provide systems and methods for performing workflow that provide for consistency and uniformity at a minimum cost.

A further object of the present invention is to provide systems and methods that allow for oversight, management, and monitoring of workflow.

Other objects, features, and advantages of the present invention will become apparent with respect to the remainder of this document. BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings, which are incorporated in and form a part of the specification, illustrate preferred embodiments of the present invention and, together with the description, disclose the principles of the invention. In the drawings: Figure 1 is a block diagram of a system according to a preferred embodiment of the invention;

Figure 2 is a diagram of interrelationships between design components forming part of the invention;

Figure 3(A) is an example of an object tab for a component forming part of the invention and Figure 3(B) illustrates a drag and drop feature;

Figure 4 is an example of assigned permission levels to a component; Figure 5 is an example of a data tab for a user component; Figures 6(A) to 6(1) are examples of data, message kind, database field, message field, GUI, GUI2, label, bar, and help tabs, respectively for a data element component; Figure 7 is an example of a data tab for an expression component;

Figure 8 is an example of a data tab for a restriction component; Figures 9(A), 9(B), and 9(C) are examples of data, reference, and label tabs, respectively, for a message type component;

Figure 10(A) is an example of a data tab for a message store component and Figures 10(B) to 10(G) are examples of a type tab for a message store component illustrating different storage types;

Figures 1 1(A) to 1 1(D) are examples of data, stored procedure, result, and label tabs for a query set component;

Figure 12 is an example of query node tree; Figure 13 is an example of a data tab for a query node component;

Figure 14 is a diagram illustrating a join between two database tables; Figure 15 is an example of a data tab for a join component; Figure 16 is a diagram of a sample workflow having three work steps; Figures 17(A) and 17(B) are examples of data and label tabs, respectively, for a work step component;

Figure 18 is a diagram of a sample workflow having work steps and category components;

Figures 19(A) and 19(B) are examples of a data tab and more tab, respectively, for a category component.

Figure 20 is a diagram of a workflow having work steps, category components, and connectors;

Figure 21 is an example of a data tab for a connector component;

Figures 22(A) and 22(B) are examples of data and wizard tabs, respectively, for a workflow component;

Figures 23(A) and 23(B) are examples of data and label tabs, respectively, for a language component;

Figure 24 is an example of a data tab for a locale component;

Figure 25(A) is a diagram of an inheritance tree and Figure 25(B) is an application of container inheritance;

Figure 26 is a view from an editor illustrating language inheritance; Figure 27 contains tables illustrating message inheritance;

Figure 28 is an example of a sample panel having data elements and groups of data elements;

Figure 29 is a table illustrating the positioning of data elements in a Group 1 container in Figure 28; Figure 30 is a table illustrating the positioning of the components and groups of components in Figure 28;

Figures 31 (A) to 31 (C) depict the development of a test panel having various components and groups of components;

Figure 32 is an example of an interface built using a development platform according to the invention;

Figure 33 is a representation of the components and groups of components forming the interface shown in Figure 32;

Figure 34 is a representation of one of the groups of elements listed in the container of Figure 33 along with the individual data elements forming that group; Figure 35 illustrates the definition of one data element component and its positioning relative to a second component in a vertical direction; Figure 36 illustrates the definition of one data element component and its positioning relative to a second component in a horizontal direction;

Figure 37 is a representation of a message store component and the various storage types available for selection; Figures 38(A) and 38(B) are partial views of an interface that illustrate the ability ofthe interfaces to dynamically adjust based on user security;

Figures 39(A) and 39(B) are partial views of interfaces that illustrate the ability of the interfaces to dynamically adjust based upon user language;

Figure 40 is a block diagram of a payment processing system; Figure 41 is an example of a workflow for use in placing blocks on transactions;

Figure 42 is an example of a main case screen showing fields in an "Account Information" tab;

Figures 43(A) to 43(C) are examples of sub-tabs and related fields under a "Customer" tab on the main case screen of Figure 42; Figure 44 is an example of a "Card" tab and related fields on the main screen of

Figure 42;

Figure 45 is an example of a "Transactions" tab and related fields on the main screen of Figure 42;

Figure 46 is an example of a "Customer Notes" tab and related fields on the main screen of Figure 42;

Figure 47 is an example of an Account History screen accessible from the main screen of Figure 42;

Figure 48 is an example ofthe main screen of Figure 44 having its fields populated with information indicative of work step 1 in the workflow of Figure 41; Figure 49 is an example ofthe main screen of Figure 42 having its fields populated with information indicative of work step 2 in the workflow of Figure 41 ;

Figure 50 is an example of a workflow for approving an authorization process;

Figure 51 is an example of a workflow for declining an authorization process;

Figure 52 is an example of a Detailed Case Report being generated by the system of Figure 40;

Figure 53 is an example of a Queue Activity Report generated by the system of Figure 40;

Figure 54 is an example of a Analyst Activity Report generated by the system of Figure 40;

Figure 55 is an example of an Analyst Activity Report by Outcome generated by the system of Figure 40;

Figure 56 is an example of a Daily Client Summary Report generated by the system of Figure 40; and

Figure 57 is an example of a Monthly Case Activity Report generated by the system of Figure 40.

DETAILED DESCRIPTION Reference will now be made in detail to preferred embodiments ofthe invention, non-limiting examples of which are illustrated in the accompanying drawings.

I. Overview

According to one aspect, the invention is directed to systems and methods implementing declarative programming. In a preferred embodiment shown in Figure 1 , a system includes a transaction engine and a repository. The transaction engine in general governs the basic behaviors ofthe system and coordinates work flow and the repository is a declaration space for storing object definitions. The system is basically a two-layer architecture in which the transaction engine is the lower layer and objects, data tables, and user functions defined within the repository form the upper layer.

As will be described in more detail below, systems and methods according to the invention overcome many ofthe disadvantages of existing programming techniques. For instance, applications can be developed without writing any code but instead by defining attributes within the repository. The development time and cost is therefore substantially reduced. Furthermore, changes can be made to an application by changing the definitions within the repository, thereby avoiding any need to create or to debug any code. Because changes to a program are almost inevitable, the invention significantly reduces the cost involved in updating and customizing applications. The invention also permits applications to be truly platform independent and scaleable. Additionally, the systems and methods are completely priority-based in real time to ensure that time-based activities are properly handled. Other advantages and features ofthe invention will become apparent from the description below.

According to another aspect, systems and methods for interfacing with a computer system overcome some of the disadvantages of existing interfaces. For instance, interfaces according to the invention allow the dynamic resizing and repositioning of displays based on such things as security, language, locality, and user. The interface is platform independent and can be developed and modified easily. Additional advantages and features of systems and methods for interfacing are described in more detail below.

II. Architecture

A. Transaction Engine

In the preferred embodiment, the transaction engine is formed from a set of highly generalized C++ classes. As discussed above, the transaction engine provides the basic behaviors for a system and has a core engine that distributes work among various objects and manages their relationships. The core engine is a set of code that moves messages from sources through processing modules, also called work steps, to stores and also moves messages from stores through processing modules to sinks. With the preferred system, most work is represented by messages that spend time in the message stores, some of which are queues. The work may be performed in interactive way, which requires some interaction with a user, or in a non-interactive way. For non-interactive, the core engine determines which workstep to execute next based on declared priorities of the worksteps. For interactive, the core engine waits for user input before proceeding to the next workstep.

B. Repository

In the preferred embodiment, the repository is a persistent collection of object definitions organized into component dictionaries with these dictionaries collectively forming a library. A dictionary is a collection of components of a similar type, such as all message stores. With conventional programming techniques, the relationships among objects would normally be computed during program execution. In contrast, the repository allows these relationships to be defined in the database and also allows a wide variety of restrictions and security relationships to be declared. The repository is not limited in the types of objects that may be defined and, in the preferred embodiment, includes the following components: application, data element, expression, restriction, message type, message store, join, query, query node, user, language, locale, work step, and work flow.

C. Components

The systems and methods according to the invention provide a set of component type definitions in the form of classes. Objects are named instances of component class definitions maintained within the repository and are defined by a set of attributes and values. Reuse of object definitions is supported through inheritance ofthe attribute values. As will be described in more detail, component inheritance according to the invention differs from the type of inheritance found in conventional object-oriented programming languages. The objects support the addition of data members and the overriding of attribute values within inherited objects.

D. Attributes

As described above, the components are defined through their attributes, which is also the case for object-oriented programming. One way in which a component according to the invention differs, however, is that in addition to a set of attributes, the components also have values. One advantage of associating values with the components is that reuse of attribute values can be accomplished through inheritance. Inheritance is defined through a parent-child relationship ofthe parent's attribute. The inheritance relation is limited to a single parent of a similar component type. An attribute maintains information regarding the inherited state of its value and inherited values reflect changes to corresponding parent component attributes. Non- inherited, also called overridden, attributes are unaffected by parent component attribute changes. The set of attribute data types are defined by built-in C++ types, component references, and component reference collections. The built-in and component reference type attributes resolve inheritance by traversing the inheritance tree during the deployment phase, which is the conversion from a development repository schema to an execution repository schema. The attributes state information is analyzed and, for inherited attributes, the parent component is checked for its value and this process is repeated recursively until a non-inherited value is found. Component reference collection type attributes, on the other hand, maintain only the set of component references defined for the owning component. For example, a parent's collection attribute may have references "A" and "B" and the child's collection attribute has reference "C." The child's collection attribute does not contain references to "A" and "B," although they are inherited from the parent. This inheritance structure is maintained in the repository.

E. Administrator In general, an Integrated Development Environment (IDE) editor provides tools for interfacing with the repository. The IDE editor provides a user administration tool for allowing a developer to define instances of all objects and permits editing of all objects with minimal time and effort. The user administration tool preferably provides an entry for each object type, such as data element type and message store, and lists all instances of objects within their corresponding object type. Each message type that has been defined would therefore appear under message type. The user administration tool supports typical list operations such as insert, collapse, and drag and drop. When a new instance is inserted, all of the basic attribute names automatically appear with it and are ready to be filled in with values. The user administration tool provides an interface suitable for adding new components or otherwise altering the transaction engine or repository. A localization editor tool allows for the editing of language components and language labels for some components and a workflow editor tool allows for the editing of workflow. Additional explanation and description ofthe IDE editor is provided below.

III. Components

Each of the various components of the invention forming part of a preferred embodiment of the invention will be described in further detail below. The invention, however, is not limited to these specific components but instead may include variations of these components or other components. Even though each component is addressed separately, a general description of some of the components will nevertheless be provided so as to provide a high level overview.

With reference to Figure 2, the data element forms the basic unit of data in an application. Each data element is defined as an independent entity because it comprises everything needed for displaying, editing, storing, security and integrity whether in storage, in memory or on the screen, and furthermore exhibit inheritance. Data element definitions are gathered together into message types.

Message types are completely independent of methods used to store data, exhibit inheritance, and are recursive. Instances of message types are messages, which are kept in message stores. Message stores may be implemented in a variety of ways, including but not limited to RDBMS tables, text files, indexed files, operating system queues, and buffers.

The repository also defines relationships and restrictions. The join component encompasses a wide variety of information concerning the relationships between data elements and messages. The join component allows fields between tables to be joined and allows data elements to be expressed with reference to other data elements.

Restrictions express all the limitations on possible values of data elements. The restrictions inherit from each other and are inherited by the objects to which they are attached. The repository also defines users which are organized into groups and have security relationships that may influence a user's interface. The repository also defines individual worksteps. The worksteps are joined together with connectors to define a workflow. The worksteps and messages may have priorities assigned to them which influence the order of execution for the messages and worksteps.

The administrator includes the Integrated Development Environment (IDE) editor for providing a graphical user interface for creating, editing, and deleting component definitions. With this declarative approach to programming, attribute definitions and other data governing the behavior of an application are contained within the repository.

Since most definitions contain references to other components, graphical views provided by the IDE editor can be extremely useful in visualizing the interaction ofthe components. Thus, the figures contain many views of interfaces provided by the IDE editor both to explain the IDE editor and to explain the components and their relationships to other components.

A. Object As discussed above, the IDE editor allows attributes of objects to be defined within the repository. Figure 3 is an example of an object tab that allows a developer to specify a unique name to the component and to specify any parent to that object. Additional information that may be specified for any component includes the author who created the component, the version level ofthe component, and a description ofthe component. Furthermore, each object can have a security attribute, which will be described in further detail below. The object tab shown in Figure 3(A) is common to all components and each type of component will have one or more additional tabs, which will be described in more detail with reference to each component. The repository editor preferably automatically assigns a component name to an object but this name may be modified by the developer.

A drag and drop feature is preferably used to assign a component object to its parent property. An example of the drag and drop feature is illustrated in Figure 3(B). With the repository editor, a previously defined component object may be selected from an object list panel and dragged to an appropriate property, such as SampleDataElementl and SampleDataElement2.

B. Security

As mentioned above, security is another attribute that may be defined for each object. The invention preferably provides various levels of security and controls permissions to create, read, update, delete, and execute (CRUDE). Figure 4 provides an example of assigned permission levels to various users. As shown in this Figure, a group of users defined by Admin has permission to create, read, and update the component DE I and users defined within group User_l only have permission to read the component. C. Users

As discussed above, each component can have security assigned based on the user or group of users. The users, in turn, are defined with reference to a user component. An example of a data tab for a user component is shown in Figure 5. As shown in the Figure, a user component includes an identification string attribute defining the user, a password string attribute defining the password for the user which is used at login, and a user group attribute to define whether the component is a single user or a group of users. Additionally, a user component includes attributes defining a user's preferred locale and language, languages spoken by the user or group of users, and information attributes Infol to Info4 designed to hold user-supplied data for security purposes, such as a mother's maiden name of a user.

D. Data Element

A description will now be provided with reference to a data element component and a data element group component. A data element component is used to define all data for an application and contains information relating to both the application and to the user interface. The data element group component is a specific type of data element that allows the combination of multiple data element components and data element groups into a single object. For instance, a data element group can correspond to a physically contiguous grouping of data or to a rectangular area ofthe display screen.

An example of a data tab for a data element component is shown in Figure 6(A). A data element component includes a data type attribute for defining the internal data type for the component and how its value is stored. The data type may be any type, such as but not limited to character, boolean, integer, real, alpha, alpha-numeric, numeric, data, type, currency, group, bit map, or array. The data element data tab also includes attributes allowing the length of the data to be defined, such as the number of bits required by bit map and array. The data element component, as described above, may be a group of data elements with the various elements in the group being defined within the elements attribute. Also included in the data element data tab are attributes for expressions and restrictions, both of which will be described in further detail below. In general, the restrictions attribute can be used to define restriction objects used to validate data integrity of data elements.

As shown in Figure 6(B), the data element component is also defined through a data element message tab. Through an audit attribute on this tab, an audit can be defined so as to be generated any time the field is updated. Figure 6(C) shows an example of a database field tab which allows a developer to define attributes on how to store data elements, such as within an RDBMS or VSAM message store. An example of a data element message field tab is shown in Figure 6(D). Through this tab, a developer can define the external data type ofthe component and the format ofthe components data within a message type data stream. The IDE editor preferably provides a drop-down box containing the possible selections, such as but not limited to native, ASCII, EBCDIC, unsigned BCD, signed BCD, or bit field.

An example of a GUI tab is shown in Figure 6(E). In general, the GUI tab attributes allow a developer to define how the data element will be graphically represented on a display panel or screen. The view attribute defines the type of control used to view the data value of a component. A position attribute defines the location of the component within its group if the element forms part of a container or panel. The position attribute preferably allows the component to be displayed at a fixed location on this screen, such as top left, top right, bottom left, or bottom right, or to display the component relative to another object. A panel type attribute defines the type of window used to display the panel.

An example of a data element GUI2 tab is shown in Figure 6(F). The GUI2 tab provides additional attributes for defining aspects of a data element. These attributes include expression attributes for defining how the element is displayed and an actions attribute that defines how an application will respond to predefined panel events. An example of a data element label tab is shown in Figure 6(G) and includes attributes for defining a label for the component. An example of a data element bar tab is shown in Figure 6(H) and includes attributes for defining such things as a tool tip, status bar, menu bar. and tool bar. An example of a data element help tab is shown in Figure 6(1). The help tab allows a developer to define the text that is displayed when a user selects a help function. E. Expressions and Restrictions

As discussed above, an expression may form part ofthe definition of an object. Expressions may be used in many places for various purposes, such as to assign and analyze data, invoke functions, or define symbolic names. An expression is defined by an expression component and is defined preferably using C or C++ read-only syntax. A sample data tab for an expression component is shown in Figure 7(A) and defines the value ofthe data element and provides a default value for the data element. Both of these attributes are defined with reference to an expression component that would be inserted in those fields. Figure 7(B) illustrates an example of an expression edit panel for defining an expression. The expression component also includes an attribute for defining the language for the text. The language component will be described in further detail below. A restriction component is a boolean expression that provides constraints on data element values and also integrity tests for message types. Using the drag and drop feature, multiple restriction objects can be assigned to the restrictions (RR) property of both data elements and message types. An example of a data tab for a restriction component is shown in Figure 8.

F. Message Types and Message Stores

A message is a mechanism used to input, output, and transfer information throughout an application, and a message type component defines a physically contiguous group of data items. A message instance is an actual message for a particular message type. In other words, if a message type is defined to hold an account number and name as data elements, then a message instance of that message type might hold the values 1234 and John Doe. A message instance result set is a special class of a message instance that contains multiple message instances. For example, if a message instance contains a single account number and name, a message instance result set would contain multiple account numbers and names.

An example of a message type data tab is shown in Figure 9(A). A priority attribute is provided on the message type data tab and allows a developer to assign an integer value to the message type. The integer value is used by the transaction engine to set an overall priority level for processing. In addition to messages, an application component, workflow component, and workstep component also have an associated priority attribute used by the transaction engine in determining priorities of these elements. Also included on the message type data tab is an items attribute. The items attribute allows a developer to define the data elements and/or data element groups that combine to make up the message type. The message type data tab also includes a timed attribute that allows a developer to define a timing requirement associated with the message type. Additionally, the user can define an appropriate response if the message type is not completed within the allotted time period.

An example of a message type reference tab is shown in Figure 9(B). The message type reference tab has a restriction attribute that allows a developer to define the restrictions used to validate the data integrity ofthe message type data stream. These restrictions are executed by the transaction engine during parsing ofthe input data stream. An example of a message type label tab is shown in Figure 9(C). The message type label tab has a group label attribute which is an expression that allows a developer to define the label that will appear in a group of messages of this message type in an explorer control for the language specified. For example, if this message type represents a customer, the attribute may be set to "Customers." The message type label tab also includes a single label attribute which is an expression that allows a developer to define the label that will appear for a single message of this message type in an explorer control for the language specified. For example, if this message type represents customers, a label such as

"Customer: Big Spender" may be displayed. While the group label attribute will often be a simple character expression, the single label attribute will likely take advantage ofthe fact that this is in fact an expression and will combine static text and values that exist in the context. In general, a message store defines the type of storage used to maintain a message store component. Each message store component has an associated message type that specifies the content and layout ofthe data written to and read from the message store. Once defined, message stores allow the application to input and output data without regard to the method used to physically maintain the information. An example of a message store data tab is shown in Figure 10(A). The message store data tab has a Windows® MsAccess® attribute that allows a developer to define the type of access allowed to the message store. The MsAccess® attribute may define various levels, such as read only, write only, read/write, or no access. The message store data tab also has an MType attribute that allows a developer to define the content and layout of all data elements written to and read from this message store and a FileName attribute that allows a developer to define the actual name ofthe file for a non-RDBMS message store or the table name for an RDBMS message store. The message store data tab also includes an MS Share attribute that allows a developer to define the type of sharing allowed for this message store. This attribute may permit various types of sharing, such as compatible share, no sharing, read share, read/write share, or write share. A timed attribute is also provided on the message store data tab and allows a developer to indicate that timed messages are supported by this message store. Another attribute included within the message store data tab is a temporality attribute that allows a developer to indicate that the message store supports temporal data. In general, temporality allows developers to define the time during which specific values for data elements in the message store are valid. Temporality permits developers to define conditions that become effective for a specified time interval. Also, multiple changes made to the application over a period of time can all be set to become effective at the same time. A TemporalTable attribute allows a developer to indicate that a separate table exists that controls the temporality feature. Message store components also include attributes for defining the storage type.

The invention supports any type of storage including, but not limited to, DBMS, Flat File, In Memory, Queue, Logical, VSAM, HLLAPI and Network. An example of a flat file tab is shown in Figure 10(B) and allows a user to define the type of data within the flat file, such as ASCII or binary. The flat file type tab also includes an OpenMode attribute that allows a user to define the manner in which the file should be opened if it can be written to, includes an append option for specifying that the file should be opened in a manner in which any data written to this file is appended to existing data, and a truncate option which indicates that the file should be opened in a manner in which any existing data in the file is removed before any new data is written to it. An example of a DBMS type tab is shown in Figure 10(C). This tab includes a dbName attribute which allows a developer to define the name ofthe database on the server, a dbmsType attribute which allows a developer to define the type of server, such as a SQL server, and a dbServer attribute that allows a developer to define the name ofthe server containing the database. An example of a VSAM type tab is shown in Figure 10(D). By specifying the message store as a VSAM type, applications developed with the invention can access VSAM files on a host computer for data storage.

An example of a network type tab is shown in Figure 10(E). By specifying the storage type as network, a user can define applications that use a network connection for data storage. The network storage type tab includes a transport attribute which allows a developer to identify the type of connectivity that will be used by this message store. The invention supports any type of transport, including but not limited to TCP/IP, NetBios,

Lu2.0, Lu6.2, Async, Spex/Ips, Bisync, X.25, Pipe, and File. Other attributes provided on this type tab allows a developer to define the protocol, to select raw or extended connectivity, to define compression, to define a specific port, to define a host address, and to define time out functions. An example of a HLLAPI storage type tab is shown in Figure 10(F). This type of message store allows a user to define a HLLAPI connection for data storage. This tab includes a settle time attribute for allowing a developer to define the amount of time to wait for a screen to display before electronically reading or scraping the screen, an HLLAPI time out attribute for allowing a developer to define the amount of time to wait for the host to respond before returning an error, and an emulator type attribute to indicate the name ofthe software package being utilized for HLLAPI. An example of a Disk Storage Location (DSL) storage type tab is shown in Figure 10(G). The DSL type tab allows a developer to define DSL files and to identify a server for the DSL files.

G. Queries and Query Nodes

A query set component provides a way of retrieving or deleting data from one or more message stores by defining the data elements and any limiting criteria. An example of a query set data tab is shown in Figure 1 1(A). The query set data tab includes a scope attribute which allows a developer to define where the results should be placed in the context, which will affect when the results are removed. The scope attribute in the preferred embodiment includes selections for workstep, transaction, workflow, and application. The query set data tab also includes an action attribute which allows a user to define the initial action to take when executing a command. Through the action attribute, a developer can specify that the initial action should be taken in order to select or retrieve data from a message store or the action should be taken so that data defined by the select criteria is deleted. The query set data tab also includes a TimeoutAction attribute that allows a developer to define the action to be taken if the current transaction reaches a time out.

An example of a query set stored procedure tab is shown in Figure 11 (B) and allows a developer to identify a pre-defined procedure that executes and returns desired results. The query set stored procedure tab also includes an input parameter attribute that allows a user to define all input data required by a specific stored procedure in order to execute.

An example of a query set result tab is shown in Figure 11(C). The query set result tab includes a SelectCriteria attribute that allows a developer to define an expression that identifies a set of results. For instance, the select criteria attribute may be used to select all ofthe accounts for a certain customer, all ofthe accounts for a currently selected customer in a certain context, or all ofthe accounts that have a balance greater than a certain dollar amount. A result attribute allows a developer to define data elements to retrieve. A developer is able to select only certain data elements within a message store or to select the entire set within the message store. The query set result tab also includes a sort attribute that allows a developer to define the sort order ofthe results to be returned. An example of a query set label tab is shown in Figure 11(D). The query set label tab includes a group label expression attribute that allows a developer to define the label that will appear if a group of messages of this message type are displayed in an explorer control for the language specified. The query set label tab also includes a single label expression attribute which allows a developer to define the label that will appear for a single message of this message type in an explorer control for the language specified.

A query node component provides a way of retrieving data using either a query set or a join component. Each query node can also be assigned a position within a tree-like structure of query nodes and is executed in a sequence as defined by the tree. This provides the ability to link any combination of query sets and joins in an ordered sequence for execution. For example, Figure 12 illustrates a query node structure made up of eight nodes. When called by an application, query node 2 QN2 would first execute its query set or join and retrieve the results and then call both query nodes 5 QN5 and 6 QN6. The data retrieved by query node 2 QN2 would be available to both query nodes 5 QN5 and 6 QN6 and could be used in the definition of their query set or join.

An example of a query node data tab is shown in Figure 13. The query node data tab includes a query attribute that allows a user to retrieve data as specified in a query set object. The query node data tab also includes a node child attribute that allows a user to define another query node as a child of this node in a tree-like structure, such as the one shown in Figure 12.

H. Join A join component defines a logical link between two tables and a database. The joins, as discussed above, are used by queries to quickly establish a unique row of data that will satisfy specific search criteria. For example, Figure 14 illustrates how two database tables can be joined by the state code and state fields. Using this logical connection provided by the join definition, queries to the database could quickly retrieve the full state name from the first table for any corresponding state code found in the second table. An example of a join data tab is shown in Figure 15. The join data tab includes a

RelType attribute that allows a developer to define the relation type, examples of which are for joining database tables, inheritance, and GUI. The join data tab also includes a parent cardinality attribute and a child cardinality attribute. The parent cardinality attribute allows a developer to define the cardinality rules from the parent to the child table and. conversely, the child cardinality attributes allows a developer to define the cardinality rules from a child to the parent table. These rules, for instance, may include one to none, one to one, or one to many. The join data tab also includes an attribute to allow a developer to identify a message store as the parent and an attribute for allowing a developer to identify a message store as the child. Furthermore, the join data tab includes attributes for allowing a developer to define parent data elements and child data elements. I. Workflow and Worksteps

As discussed above, the transaction engine routes messages through worksteps to achieve a desired workflow. Each workflow is made up of interconnected units of work called worksteps. Each workstep component defines specific units of work required to perform the overall function ofthe workflow.

A first step in defining a workflow is to create the individual worksteps. Figure 16 illustrates a diagram of the first step in the formation of a workflow. Figure 16 illustrates three types of worksteps: a source workstep, a mapper workstep, and a sink workstep. In general, a source workstep inputs data from message stores, a mapper workstep provides general data processing, and a sink workstep outputs data to the message stores.

An example of a workstep data tab is shown in Figure 17(A). The workstep data tab includes a step type attribute that allows a developer to define the overall functionality ofthe workstep component. The workstep may be of any type including, but not limited to, a mapper, a source, a sink, or an interactive workstep that provides a user interface for interactive workflows. The workstep data tab also includes a priority attribute that allows a developer to set the relative priority level for processing this step versus other active worksteps. The workstep data tab also includes a message store attribute for allowing a developer to indicate the message store used as an input for a source-type workstep or as an output for a sink-type workstep, a query node attribute for allowing a developer to indicate the queries that should be executed when selecting data from a message store, and a panel attribute to allow a developer to indicate the panel that should be displayed when processing the workstep.

An example of a workstep label tab is shown in Figure 17(B). The workstep label tab includes a display label attribute that allows a user to have multi-lingual worksteps. With this attribute, a user can identify the name of a specific supported language or a string representation of a label text for a specific language.

After defining the type of the workstep, the developer next defines category components. A category component resides within a workstep and provides a way to accept input messages and produce output messages. Category components are terminal points for all data transfers between worksteps. Figure 18 illustrates the addition of categories to the worksteps of Figure 16. An output category has been added to the source workstep, both input and output categories have been provided to the mapper workstep, and an input category has been provided to the sink workstep. In general a category component represents a scenario that may lead to a specific workstep or provide an exit from one workstep to another workstep. An example of a category data tab is shown in Figure 19(A). The category data tab includes a category type attribute which allows a developer to define the overall functionality ofthe category component, such as an input that accepts input messages or an output that produces output messages. A queue attribute provided on the category data tab allows a developer to reference a message store associated with the category component. An example of a category "More" tab is shown in Figure 19(B) and includes an expressions attribute that allows a developer to specify expressions to run sequentially to populate the context ofthe current category. The category "More" tab also includes a relationships attribute that allows a developer to select data and populate the context of the current category. After defining the worksteps and the categories, the process of defining a workflow next involves providing connections between the worksteps. A connector component is defined to provide the data path between the output-type category of one workstep with the input-type category of another workstep. Figure 20 illustrates a workflow in which the worksteps and categories shown in Figure 18 have been tied together with connectors. As shown in this Figure, the output-type category ofthe source workstep is connected to the input-type category ofthe mapper workstep and the output- type category ofthe mapper workstep is connected to the input-type category of the sink workstep.

An example of a connector data tab is shown in Figure 21. The connector data tab includes a StepTo attribute that allows a developer to define the workstep that control is to be transferred to when executing this connector and a StepFrom attribute that allows the developer to define the workstep that control is transferred from when executing this connector. The connector data tab also includes a flow attribute that allows a developer to define the workflow to which this connector belongs. The connector data tab also includes attributes for allowing the developer to define the category that this connector should execute in the StepTo workstep and also the category that the connector should execute from in the StepFrom workstep.

A workflow is therefore created by defining worksteps, categories, and connections between the worksteps. An example of a workflow data tab is shown in Figure 22(A). The workflow data tab includes a priority attribute that allows a developer to assign an integer value, such as between 0 and 255, as the priority value for the workflow. This priority value is used to set an overall priority level for processing. The workflow data tab also includes a workflow type attribute that allows a developer to specify when the workflow should execute, such as at start up when the application starts, at shut down just before an application terminates, or at a normal time when the workflow is called. The workflow data tab also includes a steps attribute that allows a developer to identify all ofthe workstep objects associated with the workflow and a connections attribute that identifies all connector objects associated with the workflow. A flow panel attribute allows a developer to specify a panel, which is a data element group, that is to be displayed when the workflow is running. A champion challenger attribute identifies all champion challenger objects associated with the workflow. An example of a workflow wizard tab is shown in Figure 22(B). The wizard tab allows a developer to add new work steps, new categories, and new connectors to a workflow.

J. Language A language component, along with locale and user components, gives a developer the ability to generate true international applications. These components enable developers to produce screen labels and help text assigned to specific users. Multiple users can run the same applications simultaneously, with different screen labels and help being displayed based not only on their language, but also on their specific locale. An example of a language data tab is shown in Figure 23(A). The language data tab includes a month names attribute for allowing a developer to represent long month names and a short month names attribute for allowing a developer to identify the short month names to be displayed. The language data tab also includes a day names attribute for allowing a developer to identify the long day-of-week names to be displayed and a short day names attribute for allowing a developer to identify the short day-of-week names to be displayed. An example of a language label tab is shown in Figure 23(B). The language label tab provides developers with the capability to dynamically switch languages in menus.

A locale component, as described above, along with the language and user components allow developers to produce screen labels based on user language and a specific user locale. An example of a local data tab is shown in Figure 24. The locale data tab includes a language attribute for allowing a developer to specify the language component to use in this locale. The locale data tab also includes attributes for allowing developers to define the character used to separate the decimal point, the character(s) to use to represent numeric and currency groups, the character(s) to use to separate numeric date parts, the character(s) to use to separate numeric time parts, an integer to define the number of digits in each group for non-currency numbers, and an integer to define the number of digits in each group for currencies.

IV. Inheritance A. Overview

Inheritance has already been described at least in part above with reference to some ofthe components. In general, multiple types of inheritance exist and the types of inheritance vary from each other according to the way in which they define relationships between components. Inheritance according to the invention differs in many ways from inheritance through existing object-oriented programming techniques.

B. Component/ Attribute One type of inheritance is called component or attribute inheritance. Attribute inheritance defines a relationship between parent and child components where the child receives or inherits the property values of its parent. This relationship is defined through a component's parent property. A parent can have one or more child components but a child component can have only a single parent. An example of an attribute inheritance tree is shown in Figure 25(A). With reference to this Figure, components B, C, and D are childs of component A and each inherits the property values of component A. Further, components E and F are child components of component B and inherit those property values of component B. Similarly, component G is a child of component D. At any point in the hierarchy, inherited property values can be overridden. When this happens, the inherited values of all affected child components are updated to reflect the change made at the parent level. Non-inherited or overridden property values are unaffected by changes made at its parent component. Thus, with reference again to Figure 25(A), all components below component A will inherit its property values. However, if a specific property value is overridden at component B, then components E and F will inherit that property value from component B but all other inherited values will continue to come from component A.

In object-oriented programming, an object accesses another object's data by calling the object's data access methods. Thus, object-oriented programming discourages direct access to common data by other programs. Only the object that "owns" the data can change its content and other objects can view or change the data only by the owner.

In contrast, inheritance with the invention allows components to inherit the data or attribute of its parent. With reference again to Figure 25(A), component E therefore would inherit the values or attributes of component B and component A. The values, however, may be overridden at component B so as to be different from those in component A. For these overridden values, components E and F will inherit the values of component B and not those of component A. Similarly, components E and F may override some ofthe values inherited from component B. The ability to inherit attributes or values from other components provides advantages over procedural programming techniques. For instance, an application may define a data element of the year and define its length to be two integers. Thus, the application may represent the year 1999 as "99." Typically, with a procedural program, the developer would have to first locate every line that contains the year and make an appropriate change to the code. With the invention, the developer need only go to the data element defining the year and change the length so that it is four digits rather than just two digits. This change is made within the repository and does not require any recompiling or debugging of the code. Thus, changes can be easily and quickly made to an application thereby reducing the cost to a company. C. Container

In addition to attribute inheritance, the invention also supports container inheritance. The transaction engine uses container inheritance to derive some values With container inheritance, a container may be defined to include a group of components. For example, with reference to Figure 25(B), a data element group for A/C History may contain data elements called Balance, Date and Transaction ID. At runtime, it is possible that all contained fields, with the exception ofthe Balance field, obtain their value from a common message store or message, such as one called Common, in accordance with the application logic. This common source for value may then only be specified with the immediate container of these fields, such as A/C History. The Balance field might refer to an altogether different source for its value at runtime. With reference to Figure 25(B), at runtime, the Date and Transaction ID fields inherit the Data Source attribute , which is that attribute which identifies the location source of a field's value at runtime, from that of its container, namely A/C History.

D. Language

Many components contain multi-lingual attributes. These attributes contain a value for the attribute for each language supported by the application. Oftentimes, two languages for an attribute can share the same string value. For example, assume an application supports Canadian English, American English, and British English languages. If the application also creates a language called English and makes it the component parent of the other three more specific English languages, then whenever the three specific languages share a string value, the string value can be filled in the multi-lingual attribute for English and the transaction engine will use the English value as the value for any ofthe other three more specific languages that do not have a value.

Figure 26 provides an illustration of language inheritance in one portion of the display. This portion ofthe display illustrates American English, Deutsch, and Espanol. Further divisions may be made within each language, such as European English, British, and Canadian English. Figure 26 also illustrates various data elements and the different languages. For instance, the data element telephone has a label "Telephone" in American English, Canadian English, and European English but has a label "Telefono" for Espanol. Similarly, a label named US_Dollars has a label "Currency" for the different versions of English but has a label as "Monedas" for Espanol. Thus, according to these examples, Canadian English and European English inherit their values from American English but Espanol has specified values, specifically "Telefono" and "Monedas."

E. Message

In addition to attribute, container, and language inheritance, the invention also supports message inheritance. Occasionally, a message store may contain messages that are not in the same format, but the messages are part of a family of messages. Individual messages may provide some kind of type field that allows the application to decide how to parse each data element. An example will now be described with reference to Figure 27. Four messages may be utilized to talk to an ATM machine. All the messages contained an account number and the second field describes what the message should do as well as the format for the rest ofthe message. For instance, when the transaction engine is presented with a "Withdrawal" message, the transaction engine will parse the message by first determining that the message store message type attribute is Root. The transaction will start by parsing in the data element of Root, which in this example will result in CaseAccount and Type. The transaction engine will evaluate the ParseSelector expressions of all children of Root and locate the true expression. In this example, the children of Root are Inquiry and Common and the selector will be true for Common. The transaction engine will next parse the data elements of Common and add "Amount" to the message. The transaction engine will evaluate the ParseSelector expressions ofthe children of Common and locate the selector of message with "Withdraw" as true. The transaction engine would then be finished parsing since "Withdraw" does not contain any child message types.

F. Sibling

The invention also supports sibling inheritance. As described above, a child component can inherit all attributes or values of its parent component. The child component, however, need not inherit all values and some may be overwritten. Another way in which a child component can inherit from another component is through sibling inheritance. With sibling inheritance, a value in one component is expressed relative to a value in another component. For instance, a first component may have a value that is expressed as two times the value defined in a second component. Other siblings may be added to an existing sibling relationship, such as by specifying that a third component has a value defined relative to the value in the first component which, in turn, is tied to the value in the second component.

G. Value-Based Inheritance

System users can also benefit from inheritance. An Account Master file, for example, could have records organized as an arbitrarily large hierarchy, perhaps corresponding to the organizational structures of various organizations. An agent could set a field value, such as a spending limit, in a record corresponding to a particular organizational level and have it apply to all the people in that organization. The ability to override inherited values would let the agent override that spending limit for any particular group within that organization.

H. Component Replacement Inheritance

Component Replacement Inheritance (CRI) is similar in some ways to normal attribute inheritance. With CRI, however, if a component A' is made to inherit from A, A' will be treated the same as A. As a result, other components or other aspects of an application that refer to A would then use the modified A'. CRI can also chain components together. For instance, a string of components could be defined as A — A' — A" — A'". With this type of inheritance, A could represent an application delivered by the developer, A' the customization performed by a multi-national company, A" the customization performed by some national part ofthe company, and A'" the customization performed by a division within that particular country.

CRI provides many advantages, especially with respect to customization and maintenance. From the developer's viewpoint, the developer can deliver an application and can allow the customer to customize it by using CRI. Rather than needing to modify the application itself, the customer can advantageously use CRI to inherit from the pieces they want to modify. The system treats the modifications as if they occurred within the application itself, but the modifications are isolated in separate files.

V. User Interface The systems and methods according to the invention allow interfaces to be easily developed. For instance, a data group component D may be defined to include data element components A, B, and C. A data group is not limited to a collection of individual components but may also be defined to include other data groups. For instance, a data group component F may be defined to include the data group component D as well as a data element component E.

The use of these data elements and data element groups allows a developer to easily define a panel on a screen. An explanation will now be provided with reference to the development of a panel shown in Figure 28. This panel includes data elements 1 DEI and 2 DE 2 that are defined within a panel labeled Group 1. The Group 1 panel also includes a component labeled Button 6. The Group 1 panel forms a part of a larger group labeled Panel 1. The Panel 1 container, in addition to the Group 1 panel, is defined to include additional components labeled Button 1 to Button 5.

An example of a table listing the positions of each element in Group 1 is shown in Figure 29. As shown in this Figure, data element DE 1 is positioned at the top left ofthe panel, data element DE 2 is positioned relative to data element DE 1 in a vertical direction, and Button 6 is positioned at the bottom right ofthe panel. An advantage of such a positioning scheme is that it allows the data element DE 2 to be always positioned below the first data element DE 1. Thus, the second data element DE 2 will dynamically reposition itself within the screen if a change in data element 1 DE 1 affects the amount of vertical space consumed by that data element.

Figure 30 is a table that illustrates the relative positioning of the components forming the Panel 1 group. As reflected in this table, the Group 1 panel is at the top left ofthe display, the first button Button 1 is at the top right, and the third button Button 3 is at the bottom left. Thus, the Group 1 panel and the first and third buttons are at a fixed position on the screen. The second, fourth, and fifth buttons, on the other hand, are positioned relative to other components. The second button Button 2 is positioned relative to the first button Button 1 in a vertical direction, the fourth button Button 4 is positioned relative to the third button Button 3 in a horizontal direction, and the fifth button Button 5 is positioned relative to the fourth button Button 4 in a horizontal direction. Thus, Button 2 will always be below Button 1 , Button 4 will always be to the right of Button 3, and Button 5 will always be to the right of Button 4.

Another illustration of building panels will be provided with reference to Figures 31(A) to 31(C). Figure 31(A) illustrates a panel labeled "My Test Panel" which may be formed from one data element component. In creating this panel, the data element component may be defined to have a length of 40, a view of entry, a label equal to "Name," and label positioning equal to top. The data element for the label name can then be added to a data element group called "My Panel." The data element group called "My Panel" can have a type defined as group, a view defined as panel, and a label defined as "My Test Panel." This data element group would then contain the data element for "Name" as one of its children. The developer may then add "City" and "State" to the panel, as shown in Figure

31(B). To form the panel shown in Figure 31(B), a developer can add a second data element component for the city and define the view as entry, the length as 25, the label as "City:", the label position as top and the position as relative to the name data element. The state data element component can also be added to the panel group and can be defined to have a view as ComboBox, label as "State:", label position as top, and position as relative to the city data element component.

In a similar way, additional components or groups of components may be added to the panel. For instance, as shown in Figure 31(C), a set of buttons labeled as "Print," "OK," and "Cancel" have been added to the group labeled "My Test Panel." The Print, OK, and Cancel buttons can therefore be defined as separate data elements and as a command button and can be included within a data element group that is included within the group for the test panel.

An explanation will now be provided with reference to a payment processing system to illustrate some advantages ofthe invention. Figure 32 illustrates an interface that may be presented to a user, such as a client representative. The interface shown presents information on a particular card-holder's account, such as the card-holder's name, address, list of transactions, balance and interest information, and a set of control buttons.

Figure 33 illustrates a data element group that defines the interface shown in Figure 32. The data element group entitled DemoGroup contains elements of a NameBlock group component, AddressBlock group component, Transaction group component, Balance component, Interest component, and RSMFormControls group component. The NameBlock group defines the top two rows of the display, the AddressBlock group defines the address information, the Transaction group defines the list of transactions, the Balance element defines the balance, the Interest element defines the interest, and the RSMFormControl group defines the buttons on the bottom ofthe display. As shown in more detail in Figure 34, the NameBlock data element group includes individual data elements for account number AcctNum, statement date StmtDate, name Name, personal identification number PIN, credit limit CreditLimit, late payment LatePayment, and VIP status ofthe card-holder VIP. All ofthe data elements and data element groups have their positions defined on the interface shown in Figure 32. For instance, looking at the CreditLimit data element shown in Figure 35, the credit limit information is displayed relative to the statement date in a vertical direction. With reference to Figure 32, the credit limit is shown below the payment due date. The position ofthe StmtDate data element as shown in Figure 36 is defined relative to the PIN data element in a horizontal direction. Thus, as shown in Figure 32, the payment due date field is positioned horizontally to the right ofthe PIN field. The message store component conveniently allows developers and users to designate the data type. Figure 37 provides an example of a message store component for account balance and illustrates examples of storage types available. These storage types include, but not be limited to DBMS, FlatFile, Inmemory, Queue, Logical, Network, VSAM, HLLAPI, and DSL.

As described above, interfaces developed with this invention allow for security to be assigned based on the user. As an example, Figure 38(A) illustrates account information that may be available to a first user having a greater degree of permission than a second user, which receives the account information shown in Figure 38(B).

Advantageously, fields that are omitted when displaying the information to the second user, namely the Open-to-buy and Credit limit information is not shown in the interface displayed in Figure 38(B). Furthermore, the interface is dynamically altered so that the Total accounts information is displayed immediately below the Amount due data. In other words, the interface shown in Figure 38(B) does not include a space between the Total accounts and the Amount due for the omitted Open-to-buy and Credit limit fields. The interface as shown in Figure 38(B) therefore provides no suggestion to the second user that information has been concealed.

Another benefit ofthe invention is that the interfaces can be dynamically changed according to the language displayed. An illustration of this ability will now be described with references to Figures 39(A) and 39(B). Figure 39(A) illustrates a portion of an interface displayed in an English language and depicts a Transaction field above a Short Name field, an Organization field to the right of the Transaction field, a Logo field to the right of the Organization field, and a Status field below the Logo field. As is apparent from Figure 39(B), the relationships between these fields remain the same even when the interface is displayed in another language. Thus, when the interface is changed to

Spanish, Transacciόn is still above the Nombre Corto field, the Organizaciόn is still to the right of Transacciόn, the Logo is still to the right of Organizaciόn, and Estatus is still below the Logo field. The resizing ofthe interface is also apparent from the tabs.

VI. Scalability and Other Benefits

The systems and methods according to the invention define a platform that presents an environment specially tailored to efficiently support financial programming.

Typical financial programs repeatedly use the same types of constructs, such as varying descriptions of account numbers or embedded SQL calls to a database. By applying object-oriented programming principles to abstract these common constructs into platform objects, the invention provides a mechanism to reduce the size and scope ofthe non-common, application-specific software and thereby reduce maintenance costs.

In addition to object-oriented techniques, the invention employs a non-procedural programming style. With the invention, developers declare what the application should do, as opposed to the more traditional development model where the developer creates a program that tells how to realize an application. To support this non-procedural or declarative method of programming, the invention provides a relatively small number of components and component properties, also called attributes, that an application developer can define. The platform according to the invention understands how a component should behave based on what the application developer has defined the attributes. The declarative approach provides a way to push common programming into the platform, reduce the size ofthe application-specific portion, and reduce the associated maintenance costs.

The platform according to the invention is declarative and object-oriented in nature. The platform is built not only using an object-oriented language, such as C++, but makes objects the basis for the platform environment itself. A significant advantage achieved from this approach is to make systems built using this platform easier to extend and maintain.

The invention also presents advantages in inheritance. In general, inheritance provides the ability to define a hierarchy such that objects lower in the hierarchy can automatically "inherit" values associated with objects above them. A main advantage of inheritance is the ability to make a change in a single place that should apply to a collection of objects. For instance, one can define a base AccountNumber data element and have all Account Number definitions inherit from that base. Assume that all account numbers start out being a maximum of 15 digits long, and one encodes this information in the base AccountNumber definition. If there is a subsequent need to expand the maximum length of account numbers to 21 , one need only make the change in one place and have it apply to all my account numbers. Similarly, if a set of related Message Stores inherits from a base Message Store definition that initially associates the store with the Microsoft SQL Server RDBMS, changing the base definition to use Oracle will make all inheriting definitions use Oracle.

With procedural programming, the computer knows how to do a small number of very basic commands, such as assignment, branching, and arithmetic. The developer uses the commands to tell the computer how to perform a task. General purpose programming languages support procedural programming. Application-oriented programming languages embody application- specific knowledge into a set of higher-level programming constructs. Application in this sense may be application areas, such as financial transactions or word processing. Application- oriented languages may be procedural or declarative; they are declarative if the way they provide access to their higher-level constructs is via interpreting attributes.

Declarative programming can reduce the number of places in a program where a developer needs to make changes. For example, authorization systems keep counts on account activity, such as a daily tally of approved transactions for each account. In a procedural authorization system, there would be n places in that program where it could decide to approve a transaction. To keep the tally, the developer would tell the system in each of those n places to look up the appropriate data element and increment it. On the other hand, a declarative approach would take advantage ofthe fact that no matter what the value ofthe tally is at any given time, it is always the current count of approved transactions. So the developer could declare that definition to be an attribute of the tally data element itself. According to the invention, the tally would be a derived data type. The developer can take advantage ofthe fact that the platform according to the invention knows how to take counts of records that exist in message stores (optionally partitioned by account and approved/declined).

The declarative approach breaks the direct tie in the code between approving a transaction and updating data elements that care whether it was approved. From a maintenance point of view, if the definition ofthe tally data element needs to be changed, a change need only be made at the data element itself whereas with procedural applications the n places in the code that contain the definition would first have to be located and then those lines of code would have to be changed.

With the platform according to the invention, applications are collections of workflows and each workflow is a set of interconnected worksteps. Information flows among worksteps as messages. Each workstep is an independent processing unit in that it performs a function driven entirely by its input message(s). A single process could schedule and run the entire application, but the message passing and independent nature ofthe worksteps provides scalability.

An application can run subsets of workflows as different threads or processes or on different processors. In fact, each workstep could run on a separate processor. In addition, since each processor would essentially be a server taking work from its message-based in box, the same workstep could be assigned to multiple processors so that work destined for a particular workstep could be served by any of the n processors running that workstep.

Ultimately, a set of n available processors may be provided, any one of which could run any workstep that had available work as soon as it became free. Limits, however, could be placed on which worksteps a particular processor would be eligible to run. When a user interacts with the system, for instance, that user's workstation could be the only server eligible to execute the corresponding interactive worksteps.

VII. Work Flow

A. Overview

As discussed above, work flows are developed, in part, by defining individual work steps and by defining interconnections between the work steps. These work steps may be either interactive, which require some action or input by a user, or non-interactive, which require no user intervention. The work flow imposes uniformity within a company since work items are treated in a consistent manner as they travel down the work path. Further, with the invention, an even greater degree of uniformity may be provided by using interactive work steps since scripts, prompts, drop-down menus, pre-selected options, and other input or output options can be provided to the user. Because ofthe great degree of guidance that can be given to the user, work flows according to the invention can require only a limited amount of training, thereby significantly reducing costs to a company.

Traditionally, uniformity and consistency are accomplished by hiring inexpensive people and telling them exactly what to do. Unfortunately, work flows typically achieve uniformity and consistency at the price of high quality since work flows do not easily accommodate unanticipated or changing circumstances. Work flows according to the invention, on the other hand, are able to achieve uniformity and consistency while at the same time allowing for high quality. Work steps or even work flows may be altered according to the user, whereby less experienced users may have a greater degree of guidance than less senior users. In other words, more senior users can have greater freedom to apply their expertise to situations in order to produce high quality results. One way in which a company can achieve both high quality and low cost is through a champion-challenger approach to work flow, which will be described in greater detail below.

Because work flows are defined within the repository, developers, and even the customer if the proper permissions are granted, can easily alter a work flow. For instance, individual work steps can be changed, additional work steps may be added, queries may be changed, or interconnections may be altered all within the repository. As a result, developers need not develop a single application for every customer but can easily custom build work flows to specific end-users. Further, even after a work flow is implemented within an organization, altering the work flow is simple enough that the customer can make adjustments to the work flow, again assuming the developer has granted permissions to the customer. These adjustments may be made to improve upon the work flow or may be made in response to changing conditions.

Moreover, changes to work flow may be made and adopted quickly within a company. The users do not require much, if any, training on the changes since the system can be designed to guide the user completely through the process or at least through the revised portions ofthe work flow. As mentioned above, the system can provide scripts to the users instructing them on what to do or say in a given situation. The users are additionally instructed to enter the outcome or response in a given situation, such as the result of the user performing the designated action or saying the prescribed script. The system captures the outcome and responses and, together with all other relevant information, such as the profitability of an account, then decides the next step to take. Consequently, companies can alter and immediately promulgate new policies and procedures in an automated fashion which enables both new and experienced users to receive "just- in-time" training for all situations.

Work flows according to the invention also permit users to exercise more advanced, sophisticated, or complex logic without additional training. Often, work flows would have to adopt simple logic to situations since more complicated logic would be cumbersome and possibly beyond the capabilities of some users. Because work flows according to the invention can instruct the user on what to do or say in response to a certain situation and decide the next step after the user inputs the outcome or response, more complicated logic, such as hyper-segmentation or decision-tree logic, is possible. As will be described in greater detail below, the invention also permits oversight and management of work flows. When a work item passes along the work flow, data which indicates the treatment of that work item at each ofthe work steps is captured. With this data, a company can monitor and analyze all aspects of performance. For instance, reports can be generated to highlight various aspects ofthe work flow. Non- limiting examples of these reports are described below with reference to Figures 52 to 57. Another advantage of work flows according to the invention is that companies can better manage and control work assignment and work loads. The data that is captured at each work step for all work items can be used to identify portions ofthe work flow, such as individual users or specific work steps, that are overburdened and to identify portions that can accept additional work. With such knowledge of work loads, the work flow can be modified so that work assignments or work loads are more evenly distributed, thereby improving efficiency. A further advantage of work flows according to the invention is that the workflow can be optimized through champion-challenger routines. Workflows can be designed so that the work path is altered to test out new work paths. The work path may be altered based on various criteria, such as the user, caller, customer, time of day, date, reasons for call, etc. For instance, certain users, such as those less qualified, can follow a prescribed work path and other more senior users can be given flexibility in testing out other work paths. Champion-challenger aspects of the invention will be described in more detail below.

The invention also allows for a great deal of commonality between call-centers and web-based customer self-service. As discussed above, the invention can guide the users completely along the work path with scripts, pre-defined inputs, outputs, etc. In a similar way, the guidance that is designed for the user can easily translate into a web- based interface that is provided to the customers.

The methods and system according to the invention can be used to develop and to implement workflows for a variety of uses. Preferred embodiments of workflow are directed to systems and methods for managing financial accounts, such as payment processing systems for credit cards. Consequently, when explaining certain aspects of the invention, reference may be made to a payment processing system as an illustrative example.

Users are able to take existing user-defined workflows and edit them. Users can save a new or modified workflow with a given name, and then give some number of users access to the new workflow without affecting the existing production workflows and users. User access to workflows have both starting and ending effective dates. This enables workflows to be installed, and having the system switch over from the old system to the new system. A number of workflows, some of which may be modified versions of others, may be stored in the system at the same time. For audit trail purposes, all history would include work step id and version id.

The IDE editor according to the invention enables users to define work steps, actions, and routing rules to guide the units of work through the stages of processing. An advantage of a system like this is that it enables administrators at a site to monitor and control their workflows and processing rules, adjudicating an increasing number of cases and taking an increasing number of actions without human intervention.

B. Work Flow Case Management

For the purposes of this description, a case is a unit of work and is created, routed among various work steps, and completed. A work step is a processing step and typically will require a human, but this is not required. A single work step may define everything a user does with a case, or the user may go through multiple work steps and branches in the course of processing a unit of work. A queue is an ordered and prioritized collection of cases awaiting processing in a work step. Routing rules are expressions which control which processing path a case should take while actions are actions that can be taken by the system in a work step. The set of actions can be expanded only by adding functions to the underlying application. However, the available actions may be selected and invoked with parameters. Users define the users that may access the system, and control which of the workflow capabilities to which they have access. Time/event handling is a way for the administrator to set minimum and maximum time limits on future actions, and to control the handling of external events such as receipt of payment. Event logs allows one to maintain the history of each case, which is important for making decisions based on the history of the case and for comparing different approaches to handling the cases. In addition to these core constructs, users need a way to make changes to workflows in a systematic and controlled manner, and a way to help decide which of several proposed workflows are the best. This user-controlled workflow is applicable to many modules of a card processing system, including new applications, collections, fraud handling, customer service, interchange tracking, dispute resolution and others. The invention provides a set of constructs common to these applications that can then be shaped to meet individual needs by application programmers and users. A second major application ofthe functionality provided with the invention is in operations process management. This functionality enables administrators to largely automate the detection and response to exception conditions which arise during the course of processing. For example, administrators can define actions that should take place automatically when the oldest unprocessed application is more than X days old, when the oldest incoming call has waited more than X minutes, when the workload of collections exceeds X cases per collector, when a worker's rate of resolving disputes drops below X per day, etc.

The definition of all cases have some elements in common. Cases will correspond to messages that are sent through workflows. The programmer will set up what a case is. The main requirements are that it is possible to find a case given knowing something about it (the name ofthe person involved, the number ofthe account, etc.); the history of the case is logged in terms ofthe date/time and work step processing history. The work step processing history includes the id of each work step and potentially the id ofthe champion or challenger of which it is a part.

For processing a new account, the case record may contain all the same information as an application. For handling a dispute, the case record may contain the entire message received from the network. For handling collections, the case message may contain little application information, but may be just a place holder for information in other places. After a work step, the administrator needs to be able to control the further processing ofthe case. To do this, the administrator defines one or more branches, or possible paths which the case may take. For each branch, the administrator defines the conditions under which the case will take the branch. Each branch or path is a queue. The conditions are a test which may be arbitrarily complicated. Essentially, the administrator should be presented with an interface that allows him to select any variables in or related to the case, the previous events in processing the case, or other data which can be accessed. The administrator should be able to form expressions out of the variables.

Queues connect actions that an operator might take while a case is on his desk. So if a dialog with a caller is scripted, a case corresponding to a dialog which is only partly finished should not be suddenly routed to another operator. This can be accomplished by designating a set of work step steps as being unitary, so that once a user is assigned to the case, that same user carries the case through the entire workflow, until the end of the section designated as unitary. With this exception and a probable difference in implementation, the meaning and function of queues remains the same. Within the unitary area, there will only be one queue that has anything on it, and only one user will ever process work steps for the case. The order of items in queues is determined by the priority field in the case message. This priority can be set by formulas in work steps, and can be read by routing rules.

Administrators are preferably not given the full range of work steps to choose from. Instead, they can route work to existing work steps or they can create new work steps which contain scripts. The scripts, are selected by the administrator and some examples of which include:

* Send a letter. The letter would be handled by an external package and would have text substituted or merged into it from the application, as specified in the arguments.

* Execute application-defined workflow/work step. For example, send request for information to a credit bureau. * Schedule a call to a person.

* Say something to a person, and have the operator select which choice best describes the response. The "say" string would be formatted text which could have variables substituted into it from any related variable. The possible outcomes or responses would be determined by the supervisor, and can be used in routing rules. * Cause a form to appear on the screen, e.g. enter variable payment schedule or enter information regarding dispute. For any of these scripts and other possible scripts, the system can also require the operator to enter the outcome. If the script involved saying something to a person, the outcome could be the reply from the person. As another example, if the script involved scheduling a call, the outcome could be that the scheduling was successful or unsuccessful. Based on the outcome, the system can determine the next workstep.

C. Timers

If a case is placed on a queue, the case is kept there for a specified time interval, barring external events. The intended action is specified to take place at a certain time, either relative or absolute. The item is preferably kept in the queue and is not fed it into a work step until the time is ready. One kind of time is an actually scheduled event. Another is a time limit which, when passed, causes a new sequence of actions to take place. The scheduled time should take priority over a time limit lapsing by default.

Events initiated outside the system are noted and accounted for in the workflow. Certain external events can initiate cases, for example receiving a phone call on a new issue, receiving an application, or receiving the first notice of a disputed transaction. Any of these events cause a case to be created and sent on a workflow. In addition to internal events, an external event related to a case which already exists can initiate a case. If the external event is unanticipated, the person taking the call first finds the case in process and determines whether he or she has permission to affect the status ofthe case. If the external event is anticipated, such as a response from the credit bureau, a call from the collectee in response to a letter, or a response from the merchant concerning the dispute, then the following are specified or defined:

* The expected response. * The time limit for waiting.

* The actions to take, such as which queue to go onto, if the response has not taken place by the time limit.

* The actions to take when the response is received.

The system thus provides a central way to identify an event which expects a response, and the programmer provides a method for matching newly arrived events to cases which expect responses. When events are received from the outside, sometimes all the events are going to be responses to requests e.g. credit bureau information. In other cases, the events will be a mixture of "new" and anticipated e.g. many interchange messages.

While it should be possible to turn it off, the normal case will be that administrators will want a log in uniform format which records each important event in the system. In particular, for each case, the log should include the id ofthe case, the date/time it entered which queue or which work step, and the id ofthe user who handled the work step if any. The contents ofthe event log are used in making routing decisions about the case. While it may be possible to handle time by a special kind of work step, making a special kind of queue that knows about time is preferred. The queue message store expects to see certain data elements in the message which would specify the time that the message should be made available.

A special work step could be devised to handle actions. However, it may also make sense to define a particular work step for each type of action; this allows the use of user-exit work steps. Then when a user selects an action, a copy of the model work step for that action is placed into the workflow. Several actions in succession are simply several work steps linked linearly. This approach exposes the actions more easily in the event log. A special work step could filter a stream of incoming events and match them against a store of cases which are pending responses. The store would be set up to let the case out on one path if the time limit expires, and on another path when a match comes in. The method of doing the matching is specified, preferably by some unique key which appears in both messages. If there is a match, the case "picks up" the incoming event, such as through a query.

D. Work Flow Example

An example of a payment processing system will now be described with reference to Figure 40. One important aspect of a payment processing system is the detection of fraud. Fraudulent use of credit cards presents a large cost to the issuers of the cards and early detection of fraud can be vital to reducing this cost. Many systems have been developed for monitoring credit card transactions in order to detect aberrant behavior which might suggest fraudulent use. The invention may use any suitable system or application for detecting possible cases of fraud and preferably uses Fraud Intercept software from Fair, Isaac and Company, Inc. With reference to Figure 40, a PC table maintenance system defines fraud intercept control files, which include system parameters, SPID assignment, scorecard assignment, and Post-Auth and In-Auth fraud detection strategies. In general, the fraud detection strategies include conditions or scenarios that will result in a case being passed to a workflow based case management system, which is preferably Fraud Dossier. A post authorization module facilitates movement ofthe In-Auth control files to a host system (an AP application), stores transaction data for scoring, calculates a Post-Auth Review score (PAR), makes possible estimator reporting, and executes Post-Auth fraud detection strategies. The Post-Auth fraud detection strategies include the ability to identify accounts to be flagged for In-Auth action and accounts to be passed to a workflow-based case management system for managing fraud. In the preferred embodiment, the case management system is called Fraud Dossier. For those accounts requiring real-time action, a pre-authorization score is calculated. For those accounts past due Post-Auth fraud detection strategies identifies the complexity of the potential fraud. An In- Authorization Module resides within the AP environment. POS transactions are passed to the In-Auth module via the host system and are evaluated for authorization and fraud in real-time. The authorization processor (AP) defines authorization features such as the type of authorization processing, which may be post, cooperative, stand-in, or standalone. The AP also defines the method, such as positive file with balance authorization, negative-exception file or positive file. The AP further defines such things as the card groups. This workflow, an example of which is called Fraud Dossier, provides a case management fraud queuing system. Suspected fraudulent transactions are assigned to cases and queues based on fraud intercept strategy outcome scenarios.

E. Fraud Dossier workflow A preferred work flow for Fraud Dossier will now be described with reference to

Figure 41. The work flow involves work steps that are interactive, thereby requiring action by an analyst, and non- interactive work steps, represented by dotted boxes which do not involve any analyst action. An analyst preferably is presented with a main case screen as shown in Figure 42. The main case screen includes case information, such as case number, card number, customer name, case category, and case keyword. The main case screen also includes case action having fields for a script and outcomes, both of which will be described in further detail below, has information on the financial institution ID and name, and has several tabs of information, which include an "Account Information" tab having card number, status code, current balance, number of cards, overdraft status, and overdraft number of days. The Account Information tab has score information which is ascertained from the Fraud Intercept system. The score information may include other scores, such as from a credit or other application scoring system.

Information that is preferably provided on a "Customer" tab is shown in Figures 43(A) to 43(C). The Customer tab may be further divided into subtabs, such as "Card Holder 1 & 2," "Card Holder 3 & 4," and "Base Line." The Customer tab therefore provides card holder's names, social security numbers, dates of birth, maiden names, issue dates, balance information, and address information. An example of a "Card" tab is shown in Figure 44. The Card tab includes the name ofthe card holder, social security number, date of birth, telephone numbers, maiden name, issue date ofthe card, and address information. A preferred example of a "Transactions" tab is shown in Figure 45. As the name suggests, the Transactions tab includes information on transactions for a particular card. The Transaction data preferably includes transaction date, time, amount, authorization code, reason code, merchant code, and fraud score. A preferred example of a "Customer Notes" tab is shown in Figure 46. "Customer Notes" allows the user, such as a customer service representative, to take notes about what a customer says for later review. Multiple notes may be associated with a particular case.

The main case screen shown in Figure 42 has several buttons for "Case Notes," "Case History," and "Acct History." An example of a diagram ofthe account history dialog is shown in Figure 47. The account history button preferably displays notes, history, and transactions of all cases associated with the current account for a predetermined period of time, such as for the past 12 months. The account history dialog preferably includes case information, case history, case notes, and transaction information.

The work flow example shown in Figure 41 will now be described in further detail. A fraud analyst initiates the work flow by selecting "Case" from the main case screen menu bar and selecting the "Work Next Case" option. As shown in Figure 41 , work step 1 involves calling the card holder or receiving a call from the card holder. An example of an interface provided to the analyst for calling the card holder is shown in Figure 48. As shown in this Figure, the analyst is presented with case information, such as case number, card number, and customer name and is also presented with case action, which includes a script for prompting the analyst to perform certain action. In this example, the analyst is prompted to "Call Card Holder 1 Freddie CHMURA" at a certain telephone number. The outcomes field within the case action section provides a dropdown list containing responses or results for the case. These options may include bad phone, left message, busy, too early to call, or too late to call. The system uses the particular outcome selected by the analyst to determine the next work step within the work flow. For instance, if the call is established, the work flow proceeds to Work step 2 which involves inquiring about the transaction. On the other hand, if the outcome is a bad phone, left message, or busy, the work flow proceeds to work flow 3 which involves incrementing to the next possible phone number for that card holder. As shown in the work flow diagram in Figure 41, work step 3 is a non-interactive work step in which the Fraud Dossier system automatically increments to the next possible telephone number. If a number is available, the work flow returns to work step 1 where the analyst attempts to call the card holder. When there are no more telephone numbers for that card holder, the work flow proceeds to work step 1 1 in which the analyst marks the transaction as a suspect block but does not involve an actual card block. Next, after work step 1 1 , the work flow proceeds to work step 6 which is a non-interactive work step involving updating the host system and is followed by work step 5 in which the analyst closes the case or reschedules it to a future time.

As mentioned above, work step 2 involves inquiring about a transaction with the card holder. An example of an interface presented to the analyst is shown in Figure 49.

In this example, the analyst is presented with a script that prompts the analyst to verify the customer's address, telephone numbers, and credit reporting errors. At this work step, the analyst is preferably provided outcomes for removed-block, stolen card-block, lost card- block, fraud-block, and suspect-block. A default option under the outcome is preferably designated as no-block. The outcomes may also include an indication to do not disturb (DND) the cardholder. If a DND is entered by the analyst, the work flow then proceeds to work step 10 where the analyst enters the date followed by a non-interactive work step 7 which involves updating the host system and DND date. After work step 7, or if the analyst entered a block without a do not disturb entry, the work flow proceeds to work step 6 where the host system is updated with the appropriate block code. Next, the work flow moves to work step 5 where the case is either closed or rescheduled.

Based on the analyst input at work step 5, the work flow either proceeds to work step 12 where the case is closed or work step 13 where the case is rescheduled. When a case is closed, the work flow proceeds to work step 12 which is a non-interactive work step and which the system updates the host system status code. The analyst may then select the next case and return to work step 1 with this next case. When the analyst indicates that the case needs to be rescheduled at work step 5, the work flow then proceeds to work step 13 where the analyst may enter a date at which time the system places the case back in the analyst queue for processing.

Some sample work flows will now be described to further illustrate the work flow shown in Figure 41. In a first sample work flow, the analyst is presented with a script to call a card holder 1 at home at a particular number. In response to the card holder answering the call, work flow proceeds to work step 2 where the analyst inquires about the transaction in question. At this work step, the card holder responds by indicating that the transaction is fraudulent and the analyst consequently places a fraud block on the transaction. The work flow then proceeds to work flow 6 in which the system automatically sends an update to the tandem blocking the account followed by work step 5 in which the analyst is questioned in the script as to whether to close the case. The analyst selects a reschedule outcome whereby the case is rescheduled for later review. In this first example, the analyst had the ability to place the block on an account. The preferred practice is not to allow the analyst to place the block but instead for an agent to inform the system of an outcome and to allow the workflow to decide whether to block the card. For example, the system might direct the agent to ask the customer whether he/she made a particular transaction. The possible outcomes could include: (1) the customer made the transaction; (2) the customer did not make the transaction; and (3) the customer is unsure. Based on the outcome, the workflow may decide to block, not to block, or to direct the agent to obtain more information.

In a second sample work flow, the analyst at work step 1 is prompted to call the card holder at home at the certain number. The card holder does not answer the call in this work flow and instead the analyst encounters a bad telephone number. The analyst therefore selects the bad phone option for the outcome. The work flow then proceeds to work step 3 in which the system automatically sets the phone to the card holders business telephone number. Work flow then returns to work step 1 in which the analyst tries this new telephone number. According to this sample work flow, the card holder answers the call, the analyst selects the card holder 1 out-bound as the outcome and the work flow proceeds to work step 2 where the analyst inquires about the transaction in question. The card holder indicates that the transaction is fraudulent and the analyst places a fraud block on the transaction. As with the first sample work flow, the work flow then proceeds to work step 6 in which fraud Dossier sends an update to the tandem blocking the account. In the second sample workflow, however, the analyst selects to close the case at work step 5 rather than reschedule. In a third sample work flow, the analyst encounters a bad telephone number at work step 1 and selects the bad phone outcome. Fraud Dossier then at work step 3 sets the phone to the card holder^'s business number and, at work step 1, the analyst then tries this number. After the card holder answers the number, the analyst is prompted at work step 2 to inquire about the transaction in question. In this sample work flow, the card holder responds by saying he purchased the item, in which case the analyst selects the No- Block outcome. The work then proceeds to work step 5 in which the analyst is questioned as to whether the case should be closed. The analyst then indicates the outcome as Close to close the case.

In a fourth sample work flow, the analyst calls a card holder and leaves a message since the call is not answered. In response to the left message outcome being selected by the analyst, work flow proceeds to work step 3 in which fraud Dossier sets the phone to the card holder's business number and returns to work step 1 in which time the analyst calls the business number. According to the sample work flow, the card holder does not answer and the analyst leaves a message at this work number. In response to the left message outcome being selected by the analyst, work flow proceeds to work step 3 again where the phone is set to the business number of card holder no. 2. At work step 1 , the analyst calls the second card holder and leaves a message when the phone is not answered. Fraud Dossier then sets the phone number a card holder's third business number and the analyst tries this third card holder's number at work step 1. After leaving a message with this third card holder, fraud Dossier sets the phone number to a fourth card holder's business number and the analyst tries this number at work step 1. After the analyst leaves a message with this fourth card holder, the work flow proceeds to work step 3 and, in this example, finds that there are no more valid phone numbers. Processing therefore moves to work step 11 where the analyst is given the option of selecting a block. In this example workflow, the analyst marks the case as a suspect-block and at work step 6 the host system is updated to have a block code of suspect-block. At work step 5, the analyst is scripted to either close the case or reschedule and the analyst selects the reschedule outcome. Accordingly, the work flow proceeds to work step 13 at which point the analyst reschedules the case for the next day. On the next day, the analyst is presented with this case again, and at work step 1 calls the card holder at home. This time, the card holder answers the phone and states that he had purchased the item in question. The analyst therefore selects the no-block outcome.

F. Authorization Examples

The invention is not limited to Fraud Dossier but can be applied to the entire payment processing system shown in Figure 40. For instance, examples of authorization workflows will now be described with reference to Figures 50 and 51 to illustrate how two authorization requests, one resulting in an approval and one in a decline, make their way through the system.

Figure 50 depicts an example of a workflow that describes a path for an approved transaction. Unless marked as a source or sink, each work step is a Mapper. Note that all message passing uses the Standard Authorization message, with the following exceptions: the message that "Visa In" passes to "Parse Visa In" is a Visa Authorization message, and the message that "Auth Outgoing" passes to "Visa Out" is a Visa Authorization message. The "Approvals'^* sink is a logical store that provides a view ofthe approved transactions for a given account. The Visa In work step is a message store that is the source of transactions for the workflow. For the prototype, it reads parsed Visa Authorization messages from a flat file and is always ready to run. When the transaction engine passes control to Visa In, it logically reads the next line/message from the input file (in its implementation, it might buffer messages to be more efficient) and formats it as a dBB Visa Authorization message and then calls a transaction engine method to place the message on its single output category.

The transaction engine knows there is a single message store (a queue) associated with Visa In's output category. It calls the queue's method to place the message on that queue. Since the transaction engine knows that all the queues for this scenario are running on the same machine, it also knows that it is the only producer and consumer of messages for the queues. So it can keep a count of how many messages are in each queue. If there were a queue that had a different source for message (e.g., an IPC queue), the transaction engine would either need to poll the queue to see if it had any messages, or the queue would have to indicate (via shared memory or interrupt) that it had a message. This queue connects to the Parse Visa In work step. Since the queue has a message in it, the transaction engine knows it can schedule Parse Visa In to run, so it places it in ready- to-run list ofthe appropriate priority. When it is ready to run Parse Visa In, the transaction engine uses a queue method to get the next message, and it calls the Parse Visa in work step's execute method, passing it the Visa Authorization message. Each work step follows the following sequence of steps, as appropriate:

Restrictions will be turned on for the Parse Visa In work step, so the first step the work step does is check the values ofthe Visa Authorization data element parameters against any restrictions. In this example, the values for all parameters pass. The work step calls a context object method to add the Visa Authorization message to a context, which is an in- memory data work area. The work step next instantiates the messages for the message types associated with its output categories. If the same message type is associated with multiple output categories, the work step only creates one instance of that message type. A Standard Authorization message type is associated with its success output category, so it creates a new message instance of that message type using default values, and it adds it to the context. Next, the work step executes its queries. There is one query associated with Parse

Visa In. The work step executes it to find the associated Visa Account BIN Location message and adds it to its context. If there are any assignment expressions associated with a work step, it executes these next. There are a collection of assignment expressions associated with the Parse Visa In work step, most of which map values from the Visa Authorization message to the Standard Authorization message. One ofthe expressions is interesting in that it evaluates a substring of Standard Authorization's account number, starting at a position and with a length that are specified in the Visa Account BIN Location message. To execute this assignment, the expression object would pass the account number, starting position, and length to a substring operator object, which would return the resulting substring. A work step finishes its main work by evaluating the selectors (Boolean expressions) associated with its output categories. This category would check an error data element ofthe Standard Authorization message, which in this scenario would contain its default value of no-error. The success output category would match, and the work step would ask the transaction engine to put the Standard Authorization message on the queues associated with that success output category. The transaction engine asks the Standard Authorization message for a new reference to itself (resulting in incrementing an internal reference counter) for the first queue associated with the output category, and it asks it for a copy for each additional queue. For this work step, there is only one queue associated with the output category. Finally, the work step calls the context's flush method, which calls the destructors for each of its associated messages.

According to the example workflow described above, the Standard Authorization message will go to the Visa Validation work step. It will follow the same steps described for the Parse Visa In work step, with the following differences: since the work step wants to simply pass the Standard Authorization message through to the output (with possible changes), it does not instantiate a new copy. It simply points to the Standard Authorization message that already exists. Alternatively, the application programmer could have the option of asking for a separate copy.

Two queries are associated with the Visa Validation work step. The first uses Standard Authorization to find the appropriate BIN Control message and the second uses Standard Authorization to find the desired Visa Validation Categories message.

Four interesting output categories whose selectors check fields in the Standard Authorization message to see whether (1) the authorization is on a different bank (not on us), (2) is an authorization on this bank (on us), (3) is an inquiry for this bank, or (4) is a reversal for this bank. In this example with an "on us" authorization, the Boolean expression for that output category will be evaluated to Authorization message out through the "on us" output category.

The "on us" output category connects to the Authorization On-Us processing work step. This work step has the following special characteristics: There are four queries with two of them being straightforward mappings, one from the Standard Authorization message to the appropriate Authorization Account Master message, and the other from the Authorization Account Master message to the desired Authorization Account Status message. The other two queries require information from both the Standard Authorization message and from the Authorization Account Master message in order to find the necessary Authorization Block Code Control and Authorization Control messages.

Most of the assignment expressions set fields in the Standard Authorization message to indicate the results of various validity checks (e.g., valid expiration date, card has been activated). The workflow allows for overrides for each validity check according to whether the issuing organization cares about that particular check. The workflow also allows for a customer VIP status that overrides some validity checks.

Two interesting output categories correspond to approving or declining the transaction. The selector for the "approved" output category evaluates to true if and only if every validity check is true. The "declined" category selector evaluates to true if or only if every validity check is true. For example, if all validity checks pass, the work step asks the transaction engine to place the Standard Authorization message on the queue associated with its "approved" output category. When the transaction engine takes the Standard Authorization message from the Authorization On-Us work step, it asks the message for a second copy (by reference) of itself. It puts one copy on the queue that connects to the Approvals work step and the other copy on the queue that connects to the Authorization Outgoing work step. A preferred approach, as depicted in Figure 51 , uses the Approvals work step as a logical message store. Alternatively, a work step may be placed in between the Authorization On-Us and Authorization Outgoing work steps. Using the Approvals work step as a logical store is preferably because it exercises logical message store, temporarily, and derived data element values. With this approach, the Approvals work step takes each Standard Authorization message and stores it in a logical store. That is, a logical store exists for each account number that corresponds to the approved transactions for that account for each day.

The Authorization Account Master message has several fields that correspond to counts of approved transaction values. For example, one field is the count of approved transactions for each account and is defined as having a derived value that is the Count of the records in the Approvals logical message store. Another example is a field that is the total amount authorized each day for each account. This field is defined as having a derived value that is the Sum ofthe AmountApprovedAu hToday field of each record in the Approvals local message store. An alternate approach to implementing workflow does not require logical message stores or derived data values and may be desirable, for instance, should time or other pressures require scale backs in any prototype implementation plans. With this approach, a work step (called Authorization Approval) is fit between the Authorization On-Us and Authorization Outgoing work steps. With this approach, the logical store Approval work step disappears.

The Authorization Outgoing work step has a single query that finds the Authorization Account Master message. The assignment expressions update the counts described as derived date element values above. The Authorization Outgoing work step follows the standard work step process, with the following particulars. One category that connects to the Authorization Logging work step has the Standard Authorization message type associated with it, and a second category that connects to the Visa Out work step has the Visa Authorization message type associated with it. The work step uses the input Standard Authorization message for the first output category, and it creates a new default value instance ofthe Visa Authorization message for the other output category. There are no queries associated with this work step. All the assignment expressions map values from the Standard Authorization message to the Visa Authorization message. Both output category selectors have Boolean values of true, so they will both output messages and leave the work step.

The Authorization Logging work step is a message store. It provides a record of all the transactions that the system receives. The Visa Out work step is a message store. The Visa Out work step takes the values from the Visa Authorization message and sends them out over a transmission line, performing the opposite task of the Visa In work step. Alternatively, the Visa Out work step may store the messages in a file.

Figure 51 shows a workflow map that executes for a declined transaction and is generally the same as the approval workflow except the Approval work step is replaced by a Declines work step. This scenario is exactly the same as the Approvals scenario except that the message takes the Decline output category of the Authorization On-Us work step, based on one or more ofthe validity checks failing. The Declines work step is a logical store ofthe transactions that were declined each day for each account. Again, the logical message store may be dispensed with and an Authorizations

Declined work step may be placed between the Authorizations On-Us and Authorizations Outgoing work steps. That work step would update the appropriate fields in the Authorization Account Master message.

VIII. Workflow Oversight

The system places the data into a fact table, that has been set up as part of a star schema. Since star schemas are known to those skilled in the art, a complete explanation ofthe star schema will be omitted. By placing the data in a fact table organized in a star schema, traditional reporting tools such as Crystal Reports and Data Warehousing OLAP tools are able to access and process the data. These OLAP tools provide sophisticated data analysis capabilities. With this data, a company could (1) compare the productivity of its agents, (2) use demographic information to see if some agents do better with certain segments ofthe public and, if so, modify the workflow to have them work mainly with people from those segments, and (3) compare the productivity of a champion strategy versus a challenger strategy. With this information, a company could modify a workflow to have a group of agents work with the demographic sector and strategy that works best for that group. Other examples and applications of Data Warehousing will be apparent to those skilled in the art and are encompassed by the invention.

IX. Reports Fraud Dossier preferably is able to generate several types of reports. These reports may be generated automatically, such as at a set interval of time, or may be generated at request. Fraud Dossier provides an efficient and effective reporting system that is unique in that no batch processing is necessary. Instead, reports are always available and contain real-time data. Because Fraud Dossier does not depend upon batch processing, Fraud Dossier provides a reporting system that is both faster and more accurate. The outcome fields discussed above are a main component of the data in the reports. The outcome details are captured in a dedicated database and become attributes used in the various reports. Access to the reports may be restricted based upon the user security level.

One example of a report that may be generated is a Detailed Case Report. The Detailed Case Report provides complete history for a specific case. From the day of creation to the time of closure, the detailed case report history records every action taken to manage each case. This report can be generated on request by using a unique case number and report information can be viewed on screen or sent to a printer. The detailed case report can be used to internally track the progress of a specific case or can be sent to the financial institution related to the account. For instance, this report may be used to notify financial institutions of adverse actions taken for specific card holders. This notification may be sent via e-mail or through some other routing mechanism, such as facsimile. An example of a detailed case report is shown in Figure 52.

A queue activity report is another type of report that is preferably provided with Fraud Dossier. The queue activity report provides outcome activity by analyst for each financial institution based on their risk level or fraud score. The queue activity report maintains queue identification and provides client totals. The report also displays weekly counts for the number of opened cases, number of fraud cases, number of no fraud cases, number of rescheduled cases, number of blocked cases, number of removed block cases, number of letters generated, number of pending cases, number of outbound calls, and number of inbound calls. An example of a queue activity report is shown in Figure 53. Another type of report is an analyst activity report which provides an activity listing by analyst sorted alphabetically by name. The analyst activity report displays the name of each analyst and the related outcomes, for given date range, for the following outcomes: number of open cases, number of fraud cases, number of no fraud cases, number of rescheduled cases, number of blocked cases, number of removed blocked cases, number of letters generated, number of pending cases, number of outbound calls, and number of inbound calls. An example of an analyst activity report is shown in Figure 54.

The analyst activity report provides the ability to drill-down functionality at the analyst row level. By performing such a drill-down function, an analyst details by outcome subreport is generated. This subreport provides the ability to expand a specific analyst row to display the detail of every action taken. This sub report also displays the total number of activities for each ofthe following outcomes: number of open cases, number of fraud cases, number of no fraud cases, number of rescheduled cases, number of blocked cases, number of removed blocked cases, number of letters generated, number of pending cases, number of outbound calls, number of inbound calls, institution ID, card number, and case number. An example of an analyst details by outcome subreport is shown in Figure 55.

A client summary report provides information for each financial institution and includes summarized case data by account. The client summary report is automatically generated based upon a predefined schedule and produces a file format report. The report includes the case information, such as the card holder's name, the card holder's account number, the date the case was opened, the date the account was blocked, and the case was closed, if applicable. The report also displays information for a given date range for the categories of confirmed fraud, blocked and unable to contact, unable to contact and no block, and no fraud apparent. An example of a daily client summary report is shown in Figure 56.

A monthly case activity report is similar to the client summary report but provides additional outcomes. The monthly case activity report may be distributed to each institution on a periodic basis, such as monthly or may be generated on command. The report provides a grand total for each financial institution of each ofthe following outcomes: number of opened cases, number of fraud cases, number of no fraud cases, number of rescheduled cases, number of blocked cases, number of removed blocked cases, number of letters generated, number of pending cases, number of outbound calls, and number of inbound calls. An example of a monthly case activity report is shown in Figure 57.

A client summary fixed format file is similar to the client summary report but creates a fixed length disk file on a monthly basis. The file is then reviewed to verify charges and may be distributed to each financial institution. The information captured in this file includes the number of outbound calls, number of inbound calls, number of letters generated, number of cases blocked, and the number of cases opened.

IX. Champion Challenger

More elaborate methods of change testing are also possible with the invention in addition to this change management system. One example of such a method is an implementation of a champion challenger management system. According to one aspect of champion/challenger, a main production workflow exists through which most of a system's work passes. Administrators devise challenger strategies at will. A challenger strategy is typically an edited version of a production workflow which may have changes of any kind, but often in which the routing is more refined and which may involve more work steps.

After creating a challenger workflow as a proposed replacement for part or all of an existing production workflow, the administrator defines terms that control the "challenge." By defining the "challenge," the administrator controls: * when the trial starts

* when the trial ends * whether randomly selected messages are to be given to the two workflows

* what is the fraction of messages to be given to the challenger (from 0 to 100%)

* which users are assigned to which workflows

The system tracks which cases went through which branch ofthe workflow, such as the champion or one ofthe challengers. The invention is not limited to just a single challenger but instead can incorporate a plurality of challengers. These multiple challengers may focus on the same area of a work flow and test out different options or may be focused on different portions ofthe work flow. The star schema warehouse detail is preferably provided in a format that enables analysis to be performed ofthe two methods on any grounds the user chooses, which will certainly vary. The data may be dumped into a warehouse with a template for making comparisons on the most typical grounds: processing time, processing cost, elapsed time, etc.

After the effective time for the challenger workflow passes, no further actions are taken without user input. The workflow is still in the system, but no cases get routed to it, and no users interact with it. The administrator can edit the challenger in any way, including making more changes, running another trial, etc.

A champion workflow isn't really different in principle from a challenger. An unchallenged workflow has:

* a starting effective date in the past * an ending effective date either in the future or not set

* all the messages routed to it

One way of thinking about champion/challenger is to imagine a built-in work step which starts a challenge and another that ends one. These work steps bracket the section ofthe master workflow that contain the portion being challenged. The starting work step has all incoming messages routed to it, and has two outputs, one for the champion branch and one for the challenger. It reads the administrative control information, and distributes incoming messages to the outputs according to the controls. In addition, it sets something that enables the messages to carry which path they went down. The ending work step does the reverse: it merges the message streams and produces a single output. Proposed workflows may be tested in other ways, such as in a more conservative way than champion/challenger. Champion challenger is preferred when some existing workflow works and attempts are made at improving it. To test whether an improvement works, the modified workflow is placed into a separate environment and is fed test data.

The functionality specified above would largely be under the control ofthe normal application programmer. However, for the part that is under administrator control, a user interface is provided that enables the administrator to view the workflows which are in effect, make changes, etc. The full end users of the system who process workflow items are unaffected by this functionality and have no way of knowing whether a work item got to them under the control of an application programmer or an administrator-defined workflow. The administrative functions supported include the following:

* Browse, edit and add workflows according to established user permissions

* Browse, edit and add champion/challenger editions of workflows

* Access workflow transaction history to evaluate strategies, user productivity, etc. The possible functionality for administrative reports and analysis is endless. A strategy that enables extremely simple selections of transaction history (e.g. by date range and/or user group and/or case type) to be made, with the resulting full records being loaded into a database and/or Excel for analysis. Of course, the database itself is available for access by report writers and query tools. The reports discussed above with reference to Figures 52 to 57 are preferred examples of what types of reports are possible with the invention. Figure 54, for instance, is an analyst activity report and provides an activity listing for each user or analyst. From this report, an administrator can review the activities of each analysts, such as the number of open cases, the number fraud cases, number of rescheduled cases, etc. The other reports discussed above provide other information from which an administrator can analyze the performance of a system. The forgoing description ofthe preferred embodiments ofthe invention has been presented only for the purpose of illustration and description and is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many modifications and variations are possible in light ofthe above teaching.

The embodiments were chosen and described in order to explain the principles of the invention and their practical application so as to enable others skilled in the art to utilize the invention and various embodiments and with various modifications as are suited to the particular use contemplated.

Claims

CLAIMS What We Claim:

1. A payment processing system for use in managing accounts, comprising: a plurality of worksteps interconnected to each other to define a workflow for handling management of customer accounts, each workstep performing a unit of work in the workflow; a plurality of categories wherein each category is associated with one ofthe worksteps and controls routing of work for the associated workstep; and a plurality of connectors for interconnecting the worksteps to each other, wherein each connector couples at least two worksteps to each other; wherein attributes of at least the worksteps are defined in a declaration space within a repository.

2. The system as set forth in claim 1, wherein at least one ofthe worksteps provides a proposed script that may be recited by a user.

3. The system as set forth in claim 1, wherein the workflow is dynamically altered based on a condition of a workflow criteria.

4. The system as set forth in claim 3, wherein the workflow criteria comprises a user whereby the workflow is dynamically altered based on the user.

5. The system as set forth in claim 3, wherein the workflow criteria comprises time whereby the workflow is dynamically altered according to a time at which the workflow is executed.

6. The system as set forth in claim 3, wherein the workflow criteria comprises a financial institution whereby the workflow is dynamically altered based on the financial institution associated with a particular account.

7. The system as set forth in claim 3, wherein the workflow criteria comprises a champion challenger unit for modifying the workflow.

8. The system as set forth in claim 1, wherein the worksteps include interactive worksteps, which require action by a user in performing work, and non- interactive worksteps, which do not require any action by a user in performing work.

9. The system as set forth in claim 1 , wherein the worksteps include a priority attribute for setting a relative priority on execution of worksteps in the workflow.

10. The system as set forth in claim 1, further comprising timers for regulating placement of messages in queues.

11. The system as set forth in claim 1 , wherein attributes ofthe categories are defined in the declaration space within the repository.

12. The system as set forth in claim 1, wherein attributes ofthe connectors are defined in the declaration space within the repository.

13. The system as set forth in claim 1, wherein attributes of the workflow are defined in the declaration space within the repository.

14. The system as set forth in claim 1, wherein at least one ofthe worksteps informs a user how to perform a task.

15. The system as set forth in claim 14, wherein the one workstep provides a script to the user.

16. A system for performing workflow, comprising: a repository having a declaration space for storing definitions of messages, for storing definitions of worksteps, and for defining a workflow, wherein each workstep performs a unit of work in the workflow; and a transaction engine for passing messages between worksteps according to the workflow; wherein changes to the workflow are made by altering within the declaration space the definition of any workstep.

17. A system for performing workflow, comprising: a plurality of worksteps, with each workstep performing a unit of work on a message; a plurality of categories, with each category being associated with one ofthe worksteps and controlling message routing for the associated workstep; and a plurality of connectors for interconnecting the worksteps to define the workflow, with each connector coupling at least two worksteps to each other; wherein the worksteps include interactive worksteps, which require action by a user in performing work, and non-interactive worksteps, which do not require any action by a user in performing work.

18. The system as set forth in claim 17, wherein the worksteps includes a source workstep for receiving data from a data source, a sink workstep for placing data in storage, and a mapper workstep for performing an action on data associated with a message.

19. The system as set forth in claim 17, wherein execution of one workstep occurs in parallel to execution of at least one other workstep.

20. The system as set forth in claim 17, wherein the categories control the transfer of messages between worksteps.

21. The system as set forth in claim 17, wherein at least one ofthe interactive worksteps instructs the user on how to perform the action required by the user.

22. The system as set forth in claim 21, wherein another one ofthe worksteps receives input from the user on results ofthe action.

23. A system for performing workflow, comprising: a plurality of worksteps, with each workstep performing a unit of work on a message; a plurality of categories, with each category being associated with one ofthe worksteps and controlling message routing for the associated workstep; and a plurality of connectors for defining the workflow, with each connector coupling at least two worksteps to each other, wherein the workflow is dynamically altered based on a condition of a workflow criteria.

24. The system as set forth in claim 23, wherein the workflow criteria comprises a user whereby the workflow is dynamically altered based on the user.

25. The system as set forth in claim 23, wherein the workflow criteria comprises time whereby the workflow is dynamically altered according to a time at which the workflow is executed.

26. The system as set forth in claim 23, wherein the workflow criteria comprises a financial institution whereby the workflow is dynamically altered based on the financial institution associated with a particular account.

27. The system as set forth in claim 23, wherein the workflow criteria comprises a champion challenger unit for modifying the workflow.

28. The system as set forth in claim 23, wherein at least one ofthe worksteps is an interactive workstep requiring action on the part of a user and the workflow criteria comprises an outcome of the action by the user, whereby the workflow is dynamically altered according to the particular outcome of the user's actions.