KR20030001369A - Method for workflow processing through computer network - Google Patents

Abstract

Computer systems use common communication networks, such as the Internet, to facilitate communication and business activities between a plurality of business entities. The system stores a plurality of business objects that define business activities between the parties. Each business object has a plurality of states, each representing a processing step. A group of work units define the functions performed on a business object and typically each work unit includes transitions between states of the business object. A series of business rules define the validity of work units for each state as well as constraints on the activities that can be performed by the business object. Preprocessing and postprocessing steps corresponding to the current environment are performed before and after each complete data file is stored in the system database. Like XML, defined file formats are used for data storage for internal processing and business transactions. The system may receive a standardized file format or convert any owner's file to a standardized format. Delivery to the recipient is done as a file in a format defined by the recipient. The output file may be in a standardized format or may be converted into a specifically required format associated with the recipient. New business objects can be added to the system to extend the range of business activities that can be supported. Since this is done in modules, any type of business activity and a wide range of businesses can be handled by the system.

Description

Workflow processing through computer network

Over the years, businesses have integrated computer systems into many essential parts of their internal operations. In most cases, the integration of such computer systems has substantially increased the productivity of the business. Businesses are enhancing computer operations by adding additional software and hardware to existing systems. This personal business development based on internal requirements has resulted in each business being highly developed and equipped with efficient internal computer operation, but this internal development has resulted in a business environment that greatly undermines business for business interaction.

As the business grows, the business generally adopts data formats and communication procedures that are not the same as those used by other businesses. When two business interactions occur, communication is frequently disrupted due to differences in the procedures and formats implemented by the two parties. Therefore, there is a need for processes and systems that will reduce problems caused by incompatible communication structures between the parties.

Another obstacle to business activity between the parties is that normal business behavior requires a series of transactions between the parties before the desired result is reached. In many examples, these transactions are performed by telephone calls, faxes, letters and email.

In view of these communication and business procedure problems that hinder commerce, there is a need for processes and apparatus that not only efficiently handle business transactions in the required sequences, but also improve communication between incompatible formats. In addition, such a system must be able to accommodate growth, new business activities and new industries without modifying the basic operating structure by adding new information one by one defining the required communication and process.

Summary of the Invention

A selected embodiment of the present invention is a workflow processing method through a computer system among a plurality of users. The method begins with receiving an input data file having a plurality of units of data from a first user to initiate a transaction. One of the plurality of stored business objects is selected for a transaction. Each of the business objects includes a plurality of states, a plurality of work units each associated with at least one of the states, and a plurality of rules related to the selected ones of the states and the work units. The selected business object has one of the selected states at one time. Next, one of the work units is selected for the transaction. The validity of the selected work unit is determined with reference to one of the rules associated with the selected one of the states of the selected work unit and the selected business object. If it is determined that the selected work unit is valid, it performs the designated function for the selected work unit. The next step is to select a new state for the selected business object. Generate an output file based at least in part on the function performed for the selected job state. The final step is to make the output file available to a second user of the system. The second user is the recipient.

Other aspects of the present invention provide a complete business activity that is performed multiple times by repeating the method described above, the conversion of received files into a standardized format, the use of a standardized internal data format, and the output files in advance by the recipient. Includes conversion to selected formats. Another aspect of the invention includes pretreatment and postprocessing operations.

FIELD OF THE INVENTION The present invention relates generally to business communications, and in particular to the processing of business transactions between a plurality of parties.

1 is a schematic diagram of a data communication network connected to a plurality of users and also connected to a system for processing transactions in accordance with the present invention.

2 is a schematic state diagram of a sample business object.

FIG. 3 is a table defining the functionality for the business object shown in FIG. 2 listing states, work units, rules, preprocessing steps, and postprocessing steps associated with the business object.

4 is a flow diagram illustrating an example of a processing step incorporating the present invention.

5 is a transaction schematic diagram illustrating processing steps of a transaction in relation to a particular file type and processing operation.

6 illustrates a particular example of a business object, ie, a flood order, comprising a plurality of states and a plurality of defined work units.

FIG. 7 is an information table defining the business object shown in FIG. 6 including states, work units, rules, preprocessing steps and postprocessing steps.

8A and 8B are detailed flow diagrams illustrating an implementation of the present invention.

9A and 9B are transaction explanatory diagrams of examples of the present invention that include three stages of processing of specific data types, transformations, processing, and file delivery.

FIG. 10 shows an example of the owner's text format for an example flood order. FIG.

FIG. 11 illustrates an example of a RealXML file used in the practice of the present invention for a new flood order.

12 shows an example of an owner's X.12 format file delivered to a vendor for a new flood order.

FIG. 13 shows an example of an owner format file received from a vendor in response to receiving the output file shown in FIG. 12; FIG.

FIG. 14 shows an example of a schematic state diagram of a business object for claims processing. FIG.

FIG. 15 is a table defining functions for the business object shown in FIG. 14 listing states, work units, rules, preprocessing steps and postprocessing steps.

The present invention relates to a computer system and method for processing business transactions between a plurality of parties. A computer network 20 for implementing the present invention is described with reference to FIG. The present invention operates with a communication network 22, which may be, for example, the Internet, a public switched telephone system, or any other communication system. The network 20 includes a plurality of network terminals 24, 26, 28, 30. The main functions performed by the present invention are executed by processors in the computer system 36 connected to the communication network 22. System 36 is connected to communication network 22 through a firewall. System 36 also includes a web server 48, a database server 42, a REALMonitor server 44, an SNA server 46, and an FTP server 48. The servers 38, 40, 42, 44, 46 are connected to each other by a network 58 such as a local area network (LAN) or the like.

The present invention can be implemented in any desired configuration of servers and any distribution of functions contained centrally in one or a few servers or widely distributed across many processors.

In one implementation of the invention, terminals 24 and 26 may be used by lenders of a real estate environment, and terminals 28 and 30 may be used by service providers to lenders. .

The present invention encompasses a method for processing transactions and providing communication between entities involved in a business activity. For example, the lenders in terminals 24 and 26 require a service provided by the providers of terminals 28 and 30. In this real estate environment there may be hundreds of entities corresponding to the lenders. In most cases, each of these entities has its own formats and information definitions that do not match the formats and information definitions of other entities. Another aspect of the invention is the processing of transactions to perform the necessary functions to enable the necessary transactions between the parties. Although the present invention may be used for retailers and customers as well, it mainly applies to the provision of transactions between business entities.

An important term used in connection with the present invention is the term "business object". A business object is defined as a business process of multiple functions that are related to each other, and the process has a plurality of states but in only one state at a time, with restrictions on what functions can be performed in each state. Constraints are referred to herein as business rules. A business object includes one or more work units that define specific functions within the business object. In selected embodiments, the business object is implemented as a program "object" using an object oriented programming language. Such programming languages include C ++ and Visual Basic. In general, object-oriented programming is described in Copyright 1994, Grady Booch's "Object Oriented Analysis and Design With Applications", 2nd edition, published by B. Benjamin / Cummings Publishing. Include this booklet for reference here.

Business objects referred to herein may be implemented in non-object oriented programming languages but still include the same structural elements and operations as described herein. Business objects primarily describe the context of business interactions between the parties, and are not models of the inner workings of individual businesses.

General examples of business objects called "business objects # 1" are shown in FIGS. 2 and 3. In FIG. 2, business object # 1 (BO # 1) has five states, 70, 72, 74, 76, and 78, representing states A, B, C, D, and E, respectively. One of the states of business object # 1 has a functional action 80 associated with state 72 (B).

Business object # 1 is the work units 82, 84, 86 represented by WU # 1, WU # 2, WU # 3, WU # 4, WU # 5, WU # 6, and WU # 7 in Figs. , 88, 90, 92, 94).

As shown in FIG. 3, defined system functions are maintained in data storage 98, such as system memory or disk. Storage 98 includes block 100 indicating that it is business object # 1 and indicating that it has states A, B, C, D, and E. Each state represents a stage in the processing of a business object. Storage 98 includes block 102 representing work units # 1 through # 7 (82-94) associated with business object # 1. Each work unit also includes a definition of its specific functionality.

As shown in Fig. 2, WU # 1 82 defines the function of transition between state A and state B. WU # 2 84 defines the function of the transition of states B and E and WU # 3 86 defines the function of the transition of states A and E. WU # 4 88 defines the function of the transition of state A and state C and WU # 5 90 defines the function of the transition of state C and state E. WU # 6 92 defines the function of the transition of state C and state D, and WU # 7 94 defines the function associated only with state B of business object # 1.

Storage 98 for business object # 1 also includes block 104 containing a set of rules represented by R # 1, R # 2, R # 3, R # 4 associated with business object # 1. . The rules define the requirements and restrictions on what can be done in the corresponding business object. Each rule is defined with respect to a specific environment. As shown, R # 1 is associated with state A of business object # 1. R # 2 is associated with WU # 1. R # 3 is associated with state B and current WU # 2, and R # 4 is associated with state C. However, the work units and rules in blocks 102 and 104 are specifically related to business object # 1 and its defined states.

Storage 98 also includes a group of pre and post processing steps shown in blocks 106 and 108. Block 106 illustrates processing steps # 1 and # 2. Each processing step has a defined association with entities in storage 98 and is associated with one of the business objects defined in storage 98.

In the present invention, a party involved in sending or receiving a communication is referred to as a user. Specifically, the user initiating a transaction is called the initiator and the person receiving the results of this transaction is defined as the recipient. Specifically, as shown in FIG. 1, an example of an initiator is a lender and an example of a recipient may be a service provider or a vendor. However, when the service provider has begun work, the service provider may be the initiator and one of the lenders may be the recipient.

As shown in FIG. 3, each processing operation is defined for a specific environment of a specific business object in the storage 98 and includes a specific function. In storage 98, preprocessing step # 1 is implemented for WU # 1. Likewise, all other defined preprocessing steps in storage 98 have a defined environment and defined functionality.

In most cases, preprocessing steps are defined for a particular entity. Post-processing steps are generally defined for specific entities.

Similarly, there are post processing steps within block 108. Likewise, each post-processing step corresponds to a specific business object and has a defined environment and defined functions. When a defined environment exists for a particular post-processing entity, the corresponding function is performed for that entity.

The storage 98 shown in FIG. 3 may include a significant number of business objects. To each of these objects work units, rules, preprocessing steps and postprocessing steps are associated. As shown in this figure, business object # 2 has states A, B, and C. This business object is associated with a block 118 that defines work units, a block 114 that defines associated rules, a block 118 for associated preprocessing steps and a block 120 for postprocessing steps. Preprocessing and postprocessing steps may not exist for all business objects.

1, 2, and 3, a business object such as # 1 is defined for a particular relationship that may occur between any two of the users set up in the system 20. The storage 98 is included in the system 36, in particular in the server 42. System 36 stores a plurality of business objects as shown in FIG. 3 so that a significant amount of business transactions can be made between users. For each business object, it includes defined work units, rules, and any associated preprocessing and postprocessing steps.

When a user, such as the owner of terminal 24, acts as an initiator and starts a transaction, it sends an input file through network 22 to system 36. With this file described below, a business object is selected and a series of steps defined by this selected business object are performed by the system 36 as shown in FIG. In general, receiving a file from an initiator causes a business object to transition from one state to another after a given state, for example state A, is set for the selected business object or after functional operations are performed. In many cases, communication is sent to the recipient when a state is fulfilled or created. In general, the processing of a business object continues to receive file communications from users and each is involved in transitioning between states of the business object. This continues in most cases until an end object is reached that indicates the completion of the business activity between the two parties, but may indicate the end of the activity before completion.

The data structure associated with the present invention as shown in Figures 2 and 3 provides a definition and modularity that enables efficient and economical realization of a wide range of business transactions between a large number of users. System 36 may be extended in increments to add additional business objects as needed by users of the system. A big advantage of this approach is that entirely new types of business activities and new types of data formats can be included as defined elements in business objects, and each industry can build a specific system for each type of business transaction, It may be added to the storage 98 of the system 36 without having to design the systems specifically for the unique data formatting and communication techniques used by a particular business in the industry.

A basic flow diagram illustrating the processes of the present invention is shown in FIG. This is also described with reference to FIGS. 1, 2 and 3. In a first block 132, the system 36 receives a user input file (IDF) from the lender having an initiator, for example, the terminal 24 shown in FIG. At block 134, system 36 reads the input data file and selects the specific business object specified for that file. This corresponds to the business objects previously recorded in the storage 98 as shown in FIG. The file also includes the specific data used by the system 36 at block 136 to activate the selected business object to create an instance of that object.

As shown in block 138, the system 36 examines the input data file, or the folder in which it is stored, to determine the designated work unit to execute in the current transaction.

The business process used herein typically includes a plurality of transactions, each of which generally corresponds to one of the states of the business object. The flowchart shown in FIG. 4 illustrates the processing of one transaction occurring within a business object.

In block 140 the system 36 determines by examining the storage 98 whether any preprocessing steps are to be realized. If so, the function corresponding to each of these preprocessing steps is performed. The preprocessing step is mainly to obtain additional data. Next, at block 150, system 36 performs the defined function for the selected work unit.

After the specific function for the selected work unit is performed, at block 152 the system 36 is not only in the input data file received from the user, but in addition to any additional information and data generated during preprocessing and performance of the selected work unit. Load a file containing all relevant pieces of information into the database.

At block 154, the system performs a defined post processing associated with the current environment that exists upon entering this block. The transaction may require the generation of some output, which is performed at block 156, and the output is sent to the recipient designated at block 158.

The post-processing phase is usually a confirmation that something has been fixed or the work has been performed.

In general, the transaction as shown in FIG. 4 processes the transition from the initial state of the business object or from one state to another within the business object. The resulting state may be an intermediate state that will lead to the next transitions, or it may be an end state indicating completion of the functions required for a particular business object. Preprocessing may not be performed in all transactions and likewise postprocessing may not be performed in all transactions.

Examples of the present invention have been provided within the context of the processing of real estate transaction documents. The setting includes a number of lenders who pay loans corresponding to real estate and service providers that provide specific services needed in the real estate sector. An important aspect of this example is that both users, namely requesters and recipients, will use different formats in their businesses to perform real estate functions. At present, such incompatibility limits the processing of real estate activities, but such problems can be addressed within the present invention. Over time, it is possible that some industries, such as the real estate industry, will reduce this problem by standardizing on activity formats for files. In this example, the lender's customer, such as associated with terminal 24 shown in FIG. 1, requested a loan to purchase a particular asset. In this example, the lender, called the initiator, must perform multiple activities before he can approve the loan on the asset. One step in the process that represents this example is a judgment made by the lender about the status of the asset in relation to the flood. This decision is frequently an important step in the loan evaluation process. To answer these questions, the lender submits what is called a "flood order" to determine the flood rating status for a particular asset. There are many different service providers (vendors) in the United States who provide this information. Some vendors only work in certain regions, and national vendors may only work with certain lenders rather than all lenders. Because many lenders work nationwide, the processing of a single flood order can be relatively complex in the context of thousands of flood orders being processed.

In the following description of the present invention, a transaction schematic is shown in FIG. 5 for the processing of such an order, in a wide range, which may be a flood order of the present example. The transaction schematic of FIG. 5 has three steps. These are the input and transform stage 168, the transaction processing stage 170, and the transform / output / deliver stage 172. In this example, the lender is referred to as the initiator (I). In FIG. 5, the initiator places an order, such as a flood order, at step 168. The initiator sends a file from its terminal 24 to the system 36 via the network 22. This may be a file 174 in an owner (original?) Format or an XML file 176. The received owner file is placed in one of a set of folders reserved for a particular initiator. The initiator places the owner file in a specific folder associated with a particular work unit and business object for the required work.

If the file is in the owner's format, it is processed by the converter 178 to generate the XML file 180. File 176 corresponds to file 180.

In this real estate processing example, a standardized file format using XML (Extesible Mark-up Language) was selected. More details on XML are described in the February 10, 1998 "XML 1.0", W3C Recommendation (page 41), which is incorporated herein by reference. XML describes a class of data objects, called XML documents, and in part describes the behavior of computer programs that process them. XML is in the Standard Generalized Mark-up Language (SGML) format specified by ISO 8879, and a specific structure for XML document files was chosen to define the data needed for real estate processing associated with defined business objects. The non-XML files are converted into standardized XML files for processing in system 36.

In step 170 of FIG. 5, the business object defined by the data in the file submitted by the initiator for the formatted XML file is selected. Business objects are defined by folders for owner files. The initiator selects the appropriate folder. For each transferred file (transaction) a work unit is also identified. The unit of work is specified in the XML file but is reassigned by the folder selected for the owner file. This is handled within step 170 by the business logic processor 182. This is done in conjunction with the database 184 of the system corresponding to the storage 89 shown in FIG. The database 184 includes the business objects and associated work units and rules described above with reference to FIGS. 2, 3, and 4. Preprocessing step 186 is primarily performed according to the current environment to collect additional information. After preprocessing step 186 is completed, current file information is stored in database 184. Next, post-processing is performed as determined by the current environment.

As a result of the processing performed during transaction processing step 170, an XML file 190 is created. In this example, order delivery is needed to the selected recipient. If such a recipient uses the XML standard format, the file 190 is delivered via a transfer 192 and to the recipient R, the service provider of choice in this example, by FTP (File Transfer Protocol) method or via email. Delivered.

If the selected recipient does not use a standard XML file, file 190 is provided to converter 194 to create an owner format file 196 that is sent to the selected recipient by FTP or email. In this example, the document provided to the recipient is a flood order that confirms the flood order request, asset identification, initiator, and all other necessary information in a format compatible with the recipient. At this point, it is the recipient's duty to provide a response. This step defines a particular vendor as the initiator T in accordance with the present description.

Continuing the example of a flood order, we define business object # 7 representing the flood order business processing with reference to FIGS. 6 and 7. Flood order processing (business object # 7) has states 220, 222, 224, 226, and 228 that are states A, B, C, D, and E, respectively, for this business object. Business object # 7 is the work units 234, 236, 238, 240, 242, corresponding to WU # 1, WU # 2, WU # 3, WU # 4, WU # 5, WU # 6, WU # 7, respectively. 244, 246). In FIG. 6, Flood Order Business Object # 7 has a state 220 (A) indicating a state of a new order by the requestor. This is performed by work unit 234 (WU # 1). When the vendor has performed the operations necessary for confirming the receipt of the order, i.e., executing work unit 236 (WU # 2), business object # 7 goes to state 222 indicating " order confirmation ". In this state, it may be necessary for any one of the users to attach the document to the current file. This is accomplished by executing work unit 246 (WU # 7). Execution of this work unit does not transition the business object from one state to another, but rather modifies information established for a given state, which in this case is a document attachment to a file.

In general, the counterpart may execute a work unit by sending a file to the system 36 that identifies the work unit or a file in a folder that identifies the selected business object and work unit.

The vendor may not be able to process the requested order or may not want to process the requested order. If this happens, the vendor executes this work unit 238 (WU # 3) by sending a file that references the work unit to the system 36 and the business object is moved to the exit state 224. This is the "Reject Order" state. In this state, the requester is notified that the order has been rejected and business object # 7 has finished processing.

The vendor may complete the order with the exit status 226 of business object # 7 by executing the work unit (WU # 4) and returning all information needed for the flood order to the requestor.

The work unit 242 may only be executed when in the state 222 that allows the requestor or vendor to cancel the current order. If either party has executed this work unit, business object # 7 transitions to exit status 228 (E) to terminate the processing of business object # 7. Another cancellation choice is for the requestor to execute the work unit 244 (WU # 6) to bring the business object to the exit state 228 to cancel the order established in state 220.

In FIG. 7, the system of this example includes a storage unit 252 that includes a plurality of business objects and specifically defined business object # 7. As shown in storage 252, there is a block 252 for identifying a particular business object BO # 7 and the states of this business object.

7 illustrates business object # 7 defined in block 254, work units defined in block 256, rules associated with business object # 7 defined in block 258, and defined in block 260. Storage 252 with pre-processing steps, and if-post-processing steps defined in block 262. There may be any number of business objects in storage 252 that precede or follow business object # 7.

In business object # 7 of FIG. 7, WU # 1 relates only to state A of business object # 7. This is a work unit for a new order. In FIG. 5, this is a transaction processing step 170 followed by delivery of the XML or owner's file to the system 36 by the requestor through a step 172 of delivering to the recipient in a predefined format for receipt by a particular vendor. It includes sending. In general, with the execution of a work unit, a new state is established for executing the current business object, such as business object # 7 shown in FIG. 6, as a result of one pass from left to right through the transaction schematic shown in FIG. do.

WU # 2, in FIG. 5, represents the process of confirming receipt of an order by the vendor, in which case the vendor becomes the initiator, and WU # 2 in this transaction steps 168, 170, for delivery to the majority recipient. Send the file via 172). Accordingly, business object # 7 transitions from state 220 (A) to state 222 (B) of order confirmation. The file submitted by the vendor refers to an instance of the specific business object # 7 that is executed.

WU # 3 represents the process of rejecting an order by a vendor. In this case, the vendor is the initiator (FIG. 5) that sends the formatted file processed through steps 168, 170, 172 to provide the recipient (the lender) with information indicating that the particular order has been rejected. Accordingly, business object # 7 goes from state 220 (A) to end state 224 (C).

In FIG. 7, WU # 4 represents a function for transitioning from state B to state D. FIG. Execution of this work unit involves sending a file from the vendor from left to right through the process described in the transaction schematic in FIG. 5 to provide the order completion in the appropriate format to the recipient (the lender). As a result, business object # 7 changes to the completion state 226 (D) of the order completion.

WU # 5 may be initiated to cancel an existing confirmed order by the requestor or vendor. As a result, the state transitions from the state 222 (B) to the state 228 (E).

WU # 6 is the act of canceling an order by the requestor before it is rejected by the vendor or confirmed by the vendor. As a result, the state transitions from the state 220 (A) to the end state 228 (E).

WU # 7 does not perform the function of transitioning from one state to another in Business Object # 7, but instead represents the ability to attach a specific document to an ongoing flood order so that users can refer to it.

In FIG. 7, rules representing the constraints on functions and activities that may be performed with respect to business object # 7 are listed. The rules related to this particular business object are described below.

R # 1 indicates that the only valid work unit is WU # 1 when an object instance does not exist and needs to be created.

R # 2 indicates that the only valid work units for state A are WU # 2, WU # 3, and WU # 6.

R # 3 indicates that the only valid work units for state B are WU # 4 and WU # 5.

Business object # 7 may also include preprocessing # 1 steps that occur in the environmental conditions of the transaction to perform data manipulation functions to achieve changes in the current business object context prior to executing the unit of work to achieve the necessary business logic. have. Preprocessing step # 1 for the reproduction of work unit # 1 is to verify the address for the order. Preprocessing step # 1 for work unit # 1 is to select a vendor using a predetermined process established by the lender.

In block 262 post-processing step # 1 is performed when certain environmental conditions of a "transaction" have been reached. This environment is the occurrence of work unit # 4. This post-processing includes an electronic funds transfer (EFT) operation to pay for the flood order.

A detailed processing flow illustrating an example of the present invention is shown in FIGS. 8A and 8B, further illustrating an example flood order.

Following start block 276, go to block 278 to detect if there is an input file in the initiator's folder. In block 280, a query is made to determine if the format of the received file is XML, which is the configuration previously determined. If the answer is yes, then go to block 282 and examine the received file to determine the particular business object identified within the file. The XML file specifies a business object and the folder holding the owner's file corresponds to the selected business object and work unit. This business object corresponds to one of the business objects in the system store, such as 252 in FIG. In this example, the selected business object is business object # 7. Continuing with FIG. 8A, if the answer is no at block 280, go to block 284 and convert the received file to the desired XML format. This is done by the converter 178 shown in FIG. Block 284 is followed by block 282.

Following block 282, block 286 is executed to configure or activate a particular instance of the selected business object determined at block 282. Continuing to block 288, the input file is further examined to determine which work unit associated with the selected business object has been selected. This corresponds to one of the defined work units, such as block 256 in FIG. 7. The work unit is specified in the original XML file and corresponds to the file folder for the original owner file.

At this time, the system 36 received the input file from the initiator, selected the business object specified in the file, activated the business object, and determined the work unit designated by the initiator. Then go to block 290 to determine if the specified work unit is valid for the current state of the business object. This state is determined by business rules associated with the selected business object, such as business rules as defined in block 258 of storage 252 in FIG. If in execution of block 290 it is determined that the current work unit is not valid for the current state, a no message is taken and an error message sent to the initiator at block 298 is generated and then proceeds to end block 300.

If it is determined that the current work unit is valid in the execution of block 290, an example is taken and go to block 296 to determine which preprocessing steps are to be performed. Compare the current environment with the defined preprocessing step environment listed at block 260 of FIG. If any of the listed preprocessing step environments match the current environment, an example is taken and go to block 302 to perform the specified one or more preprocessing steps. If the current environment does not match any of the pre-stored environmental conditions, a no is taken to go to question block 304. Block 304 corresponds to another one of the rules in block 258 that define the validity of the data present in this processing step. If it is determined that there is invalid data at this point, a NO is taken to go to block 306 to generate a suitable error message and send it to the initiator, and to end block 308.

The validity of the data is determined by a set of rules for certain types of data. For example, the data field for a ZIP code must have exactly 5 or 9 digits and no alphanumeric characters. A flood class, which may be A, B, or C, may not have any other characters, but only one character. For reports with flood risk, there should be text in the comment field.

If the data is determined to be valid at block 304, an example is taken and the block goes to block 310 to perform the requested functions associated with the designated work unit. This includes the actions performed by the business logic processor 182 (FIG. 5) defined for the business work unit.

Following block 310, go to question block 312 to determine if there is a change in status for the selected business object. If so, an example is taken and block 314 is set to the new state of the business object. This corresponds to specifying a new state of the business object as shown in FIG. At block 312, if no change is needed, a no is taken to question block 316. In this block, determine what type of delivery is required to the recipient, such as a file. If such a delivery is needed, an example is taken to go to block 318 to determine the format required for delivery, and to block 320 to determine a delivery mechanism for delivery such as FTP or email. Next, go to block 322 to perform the currently defined transaction delivery in terms of format and mechanism. After block 322, go to question block 324, which is entered even if a no response is made at block 316.

At question block 324, a query is made to which of the post-processing steps listed in block 262 of FIG. If the answer is yes, go to block 326 and perform the specified post-processing steps. If no, no is taken to block 328, which may then enter block 326 next. In block 328, if confirmation is needed for the initiator at this stage, such confirmation is generated and any generated confirmation is sent to the initiator. Finally, go to end block 330 to complete this transaction, which in most cases results in a transfer of status for the currently selected business object.

Continuing the example of a flood order, reference is made to FIGS. 5, 6, 7, 7, 8A, and 8B. Assuming the requester has submitted a new order (FIG. 6) to execute work unit 234, business object # 7 will be in state 220 (A). In this state, the vendor is notified that the order has been placed and has specific data about the order. In this case, the initiator may be a requestor or a vendor as defined in business object # 7 (FIG. 6). In this example, if the vendor wants to confirm the order, the vendor will be designated as the initiator in the next transaction and will send the input file as shown in step 168 of FIG. 5 to a folder corresponding to that particular vendor. System 36 then executes block 278 of FIG. 8A to detect the input file and then determine if the file is in the correct XML format of block 280. Otherwise, the transform step will be performed at block 284 by the converter 178 shown in FIG.

In step 282, a determination is made on the business object identified in the input file from the initiator (in this case the vendor). This identifies an existing business object that was previously selected and activated. Step 286 goes to step 288 to determine the work unit specified in the input file received from the vendor. In this example, this would be WU # 2 in block 256 shown in FIG. In block 288, the rules for business object # 7 will be referenced to determine if this work unit is valid in this state. Rule # 2 shows that this work unit is valid in this state. An example is taken from block 290 to determine which preprocessing steps should be executed. In the current environment there are no such preprocessing steps and NO goes to block 304 to determine if all existing data in the file under processing is valid. If the data is valid, an example is taken and goes from block 304 to block 310 to perform the selected work unit, WU # 2 (FIG. 7). This is done by sending an XML file, possibly converted, received as file 190 from business logic processor 182.

After the file format required by the recipient (in this case the lender) is determined, it goes to a file transfer block 192 (FIG. 5) or a converter 194 that creates an owner file or delivers an existing XML file. The sending mechanism of FTP or e-mail for a particular recipient is also determined and a file suitable for the recipient is sent.

In FIG. 8B, go to question block 312 to determine if a state change is needed for the current business object, in this example, business object # 7. In this example, if the answer is yes, then go to block 314 and change the state of business object # 7 in processor 182 from state 220 (A) to state 222 (B). This is the order confirmed to the lender.

Also in FIG. 8B, blocks 316-322 are processed for file delivery to the recipient (the lender) after selecting the format and mechanism.

In a next step go to block 324 to determine what post processing steps are needed. This is done by comparing the current environment with the post-processing steps listed in block 262 of FIG. If there is a match, an example is taken and the block goes to block 326 where the designated post-processing steps are performed. In the present state no post-processing steps are necessary. Finally, at block 328, a confirmation is sent to the initiator that is the vendor in this case that the order confirmation is complete.

More details of the examples of the invention described with reference to the flood example are shown in FIGS. 9A and 9B in addition to FIGS. 10, 11, 12. The described example relates to the real estate industry and in particular to the processing of a "flood order" by the lender to determine if the designated asset has a flood rating. The system shown in Figs. 9A and 9B is divided into three stages. These are the input and conversion step 352, the order processing step 354 and the output and delivery step 356. One method of input to the system is via web clients 358, 360, 362 which are part of the web farm 364 which communicates in a conventional manner to the web server 366 which is part of the system 36.

The files can be sent to any one of many technologies to the system server. These include a TransXML file 368, an X.12 file 370, and a file 372 in owner format. The web server 366 operates in conjunction with the program 382 to generate the specified format XML files that are sent as the RealXML file 384.

Files 368, 370, 372 are put on the server in folders corresponding to the selected work units for the respective initiator and owner files. These are monitored by the program REALMONITOR 386. REALMONITOR 386 checks the format of the file, transfers the preformatted XML file 368 directly to the RealXML file 384, and transfers the X.12 file to the converter 388. The converter 388 then provides the file 384 and sends the owner file 372 to the converter 390 so that the converter 390 generates the resulting XML file 384.

However, the present invention is not limited to this one karma, but can generally be applied to business processing between a plurality of entities in any karma.

RealXML file 384 is an XML file 391 in a defined format that is input to a program 392 called "RealXMLDb". This is the object program associated with the defined XML file. Program 392 operates in conjunction with a database 394 that stores not only the current XML file but also system functions as shown in FIG.

Program 392 performs optional preprocessing steps 396 and 398 using data stored in database 394. When these steps are completed, the current state of the formatted XML file is stored in the database 394.

RealXMLDb program 392 then performs the specified work unit in the received file and, if necessary, performs order delivery 400 which includes access to the REALDelivery object program 402 (FIG. 9B).

In FIG. 9B, the program 402 (REALDelivery) generates and transmits a RealXML file 416 or executes an exporter program 418 in response to a recipient's request. RealXML file 416 is transmitted via TranXML export operation 420 to deliver TransXML file 422 to the designated recipient.

If the designated recipient has specified that they will receive the files in the X.21 file format, the exporter 418 sends the existing RealXML file from the program 402 to the converter 423 to generate the X.12 file 424. .

If the designated recipient has specified an owner format, then the exporter 418 sends the standardized XML from the program 402 to the owner format converter 426 which generates the owner format file 428.

The owner's format file 372 for the flood order example is shown in the detailed example in FIG. The formatted XML file 391 is shown in the particular embodiment in FIG. 11. The X.12 file 424 is shown in detail in FIG.

The processing of the example flood orders described above will be described in more detail with reference to FIGS. 9A, 9B, 10, 11, 12. In this example, the lender, such as a bank, sends a flood order to the system by submitting a text file in its predefined layout. This text file is the owner format file 372 shown in FIG. This file is sent through the TFT to the designated input folder of the pillar on the system TFT server as shown in FIG.

The REALMONITOR program 386 detects that the file of interest is in a specific folder in the server and moves the file to the processing folder. The program 386 examines the file, detects that the file is in owner text format, and converts the text file 372 of the subject text file 372 into a RealXML file in the specified format used by the system. Call the appropriate translator object. The generated XML file is the file 391 shown in FIG. File 391 has a unique identification that represents a particular instance of a selected business object.

This file is then sent to the RealXMLDb program 392 where it determines that the file belongs to the submitted lender and invokes the particular program (objects) containing the necessary preprocessing steps for this particular lender's flood orders. . One preprocessing step is that when this particular lender places an order for the flood, the system will automatically select a vendor from the list of approved vendors. This is based on a set of rules previously provided by the lender. When the preprocessing is complete, the specific vendor that receives the order is specified. After the preprocessing is complete, the order file is loaded into the system database 394.

After the file is loaded, RealXMLDb program 392 examines the postprocessing steps specified for this particular lender and this particular type of order. This particular lender stated that one post-processing step would automatically place a credit report order upon completion of the flood order.

The main function to be performed by the submission of a flood order is to submit the order to the selected vendor. This is the function specified for the work unit in file 372. The RealXMLDb program calls the order delivery program 400 to perform the following steps necessary to complete the delivery. The order delivery program 400 checks the database 394 to determine which format and which transfer mechanism the selected vendor requires for new orders. In this example, the selected vendor prefers that the X.12 format be used for flood orders and that the order be placed in an output folder in the system FTP server 48. The delivery program 400 calls the converter 422 to convert the file to the desired format (X.12) for the selected vendor. The converter 422 stores the selected vendor's file 424 in the vendor's output folder of the FTP server 48, making it available to the vendor. The vendor may also specify that it will be sent directly to the vendor.

The owner's text format file 372 shown in FIG. 10 includes all the information needed by the vendor in issuing a flood status report for a particular asset. When this file is submitted by the lender, it is sent to a folder that corresponds to a particular work unit of a particular business object. In the example, this is the "new order" of the work unit in business object # 7 (order). System 36 identifies the business units and work units that are placed there by the folder.

In FIG. 11, file 391 is an example of a standardized XML file used in system 36 of the present invention. The business object is specified in the field "BO Name" as "Order". The work unit is specified in the "Work confirmation" field as "Create". Data elements for business objects are specified after the "tag name" fields. The file 424 shown in FIG. 12 is in a preprocessing format previously selected by the vendor. Part of this file is a unique identification that refers to a particular instance of the selected business object. This identification is the term "CESARG948321893652".

After the vendor picks up or receives the output file 424, the vendor can confirm that the order has been received by submitting an input file 430 as shown in FIG. 13. This file contains the identification number that was in the received file 424. This is the first line marked "Order Identification". System 36 uses the identification number in file 430 to associate a particular instance of the selected business object, which is business object # 7 in the example, to the file.

Although the present invention has been described with reference to the field of real estate transactions, it is equally applicable to communication and business activities between businesses in other fields and industries. The modular structure of the present invention allows the addition of business objects along with corresponding work units, rules, preprocessing and postprocessing steps when the system requires business activities for processing. The addition of another business object to the system 36 is shown in FIGS. 14 and 15. This example is for the processing of car insurance claims. Entities involved in this process include large insurance companies, insurance issuers, authorized auto repair shops, police and state car dealers. A series of transactions between multiple parties of these parties is necessary to process a car insurance claim. Business object # 248 for this processing is shown in FIG. 14 and the business object is shown in FIG. 15 along with its associated work units, rules, preprocessing and postprocessing.

Business object # 248 in FIG. 14 has states 440 (A), 442 (B), 444 (C), 446 (D), 448 (E), and 450 (F). Also, work units 452 (WU # 1), 454 (WU # 2), 456 (WU # 3), 458 (WU # 4), 460 (WU # 5), 462 (WU # 6), 464 (WU) # 7)).

In FIG. 15, storage 470 includes block 472 for identifying business object # 248 with specified states. Block 474 specifies the work units corresponding to business object # 248. Block 476 specifies rules associated with business object # 248. Block 478 describes the preprocessing steps associated with business object # 248 and block 480 describes the postprocessing steps associated with business object # 248.

After business object # 248 is ready, it is loaded into system 36 and the system can process input files from users to perform the function of this new business object. This illustrates the modular approach of the present invention.

In summary, the present invention provides a structure and process that reduces the cost and increased time to increase productivity by reducing the difficulty of communication and business processes between businesses.

While some embodiments of the invention have been illustrated in the accompanying drawings and described in the foregoing description, the invention is not limited to the disclosed embodiments and many rearrangements, modifications, and substitutions are without departing from the scope of the invention. It will be appreciated.

Claims (30)

In the workflow processing method through a computer system between a plurality of users, Receiving an input data file from a first user to initiate a transaction, the input data file having a plurality of data units; Selecting one of a plurality of stored business objects for the transaction, each of the business objects comprising a plurality of states, a plurality of work units each associated with at least one of the states, the states and A selection step comprising a plurality of rules related to selected ones of the work units, wherein the selected business object has one of the states selected at one time; Selecting one of the work units for the transaction; Determining a validity of the selected work unit with reference to one of the rules associated with the selected one of the states of the selected work unit and the selected business object; If it is determined that the selected work unit is valid, performing a designated function for the selected work unit; Selecting a new state for the selected business object; Generating an output file based at least in part on the function performed for the selected job state, and Making the output file available to a second user of the system. The method of claim 1, Performing a preprocessing operation to collect information related to the one business object prior to generating the output file. The method of claim 1, Performing a postprocessing operation for communicating information to a counterpart after said step of performing a function designated by said selected work unit. The method of claim 1, Storing data associated with the input file in a database. The method of claim 1, And wherein said business object is an object used for object oriented programming. In the workflow processing method through a computer system between a plurality of users, Receiving input data from a first user for a transaction, the input data file having a plurality of data units; Selecting one of a plurality of stored business objects for the transaction based on data in the input data file, each of the business objects having a plurality of states and a plurality of states each associated with at least one of the states; The selection step comprising a work unit and a plurality of rules relating to the states and selected ones of the work units, wherein the selected business object has one of the states selected at one time; Selecting one of the work units for the transaction based on data in the input data file; Determining the validity of the selected work unit with reference to one of the rules associated with the selected one of the selected work unit and states of the selected business object; Performing a designated function on the selected work unit if it is determined that the selected work unit is valid; Selecting a new state for the selected business object; Generating an output file based at least in part on the function performed for the selected job state, and Making the output file available to a second user of the system. The method of claim 6, And performing a preprocessing operation to collect information related to the one business object prior to generating the output file. The method of claim 6, And performing a post-processing operation of communicating information to a counterpart after said step of performing a function designated by said selected work unit. The method of claim 6, Storing data related to the input file in a database. The method of claim 6, And wherein the business object is an object used in object oriented programming. In the workflow processing method through a computer system between a plurality of users, Receiving an input data file from a first user for a transaction, the input data file having a plurality of data units and stored in one of a plurality of folders associated with the first user; Selecting one of a plurality of stored business objects for the transaction based on the folder in which the input data file is stored, wherein each of the business objects has a plurality of states and at least one of the states. The selection step comprising a plurality of work units each associated with and a plurality of rules relating to the states and selected ones of the work units, wherein the selected business object has one of the states selected at once; Selecting one of the work units for the transaction based on the folder in which the input data file is stored; Determining the validity of the selected work unit with reference to one of the rules associated with the selected one of the states of the selected work unit and the selected business object; If it is determined that the selected work unit is valid, performing a designated function for the selected work unit; Selecting a new state for the selected business object; Generating an output file based at least in part on the function performed for the selected job state, and Making the output file available to a second user of the system. The method of claim 11, And performing a preprocessing operation to collect information related to the one business object prior to generating the output file. The method of claim 11, And performing a post-processing operation of communicating information to a counterpart after said step of performing a function designated by said selected work unit. The method of claim 11, Storing data associated with the input file in a database. The method of claim 11, And the business object is an object used for object oriented programming. In the workflow processing method through a computer system between a plurality of parties, Detecting an input file from a first user, the input file being stored in one of a plurality of folders associated with the first user and the input data file having a plurality of data units; Generating a standardized format file using data from the input data file and information associated with one of the folders in which the input file is stored, wherein the generated standardized format file comprises: An identification of one of the stored business objects and an identification of one of a plurality of stored work units associated with the one business object, each of the stored business objects: (a) a plurality of states, wherein the selected business object has one of the states selected at one time; (b) a plurality of work units each associated with at least one of the states, and (c) said generating step comprising a plurality of rules relating to said states and selected ones of said work units, Performing a function associated with the one work unit, Changing the state of the one business object, Determining a file format selected for a second user to receive an output file for the transaction; Generating the output file in the selected file format using data associated with the business object, and Making the output file available to the second user. The method of claim 16, And performing a preprocessing operation to collect information related to the one business object prior to generating the output file. The method of claim 16, Performing a post-processing operation to communicate information to a counterpart after said step of performing a function designated by said selected work unit. The method of claim 16, Storing data associated with the input file in a database. The method of claim 16, And the business object is an object used for object oriented programming. A method for processing transactions between parties by use of a computer system, Receiving a first input data file from a first user to initiate a transaction, the input data file receiving a first input data file having a plurality of data units; Selecting a business object from a plurality of stored business objects, each of the stored business objects being: (a) a plurality of states, wherein the plurality of states, wherein the selected business object has one of the states selected at one time; (b) a plurality of work units each associated with at least one of the states, and (c) said selecting step comprising a plurality of rules relating to said states and selected ones of said work units; Selecting a first work unit of the work units, Performing a function defined for the first work unit, Setting a first state of the states as a function of the first work unit, Generating a first output file based on the selected business object; Making the first output file available to recipients; Receiving a first input file from the recipient; Selecting a second work unit of the work units in response to the first input file from the recipient; Changing to a second of said states as a function of said second work unit, Based on the selected business object, generating a second output file, and Making the second output file available to the first user based on the selected business object and the second work unit. The method of claim 21, And performing a preprocessing operation to collect information related to the selected business object prior to generating the output file. The method of claim 21, Performing a post-processing operation to communicate information to the counterpart after performing the function designated by the selected work unit. The method of claim 21, Storing data associated with the input file in a database. The method of claim 21, And the business object is an object used for object oriented programming. In a computer system for providing workflow processing between a plurality of parties, A communication system for sending files to and receiving files from the parties, A system storage having a plurality of business objects, each of the stored business objects, (a) a plurality of states, (b) a plurality of work units each associated with at least one of the states, and (c) said system storage comprising a plurality of rules relating to said states and selected ones of said work units, Receive an input file from the first of the parties via the communication system to associate one of the business objects with the input file, select one of the work units, and define for the one work unit. A processor for processing a specified function and for setting one of the states of the one business object, The processor is coupled to the communication system to make an output file available to a second of the parties, the output file being a function of the one business object and the input file. The method of claim 26, A preprocessing operation stored in the system storage and associated with a particular state of a particular one of the business objects. The method of claim 26, A post-processing operation stored in the system storage and associated with a particular state of a particular one of the business objects. The method of claim 26, And a plurality of translators for converting input files having certain formats into a standardized file format for use by the system. The method of claim 26, And a plurality of converters for converting the standardized file format used by the system into predetermined output formats.