Note: Descriptions are shown in the official language in which they were submitted.
CA 02306175 2000-04-07
WO 00/08583 PCT/US99/02155
NETWORK CONTACT TRACKING SYSTEM
Cross Reference To Related Applications
This application claims priority to U.S.
Provisional Application No. 60/095,652, filed August 7,
1998.
Background of the Invention
The present invention relates to interaction with
customers for Internet commerce. In particular, this
invention relates to delivery of a sequence of messages
to specific individuals in a time relative fashion.
Determination of whether a customer receives a message is
based upon a databased history of prior transactions with
that customer.
A mechanism is described which implements a
sequential or non-sequential, time-relative delivery of
human readable messages based on specific input criteria.
Different sets of criteria are maintained by the system
concurrently. Each unique set of criteria is called a
decision track. The input criteria for a decision track
is continually evaluated to yield a continuous stream of
contacts to deliver messages.
By way of background access to distributed
networks such as the Internet has increased greatly in
recent years and challenged commerce to use the Internet
advantageously. Commercial Inet sites (e. g. an Internet
or an Intranet site) have been added to networks to
permit direct marketing of goods and services in an
electronic environment. A great expenditure of time and
effort has been invested to create a myriad of resources
available to Inet browsers. As a means to benefit from
the Inet forum, it is useful to have tools to interact
with those browsing the Inet and track their contacts to
CA 02306175 2000-04-07
WO 00/08583 PCT/US99/02155
- 2 -
a particular Inet-site. Current tools available for
interacting with such Inet clients, although useful, are
primitive and limited in their capabilities and
specifically do not permit time sequenced communication
or real-time interaction which greatly facilitates
commerce on the Internet.
Purveyors of the Internet desire interactions that
further emulate a real life commercial experience.
Virtual storefront owners, corporate home pages, online
catalogue vendors, and other Inet-site owners, would find
it useful to duplicate the real life experience of
recognizing a repeat customer or visitor and remembering
details concerning that person's previous visits.
Internet interactions that can be tailored to a profile
of a visitor to a web site would thus be advantageous.
It would also be useful to implement a vehicle to
deliver a sequence of communications to a specific
individual based upon profile knowledge both previously
obtained and immediately determined during a web site
visit. Further it would be useful to transmit such
communications on a time schedule relative to an event.
In order to determine delivery of a message, information
on an individual, who may be anonymous, must be
maintained. This information may include by way of
example, where the individual can be contacted, what
interests the individual may have, what sequence of
messages has already been delivered, what format to send
a message in, when is a favored time of day to reach that
individual, and other useful information. To date, no
solution is available that can provide such information
and implement communication in a real time or event
sequenced fashion.
Prior /net database tools allow gathering of a
group of addresses and delivery of a message to the
entire group through batch mode processing. Batch mode
CA 02306175 2000-04-07
WO 00/08583 PCT/US99102155
- 3 -
processing performs a given set of functions on groups of
data referred to as batches. Typically data is collected
and stored until a scheduled processing time. At the
scheduled time, data is removed from a collection device
and transferred to a processing device in batches. The
processing device then performs a preprogrammed function
in a backroom environment. Follow up to the collected
data is thus subject to the timing of the batch
processing.
Batch mode processing only allows follow up to a
message after some period of time has elapsed. A new
list of individuals may be gathered or the same List of
individuals may be used to send another message. The
problem that remains with this contact methodology is
that it does not execute in real time, or even a time
sequence queuing from an individual contact to a web
site.
A system is needed that will deliver a message or
a sequence of messages or perform some other useful
action related to an individual's contact with a web site
as soon as that individual client has been determined to
have met predetermined criteria.
Summary of the Invention
Accordingly, an article of manufacture, a method
and a system are provided for tracking Internet and/or
Intranet contacts and automatically responding to such
contacts in a real time environment with customized
communications. The invention allows for a sequence of
personalized messages to be sent to an individual
contacting a web site on a real time basis and for
personal messages to continue to be sent on a time
schedule queuing off of a web site contact. A contact
comprises access to an electronic interface such as a web
site. A client is a person making such contact, or
CA 02306175 2000-04-07
WO 00/08583 PCTIUS99I02155
- 4 -
causing a node of a network to make such contact. When a
server, or system of servers hosting a Web site is
contacted, useful information pertaining to, for example,
a client's interests, browsing habits, purchasing
history, time of contact, lead source of a contact, and a
name and address if available, is gathered to create a
contact profile database relating to the client. Further
interactions with that client are customized in real
time, according to the profile of information gathered in
previous interactions including those interactions
immediately preceding. In this way, activities can be
directed towards a specific client in a time relative
sequence. Information is disseminated to a specific
client according to the information captured in that
client's profile.
Disseminated information takes the form of
customized communication. Communications may, for
example, be modified contents of an Inet-site, e-mail,
fax, voice mail, or U.S. mail. All communications can be
part of a time sequence triggered by events in real time.
With the use of real time customization, communications
directed towards a client are intelligently structured
according to accumulated information in the contact
profile database and the occurrence of events. The use
of a relative time line allows communications to take
place on a timetable specifically tailored to the actions
taken by a client.
A client profile is typically a database
comprising related tables of data. The database may be
updated via computer program code, or via direct input
such as by a user of the invention, or a client directly
supplying information. The database is stored in a
medium allowing the data to be queried or retrieved.
For the purposes of this disclosure an Internet
can refer to, for example, a network comprising computers
CA 02306175 2000-04-07
WO 00/08583 PCT/US99/02155
- 5 -
exceeding the boundaries of a private network. An
Intranet can refer to, for example, computers within a
private network. An Inet can refer to an Internet and/or
an Intranet adhering to an Internet protocol or similar
protocol. An Inet-site is, for example, a site available
on either an Internet or an Intranet. A network, for
example, can have a computer acting as a server and a
computer acting as a client. A contact can, for example,
be an access to an electronic interface such as a web
site, or other contents of a stored memory such as a hard
drive or dynamic random access memory of a server. A
client can be a person, a node operator, or broadly, a
machine or electronic device making such contact, or
causing a node of a network to make such a contact. Real
time is meant to be read broadly to signify on a basis
timely to or in relation to an individual event.
Other advantages and features of the present
invention will become apparent from the following
description, including the drawings and the claims.
Brief Description of the Drawing
FIG. 1 is a computer hardware diagram.
FIG. 2 is a computer network diagram.
FIG. 3 illustrates an embodiment of a decision
track data structure.
FIG. 4 illustrates the flow of a real time
response mechanism.
FIG. 5 illustrates the flow of querying a contact
profile database.
FIG. 6 illustrates the flow of continual
evaluation during decision track execution.
FIG. 7 illustrates the flow of an e-mail parsing
routine.
FIG. 8 illustrates a data structure collateral
management
CA 02306175 2000-04-07
WO 00/08583 PCTIUS99/02155
- 6 -
FIG. 9 illustrates a small office configuration
supporting this invention.
FIG. 10 illustrates a UNIXT"'-Based Database
configuration.
FIG. 11 illustrates a flow of querying database
records comprising information gathered from an Inet
interface.
FIG. 12 illustrates a screen with a circumscribed
area.
FIG. 13 illustrates multiple icons on a screen.
Description of the Preferred Embodiments
Fig. 1 depicts physical resources of a computer
system 100. The computer 100 has a central processor 101
connected to a processor host bus 102 over which it
provides data, address and control signals. The
processors 101 may be any conventional general purpose
single- or multi-chip microprocessor such as a Pentium
processor, a Pentium~ Pro processor, a Pentium II°
processor, a MIPS° processor, a Power PC° processor or an
ALPHA° processor. In addition, the processor 101 may be
any conventional special purpose microprocessor such as a
digital signal processor or a graphics processor. The
microprocessor 101 has conventional address, data, and
control lines coupling it to a processor host bus 102.
The computer 100 includes a system controller
103 having an integrated R.AM memory controller 104. The
system controller 103 is connected to the host bus 102
and provides an interface to random access memory 105.
The system controller 103 also provides host bus to
peripheral bus bridging functions. The controller 103
thereby permits signals on the processor host bus 102 to
be compatibly exchanged with signals on a primary
peripheral bus 110. The peripheral bus 110 may be, for
example, a Peripheral Component Interconnect (PCI) bus,
CA 02306175 2000-04-07
WO 00/08583 PC'T/US99/02155
an Industry Standard Architecture (ISA) bus, or a Micro-
Channel bus. Additionally, the controller 103 can
provide data buffering. and data transfer rate matching
between the host bus 102 and peripheral bus 110. The
controller 103 thereby allows, for example, a processor
101 having a 64-bit 66 MHz interface and a 533
Mbytes/second data transfer rate to interface to a PCI
bus 110 having a data path differing in data path bit
width, clock speed, or data transfer rate.
Accessory devices including, for example, a
video display controller 112 and network controller 114
can be coupled to the peripheral bus 110. The network
controller 114 may be a modem, an Ethernet networking
card, a cable modem, or other network access device. The
system 100 may also include a secondary peripheral bus
120 coupled to the primary peripheral bus 110 through a
bridge controller 111. The secondary peripheral bus 120
can be included in the system 100 to provide additional
peripheral device connection points or to connect
peripheral devices that are not compatible with the
primary peripheral bus 110. For example, in the system
100, the secondary bus 120 may be an ISA bus and the
primary bus 110 may be a PCI bus. Such a configuration
allows ISA devices to be coupled to the ISA bus 120 and
PCI devices to be coupled to the PCI bus 110. The bridge
controller 111 can also include a hard disk drive control
interface to couple a hard disk 113 to the peripheral bus
110 and a controller to other computer readable medium
150.
The computer 100 also includes non-volatile ROM
memory 122 to store basic computer software routines.
ROM 122 may include alterable memory, such as EEPROM
(Electronically Erasable Programmable Read Only Memory),
to store configuration data. For example, EEPROM memory
may be used to store hard disk 113 geometry and
CA 02306175 2000-04-07
WO 00/08583 PCT/US99102155
_ g _
configuration data. BIOS routines 123 are included in
ROM 122 and provide basic computer initialization,
systems testing, and input/output (I/O) services. For
example, BIOS routines 123 may be executed by the
processor 101 to process interrupts that occur when the
bridge 111 attempts to transfer data from the ISA bus 120
to the host bus 102 via the bridge 111, peripheral bus
110, and system controller 103. The BIOS 123 also
includes routines that allow an operating system to be
"booted" from the disk 113 or from a server computer
using a local area network connection provided by the
network adapter 114. The operating system boot operation
can occur after the computer 100 is turned on and power-
on self-test (POST) routines stored in the BIOS 123
complete execution, or when a reset switch is depressed,
or following a software-initiated system reset or a
software fault. During the boot process, the processor
101 executes BIOS 123 software to access the disk
controller 111 or network controller 114 and thereby
obtain a high-level operating system. The high-level
operating system is, for example, the Microsoft Disk
Operating System {DOS)', Windows 95TM, Windows NT~", a UNIX
operating system, the Apple Mac OS T"' operating system, or
other operating system.
An operating system may be fully loaded in the
RAM memory 105 or may include portions in RAM memory 105
disk drive storage 113, or storage at a network
location. For example, the Microsoft Windows 95TM
operating system includes some functionality that remains
in memory 105 during the use of Windows 95~" and other
functionality that is periodically loaded into RAM memory
105 on an as-needed basis from, for example, the disk
113. An operating system, such as Windows 95T"" or Windows
NT TM provides functionality to control computer
peripherals such as devices 112-114, 121, and 124, and to
CA 02306175 2000-04-07
WO 00/08583 PCTIUS99/02155
_ g _
execute user applications. User applications may be
commercially available software programs such as e2
SalesOffice~' word processing, spreadsheets, computer
aided drawing and manufacturing software, scientific
software, Internet access software and many other types
of software. User applications may access computer
system peripherals 112-114, 121, and 124 through an
application programming interface provided by the
operating system and/or may directly interact with
underlying computer system 100 hardware.
A collection of computers 100 can serve as
components of a computer network. As shown in Fig. 2, a
computer network 200 can include a host computer system
210 and client computers 231-233 or other network access
devices 234-236. The client computers 231-233 or other
network access devices 234-236 can communicate with the
host 210 to obtain data stored at the host 220 in
database 214 or collateral stored in a collateral library
215. The client computers 231-233 or other network
access devices 234-236 can interact with the host
computer 210 as if the host was a single entity in the
network 200. However, a host 211-213 may include
multiple processing and database sub-systems that can be
geographically dispersed throughout the network 200. For
example, a host 210 may include a single computer server
211 or a tightly coupled cluster 211-213 of computers 100
(Fig. 1) at a first location that access database system
214 or collateral stored in a collateral library 215 at
remote locations. Each database system 214 or collateral
stored in a collateral library 215 may include additional
processing components.
Client computers 231-233 or other network access
devices 234-236 can communicate with a host system 210
over, for example, a combination of public switched
telephone network dial-up connections and packet network
CA 02306175 2000-04-07
WO 00/08583 PCT/US99/OZ155
- 10 -
interconnections. For example, client computers 231-233
may each include a modem coupled to voiceband telephone
line 241-243. To communicate with a host 210, the client
computer 231 can establish a data connection with a local
terminal server 225 or 226 by dialing a telephone number
assigned to the local terminal server 225. Other network
access devices 232-233 can connect through dial up,
direct cable access or other communications media. A
local terminal server 225 or 226 may have both dial-up
and packet network interfaces allowing the server 225 or
226 to receive data from client computers 231 or other
network access devices 235 and 236, segment the received
data into data packet payload segments, add overhead
information to the payload segments, and send the
resultant data packets over a link 221 to a packet data
network 220 for delivery to a host system 210. Terminal
servers 225 and 226 may also be referred to as a network
service provider's point-of-presence (POP).
The overhead information added to the payload
segments include a packet header. A packet header
includes a destination address assigned to the host
system 210 and a source address assigned to the local
terminal server 225. Other overhead information may
include information associating the data packet with a
specific client 231-233. Similarly, the host system 210
may send data to a client 231-233 by segmenting the data
into data packet payload segments, and adding overhead
information to send the data packet to a client 231-234
at the terminal server 225. Client computers 234-236 may
similarly exchange data with the host 210 over
communications links 244-246 to the terminal server 226.
Data packet formats, switching equipment within
the packet network 220, and networking protocols used
within the network 200 may conform to the transaction
control protocol/internet protocol (TCP/IP). In a TCP/IP
CA 02306175 2000-04-07
WO 00/08583 PCT/US99/02155
- 11 -
implementation, the host 210, packet network 220,
terminal servers 225 and 226 are each assigned a unique
Internet protocol (IP)- network address. TCP/IP switching
equipment within the network 220 can direct a TCP/IP
packet to the intended recipient 210, 225, or 226 based
on the packet's destination IP address. implementations
may use other networking protocols and packet formats.
A vehicle such as a network interface screen 251
comprising an Inet-site, hosted on a server or a system
of servers, gathers information via a software program,
the information relating to a contact made with the
server.
On an initial contact, information is taken from
sources such as the Internet Protocol (IP) address of a
client or a login screen at the site accessed. It may
also be useful to download a cookie to identify a client
during subsequent contacts. A "Cookie" sometimes
referred to, as a "Magic Cookie" is a short piece of data
downloaded to a client's computer and then read back by
an Inet-site during subsequent interactions. Typically,
this type of identification is accomplished through use
of a small text file with information pertaining to a
client's access to the originating Inet-site. The text
file is sent to reside on the client's computer. The
text file is presented to the originating Inet-site by
the client's browser and avoids the necessity of
repeating information submitted during a previous
interaction. Most cookies reside in a computer's random
access memory and are erased when a client exits his
browser. More permanent cookies are stored on a client's
hard drive and referred to as persistent cookies.
Cookies can be used to tell a server if a client has
visited the Inet-site before.
Information relating to an Inet contact is
gathered and stored in a contact profile database 252.
CA 02306175 2000-04-07
WO 00108583 PCT/US99/02155
- 12 -
Actions taken by a client including browsing behavior are
databased along with other related information and added
to a contact profile. -Subsequently, information relating
to a client can also be added to the contact profile
database 252. Additional information may be input by a
user, input by a client via an Inet interface 251, or
merged from another data source. Inet screens customized
according to the information gathered can then be
presented to the client in real time, and other
customized forms of communications may also be
disseminated.
An unattended mechanism, such as an Inet interface
screen 251, can be used for gathering customer
information. Inputs may comprise a form to be filled in
with information by a client, audit trail information
such as page hits, file downloads or other Inet server
interactions, such as searches. Information received by
contact filled forms can be used to create or update
information about a particular client. Audit trail
information can be used to perform complex tasks such as
notifying users of new versions of a product or
performing follow up contacts to obtain additional
information. Tasks may be carried out by a user
customizable programming mechanism referred to as a
decision track.
A contact profile database 252 comprising gathered
data can be referenced by a decision track 253 mechanism.
Decision Track records 300 can include: a client ID 310,
which is a system identifier and uniquely identifies an
individual or contact within the system; a decision track
ID 311, which is a unique identifier for a sequence of
actions to be taken such as the delivery of a message; a
starting time 312, which is a time stamp of when a
contact is first placed on that decision track; the
current step 313, typically one of a plurality of steps
CA 02306175 2000-04-07
WO 00/08583 PCTIUS99I02155
- 13 -
comprising a decision track 253 such as one message in a
sequence of messages; and the last time 314 an action was
taken directed toward this particular contact.
Tables may be modified to update customer and
contact information. Table management can also include
maintaining client contact audit trails. Locally
generated contacts, such as phone, fax, e-mail and voice
mail, as well as server-generated contacts can be stored.
Individual customer records may be marked as private or
public. Private records may be maintained locally and
not synchronized with other servers. In addition private
records may remain visible only to designated users.
Changes to public records can be automatically
synchronized with other servers in a multiple server
environment.
Real time response can be accomplished by
continuous gathering of contacts and evaluation of data
relating to those contacts as well as evaluation of
events that have occurred. Actions can be taken based on
these evaluations after which the system is designed to
loop back again to contact gathering. This flow is
illustrated in FIG. 4.
The contact gathering process 410 collects
information from any of the information sources known to
the system. In particular sources comprise but are not
limited to, a contact profile table, a history table, and
any other table comprising a contact profile database. A
history table contains transactional history relating to
contacts, including but not limited to a list of web
pages contacted, a purchase history, downloading activity
and other data relating to a contact deemed to be of
value to a user of this invention.
Step evaluation 411 compares information in a
contact profile database 252 with criteria set forth by a
user. A top level query gathers a result set comprising
CA 02306175 2000-04-07
WO 00/08583 PCT/US99/02155
- 14 -
contacts meeting a specified criteria. The result set is
formed comprising a list of contact IDs that meet the
criteria necessary to be placed on a decision track. The
decision track 253 is then initialized for the aforesaid
result set with each of the records comprising the result
set placed on the first step of the initialized decision
track. (Fig. 4.}
As the decision track 253 executes, a continual
evaluation takes place to monitor the various steps 610
for all of the contact records involved in the execution.
In addition, event evaluation 412 can take place and be
tested against criteria necessary to advance to the next
step of a decision track. For example, criteria to
advance to the next step of a decision track 253 may be
the expiration of a 24-hour period. The 24-hour period
constitutes an event. Once an event has taken place, a
step evaluation result tests true 611 and contact records
waiting on that event advance to a next step of the
decision track. When all criteria have been met, an
action may be performed 612 as set forth in a step of a
decision track.
Typically, contact to an Inet-site is effectuated
via a client computer that has been lead sourced from
another Inet-site. In this case a lead source 813 may
also be added to a contact profile database. A lead
source designates the site from which a contact
originated. Tracking lead sources can be used to analyze
an ad campaign and to quantify referrals from other
sites. Information gathering techniques implemented in
this invention allow for an accurate accounting of how
many leads originating from a specified source eventually
convert to a sale or result in some other desirable
interaction. Quantifying information relating to a lead
source can be useful in determining the value of
advertising an that lead source. In addition compiled
CA 02306175 2000-04-07
WO 00/08583 PCT/ITS99I02155
- 15 -
lead source data can be used to compensate a lead source
based on an actual number of click throughs, or the
number of click throughs that convert to a sale or take
some other desired action.
Interaction with a client can be based upon
information accumulated in a contact profile database.
Interaction includes a response to a request made by a
client and also proactive communications originating from
a host site. Communications can be customized according
to pre-established criteria that a user may modify at any
time. Clients may be placed in a particular
classification and receive specific collateral
communications based upon data stored in a contact
profile database 252 such as a contact's tracked browsing
or purchasing behavior, or other useful information.
Classification criterion and a history of collateral
receipt may become part of the client profile that is
databased. Communications can be disseminated according
to classifications in the contact profile database. A
user may also make reference to the contact profile
database 252 during subsequent interactions with that
client, during user initiated communications, or at any
other time that such data may be useful.
Collateral is a communication piece. A collateral
library 215 may be stored in a database. Execution of a
decision track 253 determines if a client should be sent
a collateral piece at a given time. During execution of
a decision track 253, contacts are queried to meet
predetermined criteria 510. If predetermined criteria
are met, a corresponding action may be taken such as
initializing result set to a first step 511. For
example, a corresponding action may cause a designated
piece of collateral to be sent to a client. A specific
example of a collateral is sending a message two weeks
before a holiday, such as Mother's Day, to all customers
CA 02306175 2000-04-07
WO 00/08583 PCTIUS99/02155
- 16 -
who bought on last year's Mother's Day, and sending out
"Thank you" messages for purchases followed up by
promotional messages after a predefined period.
A collateral library 215 allows for consistency in
appearance that can create a theme throughout the
collateral pieces. This is useful in creating a
corporate identity. Collateral pieces 825 with similar
features are more likely to be associated with an
originating entity. A databased library of collateral
may act as templates to be modified according to
information in a client's profile. Collateral can be
stored in a collateral database 255 using an index of
labels 826 or binder information. Associated with the
label will be documents having equivalent content but
created in different format types. Types 824 include for
example, e-mail, HTML, RTF, text, fax, white paper,
brochure, telemarketing materials, voice mail, postal
mail, as well as other appropriate types. Due to the
nature of different collateral types 824, it is sometimes
preferable to database locations of links to collateral
pieces 825 instead of the collateral piece 825 itself.
In addition, for electronic collateral, a graphic may be
linked via a uniform resource locator (URL). External
editors such as commercial word processors and graphics
packages may be used to create and edit collateral.
Centralized collateral management provides a mechanism
for storing multiple collateral objects of different
types under a common label.
Various modes of delivering collateral require
different interfaces. Pager configuration involves
specifying a phone number to dial and a sequence to
specify the PIN number and transmit a message. Internet-
based pager services can also be supported. Fax
interface configuration involves specifying a fax device
to use and a mechanism for delivering the phone number of
CA 02306175 2000-04-07
WO 00/08583 PCTIUS99/02155
- 17 -
the target fax machine. Voice mail interface includes
specifying a voice mail device and collateral for
messages as well as telephone numbers and time of day to
place calls.
One data structure that can be used for
accomplishing centralized collateral management is
illustrated in Fig. 8. Centralized collateral management
can be accomplished by organizing the collateral into
collateral binders 820 of various labels 826 each label
826 indicating a content 823 of a collateral with an ID
822, and collateral type 824.
The client's profile in the contact profile
database 252 will determine the format type of the
collateral to be sent to the client. Each contact can
have a preferred contact type 812 stored in the contact
profile database. The contact type can be determined
from a client's browser, contact input into a form, types
of documents requested by a client or other information
gathered during client interaction. If a decision track
253 determines that an action should take place relating
to a particular contact, the contact profile database 252
is referenced to determine the preferred contact type for
that particular contact.
Collateral can also be displayed in apportioned
areas of an Inet-site screen 251. For example, the Inet
screen 251 can have one, or more geographic areas
circumscribed. Each circumscribed or apportioned area
1201 can be capable of displaying a customized content.
As information on a client is gathered, or information is
referenced from a contact profile database 252, the
contents of a circumscribed area may be designated to
contain a specific collateral piece according to that
information. In a preferred embodiment a decision track
253 is a vehicle used to designate the contents of a
circumscribed area 1201.
CA 02306175 2000-04-07
WO 00/08583 PCT/US99102155
- 18 -
Communication with a client can be directed
towards an interest demonstrated by a client by analyzing
actions taken by a client on a web site, or determined
from data stored in a client profile database, as
discussed earlier. By way of example, if a client
answers an online offer for sale, that offer for sale may
not be subsequently presented to that client. Instead
perhaps a follow up offer may be made. Similarly, if a
client shows interest in a product line, additional items
relating to the client's interest may be presented to
that client either by showing additional items on a
screen the client views, such as a custom Inet-site
screen, or sending the information to the client via e-
mail, fax, mail or other suitable medium. These paths of
interaction are termed decision tracks.
An Inet-site screen 251 is contacted by a client
via a network access device 234-236. Inet-sites may be
located for example on Internet or Intranet networks. An
example of an access device is a client computer 231-233.
Use of an access device such as a computer allows a
contact to remain anonymous. If a client is anonymous, a
client ID 310 is created based on the IP address, or a
cookie downloaded to the client's access device. During
an interaction between a client and an Inet screen, an
anonymous client may be queried for identification. Once
identified, the profile created on initial contact is
assigned to the newly identified entity, and may be
transferred to a table dedicated to known entities or
leads. If an anonymous contact is not converted to a
known entity, the profile can still be databased
according to the created ID and tracked for future
contacts. If the contact remains anonymous and dormant,
the anonymous profile may be pruned from the database
after a predetermined time lapse follows a last contact.
CA 02306175 2000-04-07
WO 00/08583 PCT/US99/02155
- 19 -
Processing work can be divided into tracks of work
that may be referred to as decision tracks. Each
decision track 253 comprises a series of at least one
condition that is to be tested by records of a database.
The structure of a decision track 253 is described below
(Table 1). The decision track 253 definition describes
the top level of a decision track. The decision track
253 step definition describes the structure of one of the
individual steps that are interconnected to form a
complete decision track.
Table 1
Fie Description
Description This is a user-friendly description of the
decision track.
Decision Track This is a unique code that is assigned to
ID each decision track. It provides a simple
mechanism to quickly identify a particular
track. A tag is usually human readable so
that users may refer to it in other
conversations to refer to a specific
message thread. The tag may be inserted
into the collateral that is sent out to
the client.
Local These are allocated when the decision
Variables track is started for a contact and used to
provide mechanisms for tracking state
between nodes across time. They can be
used to implement simple looping
constructs or sophisticated branching
algorithms.
Conditions If a condition is valued true, then the
corresponding actions are taken.
Actions Actions include setting variables, writing
records, and sending collateral to the
associated contact. Actions can also
include advancing to other states of a
decision track.
Target List This is a query that defines which
contacts are to be assigned to the
decision track. These queries can be
executed continuously to allow including
new contacts that meet the criteria
de f fined .
CA 02306175 2000-04-07
WO 00/08583 PCf/US99/02155
- 20 -
Events/Queries Events may be time of day and date timer
expiration, database queries or local
variable values. Multiple Events/Queries
may be interconnected with boolean ANDS
and ORs to form logical expressions. The
As conditions of the decision track 253 are
evaluated 610 and met with a true result 620, a
predetermined action may be taken 630 in response to a
condition met. If a condition is not met, then no action
corresponding with that condition is executed.
Appropriate action may take place on-line, such as
presenting a collateral on a web site screen during a
client's next visit, or off-line, such as mailing a
hardcopy brochure via standard mail services, or fax. In
addition, actions are sequenced so as to proceed in a
desired order, as illustrated in Table 2 below.
Table 2
Dec Trac
a
oa
Con ition 1 I Con ition is Met T en Acta.on
1
Con ition 2 I Con ition is Met T en Action 2
Con ition 3 I Con ition is Met T en Action 3
Con ition 4 I Con ition is Met T en Action 4
~on ~tion j ~ Con ition is Met T en Action 5
In one embodiment a series of records is tested
against a selected condition. As each record is tested,
if it meets the criteria of a condition, then a
corresponding action may be executed. In another
embodiment, multiple conditions are tested against a
selected record, with corresponding actions being
executed thereafter if the criteria of the conditions are
met. A user may establish and modify test conditions at
any time.
In still another embodiment decision tracks are combined
with a network tracking system. In this case, decision
tracks are designed to test conditions against data
gathered and stored in a contact profile database. For
CA 02306175 2000-04-07
WO 00/08583 PCT/US99/02155
- 21 -
example information can be gathered from an Inet
Interface screen 1110 into database records. Data
comprising a database such as the contact profile
database 252 may be updated in real time, increasing the
responsiveness of the decision track. A query of
database records 1120 can test conditions set by a user.
Predetermined actions set by a user can be performed for
those records meeting a condition 1130. With real time
interaction, the effectiveness of a particular decision
track 253 can be analyzed at any point in time, as the
feedback can be immediate.
In addition a user may modify a decision track 253
in response to data gathered in real time. Conditions
and corresponding actions comprising a decision track 253
can be created and modified by a user. For example, if a
particular subject matter present on an Inet site is
attracting a high number of contacts, a user may
immediately tailor a set of conditions to appropriately
respond to those contacts.
Responses can be accomplished in real time, or in
a time sequence relative to an event. For example a
preferred embodiment will modify an Inet site screen 251
in real time and send collateral in a sequence at
predetermined time intervals triggered by an event. For
example, twenty-four hours following a desired
transaction such as a sale can be defined as an event.
This invention can automatically send a follow up
message, and invite more interaction when that twenty
four hour event has taken place. Sequence timing can be
in response for example to a profile that indicates that
a client tends to sign on-line during particular hours of
the day. The sequence may be timed to correspond with a
client during those hours that the client is signed on-
line.
CA 02306175 2000-04-07
WO 00/08583 PCTIUS99/02155
- 22 -
Decision tracks 253 and the criteria for each step
of a decision track 253 can be created and manipulated
via a user interface 1300. A preferred interface
utilizes a graphical representation 1310 for each step of
a decision track 253 as it is created. The graphical
representation facilitates accurate processing of the
data and ease of use. Another method for creating
decisions tracks would include a written language
statement defining criteria for each decision.
Different flows can result from both internal and
external triggers to a decision track 253 system.
Decision tracks may test for different trigger events as
a condition to be met before taking an action. Trigger
events may be time-based single events, time-based
recurring events or external input and query result
events. External triggers include e-mail to accounts
monitored by a server and Inet input. Internal triggers
can include events that are generated as a result of a
scheduling database that can indicate tasks that have
transpired.
In addition an indicator may be made part of a
database to store actions taken during execution of a
decision track. Such an indicator can mark a contact
record that achieves a particular result. A decision
track 253 may then determine if it is desirable to
continue executing a decision track 253 for a marked
record.
Many methods are well known for marking database
records. One method includes creation of a "yes/no"
field that toggles between 1 and 0 to indicate a given
state. Another known method of marking is to associate
an array of variables with a given set of values. Values
may indicate if a desired result has been achieved for a
plurality of record states.
CA 02306175 2000-04-07
WO 00/08583 PCTNS99102155
- 23 -
Actions designated by a decision track 253 may
include one time calendar based mailings, mailings driven
on responses to purchases, or mailing based on elapsed
time without purchases. As activities are performed on
contacts in relation to processing decision tracks, a
client's audit trail is updated and used to maintain the
current state of individual decision tracks. The audit
trail can also be used for error recovery in the case of
system failures, thereby facilitating faultless restart.
Various processing functions used to implement
this invention are typically performed without user
intervention and can sometimes be referred to as back
office functions. A server 211-213 implements back
office logic to coordinate various client components. A
server can also implement tasks not requiring user
intervention such as e-mail routing and performance of
unattended, previously scheduled activities. It is
preferred for a server to have an instrumented interface
that can display current status information made
available by an administration module.
A front end is the primary front end seen by a
user. In a preferred embodiment, user interface is
constructed with a list of icons representing various
available modules on one side of a screen with module
specific information display on the opposite side of the
screen.
Reports for local viewing as well as formal
reporting can be supported. Reports may be saved,
printed, or forwarded via e-mail. The reports include
various detail reports and summary reports of campaign,
lead and contact information.
A console log may display the current output of
activities. All logged activities can be time stamped.
The log may be cleared or saved to disk. A log can
include entries when users log in and out, when a system
CA 02306175 2000-04-07
WO 00/08583 PCT/US99/02155
- 24 -
is started, when server-to-server synchronization is
performed and when various routing and tracking events
occur. The amount of detail included in a log is
adjustable. The age of information in a log is also
configurable.
This invention is designed to utilize a
commercially available database engine 910. Many such
database engines are commercially available and include
for instance, Oracle", Sybase~', Informix'"" and Microsoft
SQLT'" servers. Database tables used by a server of this
invention may be administratively customized to integrate
with an existing database structure. A create database
utility, available in a preferred embodiment,
automatically creates the tables required by a decision
track. In addition, although internal databases such as
a contact profile database 252 are preferred, queries may
be processed against external Structured Query Language
(SQL) databases.
Several configurations using combinations of
2 0 Windows NTT"" servers and UNIXT"" servers to support Inet
services, database servers 214 and a server 214 storing
decision tracks 253, can be detailed. The following are
presented as examples only and should not limit the scope
of this invention.
As an example, a small office configuration
illustrates a configuration supporting this invention
(Fig. 9), with Inet, Database and Decision Track Server
functions located on a single Windows NTTM system 911.
Other various front-end components, such as those
requiring customer interfaces, can run on Windows 95t"" and
Windows NT~" systems.
A Windows NTTM configuration may also use multiple
Windows NTt"" systems to support the various service
components. A different Windows NTT" system may be used
for Inet services, another system for a database server
CA 02306175 2000-04-07
WO 00108583 PCT/US99/02155
- 25 -
and still another system for a decision track server.
Various front-end components can run on Windows 95 and
Windows NTTM systems.
A UNIXTM-Based Database configuration may be
similar to a Windows NT's configuration except that the
database server may be implemented using a Solaris~" based
Oracle'" server. (Fig.lO)
Inbound e-mail to accounts monitored by a server
can be parsed 710 for both explicit requests (such as
subscribe/unsubscribe requests) and implicit requests
whose actions are determined through loose parsing of the
requests. Parsing can be used to provide automatic
response 720 generation to product information or
technical support queries.
Bounced mail messages returned from an invalid
address can be automatically processed and routed by an
e-mail parser. If a destination address is in a contact
profile database, a bounce counter can be incremented.
If a counter reaches a system-defined limit, the
corresponding contact record can be flagged as having an
invalid e-mail address and future mail messages will not
be delivered to that contact. In addition, Inet scripts
can prompt a client with an invalid e-mail address when
they next contact the site and request entry of a valid
e-mail address. E-mail addresses may be verified to the
extent possible. A primary verification method can be to
ensure that the domain name provided is reachable.
Duplicate records in a contact profile database
252 can be eliminated based on e-mail address. Also,
standard de-duplicating algorithms to locate and
eliminate or combine duplicate contact information may be
used. User interaction on questionable duplicates is
preferable.
When for example an e-mail message is received,
general conditions may be evaluated. Conditions include
CA 02306175 2000-04-07
WO 00/08583 PCT/US99/02155
- 26 -
specific words in the recipient's address, the sender's
address, the subject, the body. Conditions are then
matched against a sender's address in the contact
database. If a match is found, appropriate actions may
be taken, such as unsubscribe a user from a mail list,
add a user to a mail list, send a collateral piece to a
user, or forward a message to an account.
A preferred embodiment of this invention can also
use multiple servers concurrently within a peer group to
implement load balancing and fault tolerance. Load
balancing and fault tolerance can be achieved by many
known methods, the preferred method comprises claiming
ownership of decision tracks and allocating work base on
such ownership.
A synchronization function is also preferred to
ensure full replication across multiple servers. Each
remote server may maintain a complete copy locally of
various databases used by a decision track 253
application. Conflicts in synchronization can be
resolved by human interaction. Synchronization
operations may be configured to operate continuously or
periodically. Synchronization may be configured by
establishing partnerships between cooperating servers. A
server will attempt to synchronize its databases with
other servers in a partner list. In this way, data
synchronization may be tailored to the amount of
communications bandwidth available between any given set
of servers.
It is also preferred to implement load balancing
and fault tolerance across several servers. Methods for
load balancing and fault tolerance are well known and add
to the reliability and responsiveness of a network
system. A preferred embodiment utilizes a system of load
balancing that divides work into tracks such as decision
tracks and allows individual servers to claim ownership
CA 02306175 2000-04-07
WO 00/08583 PCT/US99/02155
- 27 -
of a particular track. After some initial work an owner
server may then allocate blocks of work to other servers
that may comprise a peer group of servers. Division and
allocation of the work can provide load balancing. A
plurality of servers comprising a peer group can provide
fault tolerance.
The methods and mechanisms described here are not
limited to any particular hardware or software
configuration, or to any particular communications
modality, but rather they may find applicability in any
communications or computer network environment. In a
preferred embodiment of this invention, a software
program on a computer readable medium is,loaded on a
server or a plurality of servers. The software program
comprises a front-end application that allows users to
access a variety of the features designed to automate
contact management on the Internet.
The techniques described here may be implemented
in hardware or software, or a combination of the two.
Preferably, the techniques are implemented in computer
programs executing one or more programmable computers
that each includes a processor, a storage medium readable
by the processor (including volatile and non-volatile
memory and/or storage elements), and suitable input and
output devices. The programmable computers may be for
example general-purpose computers or special-purpose,
embedded systems. In either case, program code is
applied to data entered with or received from an input
device to perform the functions described and to generate
output information. The output information is applied to
one or more output devices.
Each program is preferably implemented in a high
level procedural or object-oriented programming language
to communicate with a computer system. However, the
programs can be implemented in assembly or machine
CA 02306175 2000-04-07
WO 00/08583 PCTlUS99/02155
- 28 -
language, if desired. In any case, the language may be a
compiled or interpreted language.
Each such computer program is preferably stored on
a storage medium or device (e. g., CD-ROM, hard disk,
magnetic diskette, or memory chip) that is readable by a
general or special purpose programmable computer for
configuring and operating the computer when the storage
medium or device is read by the computer to perform the
procedures described. The system also may be implemented
as a computer-readable storage medium, configured with a
computer program, where the storage medium so configured
causes a computer to operate in a specific and predefined
manner.
The invention described has broad application to a
wide range of electronic interaction environments and a
number of embodiments based upon the principles disclosed
are possible. Those skilled in the art will recognize
that the method and apparatus of the present invention
has many applications, and that the present invention is
not limited to the representative examples disclosed
herein. Moreover, the scope of the present invention
covers conventionally known variations and modifications
to the system components described herein.
What is claimed is:
