Method for the standardization and syndication of business transactions

RELATED APPLICATION

[0001] This application is a continuation of pending U.S. provisional patent application Serial No. 60/371,292 filed on Apr. 9, 2002, which is incorporated by reference in its entirety herein.

BACKGROUND OF THE INVENTION

[0002] As the world's economies have merged into one global economy, cross border trade has gained in importance and frequency. These cross border transactions range from a simple sale of goods to complex construction projects and more. Individuals in the United States want to sell food to African corporations. French communications firms want to contract with governments in less developed countries to set up their communications infrastructure. German construction companies want to bid on an airport construction project in South America. Canadian investors want to finance a business in Indonesia. Businesses all over the world are identifying business opportunities outside of their national borders.

[0003] While economies all over the world have opened themselves to the idea of globalization, the cost of cross border transactions, in terms of money, time, and effort, has remained a barrier. Although many businesses have identified opportunities outside of their borders, they have little knowledge of the requirements for executing a cross border transaction. It may be impractical for these businesses to invest resources into understanding a specific cross border transaction, when the change of one variable, such as the country of origin of the goods or the type of goods, may call for a completely different process. Even when a business identifies an opportunity that requires the execution of the exact same transaction every time, the transaction may still prove to be too costly. Such transactions can require as many as 200 documents to complete one deal. It can take six months or longer to process paperwork. Legal and other procedural costs have averaged seven percent of a transaction's value, as high as fifteen percent. Businesses of all sizes have held back from entering a growing and lucrative global marketplace because of the awesome paperwork load, its expense and incalculable variable costs. In order to maximize trade efficiencies on a global scale, the overhead costs of cross border transactions must be reduced to a practical level.

[0004] Others before have attempted to implement electronic solutions to reduce the high overhead costs of international transactions. While many of the systems implemented are excellent task performers, they lack the flexibility and interoperability to handle the expansive range of international transactions. These systems are typically designed to handle a specific transaction for a large Fortune 1000 company, but because these products are proprietary, conflicting application standards prevents cost effective seamless interoperability among enterprises. The expense and inefficiency of constant system updating and reengineering in order to interface with multiple information technology systems in the execution of one desired transaction does not equate to the desired comprehensive solution to reduce overhead costs across all cross border transactions.

OBJECTS AND SUMMARY OF THE INVENTION

[0005] The present invention overcomes the prohibitive overhead costs of international business transactions by providing a systemic approach to all business transactions, whether across international borders or across the street. It overcomes the problems associated with the transfer of information by communicating through a standardized universal language over an open architecture. It overcomes the problems associated with delay through the dynamic acquisition and storage of relevant information and documentation along with the simultaneous execution of required actions. It defines a business method for the efficient execution of any business transaction, as well as a system that implements that method. In effect, it provides businesses all over the world, regardless of their size, with a tool to efficiently and seamlessly conduct business transactions by simply specifying the goals of their desired transaction.

[0006] It is an object of the present invention to provide a method for standardizing and syndicating international business transactions over a communications network, comprising the steps of receiving a transactional request containing terms of the business transaction from a client and categorizing the transaction into pre-defined categories. The method retrieves the functional templates for the pre-defined categories from a database and generates functional aspects of the business transaction, such as forms, documents and the like, based on the terms of the business transaction and client information to enable the client to execute the business transaction.

[0007] In accordance with an embodiment of the present invention, the system dynamically collects and stores information, forms, documents, etc. relevant to the conduct of the nearly infinite range of known transactions in a central repository, or various repositories. The system may acquire such information from strategic partnerships with entities such as world trade organizations, national government agencies, local government agencies, private companies dedicated to the acquisition of such information, etc. The system may also acquire such information from publicly available sources, including databases connected through communications networks.

[0008] In an embodiment of the present invention, the system links the acquired information according to a certain transaction grouping. For example, after acquiring the required construction permits for building a road in Brazil, the system can store such permits under one or more groupings, such as, Brazilian Road Construction, Brazilian Project, Road Projects, etc. The system can link such information under one or more transactional groupings in any manner known in the art of data storage and indexing.

[0009] According to an embodiment of the present invention, the system constantly updates the stored information, forms, documents, etc. to ensure that such information is not outdated. The system can update this information automatically through scheduled updates or triggers or any other fashion. The system can also invoke manual updates in response to specific requests or as a system check or for any other purpose. Furthermore, the system operator or administrator can partner with a governmental organization, a private company or other entities to ensure the “freshness” of the information in the system, such as new governmental regulations or new rate structures, etc.

[0010] In an embodiment of the present invention, the system solicits transaction parameters from a user and identifies, from its repository (or repositories), a specific transaction or transactions consistent with those parameters. Once the system ensures that the correct transaction(s) has (have) been identified, the system can develop a transaction template, which guides the execution of the identified transaction(s), and then display it to the user. The template can comprise the following illustrative list of features or any combination thereof: a list of the required steps to execute the desired transaction(s); a list of the documents that need to be completed to execute the transaction(s); instruction on how to acquire and/or complete those documents; links to electronic versions of such documents; links to submit those documents to the proper authorities; a list of governmental approvals required; contact information (such as phone number, e-mail, fax number, etc.) for the appropriate authorities who provide such approvals; guidelines for acquiring such approvals; electronic applications for such approvals; lists of buyers for goods; lists of sellers of goods; contact information for such buyers or sellers; platforms for electronically negotiating prices and quantities between the buyers and sellers; lists of shipping companies that pick up and deliver such goods, from and to such locations; electronic reservation and payment form for such shipping companies; lists of banks/investors that fund such transactions; etc.

[0011] In an embodiment of the present invention, the system utilizes open standards in its system architecture to enable the system to acquire data from its data sources and deliver information to trading partners. This open standards-compliant hub architecture overrides incompatible application platforms and enables coherent message and document transmission between trading partners. Open proficiency effects process integration with back-end operating systems. Companies or countries engaging in electronic cross border trade may agree to communication and information specifications for transaction protocols. These protocols become the guidelines for processing electronic commerce within the hub. Trading partners do not need a common set of hardware, operating systems, middle-ware, or application software, nor must they be aware of their counterpart's IT competence in order to do business with one another. Trading partners may control and guide the business process, which is isolated from the technology process, and are solely responsible for confirmation or cancellation of a result.

[0012] In a preferred embodiment of the invention, there are two categories of protocol, one for the business process, the second for the technology process, both protocols being harmonized within the hub. Business process protocols may be organized into partner-specific modules constructed by congregating data templates delineating a trading partner's IT capabilities and, for a company, identification data (ISO, NAICS, ANSI, SITC codes, etc.), industry role (i.e., producer, service provider, distributor, location(s), business history, management), local laws, national treaties and agreements relevant to cross border trade, etc. For a country, a module may encapsulate geography, population, government, economy, literacy, languages, computer literacy, suffrage, labor force, treaty, pact and trade bloc signatories, basic industries, natural resources, trade partners, communications, transportation and defense forces. The technology process protocol applies open source XML language to translate business process input and synchronize multiple platforms into standards-consistent messages, documents or other acknowledgments. ISO 15022 principles make possible the conversion of any message or document type to support specific information flows. Outcomes are governed by the precepts of the business process, not by a central design authority, and a durable record of decisions is compiled to allow consideration of numerous possible successful outcomes, such as various what if outcomes.

[0013] In an embodiment of the present invention, the system utilizes known or proprietary encrypted technology to provide secured communication between various parties to the transaction. For example, when instructed by a trading partner, the system can encrypt resulting documents to provide secured documents that are accessible only by the trading partners or their agents. Each trading partner's process implementations can be kept independently, and trade transaction complexity may be embedded and automated within the system's hardware and software infrastructure. Furthermore, intuitive computing can restate results in the originating language such as English, French, German, Russian, Japanese, various dialects of Chinese, etc., of each trading partner enabling real-time interaction and informed decisions.

[0014] It is an object of the present invention to provide a system and technique for more efficiently conducting international trade.

[0015] It is also an object of the present invention to provide a system and technique for syndicating international trade.

[0016] It is another object of the present invention to provide a system and technique that simply, efficiently, and effectively guides businesses and individuals through complex transactions, whether within a nation's border or across international borders.

[0017] It is yet another object of the present invention to provide a system and technique that simultaneously executes the various tasks involved in a complex transaction, whether within a nation's border or across international borders.

[0018] It is still another object of the present invention to provide a system and technique that utilizes open standards in its system architecture so that the various systems of the parties involved in a transaction may effectively communicate with one another absent the barrier of reconfiguring their systems for the sake of compatibility

[0019] It is a further object of the present invention to provide a system and technique that effectively centralizes the resources needed to complete complex transactions, whether within a nation's border or across international borders.

[0020] It is yet a further object of the present invention to provide a system and technique that indexes and stores the information collected regarding a specific transaction in such a manner that future users may easily and efficiently reuse such information in the completion of identical or similar transactions, or transactions which involve identical or similar steps in their completion.

[0021] Various other objects, advantages and features of the present invention will become readily apparent from the ensuing detailed description, and the novel features will be particularly pointed out in the appended claims.

BRIEF DESCRIPTION OF THE DRAWINGS

[0022] The following detailed description, given by way of example, and not intended to limit the present invention solely thereto, will best be understood in conjunction with the accompanying drawings in which:

[0023]FIG. 1 is a block diagram of the system architecture of an embodiment of the present invention; and

[0024]FIG. 2 is a flow chart for the system process of an embodiment of the present invention; and

[0025]FIG. 3 is a block diagram illustrating a logical view of the system architecture of FIG. 1; and

[0026]FIG. 4 is a flow chart illustrating the data flow in accordance with an embodiment of the present invention; and

[0027]FIG. 5 is a flow chart for processing a request for information in accordance with an embodiment of the present invention; and

[0028]FIG. 6 is a flow chart for processing a request for business transaction in accordance with an embodiment of the present invention.

DETAILED DESCRIPTION OF THE EMBODIMENTS

[0029] Currently available communications apparatus and electronic components readily implement the present invention. The invention finds ready application in virtually all-commercial communications networks, including, but not limited to, an intranet, a local area network (LAN), a wide area network (WAN), World Wide Web, a telephone network, a wireless network, and a wired cable transmission system.

[0030] The present invention avoids the weaknesses of current systems by facilitating the execution of complex transactions, including international transactions, by utilizing open standards in its system architecture and allowing compatibility between the systems of all parties involved in such transactions. Additionally, the present invention provides the benefit of flexibility, as it has not been tailored for the transactional needs of any particular business or industry. The system of the present invention is dynamic and systematically and comprehensively collects the required information and resources required to guide the execution of and/or execute transactions as requested by its users. The system also stores and indexes the information collected for requested transactions in such a manner that it allows for syndication of one or more components of those transactions.

[0031] Turning now to FIG. 1, the block diagram illustrates an ergomundus system <b>10</b> (or system <b>10</b>) in accordance with an embodiment of the present invention. According to this embodiment of the present invention, clients <b>120</b> initiate the transaction by contacting the system hub or ergohub <b>100</b>. The hub <b>100</b> solicits information from such clients <b>120</b>, including, but not limited to, transaction parameters and client or user profile information. The hub <b>100</b> processes such solicited information and compares the solicited transaction parameters to transaction parameters that have been previously categorized, indexed, and stored in the system repository or database <b>300</b>. It is appreciated that within the system repository, data warehouse or database <b>300</b>, transaction parameters may be connected to align specific cross border transactions or parts thereof either automatically by the system hub <b>100</b> or through manual labor.

[0032] In accordance with an embodiment of the present invention, the business transactions are based on template, profile and informational need of each client. The business transactions are predefined and coded for each client. There is a single modular transaction for each subtask associated with the completion of a particular business transaction. Client profiles provide client specific information based on pre-negotiated terms and conditions, such as security issues, customer base, country preference etc. Templates are internal ergopro instructions to locate the required information or instruction to complete the requested transaction. Ergopro <b>200</b> is a software application residing in the ergohub <b>100</b>, which utilizes ergodna or ergomundus dynamic navigational architecture. Ergopro <b>200</b> formulates, personalizes, secures, stores, information locates, places in a ‘folder’ and executes to a predefined state of completion of the business transaction. Foldering is the process whereby data from many different sources is collected and stored in one location within the ergopro application.

[0033] The system <b>10</b> maintains a data warehouse <b>300</b> for all information and process within a secure environment. The data repository or data warehouse <b>300</b> contains information such as forms, laws, logistics, transportation information, trade agreements, export procedures, maps, tax instructions, etc.

[0034] The process of initiating a business transaction using the ergomundus system <b>10</b> in accordance with an embodiment of the present invention is now described in conjunction with FIG. 1. The client <b>120</b> submits a client request to the ergomundus system <b>10</b> via a communications network, such as telephone network, cable network, local area network, Internet, etc., using a standard web browser or graphic user interface (GUI) in step <b>1000</b>. The ergomundus system <b>10</b> routes the client request to the appropriate ergohub <b>100</b> in step <b>1010</b>. It is appreciated that the ergohub <b>100</b> can be a single machine (or computer) or a collection of machines. The ergohub <b>100</b> executes specific functions to determine requirements, location, client rights, client profiles, etc. In accordance with an embodiment of the present invention, the ergomundus system <b>10</b> determines a particular ergohub <b>100</b> and/or configuration of the ergohub <b>100</b> based on the geographical and functional requirements of the client's business transaction.

[0035] The ergopro <b>200</b> initiates transaction preparation module <b>250</b> to assign entitlements and prepare the business transaction, such as legal issues, whether the contemplated business transaction is allowed in the selected country, countries and companies included in the business transaction, etc., in step <b>1020</b>. Also, the ergopro <b>200</b> sets up retrieval procedures <b>240</b> to retrieve information from the internal database <b>300</b> or to interface with external systems through application protocol interface (API) <b>230</b>, preferably an open architecture interface, in step <b>1030</b>. In many cases, the information required to transact business through the ergomundus system <b>10</b> has been already collected and stored in the business intelligent warehouse database <b>300</b>. In accordance with an embodiment of the present invention, if the requisite information is available from the system database <b>300</b>, then ergopro <b>200</b> sets up background processes in step <b>1030</b>, such as high speed search engine (HPSE) <b>430</b> and business intelligent (BI) process <b>440</b>, to search and retrieve the information from various information repositories of the system database <b>300</b> in step <b>1040</b>. The system database <b>300</b> contains various information repositories to hold legal information, logistics information, client information, etc.

[0036] However, if the requisite information is unavailable from the system database <b>300</b>, then ergopro <b>200</b> sets up background processes, such as API <b>230</b>, to interface with an external system (e.g., governmental databases), or hyper text transfer protocol (HTTP) process <b>410</b> or web application server (WAS) process <b>420</b> to access the Internet in step <b>1030</b>.

[0037] For example, the system database <b>300</b> may contain information on the construction of an airport in Beirut. One step of this construction project may have been the bidding process to obtain the Lebanese Government contract for the construction of the airport. If bidding for government contracts in Lebanon had been previously conducted through this system <b>10</b>, then the hub <b>100</b> has already stored the required documents, contacts, fees, process steps, etc., that were needed to correctly execute the bidding process for government contracts in Lebanon. Also, the hub <b>100</b> has already categorized and indexed this information accordingly within the system <b>10</b>. In another embodiment, a system administrator or operator manually enters, categorizes, and indexes the bidding information into the system <b>10</b> after researching that information. In still another embodiment, the hub <b>100</b> may continuously or periodically research databases around the world for the bidding information. In yet another embodiment, the system <b>10</b> operators or administrators partner with governments and/or private firms around the world to collect such transaction information for the system <b>10</b>. In other embodiments of the present invention, the methods mentioned above, in addition to countless others could be used to update the system databases <b>300</b> with the required transactional information for a variety of transactions and parts thereof.

[0038] In an embodiment of the present invention as illustrated in FIG. 1, based on the transactional information already stored in the system database <b>300</b>, the hub <b>100</b> generates functional transaction templates for each transaction category or sub-category. These functional templates include but are not limited to templates for generating business documents, templates for collecting the relevant contact information, templates for calculating fees associated with the transaction, templates for generating electronic links to sources of further information, templates for generating flow charts of the optimal steps required in completing the transaction or certain steps of the transactions, templates for generating communication links with parties to the transaction, etc. In the Beirut airport example, based on the bidding information previously collected, categorized, indexed, and stored in the system database <b>300</b>, the hub <b>100</b> may have generated document templates for all the forms that must be completed and submitted to the Lebanese government in order for a bid to be considered; fee templates for all the fees that must be submitted to the Lebanese government, the form of such fees, and the payees to which such fees may be address; contact templates with listings of government officials to be contacted for specified reasons and hyper-text links to their email addresses. In accordance with an aspect of the present invention, FIGS. <b>3</b>-<b>6</b> show an implementation of the inventive system of FIG. 1.

[0039] In an embodiment of the present invention as illustrated in FIGS. 2, 5, and <b>6</b>, the hub <b>100</b> houses the transaction parameters solicited from the client to search for pre-categorized transaction parameters stored and indexed in the system database <b>300</b>. If the hub locates matching transaction parameters, then the hub <b>100</b> accesses the functional templates stored in connection with such transaction parameters and retrieves such functional templates for the client's use. In an embodiment of the present invention as illustrated in FIG. 2, the hub <b>100</b> can collect matching templates in a single folder as it processes its search for all templates that may be connected to the specified transaction or steps thereof. In another embodiment of the present invention the system <b>10</b> may collect the functional templates identified via the solicited transaction parameters in different folders labeled according to a specific part of the transaction. In still another embodiment of the present invention, the hub <b>100</b> may collect such functional templates in a single folder with subfolders identifying templates with specific portions of the transactions. In other embodiments of the present invention the methods identified above for the collection and retrieval of the functional templates in addition to countless others may be used by the hub <b>100</b> to access and retrieve the functional templates for a specific transaction. For example, if a user is interested in building an electric plant in Beirut, and the bidding process for Lebanese Government contracts with related functional templates have been categorized, indexed, and stored in the system database <b>300</b>, then the hub <b>100</b> may collect the Lebanon Government Contract Bidding templates in a folder labeled as Lebanon Government Contract Bidding as it searches for other templates associated with the building of an electric plant in Lebanon.

[0040] An exemplary manner in which the ergomundus system <b>10</b> processes a business transaction in accordance with an embodiment of the present invention is now described in conjunction with FIG. 2. The client <b>120</b> accesses the ergomundus homepage via the Internet and requests access to the ergomundus system <b>10</b> in step <b>1050</b>. For example, the client may enter userid, password, and other information to access the ergomundus system <b>10</b>. In accordance with an embodiment of the present invention, the information is entered on a pre-designed screen based on the transaction type and entitlements. The ergopro <b>200</b> verifies or performs security checks based on the userid and password in step <b>1060</b>. In accordance with an embodiment of the present invention, the ergopro <b>200</b> may request the client <b>120</b> to answer additional questions as part of the security check in step <b>1060</b>. Alternatively, various other security measures can be utilized, which can be chosen by the client. Once the client <b>120</b> has been verified as an authorized user, ergopro <b>200</b> provides the client <b>120</b> with an access to the ergomundus transaction homepage.

[0041] The ergopro <b>200</b> inserts a predefined client profile from the ergo or system database <b>300</b> in a dynamic data folder, which may comprise multiple sub-folders, to control compatibility with ensuing transactional insertions, as described herein, in step <b>1070</b>. For example, the client profile may contain various client specific information based on pre-determined parameters established between system provider (e.g., ergomundus) and the client, such as legal information, trade agreements, client contractual agreements, permitted transactions, countries, transaction types, such as business to business, procurement, business to government, etc.

[0042] The ergopro <b>200</b> inserts an entitlement guide to specific international trade information based on client predetermined trade agreements and legal information in the dynamic data folder in step <b>1080</b>, and business transaction navigational templates negotiated with various trading partner and defined based on client contractual agreements in step <b>1090</b>. After various client specific information are obtained, the ergopro <b>200</b> instructs one or more background processes, such as HTTP <b>410</b>, WAS <b>420</b>, HPSE <b>430</b> and BI <b>440</b> to search the system database <b>300</b>, Internet, and external systems based on the client information collected in the dynamic data folder in step <b>1110</b>. It is appreciated that the background processes can use any known searching techniques, such as web crawling. The results of the searches are captured and stored in the system database <b>300</b> for use by the ergopro <b>200</b> in step <b>1110</b>.

[0043] The ergopro <b>200</b> also files and organizes the results that was captured and stored in the system database <b>300</b> in the dynamic data folder, such as in dynamic transaction sub-folder, in step <b>1120</b>. Also, the ergopro <b>200</b> indexes the results based on the information type and associates the information to a specific client request in step <b>1120</b>.

[0044] After indexing the information, the ergopro <b>200</b> retrieves all necessary forms to complete the business transaction specified in the client request are obtained either from the system database <b>300</b> or from external systems, e.g. governmental forms from appropriate government agency, and inserted into the dynamic folder in step <b>1130</b>. The ergopro <b>200</b> completes the form (or provides form fulfillment information) using the search results and the client information in the dynamic data folder in step <b>1140</b>. Also, in step <b>1140</b>, ergopro <b>200</b> verifies that information are consistently provided in various forms, sorts and sequences the forms in appropriate order, and identifies the forms using tags or fields in the dynamic data folder. In accordance with an embodiment of the present invention, the ergopro <b>200</b> forwards any calculations and/or estimations required to complete the forms to the client <b>120</b> for review and enters such calculations and/or estimations only after receiving approval and instructions (or requests) to make such entries from the client <b>120</b> in step <b>1150</b>.

[0045] After ergopro <b>200</b> determines that all requisite forms have been completed and requisite transactional information have been collected, ergopro <b>200</b> organizes these forms and information into a presentation format suitable for display to the client <b>120</b> in step <b>1160</b>

[0046] According to an embodiment of the present invention as illustrated in FIG. 1, if the hub <b>100</b> fails to locate functional templates associated with some or all of the transaction parameters, then the hub <b>100</b> searches for the information required to complete this transaction beyond the system boundaries. The hub <b>100</b> may search databases outside of the system through various communications networks, including, but not limited to, an intranet, a local area network (LAN), a wide area network (WAN), World Wide Web, a telephone network, a wireless network, and a wired cable transmission system. In another embodiment of the present invention, a system administrator would manually acquire the information required to complete the transaction and then manually enter the information into the system <b>10</b> so the hub <b>100</b> could generate the required functional templates. In still another embodiment of the present invention, the system <b>10</b> administrators could partner with a private research firm to acquire and enter the information on demand. In yet another embodiment of the present invention, the hub <b>100</b> simply provides the client <b>120</b> with templates already stored within the system database and any parts of the transaction that are unaccounted for must be completed by the client absent the guidance of the present invention. In even another embodiment of the invention, if the database <b>300</b> does not contain a template to account for a part or all of a client's requested transaction, the hub <b>100</b> provides the client <b>120</b> with templates that are most similar in nature and characteristics for guidance in completion of the transaction. Other embodiments of the present invention may include a combination of any or all of the above-mentioned information retrieval processes in addition to countless others.

[0047] According to an embodiment of the invention as illustrated in FIG. 1, when the hub <b>100</b> retrieves information from outside the system, the hub generates functional templates based on such information. In addition to providing these templates to the client <b>120</b> in a system folder or system folders, the hub <b>100</b> also categorizes the functional templates according to the specific transaction or part thereof and stores the templates in its database <b>300</b> for future use. Continuing with the Beirut power plant example, if the only functional templates contained within the system <b>10</b> for this particular transaction are the ones relating to the bidding portion of the transaction, then the hub will reach out to databases of the Lebanese government over the World Wide Web and access the required information for the remaining portions of the transaction. The hub <b>100</b> has security clearance with respect to these databases through a partnership with the Lebanese government. In an embodiment of the present invention, the hub <b>100</b> will be able to access the databases on the Lebanese government's systems because the system of the invention uses an open system architecture, which freely allows electronic data exchange and messaging throughout the world.

[0048] In accordance with an embodiment of the present invention, the system <b>10</b> utilizes open standards in its system architecture to enable the system <b>10</b> to acquire data from its data sources and deliver information to trading partners. This open standards-compliant hub architecture overrides incompatible application platforms and enables coherent message and document transmission between trading partners. Open proficiency effects process integration with back-end operating systems. Companies or countries engaging in electronic cross border trade may agree to communication and information specifications for transaction protocols. These protocols become the guidelines for processing electronic commerce within the hub. Trading partners do not need a common set of hardware, operating systems, middle-ware, or application software, nor must they be aware of their counterpart's IT competence in order to do business with one another. Trading partners may control and guide the business process, which is isolated from the technology process, and are solely responsible for confirmation or cancellation of a result.

[0049] According to an embodiment of the present invention as illustrated in FIG. 2, the hub <b>100</b> delivers a folder or folders containing the functional templates required to complete the specified cross border transaction. The hub <b>100</b> may use these templates in combination with the information solicited from the client <b>120</b> to generate the functional aspects of the transaction including, but not limited to, business documents, contact sheets, information links, communication channels, lists of fees, document submissions, fund deliveries, shipping instructions, etc. In another embodiment of the present invention, the hub <b>100</b> may simply deliver the folder or folders of functional templates to the client <b>120</b> without generating the functional aspects of the transaction. In still another embodiment of the present invention, the hub <b>100</b> may generate one or more of the functional aspects of the transaction while providing the client <b>120</b> with the templates for other aspects of the transaction. In yet another embodiment of the present invention, the hub <b>100</b> may generate one or more of the functional aspects of the transaction, provide templates guiding one or more other aspects of the transaction, and provide no guidance for the remaining aspects of the transaction. In the context of the Beirut power plant example, the hub <b>100</b> may generate all of the business documents with respect to the bidding portion of the transaction, submit those bidding documents electronically to the Lebanese government, and transfer funds from the client's account to the appropriate Lebanese government accounts in satisfaction of the fees. Furthermore it may provide templates for ordering supplies from sources all over the world, templates for arranging communication links with authorities in the Lebanese government to discuss the status of the bid, templates for preparing the financial arrangements to finance the project in case the client <b>120</b> wins the bid, etc. Meanwhile other aspects of this complex transaction may be left to the user to complete without guidance.

[0050] Turning now to FIG. 3, there is illustrated a logical view of the system architecture in accordance with an embodiment of the present invention. The message queue module <b>210</b> of the ergopro <b>200</b> sends and receives information from other components of the system <b>10</b> via the message queue <b>220</b>, which is uniquely assigned to each business transaction. It is appreciated that any known message queuing techniques and products can be utilized, such as IBM MQSeries® messaging product. Each server, background processes and applications supporting a particular business transaction can communicate with the ergopro <b>200</b> via a unique message queue (MQueue) <b>110</b> established for or assigned to that business transaction. The ergopro <b>200</b> communicates with each server, such as database <b>330</b>, HPPT <b>410</b>, WAS <b>420</b>, HPSE <b>430</b> and BI <b>440</b>, via a unique API module <b>230</b>. For example, if the ergopro <b>200</b> wants to transmit a function call, e.g., a stored procedure for updating the database, to the system database <b>300</b> for a particular transaction, then the message queue module <b>210</b> formulates the request and places or puts the requested function call in the message queue <b>220</b> associated with that transaction (or the requesting message queue <b>220</b>) in step <b>3000</b>. The message queue module <b>210</b> delivers the requested function call in the requesting message queue <b>220</b> to the API module <b>230</b> of the system database <b>300</b> in step <b>3010</b>. The API module <b>130</b> then sends the database call to the system database <b>300</b> and a matching set of stored procedures completes the necessary database task, such as updating the database, in step <b>3020</b>. It is appreciated that certain information in the database <b>300</b> can be linked or related, such that any changes to a particular information may require its related information to change accordingly. For example, if the Chinese government changes its currency regulations, this may impact not only information regarding Chinese law, but may also impact procurement information, financing information, etc., for any Chinese related transaction. Accordingly, database triggers can be used to initiate new/changed requirements for all appropriate tables in the database <b>300</b> and to initiate changes to the result presentation.

[0051] The looping response module <b>260</b> of the message queue module <b>210</b> monitors the requesting message queue <b>220</b> to determine if the request is completed (i.e., a successfully completed message or an error message) in step <b>3030</b>. If the looping response module <b>260</b> determines that there is a message in the requesting message queue, then the message is retrieved from the requesting message queue <b>220</b> by the message queue module <b>210</b> of the ergopro <b>200</b> in step <b>3040</b>.

[0052] Turning now to FIG. 4, there is illustrated a data flow chart in accordance with an embodiment of the present invention. The message queue module <b>210</b> of the ergopro <b>200</b> initiates the message queue <b>220</b> in step <b>4000</b> and determines if there is a message in the message queue <b>220</b> in step <b>4005</b>. If it is determined that there is no message in the message queue <b>210</b>, then ergopro <b>200</b> proceed to step <b>4030</b> to process new order, i.e., building new business transactions for the clients. However, if it determined that there is a message in the message queue <b>220</b>, then the ergopro <b>200</b> extracts and checks the information or data contained in the message in step <b>4010</b>. Also, the ergopro <b>200</b> may reformat the data, if necessary, based on the record type. For example, data obtained from the Internet or an external system may need to be reformatted into the data standard of the ergomundus system <b>10</b>.

[0053] After the data in the message has been confirmed, the ergopro <b>200</b> determines source of the message to associate the information to a pending business transaction process or folder or to create new business transaction process in step <b>4020</b>. After the source of message or send has been identified, the ergopro <b>200</b> associates the message to the appropriate pending business transaction or creates new order process in steps <b>4030</b> and <b>4040</b>. If the message is determined to be from the Web, such as a new request from client <b>120</b> or information from the Internet or external system, then ergopro <b>200</b> proceeds to step <b>4040</b> to dispatch the message and the information contained therein to the appropriate pending business transaction or create new business transaction for new client based on the client profile and template designation information. Otherwise, if the message is determined to be from the ergomundus system <b>10</b> (i.e., direct request), such a message containing an update function, funds transfer, etc., the ergopro proceed to step <b>4030</b> to setup a new order or background process to complete the task.

[0054] After dispatching the request/message to the appropriate business transaction or creating new transaction based on the client profile and template designation obtained from the system database <b>300</b>, the ergopro <b>200</b> formulates a response to the request/message in step <b>4060</b> and stores the request/message in the system database <b>300</b> in step <b>4070</b>. The ergopro <b>200</b> determines if the database <b>300</b> has all the necessary data and information (i.e., response key flag is “on” or response key is available in the response key table) to build a response in step <b>4080</b>. The response key table is stored in the system database <b>300</b>. If it is determined that the response key is available for this particular request, then ergopro <b>200</b> formulates the response in step <b>4090</b>. However, if it is determined that the response key is unavailable for that particular request, then the ergopro <b>200</b> returns to step <b>4000</b> to add the message back in the appropriate message queue base on the request type.

[0055] Turning now to FIGS. 5 and 6, there is illustrated a flow chart for processing an exemplary “simple” request for information and an exemplary “complex” request for business transaction execution, respectively, (i.e., types of business transaction) by the ergomundus system <b>10</b> in accordance with an embodiment of the present invention. The client <b>120</b> requests a business transaction (i.e., a request for information) in step <b>5000</b>. Based on the client profile, template and required forms and documents, ergopro <b>200</b> begins the process of creating a dynamic folder and search criteria in step <b>5010</b>. The ergopro <b>200</b> captures and compiles the appropriate forms, documents and information, such as export procedures, tax instructions, bill of lading, bill presentment, calculations, payment procedures, laws, trade agreements, logistics, etc., in step <b>5020</b> and stores the results in a dynamic data or transactional folder uniquely associated with the client request in step <b>5030</b>. Also, ergopro <b>200</b> transmits the results or the dynamic transaction folder to the client <b>120</b> in step <b>5030</b> and stores the results in the system database <b>300</b>, which categorizes and organizes the information for automatic updating and syndication to optimize future request for the same or similar information in step <b>5050</b>. The stored data may become stale over time or changed by the data owner (i.e., information was obtained from UN and UN has now changed the data), which renders the stored data useless. Accordingly, instead of refreshing the data on demand, the system automatically updates the data when the underlying data is changed by the data provider or owner. However, if ergopro <b>200</b> is unable to process or respond to the request, then ergopro <b>200</b> generates an error message in step <b>5040</b>. For example, the requested information may be currently unavailable from the system database <b>300</b>.

[0056] While the present invention has been particularly described with respect to the illustrated embodiment, it will be appreciated that various alterations, modifications and adaptations may be made based on the present disclosure, and are intended to be within the scope of the present invention. It is intended that the appended claims be interpreted as including the embodiment discussed above, those various alternatives, which have been described and all equivalents thereto.