JP2004502209A - Method of workflow processing via computer network - Google Patents

Abstract

A computer system that facilitates communication and business activities between multiple business entities using a common communication network such as the Internet. The system stores a plurality of business objects that define business activities between those skilled in the art. Each business object has a plurality of states, each representing a stage of processing. A group of units of work defines a function to be performed on a business object, and typically each unit of work includes a transition between states of the business object. A set of business rules defines the validity of a unit of work for each state, as well as restrictions on the activities that a business object can perform. Pre-processing and post-processing steps corresponding to the current environment are performed before and after the complete data file is stored in the system database, respectively. Defined file formats, such as XML, are utilized for internal processing and storage of data relating to business transactions. The system can receive a standardized file format or convert any proprietary file to a standardized file. Communication to the recipient is performed as a file in a format defined by the recipient. The output file may be in a standardized format or converted to a specially 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. This is done on a modular basis so that the system can handle any type of business activity or a wide range of business.

Description

[0001]
(Technical field of the invention)
The present invention relates generally to business communications, and more particularly, to the processing of business transactions between multiple parties.
[0002]
(Background of the Invention)
In the past few years, businesses have incorporated computer systems into many essential parts of their internal operations. In many cases, incorporating such computer systems has greatly increased enterprise productivity. Companies build computer operations by adding additional software and hardware to existing systems. This individual development based on internal requirements has resulted in a corporate environment in which each company has highly developed and efficient computer operations, but such internal development is B-to-B interactive. Is greatly impaired.
[0003]
As companies grow, they adopt data formats and communication rules that are generally not the same as those used by other companies. When two parties have the opportunity to interact, there are often communication barriers due to differences in regulations and formats enforced by the two parties. Therefore, there is a need for a process and system that reduces the problems caused by incompatible communication structures between the parties.
[0004]
A further obstacle to corporate activity between the parties is that a typical business operation requires a series of transactions between the parties before achieving the desired result. Often, these transactions are performed by telephone call, fax, letter, and e-mail. It is very inefficient for multiple parties to build one business activity schedule each time they need to work together.
[0005]
In view of these communication and business procedure issues that impede commerce, there is a need for processes and devices that enhance communication between incompatible formats and that efficiently process business transactions in the required order. I have. In addition, such systems allow growth, new business activities, and new business activities without changing the basic in-use configuration by adding new information that defines the required communications and procedures, step by step. It must be adaptable to the industrial sector.
[0006]
(Summary of the Invention)
A preferred embodiment of the present invention is a method of workflow processing between a plurality of users via a computer system. The method begins by receiving an input data file from a first user to initiate a transaction, the input data file having a plurality of data units. One of the stored business objects is selected for this transaction. Each of the business objects includes a plurality of states, a plurality of units of work each associated with at least one of the states, and a plurality of rules associated with each of the states and a selected one of the units of work. The state of the selected business object is selected one at a time. Next, one of the units of work is selected for the transaction. The validity of the selected unit of work is determined with reference to the selected unit of work and the selected one of the states of the selected business object. The function specified for the selected work unit is executed when the selected work unit is determined to be valid. The next step is to select a new state for the selected business object. An output file is created based on at least a portion of the functions performed on the selected unit of work. The final step is to make the output file available to a second user of the system. The second user is a recipient.
[0007]
Another aspect of the present invention is a method for converting a received file to a standardized format, using a standardized internal data format, and converting the output file to a format preselected by the recipient. Includes complete business activities carried out by. Yet another aspect of the invention includes a pre-processing operation and a post-processing operation.
[0008]
For a more complete understanding of the present invention and its advantages, reference is made to the following description taken in conjunction with the accompanying drawings.
[0009]
(Detailed description)
The present invention is directed to a computer system and method for processing a business transaction between a plurality of parties. A computer network 20 embodying the present invention will be described with reference to FIG. The present invention works in conjunction with a communication network 22, such as the Internet, a public switched telephone system, or other communication system. Network 20 includes a plurality of network terminals 24, 26, 28 and 30. The basic functions performed by the present invention are performed by a processor of a computer system 36 connected to the communication network 22. The system 36 is connected to the communication network 22 via a firewall server 38. The system 36 further includes a web server 40, a database server 42, a real monitor server 44, an SNA server 46, and an FTP server 48. The servers 38, 40, 42, 44, 46 and 48 are interconnected by a network 58, such as a local area network.
[0010]
The present invention is based on any desired configuration of the server, and any distribution of functions that are centrally included in one or several servers or that are widely distributed through multiple processors. Can also be implemented.
[0011]
In one embodiment of the present invention, terminals 24 and 26 can be used by a lender in a real estate environment, and terminals 28 and 30 can be used by a service provider for that lender.
[0012]
The present invention includes a method for processing transactions and providing communication between entities engaged in business activities. For example, lenders of terminals 24 and 26 require services provided by the providers of terminals 28 and 30. In such a real estate environment, there may be hundreds of entities corresponding to lenders and hundreds of entities corresponding to service providers. Often, each of these entities has its own data format and information definitions that do not match the formats and definitions of other parties. A further aspect of the present invention is the processing of transactions to perform the necessary functions to enable required commercial transactions between the parties. A basic application of the present invention is to provide commerce between business entities, which can be used by retail entities and consumers as well.
[0013]
One important term used in connection with the present invention is "business object". A business object is defined as a multi-functional business process involving functions, which has multiple states but is in one state at a time, and it is possible to execute which function in each state. Has limitations on what can be done. This restriction is referred to herein as a business rule. A business object includes one or more units of work that define a particular function within the business object. In selected embodiments, business objects are implemented as a single program "object" using an object-oriented programming language. Such programming languages include C ++ and Visual Basic. An object-oriented programming language is written by Grady Book, copyrighted in 1994, B.C. Benjamin / Cummings Publishing Company Publishing, “Object Oriented Analysis and Design With Applications”, 2nd edition. This book is incorporated herein by reference.
[0014]
The business objects referred to herein can be implemented by a non-object-oriented programming language, but still include structural elements and operations similar to those described herein. This business object primarily describes the business interaction between the parties. This is not a model of the internal operations of individual companies.
[0015]
A general example of a business object called "BUSINESS OBJECT # 1" is shown in FIGS. Referring to 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 operation 80 associated with state 72 (B).
[0016]
Business object # 1 is a unit of work 82, 84 identified as WU # 1, WU # 2, WU # 3, WU # 4, WU # 5, WU # 6, and WU # 7 in FIGS. , 86, 88, 90, 92 and 94.
[0017]
As shown in FIG. 3, the functions of the defined system are stored in a data store 98 such as a system memory or a disk. Store 98 includes a block 100 that identifies business object # 1 and indicates that it has states A, B, C, D, and E. Each state represents a stage of processing the business object. Store 98 includes a block 102 identifying work units # 1 through # 7 (82-94) associated with business object # 1. Each unit of work further includes a definition of that particular function.
[0018]
As shown in FIG. 2, WU # 1 (82) defines a function that causes a transition between states A and B. WU # 2 (84) defines a function that causes a transition between states B and E, and WU # 3 (86) defines a function that causes a transition between states A and E. WU # 4 (88) defines a function that causes a transition between states A and C, and WU # 5 (90) defines a function that causes a transition between states C and E. WU # 6 (92) defines a function that causes a transition between states C and D, while WU # 7 (94) defines a function that is only relevant to state B of business object # 1.
[0019]
Store 98 for business object # 1 further includes a block 104 that includes a set of rules identified as R # 1, R # 2, R # 3, and R # 4 associated with business object # 1. Rules define the requirements and restrictions that can be enforced on the corresponding business object. Each rule is defined for a particular 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 both state B and WU # 2, and R # 4 is associated with state C. However, the units of work and rules in blocks 102 and 104 are specifically related to business object # 1 and its defined state.
[0020]
Store 98 further includes a group of pre-processing and post-processing steps shown in blocks 106 and 108, respectively. Block 106 shows preprocessing steps # 1 and # 2. Each processing step has an association defined for an entity in the store 98 and pertains to one of the business objects defined in the store 98.
[0021]
In the present invention, a party involved in either transmission communication or reception communication is referred to as a user. Specifically, a user who initiates a transaction is called an initiator, and a user who receives the result of the transaction is defined as a recipient. More specifically, as shown in FIG. 1, one example of an initiator may be a lessor and one example of a recipient may be a service provider or a vendor. However, when a service provider initiates an action, that service provider can be an initiator and one of the lessors can be a recipient.
[0022]
As shown in FIG. 3, within the store 98, each pre-processing operation is defined for a particular environment of a particular business object and includes a particular function. In the store 98, the pre-processing step # 1 is performed on the WU # 1. Similarly, all other defined pre-processing steps in the store 98 have a defined environment and defined functions.
[0023]
Pre-processing steps are most often defined for a particular entity. Post-processing steps are generally defined for a particular entity.
[0024]
In a similar manner, there are post-processing steps within block 108. Each post-processing step also corresponds to a particular business object and has a defined environment and defined functions. If a defined environment exists for a particular post-processing entity, the function corresponding to that entity is performed.
[0025]
The store 98 shown in FIG. 3 may include a number of business objects, each of which has an associated unit of work, rules, pre-processing steps, and post-processing steps. As shown in this figure, business object # 2 has states A, B and C. Associated with this business object is a block 112 for defining a unit of work, a block 114 for defining an associated rule, a block 118 for an associated pre-processing step, and a block 120 for a post-processing step. ing. Pre-processing and post-processing steps do not exist for all business objects.
[0026]
Referring to FIGS. 1, 2, and 3, a business object such as # 1 is defined with respect to certain relationships that may occur between any two users set up for system 20. Store 98 is included in system 36, but more specifically in server 42. The system 36 stores a plurality of business objects, as shown in FIG. 3, to allow a large number of business transactions to be performed between users. For each business object, a defined unit of work, rule, and any associated pre-processing and post-processing steps are also included.
[0027]
When a user, such as a lender at terminal 24, is acting as an initiator and initiating a transaction, the user sends an input file to system 36 over network 22. This file provides for the selection of business objects, as described in detail below, and causes the system 36 defined by the selected business object to perform a series of steps, as shown in FIG. Generally, receiving a file from an initiator establishes a given state for a selected business object, such as state A, or moves a business object from one state to another after a functional operation has been performed. Transition. In many cases, this state transition or creation results in the routing of communication to the recipient. In general, the processing of business objects continues to receive more file communications from the user, each of which is generally associated with a transition between states of the business object. This continues until the end object is reached. This termination object often indicates the completion of the activity between the two parties, but may also indicate that the activity has been terminated before completion.
[0028]
The data structures associated with the present invention, as shown in FIGS. 2 and 3, provide definition and modularity to enable efficient and economical implementation of a very wide range of business transactions among a large number of users. I do. The system 36 can be incrementally expanded to add additional business objects as requested by users of the system. The great advantage of this approach is that it does not require a specific system to be built for each type of business transaction for each industry, or specifically for the proprietary data formatting and communication technologies used by specific companies in the industry. A completely new type of business activity and a new type of data format can be incorporated as elements defined within a business object and added to the store 98 of the system 36 without having to design the system.
[0029]
A basic flow diagram that generally represents the process of the present invention is shown in FIG. This will be further described with reference to FIGS. In a first block 132, the system 36 receives a user input data file (IDF) from an initiator, for example, a lessor having the terminal 24 shown in FIG. At block 134, the system 36 reads the input data file and selects the particular business object specified in the file. This corresponds to the business object already recorded in the store 98 shown in FIG. This file further contains specific data used by the system 36 at block 136 to populate the selected business object and thereby create an instance of that object.
[0030]
As shown at block 138, the system 36 examines the input data file, or folder where it is stored, to determine the particular unit of work to be performed in the current transaction.
[0031]
A business process as used herein typically includes a plurality of transactions, each transaction generally corresponding to one of the states of the business object. The flowchart shown in FIG. 4 represents the processing of one transaction that occurs within a business object.
[0032]
At block 140, the system 36 determines whether to perform a pre-processing step by examining the store 98. If so, the function corresponding to each of those pre-processing steps is performed. The pre-processing step is mainly for acquiring additional data. Next, at block 150, the system 36 performs the functions defined for the selected unit of work.
[0033]
Upon completion of performing the particular function on the selected unit of work, the system 36 proceeds to block 152 where all relevant portions of the information in the input data file received from the user, as well as the pre-processed and selected unit of work, Load the database with a file that contains any additional information and data generated during the execution of.
[0034]
At block 154, the system performs defined post-processing related to the current environment that exists at the time this block is entered. This transaction may need to generate some output, which is performed at block 156, and the output is sent to the recipient specified at block 158.
[0035]
The post-processing steps are primarily for sending confirmation or notification that something has changed or that an action has been performed.
[0036]
In general, processing a transaction as shown in FIG. 4 results in the identification of the initial state of the business object, or the transition of the business object from one state to another. The resulting state may be an intermediate state followed by further transitions, or it may be an end state indicating the completion of a function required for the particular business object. Pre-processing is not performed in every transaction, and post-processing is not performed in every transaction.
[0037]
An example of the present invention is then presented in the context of processing real estate transaction documents. This involves a large group of lenders providing real estate financing and service providers providing the special services required in the real estate realm. An important point of this example is that both the requester and the recipient user are likely to use different formats in their business to perform the real estate function. At present, this incompatibility hinders the processing of the real estate business, but this problem can be addressed by the present invention. Over time, certain industries, such as the real estate industry, may standardize on activity formats for files and alleviate this problem. In this example, a lender customer associated with terminal 1 shown in FIG. 1 has requested a loan to purchase a specific asset. A lender, referred to as an initiator at the beginning of this example, cannot authorize a loan for its asset without performing multiple activities. One step in the process representing this example is for the lessor to determine the status of the asset in relation to the flood. Such a decision is often an important step in the loan rating process. To answer this question, a lender submits what is called a "flood order" to determine the flood classification status of a particular asset. There are many different service providers (vendors) in the United States that provide this information. Some vendors only operate in certain regions, and some national vendors operate only for certain lenders rather than all lenders. Since many lenders are operating nationwide, processing a single flood order can be a relatively cumbersome task in the context of processing thousands of flood orders.
[0038]
In further describing the present invention, a schematic diagram representing the order of such real estate in a broader context is shown in FIG. 5, one of which is the flood order of this example. The schematic diagram of the transaction in FIG. 5 has three stages. There is an input and translation stage 168, a transaction processing stage 170, and a translation / output / delivery stage 172. In this example, the lessor is referred to as initiator (I). Still referring to FIG. 5, the initiator places an order, such as a rank order, at step 168. The initiator sends a file from its terminal 24 to the system 36 over the network 22. This may be a manufacturer-specific format file 174 or an XML file 176. The received manufacturer-specific files are placed in one of a set of folders reserved for a particular initiator. The initiator places the manufacturer's proprietary files in specific folders associated with specific units of work and business objects for the required actions.
[0039]
If the file is in a format unique to the manufacturer, the file is processed by the translation program 178 to create an XML file 180. File 176 corresponds to file 180.
[0040]
In the example of the real estate processing, a standardized file format using the extended markup language (XML) is selected. XML is described in the W3C recommendation “Extensible Markup Language (XML) 1.0” (page 41) issued on February 10, 1998, 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 the objects. XML is a form of SGML that is specified in ISO 8879, that is, a Standard Generalized Mark-up Language. By definition, XML documents are compliant with SGML documents. A particular structure of the XML document file has been selected to define the data required in the real estate processing associated with the defined business object. Non-XML files are converted to standardized XML files for processing by system 36.
[0041]
Still referring to FIG. 5, at step 170, a business object defined by data in the file submitted by the initiator to the formatted XML file is selected. This business object is defined by that object's folder for manufacturer-specific files. The initiator selects a corresponding folder. A unit of work is further identified for each file (transaction) sent. The work unit is specified by an XML file, but in this case also by a selected folder for a file unique to the manufacturer. This is processed by the business logic processor 182 at step 170. This processing is performed in conjunction with the system database 184 corresponding to the store 98 shown in FIG. The database 184 contains the business objects described above with reference to FIGS. The preprocessing step 186 is performed mainly to collect additional information according to the current situation. When the preprocessing step 186 is completed, the current file information is stored in the database 184. Then, post-processing 188 determined by the current situation is performed.
[0042]
As a result of the processing performed in the transaction processing state 170, an XML file 190 is created. In the example described here, it is necessary to deliver the order to the selected recipient. If the recipient uses the XML standard format, the file 190 is delivered via transfer 192 to the recipient (R), in this example, the selected service provider, in an FTP (File Transfer Protocol) manner or by email. Is done.
[0043]
If the selected recipient does not use a standard XML file, the file 190 is provided to the translation program 194 to create a file 196 in the manufacturer's own format, which is likewise selected by FTP or email. Send to the ent. In the example described here, the document provided to the recipient is a flood order, which is in a format compatible with the recipient, requesting the flood order, identifying the property, initiator, and any other required Identify information. At this point, it is the recipient's responsibility to provide a response. According to this description, in this step, a specific vendor is defined as an initiator (I).
[0044]
Continuing with the flood order example, reference is made to FIGS. 6 and 7 to define a business object # 7 representing the business process of the flood order. The flood order process (business object # 7) has states 220, 222, 224, 226, and 228, which correspond to states A, B, C, D, and E, respectively, of this business object. Business object # 7 includes work units 234, 236, 240, 242, 244, and 246, which are respectively WU # 1, WU # 2, WU # 3, WU # 4, WU # 5, WU # 6, and WU # 6. This corresponds to WU # 7. Still referring to FIG. 6, flood order business object # 7 has a state 220 (A), which represents a state where a new order has been placed by the requester. This is performed by the work unit 234 (WU # 1). When the vendor performs an operation necessary for confirming receipt of the order, that is, execution of the work unit 236 (WU # 2), the business object # 7 is moved to a state 222 representing "confirmed order". In this situation, either the user (requester or vendor) may need to attach a document to the current file. This is performed by executing the work unit 246 (WU # 7). Executing this unit of work does not cause the business object to transition from one state to another, but modifies the information set for a given state, in this case, attaching a document to a file. Hit.
[0045]
Generally, a party performs a unit of work by submitting a file identifying the unit of work, or a file placed in a folder identifying the selected business object and unit of work, to the system 36.
[0046]
The vendor may not be able to process the requested order or may not want to process the requested order. In such a case, the vendor executes the work unit 238 (WU # 3) by submitting a file referencing the work unit to the system 36, and the business object is moved to the end state 224. This is a "rejected order" condition. In this state, the request side is notified that the order has been rejected, and the processing of the business object # 7 is terminated.
[0047]
The vendor can execute a unit of work 240 (WU # 4) and transfer all the information needed for the flood order back to the requester, thereby completing the order for business object # 7 with end state 226 I do.
[0048]
The unit of work 242 can only be executed when the business object is in state 222 to cause the requester or vendor to cancel the current order. When either party activates this unit of work, business object # 7 is moved to end state 228 (E), thereby ending processing of business object # 7. Yet another cancellation option is for the requester to execute a unit of work 244 (WU # 6) to cancel the order set in state 220, thereby again moving the business object to the end state 228. .
[0049]
Referring to FIG. 7, the system in this example has a plurality of business objects and, in particular, a store 252 containing a defined business object # 7. As shown in store 252, there is a block 254 that identifies a particular business object (BO # 7) and the state of that business object.
[0050]
FIG. 7 illustrates storage 252, where the state of business object # 7 is defined at block 254, the unit of work is defined at block 256, and the rules associated with business object # 7 are defined at block 258 and the If so, the pre-processing step is defined at block 260; if present, the post-processing step is defined at block 262. In the storage 252, there may be any number of business objects before or after the business object # 7.
[0051]
Referring to business object # 7 in FIG. 7, WU # 1 is associated only with state A of business object # 7. This is the unit of work for a new order. Referring to FIG. 5, for this unit of work, the requestor sends a file to the system 36 in XML or a proprietary format for the transaction processing step 170, and then in step 172, the file is sent in the previously defined format. This includes delivering to the recipient (vendor) and receiving by that particular vendor. In general, execution of a unit of work elapses once from left to right in the transaction schematic shown in FIG. 5, resulting in a new state being established for the currently executing business object, such as business object # 7 shown in FIG. Is done.
[0052]
WU # 2 represents the process by which the vendor confirms receipt of the order, in which case the vendor becomes the initiator (see FIG. 5) and sends the file through steps 168, 170, 172 to send the recipient, this transaction Then deliver to the lessor. As a result, the business object # 7 transitions from the state 220 (A) to the confirmed order state 222 (B). The file submitted by the vendor references an instance of a particular running business object # 7.
[0053]
WU # 3 represents the process by which a vendor rejects an order. In this case, the vendor becomes the initiator (FIG. 5), sends the formatted file, and processes the file in steps 168, 170, 172 to provide the recipient with information indicating that the particular order has been rejected. Lender). As a result, business object # 7 moves from state 220 (A) to end state 224 (C).
[0054]
WU # 4 in FIG. 7 indicates a function that results in a transition from state B to state D. Performing this unit of work involves sending a file from the vendor through the processing of the transaction schematic shown from left to right in FIG. 5 to inform the recipient (lessor) of the completion of the order in an appropriate format. As a result, the business object # 7 is changed to the end state 226 (D) corresponding to the completed order.
[0055]
WU # 5 can be initiated by either the requester or the vendor to cancel an existing confirmed order. As a result, the state transits from the state 222 (B) to the state 228 (E).
[0056]
WU # 6 is an operation in which the requester cancels the order before the order is rejected or confirmed by the vendor. As a result, the state transits from the state 220 (A) to the end state 228 (E).
[0057]
WU # 7 does not perform the function of transitioning business object # 7 from one state to another, but represents the function of attaching a specific document to an ongoing flood order so that the user can refer to it.
[0058]
FIG. 7 shows a list of rules that represent restrictions on functions and activities that can be executed on business object # 7. The rules associated with this particular business object are described as follows:
R # 1 indicates that the only valid unit of work when the object instance does not exist and needs to be created is WU # 1.
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 work units valid for state B are WU # 4 and WU # 5.
[0059]
Business object # 7 can further include a pre-processing # 1 step, which involves changing the context of the current business object prior to executing the unit of work to achieve the required business logic. Performed on the status conditions of the transaction to perform the function. The preprocessing step # 1 for repeating the work unit # 1 is to confirm the address of the order. Pre-processing step # 2 of work unit # 1 is to select a vendor using a predetermined procedure set by the lessor.
[0060]
Post-processing step # 1 of block 262 occurs when a particular "transaction" status condition is reached. This situation is the occurrence of work unit # 4. This post-processing includes an electronic funds transfer (EFT) operation to pay for the flood order.
[0061]
A detailed process flow representing an example of the present invention is shown in FIGS. 8A and 8B and is further described in connection with the flood order example.
[0062]
Following start block 276, block 278 is entered to detect if there is an input file in the initiator's folder. An inquiry is made at block 280 to determine whether the format of the received file is XML, which is a predetermined setting. If the answer is yes, flow proceeds to block 282 where the file received is examined to determine the particular business object identified in the file. The XML file specifies the business object, and the folder holding the manufacturer's own 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 business object selected is business object # 7. Continuing with FIG. 8A, if the answer in block 280 is no, proceed to block 284 and convert the received file to the desired XML format. This is performed by the translation program 178 of FIG. Following the block 284, a transition is made to block 282.
[0063]
Following block 282, block 286 is executed to build or populate a particular instance of the selected business object as determined at block 282. Continuing at block 288, the input file is further examined to determine the selected unit of work associated with the selected business object. This corresponds to one of the defined work units, such as the work unit shown in block 256 of FIG. This work unit is specified in the original XML file, and corresponds to the file folder for the original manufacturer's original file.
[0064]
At this point, system 36 has received the input file from the initiator, has selected the business object specified in the file, populated the business object, and determined the unit of work specified by the initiator. Control then passes to block 290 to determine whether the specified unit of work is valid for the current state or status of the business object. This refers to states A, B, C, D, E, or status not in state. This status is determined by the business rules associated with the selected business object, such as the rules defined in block 258 of store 252 of FIG. If the execution of block 290 determines that the current unit of work is not valid for the current state or status, then proceed to block 298 according to the No branch, generate an error message and send it to the initiator, and then end block. Transition to 300.
[0065]
If the execution of block 290 determines that the current unit of work is valid, the process proceeds to block 296 following the Yes branch to determine whether any pre-processing steps should be performed. The current situation is compared with the situation of the defined pre-processing step shown in block 260 of FIG. If any of the list of pre-processing step statuses matches the current status, the process proceeds to block 302 according to the Yes branch, and executes one or more specified pre-processing steps. If the current situation does not match any of the stored situation conditions, the process moves to question block 304 according to the No branch. Block 304 corresponds to another of the rules of block 258 and defines the validity of the data present at this stage of processing. If it is determined at this point that there is invalid data, the process proceeds to block 306 according to the No branch, generates an appropriate error message and sends it to the initiator, and then proceeds to the end block 308.
[0066]
Data validity is determined by a set of rules for a particular type of data. For example, the data field of the ZIP code must be exactly 5 or 9 digits and must not contain alphabetic characters. A flood rating, such as A, B, or C, must not include any other characters and can have only one character. For reports with a flood disaster, there must be text in the comment field.
[0067]
If the data is determined to be valid at block 304, the process proceeds to block 310 according to a Yes branch to perform the required function associated with the specified unit of work. This includes the actions defined by the business logic processor 182 (FIG. 5) defined for that business unit of work.
[0068]
Following block 310, enter question block 312 to determine if the status of the selected business object has changed. If so, proceed to block 314 according to the Yes branch to set a new status or state for the business object. This corresponds to specifying a new state of the business object as shown in FIG. If no change is required in block 312, the process proceeds to question block 316 according to the branch of No. This block determines if any type of delivery, such as a file, is required to the recipient. If such a delivery is required, the Yes branch is taken to block 318 to determine the format required for delivery, and then at block 320 to determine the delivery mechanism for the delivery, such as FTP or email. Then, the flow transitions to block 322 to execute delivery of the transaction specifying the format and mechanism. Following block 322, the process moves to a question block 324, which is a block to which the process proceeds even if the answer is no in block 316.
[0069]
An inquiry is made at interrogation block 324 to determine whether the current status status matches any of the post-processing status statuses listed in block 262 of FIG. If the answer is yes, the process moves to block 326 where the specified post-processing steps are performed. If the answer is No, the process moves to block 328 according to the branch of No. At block 328, if such an action is required at this stage, a confirmation is created for the initiator and the created confirmation is forwarded to the initiator. Finally, a transition is made to end block 330 to complete the transaction, which in most cases has resulted in a change in the state of the currently selected business object.
[0070]
Continuing with an example of a flood order, reference is now made to FIGS. 5, 6, 7, 8A and 8B. Assuming that the requestor submits a new order (FIG. 6) and executes the unit of work 234, business object # 7 is in state 220 (A). In this state, the vendor is notified that the order has been submitted to the vendor and that it has data specific to the order. At this time, the initiator may be the requester or the vendor according to the definition in the business object # 7 (FIG. 6). In this example, if the vendor wants to confirm the order, the vendor will be designated the initiator of the next transaction and will submit the input file to the folder corresponding to that particular vendor, as shown in step 168 of FIG. System 36 then executes block 278 of FIG. 8A to detect the input file, and then determines at block 280 whether the file is in the correct XML format. If not, the translation step is performed at block 284 by the translation program 178 shown in FIG.
[0071]
At step 282, the business object identified in the input file from the initiator (the vendor in this example) is determined. This identifies existing business objects that have been previously selected and populated. Next, the process proceeds from step 286 to step 288, where the unit of work specified by the input file received from the vendor is determined. In this example, this work unit is WU # 2 of the block 256 shown in FIG. At block 288, the rules of business object # 7 are referenced to determine if the unit of work is valid in that state. Rule # 2 indicates that the work unit is valid in that state. Proceeding from block 290 to the Yes branch, it is determined whether any preprocessing steps should be performed. In the current situation, there is no such pre-processing step and following the branch No, proceed to block 304 to determine if all existing data in the file being processed is valid. If the data is valid, the process proceeds from block 304 to block 310 according to the Yes branch, and executes the selected work unit, that is, the work unit WU # 2 (FIG. 7). This is done by sending the XML file received from the business logic processor 182 and possibly converted as a file 190.
[0072]
Once the file format required by the recipient (in this case, the lender) is determined, the process moves to the file transfer block 192 (FIG. 5) or the translation program 194 to generate the manufacturer's own file or to use an existing XML file. Is transported. The FTP or email transmission scheme for the particular recipient is also determined, and the appropriate file is sent to the recipient.
[0073]
Still referring to FIG. 8B, enter query block 312 to determine if an existing business object, in this example, business object # 7, needs a status change. In this example, the answer is yes, and the flow moves to block 314 to change the state of business object # 7 in processor 182 from state 220 (A) to state 222 (B). This is a state where the order has been confirmed with the lessor.
[0074]
Still referring to FIG. 8B, blocks 316-322 are processed to select a format and transmission mechanism, and then perform file delivery to the recipient (lessor).
[0075]
The next step is to enter block 324 to determine if any post-processing steps are required. This is done by comparing the current situation with the post-processing steps listed in block 262 of FIG. If they match, the process proceeds to block 326 according to the Yes branch, and executes the specified post-processing step. No post-processing steps are required in this example situation. Finally, at step 328, a confirmation that the order confirmation has been completed may optionally be sent to the initiator, in this case a vendor.
[0076]
A more detailed description of an example of the present invention described with reference to the flood order example is shown in FIGS. 9A and 9B in addition to FIGS. The examples described herein relate to the real estate industry, and in particular, to the processing of “flood orders” by lenders to determine whether a designated asset has a flood rating. The system shown in FIGS. 9A and 9B is divided into three stages. There is an input and transformation stage 352, an order processing stage 354, and an output and delivery stage 356. One way to enter the system is through web clients 358, 360, 362 that are part of a web farm 364 that communicates in a conventional manner with a web server 366 that is part of the system 36.
[0077]
The file can be sent to the system server using any of a number of techniques. This includes the TransXML file 368, X. There are 12 files 370 and a file 372 in a manufacturer-specific format. The web server 366 operates in conjunction with the program 382 to generate an XML file in a specified format, which is transferred as the RealXML file 384.
[0078]
The files 368, 370, 372 are placed in the server in folders corresponding to individual initiators and selected units of work for manufacturer-specific files. These files are monitored by the program REALMONITOR 386, which identifies the format of the files and sends the pre-formatted XML file 368 directly to the RealXML file 384, where X. When the 12 files are sent to the translation program 388, the translation program 388 provides the file 384, and when the manufacturer's own file 372 is sent to the translation program 390, the translation program 390 generates the final XML file 384.
[0079]
However, the present invention is not limited to this industry, but can be widely applied to business processing between multiple parties in any industry.
[0080]
The RealXML file 384 is an XML file 391 in a defined format, which is input to a program 392 called “RealXMLDb”. This is an object program associated with the defined XML file. The program 392 operates in conjunction with a database 394 that stores system functions as shown in FIG. 3 in addition to the current XML file.
[0081]
Program 392 utilizes the data stored in database 394 to perform optional pre-processing steps 396 and 398. Upon completion of these steps, the current state of the formatted XML file is stored in database 394.
[0082]
At this point, RealELDb program 392 executes the unit of work specified in the received file and, if necessary, executes order delivery 400 including access to RealDelivery object program 402 (FIG. 9B).
[0083]
The RealXMLDb program 392 also executes any optional post-processing defined at steps 404 and 406.
[0084]
With further reference to FIG. 9B, the program 402 (REALDevery) creates and sends the RealXML file 416 or launches the exporter program 418, depending on the requirements of the recipient. The RealXML file 416 is transferred through a TransXML export operation 420 to transport the TransXML file 422 to a designated recipient.
[0085]
The designated recipient is X. When receiving an instruction to receive a file in the X.12 format, the exporter 418 transfers the existing RealXML file from the program 402 to the translation program 423, A 12 file 424 is generated.
[0086]
If the designated recipient specifies a maker-specific format, the exporter 418 transfers the standardized XML from the program 402 file to the maker-specific format translation program 426, which translates the maker-specific format file. 428 is generated.
[0087]
FIG. 10 shows a detailed example of the file 372 in the manufacturer's own format as an example of the flood order. The formatted XML file 391 is shown in the specific embodiment of FIG. X. The twelve files 424 are shown in detail in FIG.
[0088]
The flood order processing described above will be described in more detail with reference to FIGS. 9A, 9B, 10, 11, and 12. In this example, a lender, such as a bank, sends a flood order to the system by submitting a text file with its pre-designated layout. This text file is a file 372 in a manufacturer-specific format shown in FIG. This file is sent via FTP to the lessor's designated input folder in the system's FTP server, such as 48 in FIG.
[0089]
The REALMONITOR program 386 detects that the file of the lessor 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 the manufacturer's proprietary text format, calls the appropriate translator program object, ie, the translator 390, and converts the lessor's text file 372 into the specified format used by the system. Performs the function of converting to a RealXML file. The generated XML file is the file 391 shown in FIG. File 391 has a unique identification representing a particular instance of the selected business object.
[0090]
This file is then sent to RealXMLDb program 392, which determines that the file belongs to the lender of origin, and calls a particular program (object) that includes the pre-processing steps required for that particular lender flood order. . One of the preprocessing steps specifies that when the particular lender places an order for the flood, the system will automatically select one vendor from the list of approved vendors. This is based on a set of rules supplied by the lessor in advance. Upon completion of the pre-processing, a particular vendor to receive the order is specified. Upon completion of the pre-processing, the order file is loaded into the system database 394.
[0091]
When the file is loaded, RealXMLDb program 392 examines the post-processing steps for that particular lender and that particular type of order. This particular lender specifies that in one of the post-processing steps, a credit report is automatically issued upon completion of the flood order.
[0092]
The primary function performed by a flood order submission is to submit the order to selected vendors. This is a function specified for a work unit in the file 372. The RealXMLDb program calls the order delivery program 400 to further perform the steps required to complete the delivery. Order delivery program 400 consults database 394 to determine the format and transport mechanism required by the selected vendor for a new order. In this example, the selected vendor has X.D. It wants to use the 12 format and place the order in an output folder within the system's FTP server 48. The delivery program 400 calls the translation program 422 to convert the file into the format desired by the selected vendor (X.12). The translation program 422 then stores the selected vendor's file 424 in the vendor's output folder on the FTP server 48 and makes it available to the vendor. The vendor can also specify that the file be sent directly to itself.
[0093]
The manufacturer-specific text format file 372 shown in FIG. 10 contains all the information required by a vendor to issue a flood status report for a particular asset. When submitting this file to the lessor, the file is sent to a folder corresponding to a particular unit of work of a particular business object. In this example, this is the work unit “new order” of business object # 7 (order). System 36 identifies business units and work units by the folder in which it is located.
[0094]
The file 391 in FIG. 11 is an example of a standardized XML file used in the system 36 of the present invention. The business object is specified as “order” in the field “BO name”. The unit of work is specified as “create” in the “Identity action” field. The data element of the business object is specified after the field “tag name”. The file 424 shown in FIG. 12 is a pre-processing format selected by the vendor in advance. Part of this file is a unique identification that references a particular instance of the selected business object. This identification is the expression “CESARG94821893652”.
[0095]
Once the vendor has obtained or received the output file 424, the vendor can confirm that the order has been received by submitting the input file 430 shown in FIG. This file contains the identification number that was in the received file 424. This number is in the first line identified as "Identify Order". System 36 uses this identification number in file 430 to associate the file with a particular instance of the selected business object, in this example, business object # 7.
[0096]
Although the invention has been described above with reference to the field of real estate transactions, the invention is equally applicable to the communication and processing of business activities between businesses in other fields and industries. The modular structure of the present invention allows business objects with corresponding units of work, rules, pre-processing and post-processing steps to be added as needed, and allows the system to handle business activities. The addition of other business objects to the system 36 is shown in FIGS. This example is for processing a car insurance claim. Entities involved in such processing include large underwriters, issuers of insurance, licensed auto repair shops, police agents, and state car agents. A series of transactions between a plurality of these parties is required to process a car insurance claim. FIG. 14 shows a business object # 248 for such processing, and FIG. 15 shows a business object associated with a unit of work, a rule, pre-processing, and post-processing.
[0097]
14 has states 440 (A), 442 (B), 444 (C), 446 (D), 448 (E), and 450 (F). Further, work units 452 (WU # 1), 454 (WU # 2), 456 (WU # 3), 458 (WU # 4), 460 (WU # 5), 462 (WU # 6), and 464 (WU #) # 7) is included.
[0098]
Referring to FIG. 15, storage 470 includes a block 472 that identifies business object # 248 having a specified state. Block 474 specifies a unit of work corresponding to business object # 248. Block 476 specifies the rules associated with business object # 248. Block 478 describes the pre-processing steps associated with business object # 248, and block 480 describes the post-processing steps associated with business object # 248.
[0099]
When business object # 248 is prepared, it is loaded into system 36, which can process input files from the user and perform the functions of the new business object. This demonstrates the modularity of the present invention.
[0100]
In summary, the present invention provides structures and procedures for reducing the difficulties of communication and business procedures between businesses, thereby reducing costs and time spent and increasing productivity.
[0101]
While some embodiments of the invention have been illustrated in the accompanying drawings and have been described in the foregoing detailed description, the invention is not limited to the embodiments disclosed herein and departs from the scope of the invention. It will be appreciated that many modifications, variations, and alternatives are possible without.
[Brief description of the drawings]
FIG. 1 is a schematic diagram of a data communication network connected to a plurality of users and also to a system for processing transactions according to the present invention.
FIG. 2 is a schematic diagram of a state of a sample business object.
FIG. 3 is a table defining functions for the business object shown in FIG. 2, including a state, a work unit, a rule, and a list of pre-processing steps and post-processing steps related to the business object.
FIG. 4 is a series of flowcharts illustrating a general example of a processing step involving the present invention.
FIG. 5 is a schematic diagram of a transaction showing the stages of processing of the transaction along with certain file types and processing operations.
FIG. 6 illustrates a specific example of a business object including a plurality of states and a plurality of defined units of work, ie, a flood order.
FIG. 7 is a table of information defining the business object shown in FIG. 6, including a state, a work unit, a rule, a pre-processing step, and a post-processing step.
8A and 8B are detailed flow charts representing an implementation of the present invention.
9A and 9B illustrate a transaction description for an example of the present invention that requires three stages of processing, translating, processing, and delivering files of a particular data type.
FIG. 10 is a diagram showing an example of a manufacturer-specific text format for an example of a flood order.
FIG. 11 illustrates an example of a RealXML file used in one embodiment of the present invention for a new flood order.
FIG. 12: For a new flood order, the manufacturer's own X.D. It is a figure showing an example of a file of 12 formats.
13 is a diagram showing an example of a manufacturer-specific format file received from a vendor in response to receiving the output file shown in FIG.
FIG. 14 is an example of a schematic diagram of a further state of a business object for claim processing.
FIG. 15 is a table defining functions for the business object shown in FIG. 14, including a list of states, work units, rules, pre-processing steps and post-processing steps.

Claims (30)

In a method of workflow processing between a plurality of users via a computer system,
Receiving an input data file from a first user for initiating a transaction, wherein the input data file has a plurality of data units;
Selecting one of a plurality of stored business objects for the transaction, wherein each of the business objects includes a plurality of states, a plurality of units of work each associated with at least one of the states. And a plurality of rules pertaining to the states and selected ones of the units of work, wherein the selected business object is selected one of the states at a time;
Selecting one of the units of work for the transaction;
Determining the relevance of the selected unit of work with reference to a selected unit of work of the selected business object and one of the rules associated with the selected one of the states;
Executing the specified function on the selected work unit if the selected work unit is determined to be valid;
Selecting a new state for the selected business object;
Creating an output file based on at least a portion of the function performed on the selected work state;
Making the output file available to a second user of the system. The method of claim 1, further comprising performing a pre-processing operation to collect information related to the one business object before the step of creating an output file. The method of claim 1, further comprising performing a post-processing operation that communicates information to a party after the step of performing a function specified by the selected unit of work. The method of claim 1, including storing data associated with the input file in a database. The method of claim 1, wherein the business object is an object used in object-oriented programming. In a method of workflow processing between a plurality of users via a computer system,
Receiving an input data file for a transaction from a first user, wherein the input data file has 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, wherein each of the business objects has a plurality of states, at least one of the states Including a plurality of units of work each associated with said plurality of rules and said states and a plurality of rules relating to each of said selected units of work, wherein said selected business object is one of said states selected at a time; ,
Selecting one of the units of work for the transaction based on data in the input data file;
Determining the relevance of the selected unit of work with reference to a selected unit of work of the selected business object and one of the rules associated with the selected one of the states;
Performing the specified function on the selected work unit, if the selected work unit is determined to be valid;
Selecting a new state for the selected business object;
Creating an output file based on at least a portion of the functions performed on the selected work state;
Making the output file available to a second user of the system. 7. The method of claim 6, further comprising performing a pre-processing operation to collect information about the one business object prior to the step of creating the output file. 7. The method of workflow processing according to claim 6, further comprising, after the step of performing a function specified by the selected unit of work, performing a post-processing operation that communicates information to a party. The method of workflow processing of claim 6, including storing data associated with the input file in a database. 7. The workflow processing method according to claim 6, wherein the business object is an object used in object-oriented programming. In a method of workflow processing between a plurality of users via a computer system,
Receiving an input data file for a transaction from a first user, wherein the input data file has a plurality of data units and is located in one of a plurality of folders associated with the first user. Steps to be stored;
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; A plurality of units of work, each associated with at least one of the states, and a plurality of rules, each associated with a selected one of the states and the unit of work, wherein the selected business object has one of the states at a time. Selected steps;
Selecting one of the units of work for the transaction based on the folder in which the input file is stored;
Determining the relevance of the selected unit of work with reference to one of the rules associated with the selected unit of work of the selected business object and the selected one of the states;
Executing the specified function on the selected work unit if the selected work unit is determined to be valid;
Selecting a new state for the selected business object;
Creating an output file based on at least a portion of the function performed on the selected work state;
Making the output file available to a second user of the system. The method of workflow processing according to claim 11, comprising performing a pre-processing operation to gather information about the one business object before the step of creating the output file. The method of workflow processing according to claim 11, further comprising, after the step of performing a function specified by the selected unit of work, performing a post-processing operation that communicates information to a party. The method of claim 11, further comprising storing data associated with the input file in a database. The workflow processing method according to claim 11, wherein the business object is an object used in object-oriented programming. In a method of workflow processing between a plurality of parties via a computer system,
Detecting an input file from a first user, wherein the input file is stored in one of a plurality of folders associated with the first user, and wherein the input data file stores a plurality of data units. Having steps;
Creating a standardized format file using data from the input data file and information associated with the one of the folders in which the input file is stored, wherein the created standardized format file is Comprises an identification of one of a plurality of stored business objects and an identification of one of a plurality of stored units of work associated with said one business object, wherein each of said stored business objects is ,
(A) a plurality of states, wherein the selected business object is one of the states selected at a time;
(B) a plurality of work units each associated with at least one of the states;
(C) including the state and a plurality of rules relating to each of the selected ones of the work units;
Executing a function associated with the one unit of work;
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;
Creating the output file in the selected file format using data associated with the business object;
Making the output file available to the second user. 17. The method of workflow processing according to claim 16, comprising, prior to the step of creating the output file, performing a pre-processing operation to collect information about the one business object. 17. The method of workflow processing according to claim 16, comprising, after the step of performing a function specified by the selected unit of work, performing a post-processing operation that communicates information to a party. The method of claim 16, comprising storing data associated with the input file in a database. 17. The workflow processing method according to claim 16, wherein the business object is an object used in object-oriented programming. In a method of processing a transaction between parties using a computer system,
Receiving a first input data file from a first user for initiating a transaction, wherein the input data file has a plurality of data units;
Selecting one business object from a plurality of stored business objects, wherein each of the stored business objects comprises:
(A) a plurality of states, wherein the selected business object is one of the states selected at a time;
(B) a plurality of work units each associated with at least one of the states;
(C) including the state and a plurality of rules relating to each of the selected ones of the work units;
Selecting a first work unit of the work unit;
Executing a function defined for the first unit of work;
Establishing a first state of the state as a function of the first unit of work;
Generating a first output file based on the selected business object;
Making said first output file available to recipients;
Receiving a first input file from the recipient;
Selecting a second work unit of the work unit in response to the first input file from the recipient;
Changing the state to the second state according to the second work unit;
Generating a first output file based on the selected business object, and transmitting the second output file to the first user based on the selected business object and the second unit of work; And a transaction processing method comprising the steps of: 22. The method of processing a transaction according to claim 21, comprising, before said step of creating a first output file, performing a pre-processing operation to collect information relating to said selected business object. 22. The method of processing a transaction according to claim 21, comprising, after the step of performing a function specified by the selected unit of work, performing a post-processing operation that communicates information to a party. 22. The method of processing a transaction according to claim 21, comprising storing data associated with the input file in a database. The method of processing a transaction according to claim 21, wherein the business object is an object used in object-oriented programming. In a computer system that provides workflow processing between a plurality of parties,
A communication system for transmitting a file to the party and receiving a file from the party;
A system storage having a plurality of business objects, wherein each of the business objects is:
(A) a plurality of states;
(B) a plurality of work units each associated with at least one of the states;
(C) system storage including the state and a plurality of rules relating to each of the selected ones of the work units;
A processor for receiving an input file from a first one of the parties via the communication system, and associating one of the business objects with the input file; A processor for selecting, processing a function defined for said one unit of work, and establishing one of said states of said one business object, said output file comprising: A processor coupled to the communication system for use by two parties, the computer system comprising:
A computer system for providing workflow processing, wherein the output file is a correlation between the one business object and the input file. 27. The computer system for providing workflow processing according to claim 26, comprising a pre-processing operation stored in the system storage and associated with a particular state of a particular one of the business objects. 27. The computer system of claim 26, comprising a post-processing operation stored in the system storage and associated with a particular state of a particular one of the business objects. 27. The computer system for providing workflow processing according to claim 26, comprising a plurality of translation programs for converting an input file having a predetermined format into a standardized file format for use by the system. 27. The computer system for providing workflow processing according to claim 26, comprising a plurality of translation programs for converting a standardized file format used by the system into a predetermined output format.

Images