WO2001073650A1

WO2001073650A1 - Method and apparatus for using an expert system to execute business transaction documents to facilitate electronic commerce

Info

Publication number: WO2001073650A1
Application number: PCT/US2001/008717
Authority: WO
Inventors: Gregory T. Royal
Original assignee: Xbridge Software, Inc.
Priority date: 2000-03-24
Filing date: 2001-03-19
Publication date: 2001-10-04
Also published as: AU2001247559A1; NZ521427A; CA2403652A1; EP1266331A1; EP1266331A4

Abstract

A method and system is described for electronic commerce system enabling corporations to transact business over the Internet or Value Added Networks. The expert system allows businesses to transact business without regard for disparate internal systems and disparate supplier and logistical systems. An expert system, method and apparatus which consists of an input manager (200) to normalize incoming documents and an inference engine (400) that contains a dynamic decision template manager (410) that allocated templates to documents based on the prevailing environment. The inference engine executes the template based on a dynamic node engine (420) and the node execution manager (440). They execute the decision template (430) based on traversing the decision template and executing a conditional branch or passing the execution to the task manager. The task manager identifies the appropriate data source to manipulate and passes the result back to the node execution manager.

Description

METHOD AND APPARATUS FOR USING AN EXPERT SYSTEM TO EXECUTE BUSINESS TRANSACTION DOCUMENTS TO FACILITATE ELECTRONIC COMMERCE FIELD OF INVENTION

The present invention relates to an expert system method and apparatus to facilitate the movement of business transaction documents between a plurality of organizational entities and within those entities. BACKGROUND OF THE INVENTION

A business contract consists of a document and a relationship between two or more entities in order to transact business. The document, for example an Invoice, is not an Invoice unless it inherits its state from the prescribed relationship. The document is the reduction of the relationship into words and logic, not the contract itself.

Business relations are in a constant state of flux. Rules and logic for dealing with other entities change with reasonable speed. With the advent of the Internet, those relationships move even more quickly than the traditional environment in order to gain advantage.

To treat all business documents with equal logic and sustenance is incorrect. Business documents are dynamic and require to be treated within their current context. By breaking out the logic of the document from the document itself, a computer system can more effectively handle a multiplicity of documents and a multiplicity of contexts. A fundamental attribute of commerce is the multiplicity of documentation required to perform transactions.

Electronic Commerce is a relatively new field of endeavor. Traditionally the transaction of business has used paper or a facsimile thereof as the preferred mechanism as a means of transaction. An example is the Purchase Order. This document in itself may yield any number of additional documents, such as contracts for sale, supplier agreements, bills of lading, customs documents, bank drafts etc. Inherent in business is a set if logic that is learned by teams of administration staff to conduct day to day business. There have been a number of attempts to automate these processes over the years. For a number of years Electronic Data Interchange (EDI) directed by the American National Standards Institute and others have ratified EDI standards such as ANSI ASC X.121 (often called ANSI X.12), UNTDI2 and EDIFACT3. These standards have relied upon costly value added networks and proprietary equipment.

The complex environment and implementation costs have relegated EDI to the largest corporations most able to afford it. Although it is a rich environment covering many methods of business, its cost and proprietary nature have limited its applicability to the many organizations. Adoption has not been wide spread and has usually been as a result of a larger organizations dictate, rather than a widespread adoption. There have recently been a number of advancements in the ability to transact business that allows greater scope for the use of electronic means for transacting business. The Internet with its ubiquity and low entry cost has created a low cost entry platform for many businesses to participate. The adoption and ratification of Hypertext Mark Up Language (HTML) Extensible Mark Up Language (XML) have further improved the adoption of the Internet and the World Wide Web as a viable platform for commerce.

The failure of Electronic Data Interchange is its cost to implement which directly influences the ability to extend the reach and usefulness of EDI. Electronic Data Interchange systems have previously not been able to overcome these limitations.

Most of the prior art in this field seeks to reduce the business logic to static, known environments. The environment was a schema that described the document to be processed in a form suitable for both systems. The document was then simply passed from one to the other.

U.S. Pat. 5,794,234 (The EC Company, Aug 1998) provides for the Method and System for providing electronic commerce between incompatible data processing systems. This is a simple translation system that uses a universal file format to translate a transaction from one format to another. It does not encompass business logic, it simply translates the transaction from one format to another and forwards it. Business logic is provided by other systems.

U.S. Pat. 5,410,675 (Shreve et al, Apr 1995) is a method for restructuring input data having a pre- specified data structure as input with a data management engine, such as a translation engine, which is dynamically configured by the input data to conform the input data to an output data structure. This prior art assumes a known state at all times as the input passes to the output. No logic is used internal to the system to act upon the data and influence it, other that the input itself.

Electronic Commerce prior art also seeks to find mechanisms to support the translation of data within a known state. U.S. Pat. 5,710,887 (Broadvision, Jan 1998) provides for the architecture of an electronic commerce system. It is a system for facilitating commerce transactions over a computer driven network. This prior art does not deal with the issue of the many types of business transactions that can perform via electronic commerce. For example the logistics aspect of a purchase is assumed to be static, as is the ability to provide support documentation such as customs clearance. Furthermore the relations this prior art assumes, are static through time. The reality is that business relationships, the rules and logic behind them change over time and with relative frequency. It states that previous attempts to provide electronic commerce subsystems have been tailored for an individual offering, yet it within itself does not adequately answer the reality of communication between multiple disparate systems with multiple disparate data formats. Business transactions are distinct from the document that supports them. For example, an Invoice is not an invoice until it inherits the convention as rules of the recipient. An invoice to XYZ Corporation can not be written until an instance of the relationship is created, then the document inherits that relationship. Then the Invoice document becomes meaningful.

U.S. Pat. 5,970,475 (Intelisys, Oct 1999) provides for the building of an electronic procurement system for trading partners. Using three basic entities, it provides a framework for the clearance of transactions between trading partners. It again uses static business logic to facilitate the transaction nor does it address the problem of multiple disparate systems of suppliers. Furthermore, the patent states that the supplier catalogue is based on software that is dependent on the purchasers procurement system. It does not provide for suppliers to have multiple vendor systems and the integration of each of those.

Expert Systems are relatively new. One of the earliest patents in the area is U.S. Pat. 4,803,641, which is a computer system that uses a knowledge base to extract solutions inferred from the input of the user.

For example, U.S. Pat. 4,803,641 (Tecknowledge, Feb 1989) provides for the building an expert system tool on a computer. It provides a mechanism for a user to interact with the computer system and extract knowledge from a knowledge base. Specifically, this is used for computer consultation, medical consultation or where there exists a substantial body of knowledge exists to solve a specific problem.

Further, work in this area is confined to extending the diagnostic capability of the expert system. U.S. Pat. 4,829,426 (Cogensys, May 1989) improves on the process by making computer generated paramoφhic models of an expert's decision process. This patent confines itself to the generation of a better method for expert decision making.

U.S. Pat 5,319,740 (Hitachi, June 1994) provides for a building method where the inference process is executed with a static decision tree and user based responses. It does not provide for or make any dynamic allocation of decision trees nor does it allow for modification of those trees within the system itself. US Pat. 5,835,683 (IBM, Nov 1998) provides for the creation and maintenance of a knowledge base for an expert system. The knowledge base is created at runtime with instances of cells to develop the decisions to be made. What is does not do is provide a means for the expert system to interact with other computer systems to solve problems. Nor does allow for dynamic allocation of decision trees to documents or the ability for multiple recursive trees to exist. Automated procurement lends itself well to the World Wide Web. Earlier prior art concentrated on automating the process of procurement within the coφoration. U.S. Pat 5,361,199 (TI, Nov 1994) provides for the Automated procurement system with multi-system data access. This prior art requires firstly a homogeneous environment to operate and secondly a simple data storage mechanism to support queries across the data. U.S. Pat 5,319,542 (IBM, June 1994) provides for a system to requisite goods through the use of catalogues, both public and private. Again this patent assumes that the environment is static and uniform amongst suppliers and vendors. The assumption in this art is that the environment is homogenous. An extension of this art using the Internet would come up with considerable difficulties. It furthermore does not provide any means or indications as to how best to operate in a heterogeneous environment. Finally, all of the above prior art treats the environment for which the business transactions exist as essentially static and fixed. This limits the systems ability to extend itself and form new relationships with other parties and organizations. Another practical difficulty for the prior art is how best to encapsulate multilingual relationships.

What is needed is a system and method to dynamically facilitate document exchanges for fluid relationships. SUMMARY OF THE INVENTION

In contrast to the prior art, the present invention provides a method for providing an expert system method and apparatus that allows an organization or plurality of organizations to pass business transactional documents between each other. This allows for the timely execution of business logic, rules and tasks to automate the business process which is currently to a large extent manual in nature. Briefly, the foregoing object is accomplished in accordance with aspects of the present invention by an expert system that provides for the input of multiple disparate documents from multiple sources. These documents are identified by the source of the document, duly authenticated, and by a type definition as to the format and structure of the document. A Profile Manager may append additional information to the document. This may be information about the source of the document or relating to objects inside the document. This document is then parsed through a generic parser, or multiple receptors depending on the schema that the document is coded for and normalized to the internal schema of an Expert Engine. This document is then passed to an Inference Engine for normalization.

The Inference Engine assigns a Decision Template to the document via a Template Manager. The Decision Template contains information as how to execute the document package dependent on the nature and constitution of the document. The document package is then passed to a Dynamic Node Engine to execute the Decision Template through it's own Node Execution Manager. The Inference Engine has the ability to identify embedded templates within a template and pass execution control back to the Template Manager to fetch additional templates to execute. Using common recursive techniques, templates can be embedded with templates to develop very complex compound templates. The Node Execution Manager executes individual nodes in the decision template, generally either a conditional branch or a task to be executed. A Task Engine then executes the task itself. A multiple number of tasks are applicable to the document including, but not limited to, add, insert, edit, delete, query and fetch internal data or data from external sources. An example of an external source is legacy systems through the use of connectors to data-sources. These connectors are flexible classes and methods that use standard protocols to connect to these data-sources.

Once the Dynamic Node Engine has completed all nodes for a template, it passes control back to the Inference Engine. The Inference Engine checks to see if all templates have been completed. If so, the result is passed to an Output Manager to complete the response. The Output Manager updates internal tables via the Profile Manager, then converts the document back to the original source document type using a reverse parser. It also will append any presentation documents formats required such as XSL and CSS and pass the result back across the network to the source. Presentation formats are not limited to US English. Most foreign languages can be supported using Document Type Definitions for that Language.

An object of the present invention is to provide a system for facilitating commercial transactions over a computer driven network capable of providing communications between at least two parties. It is a further object of the invention to provide an electronic computer architecture that accommodate a wide variety of commerce transactions including those that are now currently physical in nature.

It is a further object of the invention to provide means to facilitate connections between at least two disparate systems. It is a further object of the invention to assist electronic commerce transactions by providing a mechanism for expert analysis and execution of documents by using extensible decision logic to each business document.

It is a further object of the invention to provide an abstract layer above existing applications that make it easy to implement and scale. It is a further object of the invention to provide a mechanism for the unfettered establishment of electronic commerce relationships without due regard for technologies or systems.

It is a further object of the invention to provide a mechanism for the unfettered establishment of electronic commerce relationships without due regard for any other third party participation.

Still further objects and advantages will become apparent from a consideration of the ensuring description and drawings.

Therefore, in accordance with the previous summary, objects, features and advantages of the present invention will become apparent to one skilled in the art from the subsequent description and the appended claims taken in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS FIG 1 is a flow diagram of the major constituent parts of the expert system;

FIG 2 is a more detailed flow diagram exposing the Inference Engine and its constituent parts;

FIG 3 is a more detailed flow diagram exposing the Input Manager and its constituent parts;

FIG 4 is a more detailed flow diagram exposing the Profile Manager and its constituent parts;

FIG 5 is a more detailed flow diagram exposing the Node Execution Manager and its constituent parts;

FIG 6 is a more detailed flow diagram exposing the Task Engine and its constituent parts;

FIG 7 is a more detailed flow diagram exposing the Output Manager and its constituent parts;

FIG 8 is a schematic of the primary participants and how the expert server fits into an existing coφorate network architecture. FIG 9 provides a breakdown of the components required to build the Expert Engine;

FIG 10 provides a logic chart showing the logic flow inside the Expert Engine; FIG 11 is flowchart for validation and authentication of incoming requestors;

FIG 12 is a flowchart for the validation and normalization of incoming documents;

FIG 13 is a flowchart of the Profile Manager;

FIG 14 is a flowchart of the Inference Engine; and

FIG 15 is a flowchart of the Output Manager DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The present invention can be described with several examples given below. It is understood, however, that the examples below are not necessarily limitations to the present invention, but are used to describe typical embodiments of operation. First, the reference numerals within the drawings will be listed in the table below and then the preferred embodiment will be described.

Now referring to Fig 1, the figure represents the three major components of the Expert System 100. An Input Manager 200 to receive incoming documents, the Inference Engine 400 that provides the processing logic, and an Output Manager 600 that formats and dispatches the output in a defined manner.

Fig 2 represents an exploded view of the Inference Engine. The major components of the Inference Engine 400 are the Template Manager 410 and the Dynamic Node Engine 420. The Template Manager 410 receives the input document from the Input Manager 200. The Template Manager 410 then provides the template based on the input document and the profiles attached at the input stage. Any one of the profiles, or the document itself can alter the decision template used.

For example, a request comes in for a catalogue item, a PC Workstation for a staff X. The request comes in via an XML request. This document is normalized and passed to the Profile Manager (shown in Fig 3). The Profile Manager then appends the staff/department profile, and a catalogue profile to the request

The catalogue request is passed to the Inference Engine 400. The Template Manager 410 decides the correct decision template to use and passes that template to the Dynamic Node Engine 420. The staff profile can alter what workstation configurations that are passed back as the result of the action.

Another example would be a purchase order for an item that requires customs clearance. The Profile Manager would attach details of the clearance procedure that is then passed to the Template Manager 410. A template is then assigned to follow the import procedure.

Once the Template Manager 410 has assigned a template to the document, it is passed to the Dynamic Node Engine 420. The Dynamic Node Engine 420 uses the template to pass each node in the Decision Template 430 to the Node Execution Manager 440.

Control can be passed back to the Inference Engine 400 and the Template Manager 410 if the current node requests the execution of another template. For example, a node can call another template to request import clearance documentation. The Inference Engine 400 uses recursive techniques to execute each template until all of the templates are completed 480. This way, distinct, but common decision trees can be embedded into each other resulting in highly flexible business process logic. Once all the templates are complete, the result is passed to the Output Manager 600.

Fig 3 shows the components and flow of the Input Manager 200. The Expert System receives a request from an external source. The request is validated and a session key is generated for this transaction 210. The request is validated as an XML document and the Document Type Definition are checked for validity 220. A geneπc parser can be used to parse the document for normalizing for internal processing. Alternatively, the Document type is used to identify the correct parser to normalize the document 230. The parsers 240 - 270 normalize the document for internal processing. Fig 4 shows the components for the Profile Manager 300. The profile manager attaches profile information for suppliers and other third parties such as freight, logistics and clearance houses 320, 360. It also will provide profile information for external customers, internal customers such as staff, departmental purchasing and coφorate profiles 310, 330, 340, 350. Using this module approach other profiles can be added as needed. Fig 5 shows an exploded view of the Node Execution Manager 440. The Node Execution

Manager 440 looks at the node to decide whether a decision needs to be made, such as a conditional branch 442, or other decision 444, or pass the node to the Task Engine 450. The modular Task Engine 450 then passes the execution of the node off and continues on with the decision tree.

Fig 6 is an exploded view of the Task Engine 450. The Task Engine's 450 job is to execute tasks inside the decision tree. The Task Engine 450 executes instructions within the task passed to the Task Engine 450. Using ANSI SQL compliant tables, tasks can be compound SQL statements or predefined tasks 460. Again, using a module approach, connectors can be defined to call other XML databases, or Expert Servers 490, SAP R 3 using ABAP 491, or CORBA, JDBC, ODBC COM/DCOM compliant data sources 492. Fig 7 is an exploded view of the Output Manager 600. The results of the execution are passed from the Inference Engine 400, to the Output Manager 600. The Profile Manager 300 first checks the output to see if there is any need to update the profile tables 610.

An example of a profile update may be a change m a discount structure as a result of a query to a supplier catalogue. The result is then converted back into the document type expected by the external system 630. Examples are Open Business Initiative (OBI), cXML, Biztalk, Common Business Language or other XML based formats 640 - 670. Another option is to pass back presentation information if the external system requires formatting information. Examples of formatting are CSS and XSL 680.

Fig 8 provides a view of how the expert server is setup in a networked environment. External organizations wish to transact business with Organization A. Organization A has a web presence 850 that provides information and services for the business. This could include marketing information and shopping facilities.

One example is when Customer 810 makes a request for a catalogue item on the company Web Server 850. The Web Server makes a request back to the Internal Expert Server 100 via an XML request. The Expert Server 100 calls the information from the Legacy System 870 for the catalogue item information, which then passes it back to the Web Server 850. The Customer 810 then wants to know the delivery time for the item in question. Web Server 850 calls the Expert Server 100 to ask the delivery timeframe. The Expert Server 100 asks for the build time from the Legacy System 870 and the delivery time and cost from the Logistics Server 820. This is passed to the customer browser along with the presentation information. The Customer 810 then wants to query an item that is not available in the existing catalogue. The

Web Server 850 asks the Expert Server 100. The Expert Server 100 asks either a third party XML Server 800, or a business portal such as Ariba or CommerceOne 830. The result is returned to the Customer browser 810 along with formatting information.

Another example is when a third party vendor wants to sell an item of Organization A. The third party server 800 calls the Expert Server 100 to ask if the item is available.

Another example is when a third party vendor wants to check on an assembly before purchase. The third party 800 passes the configuration as an XML document to the Expert Server 100. The Expert Server 100 parses the document through a rule checker and returns the result.

Fig 9 shows the hardware and software components necessary to build the Expert Server. A computer hardware platform 920 is required along with an operating system 922. Example operating systems are Windows NT Server with a Compaq Proliant Server or a AS400 with OS400 operating system. However, most platforms are supported by the preferred embodiment. Also shown are the Network Card 930 and the TCP/IP Stack 932.

Databases that can be used are an ANSI SQL compliant Database such as Oracle 924, Microsoft Sequel Server 926 or MySQL 928. This list is not exhaustive although the database needs to be JDBC or ODBC compliant. On top of the database is the Java Development Kit 934 including the Java Database Connector 936.

The Web Server 944 provides communication between the Expert Server and third party organizations running Web Servers, web browsers, and other XML compliant systems. Examples of Web Servers are Apache, Netscape Commerce Server, and Microsoft's Internet Information Server (US).

The Web Server supports Perl scripting language 938. Common examples of other languages that can be used are Active Perl for Windows NT and Mod_perl for the Apache Server. The XML Parser 940 is used to parse, generate, manipulate, and validate XML documents. Examples of popular XML Parsers include XML Parser for Java from IBM and Cocoon from the Apache Software Foundation. The Web Server uses Secure Sockets to provide an encrypted link to a third party browser 948.

Server to Server communication 946 security is provided by public key encryption techniques implemented by the various techniques dependant on the requirement of both parties. Examples are RSA Encryption, Pretty Good Privacy and Motorola's CipherNet. A Digital certificate is attached to the document to certify the authenticity of the third party. Fig 10 provides a logic chart showing the logic flow inside the Expert Engine. The Expert Engine first receives the XML document as input 950. The document is then validated and a session identifier is assigned 952. Profiles are then attached based on objects in the document 954. A decision template is assigned to the document 956, and the nodes are executed 958. If there is an embedded template 960, then control is passed back to the top of the new decision template 956. Once all nodes 962 and templates 964 are completed, the results are passed to the output for formatting and response 966. The Expert system is a set of classes and methods designed to work on document objects. Now referring to Fig 11, the document is received from the listener port on the Host System 1010. The listener program receives a request to connect to the port using Secure Layer Socket.

Additionally, the server can assign the sockets on any number of ways. For example, a set of sockets can be used for low security traffic from a superset of IP addresses and a set for high security traffic which allows access from a subset of IP address. Ports can be assigned for specific high traffic business such as the top supplier or customer.

The listener program accepts the request and creates a secure socket with the Requestor 1020. Once the socket is created, the document is called to test the nature of the document 1030. The decision is then made as to whether or not the certification is needed for the request 1040. If certification is needed, then the socket is passed off to the authentication manager to certify that the requestor is as who they say they are.

Authentication is achieved by two methods, firstly by the use of an approved certificate from a trusted authonty such as Verisign 1063 or by using standards such as X.509 from the Internet Engineeπng Task Force (IETF) 1062 or PGP from Pretty Good Pπvacy 1061. Each of the authentication methods are classes that are used to validate the document. The certificate is requested from the third party 1050, and verified from a trusted third party or through the exchange of keys 1060.

If the certificate is rejected, then a denial response is sent and the session dropped 1071. If the certificate is veπfied, then it is passed into the transaction log along with the encrypted document 1080. This is the repudiation step. This step is only required for documents that require an audit trial for repudiation.

The vast majority of transactions are query and updates, for which either the normal system will log or the ultimate application will log. For example, an update of the delivery address is usually logged in the Sales Order System, not in the Expert System. What documents need to be repudiated is controlled by the Administration Module of the system. The ultimate level of security should be a result of the security conventions decided upon by the two parties. In many instances, simple transport layer encryption may suffice for the majority of low sensitivity traffic such as a catalogue request, delivery address updates, etc The document is then securely transmitted, authenticated and passed to the XML valuator 1090.

Now reference will be made to the Document XML Validation in Fig 12. The document validation process accepts the document from the authenticator 1100. This next process validates the structure of the document prepaπng it for the Inference Engine. The process extracts the document type definition (DTD) from the document 1110. The next step is to ask whether the document has a schema that is known to the system 1120. If it is not known, then the schema is called from the remote site provided in the document 1130. Sets of classes are defined to handle popular schema 1170. Examples are Common Business Language, Biztalk, Open Business Initiative and cXML 1171, 1172, 1173. Then, two tests are performed. The first is whether the document is well formed, that is does it follow XML tag conventions? The second is whether the document is valid, which means does it conform to the DTD attached to the document 1150? If either of the tests fail, then the administrator is flagged and the document session is dropped 1160. Otherwise, the document is normalized using an internal schema for the Inference Engine 1180. This includes making sure elements are correctly typed. The normalized document is then passed to the Profile Manager 1190.

The Profile Manager in Fig 13 profiles information that assist in the execution of the document. For example, supplier information, logistics information, and data-source access. The Profile Manager accepts the instance of the document and its definition from the validation process 1200. The document is then tested for object tags that relate to objects defined outside elsewhere 1210. If there are external objects 1220, the object data is sub-classed to the document object 1230.

For example, the supplier and catalogue number are sub-classed below under the current document. This allows fast and convenient methods for extracting data for the inference engine. Supplier [SupplierSessionKey] = new Supplier(abc); Catnumber [CatNumSessionKey] = new Catnumber(def); DocSessionkey.add(SupplerSessionKey); DocSessionkey.add(CatNumSessionKey);

In this example, the document makes a request for a price and delivery timeframe for item ABCEF using UPS ground. By sub-classing, UPS within this document will allow the Inference Engine to quickly extract the information from either an internal databases or through a remote invocation to the UPS site. The subclass holds the methods and the Inference Engine does not care how the data is retrieved.

<?xml version="1.0"> <catalog> <item>

ABCDEF </item> </catalog> <freight> UPS GROUND </freight> <request> price, time

</request>

</xml>

The object profiles are sub-classed under the Document Engine 1240. Once this is complete, the instance of the XML document is passed to the Inference Engine 1250.

Now referring to Fig 14, the Inference Engine accepts the document from the Profile Manager

1300. At this point, the document object includes the definition and subclasses. The document then enters the Template Manager. The Template Manager's job is to assign a decision tree to the document object

1310. The Template itself is a document object model (DOM) instance of an XML model. It is assigned based on the nature of the document and the requestor 1320.

The execution manager fetches the template 1320 and prepares the template for execution. The node from the template is then fetched 1330. The node itself can fetch a template 1340. The node is executed 1350 using various classes previously sub-classed or from new interfaces or classes as needed

1351,1352,1353.

The Node Execution Manager tests for the end of the decision template 1360. If this is true, then the Template Manager tests to see if all the templates have been executed 1370. If this is true, then the results of the execution manager are passed to the Output Manager 1380. The Output Manager is depicted in Fig 15. The output manager receives the output from the

Inference Engine 1400. The Profile Manager then tests to see if the output has any reference to existing data objects 1410. If this is true, the profile data-sources are updated 1420. An example would be the modification of delivery address, or a change in the address of a server. The data-sources need to be assigned by the administrator 1421, 1422, 1423. At this point, the result is a well-formed valid XML document 1430. The Output Manager then tests to see if the document requires reformatting for output 1440. If so, then the correct parser is called from the classes 1441, 1442,1443. It is not always necessary to reformat the document if the recipient of the output can accept well-formed documents themselves. For example, the result of an update can simply return a well-formed XML document stating that the update was successful. The Output Manager then tests to see if presentation information is required 1460. If the recipient of the output is a browser, then presentation information will be needed to correctly display the output. If the recipient is another expert engine or server application, then presentation information will probably not be needed as the other server will do its own processing.

The Output Manager attaches presentation information if required 1470. There are a number of ways currently available to do this including CSS and XSL 1471,1472,1473. The completed document object is passed back through the port to the recipient 1480. From the description above, a number of advantages of the invention become evident. For example, the ability to tailor the business rules and logic depending on the context of the document. This allows for many different documents to be handled without the need for coding each document instance.

The ability to integrate multiple disparate supplier systems from multiple organizations is also an advantage. This invention solves this problem by using XML to normalize internally. This modular approach allows the invention to also normalize legacy interfaces such as COM and CORBA objects, ABAP and others. By normalizing the data internal to the system, the expert system can be extended to accommodate new standards in a modular fashion.

Additionally, the ability to provide extensible business logic through compound templates allows businesses to greatly improve the automation of business transactions and reduce the cost of those transactions. This also reduces the complexity of business logic.

Moreover, the expert system method and apparatus provides a highly extensible platform for business to business transactions that improves the ability of business to conduct commerce with multiple disparate suppliers and third parties. Furthermore, the use of dynamic templates and dynamic node execution overcomes the prior art's inability to respond to dynamic environments.

While the above description contains many specific details, these should not be construed as limitations on the scope of the invention, but rather as an exemplification of one of the preferred embodiment thereof. Many other variations are possible. For example the expert system could be used as an exchange gateway within organizations for bridging multiple disparate systems. Or it could be used to serve catalogues to third parties or affiliate systems.

Furthermore there are many other computer languages that the expert system can be embodied including but not limited to C, C++, Perl , Visual Basic, ASP, Oracle etc.

In addition, the expert system has the advantage that: it lends itself to diagnostic and consultative capabilities for web based application such as Customer Resource Management, Customer Service Systems, and Sales force automation. The invention also lends itself to website portal integration, web retail shopping and comparative shopping. The invention also lends itself to electronic procurement systems. Further, the system also has a capability to facilitate complex document routing. That is, it can pawn multiple documents from one document or vice verse. Each has it's own logic to follow.

Accordingly, it is appropriate that the appended claims be construed broadly and in a manner consistent with the scope of the invention.

Claims

1. A method for using an expert engine to process a plurality of business transaction documents, the method comprising: providing an input manager that, receives a document object from a plurality of entities, secures the transmission, authenticates the plurality of entities, authenticates the document object, creates a user session, assigns a profile object to the document object, then normalizes the document object according to an internal schema; providing an inference engine that, accepts the document object from the input manager, assigns a decision template to the document object for processing, processes the document object according to the decision template; and providing an output manager that, formats the response from the inference engine based upon the conditions derived from the input manager and the result derived from the inference engine, and then passes that response back to the plurality of entities, wherein the plurality of entities can transact the business transaction documents between the plurality of entities based on a current and dynamic relationship between the plurality of entities.

2. The method of claim 1 further including identifying and authenticating the document object and assigning a session identifier to uniquely differentiate a multiple user session, multiple transactions and multiple transaction states.

3. The method of claim 1 further including maintaining and assigning a plurality of profiles to a plurality of internal and external organizational and data entities.

4. The method of claim 1 further including normalizing the document object, by a plurality of parsers, to a common internal schema to allow orderly passage through the inference engine.

5. The method of claim 1 further including assigning, by the template manager, to the document object, a set of rules for formulating a decision template based on the document object and prevailing environmental conditions.

6. The method of claim 1 further including traversing the decision template, by a dynamic node engine, and passing a node to a node execution manager.

7. The method of claim 6 further including managing, by a node execution manager, the execution of tasks inside the inference engine in order to effect the decision template.

8. The method of claim 1 further including updating the plurality of profiles, by a profile manager, based on the results obtained from the inference engine.

9. The method of claim 1 further including converting, by a plurality of parsers, normalized internal schema into external document objects, and supplementary document attachments depending on the requirements of output format.

10. A system for facilitating commercial transactions between a plurality of entities over a computer network capable of providing communications between the plurality of entities, the system comprising: a means for accepting a document object from a plurality of entities and from a plurality of disparate systems, a means for inferring a plurality of decisions based upon a context of the document object, a means for executing the plurality of decisions; and a means for outputting data to the plurality of disparate entities with a plurality of disparate requirements.

11. The system of claim 10 further including a means for identifying and authenticating the document object and assigning a session identifier to uniquely differentiate a multiple user session, multiple transactions and multiple transaction states.

12. The system of claim 10 further including a means for maintaining and assigning a plurality of profiles to a plurality of internal and external organizational and data entities, and assigning a subset of the plurality of profiles to a plurality of document objects.

13. The system of claim 10 further including a plurality of parsers that normalize the document objects to a common internal schema.

14. The system of claim 10 further including a means for assigning the document object, a set of rules for traversing an assigned decision template based on the document object itself and prevailing environmental conditions.

15. The system of claim 10 further including a means for executing the decision template but reciting a node inside the decision template.

16. The system of claim 10 further including a means to manage the execution of tasks from a plurality of nodes.

17. The system of claim 10 further including a means for accepting the result and structuring the result suitable for response back to the plurality of entities.

18. A system for facilitating commercial transactions between a plurality of entities over a computer network capable of providing communications between the plurality of entities, the system comprising: a means for accepting a document object from a plurality of entities and from a plurality of disparate systems, a means for inferring a plurality of decisions based upon a context of the document object, a means for executing the plurality of decisions; a means for outputting data to the plurality of disparate entities with a plurality of disparate requirements; a means for identifying and authenticating the document object and assigning a session identifier to uniquely differentiate a multiple user session, multiple transactions and multiple transaction states; a means for maintaining and assigning a plurality of profiles to a plurality of internal and external organizational and data entities, and assigning a subset of the plurality of profiles to a plurality of document objects; a plurality of parsers that normalize the document objects to a common internal schema; and a means for assigning the document object, a set of rules for traversing an assigned decision template based on the document object itself and prevailing environmental conditions.