WO2001069485A1

WO2001069485A1 - Method and system for conducting interactive business processes and communications

Info

Publication number: WO2001069485A1
Application number: PCT/US2001/004770
Authority: WO
Inventors: Yan Zhang; James J. Sun; Julia Zhang; Kejia Sun; Bao Qi-Bin; Weiguang Shao
Original assignee: Fulton International Corporation
Priority date: 2000-03-14
Filing date: 2001-02-14
Publication date: 2001-09-20
Also published as: WO2001069485A9; AU2001238272A1

Abstract

A method for setting up an interactive business process for a plurality of users, see figure 2. The method comprises accepting definition instructions from a user, (connection to Users via Internet) and accepting data fields to contain information for the business process, (16) wherein the act of accepting definition instructions allows the user to create a user-definable business process, and wherein the accessability of certain information is a function of time and system user authority.

Description

Title: METHOD AND SYSTEM FOR CONDUCTING INTERACTIVE BUSINESS PROCESSES AND COMMUNICATIONS

FIELD

This invention relates to methods and systems for conducting business processes and communications. The methods and systems are implemented in computer hardware and software.

BACKGROUND

The development of Internet has allowed users to access different information through World Wide Web ("WWW") sites located anywhere in the world as long as the user has a computer and modem connection or some other communication facilitating device, and it has facilitated business-to-customer e-Commerce allowing businesses to sell their products to consumers through the Internet. In recent years, companies have begun conducting business- to-business e-Commerce by leveraging the Internet to gain a closer alignment with customers and partners, to integrate supply chains, and to take advantage of new revenue opportunities. Much of the business-to-business e-Commerce has been focused on large companies by providing them with special application software which allows their business customers to automate procurement processes. Because of the expense of the special application software, which is often designed for certain specific applications, this procedure for business-to- business e-Commerce has not been widely used.

Ariba Corporation has developed several application software packages for business- to-business e-Commerce. Its ORMS application software package and ORMX application software package enable business buyers to get the goods and services they need and provide content access, routing and approvals, and ERP integration. Its Network platform also integrates buyers using Ariba buyer-enablement applications with the global electronic economy and provides a range of Internet services for buying and selling organizations. The Ariba software applications are, however, designed for certain specific applications and lack the flexibility to be used for any business process.

Another business-to-business e-Commerce package, the Commerce Chain Solution provided by Commerce One, has also been limited to facilitating buying and selling processes

by automating the indirect goods and services supply chain for buyers and suppliers. The

Commerce Chain Solution consists of two major components, a Commerce One BuySite and a Commerce One MarketSite, both of which have a specific application and lack the versatility that is needed in today's business world to perform varied processes.

Lotus Notes is another software package that may be used for some specific business processes. Lotus Notes, in general, focuses on enterprise wide, intranet-based systems for office-oriented tasks, and it does not, in general, focus on business-to-business Internet-based

business processes.

Other business-to-business application solutions are also for specific and narrow applications. U.S. Patent No. 5,995,947, issued to Fraser et al., describes an interactive

mortgage and loan information and real time trading system. U.S. Patent No. 5,978,768,

issued to McGover et al., describes a method for allowing companies to advertise job openings on the Internet and job seekers to respond and send resumes through the Internet. U.S. Patent No. 4,799,156, issued to Shavit et al., discloses an interactive market management system for interactive on-line electronic communications and processing of

business transactions between multiple users. Although this system has an access means and

a processing means which allow one user, e.g., a buyer, to chose one business partner for a specific business process from multiple users, e.g., sellers, it lacks the capability of involving multiple business partners in multi-step business processes, which is common in today's business world.

In spite of the emergence of the Internet and software developments to date, most business is still conducted using traditional methods, such as telephone, facsimile, and paper documents. One reason for this is that most of the existing business-to-business e-Commerce solutions only allow a limited number of business partners, such as two or three, to exchange business information during a business transaction, and most of these e-Commerce solutions are for specific applications. A need exists for an application that is capable of integrating multiple business users into a business process and that is not limited to a specific application, such as facilitating buying and selling processes.

SUMMARY

In one embodiment, the invention is a method for setting up an interactive business process for a plurality of users. In this embodiment, the method comprises accepting definition instructions from a user to set up the business process, including accepting rules, accepting roles to be taken by system users, and accepting data fields to contain information for the business process, wherein the act of accepting definition instructions allows the user to create a user-definable business process, and wherein the accessability of certain information within the data fields is a function of time and system user authority.

Another embodiment of the invention is a method for defining an interactive business process. In this embodiment, the method comprises accepting natural business process language that sets forth the functions of a business process between a plurality of users, and translating the natural business process language into coded language by interactively accepting definition instructions from a user to set up the business process, including accepting rules, accepting roles to be taken by system users, and accepting data fields to contain information for the business process, wherein the act of accepting definition instructions allows the user to create a user-definable business process, and wherein the accessability of certain information within the data fields is a function of time and system user authority.

Another embodiment of the invention is a method for defining a business process. In this embodiment, the method comprises setting up a data pool for selective access by a plurality of users, defining data fields within the data pool such that certain users have access to particular data fields at certain times during operation of the business process, and defining states and state transitions for the business process, the states and state transitions allowing for selective distribution at pre-defined times of information in the data fields relating to the business process.

Another embodiment of the invention is an apparatus for defining an interactive business process for a plurality of users. In this embodiment, the apparatus comprises a processor in communication with a memory device, the processor operative with a program on the memory device to: accept definition instructions from a user to set up the business process, including accepting rules, accepting roles to be taken by system users, and accepting data fields to contain information for the business process, wherein the definition instructions allow the user to create a user-definable business process, and wherein the accessability of certain information within the data fields is a function of time and system user authority.

Yet another embodiment of the invention is a method for performing a business process. In this embodiment, the method comprises providing accessibility to system users via a network interface to a central system containing user-defined instructions for the business process, pooling business process-related data from one or more system users in the central system, and selectively providing availability to system users to information from the pooled data, wherein the act of selectively providing availability involves determining which information is available to each system user as the business process transitions from one process state to another process state.

Another embodiment of the invention is a system for performing a business process. In this embodiment, the system comprises a computer readable program code having instructions for: providing accessibility to system users via a network interface to a central system containing user-defined instructions for the business process, pooling business process-related data from one or more system users in the central system, and selectively providing availability to system users to information from the pooled data, wherein the act of selectively providing availability involves determining which information is available to each system user as the business process transitions from one process state to another process state.

Another embodiment of the invention is a system for defining a user-definable business process. In this embodiment, the system comprises a computer program having instructions for: interactively soliciting and receiving from a user instructions to define a document representing the user-definable business process, the document setting forth data fields, states, roles, state transitions, and rules that set forth the operation of the user-definable

business process.

Yet another embodiment of the invention is a method for automating communications between business users involved in a business process. In this embodiment, the method comprises pooling business process-related data from one or more business partners, and selectively providing access to one or more user of the pooled data, wherein the act of providing access further comprises selecting the data within the pooled data that may be accessed by each user. Yet another embodiment of the invention is an apparatus for automating communication between business users involved in a business process. In this embodiment, the invention comprises a computer system having memory for storing data related to a business process and for storing communications between users in an electronic format, wherein the computer system is adapted to be accessed via the internet and wherein the system facilitates communication between users, computer instructions operable by a processor in the computer system, wherein the computer instructions enable at least one user to define a business process via the internet, pool business process related data based on the user defined process, and distribute to each user selected information from the pooled data.

Another embodiment of the invention is an apparatus for automating communication between business partners/users involved in a business process. In this embodiment, the apparatus comprises a computer system having memory for storing data related to a business process and for storing communications between users in an electronic format, wherein the computer system is adapted to be accessed via the internet and wherein the system facilitates communication between users, and computer instructions operable by a processor in the computer system, wherein the computer instructions enable at least one user to define a business process via the internet, pool business process related data based on the user defined process, and provide access to users to selected information from the pooled data.

Yet another embodiment of the invention is a method for conducting interactive business processes that require electronic data exchange among a plurality of system users. In this embodiment, the method comprises interactively defining processes, rules and roles to be taken by the system users, interactively defining a document having data fields and owners of the data fields such that the document may be accessed by various system users during operation of the business process, distributing information in the data fields to authorized system users, wherein the information is filtered prior to distribution, tracking business processing and information as the business process is carried out, and updating process status and information as the business process is carried out.

Another embodiment of the invention is a method for evaluating a school admission application. In this embodiment, the method comprises electronically receiving the school admission application from a prospective student, providing accessibility to application reviewers via a network interface to a central system containing user-defined instructions for application evaluation, and selectively providing availability to application reviewers to information from the school admission application, wherein the act of selectively providing availability involves determining which information is available to each application reviewer as the application evaluation transitions from one process state to another process state.

Another embodiment of the invention is a method for processing a purchase order. In this embodiment, the method comprises electronically receiving a purchase order from a buyer, providing accessibility to system users via a network interface to a central system containing user-defined instructions for processing the purchase order, providing the purchase order to a dealer, and allowing the dealer to submit a product order to a manufacturer; providing a shipping request for the purchase order to a trucker, and selectively providing availability to the buyer, dealer, manufacturer, and trucker to information in the central system, wherein the act of selectively providing availability involves determining which information is available to each system user at varying times.

Yet another embodiment of the invention is a method for delivering a product. In this embodiment, the method comprises electronically receiving a request for product delivery from a merchant, providing accessibility to system users via a network interface to a central system containing user-defined instructions for processing the product delivery, providing product delivery information to a trucker, wherein the trucker is capable of delivering the product to a consignee, and selectively providing availability to the merchant, consignee, and

trucker to information in the central system, wherein the act of selectively providing availability involves determining which information is available to each system user at varying times.

DESCRIPTION OF THE DRAWINGS

Figure 1 is a block diagram overview of the components of one embodiment of the invention.

Figure 2 is a basic block diagram overview of the central system of one embodiment of the invention.

Figure 3 is a block diagram overview of one embodiment of the interaction between

the users of the system.

Figure 4 is a block diagram overview of a process of one embodiment of the

invention.

Figure 5 is a block diagram overview of a process of one embodiment of the

invention.

Figure 5a is an exemplary representation of a process set up using a graphic user

interface of the invention.

Figure 5b is a list of possible state transitions that may be used within the scope of the

invention.

Figure 5c is a drawing of a state transition from a single source state to multiple

destination states. Figure 5d is a drawing of a state transition from multiple source states to a single destination state.

Figure 5e is an exemplary representation of a state transition in a trucking example of one embodiment of the invention.

Figure 5f is an exemplary representation of a state transition in another embodiment of the invention.

Figure 6 is a representative example of a defined process of one embodiment of the invention for the trucking industry.

Figure 7 is a representative example of a defined process of one embodiment of the invention for the trucking industry.

Figure 8 is a web page or database entry page that may be used in one embodiment of the invention for setting roles.

Figure 9 is a web page or database entry page that may be used in one embodiment of the invention for defining states.

Figure 10 is a web page or database entry page that may be used in one embodiment

of the invention for defining state transitions.

Figure 11 is a web page or database entry page that may be used in one embodiment of the invention for defining document fields.

Figure 12 is a web page or database entry page that may be used in one embodiment of the invention for authorizing users to manipulate information in data fields.

Figure 13 is a web page or database entry page that may be used in one embodiment of the invention for setting roles for a process.

Figure 14 is a web page or database entry page that may be used in one embodiment of the invention to assign roles to business users. Figure 15 is a block diagram overview of the definition of a process in one embodiment of the invention.

Figure 16 is a block diagram overview of a representative example of an embodiment of the invention for graduate school admission.

Figure 16a is a block diagram overview of the states and state transitions in one embodiment of a graduate school admission process.

Figure 17 is a representative example of a defined process of an embodiment of the invention for graduate school admission.

Figure 18 is a representative example of a defined process of an embodiment of the invention for graduate school admission.

Figure 19 is a block diagram of a representative example of an embodiment of the invention for a buying process.

Figure 20 is a block diagram of a representative example of an embodiment of the invention for a buying process.

Figure 21 is a web page or database entry page that may be used in one embodiment

for logging on to the system.

Figure 22 is a web page or database entry page that may be used in one embodiment for viewing particular transactions during operation of processes that have been set up using

an embodiment of the invention.

Figure 23 is a web page or database entry page that may be used in one embodiment for starting a new transaction for a defined process.

Figure 24 is a web page or database entry page that may be used in one embodiment for entering information to begin a process. Figure 25 is a web page or database entry page that may be used in one embodiment for viewing pending transactions for which the current user may act.

Figure 26 is a web page or database entry page that may be used in one embodiment by the current user to process a transaction.

Figure 27 is a web page or database entry page that may be used in one embodiment for listing transactions in which the current user has already acted.

Figure 28 is a web page or database entry page that may be used in one embodiment by the current user to change information in a transaction that the current user has already processed.

Figure 29 is a block diagram that shows the interaction between users of the process and that document of the process at different states during operation of the process.

DETAILED DESCRIPTION a. General Overview and Equipment of an Embodiment of the Invention

The present invention provides a method and system for conducting interactive business-to-consumer, consumer-to-business, business-to-business, and/or person-to-person business processing and communications. Such processes may include, but are not limited to: the transportation industry, such as airline ticket reservations, shipping, forwarding, trucking, or delivery; the financial industry, such as on-line banking, lending and borrowing, security exchange, mortgages, or accounting; the education industry, such as school admission, grant applications, project management and monitoring, on-line conferencing, home work assignments for school, or on-line examinations; the procurement industry, such as bidding, buying, selling, or auctioning of goods; retail and service industries, such as on-line shopping, reservations and confirmation for car rentals, hotels, or restaurants; the medical, pharmaceutical and health care industries, such as clinic visit scheduling or on-line medical expert consulting; the insurance industry, such as application and approval for insurance; and

the advertising industry. The present invention may be applied to any business process in any industry that requires communication and information exchange.

In one embodiment, the invention may be used to define the processes, rules, and roles of system users of a business process, and the invention may be used to provide for selective distribution of the content of the information to system users. In addition, the timing of the business process may be used to determine the selective distribution of the content of the

information. The invention, therefore, may provide for a user-definable business process that may be used for a variety of applications. Because the process is user-definable within the scope of the invention, the invention may be malleable to a wide variety of business situations, and the capability of the invention for conducting business processes is bounded

only by the creativity of the user(s) who define the business process.

Figure 29 is a block diagram that illustrates the operation of a process set up using an

embodiment of the invention. A plurality of users 12 may communicate over a

communication network 14, such as the Internet, with a central system 10 that may have a defined database structure in accordance with the invention. The database may have a

number of database fields 17, each of which may be distributed and/or accessed by different

system users 12 at different times during operation of the process. The process operation is depicted on the left-hand side of Figure 29, in which a number of process states 1, 2, . . . N,

flow from a start 11 of the process to the finish 15 of the process. The state of the process may determine the user 12 who has access to certain data fields 17 in the central system 10,

and hence the state of the process may, in part, determine the timing of information distribution to certain users 12. The data fields 17 may also be set up so that certain users 12 have permission to see and/or manipulate data in certain data fields 17 and certain other users 12 do not have access to data in those data fields 17. The system, therefore, may be user- definable to permit for the selective distribution of information and to time the distribution of information.

In another embodiment, the invention may be a computer program or set of instructions that allow a given user to set up a business process. The program may accept definition instructions from a user to set up the business process, including accepting rules and roles to be taken by system users and data fields to contain information for the business process. The program may therefore allow the user to create a user-definable business process, and accessability of certain information within the data fields may be determined as a function of time and the authority given a system user. To complete the setting up of a business process, the program of the invention may allow the user to assign the roles of the business process to specific system users.

An overview of the system of an embodiment of the invention is illustrated in Figure 1. The system of Figure 1 may have three functioning components: a central computerized system 10, a group of one or more users 12, and a communication network 14, which may be an Internet connection between the central system 10 and the users 12. In other embodiments, the communication network 14 may be a Local Area Network ("LAN") of any type, a Wide Area Network ("WAN"), a private network, or a public telephone network using an interactive voice response system ("IVR"). Communications may be accomplished using standard devices or wireless devices such as cellular phones, palm pilots, satellite dishes, cable, or other electronic communication devices or mediums known to those skilled in the art. The central system 10 provides a platform for carrying out the functions of an embodiment of the invention, and the central system 10 performs business processing and communication and has a storage device or devices for storing the business transaction information and communications in an electronic format.

In one embodiment of the invention, the users 12 involved in a business process can, via the central system 10 and the communication network 14, communicate, interact and carry out the business process, eventually finishing the business process using the communication network 14. The present invention may apply to industries, organizations, and/or businesses that require remote information exchange and communication in order to complete processes. In one embodiment, all of the communications among the users 12 are carried out over the communication network 14, and all of the information involved in the business process, such as the process content, process status, and process activities, can be viewed and retrieved via the communication network by all authorized users 12 simultaneously. In one embodiment, central system's 10 databases may update themselves after an action by any user 12, such that other users 12 may view current information on the central system 10 regarding the business process.

The method and system of one embodiment of the invention simplify business processes and communications into automated computerized operations. Such operations may be set up by interactive on-line defining of business processes and interactively on-line changing and/or re-defining of business processes. The system and method, therefore, may selectively on-line distribute information to authorized users, dynamically on-line screen, filter, and select information prior to authorized distribution to users, dynamically on-line track processes and process related information, dynamically on-line search information related to business processing, dynamically on-line send, re-send, or escalate alarm signals to authorized users, and automatically and instantly update process status and information. The system may also make use of commonly used computerized operations such as user identification, security verification, acknowledging, accepting, forwarding, and rejecting of information, and information searching.

The system and method of the invention may provide a computerized system to handle the core functions described above. The system may be modularly designed, scalable, and may have no limitation on the number of users or the complexity of the process. That is, the system may be scaled up to handle numerous business processes simultaneously covering different industries, and the system may also be scaled down to conduct only limited business processes related to one or a few companies. In one embodiment, all of the information of the process may be stored in the central system 10 and may be accessed with authorization anywhere in the world via Internet or other communication devices. The system may, in one embodiment, be a pure Internet solution, where no special software or hardware is required for users to access the system.

After a process has been defined, the central system 10 may automatically, and via the Internet or a communication network 14, connect all of the parties involved in the business process and execute the business process following the defined process rules. These business processes may be any kind of business process that requires communication and information exchange, such as electronic exchange of data, documents, images, video and audio signals. In one embodiment, the communications and interactions, such as moving the business process from one state to another and among the business partners/users involved in the business process, may be conducted via the central system 10. The database for the process may be instantly updated by the central system 10 after action by users involved in the process. In one embodiment, an electronic data exchange action may be used to view and retrieve information via Internet by all authorized users simultaneously, provided each user has authorization to view and retrieve such information. Business losses due to miscomrnunication, therefore, may be eliminated or minimized.

In one embodiment, the system of the invention may also interface with a user's internal network system, such as an Intranet or a local area network, and perform internal management of the user's business.

1. The Users of the System

No special hardware or software is required at the user's end for operation of the invention. In one embodiment, each user of the system and method of the invention may use a computer to interact with the central computer system 10 of the invention. The computer used by each user in this embodiment may be any type of computer capable of communicating over the communication network 14 with the central computer system 10.

Each user 12 of the system may be identified through its own unique user name. To get connected with the central system 10, each user 12 may register with the central system 10 and obtain a user name and a password. In one embodiment, therefore, the central system 10 may be set up to require each user 12 of the central system 10 to enter a user name and password for access to the central system 10, and the user name and the password may have to be verified each time by the central system 10 when the user 12 logs onto the central system 10. User accounts may, in one embodiment, be set up via online registration or by

other procedures such as by e-mail, fax, or telephone.

In one embodiment of the invention, four basic types of users may exist: a primary user, a secondary user, an end user, and a transit user. Each user may be identified in the process by a unique user name. In general, a primary user may be the highest level user who creates and maintains the business process. A secondary user may be a user who is subordinate to a primary user and who is responsible for one or more specific tasks of a business process. An end user is typically a party that is a client or customer of the primary user. A transit user is typically a member of the public and is a user that may access and use embodiments of the invention that are open for public use. A transit user, therefore, may not, in one embodiment, have an account with the system. Instead, the transit user can access public information, although in order to participate in the business process, the transit user set up an account.

Figure 3 illustrates the relationships between the process 30 and the parties involved in the process 30. All primary users 32, end users 34, secondary users 36, and transit users 38 of the process 30 are connected to the central system 10 via the communication network 14, which may be the Internet. All of the communications between the process 30 and the users may be two-way communications. In one embodiment, however, the communications between the process 30 and the transit users 38 may be limited such that the transit users 38 have only limited access to the process 30 and can only view and participate in the public portion of the process 30. The process 30 typically does not voluntarily send information to transit users 38. In some instances in practice, the process owner does not know in advance if there will be transit users 38 to participate in the process 30.

In one embodiment, a primary user 32 may be responsible for creating, defining, maintaining, modifying and terminating a business process 30, and the primary user 32 may authorize one or several secondary users 36 to create and define a process 30, or create and define part of the process 30. The primary user 32 typically owns the process 30 it creates unless it assigns the process 30 to others, and the primary user 32 usually has full access to the process 30. However, a primary user 32 may, in some instances, have to consult with or get permission from one or more end users 34 for process definition and modification. In one embodiment, one company or one organization has only one primary user 32 with the central system 10, although the central system 10 may not prohibit the company or organization from having more than one primary user account.

The primary user 32 may have a number of responsibilities and authorities. These responsibilities and authorities may include, but are not limited to, the following functions. The primary user 32 may be responsible for updating and maintaining the account information for the primary user account and its secondary user accounts, including updating of phone numbers, addresses, and passwords. The primary user 32 may select the services provided by the central system 10 to the primary user account. The primary user 32 may also set up secondary users for the primary user 32, such that the secondary users may or may not directly participate in a business process, or such that the secondary users may participate in more than one business process. The primary user 32 may also identify business partners and create and set up business processes and rules. In practice, the primary user 32 may have to negotiate with or get approval from its clients, who may be end users involved in the processes, in order to define the business processes and rules. In addition to the creation of business processes, the primary user 32 may modify or terminate business processes and rules.

Primary users 32 may essentially define the business process used with the invention, including assigning roles to secondary users, revoking roles from secondary users, and monitoring secondary users. The primary users 32 may be responsible for user account addition, removal, or suspension, and user account activity monitoring. Primary users 32 may also offer billing information support, access and monitor transaction histories, and monitor specific transactions. A primary user 32 may have aliases associated with it. An alias may be created when a process owner assigns a new account to a business partner who happens to have an account with the system, and the process owner may prefer to use an alias to identify its business partner. A company may, in one embodiment, have only one primary user 32, although in other embodiments, one company or entity may have any number of primary users 32 for the process.

A secondary user 36 is a single user involved in a business process 30 who has limited authorities. In one embodiment, a secondary user 36 may belong to a specific primary user 32

or a higher level secondary user 36. Within one primary user account there may exist several layers or levels of secondary user accounts. However, a primary user account may also have no secondary user accounts. In one embodiment, a secondary user 36 may be created by a primary user 32 and a primary user 32 may be the only entity that may create a secondary user 36. A secondary user 36 may participate in one or many different business processes. It is also possible that a secondary user 36 will not be involved in any business processes.

A secondary user's 36 participation in a business process and its roles in the process may depend on the assignment from its primary user 32 or higher level secondary user 36.

With authorization from the primary user 32, a secondary user 36 may assume some or all of the authorities and functions of the primary user 32. A secondary user 36 may also be granted

by the primary user 32 the authority to supervise other secondary users 36. In one

embodiment, a primary user 32 may assign one secondary user 36 as the project leader responsible for one business process. In this case, the secondary user 36 may supervise secondary users 36 and may have authority from the primary user to define, conduct, monitor and terminate the process. One function of other secondary users 36 in the process is to

accomplish tasks assigned to it by the primary user or its supervising secondary user 36. These tasks may include, but are not limited to, initiating processes, acknowledging, forwarding, or rejecting information electronically sent to it, conducting querying, spawning, or pending actions, and activating alarming systems. The end users 34 are often clients of the primary user 32, and the end users 34 may purchase goods and/or use services provided by the primary user 32. In other words, the end users 34 may be customers of the primary user 32. The nature of the end users 34 and relationship between the end users 34 and the primary user 32 determines whether the end users 34 may have influences in defining, modifying and/or terminating the process 30, and therefore the authorities and responsibilities of end users 34 may be determined through negotiation. For example, an end user 34 which is a large customer that routinely purchases goods or services from the primary user 32 may have significant influence in the process definition, ϊh such situations, when the primary user 32 exercises its authorities in a process 30 such as modifying the rules or roles, the primary user 32 may have to consult with the end user 34 and get approval prior to the process modification. In other cases, an end user 34 may not be an important client of the primary user 32, and permissions may not be required for many modifications. In still other cases, the end users 34 may be so important to the primary user 32 that authorizations from multiple end users 34 may be needed for any change of the process 30.

In one embodiment, the transit users 38 may not belong to any primary user 32 or secondary user 36. A transit user 38 may exist because there are processes that are open to the public, such as a graduate school application process or a job application process. In these cases, a transit user 38 may not need to obtain permission from the process owner to participate in the process. The transit user 38 may simply review information regarding a business process that is available to the public via the World Wide Web or otherwise. In other embodiments, a transit user 38 may wish to participate in the business process. In such a case, the transit user 38 may set up an account with the system, and then log on to the system and participate in the business process to the extent that the transit user 38 has authority to do so.

2. The Central Computer System

The central computer system 10 may be a single computer, it may be any number of computers networked together into a computer system, or it may be one or more computer servers operating over the Web. The central computer system 10 may contain a number of databases or servers, which may run on either separate computers or computer systems or may run on a single computer. In one embodiment, the central computer system 10 may have a web server and an application server. Any type of computer or computer system and software programs known to those skilled in the art may be used within the scope of the invention. In one embodiment, the central computer system 10 may be a server computer with WindowsNT, Windows 2000, Windows 95 or Windows 98, Sun Microsystems 's operating system, or an IBM operating system. In addition, software or programs within the servers or databases of the central computer system 10 or elsewhere may be used to carry out the functions and operations of the invention described above and below.

An overview of one embodiment of the central system 10 for processing and data storage of the present invention is illustrated in Figure 2. In this embodiment, the central system 10 contains an interface 16 to users, a common function 18, a foundation 20, and the system infrastructure 22. In one embodiment, the interface 16 links the users of the system via the communication network 14, which may be the Internet. In some embodiments, the interface 16 may be modified to communicate with certain types of internal network systems of some users 12 and to perform internal management of the users' business processing. The interface 16 may, in one embodiment, be used as an interface between the user and the programs, rules, and/or databases of the system. The process definitions are the definitions that set up and define the process and operation for which the system may be used. The process definitions, therefore, may include any definitions used to set up and carry out a process in accordance with the invention. Process definitions may be set up through a variety of methods used for data entry that are known to those skilled in the art, including document/table input, drag and paste software, and through the use of a graphical user interface ("GUI"). Process definitions, which may be defined by a primary user or an authorized secondary user 36, may include:

• setting up the flow of the process; for example, setting up the flow of the process from one state to another state, such as from State A to State Z.

• setting up the process states; for example, a process may have N states in addition to State A and State Z.

• identifying the parties that are involved in the process; for example, a process may involve M parties and each party may be involved in one or many process actions and states.

• assigning rules and roles to the parties involved in the process; for example, secondary user #1 may have the authority to initiate the process, secondary user #2 may be the manager who is responsible for the process and may have authority to oversee all of the parties involved in the process, and secondary user #3 may only have the authority to acknowledge the receipt of information when the information comes to its site.

• authorizing selective information distribution, such as which information is distributed to particular parties and the timing of the selective information distribution. ^• authorizing information screening, filtering and selection, such as determining which parts of the information should be sent to particular parties of the process.

• setting up alarm features, routing, and actions, such as when and where alarm signals should be sent and when and where alarm signals should be escalated and sent.

• setting up timing for automated periodic logging on to the central system 10 for the parties that do not have continuous access to the Internet. For example, a small program could be installed at a user's computer or downloaded from the central system 10 when a user first registers with the central system 10, and the program could perform the automated periodic logging on.

• setting up the responsible parties and scheduling for billing.

In one embodiment, after a process is defined and initiated, the central system 10 will carry it out to completion unless it is interrupted or terminated by authorized users.

The common function module 18 of the central system 10 uses commercially available functions, software, and systems to carry out common functions for business processing and communication. These functions may include, but are not limited to: registering new users and opening new accounts with the system, verifying the identification of a user when he or she logs onto the system (through the use of a user name and password), sending information to and retrieving information from the system and its users 12, blocking unauthorized access to the system from non-users or from non-authorized users, and accepting process definitions from primary users and authorized secondary users 36, on-line messaging, chatting, e-mailing, editing, word processing, calculating, searching, acknowledging, accepting, and forwarding and rejecting. Any commercially available software, such as, but not limited to, Microsoft Outlook, Microsoft Word, Lotus Notes, or other e-mail systems, may be used to perform one or more of these functions. Some of the functions of the interface 16 may also be carried out by the common function module 18, such as user registration and security verification.

The foundation 20 provides the functionality to carry out the primary tasks of the system. The foundation 20 may provide the basic computerized automated operations including, but not limited to, the following:

• Interactively accepting one or more authorized user's 12 instructions to predefine processes, rules and roles. In other words, a primary user or an authorized secondary user may interactively communicate with the foundation 20 via the interface 16 to define a business process.

• Interactively accepting one or more authorized user's 12 instructions to modify and re-define processes, rules and roles.

• Automatically carrying out the selective on-line distribution of information to authorized users and the timing of the distribution of selected information.

• Automatically carrying out the dynamic screening, filtering and selection of information prior to authorized distribution.

• Automatically and dynamically tracking business processing and information;

• Automatically and dynamically searching for information related to the business process.

• Automatically and dynamically sending, re-sending, and escalating alarm signals to authorized users.

• Automatically and instantly updating process statuses and information. The system infrastructure 22 includes the hardware and supporting software needed for the system operation. As noted above, the hardware may include one or more computers, servers, storage devices, and communication hubs. The software may include operating system software, data base software, server interaction software, and any other programs needed for operation of the system.

In one embodiment, a primary user may set up a process on the system such that a business process is automatically carried out to completion. Information may be selectively distributed according to preset permissions defined by the primary user and/or an authorized secondary user, and the parties to the process may view the process status and be kept appraised of the developments in the business process. These and other features of the invention will be discussed further in the following section. b. The Process

Figure 4 shows the description of a generic process 30, which is an abstraction of many business-related processes in many industries that requires the exchange of information to reach an agreement between certain business partners. In general, the processes 30 set up using the invention may have the components and definitions set forth in Figure 4. In one embodiment, the invention may be used to set up a specific process and then the invention may be used to run that process. The invention, therefore, may be used to define a specific process that performs particular processes or business tasks. For example, in one embodiment, the invention may be used to define a graduate school application process between an individual applicant and a university. Data exchange in the graduate school application process includes basic information about a student, such as name, address, and social security number, academic information, such as undergraduate GPA, undergraduate degree and college, and application data, such as the department to which the applicant is applying, the degree applied for, and the desired starting semester. Other data in the graduate school application process may include the professors' review comments and the decision to admit or reject the applicant. The following description defines the components, including the document, data fields, roles, states, state transitions, and rules, that may be used in one embodiment of the invention to define and then run a specific, user-definable business process.

1. The Document

The document 40 is the abstract concept of the data content exchanged and handled by the business partners involved in a process 30. Although different industries have different businesses to handle, communication is always conducted by exchanging information (referred to herein as "documents") between different business partners.

By definition, in an embodiment of the invention, any process may have a document 40 associated with it and a document 40 cannot exist without an associated process 30. It is also possible that a document 40 may have a set of sub-documents associated with it. In one embodiment of the present invention, the document 40 is the central data repository where all of the process-related data from all users of the process 30 are located. At different stages of a process 30, data content may be entered, modified, and viewed by authorized users. Structurally, a document 40 may contain one or more data fields 42, and a data field 42 may belong to (be subordinate to) a document 40.

2. The Data Field

Figures 4 and 5 depict the relationship between a data field 42 and a document 40. A data field 42 may contain meaningful information that may be identified and updated individually. A data field 42 may have its own name, data type, and size. The data field's 42 name may be a unique identifier. The data field 42 type indicates how the content in the data field 42 should be interpreted by the process 30 and its users. Nalid data field types include a number, text, binary type, yes/no, date/time, image (a type of binary data), and audio/video (a type of binary data).

The data field's 42 size is an integer number indicating the number of bytes occupied by the data field 42 when it is stored in a persistent storage device, such as hard disk drive. Depending on the type of data field 42, the data field 42 size may not be a fixed number.

Each data field 42 has a data owner (a user of the process). The data owner is responsible for the content of the data field he or she owns. In general, there may be two types of data: system-generated data and non-system generated data. The system-generated data are the data generated by the system during operation of the process. For example, data field A may contain information resulting from a calculation performed based on the contents in data fields B and C. The system-generated data, in one embodiment, cannot be overwritten by a user without predefined or granted authorization. The owner of a data field, however, can typically delete or modify the non-system-generated data contents. Such modification or deleting, however, typically follows the predefined process rules.

3. The Role

A role 44 (Figure 4) represents action(s) and/or responsibilities in a process 30. When a role 44 is assigned to a user, the user becomes a role taker. One role 44 may be assigned to more than one user, and possibly many users at the same time. One user may also have many roles at the same time. Figure 4 shows that a process 30 typically has a set of roles 44 associated with it. Each role 44, which may belong to a process 30, may have a unique identification number within the scope of the process 30.

Typically a process 30 is not created and handled by one user. Instead, a process 30 normally involves many users, each having its own responsibilities. For example, in the graduate school application process, a student may be the requester in the process and the graduate school may be the reviewer and approver of the process. In such a process, the student, as a user, takes the requester role and the graduate school, as another user, takes the reviewer and approver roles in this process.

Roles 44 may be dynamically created at the time a process 30 is defined and can be modified during the operation of the process 30. Roles 44 can be assigned by primary users 32 to other end users 34, secondary users 36, and transit users 38 in processes 30 that are open to the public. Roles 44 that have been assigned to a given user may be further assigned to other users if the user is given the proper authority to make such assignments.

A role taker may also be a system role taker instead of a given user. A system role taker may receive a document as an input and may determine the outcome of a transaction based on the execution of the defined process rules. The execution of roles by such a system role taker is therefore done by the system based on the pre-defined process rules. 4. The State

The state 46 (Figure 4) represents a status of a process 30. As one process 30 usually contains a certain number of actions or steps, each action is performed by a role taker, and the state 46 may represent the status of the process 30. An action in the process 30 may modify certain content of the document 40.

The state 46 is also used to enable the authorized document distribution. For example, when a student has submitted his/her application to a university in a graduate school admission process, the state 46 of the application process may be called "submitted." In this state 46, the student may only be allowed to view the data entered by himself/herself, and the student may not be allowed to view the comments of a reviewer or the identification of the reviewer. The graduate school, another user in the process who may be the process owner, may decide if and when the comments of the reviewer may be released to the student. Without authorization from the graduate school, the comments of the reviewer may not be accessible to the applicant at any time. The process 30 may be set up so that in certain states, such as in the "admitted" state, the applicant may be allowed to view the review data of the graduate school. The process 30 may be defined such that the state 46 of the process determines who may view certain data of the document 40.

One process 30 may have several different states 46, and the process owner may decide which data fields 42 at which states 46 are accessible to particular role takers. In addition, the process owner may decide what type of access may be granted to particular role takers. These roles 44 are normally defined when a process is created. However, the states 46 may be created, modified, or terminated during a process 30 by authorized users.

The state 46 of a process 30 may be dynamically and instantly updated by the process 30 to accommodate status changes after a state transition 48. Each state 46 in a process 30 may have a unique name. In one embodiment, every process may have the following five system-defined states: (1) an initial state, which may mean the process has not yet started and may indicate the initial state from which a process may begin; (2) a completed state, which may mean that the process 30 is finished and that no further action may be taken; (3) an intermediate state, which may be any state between the initial state and the terminated state, any number of which may exist for a given process 30; (4) an interrupted state, which may be a state in which a role taker requests to change the content of a document 40 and bring the process 30 back to its previous state, and before the change request is approved by the involved role takers, no further action can be taken for the process; and (5) a terminated state, which may mean that the process 30 has been cancelled for a certain reason, and once a process has been terminated/cancelled, no further action can be taken for the process 30.

Each state 46 may also be defined as an input dependent state or a free state. An input dependent state is a state that needs to receive an input from another state 46 in order to become active. For example, a "review" state for a graduate school application process is an input dependent state because the "review" state does not become active unless it receives an input from a previous state 46.

A free state, on the other hand, can become active either by input from previous states or by an action from its role taker. An initial state of a process may be a free state because the initial state does not have previous states and therefore does not receive inputs from previous states. For example, in a graduate school application process, an application submission state may be defined as the initial state and a graduate school review state may be the following state. The application submission state can be activated by a role taker, such as a student submitting an application for admission, and the application submission state is therefore a free state. The graduate school review state, which is dependent upon receiving a certain minimum amount of information from the student, will only be activated if a student submits an application, and the graduate school review state is therefore an input dependent state.

Each state 46 may also be a simple state or a complex state. A simple state is a state that will move to the next state shortly after receiving input from a previous state or when the

role taker takes an action. For example, the initial state of a graduate school application

process is a simple state in which a student initiates the application process by inputting necessary information for the application, after which the initial state moves to the next state, which may be the graduate school review state.

A complex state, on the other hand, may be a state 46 that contains one or more sub- processes, and it often has special rules attached. For example, the graduate school review state may have a number of sub-processes that allow different reviewers to review an

applicant's application. In one embodiment, four reviewers could be professors and one reviewer could be an admissions office worker, and one or more of the reviewers could have

different functions. In addition to the possible features of states set forth above, a state may

also have a number of other features, as set forth in the test and representative examples

below.

5. The State Transition

The action of a role taker changes the status of a process 30 from one state 46 to

another state 46, which may be referred to as a state transition 48. Change to a process's state 46 may be regulated according to the actual business rules of the process. For example, in a graduate school application process, a student's application cannot jump directly from the

submitted state to the approved state, because one or more reviewers must first review the

data provided by the student and make a decision regarding the student. If the student's data is acceptable, the reviewer (a role taker) can take an action to change the state 46 of the process to the "accepted" state. Once an application is accepted, other role takers such as other university officials may determine whether the application should be approved or

denied.

A state transition 48 consists of a transition from a first state to a second state. States 46 involved in a state transition 48 may be defined in the process 30, and each state transition 48 is carried out by a specific role taker in the process 30. For example, in the

graduate school application process, the student (the requester) can change the process from

the initial state to the submitted state by inputting certain information in the document 40. In

addition to the possible features of states set forth above, a state may also have a number of other features, as set forth in the test and representative examples below.

6. The Rules

Rules 50 are the constraints posted on a state transition 48. Rules 50 may determine or guard the execution of a process 30 at runtime. The rules 50 apply to the document 40 of

the process 30 during execution of the process 30. For example, the following data consistency rules are posted on the state transition 48 from the initial state to the submitted state in the graduate school application process: name, address, social security number, phone number, department to apply to, semester to start, undergraduate GPA, undergraduate college name, and undergraduate degree. In other words, the student must enter acceptable data for each of the data fields 42 above to move from the submitted state to the received state. When an applicant tries to submit his/her application document, the system must verify that acceptable data have been entered to these data fields 42.

The rules 50, therefore, may be process specific and may be associated with each state transition in the process. The rules 50 may be implemented as specific program logic or common modules. c. Setting up the Process

A process 30 may be defined in a number of manners in accordance with the invention. In one embodiment, a series of tables or text editors may be used to set up the process, as is depicted for a specific embodiment involving trucking in Figures 8-14. In other embodiments, a graphical user interface ("GUI") may be used to map out a process 30, and a combination of text editors and GUIs may also be used to set up a process 30. It should be noted that the users, document, data fields, roles, states, state transitions, and rules define the process, such that this information may be set up differently to create a user-definable process. In addition, any type of method known to those skilled in the art may be used to set up these relationships so that the process performs the intended function.

1. Using a Graphical User Interface to Set Up a Process

In one embodiment of the invention that uses a GUI to set up the process definition, a state 46 may be represented by a circle or other shape on a diagram, as shown in Figure 5a. In Figure 5a, for example, the circles sO, si, s2 . . . sl3 represent states of the process. In one embodiment that uses a GUI, different colors or shapes may be used for the circles representing the states. In order to set up a process using a GUI embodiment, the user may place one or more circles on a screen and then click on each circle in order to define the properties of the state. Figure 9 is a depiction of a table method of input that allows a user to define states with a state name and a state description.

In the GUI embodiment of Figure 5a for defining a process, a state transition 48 may be represented by a line with an arrow at the destination end. For instance, a state transition is represented by the line between the state sO and the state si in Figure 5a. After a user who is defining a process places a line representing a state transition on a page, the line may be clicked on or double-clicked on in order to open up a property window that may be used to define the properties of the state transition. The properties of a state transition may also be defined using a table method of input, as is illustrated in Figure 10.

A state transition may have the following properties: a name, a "from state" that represents the beginning state in the state transition, and a "to state" that represents the finishing state of the state transition. If a GUI embodiment is used to define a process, the user may place an arrow between the circles representing two states. The direction of the arrow, as indicated by the pointer at the tip, indicates the direction of the state transition from

the "from state" to the "to state."

Figure 5b depicts a number of arrows representing possible state transitions that may be used within the scope of the invention. The numbers on the left hand side and the right hand side specify how many "to states" or "from states" the transition connects. For instance, transition 500 in Figure 5b is a transition from a single state to another single state. Transition 520, on the other hand, is a transition from a single state to n destinations of the same state, which may be any number of destinations as determined by the role taker when the process runs or when the process is defined. For instance, in a graduate application review process, a "from state" may be the completed application state in the admissions office, and the "to state" may be a review process by a number of professors. Each "to state," therefore, may be the same type of state ~ review by a professor. Any integer 1 to n may be set up for both the source number (at the "from state") and the destination number (at the "to state"). The source number and destination number may be set up using a GUI embodiment of the invention through a window that may appear when a user clicks on an arrow representing a state transition.

A state transition may be either repeatable or non-repeatable. A repeatable state transition is a state transition that may occur more than one time during a process. For instance, a client may ask for a quotation for a given product from a manufacturer any number of times, and a state transition representing this quotation would therefore be repeatable. A non-repeatable state transition, on the other hand, is a state transition that can occur only once during a process. For an embodiment in which a client submits a request for a quotation to a manufacturer, for instance, the client may only order the product once. If the client asks for more than one order, or repeats an order state transition, the product will be placed on order more than one time. Such a state transition, therefore, is non-repeatable, because the state transition will only occur once during the process. The client in this example could change an order request, but such a change would involve canceling or modifying the original product order. In an embodiment using a GUI to define a process, a repeatable state transition may be represented with a double arrow at the end of a state transition line, as for state transitions 540, 550, 560, and 570 of Figure 5b. A non-repeatable state transition may be represented by a single arrow at the end of a state transition line, as depicted for state transitions 500, 510, 520, and 530 of Figure 5b. The repeatability or non-repeatability of a state transition may be entered in a GUI embodiment of the invention in a window used to define the properties of a state transition. Figure 5b depicts eight possible types of state transitions. State transition 500 represents a single-source, single-destination, non-repeatable state transition. Such a state transition may be used for an order submission from a client to a manufacturer. State transition 510 represents a multiple-source, single-destination, non-repeatable state transition. Such a state transition may be used in a graduate school application process where a review committee receives review reports from a number of professors. State transition 520 represents a single-source, multiple-destination, non-repeatable state transition. Such a state transition may be used by an admissions office that receives an application from a candidate and then forwards the application to multiple professors for review. State transition 530 represents a multiple-source, multiple-destination, non-repeatable state transition. State transition 540 represents a single-source, single-destination, repeatable state transition. State transition 550 represents a single-source, multiple-destination, repeatable state transition. State transition 560 represents a multiple-source, single-destination, repeatable state transition. Finally, state transition 530 represents a multiple-source, multiple-destination, repeatable state transition.

If a state transition has multiple sources, such as state transition 510 in Figure 5b if n > 1, a transition finishing rule may be used to specify when the state transition is considered to have been satisfied such that the "to state" has been reached. In an example where five professors are involved in a graduate school application process to review an application, the state transition from a submitted state to a reviewed state may be completed if, say, three of the five professors have reviewed the application. In another embodiment, it may be required that each of the five professors review the application. If three of the five professors need to review the application and submit reports in order for the application to reach the reviewed state, the transition finishing rule may be "3/5." If each of the five professors needs to review the application and submit reports, the transition finishing rule may be "5/5." In a more complex example, four of five professors may need to review the application and submit reports in order for the application to reach the reviewed state, and an admissions worker may also need to verify the applicant's academic scores in order for the application to reach the reviewed state. In such an example, each of the professors has the same function in reviewing the application, but the admissions worker has a different function. In such an embodiment, the transition finishing rule may spell out the difference between the role of the professors and the role of the admissions worker. A transition finishing rule for such an embodiment may be "4/5, 1," meaning that the state transition is not completed unless four of the five professors and the admissions worker have completed their tasks.

Figure 5b depicts eight possible state transitions that involve moving from a first state to a second state. Although the first state may have multiple sources (i.e., state transitions 510, 530,560, and 570), each source is the same type of state. Similarly, although the second state may have multiple destinations (i.e., state transitions 520, 530, 550, and 570), each destination is of the same type of state. For example, if state transition 520 represents a transition of a candidate's application for admission to graduate school from the admissions office to five professors for review, the state for each of the five professors may be the same.

In addition, however, it is possible to have a transition from a single state to multiple destination states, which differs from a transition from a single state to multiple destinations of the same type of state, as depicted in numeral 520 in Figure 5b. Figure 5c depicts a transition from a single state 600 to multiple destination states 602, 604, 606, 608. In such a transition, a single source state 600 is transitioned to several different destination states 602, 604, 606, 608. An example of such a transition for a product delivery process follows. A trucking company 600 may receive an order from a first company 602 to pick up a product from a second company 604 and deliver the product to a third company 606. The trucking company 600, therefore, may send a proposed delivery date and delivery information to the first company 602, second company 604, third company 606, and trucker 608 who will deliver the product. The state at each destination differs in such a scenario.

Figure 5c also depicts a firing rule 610 in an embodiment in which a single source state 600 is transitioned to several different destination states 602, 604, 606, 608. A firing rule may be any rule that determines how many destinations states must be reached in order to complete the state transition. For example, a firing rule for the product delivery example explained above with reference to Figure 5c may specify that only the trucker 608, second company 604, and third company 606 need be reached in order for the state transition to be completed.

Figure 5d depicts yet another embodiment of a state transition in which multiple source states 620, 622, 624, 626 transition into a single destination state 628. In other words, information from different states or sources combine to form the document to be used in the process at the destination state 628. In a graduate school application review process, a professor could review a candidate's application for substance, an admissions worker could check on the candidate's academic record for accuracy, and an admissions counselor could speak to the candidate's references. In such an example, each source state is different, but the single destination state could be a state representing a completely reviewed application.

Figure 5d depicts a ready rule 630 in an embodiment in which several different source states 620, 622, 624, 626 transition to a single destination state 628. A ready rule 630, which may be represented by a dotted line or some other character in a GUI embodiment, may be any rule that determines when the destination state is considered ready, and thus when the transition between the source states 620, 622, 624, 626 and the destination state 628 may be considered complete. The ready rule may determine which information from the source states 620, 622, 624, 626 the destination state 628 needs to receive in order to become ready. For example, in a sales process as indicated in Figure 5e, a manufacturer's representative 640 may need to receive price information from the manufacturer 642 and delivery information from a trucking company 644 before the manufacturer's representative 640 can send a quote back to a customer that made an inquiry for the goods. In such a case, the ready rule 646 may be defined as "2/2," indicating that the manufacturer's representative 640 needs to receive both the price information and the delivery information in order to be ready to determine a quotation and transfer it to the party seeking the quote. In another embodiment, as depicted in Figure 5f, a manufacturer 650 may be able to continue a process (be ready) if the manufacturer 650 receives an order from either a market representative 652 or an end user 654. In such an embodiment, the ready rule 656 may be defined as "1/ 2," indicating that only one of the two source states 652, 654 need be satisfied in order for the destination state

650 to be ready.

2. An Example of a Process Defined Using a Graphic User Interface The following example sets forth a process in standard language, a depiction of the process using a GUI, and the definitions of the states and state transitions used in the GUI. It should be noted that this is but one example of a number of processes for which the invention may be used, and the process of the invention may be set up in a number of manners that differ from the description below within the scope of the invention. a. Definition of the Process in Standard Language This example deals with a local store that typically orders its goods from local dealers. The store owner usually contacts several local dealers for a quotation when the store owner needs to order goods or products. Once one or several quotations have been delivered to the store owner, the store owner will submit an order using one of the dealers. In an urgent situation, the store owner may just submit an order (without requesting a quotation) to one dealer using a previous price or without specifying a price, thus allowing the dealer or a manufacturer to fill in the price. The store owner typically has good relationships with several dealers and/or manufacturers, and the store owner therefore may trust the dealers/manufacturers to fill in prices in urgent situations.

After a dealer receives a quotation request from the store owner, the dealer may ask one or more manufacturers for price and delivery information. In another case, the dealer may simply send the quotation back to the store owner if dealer can readily determine the price and delivery information from previous experience or because the dealer has the goods

on hand.

After a manufacturer receives a quotation request for goods from a dealer, the manufactures may return a quotation to the requesting dealer. A dealer may or may not receive quotations from all manufacturers from which quotations were requested.

Once the store owner receives the quotations from one or several dealers, the store owner may submit an order to one of the dealers. The dealer who receives the order from the store owner will then send an order to a manufacturer and will also send a quotation request to several trucking companies for shipping the goods to the store owner.

Much like the previous quotation request procedure, once the dealer get the quotations back from one or several shippers, it sends the actual shipping request to one of the shippers. At the time the product is ready for shipping from the manufacturer, the manufacturer sends the product ready information to the shipper and the dealer.

Upon receiving the product ready information from the manufacturer, the shipper sends the actual delivery date confirmation request to the manufacturer, the dealer, and the store owner. The manufacturer needs to confirm the pickup date and the store owner needs to accept the deliver date. After the pickup and delivery dates are set, the shipper can actually ship the product. After shipping is completed, the shipper sends out delivery notices to the manufacturer, the dealer, and the store owner for final confirmation. The entire process is complete when the final confirmation has been received. b. The State Definitions of the Process The state definitions, as previously discussed, may be set up using any method described above or known to those skilled in the art. Following is a set of state definitions for the example above, which is also depicted in Figure 5a. The descriptions below more fully explain the flow of Figure 5a, by setting forth the firing rules, ready rules, and other information.

SO: Initial state, process starts from SO (SS, FS, Fl/2), where SS = Simple State, FS = Free State, Fl/2 = Firing Rule Vi, the state transition from SO to SI and S2 is completed when at least one of the state transitions tsl or ts4 is completed. SI: AskQuoataionMR (SS, IDS, Fl/2), S2: MRQuotationBack (SS, IDS, Rl/2), where, IDS = Input Dependent State, Rl/2 = Ready Rule Vi, meaning the state transition from S9 and SI to S2 is completed when at least one of the two possible state transitions ts2 or tsl 3 is completed. The Ready Rule can also be spelled out to indicate which of the state transitions must be completed. For example, R-tsl3 means that the state transition tsl 3 must be completed. S3: OrderSubmitted (SS, IDS, Rl/2, F2/2), S4: AskQuotationSHP (SS, IDS), S5: OrderReachMF (SS, IDS, R2/2), S6: SHPQuotationBack (SS, IDS, F2/2), where, F2/2 = Firing Rule 2/2, the state transition from State S6 to S5 and S7 is not completed unless both state transitions ts8 and ts9 are completed. The Firing Rule can also be spelled out to indicate which of the state transitions must be completed. For example, F2/2 can be written as F-ts8, F-ts9. S7: ShipperOrderSubmitted (SS, IDS, R2/2, F2/2), S8: AskQuotationMF (SS, IDS), S9: MFQuotationBack (SS, IDS), S10: AskPickupDate (SS, IDS), SI 1: AskDeliveryDate (SS, IDS), S12: ShippingReady (SS, IDS, R2/2), S13: ShippingDone (SS, IDS). c. The State Transition Definitions for the Process Much like for the state definitions, the state transitions may be set up using any method described above or known to those skilled in the art. Following is a set of state transitions for the example above, as is also depicted in Figure 5a.

Tsl: Ask quotation to Dealers (1 source, n destination, repeatable), Ts2: Send quotation to store owner (n source, 1 destination, repeatable), Ts3: Submit order to dealer (1 source, 1 destination, non-repeatable), Ts4: Submit order directly (1 source, 1 destination, non-repeatable), Ts5: Submit order to manufacture (1 source, 1 destination, non-repeatable), Ts6: Ask quotation to shippers (1 source, n destination, repeatable), Ts7: Send quotation to dealer (n source, 1 destination, repeatable), Ts8: Submit shipping order to shipper (1 source, 1 destination, non-repeatable), Ts9: Inform shipper to manufacture (1 source, 1 destination, non-repeatable), TslO: Send product ready inform to shipper (1 source, 1 destination, non-repeatable), Tsl 1: Ask quotation to Manufactures (n source, n destination, repeatable), Tsl2: Send quotation to Dealers (n source, n destination, repeatable), Tsl3: Send quotation to store owner (n source, 1 destination, repeatable), Tsl4: Ask pick up date from manufacture (1 source, 1 destination, non-repeatable), Tsl5: Ask delivery date from manufacture (1 source, 1 destination, non-repeatable), Tsl 6: Send pick up date information to shipper (1 source, 1 destination, non-repeatable), Tsl7: Send delivery date information to shipper (1 source, 1 destination, non-repeatable), Tsl8: Send shipping notice to all parties (1 source, n destination, non-repeatable). d. Representative Examples

The generic process 30 shown in Figures 1 - 5 is an abstraction of many business- related processes in many industries that require information exchange to reach an agreement among certain business partners. The following are specific representative examples of some applications of the above embodiments of the invention. Although the description below may pertain to setting up the process definitions using a table entry form, a GUI could also be used to set up the processes.

1. Trucking industry

Figures 6-8 show the interface of one embodiment of the invention for a trucking process for defining roles 44 of the process. Figures 6 and 7 show three roles 44 that have been defined for the process: a merchant 60, a trucker 62, and a consignee 64. After roles 44 have been defined, they may be assigned by the process owner, the primary user, or authorized secondary users to different accounts, such as the primary user account, a secondary user account, or an end user account. Figure 6 also shows the definition of each role 44. In addition, Figure 6 shows the states 46 for the trucking process, including three intermediate states 66, 68, 70 for the trucking process, and Figure 6 also depicts each of the state transitions 72, 74, 76, 78, 80 for the trucking process, including a definition of each state transition 72, 74, 76, 78, 80. Figure 7 depicts the document 40 for the trucking process, including twelve data fields for this process, the data type 82 of each data field 42, and the owner 84 of that data field 42. Figure 8 depicts one possible embodiment of an interface that may allow a process owner or user to define the roles and role descriptions for the trucking process, and may be in the form of a web page to allow selection by clicking of certain options. Figure 8 depicts the definitions for three roles — a merchant, a trucker, and a consignee — and these roles may later be assigned to specific users.

Figure 9 depicts an embodiment of a interface that provides for the definition of the states and state descriptions for the representative trucking process. As shown in figure 9, an Initial 90, Completed 92, and Terminated 94 state may be defined as system defined states, and in this embodiment, no removal action may be applied to these states to remove the states from the process. In addition to these states, three other states 96, 98, 99 are shown defined and described in Figure 9.

After states have been defined, one can continue to define the transitions between different states, as depicted in Figure 10. Figure 10 depicts one embodiment of an interface that may be used for defining state transitions and assigning the role name of who partakes in the state transition. Figure 10 shows a user defining a state transition from the "TKDeliveryDateApproved" state to the "Completed" state, and depicts the trucker as the role name for this state transition, and Figure 10 also depicts that three other state transitions have been defined for the representative trucking process. After state transitions have been defined, the document for the process and the flow of the process may be established. Figure 11 depicts an embodiment of an interface that may be used for definition of the document. Figure 11 depicts a series of field names, each having a data type, length, field description, and an owner. As shown in the embodiment of Figure 11, any number of data fields may be defined for the process (as many as needed). The document depicted in definition in Figure 11 may be the central data repository for the process, and the document or data fields thereof may be exchanged among different roles or users of the process in practice.

Figure 12 depicts a user interface that may be used for defining permissions for various data fields. For instance, the "ConsigneelD" has been defined to be the Merchant's field, and permission for initial input has been granted to the merchant. Document authorization defines who can access which portion(s) (or data field) of the document, thus making authorized data distribution feasible.

After a process has been defined, it may become executable immediately. Roles may be assigned to different business partners for the process. After a user has been granted a role, the user can perform the actions defined by that assigned role in the process. Figures 13 and 14 depict two steps that may be used to assign a role to a business partner in one embodiment of the invention. Figure 13 depicts the selection of a given process for which roles may be assigned. Figure 14 depicts the assignment of defined roles to different users. For instance, in Figure 14, the "Merchant" role has been assigned to user "dtdtOOOl" and the "Consignee" role has been assigned to "mfgxOOOl." A selection may also be made to assign the "Trucker" role to a given user. After a role has been assigned to a user, the user can further assign that role to other users under his/her supervision. Figure 15 depicts a flow chart showing the set up of a process. As seen on the right

hand side of Figure 15, roles 44, states 46, state transitions 48, documents 40, document authorizations 102, and rules 50 may be defined for the process as described above. The left

side of Figure 15 depicts the acts of the login of the process owner 104, the definition of the process 106 (as also depicted on the right side of Figure 15), assigning roles to business

partners 108 (who may be end users), assigning roles to public users 110 (who may be transit

users), and assigning roles to employees 112 (who may be secondary users). After process definition, a user may login to the central system 10 and execute the process 114 according to

the process definition.

2. Graduate School Application Process

Figures 16-18 depict an embodiment of the invention for the graduate school

application process. As Figure 16 depicts, various sub-processes may be defined at different levels of a process. A sub-process, therefore, may be integrated with its parent process. Such a construction may reduce the overall data maintenance costs of the business process and, at

the same time, every business partner may still maintain its own integrity, flexibility and

characteristics.

Many universities have graduate school application processes, and each university may have its own rules and policies for handling the applications. Typically, without a system such as that of one embodiment of the invention, each applicant must submit his/her

application individually to each university or even to each department in order to be considered for admission. If a process is defined as having sub-processes, it may be possible for an applicant to submit only one application, and the same application may be distributed to different universities and processed by them using their own sub-process definitions and rules individually. Using the same process definition model described above, a sub-process may be modified without affecting its parent process, and therefore each sub-process may be integrated with other processes smoothly.

Figure 16 depicts the process hierarchy of the graduate school application process in one embodiment. As shown in figure 16, the first level process 120 may be a universal application process defined that may be defined by a system owner, such that the first level process 120 is used by each university. It may define the most generic application process model of the process, which may be shared by each university. The first level process 120 may consist of three states: an initial state 130, a review state 132, and a complete state 134. Since each university's review process may be different from another university's review process, the second level process 122 may be defined by each university according to its own rules and policies. The review state 132 from the first level process 120, therefore, may be broken up into a series of states and state transitions in the second level process 122, such as an initial review 136, a department review 138, and a final review 140. The third level process 124 may be defined by each department, such that, for instance, the computer science department 142, the physics department 144, and the business management department 146 may each define their review procedures. Figure 16a depicts a flow diagram for the graduate school admissions processes in which state names and a flow for state transitions is indicated.

Figure 17 depicts one embodiment of a simplified first level process 120 definition of the graduate school application process. The same document may be shared by each university to which an applicant may apply. This process definition depicts a number of states in the process and the data fields and corresponding data types and owners that may be used in this process.

Figure 18 depicts a sample second level sub-process 122 defined by one university for the graduate school application process. As shown in Figure 18, more intermediate states are defined for the sub-process, including state transitions, and some new data fields have been defined by this university for its own process. Figure 18 depicts that two data fields are owned by departments in this sub-process: the department comments 150 and the department result 152. The remainder of the new data fields for this sub-process are owned by the graduate school initial reviewer. If a department has its own sub-process, the document

defined by the university can be further mapped to the document defined by that individual department. Using this recursive document mapping approach, the same data need only appear once in the central system 10, and there may be no need to maintain redundant data.

Another advantage of using a sub-process such as that identified above is that, in such

an embodiment, the university does not need to get a separate GRA score authentication or a

separate recommendation letter from other universities. Instead, all of this information may be centrally controlled by the central system 10 and distributed to different universities. Such a process, therefore, may reduce the cost of an applicant who typically must pay each

university for its review of the application. In addition, the process may reduce the amount of

data maintained by a university, which may be essentially redundant data, as data may be

shared by different universities or different departments within a given university.

3. A Sales Process

Figures 19 and 20 depict a sales process embodiment of the invention in the form of a

generic process model. In a sales model, a buyer may want to buy a certain product from a dealer. To protect itself, the buyer may wish to compare the prices offered by different dealers. A dealer, similarly, may wish to look for products from different manufactures that are of sufficient quality at an appropriate price.

Figure 19 depicts the relationship among the buyers 160, dealers 162, and manufactures 164 in the process. As shown in Figure 19, the buyer's purchase request may be distributed to a certain number of dealers 162. The dealers 162 may communicate with their manufacturers 164 for the price of certain products. The price quotations from the dealers 162 may then be forwarded back to the buyers 160 once the dealers 162 have the pricing data back from the manufactures 164.

After the price quotation is sent back to a buyer 160, the buyer 160 may compare the offers from different dealers 162 and continue the purchase process with one of the dealers 162. Figure 20 depicts this second part of the process, in which a trucker 166 is integrated into the process. Figure 20 shows the concept of process integration with peers. Thus, the sales process is integrated together with the shipping process, and the trucker 166 has become involved in the process automatically when there has been a shipping request. In order to automate information delivery to the trucker and integrate the trucker into the process, information may be distributed to the trucker automatically according to the process definition and state transitions. e. Trucking Example in Operation

An embodiment of the invention in operation to complete a pre-defined process is depicted in Figures 21-28 for the trucking example set forth in Section d.l above. After the process has been defined and set up as set forth above, a user may log on to the system of the invention, as depicted in one embodiment in Figure 21. After a user has logged on, a welcome screen may be displayed for the user, as set forth in one embodiment in Figure 22. Figure 22 shows that the exemplary user "dtd00012" has 4 pending transactions 200, 12 ongoing transactions 202, and 1 regular alarm 204. The regular alarm 204 may be a message or some other method of letting this given user know that some action has taken place or that some action need be taken by that user. The alarm 204 could let a user know that the user needs to perform an action, or the alarm could let a user know that a process has been completed or that certain sub-processes of the process have been completed. The alarm 204 could page the user, call the user, send an e-mail to the user, perform a beeping action on the user's computer, or may cause the user's computer to be automatically logged into the system of the invention.

The pending transactions 200, in the example of Figure 22, may indicate the number of transactions for which the current user need take action. The ongoing transactions 202, on the other hand, depict transactions that have not been entirely completed by all of the parties to the transaction, but for which the given user is not responsible for the next action or for which the current user has already acted. From a screen such as that of Figure 22, the user can start a new transaction, view a transaction history, or process a pending transaction.

If the user decides to start a new process, the user may select the process to be started from a list of processes such as that depicted in Figure 23. In one embodiment, only those processes that may be started by the current user will be displayed in a table such as in Figure 23. Assuming the process relating to trucking has been selected from Figure 23, a "start new transaction" page may be displayed to the user as set forth in Figure 24. Figure 24 shows the information the current user must add and/or select in order to start a new process. After the current user has entered sufficient information to submit the new transaction, the transaction will appear as a pending transaction on the next actor's screen.

Figure 25 shows a number of transactions that are in a que and are waiting to be processed by a given party. The list of pending transactions shows the acting role, the current state, and the last update date and time for the transaction. The current user may process one of the transactions by clicking on it in the list. Based on the definition of the process, an engine or window may be generated that may allow the user to interface with the transaction and take any necessary action. If the current user of Figure 25 is TMI and TMI decides to click on the process identified with "1255" in the transaction ID column, a table such as that in Figure 26 may appear. The table of Figure 26 displays the current state of the process and other information that the current user may not change, and table also allows the current user to add certain information (bottom four rows of Figure 26) such that the transaction may be processed by the current user. After the current user has processed the transaction, the transaction may be removed from pending transaction list of Figure 25 and placed in the ongoing transaction list, which is depicted in Figure 27. If the current user decides to modify a transaction that has already been processed, the current user may click on the transaction as in Figure 27, and a table may appear that allows the current user to modify the action taken. Figure 28 depicts such a table that allows the current user to enter a new value for an action taken, and Figure 28 also allows the current user to view the old value. f. Conclusion

The methods and systems of the invention automate the distribution of information to various parties to business processes. Li addition, the methods and systems of the invention may be used to define and carry out a detailed business process in a structured approach in which various users of the process may be kept appraised of the status of the process.

The accompanying Figures described above depict embodiments of the present invention, and features and components thereof. With regard to references in this specification to computers, the computers may be any standard computer including standard attachments and components thereof (e.g., a disk drive, hard drive, CD player or network server that communicates with a CPU and main memory, a sound board, a keyboard and mouse, and a monitor). The processor of the CPU in the computer may be any conventional general purpose single- or multi-chip microprocessor such as a Pentium® processor, a Pentium® Pro processor, a 8051 processor, a MIPS® processor, a Motorola Processor, a Power PC® processor, or an ALPHA® processor. In addition, the processor may be any conventional special purpose processor such as a digital signal processor or a graphics processor. The microprocessor has conventional address lines, conventional data lines, and one or more conventional control lines. With regard to references to software, the software may be standard software used by those skilled in the art or may be coded in any standard programming language to accomplish the tasks detailed below.

The system and method of the invention may use the "World Wide Web" ("Web" or "WWW"), which is that collection of servers on the Internet that utilize the Hypertext Transfer Protocol ("HTTP") or HTTPS. HTTP is a known application protocol that provides users access to resources, which may be information in different formats such as text, graphics, images, sound, video, Hypertext Markup Language ("HTML"), as well as programs. HTTPS is a secured option for accessing information over the WWW. Upon specification of a link by the user, the client computer makes a TCP/IP request to a Web server and receives information, which may be another "Web page" that is formatted according to HTML. In other embodiments, files and information may be transferred according to FTP (File Transfer Protocol), SMTP (Simple Mail Transfer Protocol), or other forms of e-mail. Users can also access other pages on the same or other servers by following instructions on the screen, entering certain data, or clicking on selected icons. It should also be noted that any type of selection device known to those skilled in the art, such as check boxes, drop-down boxes, and the like, may be used for embodiments of the invention using web pages to allow a user to select options for a given component.

Servers run on a variety of platforms, including UNIX machines, although other platforms, such as Windows 95, Windows NT, and Macintosh may also be used. Computer u^'sers can view information available on servers or networks on the Web through the use of browsing software, such as Netscape Navigator, Microsoft Internet Explorer, Mosaic, or Lynx browsers. A typical Web page is an HTML document with text, "links" that a user may activate (e.g. "click on"), as well as embedded URL's pointing to resources, such as images, video or sound, that the client may activate to fully use the Web page in a browser. Furthermore, HTTP allows for the transmission of certain information from the client computer to a server. The server can then post this information on its web site, forward it on to another user or server, or save it to a database for later use.

While the present invention has been described with reference to several embodiments thereof, those skilled in the art will recognize various changes that may be made without departing from the spirit and scope of the claimed invention. Accordingly, this invention is not limited to what is shown in the drawings and described in the specification but only as indicated in the appended claims, nor is the claimed invention limited in applicability to one type of computer or computer network. Any numbering or ordering of elements in the following claims is merely for convenience and is not intended to suggest that the ordering of the elements of the claims has any particular significance other than that otherwise expressed by the language of the claims.

Claims

CLAIMSWhat is claimed is:

1. A method for setting up an interactive business process for a plurality of users, the method comprising: accepting definition instructions from a user to set up the business process, including accepting rules, accepting roles to be taken by system users, and accepting data fields to contain information for the business process, wherein the act of accepting definition instructions allows the user to create a user-definable business process, and wherein the accessability of certain information within the data fields is a function of time and system user authority.

2. The method of claim 1, further comprising accepting assignment instructions from the user to assign the roles to specific system users.

3. The method of claim 2, wherein the act of accepting definition instructions includes accepting information on states of the business process.

4. The method of claim 3, wherein the act of accepting definition instructions includes accepting information on state transitions of the business process.

5. The method of claim 4, wherein the act of accepting information on state transitions further includes accepting ready rule information for state transitions.

6. The method of claim 5, wherein the act of accepting ready rule information includes accepting definitions of when a destination state is considered ready when the destination state can receive instructions from multiple source states.

7. The method of claim 4, wherein the act of accepting information on state transitions further includes accepting firing rule information for state transitions.

8. The method of claim 7, wherein the act of accepting firing rule information includes accepting definitions on how many destinations states must be reached in order to complete a state transition from a source state.

9. The method of claim 2, wherein the system users may be selected from the group comprising: primary users, secondary users, transit users, and end users.

10. The method of claim 2, wherein the acts of accepting definition instructions and

accepting assignment instructions is carried out using a graphical user interface.

11. A method for defining an interactive business process, the method comprising:

(a) accepting natural business process language that sets forth the functions of a

business process between a plurality of users; and

(b) translating the natural business process language into coded language by

interactively accepting definition instructions from a user to set up the business process,

including accepting rules, accepting roles to be taken by system users, and accepting data fields to contain information for the business process, wherein the act of accepting definition instructions allows the user to create a user-definable business process, and wherein the

accessability of certain information within the data fields is a function of time and system

user authority.

12. The method of claim 11, further comprising accepting assignment instructions from

the user to assign the roles to specific system users.

13. The method of claim 12, wherein the act of accepting definition instructions includes

interactively defining a document having the data fields and defining owners of the data fields such that the document may be accessed by various system users during operation of the

business process.

14. A method for defining a business process, the method comprising: (a) setting up a data pool for selective access by a plurality of users;

(b) defining data fields within the data pool such that certain users have access to particular data fields at certain times during operation of the business process; and

(c) defining states and state transitions for the business process, the states and state transitions allowing for selective distribution at pre-defined times of information in the data fields relating to the business process.

15. An apparatus for defining an interactive business process for a plurality of users, the apparatus comprising: a processor in communication with a memory device, the processor operative with a program on the memory device to: accept definition instructions from a user to set up the business process, including accepting rules, accepting roles to be taken by system users, and accepting data fields to contain information for the business process, wherein the definition instructions allow the user to create a user-definable business process, and wherein the accessability of certain information within the data fields is a function of time and system user authority.

16. The apparatus of claim 15, wherein the program accepts assignment instructions from the user to assign the roles to specific system users.

17. A method for performing a business process, the method comprising:

(a) providing accessibility to system users via a network interface to a central system containing user-defined instructions for the business process;

(b) pooling business process-related data from one or more system users in the central system; and

(c) selectively providing availability to system users to information from the pooled data, wherein the act of selectively providing availability involves determining which information is available to each system user as the business process transitions from one process state to another process state.

18. The method of claim 17, further comprising allowing certain system users to write information to the pooled data when the business process has transitioned to certain process states.

19. The method of claim 18, further comprising providing alarms to certain system users when such system users need to act to transition the business process from one state to another state.

20. The method of claim 18, further comprising providing state information and role information to at least one system user during operation of the business process.

21. A system for performing a business process, the system comprising: a computer readable program code having instructions for:

22. A system for defining a user-definable business process, the system comprising: a computer program having instructions for: interactively soliciting and receiving from a user instructions to define a document representing the user-definable business process, the document setting forth data fields, states, roles, state transitions, and rules that set forth the operation of the user-definable business process.

23. The system of claim 22, wherein at least one of the data fields may be accessed by at least one system user depending on the state of the business process.

24. A method for automating communications between business users involved in a business process, comprising:

(a) pooling business process-related data from one or more business partners; and

(b) selectively providing access to one or more user of the pooled data, wherein the act of providing access further comprises selecting the data within the pooled data that may be accessed by each user.

25. An apparatus for automating communication between business users involved in a business process, comprising:

(a) a computer system having memory for storing data related to a business process and for storing communications between users in an electronic format, wherein the computer system is adapted to be accessed via the internet and wherein the system facilitates communication between users; and

(b) computer instructions operable by a processor in the computer system, wherein the computer instructions enable at least one user to define a business process via the internet, pool business process related data based on the user defined process, and distribute to each user selected information from the pooled data.

26. An apparatus for automating communication between business partners/users involved in a business process, comprising:

(b) computer instructions operable by a processor in the computer system, wherein the computer instructions enable at least one user to define a business process via the internet, pool business process related data based on the user defined process, and provide access to users to selected information from the pooled data.

27. A method for conducting interactive business processes that require electronic data exchange among a plurality of system users, the method comprising:

(a) interactively defining processes, rules and roles to be taken by the system users;

(b) interactively defining a document having data fields and owners of the data fields such that the document may be accessed by various system users during operation of the business process;

(c) distributing information in the data fields to authorized system users, wherein the information is filtered prior to distribution;

(d) tracking business processing and information as the business process is carried out; and

(e) updating process status and information as the business process is carried out.

28. The method of claim 27, wherein information distribution is conducted over the Internet.

29. The method of claim 27, wherein each system user is defined as a primary user, a secondary user, an end user, or a transit user.

30. The method of claim 29, wherein the primary user is responsible for performing acts (a) and (b).

31. The method of claim 30, wherein a primary user may have to consult with an end user in order to create and define the business process.

32. The method of claim 29, wherein the secondary user has limited authorities in the business process as defined by the primary user.

33. The method of claim 32, wherein the secondary user is created by the primary user.

34. The method of claim 33, wherein there may exist more than one level of secondary users within the primary user.

35. The method of claim 29, wherein the end user does not belong to any other system user.

36. The method of claim 29, wherein the transit user does not belong to any other system user, and wherein the transit user may participate in the business process only if the business process is accessible to the public.

37. The method of claim 27, wherein acts (a) and (b) are performed by a primary user.

38. The method of claim 27, wherein acts (a) and (b) are performed by a secondary user with authorization from a primary user.

39. The method of claim 27, further comprising dynamically on-line searching for information related to the business process.

40. The method of claim 27, further comprising dynamically sending alarming signals to authorized users.

41. The method of claim 27, wherein the system users communicate with a central system, and wherein each system user may only view the data fields in the central system that the system user is authorized to view.

42. The method of claim 41, wherein all of the information for the business process may be viewed and retrieved via Internet by all authorized users simultaneously.

43. The method of claim 41, wherein the central system comprises an interface section, a common function module, a foundation section, and a system infrastructure.

44. The method of claim 43, wherein the interface section interfaces with the users via the Internet.

45. The method of claim 44, wherein the interface section may communicate with internal network systems of the system users and perform internal management of the system users' business processing.

46. The method of claim 44, wherein the interface section registers new system users with the central system, verifies the system users when they log onto the system, and sends information to and from the central system and the system users.

47. The method of claim 44, wherein the interface section blocks unauthorized access to the central system from non-users and non-authorized users, and wherein the interface section processes definitions from authorized users.

48. The method of claim 43, wherein the common function module uses commercially available software to carry out functions for business processing and communication.

49. The method of claim 43, wherein the foundation section provides tools to carry out main tasks of the process.

50. The method of claim 41, wherein the central system is a modular system that is scalable to accommodate varying numbers of users.

51. The method of claim 27, wherein the act of interactively defining processes includes setting up the business process flow from a first state to a second state, setting up process states, identifying the users involved in the process, and assigning rules and roles to the users involved in the business process.

52. The method of claim 51 , wherein the act of interactively defining processes further includes authorizing information distribution and authorizing information screening, filtering and selection, and setting up alarm actions.

53. A method for evaluating a school admission application, the method comprising:

(a) electronically receiving the school admission application from a prospective student;

(b) providing accessibility to application reviewers via a network interface to a central system containing user-defined instructions for application evaluation; and

(c) selectively providing availability to application reviewers to information from the school admission application, wherein the act of selectively providing availability involves determining which information is available to each application reviewer as the application evaluation transitions from one process state to another process state.

54. The method of claim 53, wherein the act of selectively providing availability to application reviewers involves providing for a first level of review and providing for a second level of review.

55. A method for processing a purchase order, the method comprising:

(a) electronically receiving a purchase order from a buyer;

(b) providing accessibility to system users via a network interface to a central system containing user-defined instructions for processing the purchase order;

(c) providing the purchase order to a dealer, and allowing the dealer to submit a product order to a manufacturer;

(d) providing a shipping request for the purchase order to a trucker; and

(e) selectively providing availability to the buyer, dealer, manufacturer, and trucker to information in the central system, wherein the act of selectively providing availability involves determining which information is available to each system user at varying times.

56. A method for delivering a product, the method comprising:

(a) electronically receiving a request for product delivery from a merchant;

(b) providing accessibility to system users via a network interface to a central system containing user-defined instructions for processing the product delivery;

(c) providing product delivery information to a trucker, wherein the trucker is capable of delivering the product to a consignee; and

(d) selectively providing availability to the merchant, consignee, and trucker to information in the central system, wherein the act of selectively providing availability involves determining which information is available to each system user at varying times.