WO2005022345A2

WO2005022345A2 - Business software application system and method

Info

Publication number: WO2005022345A2
Application number: PCT/US2004/028002
Authority: WO
Inventors: Ali Jani; Nayan Vadher; Harsha Sarjapur; Sanjay Shah
Original assignee: Icode, Inc.
Priority date: 2003-08-29
Filing date: 2004-08-27
Publication date: 2005-03-10
Also published as: CA2537156A1; WO2005022345A3

Abstract

A business softwaree application system and method integrates an e-mail management system, and e-mail client system, and HTML page generator system and a credit card payment processing system. The mail management method and system tracks correspondence exchanged with external entities such as customers and vendors, through e-mail messages, and the internal internal users of the system and the e-mail messages are then desirably imported into business software (of various types) and linkages created to such external entities within business software, from the E-mail Clients.

Description

BUSINESS SOFTWARE APPLICATION SYSTEM AND METHOD

Priority Claims

This application claims priority, under PCT Treaty Rule 4.10, PCT Article 8(1) and Article 4 of the Paris Convention, to: 1) U.S. Provisional Patent Application Serial No. 60/498,911, filed on August 29, 2003 and entitled "Mail Management System and Method"; 2) U.S. Provisional Patent Application Serial No. 60/498,877, filed on August 29, 2003 and entitled "E-mail Client System and Method"; 3) U.S. Provisional Patent Application Serial No. 60/499,046, filed on August 29, 2003 and entitled "HTML Page Generator System and Method"; 4) U.S. Provisional Patent Application Serial No. 60/498,878, filed on August 29,

2003 and entitled "Credit Card Payment Processing System and Method"; 5) U.S. Patent Application Serial No. 10/847,776, filed on May 17, 2004 and entitled "Mail Management System and Method"; 6) U.S. Patent Application Serial No. 10/848,427, filed on May 17,

2004 and entitled "E-mail Client System and Method"; 7) U.S. Patent Application Serial No. 10/847,801, filed on May 17, 2004 and entitled "HTML Page Generator System and Method"; and 8) U.S. Patent Application Serial No. 10/847,769, filed on May 17, 2004 and entitled "Credit Card Payment Processing System and Method".

Field of the Invention

The present invention relates generally to a business software application system and method that integrates an e-mail management system and method, an e-mail client system and method, a HTML page generator system and method and a credit card payment processing system and method.

Background of the Invention

Business software applications are well known. These business software applications typically have various functions that are beneficial to a business user. For example, the business software application may include customer relationship management (CRM) systems or an ERP system. Typical business software applications do not have an integrated approach that permits the business software application user to integrate his business software application with other necessay and desirable tools and functions. For example, it would be desirable to provide a business software application that has an integrated mail management system, an e-mail client, a system for generating static HTML pages and a system for processing credit card transactions. Each of the integrated systems permits the business software application user to perform mail management functions, e-mail functions, HTML page generation functions and credit card processing functions without having to use another piece of software to perform those functions.

In the context of mail management, e-mail correspondence has become an integral part of modern business operations. The increased effort to use the electronic mailing in business is due to the fact that electronic mailing is extremely cost effective and less time consuming, hi particular, an electronic message does not require any postage and can be generated from any computing device with an E-mail Client. Furthermore, the physical delivery by regular postal mail ("snail mail") takes time whereas e-mail can be delivered instantaneously.

It is desirable to maintain a linkage between external e-mail correspondence and related entities within business software applications, hi particular, it is desirable to be able to accurately capture and track business e-mail correspondence and then generate Tasks and the like based on the e-mail correspondence. However, despite the fact that e-mail is being used extensively in modern business, there has been no method or system by which these e- mails can be automatically stored in a business software application and have Tasks and other actions generated from these e-mail messages. Typically, one must resort to printing of the messages or generating manual markings or reminders in the business software applications. This typical processes are slow, tedious and inefficient.

There are currently two Internet standards for the submission and receipt of e-mail messages between a client and a post office (electronic mail server/system). The first one is "Post Office Protocol Version 3" known as 'POP3' and the second one is "Internet Message Access Protocol" known as 'IMAP'. If one uses a "POP3" Post Office/Server, then it is necessary for the client to download the e-mails in a local directory whereas if a client uses an "IMAP" Post Office/Server, he/she need not download the message into a local directory. The EVIAP protocol, although space saving in terms of computer hard disk since the messages are not downloaded to a local directory, creates the possibility for mistakes in not keeping proper track of the incoming/outgoing e-mails and actions connected therewith since there is not a local copy of the messages, hi both systems, it is not possible to download a message and link it with existing business software applications. There also exists a third known e- mail message protocol, "Messaging Application Programming Interface" ("MAPI"), which is exclusively used by Microsoft. The MAPI protocol is very much like MAP, but provides extended features within Microsoft Outlook, which is an Microsoft's E-mail Client software. Other popular E-mail Client software includes Entourage (IMAP, POP3), Mac Mail (LMAP, POP3), Eudora (POP3), Outlook Web Access (Hypertext Transfer Protocol i.e. HTTP), Outlook (MAPI, LMAP, POP3) and Outlook Express (POP3, LMAP). The proposed e-mail management system of the present invention integrated into a business software application ensures reduced manual labor with the greatest possible linkage of various bodies of related data. With respect to the integrated e-mail client system, any business organization would greatly benefit from an e-mail system that is integrated into its business software that is used to automate its processes and enables it to effortlessly communicate with the typical entities that it interacts with such as users, vendors and customers. While many generic e-mail clients such as Outlook, Outlook Express, Outlook Web Access, Entourage, Mac Mail and Eudora are available, the fact that they may not be easily integrated and share information with custom databases specific to a business automation software used by the business greatly limits the extent to which they can be exploited. When e-mail communication data is independent of the other transactions carried out and recorded in the business software, the communication data cannot be attached, indexed and referenced or retrieved from within the business software, based on the entities for which such business transactions have been carried out. Thus, it is desirable to have an integrated e-mail client so that the organization can attach all e-mail communication exchanged with an external entity to other data in the business software that is specific to the entity and such data can be easily retrieved and examined, as and when required, by all concerned users of the software. With respect to the HTML page generation system, in a typical ASP (Active Server

Pages) driven World Wide Web ("Web") site, all the information is driven through the database and nothing exists in those ASP pages. A dynamic Web page is a template that displays specific information in response to queries. Most of the Web page content comes from the database connected to the Web site. These sites are easy for webmasters to update, such as new/different product offerings or prices change, as they just need to edit the database instead of hundreds of individual Web pages. However, many spiders/crawlers of search engines prefer not to search dynamic Web pages to avoid the constraints involved in search optimization. As the pages generated by e-commerce applications are dynamic in nature, it is desirable to generate static HTML Web pages for an online shop. In other words, the limitation of the known Web browsers and Web Servers is that they are designed to access only HTML documents. Furthermore, typical browsers do not have the facility to cause a Web Server to retrieve and return a non-HTML document. This inhibits a User from accessing non-HTML objects, documents or databases from Web browsers. Thus, it is desirable to provide a PageBoost system (HTML generator system and method) that overcomes these limitation of present systems and it is to this end the present invention is directed.

With respect to credit card processing systems, typical payment processing systems allow for processing of payments through different payment methods such as credit cards, electronic checks, and debit cards. Payment processing systems also allow for interfacing with other Business Software Systems thus allowing the Business Software System to integrate real time payment processing into their business processes. Payment processing systems are critical for real time processing of payments for purchasing transactions. An example of the interfacing of a business software application and a payment processing systems is the interface is the interface between the Everest Advanced Edition (Everest) (a Business Software System developed and marketed by iCode, Inc.) and ICVERIFY (a payment processing software from Verisign). Everest allows merchants with ICVERIFY accounts to process customer receipts and refunds through ICVERIFY. Everest generates Transaction Request files in the format stipulated by ICVERIFY. The ICVERIFY payment processing software reads the Transaction Request file and contacts the processing network for further processing of the transaction. ICVERIFY then formulates the response of the processing network in an answer file and Everest reads the answer file and records the response in the form of metadata in its database. Everest also performs further actions such as recording the payment based on whether the Transaction Request was approved or not.

The basic presumption for the operation of this automated interface to work is that Everest generates the Transaction Requests in a foπn understood and required by ICVERIFY and communicates the Transaction Request in a protocol stipulated by ICVERIFY. For Everest to support additional Payment Processors other than ICVERIFY, Everest would need a separate interface for each Payment Processor as each Payment Processor has its own unique data structures and formats. Thus, it is desirable to provide a payment processing system and method that overcomes the limitations of the present system and it is to this end that the present invention is directed.

Summary of the Invention

A business software application with an integrated mail management system, an mtegrated e-mail client, an integrated HTML page generator system and an integrated credit card processing systems is provided. Each of these mtegrated systems has unique aspects. For example, a mail management method and system are described that tracks correspondence exchanged with external entities such as customers and vendors, through e- ail messages, and the internal users of the system. An example of the implementation of the mail management system of the present invention is the "MailBridge" module associated with the Everest business software application that was developed by iCode, Inc. The e-mail messages are then desirably imported into business software (of various types) and linkages created to such external entities within business software, from the E-mail Clients. In more detail, correspondence in the form of e-mail is automatically imported into business software and Tasks created in accordance with the invention, hi the process, a repository of external e- mail correspondence is maintained within the business software. The mail management system in accordance with the invention is efficient, cost-effective and accurate, and the mail management in accordance with the invention would otherwise not be possible to achieve manually. hi accordance with the invention, there is provided a mail management method and apparatus for retrieving, adding and linking e-mail correspondence sent to/received from Business Partners to a business software application in the form of Tasks or e-mails. This will ensure proper tracking of outstanding issues in a timely and efficient as well as cost-effective manner. The mail management system and method in accordance with the invention provides various advantages over the typical systems. In a preferred embodiment, the mail management system and method is part of the Everest software application developed by iCode, Inc. which is the assignee and owner of this patent application. Thus, the mail management system and method permits the importation of external correspondence between Everest e-mail users and their Business Partners in the form of e-mail messages, into other business software application. The mail management system and method also associates such e-mail messages with relevant Business Partners in the business software applications. The system further permits indexing and warehousing of such e-mail messages and related data and attachments for data mining and tracking purposes and enhanced customer relationship management. The system further ensures that no correspondence with Business Partners goes unrecorded/untracked by creating Tasks for the relevant Business Partners concerned, leading to a positive impact on business growth. The system also provides the ability to view the e- mail messages and attachments for a Task or Business Partner by various parameters imported from the external E-mail Client. The system further generates a back-up of all the messages that are imported into the business software application. Thus, in accordance with the invention, a mail management method for retrieving and adding the incoming/outgoing e-mail messages to an existing database is provided. In the method, each message is scanned for the contents of the message headers, including but not limited to the TO, CC, BCC and/or FROM fields of an e-mail message, and the e-mail addresses in these fields are compared to all the e-mail addresses contained in an associated business software application database. When a match between the address in the message and the business software application database is found, the e-mail message and its attachments (if any) are added into the database. If a match is not found for the current message, any new e-mail addresses are added into the database along with the contents of the e-mail message. A Task may be created, wherever necessary, along with necessary links to the database or create necessary links for tracking purposes. In this method, the user is permitted to select the messages to be imported to the database and the user can specify the e- mail addresses or address patterns that are not to be imported into the database. hi accordance with yet another aspect of the invention, a method and apparatus for importing external correspondence between Everest users and their Business Partners in the form of e-mail messages, into business software application is provided. The method and apparatus associate such e-mail messages with relevant Business Partners in the business software application. The apparatus and method also indexes and warehouses such e-mail messages and related data and attachments for data mining and tracking purposes and enhanced customer relationship management. The apparatus ensures that no correspondence with Business Partners goes unrecorded / untracked by creating Tasks for the relevant

Business Partners concerned, leading to a positive impact on business growth. The apparatus also provides the ability to view the e-mail messages and attachments for a Task or Business Partner by various parameters imported from the external E-mail Client. For the integrated e-mail client system, it enables the user of the e-mail client to send and receive e-mails and also store, index and retrieve the e-mails in the database. An exemplary implementation of the e-mail client of the present invention may be known as "Everest E-mail" and may be integrated into the Everest business software application developed by iCode. The e-mail client allows a user to manage internal and external e-mail communication. The invention provides a mechanism for the a user to send and receive e- mails to/from other users, reply to e-mails, forward and delete e-mails, within and outside the organization. Users can also mark messages as read or unread and print e-mails. There is also provided a method for structuring, storing and retrieving e-mail communication of internal and external entities. This method has capabilities to create new folders, copy folders, delete folders, move folders, copy or move e-mails to different folders.

By integrating the e-mail client of the present invention with the database of the business software such as Everest, there is also provided an apparatus to centralize communication with external entities by providing various features. For example, the system provides configuration and supports POP3 and MAPI e-mail accounts for external communication, internal communication does not require setting up e-mail accounts such as POP3 or MAPI. The system also provides an e-mail client for sending and receiving e-mails from customers, vendors and external entities. The system also scans a user's "Inbox" for each account and upon finding a match, links the e-mail address with the customer or vendor. The system also views all e-mails sent to a customer/vendor by any user in the organization ensuring that no correspondence is lost or is confined to a single user's Inbox. The system also automatically creates an address book with all customer/vendor e-mail addresses.

Thus, in accordance with the invention, a method to integrate an e-mail client with a business software application is provided, hi the method, an e-mail account is set up for each user of the business software. Each e-mail account is managed by setting up preferences such as message formats or the notification, of the arrival of an e-mail. The method further comprises creating and managing a centralized database of e-mail addresses by combining the global address book from a mail server, a user's personal address book and the e-mail addresses of contacts in the database of the business software. The method further identifies and associates e-mails received and sent with the contacts in the database of the business software and indexes and stores all e-mails thus associated in the database, along with attachments and related data in the centralized repositoiy of the business software. The system also retrieves e-mails for the selected contacts. The e-mail message formats may include Plain Text, Rich Text Format and Hypertext Markup Language (HTML). hi accordance with another aspect of the invention, an e-mail client system is provided that comprises a computer program configured to execute instructions on a processor or computer. The instructions perfoπn different functions. Thus, the e-mail client system sets up an e-mail account for each user of the business software with preferences such as message formats or notification of the arrival of an e-mail. The e-mail client also creates and manages a centralized database of e-mail addresses by combining the global address book from an e-mail server, a user's personal address book and the e-mail addresses of contacts in the database of the business software. The e-mail client further identifies and associates e- mails received and sent with the contacts in the database of the business software and indexes and stores all e-mails thus associated in the database, along with attachments and related data in the centralized repository of the business software. The e-mail client also retrieves e-mails for the selected contacts. In accordance with yet another aspect of the invention, an e-mail client system is provided wherein the computer program further comprises a set of instructions to set up an e- mail account for each user of the business software with preferences such as message formats or notification of the arrival of an e-mail. The client further comprises means for creating and managing a centralized database of e-mail addresses by combining the global address book from an e-mail server, a user's personal address book and the e-mail addresses of contacts in the database of the business software, means to identify and associate e-mails received and sent with the contacts in the database of the business software and means to index and store all e-mails thus associated in the database, along with attachments and related data in the centralized repository of the business software, and retrieve e-mails for the selected contacts. The e-mail client system's database integrates the address retrieval element of the e-mail client with the metadata of the entities stored in the database. The indexing and storing functions of the e-mail client also identify the relevant metadata of the entity in the business database, stores a copy of the e-mail data in the database, the e-mail data being attached and indexed to the data of the particular entity to which the e-mail is sent. The integrated HTML page generating system generates HTML pages from databases such as Everest. An exemplary implementation of the HTML page generating system is the "PageBoost" module that is part of the Everest business software application developed by iCode. A method for generating HTML pages is provided that interacts with a database of a business software application and obtains product information and the settings that need to be embedded into the HTML page.

In a preferred embodiment of the invention, the HTML page generation system is exemplified by the PageBoost module that is an application within the Everest system, which is an e-commerce solution developed by iCode. However, the HTML page generation system may be used with other business software applications and similar e-commerce products where it is desirable to generate an HTML page from a business database. The HTML page generation system allows the User to create static HTML pages with META tags for keywords and descriptions. The User can submit these static HTML pages to search engines in order to increase traffic to the User's online shop. The search engines record the information given by the User, thereby ranking and exposing the User's site to millions who search the Web. The HTML page generation system produces online shopping catalogs, ordinary catalogs, price lists and database contents for the Internet. The program is designed to enable anyone with basic computer knowledge to maintain and update catalogs.

The pages that are generated using the HTML page generation system will also contain title and other contents for eveiy Web-enabled item, item alias and item category. The tool also helps to schedule the creation of these HTML pages periodically to provide for any updates/modifications to the items/categories/item aliases at the back end. In essence, without the HTML page generator, the User does not maximize its opportunity to attract visitors to its Web site through search engines.

When the HTML page generation system is incorporated into the Everest product developed by iCode, the HTML page generator comes with pre-defined HTML Templates similar to the ASP Templates in the Everest E-commerce feature. The difference being the ASP Templates and the HTML Templates is that the HTML Templates contain iTags which are used to populate the HTML page with the dynamic content from a database. There are two different Templates used by the HTML page generator - one for the index/ categories page and one for the item/Item Alias Page. hi accordance with the invention, the HTML page generator is installed on the server with the files required to generate the HTML pages. The generated HTML pages need to be hosted on the Web Server along with the e-commerce dynamic pages so that the User is seamlessly transferred from the static page to the dynamic page by the HTML page generator and taken through the e-commerce shopping process.

In accordance with the invention, an HTML page generating system for use with online product catalogs and shopping carts is provided. The HTML page generation system comprises computer software having a set of instructions to generate HTML pages using the HTML Templates having iTags embedded therein corresponding to the dynamic Templates in the e-commerce software. The page generator system enables the replacement of the iTags in the HTML Templates with the product information in the database. The system may provide one template each for index/Category Pages and for item/Item Alias Pages. In accordance with another aspect of the invention, an HTML page generating system for use with online product catalogs and shopping carts is provided. The system comprises a set of HTML Templates with iTags, one for index/Category Pages and the other for item/Item Alias Pages, means for contacting and obtaining the product information and other settings from the Database Server, means for replacing the iTags with product information from the database and means for producing the HTML page with META tags for keywords and description and with product information being generated for categories/items/item aliases. hi accordance with another aspect of the invention, a method of generating HTML pages for online product catalogs and shopping carts by integrating seamlessly with the database, which can be submitted to search engines is provided, h accordance with yet another aspect of the invention, a method of generating HTML pages for online product catalogs and shopping carts is provided, hi the method, a set of HTML Templates with iTags are created in which there is one template for each index/Category Page and one for item/Item Alias Pages. Next, product information and other settings are obtained from the Database Server and the iTags are replaced with the product information so obtained. Next, the HTML page with META tags for keywords and description and with product information for categories/items/item aliases is generated.

The integrated payment processing intermediary of the present invention allows users of a business software application, such as Everest, to use Payment Processors that are not supported within Everest. The intermediary would have within it the required mechanism to map existing output formats with Transaction Requests that are generated by Everest to formats required by other processors. It would also have within it the necessary setup requirements to communicate with the Business Software System and the Payment Processor in different protocols. The advantages of using an intermediary are that Business Software System vendors can allow their users to use different Payment Processors supported by the intermediary without making changes to their code base and users can advantageously use the Payment Processors that suit them best without having to change their Business Software System or switch to processing payment transactions manually.

In accordance with the invention, there is provided a method and an apparatus for a Business Software System to communicate with different Payment Processors without having to generate Transaction Request in the specific formats stipulated by each processor or having the necessary mechanisms for directly communicating with the processor. The Intermediary Payment Processor has the required definitions for communication protocols and Transaction Requests from Business Software Systems in the formats understood by different Payment Processors, such as ICVERIFY and PayFlowPro for example. In one example, the Intermediary Payment Processor also has the corresponding formats for the data format supported by PC Charge Payment Server, h one example, the Intermediary Payment Processor monitors the specified ports or folders for Transaction Requests in a format published by ICVERIFY and PayFlowPro; and translates these Transaction Requests to formats published by PC Charge Payment Server. The Intermediary Payment Processor then translates the response from PC Charge Payment Server to the format published by ICVERIFY or PayFlowPro. The Business Software System from which the Transaction Request originated will now be able to decipher the response and carry out further actions based on the type of response. In accordance with the invention, the Intermediary Payment Processor may be used with various different Payment Processors, hi accordance with the invention, the intermediate Payment Processor can translate between the formats of the different Payment Processors and can be updated to handle new Payment Processors using, in a preferred embodiment, an extended mark-up language (XML) translator.

The intermediary Payment Processor provides many advantages since it permits Business Software Systems to support multiple Payment Processors without making changes to their code base. The system also enables the existing users of Business Software Systems to switch to a Payment Processor not supported by their current Business Software System without having to make changes to the data setup in their software or having to resort to a manual system of processing payments. The system also permits the users of multiple Business Software Systems to use a single intermediary and multiple Payment Processors and multiple merchant accounts. The system also allows Websites and on-line shops that are dependent on TCP/IP and other protocols for real time payment processing to conveniently use Payment Processors that are based on an alternate method of connection such as dial-up without having to make changes to their Website or on-line shop. Thus, in accordance with the invention, a Payment Processor is provided. The

Payment Processor stores the required definitions for communication protocols and Transaction Requests from Business Software Systems in the formats understood by any payment processing software and the formats for the data format supported by the payment server so as to monitor the specified ports or folders for Transaction Requests in a foπnat published by the payment processing software. The system has a module to translate these Transaction Requests to formats published by the payment server and to translate the response from the payment server to the foπnat published by the payment processing software so as to enable the Business Software System from which the Transaction Request has originated to decipher the response and carry out further actions based on the type of response.

In accordance with another aspect of the invention, a Payment Processor is provided. The Payment Processor is software comprising a set of instructions to foπnat the transaction data based on the payment processing software, set up the merchant account infoπnation for each merchant account with the coπesponding payment server, identify the output mode of the transactions requests for this merchant account as a Transaction Request file or through a port, identify the folder in which the Transaction Request file is to be placed or the port to which the Transaction Request is to be sent, specify the maximum number of transactions that the intermediary is allowed to process concuπently, and in each step, updates the database with the setup data. The Payment Processor may further include software instructions to intercede between the Business Software System and the Payment Processor by receiving Transaction Requests and assigning them for further processing by retrieving the infoπnation for a particular monitor and processor from its database, begin monitoring based on the monitor type, create a repository of the processor templates objects based on the number of concurrent transactions specified, create Worker Threads based on the configuration settings and create the number of workers available, such that if workers are available end the process, or if workers are not available create Worker Threads and then end the process. hi accordance with yet another aspect of the invention, a Payment Processor is provided that is software comprising a set of instructions. The software foπnats the transaction data based on the payment processing software, sets up the merchant account ii fonnation for each merchant account with the coiτesponding payment server, identifies the output mode of the Transaction Requests for this merchant account as a Transaction Request file or through a port, identifies the folder in which the Transaction Request file is to be placed or the port to which the Transaction Request is to be sent, and specifies the maximum number of transactions that the intermediary is allowed to process concuixently, and in each step, updates the database with the setup data. The software also has a further set of software instructions to process a payment request comprising a means to identify the source of the Transaction Request and the format in which the Transaction Request has been sent, identifying the processor to which the Transaction Request should be directed, assigning the Transaction Request received to the processor object and the Thread, and if free, begin to process the Transaction Request by translating the Transaction Request from its cuπent foπnat to the format in which the processor requires the Transaction Requests to be transmitted and then transmit the Transaction Request after due validation, redirecting the response from the processor to the format recognized by the source of the Transaction Request, or in case the processor object and the Thread are not free, send it to the queue. hi accordance with yet another aspect of the invention, a method for operating an Intermediary Payment Processor is provided. In the method, the definitions for transaction data generated by the Business Software System are specified along with the equivalent definitions to be used for transmitting such information to the Payment Processor. The definitions for the format into which the responses from the Payment Processor need to be converted are specified in order that the information can be read and understood by the Business Software System. Furthermore, the folders or ports that need to be monitored by the intermediary for Transaction Requests are specified from the Business Software System and the merchant account and other information is specified that would be used by the inteπnediary to connect to the Payment Processor. The method may preserve these definitions in the foπn of metadata. The method may start the monitoring service whereby the folders or ports would be monitored for Transaction Requests. The method also handles Transaction Requests and conveys the results of the Transaction Requests to the respective folders or ports. Brief Description of the Drawings

These and other aspects of the invention will become apparent from the following description read in conjunction with the accompanying drawings.

Figure 1 is a diagram illustrating a system that includes the mail management system in accordance with the invention;

Figure 2 illustrates the sequence of steps involved in setting up the e-mail management system;

Figure 3 A illustrates the sequence of steps involved in running the e-mail management system; Figure 3B illustrates an example of the computer implemented mail management system in accordance with the invention;

Figure 4 portrays an example of the Everest server configuration interface;

Figure 5 portrays an example of the e-mail server configuration interface;

Figure 6 portrays the preference settings configuration interface; Figure 7 portrays the interface for miming the e-mail management system in accordance with the invention;

Figure 8 depicts the user interface in Everest for filtering Tasks by a user;

Figure 9 depicts the user interface in Everest for filtering Tasks by document/customer/vendor; Figure 10 depicts the relationship between Tasks, e-mails created based on the import of e-mails and their relationship with other entities such as user and documents;

Figure 11 is a diagram illustrating a Task browser application with an e-mail system task in accordance with the invention highlighted;

Figure 12 is an example of a user interface for a setting of the e-mail exclusion property of the e-mail message management system; Figure 13 illustrates a diagram showing the functional capabilities of Everest E-mail;

Figure 14A illustrates a flow diagram showing the process flow for managing e-mails from to Everest customer/vendor/users and external entities;

Figure 14B illustrates a computer implemented e-mail client system in accordance with the invention;

Figure 15 is the user interface of Everest E-mail;

Figure 16 illustrates a view of the e-mails pertaining to a specific customer from the customer browser;

Figures 17A and 17B illustrate an example of a database table that contains the e-mail addresses associated with the e-mail client;

Figure 18 illustrates the prerequisite process of the User buying and installing Everest;

Figure 19 illustrates the User buying and installing the HTML page generator;

Figure 20A illustrates the process followed by the HTML page generator to create the HTML files in accordance with the invention; Figure 20B is an example of a computer system implementation of the HTML page generation system in accordance with the invention;

Figure 21 illustrates an example of a User interface for instructions/settings for the User;

Figures 22A and 22B illustrate an example of a template for an index page for an item and a template for a Category Page, respectively;

Figures 22C and 22D illustrate an example of an ASP Category Page and a coπespondmg HTML Category Page that are generated for an e-commerce site using the HTML page generator system in accordance with the invention;

Figures 22E and 22F illustrate an example of an ASP Item Page and a coπesponding HTML Item Page that are generated for an e-commerce site using the HTML page generator system in accordance with the invention; Figures 23 A- C are examples of a first and second Category Page META tag User interfaces and a listing of the source of the META tags, respectively;

Figure 24A - C are examples of a first and second Item Page META tag User interfaces and a source of the META tags, respectively; Figure 25 illustrates a User interface that peπnits the User of the HTML page generator system to select the META database fields for a particular HTML page to be generated by the system;

Figure 26 is a flow diagram showing the interface between a Business Software System such as Everest and a supported Payment Processor such as ICVERIFY; Figure 27 is a flow diagram giving an example of how a credit card payment is processed in the absence of a seamless interface with a Payment Processor;

Figure 28 is a diagram that illustrates the activities of software development required for a Business Software System such as Everest to support another Payment Processor such as PC Charge Payment Server; Figure 29 illustrates an example of the setup in the inteπnediary to interface between a

Business Software System that generates Transaction Requests in a format supported by the Business Software System and an unsupported Payment Processor wherein Everest is the Business Software System, ICVERIFY and PayFlowPro are the supported payment processors and PC Charge Payment Server is a Payment Processor not supported by Everest; Figure 30 is a diagram showing how the intermediary intercedes between the Business

Software System and the Payment Processor by receiving Transaction Requests and assigning them for further processing;

Figure 31 A is a flow diagram that illustrates how the intermediary obviates the necessity for implementing a direct interface in a Business Software System through the steps in Figure 3 by enabling the processing of Transaction Requests from a Business Software System such as Everest through other processors such as PC Charge Payment Server (a Payment Processor not supported by Everest);

Figure 3 IB is a diagram illustrating a computer system implementation of the Credit Card Payment Processing System in accordance with the invention; Figure 32 is a prototype of how the intermediary would be configured to interact with PC Charge Payment Server and any other Business Software System;

Figure 33 is a prototype image of how the intermediary would monitor and display the status of the different Transaction Requests received; Figure 34 is an example of a configuration user interface to set-up the monitoring module of the intermediary in accordance with the invention;

Figure 35 is an example of a configuration user interface to set-up the inteπnediary for a particular payment processor system; and

Figures 36A and 36B illustrate an example of a payment processing Transaction Request and the translated output for PCCharge, respectively.

Detailed Description of a Prefeπed Embodiment

The invention is particularly applicable to a business software application with an integrated mail management module, an e-mail client module, an HTML page generator module and a credit card processing module and it is in this context that the invention will be described. It will be appreciated, however, that the mail management module, the e-mail client module, the HTML page generator module and the credit card processing module have greater utility, such as to various other electronic systems in which it is desirable to integrate one or more of the mail management module, the e-mail client module, the HTML page generator module and the credit card processing module. For purposes of the following description, certain tenns will be defined herein:

Application Server is the well known computer system on which the Everest program is installed.

Browsers: A summary display of related profiles as displayed in Everest.

Business Partner: Customers, vendors and other parties with whom the company has or shall have any relationship in the conduct of its business operations.

Business Software System: Any software that is used to process and record transactions related to sales and purchasing, in general, and receipts from customers, in particular. Category Page is the page where the items belonging to a particular category are displayed.

Database Server is the system where the database, such as Microsoft SQL, for Everest resides. The Database Server may reside on the same physical computer system, such as a server, as the Application Server.

E-mail Client: An application, which acts as, the interface for receiving e-mail messages from or sending e-mail messages to Business Partners.

Entities/Business Contacts/Contacts: Organizations or persons such as customers/vendors/prospects that a business deals with in the course of carrying out its activities.

Everest: refers to Everest Advanced Edition, a business software application developed by iCode, Inc., which is used as an example of a business software application into which one or more of the mail management module, the e-mail client module, the HTML page generator module and the credit card processing module may be integrated. Everest E-commerce is a module of Everest system that allows the User to create an online shop for its products. This module is also used as an example of a system into which the HTML page generating process and system may be incorporated.

Everest E-mail: An example of an e-mail client, that integrates with the Everest database. HTML refers to Hyper Text Markup Language, which is the world wide standard for static Web pages.

ICVERIFY: An example of a Payment Processor that normally requires request and formulates response in a file format with prescribed definitions.

Index Page is the home page of the e-commerce Web site. Intermediary Payment Processor: A Payment Processor that interfaces between

Business Software Systems and Payment Processors that use differing data formats and/or connection protocols. The Intermediary Payment Processor helps to bridge the gaps in file fonnats and connection protocols between Business Software Systems and Payment

Processors. iTags are proprietary HTML tags, which are replaced with information from the database while generating the HTML page in accordance with the invention. For example, "$Categories$" is an iTag that creates main navigation links allowing the shopper to navigate different categories of a shopping cart. Based on the settings to display the number of categories per page the HTML page will be generated with either static or dynamic links specified during generating.

Item Page is the page where the item description or the item details are displayed. Item Alias Page is similar to the Item Page where the description, price and other details are different for the alias to the item.

MAPI Compliant: A messaging application that complies with e-mail messaging standards.

META Keyword Tag - A META Keyword Tag lists all the keywords for which the User would like search engines to rank its site. Although not all search engines support this tag, META Keyword Tags should be used for the search engines that support these tags. META tags are hidden in a document's source, invisible to the reader. Some search engines, however, are able to incorporate the content of META tags into their algoritlnns. No engines penalize sites that use META tags properly, so it is recommended to include them. An example of a META Keyword Tag:

<HTML>

<HEAD>

</HEAD> </HTML> META Description Tag - A META Description Tag is similar to the META

Keyword Tag, the difference being that it is a one/two line brief description in the fonn of a correct English sentence.

PayFlowPro: An example of a Payment Processor that uses the TCP/IP protocol. Payment Processor: A processor that facilitates the processing of payments through credit cards, debit cards, electronic checks and other forms, hi one example, the Payment Processor sends the Transaction Request for processing a credit card payment, routes it through the financial network, obtains a response from the issuer of the credit card identifying whether adequate funds are available in the card holder's account and displays the response to the person or website (in case of e-commerce) initiating the Transaction Request.

Profiles: A set of data relating to an entity as stored in Everest.

Task: An entry created within the contact management module for follow-up by users of the business software applications.

User is the merchant who buys Everest and other integrated products including the HTML page generation system.

Templates are included in Everest E-commerce. There are one or more Templates (fifteen in a prefeπed embodiment) in the e-commerce module and the User has the option of using any of those for its dynamic Web site. All these 15 Templates are also available in the HTML page generator so that the User can choose the same template for the HTML pages also.

Transaction Request: Any request for processing a payment transaction, such as a credit card fransaction for example. The request may be for different types of processing such as an authorization, sale, refund, or a void transaction.

Web Crawler/Spider - A Web crawler (also known as a Web spider) is a well known program which browses the Web in a methodical, automated manner. Web crawlers typically keep a copy of all the visited pages for later processing, for example by a search engine.

Web Server is where the Everest E-commerce pages are published. The Web Server may also reside of the same physical computer system, such as a server, as the Application Server or the Database Server. Workflow. The sequence of steps involved in or necessary for the achievement or fulfillment of a Task.

A business software application that may incorporate/integrate one or more of the mail management system and method, e-mail client system and method, HTML page generator system and method and credit card processing system and method in accordance with the invention is described as follows. For this example, the Everest business software application developed by iCode, hie. is used as an example to demonstrate the method in which one or more of the mail management system and method, e-mail client system and method, HTML page generator system and method and credit card processing system and method may be used in conjunction with a business software application although the present invention is not limited to any particular business software application.

Figure 1 is an overall block diagram of a business software application system 20 that incorporates one or more of the mail management system and method, e-mail client system and method, HTML page generator system and method and credit card processing system and method. In the prefeπed embodiment, the system 20 is the iCode, hie. Everest software application that is being executed on a computer network/system as shown. However, the system may also be any other business software application. The system 20 is connected together by a computer network 22, such as the Internet as shown, the Web or any other computer network, wherein a plurality of different computing resources 24 are connected together. Each computing resource 24 is a computer system that is capable of executing computer software code to implement the business software application and the mail management system, such as the laptop, wireless device, and desktop systems as shown. Each computing resource has the well known components of a computer system, such as one or more processors, memory, such as SRAM or DRAM or flash memory, a persistent storage device, such as a hard disk drive, optical disk drive, or tape drive, and optional input/output devices, such as keyboards, mice, LCDs, CRTs, printers and the like. The system is not limited to any particular type of computing resource, however as the business software application may be implemented using various computer systems. The computing resources of the system 20 are connected together by a wide area network (WAN) and a local area network (LAN) as shown. As shown, the system 20 also may include a Web server 26 that peπnits Web access to the system by the computer resources 24. The system 20 may further include a database server 28 which is connected to the various computing resources and acts as a data repository for the system and its parts. The elements of the database server 28 are well known and not described herein. In a prefeπed embodiment, a Microsoft® SQL server may be used, but the database server may also be implemented using products developed by Oracle, Siebel and other software companies.

The system may further include a mail management system 30 that is integrated within Microsoft Outlook E-mail Client. The mail management system allows employees to be more informed on all e-mail interactions between customers and anyone in an organization and provides users with access to all such e-mails stored within Everest, hi a prefeπed embodiment, the mail management system is one or more pieces of software code, executing on a computing resource 24, that perfoπn the various functions of the mail management system as shown in more detail in Figure 3B. The mail management system is described below with respect to Figures 2-12. The system may further include a PageBoost system 32 that is a search engine solution, which integrates with Everest by generating optimized hypertext mark-up language (HTML) pages ready to be submitted to various search engines for higher page ranking, traffic hits and seamlessly integrates with Everest E-Commerce solution. In a prefeπed embodiment, the PageBoost system is one or more pieces of software code, executing on a computing resource 24, that perform various functions as shown in more detail in Figures 18- 25. The system may further include an E-mail Client system 34 that sends and receives e-mail directly from Everest. Employees are more infoπned because they have access to all e-mail sent between customers, vendors and anyone in an organization, wherein the Everest E-mail Client replaces any E-mail Client such as Outlook and integrates with Everest. In a prefeπed embodiment, the E-mail Client system is one or more pieces of software code, executing on a computing resource 24, that perfoπn various functions as shown in Figures 13 -17B. The system may further include a Pay-Bridge system 36 that bridges between different payment processors for processing credit card transactions with different payment processors and integrates with Everest allowing customers to use their own payment processors. In a prefeπed embodiment, the Pay-Bridge system is one or more pieces of software code, executing on a computing resource 24, that perfoπn various functions as shown in Figures 26 — 36B. The mail management process and system is described as follows. Figure 2 portrays an installation procedure 100 for the mail management process in accordance with the invention, hiitially, the e-mail and mail management client/software is installed onto a particular computing resource. Next, in step 101, the mail management software/process is registered by the user in the business software application, Everest in this example, through entry of various product infomiation for the mail management system, such as a serial number, a registration code, a validation code and/or an activation key. hi step 102, the user logs in to the process client. In step 102a, the system deteniiines if the registration of the user is valid and loops back to step 101 so that the user enters different registration infomiation if the cuπently entered infoπnation is not valid. If the registration is valid, then the system determines if the number of users for the particular installation of the mail management system has exceeded the license in step 102b and aborts the login if the number of users is exceeded. If the number of users is not exceeded, then the user sets up the process in step 103 by configuring the following pieces: Everest server, an e-mail server and user preferences. The process for mail management in accordance with the invention will now be described.

Figure 3 A portrays a typical system flow where the system 30 imports the e-mail messages into a business software application, such as Everest in a prefeπed embodiment. In steps 201 and 203, the system scans the e-mail messages (in a well known manner such as by reviewing the headers of the e-mails) in the e-mail inbox in the specified folder in an E-mail Client. For example, the mail management system may analyze all of the e-mail headers for contents in a FROM, TO, CC and/or BCC fields to identify the addresses and IDs of external organizations and users. In case of an incoming e-mail communication, all the incoming messages are scanned for the e-mail ID/address in the FROM field in the message headers. This e-mail ID is compared with all e-mail addresses of Business Partners stored in the business software application, such as Everest, database 202 in step 204 and 205. If a match is found, a Task or e-mail will be generated linking the sender's e-mail ID with the user cuπently logged into the business software application and the mail management system and apparatus. See steps 205 - 208. h particular, in step 205, if the e-mail address/ID matches an ID of a Business Partner in the database, then in step 206, the mail management system determines if it is set-up to create a Task. If the system is not set-up to generate a Task, then the contents of the e-mail and its attachments are stored in the database in step 208 and the process is completed. Returning to step 106, if the system is set-up to generate a Task, then the particular Task, which may be an actual Task, e-mail message or other action item, in generated in step 207 and the contents of the e-mail and its attachments are stored in the database in step 208 and the process is completed, h accordance with the invention, the particular Task/message generated for a particular e-mail message may be configured by the user. Figure 11 shows a Task browser 500 that lists the various Tasks of a supervisor user. In accordance with the invention, the e-mail system in accordance with the invention generates its own Task, such as Task 501 shown highlighted in Figure 11, based on an e-mail of the user, hi this example, the user received an e-mail message and the mail system in accordance with the invention generated the Task. hi case of an outgoing e-mail communication, the address/ID of the e-mail in the TO,

CC and/or BCC fields will be compared with the e-mail IDs in the Everest Database 202 in step 204 as before. If a match is found (step 205), the system, if it is set-up to generate a Task (step 206), will generate a Task/e-mail linking each e-mail ID in the TO, CC, BCC fields with the user cuπently logged into the apparatus as above in step 207 and the e-mail and attachments are stored in the database in step 108. As above, if the system is not set-up to generate a Task, then the contents of the e-mail and its attachments are stored in the database in step 208 and the process is completed. For both incoming and outgoing messages, if no match is found, and the checkbox for creating the Task/e-mail even if no match is found is checked (i.e., the system is set-up to generate a Task and is configured to oveπide no match), then the system will, in step 205A, add the new e-mail address if any, to the database 202 along with the contents thereof and also create the necessary links in step 207. In accordance with the invention, the user may optionally specify that any message headers not matched will also be imported. Thus, in step 205A, the user may optionally specify any e-mail addresses or address patterns that are not to be imported into the database 200. Figure 12 illustrates an example of a user interface 510 that peπnits a user of the mail management system to specify that e-mail messages from/ a particular domain, such as "icode.com" or "hotmail" as shown in Figure 12 or from a particular e-mail address may be excluded from the e-mail messages that are being processed by the mail management system in accordance with the invention. As shown, the interface permits the user to exclude domains or e-mail addresses from both incoming and outbound e-mail messages. An example of the computer system implemented mail management system in accordance with the invention is described as follows.

Figure 3B is a block diagram illusfrating an example of a computer implement mail management system 210 in accordance with the invention. In accordance with the invention, the mail management system may also be implemented as one or more software modules/pieces with a plurality of instructions of code residing on a physical data storage medium, such as a CD, DVD or other storage medium, wherein the software is installed from the CD onto a computer system for execution or executed by the computer system directly from the physical data storage medium. Similarly, the mail management system may be implemented as pieces of software embedded onto a hardware device wherein a computer system executes the mail management system using the hardware device. The computer implemented system 210 comprises various well lαiown computer resource components whose function and operation are not described as they are well known, including one or more processors 212, a persistent storage device 214, such as a hard disk drive, optical drive, tape drive or flash memory and a memory 216, such as DRAM, SRAM or the like, that stores the data and instructions being executed by the computer while the computer is tunied on. The computer system 210 may further include other well known components such as various input/output devices and devices that connect the computer system to the Internet and a computer network.

To implement the mail management system in accordance with the invention, the computer implemented system includes the database 202 described above. The computer implemented system 210 further includes one or more pieces of software that implement the mail management system such as a well lαiown operating system 218, a well known E-mail Client 220, a mail management application 222 with a user interface portion 224. In the example shown, these pieces of software reside in the memory 216 and are being executed by the processor 212 to implement the mail management system. For example, the E-mail Client is a typical E-mail Client that permits the user to view, create, send and receive e-mail messages and may be integrated into the mail management system in accordance with the invention. The user interface portion 224 may generate the user interfaces presented to the user during the execution of the mail management system. In accordance with the invention, the mail management system may generate one or more Tasks 226 that are stored in the database 226, may compare e-mail messages to addresses 228 stored in the database and store addresses into the database and may store the e-mail messages and attachments 230 into the database. Examples of the user interface to configure the system in accordance with the invention are described as follows.

Figure 4 illustrates a display screen 240 through which the user can set up the database server/Everest server. In particular, the display 240 permits the user to configure the mail management system and its association with the Everest server by entering information, such as the application server name, the database server name, the company name, the user name and password, so that the mail management system may interact with the business software application system and store data into the database server. Figure 5 illustrates a display screen 250 for setting up of the e-mail server, such as by entering profile infoπnation, a mailbox identification and a password, which gives the mail management system access to the e-mail account of the particular user in order to import the e-mail messages into the business software application system. Figure 6 is a display screen 260 for setting up the general preferences by the user when using the e-mail management system of the present invention. For example, the user may specify the methodology for linking as imported e-mail into the business software application, such as using a Task as shown, the user may specify a maximum e-mail attachment size for storage in the database and the user may specify a custom field that identifies a mail management system Task and specify its value. As shown, the user may also specify user-defined fields and exclusions using the user preference user interface. The mail management process and its user interface in accordance with the invention will be described in more detail as follows.

Figure 7 displays mail management process and an example of a user interface 300 for the mail management system in which the user specifies the e-mail messages to be imported into the system, hi particular, the process interface permits a user to set up and select the folders containing e-mails for which the user wants to create a Task so that the Tasks are added into the business software application system. For example, the system will peπnit an individual to specify that e-mails in a particular folder should generate a predeteπnined Task. As shown, the interface includes a first portion 302 that permits the user to navigate through his or her inbox (in this example an Outlook Inbox) while a second portion 04 peπnits the user to view any e-mail message or its attachment, to specify one or more folders to be imported and to specify particular e-mail messages (by tagging them) to add into the business software application system and database. Thus, this interface is a screen 300 that allows the user to import external e-mail prior to installation of the apparatus and view all Tasks / e- mails. In a prefeπed embodiment of the invention, all data can only be viewed in this interface and no e-mail messages can be sent from this screen. However, in an alternative embodiment, the mail management system may be integrated into an E-mail Client so that the interface may permit the sending and receipt of e-mail messages, hi accordance with the invention, all e-mail communication, whether incoming or outgoing, will be treated the same way and a Task/e-mail will be created for each e-mail ID in the "FROM', 'TO', 'CC and 'BCC fields. All e-mails/Tasks are stored in a single repository (the business software application database 202 in Figure 3) for the entire company. Users with appropriate rights to view e-mails/Tasks for specific user may view the e-mails/Tasks for the user. Users with appropriate rights to view all e-mail / Tasks for all users may view the e-mail/Tasks for all users so that the mail management system may include a security portion that establishes the privileges of each user of the system.

Figure 8 illustrates a user interface 400 in which the user is able to find Tasks/appoinhnents for a particular user. In particular, once the mail management system has generated Tasks/e-mail messages from the imported messages, the user may search for particular users, message subjects, creation date(s) or type of Task/message and message/Task status. Furthermore, the user may specify the number of records retrieved based on the search. Thus, the system provides the ability to view the e-mail messages and attachments for a Task or Business Partner by various parameters imported from the external E-mail Client. This is done through the "find filters" interface 400 where a Task/appointment may be searched for a customer/document or vendor/document combination. Figure 9 illustrates a user interface 410 in which a Task/appointment, such as a follow up meeting, may be searched for by other parameters, such as a customer/document or vendor/document combination as shown.

Figure 10 depicts a chart 420 with the relationship between Tasks, e-mails created based on the import of e-mails and their relationship with other entities such as user and documents, hi particular, an e-mail from a party is sorted in step 422 based on the type of entity in the business software application system. For example, the mail management system may create a Task for the user in step 424 and store the e-mail message and attachment(s) into the database. In the alternative, in step 426, the mail management system generates an e-mail with attachments for the user, then, the e-mail/Tasks with attachments may be viewed from within the business software application using the find interface described above based on "find" parameters to filter out unwanted Tasks and e-mails. In step 430, the mail management system creates a Task for the user that links the Business Partner(s) (the party identified in the imported e-mail message), and any documents and e-mail messages and attachments.

To summarize, the mail management system (lαiown as MailBridge) may import e- mail messages from any MAPI Compliant E-mail Client into Everest and create messages, such as Tasks or e-mail messages, if the FROM, TO, CC and BCC fields contain any address that matches any e-mail address of customers / vendors in Everest. The mail management system may be easily implemented in any software solution as shown in Figure 3B above. The mail management system in accordance with the invention provides many advantages. The system provides for importing external coπespondence between Everest users and their Business Partners in the form of e-mail messages, into a business software application. The system also associates such e-mail messages with relevant Business Partners in the business software application. The system also indexes and warehouses such e-mail messages and related data and attachments for data mining and tracking purposes and enhanced customer relationship management. The system also ensures that no coπespondence with Business Partners goes unrecorded/untracked by creating Tasks for the relevant Business Partners concerned, leading to a positive impact on business growth. The system also provides the ability to view the e-mail messages and attachments for a Task or Business Partner by various parameters imported from the external E-mail Client. This is done through the "find filters" interface where a Task/appointment may be searched for a customer/document or vendor/document combination. The system also makes a back up of all the messages and attachments that are imported. Figure 13 is a diagram illustrating the capabilities of the e-mail system in accordance with the invention. The e-mail client is a messaging client application (software in the prefeπed embodiment) that is built within the system 20 shown above. The e-mail client communicates internally with the user of the system 20 and externally with customers/vendors and other external entities. For internal communications, the e-mail client sends/receives e-mails from/to users, reply/forwards/deletes e-mails and marks messages as read/unread/printed, prints e-mails and saves e-mails to folders and other locations. For external communications, the e-mail client may configure and support POP3 and MAPI e- mail accounts, automatically create address books for custoiners/vendors/users, send/receive e-mails from customers/vendors/user and external entities, link the e-mail accounts with customers/vendors/users and view e-mails sent to customers/vendors/users as shown in

Figure 13. The installation process for the e-mail client system, including client accounts and preferences, is described as follows.

An e-mail account is a group of settings that defines how Everest E-mail is set up for a particular user. Everest E-mail can be set up for dial-up Internet service, corporate e-mail servers, or both. Both POP3 and MAPI e-mail accounts can be setup in Everest E-mail. If Everest is needed to work with a different set of infoπnation services, it may be useful to create additional e-mail accounts. If more than one person uses the same computer, each person should have a separate e-mail account created for his or her own use. The setup options allow users to create, modify and delete the e-mail accounts and set preferences. Everest E-mail enables users set up options for message formats while replying, forwarding and sending messages. Everest E-mail can send and receive messages in three foπnats: • Plain Text: Using this option, a user can send e-mails that do not include text foπnatting.

• Rich Text Foπnat: Using this option, a user can send e-mails with formatted text, bullets, and alignment.

• HTML: Using this option, a user can send e-mails with text foπnatting, numbering, bullets, alignment, horizontal lines, backgrounds, HTML styles and Web pages.

Each e-mail account permits the user to send e-mails from browsers and profiles using Everest E-mail. In addition, the aπival of new e-mail can be notified to the user either through a notification message or by playing a sound. The e-mail client also facilitates the creation of an address book, hi particular, an address book containing the e-mail addresses specified in the entity profiles is automatically created. These addresses are tagged and sorted based on the type of entity and are retrievable based on this type. The address book contains the e-mail addresses of three entity types: users, customers and vendors. Multiple addresses can be stored for each entity defined in Everest. Whenever a new customer/vendor/user is created in Everest, the e-mail address from the profile is accessible through the address book. Additional entries in the address book for any other type of contacts can also be created and used.

The e-mail client also peπnits the sending, receiving and managing of e-mail messages. Users familiar with any popular generic e-mail client can easily use Everest E-mail to e-mail the customers/vendors/other users of the organization. The composing element of Everest E-mail allows users to select the e-mail addresses based on the entity type to which the e-mail is addressed. The address retrieval element of the e-mail client is integrated with the metadata of the entities stored in Everest database. The relevant addresses are accessible by the classification of the entities that Everest allows - vendors, customers, users and other contacts. Furthermore, the retrieval is based on the unique identifiers or descriptions that the entities have been assigned in the business software thereby enhancing the ease of retrieval.

The e-mail client has the capability to manage received and sent e-mails in different folders, move, copy or delete the e-mails, and thus provides a mechanism to organize and manage the e-mail communication carried out with all entities. The e-mail client also handles the storing, indexing and retrieval of e-mails. Whenever e-mails are sent to different entities, Everest E-mail searches for the relevant metadata of the entity in the business database (Everest) and a copy of the e-mail data is stored in the business database. This e-mail data is attached and indexed to the data of the particular entity to which the e-mail is sent. Thus, a history of all e-mail communication is maintained, attached and indexed to the entity metadata and becomes retrievable from within the business software, hi a similar way, whenever a new e-mail is received through the Everest E-mail, the addresses database of the business software is searched for a matching entry of the e-mail address from which the e- niail has been received. If the search is successful, the e-mail data is copied to the database and indexed to the entity coπesponding to the e-mail address.

Apart from providing the user with an ability to access e-mails from the e-mail client itself, the integration provided with Everest, extends the usefulness to access these e-mails from the entity profiles within the business software. Hie attached e-mails are available to all users of the software who are allowed to access data pertaining to the entities and can be retrieved and referenced as and when required.

The retrieval mechanism allows the users to view only those messages sent by them or by all users. A filter and search functionality allows retrieval of e-mails based on various parameters the entity received such as from/sent to, time, size, folders stored and subject. Advanced queries can also be built for these filter and search operations with the queries automatically converted to SQL by Everest E-mail. An e-mail client method in accordance with the invention is described in more detail as follows.

Figure 14A illustrates a process 1100 of managing e-mail messages from customers/vendors/users and external entities in accordance with the invention. The steps described below may occur at various times and are not dependent on each other for execution, hi steps 1102 and 1104, the e-mail client system is set up during which customer/vendor/user entity information with a valid e-mail address is created and e-mail accounts (either POP3 or MAPI) are set up, respectively, hi step 1106, the e-mail client may automatically create an address book for custoniers/vendors/users based on the e-mail addresses of the customers/vendors/users. In step 1108, the e-mail client, based on user input, may choose addresses from a previously created address book for sending e-mail messages to custoniers/vendors/users or external entities, hi step 1110, the e-mail client may receive e- mails or replies from e-mails sent to the customers/vendors/users or external entities. In step 1112, the e-mail client peπnits the user to compose an e-mail and insert attachments, if required, and send e-mails to customers/vendors/users or external entities. In step 1114, the e-mail client peπnits the user to send an e-mail to customers/vendors/users or external entities from the customers/vendors/users or external entities profile/browser in the e-mail client, hi step 1116, the e-mail client, when an e-mail is sent to/received from customers/vendors/users or external entities, scans for a recognizable address of the customers/vendors/users or external entities in the e-mail by scanning the header of the e-mail message in a known manner, hi step 1118, the e-mail client peπnits folders to be created, moved, copied and deleted in the e-mail client system and messages from customers/vendors/users or external entities may be stored into the folders. In step 1120, if a recognizable address is found in a header, the e-mail message is automatically attached to the customers/vendors/users or external entity data stored in the database 28 of the business software application system. In step 1122, the e-mail client tracks e-mail client user coπespondence and company wide coπespoiidence made to a specific customer/vendor/user or external entity, hi step 1124, the e-mail client permits the user to retrieve/reference e-mails from customers/vendors/users or external entities using the e-mail client browser. In step 1126, the e-mail client permits the user to customize menus, toolbars and filter messages of the e-mail client system. An example of the computer system implemented e-mail client system in accordance with the invention is described as follows.

Figure 14B is a block diagram illustrating an example of a computer implemented e- mail client system 34 in accordance with the invention. In accordance with the invention, the e-mail client system may also be implemented as one or more software modules/pieces of code wherein each module/piece of code has a plurality of lines of instractioiis/code residing on a physical data storage medium, such as a CD, DVD or other storage medium, wherein the software is installed from the CD onto a computer system for execution or executed by the computer system directly from the physical data storage medium. Similarly, the e-mail client system may be implemented as pieces of software embedded onto a hardware device wherein a computer system executes the e-mail client system using the hardware device. The computer implemented system 34 comprises various well lαiown computer resource components whose function and operation are not described as they are well lαiown, including one or more processors 1212, a persistent storage device 1214, such as a hard disk drive, optical drive, tape drive or flash memory and a memory 1216, such as DRAM or SRAM, that stores the data and instractions being executed by the computer while the computer is turned on. The computer system 34 may further include other well known components such as various input output devices and devices that connect the computer system to the Internet and a computer network. To implement the e-mail client system in accordance with the invention, the computer implemented system includes the database 28 described above. The computer implemented system 34 further includes one or more pieces of software/modules that implement the e-mail management system such as a well known operating system 1218, an e-mail client 1220 in accordance with the invention with a user interface portion 1222. hi the example shown, these pieces of software reside in the memory 1216 and are executed by the processor 1212 to implement the e-mail client system. The e-mail client is an e-mail client with the capabilities shown in Figure 14 A that may be integrated into the e-mail management system in accordance with the invention. The user interface portion 1222 may generate the user interfaces presented to the user during the execution of the e-mail client system, h accordance with the invention, the e-mail client system may generate one or more customer/vendor/user or external entity profiles 1226 that are stored in the database 28, may store the e-mail messages and attachments 1228 into the database and may store address books 1230 for a particular customer/vendor/user or external entity in the database 28. Examples of the user interface of the e-mail client system in accordance with the invention are described as follows.

Figure 15 illustrates an example of the e-mail client user interface 1300 in accordance with the invention. The user interface permits a user to perfoπn the typical e-mail functions associated with a typical e-mail client along with the specialized functions associated with the e-mail client system in accordance with the invention, hi the example shown in Figure 15, a user of the e-mail client is reviewing a message in a preview pane, hi this example, the user has access to several different users' e-mail inboxes and those e-mail inboxes are displayed. If the user only had access to his or her own e-mail inbox, then only his or her own inbox and messages would appear in the user interface. Thus, the e-mail client system includes a security feature that permits different users of the systems to be given different levels of access and privileges within the e-mail system.

Figure 16 illustrates a user interface 1400 of the e-mails pertaining to a specific customer from the customer browser, hi particular, the user interface peπnits a user of the e- mail client to search for messages to/from a particular individual/external entity/customer. As shown in the user interface, each e-mail message contained in the e-mail client (and hence stored in the database 28 of the business software application system) has one or more fields that are specific to a particular individual/external entity or customer. In particular, each message may have a type field 1402 and a code field 1404. The type field associates the message with a particular type of entity, such as a customer (shown), a vendor or a user, while the code field associates that message with a particular external entity, hi the example shown, each external entity associated with the business software application system has a unique identification number associated with that entity so that messages may be searched for based on that entity. In the example shown in Figure 16, messages from a particular user were searched and the user can see that all of the messages are associated with the same external entity.

Figures 17A and 17B illustrate an example of a database table 1500 that contains the type field and code field described above. In particular, the database table contains a SUB_TYPE field 1502 that coπesponds to the type field 1402 and a CUST_CODE field 1504 that coπesponds to the code field 1404. The database table also connects/associates an e-mail address (see EMAIL field 1506 in Figure 17A) with an entity type and code as shown so that that particular association is stored in the database.

Although the e-mail client of the present invention is described with reference to applicant's own business software known as "Everest", the same e-mail client can be used with other well loiown business software applications with the required modification, which can be done by any person skilled in the field of computer software development.

The present invention provides a method to integrate an e-mail client with a business software application so as to enable the user to send and receive e-mails and also store, index and retrieve the e-mails in the database. Everest E-mail allows a user to manage internal and external e-mail communication. The invention provides a mechanism for the user to send and receive e-mails to/from other users, reply to e-mails, forward and delete e-mails, within and outside the organization. Users can also mark messages as read or unread and print e-mails. There is also a method for sfructuring, storing and retrieving e-mail communication of internal and external entities. This method has capabilities to create new folders, copy folders, delete folders, move folders, copy or move e-mails to different folders. By integrating the e-mail client of the present invention with the database of the business software such as Everest, there is also provided an apparatus to centralize communication with external entities by providing various features. For example, the system provides configuration and supports POP 3 and MAPI e-mail accounts for external communication. Internal communication does not require setting up e-mail accounts such as POP3 or MAPI. The system also provides an e-mail client for sending and receiving e-mails from customers, vendors and external entities. The system also scans the Inbox for each account and when a match is found, the system links the e-mail address with the customer or vendor. The system also views all e-mails sent to a customer/vendor by any user in the organization ensuring that no coπespondence is lost or is confined to a single user's Inbox. The system also automatically creates an address book with all customer/vendor e-mail addresses.

In Figure 18, the pre-requisites for the HTML page generator are purchased and installed on a server when used in combination with the exemplary Everest business software application. In other examples and implementations, the HTML page generation system does not have any pre-requisites except Everest. For example, the HTML page generation system may be incorporated into another e-commerce solution. For the Everest example, a User buys Everest in step 2101 that includes the e-commerce module as shown in step 2102. These have to be installed on a server (see step 2103), which is refeπed to as the Application Server. The installation also requires a Database Server. The Everest system preferably is installed on a Web Seiver. Figure 19 illustrates the next step for the User, which is to purchase (the HTML page generator preferably may be part of the purchase of the Everest software) and install the HTML page generator in steps 2201 and 2202 so that the HTML page generator has access to the Everest Application Server and the Database Server. The HTML page generator preferably may be installed on the same physical server as the Application Server, but may also be installed on another server. The process used by the HTML page generator to create an HTML page in accordance with the invention is described in more detail as follows. Figure 20 A illustrates a process 2300 used by the HTML page generator to create the HTML pages, hi step 2301, the HTML page generator program interface 2310 contains instructions/settings of the User. An example of that interface is shown in Figure 21 in which the User may specify the Application Server address, Database Server address and company for which the HTML pages are being generated in accordance with the invention, hi step 2302, the User may use a template 2320 for the desired HTML page. The HTML page generator may contain one or more HTML Templates similar to the dynamic Templates in Everest. In accordance with a prefeπed embodiment of the invention, there may be one template for index/Category Pages or each index/Category Page and one template for item/Item Alias Pages or each item/Item Alias Page. An example of a template 2320 for an Item Page (item/Item Alias Page) is shown in Figure 22A while Figure 22B illustrates a template 2321 for an index/category HTML page.

As shown in Figures 22A and 22B, each template 2320, 2321 is a template for an HTML Web page that includes one or more iTags 2322 wherein each iTag is replaced with data from the database when the HTML page is generated by the system. Each template provides the overall sfructure and look and feel of each HTML page while the actual dynamic data in the page is provided from a database wherein the page is generated based on the iTags. Thus, the system generates static HTML pages (based on the dynamic data in the database) that may then be crawled by typical search engines (unlike dynamic ASP pages that cannot be indexed or searched due to the dynamic data) so that the dynamic pages represented by the generated HTML pages may be properly ranked and indexed by a search engine. For example, the template in Figure 22A includes an "$ItenιName$" iTag, an "$ItemPrice$" iTag, an "$ItemCode$" iTag, an "$ItemDesc$" iTag, a "$Categories$" iTag, an "$hnage$" iTag, an "$ShopName$" iTag and an "$emailID$" iTag. hi accordance with the invention, each of these different iTags pull different pieces ,of data from the database to generate an HTML page (with the dynamic data from the database) in accordance with the invention. For example, the database may contain a list of different product categories (in a database table column, for example) that will be placed into a generated HTML page at the location of the "$Categories$" iTag when the HTML page is generated. Similarly, the database may contain a plurality of products to be sold wherein each product includes a product description, a product code, a product price and a product name which are all placed into the generated HTML page based on the location of the iTags shown. The database may also contain an image of the item that is placed at the location of the "$Image$" iTag, a shop name of the e- commerce site owner and an email address for the particular e-commerce site that are placed into the locations of the "$ShopName$" and "$emailID" iTags shown in Figure 22A. Similarly, for the template shown in Figure 22B, the categories template 2321 has an "$Categories$" iTag that pulls category data from the database to fill in the particular field in the template. In this manner, a template may be created for various different foπnat HTML pages and for HTML pages that contain different dynamic infomiation wherein an HTML page coπesponding to the template may be generated based on the data contained in the database.

Thus, in step 2303, the Database Server is contacted and product infoπnation and other settings are retrieved from the Database Server, hi step 2304, the iTags 2322 in the template are replaced with product information/data from the database. Figures 22C and 22D illustrate an example of an ASP Category Page 2333 and a corresponding HTML Category Page 2334 that are generated for an e-commerce site using the HTML page generator system in accordance with the invention. Figures 22E and 22F illustrate an example of an ASP Item Page 2335 and a coπespondmg HTML Item Page 2336 that are generated for an e-commerce site using the HTML page generator system in accordance with the invention. Figure 22C illustrates the ASP Category Page 2333 that is generated from the dynamic data in the database. Since the data in the ASP page is dynamic and the ASP page is only generated when the page is sent to the User, the ASP page cannot be crawled in the typical manner. However, as shown in Figure 22D, the coπesponding HTML page 2334 is shown that contains the same data as the ASP page, but can be crawled and indexed by search engines since the HTML page is static and the data on the page is also static. Similarly, Figure 22E illustrates the ASP Item Page 2335 (which is dynamic and has dynamic data) and Figure 22F illustrates the coπesponding HTML page 2336 that is generated by the system in accordance with the invention and contains static data that is capable of being crawled and indexed, hi accordance with the invention, the data and content in the ASP page and the coπesponding HTML page is very similar so that the Web crawler/search engine generates an accurate index of an ASP page based on the HTML page.

Thus, an HTML page with META tags for keywords and description and with product infomiation is generated for categories/items/item aliases in step 2305. The generated HTML pages are shown In Figures 22D and 22F above in which the iTags have been replaced with data from the database. Figures 23 A- C are examples of a first and second Category Page META tag User interfaces and a listing of the source of the META tags, respectively, while Figure 24A - C are examples of a first and second Item Page META tag User interfaces and a source of the META tags, respectively. In particular, Figures 23 A and 23B illustrate a first and second category META tag User interface 2340, 2341 wherein the User may enter data into the database for the META tags for the Category Page. In the example shown in Figures 23A and 23B, the META data is the same, although it will typically be different as shown in Figure 24A-C. Figure 23 C shows the HTML source code for the META tags that peπ it the HTML pages generated by the system to be searched and indexed by typical crawlers. Similarly, Figures 24A and 24B illustrate User interfaces 2350, 2351 that peπnit a User to enter the META tag description and keywords (which are different in this example) for a particular item in the database and Figure 24C shows the HTML source code for the META tags that peπnit the HTML pages generated by the system to be searched and indexed by typical crawlers. A computer system implementation of the HTML page generator in accordance with the invention is described as follows.

Figure 20B is a block diagram illusfrating an example of a computer implemented HTML page generation system 2350 in accordance with the invention, hi accordance with the invention, the HTML page generation system may also be implemented as one or more software modules/pieces with a plurality of instructions of code residing on a physical data storage medium, such as a CD-ROM, DVD or other storage medium, wherein the software is installed from the CD-ROM onto a computer system for execution or executed by the computer system directly from the physical data storage medium. Similarly, the HTML page generation system may be implemented as pieces of software embedded onto a hardware device wherein a computer system executes the HTML page generation system using the hardware device. The computer implemented system 2350 comprises various well known computer resource components whose function and operation are not described as they are well known, including one or more processors 2352, a persistent storage device 2354, such as a hard disk drive, optical drive, tape drive, or flash memory, and memory 2356, such as DRAM, SRAM or the like, that stores the data and instructions being executed by the computer while the computer is turned on. The computer system 2350 may further include other well lαiown components such as various input/output devices and devices that connect the computer system to the Internet and a computer network.

To implement the HTML page generation system in accordance with the invention, the computer implemented system includes a database 2358 containing business infomiation and a Web Server 2360 that generates HTML pages as is well known. The computer implemented system 2350 further includes one or more pieces of software that implement the HTML page generation system such as a well lαiown operating system 2361 and an HTML page generation application 2362 with a User interface portion 2364 and a template storage portion 2366. hi the example shown, these pieces of software reside in the memory 2356 and are being executed by the processor 2352 to implement the HTML page generation system. For example, the User interface portion 2364 presents the graphical User interface presented to the User to operate the HTML page generation system and the template portion 2366 stores the one or more Templates that are used to generate the HTML pages in accordance with the invention. The HTML page generation application 2362 contains instructions that implement the other functions of the HTML page generation system, such as the database query and insertion of the data from the database into the HTML page in accordance with the invention. In accordance with the invention, the HTML page generation system may download business data 2368 from the database 2358 and generate HTML pages 2370 that are generated by the well lαiown Web Server 2360. hi accordance with another aspect of the invention, an HTML page generating system for use with online product catalogs and shopping carts is provided. The system comprises a set of HTML Templates with iTags, one for index/Category Pages and the other for item/Item Alias Pages, means for contacting and obtaining the product infoπnation and other settings from the Database Server, means for replacing the iTags with product information from the database and means for producing the HTML page with META tags for keywords and description and with product information being generated for categories/items/item aliases.

In accordance with another aspect of the invention, a method of generating HTML pages for online product catalogs and shopping carts by integrating seamlessly with the database which can be submitted to search engines is provided. In accordance with yet another aspect of the invention, a method of generating HTML pages for online product catalogs and shopping carts is provided. In the method, a set of HTML Templates with iTags are created in which there is one template for each index/Category Page and one for item/Item Alias Pages. Next, product information and other settings are obtained from the Database Server and the iTags are replaced with the product information so obtained. Next, the HTML page with META tags for keywords and description and with product information for categories/items/item aliases is generated. Figure 25 illustrates a User interface 2360 that pennits the User of the HTML page generator system to select the META database fields for a particular HTML page to be generated by the system, hi particular, the User interface permits the User to select a particular data source from the database, such as Categories, from which to generate the HTML page, the title of the HTML page and where the title is located in the database, the

META keywords value and where it is located in the database (placed into the database using the User interfaces shown in Figure 23 A, 23B, 24A and 24B), the META description field and its location in the database and any custom fields in the database and wherein the data for those fields is mapped. In this manner, the User is able to specify the META tag data that is used to generate the HTML pages in accordance with the invention.

The Credit Card Payment Processing System and method in accordance with the invention has greater utility as it may be used with any systems in which it may be desirable to have a Payment Processing System with the features described herein so that it may be used with other payment methods and systems, with various Business Software Systems and with various Payment Processors.

Fi ure 26 is a graphical flow diagram that illustrates how a credit card payment is generally processed by a Business Software System with a direct interface to a Payment Processor such as ICVERIFY. Figure 26 has been depicted here to illustrate how a common connection protocol and a common file format is absolutely essential to enable a Business Software System to seamlessly interface with a Payment Processor, hi step 3100, a user creates a point-of-sale (POS) transaction in the Business Software System, hi steps 3102 and 3104, the user of the Business Software System swipes a credit card and the Business Software System validates the credit card. In step 3106, the Business Software System prepares the transaction data so that ICVERIFY can process the payment. In step 3108, the Transaction Request is generated in the exact fomiat as required by ICVERIFY. The

ICVERIFY software reads the Transaction Request file and then processes the transaction including contacting the payment network in step 3110. On receiving a response, ICVERIFY foπnats the response in the answer file in steps 3112 and 3114. h step 3116, the Business Software System reads the answer file and perfoπns other processes to complete the transaction wherein the Business Software System includes a mechanism to understand the components of the answer file and decipher the response. In step 3118, the accounting entries for the sale are generated by the Business Software System and a POS receipt is printed in step 3120. An example of payment processing without seamless integration is described as follows to illustrate the desirability for seamless integration.

Figure 27 is a graphical flow diagram that illustrates what a user of a Business Software System would have to do if there is no seamless interface between the Business Software System and the credit card processor. In step 3130, the cashier creates a POS transaction in the Business Software System. In steps 3132 and 3134, the user swipes his or her credit card and the Business Software System validates the credit card. In step 3136, the cashier goes to a credit card temiinal and manually enters the credit card infoπnation and the amount of the transaction, hi step 3138, the credit card temiinal contacts the payment gateway or banking network, hi step 3140, the credit card terminal receives a response, displays the response reference and prints a receipt, hi step 3142, the cashier re-enters the response reference manually into the Business Software System and accounting entries are made in step 3144 and a POS receipt is printed in step 3146 to complete the transaction. This diagram illustrates the fact that the lack of a seamless interface and the requirement for manual intervention lends itself to more labor as well as creates the opportunity for clerical mistakes such as processing for incoπect amounts and entering incoπect data into the Business Software System. If there is no interface, the cashier at a POS temiinal would have to duplicate activities such as entering credit card information and the amount to be processed into the credit card temiinal and would have to re-enter the result of the Transaction Request into the Business Software System. This results in process inefficiencies. The objective of the depiction in Figure 27 is to illustrate how an intermediary Credit Card Payment Processing System in accordance with the invention achieves the seamless interface depicted in Figure 26 even when the conditions necessary for such an interface are absent.

Figure 28 illustrates the activities in the different phases of a software development life cycle that would be typically required if a direct interface with a new Payment Processor was to be introduced into an existing Business Software System. It will be appreciated that supporting a new Payment Processor entails not only time but also would require ancillary activities such as maintenance for fomiat changes by the Payment Processor, updating the existing users of the Business Software System with the new executable files, and updates to user documentation, hi step 3150, a requirements definition for a new Payment Processor is received and the requirements specifications are determined in step 3152. In step 3154, the Business Software System designer must analyze and design the interface to the new Payment Processor and generate high level design documents and detailed design documents in step 3156. In step 3158, the interface for the new Payment Processor is coded and then tested in step 3160. hi step 3162, test cases and test plans are generated and reviewed, hi step 3164, once testing is completed, documentation is generated in step 3164 including user documentation 3166. hi accordance with the invention, the intermediate Credit Card Payment Processing System avoids the above steps to implement the direct interface for a new

Payment Processor as the present invention is able to integrate new Payment Processors without changing the code base of the Business Software System.

Figure 29 is a flow diagram that illustrates how the inteπnediary would be setup to facilitate the use of a new Payment Processor in conjunction with an existing Business Software System. For purposes of illustration, the flow diagram uses the example of the Everest Business Software System which cuπently supports ICVERIFY and PayFlowPro Payment Processors but does not support PC Charge Payment Server. ICVERIFY uses dial- up connections to transmit and receive information from the payment gateway; and it requires that the Transaction Request from Everest be in the format of a Transaction Request file. PayFlowPro connects to the payment gateway using TCP/IP as the protocol. It transmits infomiation using ports.

If a user of Everest wants to use PC Charge Payment Server, and still needs a seamless interface, the user can use the intermediary Credit Card Payment Processing System in accordance with the invention. Figure 29 depicts the initial setup in the intermediary wherein the merchant account infomiation to access PC Charge, and the folder or port to which the Transaction Request and response would be routed is shown/configured, hi accordance with the invention, each different Payment Processor may require a different setup and the Credit Card Payment Processing System in accordance with the invention may be used with various different Payment Processors. As can be seen, the inteπnediary provides the flexibility to support Transaction Requests in different foπnats and can convert

Transaction Requests to the appropriate format required by the intended processor (in this case, PC Charge Payment Server), hi step 3170, the foπnat of the transaction data for the existing Payment Processors, ICVERIFY and PayFlowPro, is defined and then stored in a database associated with the inteπnediary system in step 3172. hi step 3174, the merchant account information for each merchant account with the PC Charge Payment Server (the new Payment Processor) is determined and then stored in the database. In step 3176, the set-up determines if the Business Software System will generate Transaction Requests for this merchant account as a Transaction Request file or through a port and stores that data into the database. In step 3178, the set-up identifies the folder into which the Business Software System would place the Transaction Request file or the port to which it will send the Transaction Request and stores that data into the database, hi step 3180, the maximum number of transactions that the inteπnediary is allowed to process concuπently is specified and then stored in the database. The defining of the maximum number of transactions permits the user to control the load on the system. In addition, each Payment Processor may have licensing restrictions on the number of simultaneously-processed transactions so the user can use the maximum number of concuπent transactions to stay within the license requirements. A method for monitoring the Transaction Requests in accordance with the invention is described as follows.

Figure 30 is a diagram showing the how the intermediary's monitoring service 3190 monitors Transaction Requests. When the intermediary's monitoring service is initiated for a processor, it retrieves information for that processor from its database in step 3192 wherein each Payment Processor has a profile in the database that contains the relevant infomiation about that Payment Processor such as the fomiat of the data. The configuration set-up user interface for the monitoring server and the Payment Processor will be described in more detail below with reference to Figures 34 and 35. It then creates as many instances of the processor object as the number of concuπent transactions allowed for the processor and as specified in the processor settings in step 3194 and begins monitoring based on the monitor type in step 3196. It also creates as many Threads for processing Transaction Requests as are specified in the general configuration for the inteπnediary in step 3198. A method for processing a payment request in accordance with the invention is described in more detail as follows.

Figure 31 A is a diagram that illustrates a method 3200 by which the inteπnediary in accordance with the invention processes a payment request. In step 3202, the intermediary receives a notification of a payment request. When a Transaction Request is received, the inteπnediary identifies the source of the Transaction Request and the fomiat in which the Transaction Request has been sent. It also identifies the processor to which the Transaction Request should be directed, hi step 3204, the inteπnediary may assign a session ID and transaction ID to the Transaction Request, hi step 3206, the inteπnediary detemiines if a processor service is initiated. If the processor service is not initiated, then an eπor is posted in step 3208. If the processor service for the particular Payment Processor is initiated, then the intermediary deteπnines if a Worker Thread is available in step 3210. hi particular, for the purpose of concurrently performing transactions, each Transaction Request is processed by a dedicated "Thread" wherein a Thread is the basic unit to which the operating system allocates processor time. This dedicated Tliread which PayBridge allocates for processing requests is called a "Worker Tliread". The number of Worker Threads specifies the number of concurrent transactions that PayBridge should handle at any given point of time since one Worker Thread at any point of time can process only one Transaction Request. During this process, the Worker Tliread consumes one processor object con'esponding to the Transaction

Request. If a Worker Tliread is available and the coπesponding processor object is available then the Transaction Request is taken up for processing. If on the other hand, no Worker

Threads are available or if the coπesponding processor object is not available then the Transaction Request goes into the queue as described below in step 3212. To better understand these concepts, consider the following example (with the following configurations settings). In this example, the system may have three (3) Worker

Threads (Worker 1, Worker 2 and Worker 3.) Furthermore there may be two objects allocated for a Processor with code 1001, one object allocated for a Processor with code 1002 and three objects allocated for a Processor with code 1002. hi this case, the system would operate as follows: I) Request for Processor 1001 ID: 1 Request for Processor 1002 ID: 2 Request for Processor 1003 ID: 3 Assuming all the Transaction Requests come at the same time, the Transaction

Requests will be handled concuπently by PayBridge in the order below. Worker 1 - Request for Processor 1001 ID: 1 Worker 2 - Request for Processor 1002 ID: 2 Worker 3 - Request for Processor 1003 ID: 3 II) Request for Processor lOOl ID: 1 Request for Processor 1002 ID: 2 Request for Processor 1002 ID: 3 Request for Processor 1001 ID: 4 Request for Processor 1001 JO: 5 Request for Processor 1001 ID: 6

Returning to Figure 31 A, if a Worker Thread is not available, then the Transaction Request is added to the queue in step 3212 that waits until a Worker Thread is available. If the Worker Thread is available, then in step 3214, the intemiediary deteπnines if a processor object is available and add the Transaction Request to the queue in step 3212 if a processor object is not available. When a Transaction Request is in the queue, the intermediary determines if there are any Transaction Requests in the queue in step 3216 and loops back to step 3210 to process the queued Transaction Request. If there are no other Transaction Requests in the queue, then the method is completed.

When a processor object and Thread is free, it begins to process the Transaction Request. It translates the Transaction Request from its cuπent foπnat to the fomiat in which the processor requires Transaction Requests to be transmitted in step 3218. h step 3220, the intemiediary attempts to validate the Transaction Request and posts an eπor in step 3208 if the Transaction Request is not valid or transmits the Transaction Request in step 3222 after validating it. On receiving the response in step 3224 from the processor, the inteπnediary translates the Transaction Request back to the format recognized by the source of the Transaction Request in step 3226. Thus, the intermediary in accordance with the invention accommodates different Payment Processors and different foπnats so that any Payment Processor may be used with a Busmess Software System wherein the seamless integration of the Payment Processor exists without the undue expense of integrating the new Payment Processor into the Business Software System, hi accordance with a prefeπed embodiment of the invention, the system may include an XML-based translator that converts/translates between the different formats of the Payment Processors. Figures 36A and 36B described below provide an example of a Transaction Request and the coπesponding translated output sent to PCCharge. An example of a computer systems implementation of the Credit Card Payment Processing System in accordance with the invention is described in more detail as follows.

Figure 3 IB is a block diagram illustrating an example of a computer-implemented Credit Card Payment Processing System 3300 in accordance with the invention. The Credit Card Payment Processing System may also be implemented as one or more software modules/pieces with a plurality of instructions of code residing on a physical data storage medium, such as a CD, DVD or other storage medium, wherein the software is installed from the CD onto a computer system for execution or executed by the computer system directly from the physical data storage medium. Similarly, the Credit Card Payment Processing

System may be implemented as pieces of software embedded onto a hardware device wherein a computer system executes the Credit Card Payment Processing System using the hardware device. The computer implemented system 3300 comprises various well known computer resource components whose function and operation are not described as they are well lαiown, including one or more processors 3302, a persistent storage device 3304, such as a hard disk drive, optical drive, tape drive or flash memory, and a memory 3306, such as DRAM or SRAM that stores the data and instructions being executed by the computer while the computer is turned on. The computer system 3300 may ftirther include other well known components such as various input/output devices and devices that connect the computer system to the Internet and a computer network.

To implement the Credit Card Payment Processing System in accordance with the invention, the computer implemented system includes/is connected to a database 3318 and one or more Payment Processors 3322] - 3322_n as shown. The computer-implemented system 3300 further includes one or more pieces of software/modules that implement the Credit Card Payment Processing System such as a well known operating system 3308 and a Credit Card Payment Processing System 3 10 in accordance with the invention. The Credit Card Payment Processing System may further include one more modules including a user interface module 3312, a monitor module 3314 and a payment processing module 3316. In the example shown, these pieces of software reside in the memory 3306 and are being executed by the processor 3302 to implement the Credit Card Payment Processing System. For example, the user interface portion 3312 may generate the user interfaces presented to the user during the execution of the Credit Card Payment Processing System, the monitor module 3314 may monitor the credit card payment Transaction Requests as shown in more detail in Figure 30 and the payment processing module handles payment requests as shown in Figure 31 A. Thus, each step shown in Figures 30 and 31 A may be implemented using one or more computer program insfructions. In accordance with the invention, the Credit Card Payment Processing System may utilize one or more Payment Processor profiles based on information 3320 stored in the database 3318 (which may be the same database used for the Business

Software System shown in Figure 1) and assist the Payment Processors 3322] - 3322_n in the completion of the credit card payment request. Examples of the user interfaces for the Credit Card Payment Processing System in accordance with the invention are described in more detail as follows. First, a user interface to configure the system in accordance with the invention will be described.

Figure 32 illustrates an example of a user interface 3350 for configuring an intermediate payment system in accordance with the invention. In this example, the intermediate payment system is being configured to operate with the PC Charge Payment Server for which the particular Business Software System is not configured. As shown, various variables, such as the server path, merchant name or processing network may be configured for each merchant and each Payment Processor.

Figure 33 illustrates an example of a user interface 3360 for monitoring and displaying the status of the different Transaction Requests received by the Credit Card

Payment Processing System. The user interface may include a summary portion 3362 and an event monitor viewer 3364. As shown in the summary portion, the credit card payment requests for one or more different Payment Processors is being monitored. In the event monitor viewer 33 4, each payment transaction is monitored and the cuπent status of each fransaction is viewable by the user.

In accordance with the invention, there is provided a method and an apparatus for a Business Software System to communicate with different Payment Processors without having to generate Transaction Requests in the specific fomiats stipulated by each processor or having the necessary mechanisms for directly communicating with the processor. In accordance with one aspect of the invention, the Intermediary Payment Processor has the required definitions for communication protocols and Transaction Requests from Business Software Systems in the fomiats understood by ICVERIFY and PayFlowPro. It also has the coπesponding foπnats for the data fonnat supported by PC Charge Payment Server. The Intermediary Payment Processor thus monitors the specified ports or folders for Transaction Requests in a format published by ICVERIFY and PayFlowPro and translates these Transaction Requests to formats published by PC Charge Payment Server. It then translates the response from PC Charge Payment Server to the foπnat published by ICVERIFY or PayFlowPro as the case maybe. The Business Software System from which the Transaction Request originated will now be able to decipher the response and carry out further actions based on the type of response.

The credit card processing system provides many advantages. The system permits Business Software Systems to support multiple Payment Processors without making changes to their code base. The system also enables the existing users of Business Software Systems to switch to a Payment Processor not supported by their cuπent Business Software System without having to make changes to the data setup in their software or having to resort to a manual system of processing. The system also pemiits the users of multiple Business Software Systems to use a single intermediary and multiple Payment Processors and multiple merchant accounts. The system also allows the websites and online shops that are dependent on TCP/IP and other protocols for real time payment processing to conveniently use Payment Processors that are based on an alternate method of connection such as dial up without having to make changes to their website or online shop.

Thus, in accordance with the invention, a Payment Processor is provided. The Payment Processor stores the required definitions for communication protocols and Transaction Requests from Business Software Systems in the foπnats understood by any payment processing software and the formats for the data foπnat supported by the payment server so as to monitor the specified ports or folders for Transaction Requests in a format published by the payment processing software. The system has a means to translate these Transaction Requests to foπnats published by the payment server and a means for translating the response from the payment server to the fomiat published by the payment processing software so as to enable the Business Software System from which the Transaction Request has originated to decipher the response and carry out further actions based on the type of response.

In accordance with another aspect of the invention, a Payment Processor is provided. The Payment Processor is software comprising a set of instructions to fomiat the transaction data based on the payment processing software, set up the merchant account infomiation for each merchant account with the coπesponding payment server, identify the output mode of the transactions requests for this merchant account as a Transaction Request file or through a port, identify the folder in which the Transaction Request file is to be placed or the port to which the Transaction Request is to be sent, specify the maximum number of transactions that the inteπnediary is allowed to process concuπently and in each step, updates the database with the setup data. The Payment Processor may further include software instructions to intercede between the Business Software System and the Payment Processor by receiving Transaction Requests and assigning them for further processing by retrieving the information for particular monitor and processor from its database, begin monitoring based on the monitor type, create a repository of the processor templates objects based on the number of concurrent transactions specified, create Workers Threads based on the configuration settings and create the number of workers available, such that if workers are available end the process, or if workers are not available create Workers Threads and then end the process. hi accordance with yet another aspect of the invention, a Payment Processor is provided that is software comprising a set of instructions. The software foπnats the transaction data based on the payment processing software, sets up the merchant account information for each merchant account with the corresponding payment server, identifies the output mode of the Transaction Requests for this merchant account as a Transaction Request file or through a port, identifies the folder in which the Transaction Request file is to be placed or the port to which the Transaction Request is to be sent, and specifies the maximum number of transactions that the inteπnediary is allowed to process concuπently and in each step, updates the database with the setup data. The software also has a further set of software instructions to process a payment Transaction Request comprising a means to identify the source of the Transaction Request and the format in which the Transaction Request has been sent, identifying the processor to which the Transaction Request should be directed, assigning the Transaction Request received to the processor object and the Thread, and if free, begin to process the Transaction Request by translating the Transaction Request from its cuπent foπnat to the foπnat in which the processor requires the Transaction Requests to be transmitted and then transmit the Transaction Request after due validation, redirecting the response from the processor to the format recognized by the source of the Transaction Request, or in case the processor object and the Tliread are not free, send it to the queue.

In accordance with yet another aspect of the invention, a method for operating an h temiediary Payment Processor is provided, hi the method, the definitions for transaction data generated by the Business Software System are specified along with the equivalent definitions to be used for transmitting such infomiation to the Payment Processor. The definitions for the fomiat into which the responses from the Payment Processor need to be converted are specified in order that the information can be read and understood by the Business Software System. Furthermore, the folders or ports that need to be monitored by the inteπnediary for Transaction Requests are specified from the Business Software System and the merchant account and other infoπnation is specified that would be used by the inteπnediary to connect to the Payment Processor. The method may preserve these definitions in the foπ of metadata. The method may start the monitoring service whereby the folders or ports would be monitored for Transaction Requests. The method also handles Transaction Requests and conveys the results of the Transaction Requests to the respective folders or ports. Figure 34 illustrates an example of a configuration user interface 3400 in which the user can configure the monitoring functionality of the payment processing system. As shown, the user interface permits the user to specify various monitoring details including the file path, the processor code, the file extensions and the timeout periods for the monitoring process. Similarly, a processor configuration interface 3410 is shown in Figure 35 that pennits the user of the system to specify various payment server details that peπnit the system to interact with the particular payment server.

Figures 36A and 36B illustrate an example of a payment processing request and the translated output for PCCharge, respectively. The example of the payment processing request is in the format required by PayFlowPro. In accordance with the invention, the system is capable of generating Transaction Requests for many different payment processors. The translated output (generated by the payment processing system in accordance with the invention) is for the PCCharge Payment Server. For PCCharge, it provides a COM object and the properties of this object is set after parsing the text sent from both ICVERIFY and PayFlowPro Transaction Request fomiats. Thus, an example of the properties of the COM object for the PayFlowPro Transaction Request shown in Figure 36A is shown in Figure 36B. Figure 36B contains comments for each object property that are enclosed in the curly brackets.

While the foregoing has been with reference to a particular embodiment of the invention, changes in this embodiment may be made without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims.

Claims

CLAIMS: 1. A mail management method for retrieving and adding e-mail messages to an existing business software application database, comprising: scanning a header portion of each message to locate an identification; comparing the identification with a plurality of identifications stored in a business software application database to identify a matching identification; adding the message with the matching identification into the business software application database wherein the message is associated with the matching identification; and creating a Task associated with the message that is linked to the business software application database.

2. The method of Claim 1, wherein scanning the header portion further comprises identification infomiation in one or more fields of the header portion, the one or more fields including a to field, a from field, a carbon copy field and a blind carbon copy field.

3. The method of Claim 2, wherein the identification further comprises an e-mail address.

4. The method of Claim 1, wherein adding the message further comprises adding the message and its attachments into the business software application database.

5. The method of Claim 1 further comprising adding a new identification from the message and the message into the business software application database when no matching identification is located.

6. The method of Claim 1 further comprising excluding a new identification from the message and the message from the business software application database when no matching identification is located.

7. The method of Claim 6, wherein the step of excluding a new identification is user selectable.

8. The method of Claim 6, wherein excluding a new identification further comprises excluding a new identification from the business software application database when the new identification matches an excluded address pattern.

9. The method of Claim 8, wherein the address pattern is user selectable.

10. A computer implemented mail management system for use with a business software application that has a database, the system comprising: a mail management module that executes on a computer system, the mail management module further comprising instructions that scan a header portion of each message to locate an identification, instructions that compare the identification with a plurality of identifications stored in a business software application database to identify a matching identification, instructions that add the message with the matching identification into the business software application database wherein the message is associated with the matching identification, and instructions that create a Task associated with the message that is linked to the business software application database.

11. The system of Claim 10, wherein the scanning instructions further comprises instructions that scan identification information in one or more fields of the header portion, the one or more fields including a to field, a from field, a carbon copy field and a blind carbon copy field.

12. The system of Claim 11 , wherein the identification further comprises an e-mail address.

13. The system of Claim 10, wherein the instructions that add the message further comprises instructions that add the message and its attachments into the business software application database.

14. The system of Claim 10, wherein the mail management module further comprises instructions that add a new identification from the message and the message into the business software application database when no matching identification is located.

15. The system of Claim 10, wherein the mail management module further comprises instructions that exclude a new identification from the message and the message from the business software application database when no matching identification is located.

16. The system of Claim 15, wherein the instructions that exclude a new identification further comprises instructions that permit the user to select the excluded new identifications.

17. The system of Claim 15, wherein the instructions that exclude a new identification further comprises instnictions that exclude a new identification from the business software application database when the new identification matches an excluded address pattern.

18. The system of Claim 17, wherein the excluded address pattern is user selectable.

19. A computer implemented mail management system for use with a business software application that has a database, the system comprising: a mail management module that executes on a computer system, the mail management module further comprising means for scanning a header portion of each message to locate an identification, means for comparing the identification with a plurality of identifications stored in a business software application database to identify a matching identification, means for adding the message with the matching identification into the business software application database wherein the message is associated with the matching identification, and means for creating a Task associated with the message that is linked to the business software application database.

20. The system of Claim 19, wherein the scanning means further comprises means for scanning identification information in one or more fields of the header portion, the one or more fields including a to field, a from field, a carbon copy field and a blind carbon copy field.

21. The system of Claim 20, wherein the identification further comprises an e-mail address.

22. The system of Claim 19, wherein the adding means further comprises means for adding the message and its attachments into the business software application database.

23. The system of Claim 19, wherein the mail management module further comprises means for adding a new identification from the message and the message into the business software application database when no matching identification is located.

24. The system of Claim 19, wherein the mail management module further comprises means for excluding a new identification from the message and the message from the busmess software application database when no matching identification is located.

25. The system of Claim 24, wherein the excluding means further comprises means for permitting the user to select the excluded new identifications.

26. The system of Claim 24, wherein the excluding means further comprises means for excluding a new identification from the business software application database when the new identification matches an excluded address pattern.

27. The system of Claim 26, wherein the excluded address pattern is user selectable.

28. A computer implemented mail management system for use with a business software application that has a database, the system being downloaded to a computer system from a piece of media, the piece of media further comprising: instructions that scan a header portion of each message to locate an identification; instructions that compare the identification with a plurality of identifications stored in a business software application database to identify a matching identification; instmctions that add the message with the matching identification into the business software application database wherein the message is associated with the matching identification; and instructions that create a Task associated with the message that is linked to the business software application database.

29. The system of Claim 28, wherein the scanning instructions further comprises instructions that scan identification information in one or more fields of the header portion, the one or more fields including a to field, a from field, a carbon copy field and a blind carbon copy field.

30. The system of Claim 29, wherein the identification further comprises an e-mail address.

31. The system of Claim 28, wherein the instructions that add the message further comprises instructions that add the message and its attachments into the business software application database.

32. The system of Claim 28, wherein the mail management module further comprises instructions that add a new identification from the message and the message into the business software application database when no matching identification is located.

33. The system of Claim 28, wherein the mail management module further comprises instmctions that exclude a new identification from the message and the message from the business software application database when no matching identification is located.

34. The system of Claim 33 , wherein the instructions that exclude a new identification further comprises instmctions that pemiit the user to select the excluded new identifications.

35. The system of Claim 33, wherein the instructions that exclude a new identification further comprises instructions that exclude a new identification from the business software application database when the new identification matches an excluded address pattern.

36. The system of Claim 35, wherein the excluded address pattern is user selectable.

37. A method to integrate an e-mail client with a business software application and its database, the method comprising: setting up one or more e-mail accounts for each user of the business software wherein each account is configured for the preferences of each user; combining a global address book from an e-mail server, a user's personal address book and the e-mail addresses of contacts in the database of the business software together to generate a centralized database of e-mail addresses; associating an e-mail message with a contact in the database of the business software; storing the e-mail message in the centralized database of the business software according to the contact associated with the e-mail message; and retrieving messages from the centralized database based on a selected contact.

38. The method of Claim 37, wherein storing the e-mail message further comprises storing the e-mail message and its attachments into the database of the business software.

39. A method of Claim 37, wherein the messages fomiats used are Plain Text, Rich Text Format and Hypertext Markup Language.

40. An e-mail client system comprising a computer program configured to execute on a processor, the computer program further comprising: instmctions that set up one or more e-mail accounts for each user of the business software wherein each account is configured for the preferences of each user; instructions that combine a global address book from an e-mail server, a user's personal address book and the e-mail addresses of contacts in the database of the business software together to generate a centralized database of e-mail addresses; instructions that associate an e-mail message with a contact in the database of the business software; instructions that store the e-mail message in the centralized database of the business software according to the contact associated with the e-mail message; and instructions that retrieve messages from the centralized database based on a selected contact.

41. The system of Claim 40, wherein instructions that store the e-mail message further comprises instructions that store the e-mail message and its attachments into the database of the business software.

42. A system of Claim 40, wherein the messages fomiats used are Plain Text, Rich

Text Format and Hypertext Markup Language.

43. An e-mail client system comprising: means for setting up one or more e-mail accounts for each user of the business software wherein each account is configured for the preferences of each user; means for combining a global address book from an e-mail server, a user's personal address book and the e-mail addresses of contacts in the database of the business software together to generate a centralized database of e-mail addresses; means for associating an e-mail message with a contact in the database of the business software; means for storing the e-mail message in the centralized database of the business software according to the contact associated with the e-mail message; and means for retrieving messages from the centralized database based on a selected contact.

44. The system of Claim 43 , wherein the storing means further comprises means for storing the e-mail message and its attachments into the database of the business software.

45. A system of Claim 43, wherein the messages formats used are Plain Text, Rich Text Format and Hypertext Markup Language.

46. An e-mail client system of Claim 43, wherein the combining means ftirther comprises means for integrating the address retrieval element of the e-mail client with the metadata of the entities stored in the database.

47. An e-mail client system as claimed in claim 43, wherein the associating means further comprises means for identifying the relevant metadata of the entity in the business database and means for storing a copy of the e-mail data in the database, the e-mail data being attached and indexed to the data of the particular entity to which the e-mail is sent.

48. A static page generating system for use with a system that generates dynamic active server pages from a database of data, the system comprising: a database containing data to be inserted into the dynamic active server pages; a template stored in the database that contains at least one iTag wherein each iTag coπesponds to a particular piece of data in a database; and a software application executing on the system that has a set of instnictions to generate a static page based on the template wherein the iTag is replaced with the coiresponding data in the database so that the static page has static data, based on the data in the database, that is indexable by a crawler.

49. The static page generation system of Claim 48, wherein the static page further comprises an HTML page.

50. The static page generating system of Claim 48, wherein the computer software further comprising instructions that replace the iTag in the template with product infomiation from a database.

51. The static page generation system of Claim 50, wherein each template further comprises a product name iTag, a product price iTag, a product code iTag and a product description iTag wherein product name, price, code and description data from the database are inserted into the generated HTML page.

52. The static page generating system of Claim 48, wherein the template further comprises a template for each index/category HTML page and a template for each item/item alias HTML page.

53. A static page generating system for use with a system that generates dynamic active server pages from a database of data, the system comprising: a set of templates stored in a database, each template with at least one iTag wherein each iTag coπesponds to a particular piece of data in a database, the set of templates further comprising a template for a static category page and a template for a static item page; means for obtaining data in the dynamic active server pages from a database connected to the static page generation system; and means for replacing the iTags in the template with the data from the database to produce a static page so that the static page has static data, based on the data in the database, that is indexable by a crawler.

54. The static page generation system of Claim 53, wherein the static page further comprises an HTML page.

55. The static page generating system of Claim 53, wherein the computer software further comprising instructions that replace the iTag in the template with product infomiation from a database.

56. The static page generation system of Claim 55, wherein each template ftirther comprises a product name iTag, a product price iTag, a product code iTag and a product description iTag wherein product name, price, code and description data from the database are inserted into the generated HTML page.

57. The static page generating system of Claim 53, wherein the template further comprises a template for each index/category HTML page and a template for each item/item alias HTML page.

58. A method of generating a static page for use with a system that generates dynamic active server pages from a database of data, the method comprising: storing a set of templates, each template having at least one iTag wherein each iTag coπesponds to a particular piece of data in a database, the set of templates further comprising a template for a static category page and a template for a static item page; obtaining data in the dynamic active server pages from a database connected to the static page generation system; and replacing the iTags in the template with the data from the database to produce a static page so that the static page has static data, based on the data in the database, that is indexable by a crawler.

59. The static page generation method of Claim 58, wherein the static page ftirther comprises an HTML page.

60. The static page generating method of Claim 58 further comprising replacing the iTag in the template with product information from a database.

61. The static page generation method of Claim 60, wherein each template further comprises a product name iTag, a product price iTag, a product code iTag and a product description iTag wherein product name, price, code and description data from the database are inserted into the generated HTML page.

62. The static page generating method of Claim 58, wherein the template further comprises a template for each index/category HTML page and a template for each item/item alias HTML page.

63. A static page generating system for use with a system that generates dynamic active server pages from a database of data, the system comprising: a page generation computer software application; one or more templates associated with the HTML page generation application, each template containing at least one iTag wherein each iTag coπesponds to a particular piece of data in a database with data that generates dynamic active server pages; and the static page generation application further comprising a module that replaces the iTag in the template with the coπesponding data from the database so that the static page has static data, based on the data in the database, that is indexable by a crawler.

64. The static page generation system of Claim 63, wherein the static page ftirther comprises an HTML page.

65. The static page generating system of Claim 63, wherein the computer software ftirther comprising instructions that replace the iTag in the template with product infomiation from a database.

66. The static page generation system of Claim 65, wherein each template further comprises a product name iTag, a product price iTag, a product code iTag and a product description iTag wherein product name, price, code and description data from the database are inserted into the generated HTML page.

67. The static page generating system of Claim 63, wherein the template further comprises a template for each index/category HTML page and a template for each item/item alias HTML page.

68. An inteπnediate payment processor for processing payments between a business software system and a payment processor, the system comprising: a database containing one or more definitions wherein each definition is a definition for communication protocols including one of a specified port and folder, transaction requests from the business software system in the formats understood by each payment processor, and the formats for the data format supported by a payment server of the payment processor; and a payment processing module further comprising a means for monitoring the specified ports or folders for a fransaction request in a fonnat published by the payment processor, means for translating the transaction request into a foπnat published by the payment server based on the definition for the payment server in the database and a means for translating a response from the payment server into a format of the payment processing module so as to enable the business software system from which the request has originated to decipher the response and carry out further actions based on the type of response.

69. The system of Claim 68, wherein the payment processing module further comprises means for setting up a merchant account infomiation for each merchant account with the coπesponding payment server, means for identifying an output mode of the transactions requests for each merchant account as a request file or through a port, means for identifying a folder in which the request file is to be placed or the port to which the request is to be sent, and a means for specifying the maximum number of transactions that the intermediary is allowed to process concuπently and in each step, updates the database with the setup data.

70. The system of Claim 69, wherein the payment processing module further comprises means for intercepting a transaction request from the business software system and assigning the transaction request to a particular payment processor based on the definitions contained within the database, means for monitoring the transaction request based on the definition associated with that transaction request, means for generating a repository of the processor templates objects based on the number of concurrent transactions specified, and a means for creating workers threads based on the configuration settings and create the number of workers available.

71. An intermediate payment processor for processing payments between a business software system and a payment processor, the system comprising: a database containing one or more definitions wherein each definition is a definition for communication protocols including one of a specified port and folder, transaction requests from the business software system in the foπnats understood by each payment processor, and the foπnats for the data fomiat supported by a payment server of the payment processor; and a payment processing module comprising a computer program wherein the computer program further comprises instnictions that monitor the specified ports or folders for a fransaction request in a format published by the payment processor, instmctions that translate the transaction request into a format published by the payment server based on the definition for the payment server in the database and instructions that translate a response from the payment server into a foπnat of the payment processing module so as to enable the business software system from which the request has originated to decipher the response and carry out further actions based on the type of response.

72. The system of Claim 71 , wherein the payment processing module further comprises instructions that set up a merchant account infomiation for each merchant account with the coπesponding payment server, instnictions that identify an output mode of the transactions requests for each merchant account as a request file or through a port, instnictions that identify a folder in which the request file is to be placed or the port to which the request is to be sent, and instmctions that specify the maximum number of transactions that the intennediary is allowed to process concuπently and in each step, updates the database with the setup data.

73. The system of Claim 72, wherein the payment processing module further comprises instnictions that intercept a transaction request from the business software system and assigning the transaction request to a particular payment processor based on the definitions contained within the database, instmctions that monitor the transaction request based on the definition associated with that transaction request, instructions that generate a repository of the processor templates objects based on the number of concuπeiit transactions specified, and instmctions that create workers threads based on the configuration settings and create the number of workers available.

74. A payment processor comprising: a piece of software wherein the software further comprises one or more sets of instmctions; wherein a first set of instructions further comprise instructions to foπnat transaction data based on a type of payment processing software, instmctions to set up a merchant account information for each merchant account with a coiresponding payment server, instnictions to identify an output mode of each transactions request for the merchant account as one of a request file and through a port, instructions to identify a folder in which the request file is to be placed or the port to which the request is to be sent, instructions to specify a maximum number of transactions that the intermediary is allowed to process concurrently and instructions to update a database; and wherein a second set instructions further comprises instructions to process a payment request further comprising instructions to identify a source of the request and a fonnat in which the request has been sent, instructions to identify a payment processor to which the request should be directed, instructions to assign the request to a processor object and a tliread, instmctions that process the request when a free processor object and thread are available by translating the request from a cuiτent fomiat to a foπnat in which the payment processor requires the requests to be transmitted and instmctions to transmit the request after due validation, instnictions to redirect the response from the processor to the fonnat recognized by the source of the request, or in case the processor object and the thread are not free send it to the queue.

75. An inteπnediate payment processing method for processing payments between a business software system and a payment processor, the method comprising: providing a database containing one or more definitions wherein each definition is a definition for communication protocols including one of a specified port and folder, transaction requests from the business software system in the formats understood by each payment processor, and the fonnats for the data fonnat supported by a payment server of the payment processor; monitoring the specified ports or folders for a transaction request in a fonnat published by the payment processor; translating the transaction request into a fonnat published by the payment server based on the definition for the payment server in the database; and translating a response from the payment server into a fonnat of the payment processing module so as to enable the business software system from which the request has originated to decipher the response and carry out further actions based on the type of response.

76. The method of Claim 75 further comprising setting up a merchant account infomiation for each merchant account with the coπesponding payment server, identifying an output mode of the transactions requests for each merchant account as a request file or through a port, identifying a folder in which the request file is to be placed or the port to which the request is to be sent, and specifying the maximum number of transactions that the intermediary is allowed to process concuπently and in each step, updates the database with the setup data.

77. The method of Claim 76 ftirther comprising intercepting a transaction request from the business software system, assigning the transaction request to a particular payment processor based on the definitions contained within the database, monitoring the fransaction request based on the definition associated with that transaction request, generating a repository of the processor templates objects based on the number of concuπeiit fransactions specified, and creating workers threads based on the configuration settings and create the number of workers available.