AU2021100923A4 - IMD-Managing Electronic Business: Intelligent System and Method for Dynamically Managing Electronic Business Process - Google Patents

Abstract

Our Invention "IMD- Managing Electronic Business" is an intelligent business process engine hosts the execution of electronic business model and operations and provides event objects to communicate the status of operations to a business rules engine, which hosts the execution of functions associated with those rules. The invented process also includes a dynamic process established in response to event objects and the rules in question allow you to control the aforementioned engine or external systems and provide business metrics, react to business metrics and adjust the parameters of these metrics and other functions associated with the required rules. The IMD- managing electronic business functions and metrics considered also make it possible to generate event objects and a commercial management engine hosts the application relating to the preparation of commercial activity reports reflecting the state of the system. The invented method and process also receives user input for manual operations for creating, defining, redefining the functions and metrics considered or the format of business activity reports and also the functions, metrics and reports are established or defined during the real-time operation of the electronic business management system without interrupting the flow of electronic business operations in the business process engine. 20 One data record FIELD NAME VALUE Narme Stewart Little Possible Values Address Cheesetown, NC 44455 Lead Telephone 111-222-3333 Suspect Sales status Suspect -- Prospect Hot Customer Business Process Form Builder Workflow Engine Access Control Reporting& Modeling Analytics FIG. 11is an example of a hypothetical prior art data model representing a sales cycle;

Description

One data record

FIELD NAME VALUE Narme Stewart Little Possible Values Address Cheesetown, NC 44455 Lead Telephone 111-222-3333 Suspect Sales status Suspect -- Prospect Hot Customer

Business Process Form Builder Workflow Engine Access Control Reporting& Modeling Analytics

FIG. 11is an example of a hypothetical prior art data model representing a sales cycle;

IMD-Managing Electronic Business: Intelligent System and Method for Dynamically Managing Electronic Business Process

FIELD OF THE INVENTION

Our Invention is related to a IMD-managing electronic business: intelligent system and method for dynamically managing electronic business process and also directed to computer software and systems. The invention are directed to customizable computer-implemented systems and software for dynamically creating, managing, and executing business processes such as sales and marketing and also relates to process management systems generally, and more particularly, to a system and method for dynamically managing electronic business processes.

BACKGROUND OF THE INVENTION

Effective management of electronic business processes requires a comprehensive on line platform capable of real-time dynamic control and reporting of system status. Prior art systems and methodologies, however, lack the ability to provide automated self management based upon a real-time coordination of business rules, business metrics, and system resources.

For example, prior art electronic business process management systems tend to implement business process flow control based on a rigid array of static rules. Although some prior art systems provide a user-interface for manually defining or editing rule parameters, no system or methodology exists for managing electronic business processes with rules that are dynamically triggered and adapted in an automated fashion based on the critical value of business-critical metrics such as business transaction volume, response time, turn-around time, event priority, etc.

Conventionally, existing systems tend to generate system status reports and await user analysis and response before reacting to changing environmental conditions such as resource usage or client demand. What is needed is a method and system possessing functionality to automatically administer necessary business process (i.e. , business process timing and attributes) during real- time system operation based on dynamically-generated event objects and system metrics. Another disadvantage of prior art electronic business control systems is their inability to adjust business rules 'on-the-fly" without interfering with business process flow. Such functionality, however, is critical in an on-line environment where clients continuously request system response and process performance.

Yet another drawback to prior art electronic business management systems is their failure to define business rule parameters and business metrics in a standard format such that they may be interchangeably used by rules for decisions, as well as updated by rules in response to internal or external events. Additionally, business metrics defined by prior art systems lack the ability to independently generate event objects for triggering subsequent system control.

Other disadvantages of prior art systems include their inability to execute business rules in response to events generated externally or in response to a correlation of event objects generated over time. Conventionally, rule-based control systems monitor local system status only at discrete instances of time and lack functionality to sense externally-generated events or correlate event sequences that occur at separate points in time.

What is needed is a method and system for dynamically managing electronic business processes that solves these and other problems associated with prior art electronic business management systems and methodologies. The invention pertains generally to digital data processing and, more particularly, to methods and apparatus for implementation of declarative rule-based systems, and their integration into mainstream computing environments. The invention has application, by way of non limiting example, in the design and implementation of workflow applications. Such systems typically have object-oriented architectures, and the invention takes advantage of aspects of such architectures, but it is not limited to these.

The vast majority of data processing systems use a procedural-based programming paradigm. This is exemplified by programming languages like C or Java, where execution is controlled by "procedures" consisting of sequences of statements (assignments, loops, if, etc.). The programmer of such a system is responsible for specifying, in great detail, what this sequence is, and making sure that it is correct. The sequential nature of such systems, and the resulting exponentially large number of execution paths that a system of even moderate size can take, is the fundamental basis for their complexity. It is also the source of most of the very large number of bugs that typically plague such systems.

Declarative rule-based programming is a fundamentally different programming paradigm. It is characterized by the lack of any sequential statements, and any notion of state of which the programmer has to be aware. Instead, processing is specified in the form of logical rules, where each rule relates one or more output variables to a set of input variables. Such rules can be "chained" together so that the output of one rule becomes an input to other rules.

An important characteristic of such a system is that the rules always hold. In other words, the values of the variables are always such that they are consistent with the rules. For example, if a rule states a relation between variables like z=x+y, then the values of x, y, and z are constrained to be such that this relation is never violated. This implies that changes to input variables (x or y in this example) must be propagated "instantly" so that the corresponding output variables are updated according to the relation. For example, if x=1, y=2, and z=3, and then x is changed to 2, then z must be updated to 4. In this case, "instantly" means that the update happens before any user, or any processing element outside the declarative programming system, notices an inconsistency.

The need for companies to manage complex business processes has never been greater. Since the widespread use of the Internet, intranets, and extranets, the need to streamline business processes and adapt them to the emerging web architecture has become more acute. Information glut and overload has become commonplace, and it is difficult for people to "keep up." Getting the right information to the right people at the right time (including employees, customers, and suppliers) and enabling them to act upon it in an appropriate manner is a huge and difficult undertaking.

Complex processes, the organized flow of work according to specific rules and interdependencies, are everywhere in business. They include the marketing cycle, which involves customer identification and profiling at the early stage and delivery of targeted marketing vehicles at specific time intervals during later stages. Another process with many interdependencies is the sales cycle, which typically includes multiple steps beginning with initial contact with the prospect all the way to consummating a sale. Project management, supply chain management, and customer service are a few of the other areas which involve complex chains of events that can be electronically represented, tracked and analyzed.

Managing business processes is one of the most important functions of a business. For example, sales leads are critical to revenue generation. Customer service inquiries are critical for maintaining customer satisfaction. Yet, by some estimates, 60% of leads and inquiries never get into the right person's hands (salesperson, distributor, reseller, support personnel, etc.), and this number will increase as the Internet becomes more important as a source of business. To compound the problem of lost or misdirected leads and inquiries, few companies track their business processes, including lead management, systematically as the steps in the business processes move from one party to another, to determine whether the appropriate action is taken and at what cost. As a result, companies are unable to perform return on investment (ROI) calculations on activities such as lead generation and management activities. Any product or process that can help companies manage its business processes more effectively, resulting in better sales, marketing, and customer service, will be welcome in the marketplace.

Traditional system design methods focus first on what information must be captured and stored in order to produce the needed output. The result is called the data model and much time and effort go into defining the variables (fields), their logical groupings (records) and their relative associations with other variables and groupings (relationships). The resulting definitions, referred to as a database schema, are the primary foundational architecture of any relational database application. Software products that host these data models or schemas are known as relational databases, including DB2, available from International Business Machines of White Plains, N.Y., ORACLE, available from Oracle Corporation, Redwood Shores, Calif., and MICROSOFT SQL, available from Microsoft Corporation of Redmund, Wash.

FIG. 1 is an example of a small subset of a hypothetical prior art data model representing a sales cycle. In this example, several variables or fields are logically grouped to define a contact record. For example, the field labeled "Sales status," represents the current status of the contact named "Stewart Little" within the sales cycle. For this example, assume the sales cycle consists of the following progression of possible choices: Lead, Suspect, Prospect, Hot, Customer. Each choice represents that status of a given contact. In FIG. 1, Stewart Little is currently at the second step (i.e., "Suspect"). As an organization markets to Stewart and his status changes, the value of the Sales status field changes from Suspect to Prospect, then to Hot, then to Customer. In this data model, the value of the field determines the status of Stewart's progression within the sales process. This data model approach can be referred to as field-based process modeling.

In field-based workflow models, fields grouped together are logically associated and form "ladder"-like structures, whereby each ladder contains a description of all candidates in relation to the value being defined. An example of such a Sales Status Value ladder for the data model of FIG. 1 is shown in FIG. 2. In the example of FIG. 1, the Sales Status Value ladder of FIG. 2 shows the status of values for all candidates (Lead, Suspect, Prospect, etc). Changes to any one individual's "rung" value are captured, but the audit trail of when it changed and what it changed from is not automatically monitored or easily captured. These events must be hard coded by the application developers. Tracking changes such as the addition or deletion of fields, moreover, can be difficult to program.

Obviously, the data model of FIG. 1 is but a tiny subset of what would need to be designed into a data model capable of thoroughly representing most sales processes. Additional fields typically would be added for each data element that a sales organization might want to track in relationship to the contact. For example, the sales organization might want to capture demographic data such as age, employment, and income information etc. Different campaigns or marketing processes could feed off of these variables.

Access to data models such as that shown in FIG. 1 historically have been facilitated via application languages like COBOL and Fortran (used in the 70's and 80's) Powerbuilder, FoxPro, Visual Basic, C++ (Popular in the 90s), and currently popular techniques such as Active Server Pages (ASP), Extensible Markup Language (XML), Hypertext Markup Language (HTML) and other web-based languages. Essentially, these application languages provide the developer with the toolkit for defining the way and manner in which the user interacts with the data model-the user interface.

PRIOR ART SEARCH

US7509518B22003-12-162009-03-24International Business Machines CorporationDetermining the impact of a component failure on one or more services

US7640222B22006-03-032009-12-29Pegasystems Inc.Rules base systems and methods with circumstance translation US7665063B12004-05-262010-02-16Pegasystems, Inc.Integration of declarative rule based processing with procedural programming US7676390B22003-09-042010-03-09General Electric CompanyTechniques for performing business analysis based on incomplete and/or stage-based data US7711919B22003-05-062010-05-04Pegasystems Inc.Methods and apparatus for digital data processing with mutable inheritance US7849396B22004-10-292010-12-07International Business Machines CorporationMethod and system for displaying prioritization of metric values US8880487B12011-02-182014-11-04Pegasystems Inc.Systems and methods for distributed rules processing US20080196005A1 *2007-02-092008-08-14Microsoft CorporationCompositional application programming interface and literal syntax US20080320452A1*2007-06-222008-12-25Thompson Gerald RSoftware diversity using context-free grammar transformations US20090132232A1*2006-03-302009-05-21Pegasystems Inc.Methods and apparatus for implementing multilingual software applications US20090300581A1 *2008-06-032009-12-03International Business Machines CorporationIdentifying structured data types as requiring designated initializers US20100107137A1*2004-05-262010-04-29Pegasystems Inc.Methods and apparatus for integration of declarative rule-based processing with procedural programming in a digital data-processing evironment US20100217867A1 *2009-02-252010-08-26International Business Machines CorporationSystem and method for creating and using service dependency graphs to automate the development and deployment of service oriented applications US20120102453A1*2010-10-212012-04-26Microsoft CorporationMulti-dimensional objects

OBJECTIVES OF THE INVENTION

1. The objective of the invention is to provide improved methods and apparatus for digital data processing and, more particularly, for integrating declarative and procedural programming systems. 2. The other objective of the invention is to provide such integrated computational systems that are relevant to a wide variety of applications, including, for example, modeling and processing workflows. 3. The other objective of the invention is to provide methods and apparatus for improved integration of declarative and procedural programming systems that are suited for integration with systems having object-oriented data architectures. 4. The other objective of the invention is to provide such methods and apparatus as can be implemented in a variety of programming languages and/or on a variety of platforms. 5. The other objective of the invention is to a intelligent business process engine hosts the execution of electronic business model and operations and provides event objects to communicate the status of operations to a business rules engine, which hosts the execution of functions associated with those rules. 6. The other objective of the invention is to dynamic process established in response to event objects and the rules in question allow you to control the aforementioned engine or external systems and provide business metrics, react to business metrics and adjust the parameters of these metrics and other functions associated with the required rules. 7. The other objective of the invention is to possible to generate event objects and a commercial management engine hosts the application relating to the preparation of commercial activity reports reflecting the state of the system. 8. The other objective of the invention is to method and process also receives user input for manual operations for creating, defining, redefining the functions and metrics considered or the format of business activity reports and also the functions, metrics and reports are established or defined during the real-time operation of the electronic business management system without interrupting the flow of electronic business operations in the business process engine.

SUMMARY OF THE INVENTION

The invention is to provide a system and method for dynamically managing electronic business processes. In carrying out this object and other objects, features and advantages, the present invention includes a business process engine for hosing the execution of a plurality of electronic business process instances. Each process instance, in turn, comprises a plurality of work steps. Before and after the execution of each work step, an event object is generated for communicating state attributes of the process instance or work step to a business rule engine. In an additional or alternate embodiment of the present invention, event objects may be generated by external systems and communicated to the business rule engine via an appropriate external system adapter. Preferably, a persistent storage device buffers event objects generated by the business process engine and external systems for subsequent transmission to the business rule engine.

The business rule engine hosts the execution of a plurality of business rule functions which are triggered dynamically in response to the event objects, separately or in correlation. Upon execution, business rule functions may exercise control over the business process engine or external systems (via appropriate system adapters), generate business metrics, react to business metrics and adjust parameters of business metrics and other rule functions. Notably, business metrics themselves may be configured to dynamically generate event objects in response to attaining a predefined attribute or parameter value.

A business management engine hosts the generation of business reports reflecting EBMS system status. Additionally, the business management engine receives user input manually creating, defining or re-defining business rule functions, metrics and business report format. Notably, business rule functions, metrics and business report can be created, defined or re-defined during the realtime operation of the EBMS without interrupting electronic business process flow within the business process engine.

In accord with a preferred embodiment of the present invention, the EBMS may be implemented over several computing platforms including stand-alone operating environments and networked environments such as intranets and extranets including the Internet. The above objects and other objects, features, and advantages of the present invention are readily apparent from the following detailed description of the best mode for carrying out the invention when taken in connection with the accompanying drawings.

The foregoing are among the objects attained by the invention which provides, in one aspect, methods for entering, maintaining, and executing declarative rules that allow the programmer to express invariant relations, as defined above. The methods further include facilities for entering, maintaining, and executing procedural statements that allow the programmer to specify sequential activity, as defined above. The methods further provide for integration of the declarative and procedural systems such that changes resulting from procedural actions are immediately propagated within the declarative system so that, for all practical purposes, the data is always consistent with the invariant relations specified by the declarative rules.

In one aspect, the invention provides a method for integrating a plurality of procedural instructions in a procedural computational system with a plurality of declarative rules in a declarative computational system. In such a method, for each of the procedural instructions operating on one or more variables, a hash table indexed by variable names is utilized to determine whether any of these variables participate in at least one of the declarative rules. Upon execution of a procedural instruction that changes a variable participating in a declarative rule, other variables associated with the rule are updated so as to maintain a relationship imposed by the rule among the variables. The updating of the other variables is performed prior to execution of other procedural instructions.

In a related aspect, in a method as described above, for each of the updated values, changes associated with the updated variable are propagated to other rules, if any, in which the updated variable participates. The propagation of the change can be accomplished by modifying values of variables other than the updated variable so as to maintain relationships defined by these other rules.

A related aspect of the invention provides methods for efficiently propagating the effects of the changes, according to relevant declarative rules, so that the data is once again consistent with the invariant relations. This propagation is done in a manner such that neither the procedural system, nor the user, is able to detect the temporary inconsistency.

A further aspect of the invention provides methods for distinguishing variables involved in declarative processing (variables that are mentioned in declarative rules) from ones that are not, and for efficiently associating variables involved in declarative processing with the rules in which they are mentioned. This helps minimize the overhead in the procedural system associated with detection and propagation, and thus maximizes efficiency. It also ensures that variables not involved in declarative processing impose no penalty on execution performance of the procedural system. For such variables, execution of the procedural system is no less efficient than it would be for a purely procedural system (one with no declarative rule capability). The overall effect of these methods is that propagation is limited to computation necessary to repair any rule violations.

Other aspects of the invention facilitate use of object-oriented data architectures in the declarative and procedural programming systems. These aspects include methods for efficiently assigning values to variables that are embedded within (represent attributes of) objects, and for matching such variables (which may be embedded many levels deep within a sub-object hierarchy) with relevant rules. These aspects also include methods that allow declarative rules to refer to objects in sophisticated ways, and that propagate effects of changes between objects.

In a related aspect, the invention provides a method of integrating a procedural computational system, which supports object-oriented representation of data in a plurality of objects, with a declarative computational system, which provides rules for defining relationships among the objects. One step of such a method determines, for each object, whether that object participates in any of the declarative rules. Upon execution of a procedural instruction operating on an object that participates in at least one declarative rule to modify data associated with the object, the data modification is propagated to other data in that object, and/or to data associated with other objects, so as to render data values associated with the declarative rule consistent with the rule definition.

In yet another aspect, the invention provides a method of integrating a procedural computational system, which supports execution of a plurality of procedural instructions operating on one or more variables, with a declarative computational system, which provides a plurality of rules for defining relationships among these variables. The method calls for compiling each procedural instruction corresponding to assignment of a value to a variable participating in a declarative rule so as to effect, upon assignment of a value to the variable at runtime, updating of other variables associated with the declarative rule so as to maintain consistency of a relationship imposed by the rule among the variables.

In other aspects, the invention provides an integrated procedural and declarative computational system that includes a procedural module for executing procedural instructions operating on one or more variables, and a declarative module that is coupled to the procedural module so as to operate on these variables so as to maintain a set of relationships among the variables defined by one or more declarative rules. The system further includes a tracking module that is in communication with the procedural and declarative modules. Upon execution of each of the procedural instructions, the change tracking module detects changes, if any, in one or more variables participating in at least one of the declarative rules and reports the change to the declarative module. In response, the declarative module updates values of other variables participating in the declarative rule so as to maintain a relationship defined by the rule.

Hence, an integrated computational system of the invention allows both declarative and procedural programming styles in a single system. The declarative system can operate in a background mode to ensure that the rules are always true without the need for a workflow architect to insert explicit update requests in the procedural code. Such a capability provides a programmer with unprecedented flexibility in utilizing these two different programming tools without having to be concerned about the details of their integration.

While both database software and the application languages used to access them have evolved considerably in recent years, the approach to building applications has not. The rigid need to define the data structure beforehand has not significantly evolved. Changing a data model after the programming has started is equivalent to redesigning the foundation of a house after the frame has been put up. Changing requirements, however, are a given in business today, and changes to requirements is a major factor in the software industry's dismal success rates on custom software projects. While some of this can be blamed on lack of design skill, it often is simply a function of needs changing from the time when the system was originally constructed. This time-span can be as long as many years or as short as several weeks. It would be advantageous to provide software applications that are parameter driven-that is, that the application can tolerate degrees of change in the requirements.

It is one object of the present invention to help solve these and other problems, especially the need for better management and optimization of business processes and technologies, by providing an easily adaptable architecture for building business process management applications. These applications can fit any number of vertical industries with quick modification, because in one aspect the present invention provides a list-based process model instead of a field-based process model. The list based process model has several advantages that give it more flexibility and adaptability than the traditional approach, which typically requires hard coding when significant changes are made. Thus, systems implemented in accordance with the present invention can perform lead management functions and measurements without extensive recoding, resulting in fast time-to-market, better ease of use, and less cost.

It is another object of the present invention to provide an architecture for building business process management applications, which architecture includes a list engine to maintain the modularity of its components and object classes, to build a customer relationship management (CRM) platform that supports rapid adaptation to ever changing requirements. In accordance with this aspect of the invention, the architecture includes an entity data model, a list-based processing model, and a flexible user interface that provide adaptability and portability to multiple vertical markets.

In one embodiment, the present invention provides a computerized system for modeling a business process, comprising a web server and a database server. The web server implements a user interface to the system. The database server is in operable communication with the web server and comprises a data architecture representing the business process. The data architecture comprises an entity model representing an entity responsible for implementing at least a portion of the business process, a transaction model comprising at least one step defining a business process, a list model representing at least one step in the transaction, the list model comprising a list of at least one entity associated with the transaction, and a task model associated with the list, the task model defining at least one task associated with the at least one step in the transaction.

BRIEF DESCRIPTION OF THE DIAGRAM

FIG. 1 is an example of a hypothetical prior art data model representing a sales cycle;

FIG. 2 is a Sales Status Value ladder for the data model of FIG. 1;

FIG. 3 is an illustration of a computer system in which the present invention can be embodied;

FIG. 4 is an illustration of a system implemented in accordance with one embodiment of the present invention together with the representative environment in which the system can be used;

FIG. 5 illustrates an overview of a representative data schema for the core engine architecture of FIG. 4;

FIG. 6 is a representative example of the entity schema for the entity of FIG. 5;

FIG. 7. is a representative example of the transaction schema for the transaction of FIG. ;

FIG. 8. is a representative example of the list entities schema for the list entities of FIG. ;

DESCRIPTION OF THE INVENTION

As used herein, the Internet refers at least to the worldwide collection of networks and gateways that use the transmission control protocol/Internet protocol (TCP/IP) suite of protocols to communicate with one another. The World Wide Web (WWW) at least refers to the total set of interlinked hypertext documents residing on hypertext transport protocol (HTTP) servers all around the world. As used herein, the WWW is also intended at least to refer to documents accessed on secure servers, such as HTTP servers (HTTPS), which provide for encryption and transmission through a secure port. WWW documents, referred to herein as web pages, can be written in hypertext markup language (HTML). As used herein, the term "web site" refers at least to one or more related HTML documents and associated files, scripts, and databases that is presented by an HTTP or HTTPS server on the WWW. The term "web browser" refers at least to software that lets a user view documents, such as HTML documents, and access files and software related to those documents.

In accordance with the descriptions of the invention provided herein, it should be understood that although the systems and methods of the present invention have been heretofore described in relation to sales, marketing, and task management, the invention is not intended to be limited to these types of application. Those skilled in the art will appreciate that the invention, for example, has applicability to virtually any type of system that uses databases or any situation where information is modeled, accessed, or used via a prior art model, such as a field-based model.

In one embodiment, the present invention comprises a computerized system implementing the systems and methods for dynamic management of business processes described herein. FIG. 3 is a simplified block diagram of a computer system 10 in which at least a portion of the system of the present invention can be embodied. The computer system 10 can be any type of general purpose computer system, such as a personal computer (PC), server, workstation, personal digital assistant (PDA), and the like, running any one of a variety of operating systems. In addition, software embodying the present invention may, in one embodiment, reside in an application running on the computer system 10. The present invention can also be embodied in a computer-readable program medium usable with a computer system such as the computer system 10.

Referring to FIG. 3, the computer system 10 typically includes a central processor 12, a main memory unit 14 for storing programs and/or data, an input/output controller 16, a network interface 18, a display device 20, one or more input devices 22, a fixed or hard disk drive unit 24, a floppy disk drive unit 26, a tape drive unit 28, and a data bus 30 coupling these components to allow communication therebetween.

The central processor 12 can be any type of microprocessor, such as a PENTIUM processor, made by Intel of Santa Clara, Calif. The display device 20 can be any type of display, such as a liquid crystal display (LCD), cathode ray tube display (CRT), light emitting diode (LED), and the like, capable of displaying, in whole or in part, the outputs generated in accordance with the systems and methods of the invention. The input device 22 can be any type of device capable of providing the inputs described herein, such as keyboards, numeric keypads, touch screens, pointing devices, switches, styluses, and light pens. The network interface 18 can be any type of a device, card, adapter, or connector that provides the computer system 10 with network access to a computer or other device, such as a printer. In one embodiment of the present invention, the network interface 18 enables the computer system 10 to connect to a computer network such as the Internet.

Those skilled in the art will appreciate that systems and methods embodying the present invention need not necessarily include every element shown in FIG. 1, and that equivalents to each of the elements are intended to be included within the spirit and scope of the invention. For example, not all computer systems 10 will include a tape drive 28, and some computer systems 10 might include other types of drives, such as compact disk read-only memory (CD-ROM) drives.

In one embodiment of the present invention, one or more computer programs define the operational capabilities of the computer system 10. These programs can be loaded into the computer system 10 in many ways, such as via the hard disk drive 24, the floppy disk drive 26, the tape drive 28, or the network interface 18. Alternatively, the programs can reside in a permanent memory portion (e.g., a read-only-memory (ROM)) chip) of the main memory 14. In another embodiment, the computer system 10 can include specially designed, dedicated, hard-wired electronic circuits that perform all functions described herein without the need for instructions from computer programs.

The computer system 10 can be part of a client-server system, in which a client sends requests to a server and a server responds to requests from a client. That is, the computer system 10 can be either a client system or a server system. The present invention typically is implemented at the server side and responds to requests made from a client.

The client can be broadly understood to mean any entity capable of transmitting requests to a server, such as the computer system 10, or specific components thereof (e.g., terminal, personal computer, mainframe computer, workstation, hand-held device, electronic book, personal digital assistant, peripheral, etc.), a software program running on a computer directly or indirectly connected or connectable in any known or later-developed manner to any type of computer network, such as the Internet. For example, a representative client is a personal computer that is x86-, PowerPC@, PENTIUM-based, or RISC-based, that includes an operating system such as IBM@ OS/2@ or MICROSOFT WINDOWS (made by Microsoft Corporation of Redmond, Wash.), and that includes a Web browser, such as MICROSOFT INTERNET EXPLORER, NETSCAPE NAVIGATOR (or higher) (made by Netscape Corporation, Mountain View, Calif.), having a Java Virtual Machine (JVM) and support for application plug-ins or helper applications. A client may also be a notebook computer, a handheld computing device (e.g., a PDA), an Internet appliance, a telephone, or any other type of data entry device or terminal, such as a multimedia kiosk, telecommunications device, or interactive television, capable of connecting to or transmitting information over a computer network.

The term "server" should also be broadly construed to mean an entity such as a computer, computer platform, an adjunct to a computer or platform, or any component thereof, such as a program, that can respond to requests from a client. Of course, a "client" can be broadly construed to mean one who requests or gets the file, and "server" can be broadly construed to be the entity that downloads the file. The server also may include a display supporting a graphical user interface (GUI) for management and administration, and an Application Programming Interface (API) that provides extensions to enable application developers to extend and/or customize the core functionality thereof through software programs including Common Gateway Interface (CGI) programs, plug-ins, servlets, active server pages, server side include (SSI) functions or the like.

The client and server can communicate using any system or transmission method capable of interconnecting two entities that are capable of communicating with each other, such as the Internet, an intranet, an extranet, or other computer networks. For example, networks can be land-based networks, wireless networks, and combinations thereof, including telephone lines, cable television lines, direct physical connections, and networks include networks that transmit information over the airwaves, such as cellular, satellite, microwave, packet radio, infrared line of sight, and spread spectrum technologies.

FIG. 4 is an illustration of a system 50 implemented in accordance with one embodiment of the present invention, together with a representative environment in which the system 50 can be used. The system 50 is implemented at a server that is part of a networked communications system communicating over the world wide web 52 ("web 52"). In FIG. 4, the representative environment is a business in which employees 54, managers 56, salespeople 58, vendors/suppliers 60, and participants in the world marketplace 62 all have networked communications access to each other via the web 52. The representative environment of FIG. 4 also can be implemented via other types of computer networks, including intranets and extranets. Users of the system 50 access the system 50 using a web browser such as MICROSOFT INTERNET EXPLORER and can communicate with it using Internet Protocol (IP).

The system 50 of this embodiment of the invention comprises a web server 64 and a database server 66. The web server 64 includes interacting components that drive the user interface (which is explained more fully herein) of the system 50, including an Application Service Provider (ASP)/XML layer 68, and an Application Program Interface (API) layer 70. The ASP/XML layer 68 provides a user interface by which appropriate personnel, such as management 56, can modify the table structure in the database server 66. Using the ASP model, the system 50 hosts the application or platform that clients access. A provider of this application/platform can, for example, lease or rent the application to users for given periods of time, e.g., monthly. This implementation is particularly advantageous for small to medium size companies that do not have an information technology (IT) staff or infrastructure to maintain this functionality internally. In addition, the ASP/XML layer 68 can be configured to have the same "look and feel" as a given legacy database system with which a user of the system 50 is familiar.

It should be understood that, although the embodiment of FIG. 4 illustrates the system 50 as having a single web server 64 and a single database server 66, this embodiment of the present invention is scaleable. For example, depending on the needs of the clients accessing the system 50, the system 50 may be accomplished by distributing the functionality of the web server 64 over several different web servers 64 (not shown), such as "mirror" servers. Similarly, although each client accessing the system 50 typically is associated with its own database, the database functionality may be implemented using more than one database server 66.

The database server 66 includes a database manager 67, such as the MICROSOFT SQL (structured query language) RDMS (relational database management system) configured on a MICROSOFT WINDOWS NT Server, individual user specifications 72, company specific system parameters 74, vertical market system parameters 76, and a core engine architecture 78. The system 50 can store individual user specifications 72 for each user of the system 50 and company specific system parameters 74, to accommodate the different types of parameters and types of data that different businesses may need to manage. In one embodiment, the database server 66 provides a unique database for each client accessing the system 50 (clients also are referred to as users). The system 50 also includes vertical market system parameters 76 and a core engine architecture 78. In one embodiment, the vertical market system parameters 76 comprises a set of vertical market templates that operate on top of the core engine architecture 78. The templates include "standard" types of business workflows that can be customized to match each customer's specific workflow and process requirements. Thus, the operation of the system 50 can be designed to have the same "look and feel" that a user is accustomed to in a legacy system, which can significantly reduce the learning curve.

Using such vertical market templates has other advantages, as well. For example, a company using the system 50 can create industry-specific value chain intranets serving different users all working in an environment customized to their workflow and marketing process. If a company is acting as a host application service provider (ASP), it need only support one software application, which can greatly increase the company's leverage. As explained below in connection with the task management aspect of the invention, use of the list-based model of the present invention enables the platform to support virtual workflow exchange between any/all users.

The core engine architecture 78 further includes a data schema, and FIG. 5 illustrates an overview of a representative data schema 80 for the core engine architecture 78 of FIG. 4. The data schema 80 for the core engine architecture 78 includes SQL objects, which can be related, representing data tables for Entities 82, Transactions 84, Activities 86, Tasks 88, and Lists 90 (each of these is explained more fully herein). Each SQL object is associated with a primary key 92 (shown in FIG. 5 by the notation "PK"), which the database server 66 can use to help organize the order and/or manner in which it stores information. In the representative data schema of FIG. 5, for example, the primary key 92 for the data table for Entities 82 refers to the identifier termed "Entity ID" as a primary key by which the database server 66 associates information associated with the particular entity.

An Entity 82 refers to any stakeholder in or associated with an organization that uses the system 50. Entities 82 can be organizations, people, or locations and can have inheritance, like other objects. FIG. 6 is a representative example of the Entity Schema 94 (also referred to as an Entity data model) for the Entity 82 of FIG. 5. In this example, the SQL object representing the table of Entities 82 is associated with a core record of information, which in this example includes SQL objects representing a table of Customer Information 96 (e.g., customer name and address) and a table of Phone Numbers 98. It should, of course, be understood that the example of information provided in the example of a core record is merely representative of the type of information that can be stored and is not intended to be limiting.

The SQL object representing the data table for the Entity 82 is further associated with other SQL objects representing data and lookup tables associated with the Entity 82, as shown in FIG. 6. For example, the Entity 82 is associated with an SQL object representing a lookup table for Entity Types 100, a table of Entity Sub Types 102, a lookup table of Entity Sub Types 104, a table of Entity Relationships 106, and a lookup table of Entity Relationship Types 108.

The types of Entities 82 listed in the lookup table of Entity Types typically will correspond to the particular type of client using the system 50, and the available Entity Types can be a function of the company specific system parameters 74 and/or the vertical market system parameters 76 (FIG. 4). For example, for an online business to consumer (B-C) site selling books directly to consumers over the Internet, the Entity Types might include types such as sales, publisher, shipper, customer service, and customer, and each of these Entities 82 could have associated with it a core record of information, as described above.

A "stakeholder" or other user of the system 50 can fit the definition of more than one Entity Type 100, depending on the point of reference or situation. In the above B-C example, a publisher associated with the online B-C site may also, at certain times, be a customer of the online B-C site. Thus, this particular Entity may be associated both with an Entity Type 100 of "publisher," and an Entity Sub Type 102 of "customer." Thus, the data schema 94 for an Entity 82 can recognize that a given client of the system 50 (in this example, a given Entity 82, such as the publisher) can be classified in more than one way depending on the context or frame of reference. This characteristic of an Entity 82 is particularly useful for the list-based models of the invention, as will be shown below.

The Entity Relationships 106 and Entity Relationship Types 108 also can be associated with the Entity 82 and refer to relationships that a given Entity 82 may have with other Entities 82. For example, a first entity may be a given organization, and a second entity may be related to the first entity in that the second entity is a contact at the given organization. Thus, the first entity can be considered to be a "parent" entity and the second entity can be considered to be a "child" entity, having an Entity Relationship Type 108 called "organization-contact". Note that the first entity may have other "child" entities with which it has the Entity Relationship Type called "organization-contact". In addition, the first entity and the second entity could be related in different ways in different contexts; thus, they may be classified under more than one Entity Relationship 106.

Thus, the Entity data model 94 of FIG. 6 supports "many to many" relationships and defines Entities 82 by their relationships to other Entities 82 and to the organization. If it is necessary to modify information associated with an Entity 82 because of changes in its role in, relationship to, and/or responsibility for an organization or business process, it is not necessary to create an entirely new Entity data model 94. Rather, because the Entity data model 94 is organized around relationships, the additional roles and/or responsibilities of an Entity 82 can be described by adding to or deleting from the Entity data model 94 the requisite Entity Relationships 106, Entity Types 100, Entity Sub Types, 102, etc. Note that the Entity data model 94 will not require new SQL objects to handle such changes; rather, the existing data structure of the Entity data model 94 (i.e., the tables represented by SQL objects) has the flexibility to handle the changes.

FIG. 7. is a representative example of the Transaction Schema 112 (also referred to as an Transaction data model) for the Transaction 84 of FIG. 5. Transactions 84 are the primary "high level" events or business transactions that take place between and among Entities in a given business model. In many businesses, such high-level events/business transactions are definable by a business process, and in many industries the business process is industry specific. For example, if a business using the system 50 was a realtor, an example of a Transaction 84 associated with that business is the selling of a home, which is associated with an entity such as a real estate agent. The realtor may have its own "best practice" business practice associated with accomplishing the transaction of "selling a home," which might include steps such as: Sign listing agreement with homeowner, Generate real estate listing, Submit listing to multiple-listing service, Hold open house, etc., and at each of these steps the entity (real estate agent) may have further sub-responsibilities or Tasks (see below). In contrast, businesses such as insurance agencies, manufacturers, retailers, etc., may have their own set of Transactions 84, each definable by a business-specific, but possibly customized, business process.

Referring again to FIG. 7, each Transaction 84 is associated with at least one Entity 82. The Transaction Schema 112 also associates with a Transaction 84 an SQL object representing a data table of Transaction Details 112, which at includes high level information about the transaction. The association between the Transaction 84 and the Entity 82 is referred to as an Entity/Transaction Pair, and as a Transaction 84 moves through its various steps, the status of the Entity 82 at each step can be known and managed, and if other Entities 82 are involved in the same transaction, it is possible to track and manage their role in the Transaction 84. This is advantageous for businesses such as realtors, where multiple agents each typically handle multiple home sales, sometimes with more than one agent associated with the same home sale.

Referring again to FIG. 5, Tasks 88 are another type of data structure associated with one embodiment of the system 50. Tasks 88 are individual action items that originate from being self-assigned, delegated, or system generated. Typically, Tasks 88 are associated with Entities 82 and Transactions 84. Tasks 88 define and/or enumerate the actions to go between states in a given business process. For example, using the above example Transaction of a home sale, the step of "Holding an open house" might involve its own set of Tasks 88, some of which may be the direct responsibility of the Entity 82 associated with the Transaction 84, such as Hosting the Open House. Another Entity 82, such as the real estate agent's secretary at the Realtor, who is also an Entity 82, may have one or more delegated tasks, such as Placing a newspaper advertisement. Tasks 88 also can be sub-delegated; for example, the real estate agent's secretary may sub-delegate the task of Placing a newspaper advertisement, which was delegated to her, to a receptionist (who also is an Entity 82). Tasks 88 also are associated with another aspect of the present invention, called Task Management, which is described more fully below.

As noted above, a Transaction 84 associated with a given business can be defined using one or more business processes, each consisting of a series of steps or "states" of the process. Tasks are types of actions associated with the steps of states. Lists, explained below, help to define each step or state in the business process. Lists also can be used to organize and segment information such as market, demographic, and/or business specific parameters.

In accordance with the present invention, a business process can be thought of as referring to a set of states that move an Entity or an Entity/Transaction Pair along some sequence of events. Typically, the lists of the present invention can be used to "automate" a given business process. For example, a Generic Customer Process might include the following sequence of events: Marketing and Sales, Product/service development and introduction, Manufacturing, Distribution, Billing, Order Processing, Customer service, and Warranty administration. In one embodiment, the present invention also can provide for industry-specific customer processes, such as Loan processing (banking), Claim adjudication (insurance), Grant allocation (government), Merchandise return (retail), Food preparation (restaurant), Baggage handling (airline), Operator services (telecommunications), User-manual writing (computer), Reservation handling (hotel), and the like.

FIG. 8. is a representative example of the List Entities Schema 114 (also referred to as a List data model) for the List Entities 90 of FIG. 5. List Entities 90 are associated with an SQL object representing a lookup table of Lists 116. In accordance with the present invention, Lists 116 are a way to represent any state or set of information that can be attained by or associated with any Entity 82, and provide a way to group and track Entities 82 and Entity/Transaction pairs. For example, a List 116 could represent all of the customer entities in a particular marketing campaign, the status of a customer in a sales cycle, or the stage of a new employee in a training program. Lists 116 can be grouped into List Categories 118, such as Customer Status and Marketing Campaigns.

In contrast to the field-based methodology illustrated in FIGS. 1 and 2, the Lists 116 of the invention (and the associated list-based data storage) effectively equates to making field values their own "world" where business rules can easily be applied, changes automatically tracked, and actions based on those changes triggered-immediately or on a delayed basis.

Claims (5)

WE CLAIM

1. Our Invention "IMD- Managing Electronic Business" is an intelligent business process engine hosts the execution of electronic business model and operations and provides event objects to communicate the status of operations to a business rules engine, which hosts the execution of functions associated with those rules. The invented process also includes a dynamic process established in response to event objects and the rules in question allow you to control the aforementioned engine or external systems and provide business metrics, react to business metrics and adjust the parameters of these metrics and other functions associated with the required rules. The IMD- managing electronic business functions and metrics considered also make it possible to generate event objects and a commercial management engine hosts the application relating to the preparation of commercial activity reports reflecting the state of the system. The invented method and process also receives user input for manual operations for creating, defining, redefining the functions and metrics considered or the format of business activity reports and also the functions, metrics and reports are established or defined during the real-time operation of the electronic business management system without interrupting the flow of electronic business operations in the business process engine.

2. According to claims# the invention is to a intelligent business process engine hosts the execution of electronic business model and operations and provides event objects to communicate the status of operations to a business rules engine, which hosts the execution of functions associated with those rules.

3. According to claim,2# the invention is to a dynamic process established in response to event objects and the rules in question allow you to control the aforementioned engine or external systems and provide business metrics, react to business metrics and adjust the parameters of these metrics and other functions associated with the required rules.

4. According to claim,2,3# the invention it possible to generate event objects and a commercial management engine hosts the application relating to the preparation of commercial activity reports reflecting the state of the system.

5. According to claiml,2,3,4# the invention is to method and process also receives user input for manual operations for creating, defining, redefining the functions and metrics considered or the format of business activity reports and also the functions, metrics and reports are established or defined during the real-time operation of the electronic business management system without interrupting the flow of electronic business operations in the business process engine.

FIG. 1 is an example of a hypothetical prior art data model representing a sales cycle;

FIG. 2 is a Sales Status Value ladder for the data model of FIG. 1;

FIG. 3 is an illustration of a computer system in which the present invention can be embodied;

FIG. 4 is an illustration of a system implemented in accordance with one embodiment of the present invention together with the representative environment in which the system can be used;

FIG. 5 illustrates an overview of a representative data schema for the core engine architecture of FIG. 4;

FIG. 6 is a representative example of the entity schema for the entity of FIG. 5;

FIG. 7. is a representative example of the transaction schema for the transaction of FIG. 5; 2021100923

FIG. 8. is a representative example of the list entities schema for the list entities of FIG. 5;