Note: Descriptions are shown in the official language in which they were submitted.
CA 02537156 2006-02-27
WO 2005/022345 PCT/US2004/028002
BUSINESS SOFTWARE APPLICATI0~1 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. 601498,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. 101847,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.
Baclc~round of the Invention
Business software applications are well laiown. These business software
applications
typically have various fiinctions 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 necessary and desirable tools and fiinctions. For
example, it would be
desirable to provide a business software application that has an integrated
mail management
CA 02537156 2006-02-27
WO 2005/022345 PCT/US2004/028002
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 fimctions 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. h1 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. fil 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 inefftcient.
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" lcnowii as 'POP3' and the second one is
"hlternet 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 1MAP 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. W both systems, it is not possible to
download a message
and link it with existing business software applications. There also exists a
third laiov~m e-
CA 02537156 2006-02-27
WO 2005/022345 PCT/US2004/028002
mail message protocol, "Messaging Application Programming Interface" ("MAPI"),
which is
exclusively used by Microsoft. The MAPI protocol is very much like I1VIAP, 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
(IMAP,
POP3), Eudora (POP3), Outlook Web Access (Hypertext Transfer Protocol i.e.
HTTP),
Outlook (MAPI, IMAP, POP3) and Outlook Express (POP3, IMAP). The proposed e-
mail
management system of the present invention integrated into a business
softyvare application
ensures reduced manual labor with the greatest possible lineage 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 marry
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 newldifferent 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 d5mamic in
nature, it is
CA 02537156 2006-02-27
WO 2005/022345 PCT/US2004/028002
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 iWibits a User
fr0111
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 refttnds through ICVERIFY.
Everest
generates Transaction Request files in the fornat 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 fornulates
the response of
the processing networlc in an answer file and Everest reads the answer file
and records the
response in the fore of metadata in its database. Everest also perforns
ftirther 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 form 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 strucW res and fornats. Thus, it is desirable to provide a payment
processing
CA 02537156 2006-02-27
WO 2005/022345 PCT/US2004/028002
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
integrated e-mail client, an integrated HTML page generator system and an
integrated credit
card processing systems is provided. Each of these integrated 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-
mail messages, and the internal users of the system. Au 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, W c.
The e-mail
messages are then desirably imported into business software (of various types)
and linlcages
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 arid 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 traclcing 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 fomn of e-mail
messages, into other
business software application. The mail management system and method also
associates such
CA 02537156 2006-02-27
WO 2005/022345 PCT/US2004/028002
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 attaclunents for data mining and tracking proposes and enhanced customer
relationship
management. The system further ensures that no correspondence with Business
Parhiers goes
unrecorded/untraclced 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 Taslc may be created, wherever necessary, along with
necessary lincs to
the database or create necessary linlcs 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.
W accordance with yet another aspect of the invention, a method and apparaW s
for
importing external correspondence between Evexest 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 traclcing
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 apparaW s
also provides the ability to view the e-mail messages and attachments for a
Taslc or Business
Parhzer by various parameters imported from the external E-mail Client.
CA 02537156 2006-02-27
WO 2005/022345 PCT/US2004/028002
7
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 intenaal 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 marls messages as read or unread and print e-
mails. There is
also provided a method for stnicturing, 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 apparaW s to
centralize
communication with external entities by providing various features. For
example, the system
provides configwation and supports POP3 and MAPI e-mail accounts for external
communication. W ternal 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, linlcs 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 boolc 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. W 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
fimther 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
CA 02537156 2006-02-27
WO 2005/022345 PCT/US2004/028002
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).
W 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
S processor or computer. The instructions perform different fimctions. 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 arnval 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 Wlth 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 inshwctions
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 fox 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
f<mctions 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
CA 02537156 2006-02-27
WO 2005/022345 PCT/US2004/028002
iCode. A method fox 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 W tenret. 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 every 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 dyiamic 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.
W 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 d5mamic pages so that the
User is
CA 02537156 2006-02-27
WO 2005/022345 PCT/US2004/028002
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 cal-ts is provided. The HTML page
generation system
comprises computer software having a set of instnictions 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 infornzation in the database. The system
may provide
one template each for indexlCategory Pages and for iten~/Iteln Alias Pages.
10 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 fox 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. 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, pxoduct infornlation 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
CA 02537156 2006-02-27
WO 2005/022345 PCT/US2004/028002
11
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
Paynent
Processors, such as ICVERIFY and PayFlowPro for example. In one example, the
Intermediary Payment Processor also has the corresponding fonnats for the data
format
supported by PC Charge Payment Server. hi one example, the W tennediaiy
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 W tennediary 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
fiirther actions
based on the type of response. In accordance with the invention, the
Intennediaiy Payment
Processor may be used with various different Payment Processors. W 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 marls-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 nmiltiple Payment
Processors and
CA 02537156 2006-02-27
WO 2005/022345 PCT/US2004/028002
12
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 COt111eCt1011
StlCh 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 fornzats 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 format
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 format 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 fitrther 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 instntctions to format
the transaction
data based on the payment processing software, set up the merchant account
information for
each merchant account with the corresponding payment server; identify the
output mode of
the transactions requests for this merchant account as a Transaction Request
ftle or tluough 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 concurrently, 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 a pauicular 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 worlcers are
available end the process, or if workers are not available create Worker
Threads and then end
the process.
CA 02537156 2006-02-27
WO 2005/022345 PCT/US2004/028002
13
In accordance with yet another aspect of the invention, a Payment Processor is
provided that is software comprising a set of instructions. The software
formats 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
ftle 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 intennediaiy is allowed to process
concurrently, 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 forniat 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 current
format 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.
In 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. Furtherniore, 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
intermediary to connect to the Payment Processor. The method may preserve
these
definitions in the form of metadata. The method may start the monitoring
service whereby
the folders or ports would be monitored fox Transaction Requests. The method
also handles
Transaction Requests and conveys the results of the Transaction Requests to
the respective
folders or ports.
CA 02537156 2006-02-27
WO 2005/022345 PCT/US2004/028002
14
Brief Descrption 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 3A illustrates the sequence of steps involved in naming 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 rm~ning the e-mail management system in
accordance with the invention;
Figure $ depicts the user interface in Everest for filtering Taslcs by a user;
Figure 9 depicts the user interface in Everest for filtering Taslcs by
documentlcustomerlvendor;
Figure 10 depicts the relationship between Taslcs, 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 Taslc 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;
CA 02537156 2006-02-27
WO 2005/022345 PCT/US2004/028002
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
fron~/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
10 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;
15 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 instnictions/settings
for the
User;
Figures 22A and 22B illustrate an example of a template fox 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
corresponding 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
corresponding
HTML Item Page that are generated for an e-commerce site using the HTML page
generator
system in accordance with the invention;
CA 02537156 2006-02-27
WO 2005/022345 PCT/US2004/028002
16
Figures 23A- 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 permits 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 Sof~uare
System such as Everest and a supported Payment Processor such as ICVER1FY;
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 sehip in the intermediary 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 31A is a flow diagram that illustrates how the intennediaiy 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 31 B is a diagram illustrating a computer system implementation of the
Credit
Card Payment Processing System in accordance with the invention;
CA 02537156 2006-02-27
WO 2005/022345 PCT/US2004/028002
17
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
stahis 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
intemnediary 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 Preferred 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 teens 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.
CA 02537156 2006-02-27
WO 2005/022345 PCT/US2004/028002
18
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 Partxlers.
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.
ICVEItIFY: 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
fornlats and/or
connection protocols. The Intermediary Payment Processor helps to bridge the
gaps in file
CA 02537156 2006-02-27
WO 2005/022345 PCT/US2004/028002
19
formats 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
algoritluns. 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>
<META name="lceywords" content="Your site's lceywords here">
</HEAD>
</HTML>
CA 02537156 2006-02-27
WO 2005/022345 PCT/US2004/028002
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 form 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. h1 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
10 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
15 HTML page generation system.
Templates are included in Everest E-commerce. There are one or more Templates
(fifteen in a preferred 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
20 also.
Transaction Request: Any request for processing a payment transaction, such as
a
credit card transaction 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 laiown 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.
CA 02537156 2006-02-27
WO 2005/022345 PCT/US2004/028002
21
Workflow: The sequence of steps involved in or necessary for the achievement
or
fiilfillment 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, W c. 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 preferred embodiment, the system 20 is the iCode, hlc. Everest
software
application that is being executed on a computer networldsystem 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 laiown 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 corrected together by a wide area network (WAN) and a
local area
networlc (LAN) as shown. As shown, the system 20 also may include a Web server
26 that
permits Web access to the system by the computer resources 24. The system 20
may fiirther
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
CA 02537156 2006-02-27
WO 2005/022345 PCT/US2004/028002
22
well known and not described herein. In a preferred 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. In a
preferred
embodiment, the mail management system is one or more pieces of software code,
executing
on a computing resource 24, that perform 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 preferred 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 informed
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 Outloolc
and integrates
with Everest. In a preferred embodiment, the E-mail Client system is one or
more pieces of
software code, executing on a computing resource 24, that perform 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 preferred embodiment, the Pay-Bridge system is one or
more pieces
of software code, executing on a computing resource 24, that perform various
functions as
ShOWl1 111 Figures 26 - 36B. The mail management process and system is
described as
follows.
Figure 2 portrays an installation procedure 100 for the mail management
pxocess in
accordance with the invention. Initially, the e-mail and mail management
clientlsoftware 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
CA 02537156 2006-02-27
WO 2005/022345 PCT/US2004/028002
23
example, through entry of various product information for the mail management
system, such
as a serial number, a registration code, a validation code and/or an
activation key. W step
102, the user logs in to the process client. In step 102a, the system
detenmines if the
registration of the user is valid and loops back to step 101 so that the user
enters different
registration information if the currently entered information 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 3A portrays a typical system flow where the system 30 imports the e-
mail
messages into a business software application, such as Everest in a preferred
embodiment. h1
steps 201 and 203, the system scans the e-mail messages (in a well laiown
mazmer such as by
1 S reviewing the headers of the e-mails) in the e-mail inbox in the specified
folder in an E-mail
Client. Fox 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
currently 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
addressllD 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 Taslc, then
the contents ofthe 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 Taslc, then
the particular Task, which may be an actual Taslc, e-mail message or other
action item, in
generated in step 207 and the contents of the e-mail and its attaclnnents are
stored in the
database in step 208 and the process is completed. W 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 Taslc browser 500 that lists the various Tasks of a
supervisor user.
CA 02537156 2006-02-27
WO 2005/022345 PCT/US2004/028002
24
In accordance with the invention, the e-mail system in accordance with the
invention
generates its omn Task, such as Task 501 shown highlighted in Figure 1 l,
based on an e-mail
of the user. W 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
Taslc (step 206), will generate a Task/e-mail linking each e-mail ID in the
TO, CC, BCC
fields with the user currently 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 Taslde-mail
even if no
match is found is checked (i.e., the system is set-up to generate a Taslc and
is configured to
1 S override 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 permits a
user of the mail
management system to specify that e-mail messages from/ a particular domain,
such as
"icode.com" or "hobnail" 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 illustrating 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 soi~ware
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
CA 02537156 2006-02-27
WO 2005/022345 PCT/US2004/028002
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 known computer resource
components
5 whose function and operation are not described as they are well lmown,
111Chrdlllg one or
more processors 212, a persistent storage device 214, such as a hard dislc
drive, optical drive,
tape drive or flash memory and a memory 216, such as DRAM, SRAM or the like,
that stores
the data and instnrctions being executed by the computer while the computer is
W ned on.
The computer system 210 may firrther include other well larown components such
as various
10 input/output devices and devices that cormect 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
15 mail management system such as a well known operating system 218, a well
lcrrown 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
20 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
25 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
CA 02537156 2006-02-27
WO 2005/022345 PCT/US2004/028002
26
display screen 250 for setting up of the e-mail server, such as by entering
profile information,
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 Taslc as shown, the
user may specify a
maximum e-mail attachment size for storage in the database and the user may
specify a
CL1St0111 field that identifies a mail management system Taslc 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. In 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 permit an
individual to specify that e-mails in a particular folder should generate a
predetermined Taslc.
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 304
pernits 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 preferred embodiment of the invention, all data can only be viewed
in thlS
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. In 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 )D 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
CA 02537156 2006-02-27
WO 2005/022345 PCT/US2004/028002
27
appropriate rights to view all e-mail / Taslcs for all users may view the e-
mail/Taslcs 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
Taslcs/appointinents for a particular user. In particular, once the mail
management system has
generated Taslcs/e-mail messages from the imported messages, the user may
search for
particular users, message subjects, creation dates) or type of Tasldmessage
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 Tasldappoin
tinent may be
searched for a customer/document or vendor/document combination. Figure 9
illustrates a
user interface 410 in which a Tasldappointinent, such as a follow up meeting,
may be
searched for by other parameters, such as a customer/document or
vendorldocument
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. In 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
attachments) 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 linlcs the Business
Partners) (the party
identified in the imported e-mail message), and any documents and e-mail
messages and
attachments.
To summarize, the mail management system (laiown 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.
CA 02537156 2006-02-27
WO 2005/022345 PCT/US2004/028002
28
The mail management system in accordance with the invention pxovides many
advantages. The system provides for importing external correspondence 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-hail
messages and related data and attachments for data mining and tracking
purposes and
e1W anced customer relationship management. The system also ensures that no
correspondence with Business Parhlers goes unrecorded/untraclced 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 Tasklappointlnent may be
searched for a
customer/document or vendorldocument combination. The system also makes a back
up of
all the messages and attacllinents that are imported.
Figure 13 is a diagram illustrating the capabilities of the e-mail system in
accordance
with the invention. T'he e-mail client is a messaging client application
(software in the
preferred embodiment) that is built within the system 20 shown above. The e-
hail 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 customers/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-hail can be set up for dial-up W tenet 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 information services, it may
be usefill 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 1115 Or her own use.
CA 02537156 2006-02-27
WO 2005/022345 PCT/US2004/028002
29
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
fOrllatS:
~ Plain Text: Using this option, a user can send e-mails that do not
include text formatting.
~ Rich Text Format: Using this option, a user can send e-mails with
formatted text, bullets, and aligmnent.
HTML: Using this option, a user can send e-mails with text formatting,
numbering, bullets, aligmnent, 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 arrival 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. In
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 boolc for any
other type of contacts can also be created and used.
The e-mail client also permits 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
CA 02537156 2006-02-27
WO 2005/022345 PCT/US2004/028002
contacts. Furtherniore, the retrieval is based on the unique identifiers or
descuptions 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 thLlS provides a mechanism to
organize and
5 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 seaxches 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
10 history of all e-mail communication is maintained, attached and indexed to
the entity
metadata and becomes retrievable from within the business software. W 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-
mail has been received. If the search is successful, the e-mail data is copied
to the database
15 and indexed to the entity corresponding 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. The attached e-mails
are available to all
users of the software who axe allowed to access data pertaining to the
entities and can be
20 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
25 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 fr0111
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
30 execution. Iii 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
CA 02537156 2006-02-27
WO 2005/022345 PCT/US2004/028002
31
accounts (either POP3 or MAPIJ are set up, respectively. In step 1106, the e-
mail client may
automatically create an address book for customers/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
customers/vendors/users or external entities. W 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 permits 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 permits 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. In
step 1116, tile e-mail client, when an e-mail is sent to/received from
customers/vendors/users
or exterial 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 lmown
maimer. fii step 1118, the e-mail client permits 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 correspondence and
company wide
correspondence made to a specific customer/vendor/user or external entity. W
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
instnictions/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
CA 02537156 2006-02-27
WO 2005/022345 PCT/US2004/028002
32
a computer system executes the e-mail client system using the hardware device.
The
computer implemented system 34 comprises various well laiown computer resource
components whose fimction and operation are not described as they are well
lazown,
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 instmctions being executed by the computer
while the
computer is fumed on. The computer system 34 may further include other well
lmown
components such as various input/output devices and devices that comiect 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 14A 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. W
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 pernlits a user to perform the typical
e-mail fimctions
associated with a typical e-mail client along with the specialized fimctions
associated with the
e-mail client system in accordance with the invention. h1 the example shown in
Figure 15, a
user of the e-mail client is reviewing a message in a preview pane. W 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 hex 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
CA 02537156 2006-02-27
WO 2005/022345 PCT/US2004/028002
33
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. W particular, the user interface permits a
user of the e
mail client to search for messages to/from a particular individual/extemal
entitylcustomer. 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/exterlal 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. W
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 corresponds to the type fteld 1402 and a CUST CODE
field 1504
that corresponds 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 known business software applications with the required
modiftcation, 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
exterial 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
CA 02537156 2006-02-27
WO 2005/022345 PCT/US2004/028002
34
outside the organization. Users can also mark messages as read or unread and
print e-mails.
There is also a method for stnicturing, 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.
S 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 feaW res. 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 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 correspondence is lost or is confined to a
single user's hzbox.
The system also automatically creates an address boob 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 sever (see step 2103), which is referred to as the
Application Server.
The installation also requires a Database Server. The Everest system
preferably is installed
on a Web Server. 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.
CA 02537156 2006-02-27
WO 2005/022345 PCT/US2004/028002
Figure 20A illustrates a process 2300 used by the HTML page generator to
create the
HTML pages. W 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
5 for which the HTML pages are being generated in accordance with the
invention. W 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 preferred embodiment of the invention, there may
be one
template for index/Category Pages or each index/Category Page and one template
for
10 item/Item Alias Pages or each item/Item Alias Page. An example of a
template 2320 fox 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
15 data from the database when the HTML page is generated by the system. Each
template
provides the overall stntcture and look and feel of each HTML page while the
achial dynamic
data in the page is provided from a database wherein the page is generated
based on the iTags.
T11115, the system generates static HTML pages (based on the dynamic data in
the database)
that may then be crawled by typical search engines (unlilce dynamic ASP pages
that cannot be
20 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 "$ItemName$" iTag, an
"$ItemPrice$" iTag,
an "$ItemCode$" iTag, an "$ItemDesc$" iTag, a "$Categories$" iTag, an
"$Image$" iTag, an
"$ShopName$" iTag and an "$emailID$" iTag. W accordance with the invention,
each of
25 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
30 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-
CA 02537156 2006-02-27
WO 2005/022345 PCT/US2004/028002
36
commerce site owner and an email address for the particular e-commerce site
that are placed
into the locations of the "$ShopName$" and "$emaillD" iTags shown in Figure
22A.
Similarly, for the template shoum in Figure 22B, the categories template 2321
has an
"$Gategories$" 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
format HTML
pages and for HTML pages that contain different dynamic information wherein an
HTML
page corresponding 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 infornation
and
other settings are retrieved from the Database Server. hi step 2304, the iTags
2322 in the
template are replaced with product informationdata 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 corresponding 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 corresponding 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 corresponding 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. In
accordance with the invention, the data and content in the ASP page and the
corresponding
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
information 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 23A- 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
CA 02537156 2006-02-27
WO 2005/022345 PCT/US2004/028002
37
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 23A 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 23C shows the HTML source code for the META tags that
permit 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
pemnit 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 permit 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 illustrating an example of a computer
implemented
HTML page generation system 2350 in accordance with the invention. In
accordance with
the invention, the HTML page generation system may also be implemented as one
or more
software modules/pieces with a plurality of instmctions 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 instntctions being executed
by the
computer while the computer is tamed on. The computer system 2350 may further
include
other well laiown components such as various inputloutput 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
information
and a Web Server 2360 that generates HTML pages as is well laiown. The
computer
CA 02537156 2006-02-27
WO 2005/022345 PCT/US2004/028002
38
implemented system 2350 further includes one or more pieces of software that
implement the
HTML page generation system such as a well lcnown 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 instiwctions
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 lcnown 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 far indexlCategory 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/itemslitem 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 indexlCategory 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/itemslitem aliases is generated.
CA 02537156 2006-02-27
WO 2005/022345 PCT/US2004/028002
39
Figure 25 illustrates a User interface 2360 that permits 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 23A, 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.
Figure 2G is a graphical flow diagram that illustrates how a credit card
paynent 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. W step 3100,
a user
creates a point-of sale (POS) transaction in the Business Software System. In
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 ICVERIF'Y can process the payment. In
step 3108, the
Transaction Request is generated in the exact format as required by ICVERIFY.
The
ICVERIFY software reads the Transaction Request ftle and then processes the
transaction
including contacting the payment network in step 3110. On receiving a
response, ICVERIFY
formats the response in the answer file in steps 3112 and 3114. hi step 311 G,
the Business
Software System reads the answer file and perforns 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
CA 02537156 2006-02-27
WO 2005/022345 PCT/US2004/028002
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
5 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
hex credit card and the Business Software System validates the credit card. In
step 3136, the
cashier goes to a credit card terniinal and manually enters the credit card
information and the
amount of the transaction. W step 3138, the credit card terniinal contacts the
payment
10 gateway or banlcing networlc. In step 3140, the credit card terminal
receives a response,
displays the response reference and prints a receipt. Iu 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
15 manual intervention lends itself to more labor as well as creates the
opportunity for clerical
mistalces such as processing for incorrect amounts and entering incorrect data
into the
Business Software System. If there is no interface, the cashier at a POS
terminal would have
to duplicate activities such as entering credit card infomnation and the
amount to be processed
into the credit card terminal and would have to re-enter the result of the
Transaction Request
20 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
25 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 format changes by the Payment Processor,
updating the
existing users of the Business Software System with the new executable files,
and updates to
30 user documentation. fil step 3150, a requirements definition for a new
Payment Processor is
received and the requirements specifications are detemnined 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
CA 02537156 2006-02-27
WO 2005/022345 PCT/US2004/028002
41
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.
W step 3164,
once testing is completed, documentation is generated in step 3164 including
user
documentation 3166. W accordance with the invention, the intermediate Credit
Card Paynent
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 intermediary 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 currently supports ICVERIFY and
PayFlowPro
Payment Processors but does not support PC Charge Payment Server. ICVER1FY
uses dial-
up connections to transmit and receive information from the payment gateway;
and it requires
that the Transaction Request firom Everest be in the format of a Transaction
Request file.
PayFlowPro connects to the payment gateway using TCP/IP as the protocol. It
transmits
information 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. Fignue 29 depicts the initial setup in the
intern~ediary
wherein the merchant account information to access PC Charge, and the folder
or port to
which the Transaction Request and response would be routed is
shovcn~/configured. W
accordance with the invention, each different Payment Processor may require a
different set-
up 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
intermediary provides
the flexibility to support Transaction Requests in different formats and can
convert
Transaction Requests to the appropriate format required by the intended
processor (in this
case, PC Charge Payment Server). In step 3170, the format of the transaction
data for the
existing Payment Processors, ICVERIFY and PayFlowPro, is defined and then
stored in a
database associated with the intermediary system in step 3172. In 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
CA 02537156 2006-02-27
WO 2005/022345 PCT/US2004/028002
42
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. W step 3180, the
maximum
number of transactions that the intermediary is allowed to process
concurrently 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. h1 addition, each Payment
Processor may
have licensing restrictions on the number of simultaneously-processed
transactions so the user
can use the maximum number of concurrent 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 fiom its database in
step 3192 wherein
each Pa~nnent Processor has a profile in the database that contains the
relevant inforniation
about that Payment Processor such as the format 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 concurrent 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 intermediary in step 3198. A method for
processing a
payment request in accordance with the invention is described in more detail
as follows.
Figure 31A is a diagram that illustrates a method 3200 by which the
intermediary in
accordance with the invention processes a payment request. In step 3202, the
internzediary
receives a notification of a payment request. When a Transaction Request is
received, the
intermediary identifies the source of the Transaction Request and the fonnat
in which the
Transaction Request has been sent. It also identifies the processor to which
the Transaction
Request should be directed. Il step 3204, tlae intermediary may assign a
session ID and
transaction ID to the Transaction Request. hi step 3206, the intermediary
determines if a
processor service is initiated. If the processor service is not initiated,
then an error is posted
in step 3208. If the processor service for the particular Payment Processor is
initiated, then
the interniediary determines if a Worker Thread is available in step 3210. hl
particular, for
the purpose of concurrently performing transactions, each Transaction Request
is processed
CA 02537156 2006-02-27
WO 2005/022345 PCT/US2004/028002
43
by a dedicated "Thread" wherein a Thread is the basic unit to which the
operating system
allocates processor time. This dedicated Thread which PayBridge allocates for
processing
requests is called a "Worker Thread". 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 Thread consumes one processor object corresponding to the
Transaction
Request. If a Worker Thread is available and the corresponding 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 corresponding 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 l, 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.
W 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 concurrently by PayBridge in the order below.
Worker 1 - Request for Processor 1001 m: 1
Worker 2 - Request for Processor 1002 ID: 2
Worker 3 - Request for Processor 1003 ID: 3
II) Request for Processor 1001 ID: 1
Request for Processor 1002 >D: 2
Request for Processor 1002 ID: 3
Request for Processor 1001 JD: 4
Request for Processor 1001 ID: 5
Request for Processor 1001 ID: 6
Returning to Figure 31A, 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 Worlcer Thread is available, then in step 3214, the intermediary
determines if a processor
CA 02537156 2006-02-27
WO 2005/022345 PCT/US2004/028002
44
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
deternzines 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 current format to the
format in which
the processor requires Transaction Requests to be transmitted in step 3218. In
step 3220, the
intennediary attempts to validate the Transaction Request and posts an error
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
intermediary
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 formats so that any
Payment
Processor may be used with a Busiiless 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. bi accordance with a preferred
embodiment of
the invention, the system may include an XML-based translator that
converts/translates
between the different fornlats of the Payment Processors. Figlues 36A and 36B
described
below provide an example of a Transaction Request and the corresponding
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 iii
more detail as
follows.
Figure 31B 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 laiown
computer
CA 02537156 2006-02-27
WO 2005/022345 PCT/US2004/028002
resource components whose function and operation are not described as they are
well known,
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 instmctions being executed by the computer while
the
computer is fumed on. The computer system 3300 may further include other well
lalown
components such as various inputloutput 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 includeslis connected to a database
3318 and
10 one or more Payment Processors 3322 - 3322" as shown. The computer-
implemented
system 3300 further includes one or more pieces of softwarelmodules that
implement the
Credit Card Payment Processing System such as a well known operating system
3308 and a
Credit Card Payment Processing System 3310 in accordance with the invention.
The Credit
Card Payment Processing System may further include one more modules including
a user
15 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
20 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
31A. ThLIS, each step shown in Figures 30 and 31A may be implemented using one
or more
computer program instnictions. In accordance with the invention, the Credit
Card Payment
Processing System may utilize one or more Payment Processor profiles based on
information
25 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" in the
completion of the credit card payment request. Examples of the user interfaces
fox 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
30 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
inteunediate payment system is being configured to operate with the PC Charge
Payment
CA 02537156 2006-02-27
WO 2005/022345 PCT/US2004/028002
46
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
Pa~nnent 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
paynent
requests for one or more different Payment Processors is being monitored. In
the event
monitor viewer 3364, each payment transaction is monitored and the current
staW s of each
transaction 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 for~:nats stipulated by each
processor or
having the necessary mechanisms for directly communicating with the processor.
In accordance with one aspect of the invention, the W termediary Payment
Processor
has the required definitions for communication protocols and Transaction
Requests from
Business Software Systems in the forniats understood by ICVERIFY and
PayFlowPro. It also
has the corresponding formats for the data format 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 PaSnnent Server.
It then
translates the response from PC Charge Payment Server to the format published
by
ICVERIE'Y or PayFlowPro as the case may be. The Business Software System fiom
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
malting 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
WlthOllt having to make changes to the data seW p in their software or having
to resort to a
manual system of processing. The system also permits the users of multiple
Business
CA 02537156 2006-02-27
WO 2005/022345 PCT/US2004/028002
47
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 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 format
published by the payment processing software. The system has a means to
translate these
Transaction Requests to formats published by the payment server and a means
for translating
the response from the payment server to the format published by the paynent
processing
software so as to enable the Business Software System from which the
Transaction Request
has originated to decipher the response and carry out fiu-ther 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 instntctions to format
the transaction
data based on the payment processing software, set up the merchant account
information for
each merchant account with the corresponding 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 concurrently and in each step,
updates the database
with the setup data. The Payment Processor may fiuther 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.
CA 02537156 2006-02-27
WO 2005/022345 PCT/US2004/028002
48
W accordance with yet another aspect of the invention, a Payment Processor is
provided that is software comprising a set of instructions. The software
formats 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
ftle 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
concurrently and in each
step, updates the database with the seW p 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 current
format 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.
In accordance with yet another aspect of the invention, a method for operating
an
hiternediary Payment Processor is provided. fii 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 forniat 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 specifted that would be used by
the
intermediary to connect to the Payment Processor. The method may preserve
these
definitions in the form 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.
CA 02537156 2006-02-27
WO 2005/022345 PCT/US2004/028002
49
Figure 34 illustrates an example of a config~mation 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 con ftguration interface 3410 is shown in
Figure 35 that
permits the user of the system to specify various payment server details that
permit 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 formats. Thus, an example of the properties of
the COM
object for the PayFlowPro Transaction Request shown in Figure 36A is shown in
Figure 3GB.
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 deftned by the appended
claims.
