Note: Descriptions are shown in the official language in which they were submitted.
CA 02287158 1999-10-21
WO 98/49640 PCT/US98/06448
1
CLIENT PROFILE MANAGEMENT WITHIN A MARKETING SYSTEM
TECHNICAL FIELD
The present invention relates generally to telecommunication
S systems and, more particularly, to client profile management in a marketing
system.
BACKGROUND OF THE INVENTION
Telemarketing, direct mail and direct sales have become more
widespread in recent years. A diversity of businesses are employing marketing
to sell their goods and services. One of the goals of such marketing is to
establish new customers so as to expand the customer base of a business. These
businesses desire to target potential customers who are most likely to be
effectively solicited by marketing campaigns and contacts.
Conventional systems identify potential customers for contact by
telephone numbers or addresses. In general, batches of telephone numbers or
addresses are placed on contact lists and mass calling mailing or visiting
campaigns are performed. Unfortunately, such mass campaigns are not very
effective in that they generally have high failure rates. In addition, such
campaigns utilize a. large volume of resources.
SUMMARY OF THE INVENTION
The present invention provides a more effective approach to
marketing campaigns and contacts. The present invention focuses on a client
profile management system that is part of a larger marketing system. The
client
profile management system maintains a database of client profiles. The client
profiles may include individuals or businesses. The profiles are maintained,
not
on a per telephone or address basis, but rather on a per individual basis. As
such,
separate client profiles may be maintained for two individuals that live at
the
CA 02287158 1999-10-21
WO 98/49640 PCT/US98/06448
2
same address and share a common phone number. In addition, the client profiles
may be updated to reflect changes in a client, such as telephone number
changes,
name changes, and address changes. The client profiles may be received as
input
for the client profile database in a number of different formats. The client
profile
S management system provides mechanisms for parsing and formatting such input
into a standardized format that is acceptable to the database.
In accordance with a first aspect of the present invention, a method
is practiced in a computer system that has a database for holding client
profiles.
Each client profile holds information regarding clients for marketing
contacts. In
this method, input data that holds data about a client is received from a data
provider for possible addition to the database. Matching rules are applied to
determine whether the input data is for a selected client that already has a
client
profile in the database. The matching rules compare any name information and
any address information in the input data with any name information and any
address information in the client profile for the selected client. If it is
determined
by the matching rules that the input data is not for a selected client that
already
has a client profile in the database, a new client profile is created for the
selected
client in the database to hold data from the input data. On the other hand, if
it is
determined by the matching rules that the input data is for a selected client
that
already has a client profile in the databases, overlay rules are applied to
determine how to update the client profile in view of the input data. The
client
profile is then updated.
In accordance with another aspect of the present invention, a first
client profile for a first client at a given telephone number is stored in a
database.
The database stores client profiles for the marketing contact such that each
client
profile stores information regarding a client. A second client profile for a
second
client at the given telephone number is also stored in the database. The
database
has an index for accessing the client profiles on a per client basis. Thus,
separate
client profiles are provided for a single phone number in the database.
,.T
CA 02287158 1999-10-21
WO 98/49640 PCT/US98I46448
3
In accordance with a further aspect of the present invention, a first
address is stored in the database for a selected client in the client profile.
The
database stores client profiles for marketing contact. A second informational
or
former address for the selected client is stored in the client profile as
well. In
response to a request from a requester, one of the addresses stored in the
client
profile is provided to the requester. Hence, the database stores multiple
addresses for a single client.
In accordance with an additional aspect of the present invention, a
first set of input data is received in a first format from a first data
provider at a
computer system. The computer system holds a database that has client profiles
for holding information regarding clients for marketing contact. The first set
of
data is reformatted into a standardized format and at least some of the data
in the
first set of input data is added to a first client profile in the database. A
second
set of input data and a second format is received from a second data profile
at the
computer system. The second set of input data is reformatted into the
standardized format and at least some of the data in the second set of input
data
is added to a second client profile in the database. The computer system
includes
the ability to receive and integrate data from multiple data providers in
different
data formats.
BRIEF DESCRIPTION OF THE DRAWINGS
A preferred embodiment of the present invention will be described
below relative to the following drawings.
Figure 1 is a block diagram illustrating the strategic marketing
(SaMS) infrastructure that is suitable for practicing the preferred embodiment
of
the present invention.
Figure 2 is a block diagram of a computer system that is suitable
for practicing the preferred embodiment of the present invention.
CA 02287158 1999-10-21
WO 98149640 PCT/US98/06448
4
Figure 3 illustrates the logical organization of the CARMA
database.
Figure 4 illustrates data flow within CARMA.
Figure 5 is a flowchart illustrating the steps that are performed to
process data by CARMA.
Figure 6 is a flowchart illustrating the steps that are performed to
apply the matching rules.
Figure 7 is a diagram that illustrates the different categories of rules
that are found within the match rule table.
Figure 8 is a diagram that illustrates the different types of overlay
rules that are found in the preferred embodiment of the present invenrion.
DETAILED DESCRIPTION OF THE INVENTION
The preferred embodiment of the present invention provides a
client acquisition and retention management architecture (CARMA). CARMA is
part of a strategic marketing system (SaMS) infrastructure that provides
client
management, information management and contact services for a marketing
system. CARMA collects, tracks, and manages client information for marketing
and sales functions. CARMA is flexible enough to be used by virtually any type
of business and can track a wide range of information regarding clients.
Information regarding the clients may be obtained from virtually any source in
any format. CARMA provides processing for standardizing data formats and
performing hygiene functions on input data.
As will be described in more detail below, CARMA includes a
database of client profiles and program code for managing the client profiles.
CARMA receives input data from multiple sources and processes the input data
to create new client profile records in the database. In addition, CARMA
determines whether input data is received for a client that already has an
associated client record within the database. CARMA provides matching
CA 02287158 1999-10-21
WO 98149640 PCT/US98/06448
techniques for locating such matches and provides overlay rules for resolving
. how the existing client profile should be updated.
The client profiles are created on a per individual basis rather than
on a per telephone basis or a per address basis. Multiple clients may share a
5 common telephone number or address. Profiling information and
characteristics
is, thus, applied to individuals rather than to an entire household. CARMA
also
may maintain multiple relationships per client, including multiple addresses,
multiple account numbers, multiple membership numbers, multiple input source
(list) entries and multiple phone numbers per client. CARMA facilitates
changes
in client profiles by performing continuous ongoing tracking of clients.
Address
changes, telephone number changes, name changes, service connections and
service disconnections rnay be tracked via CARMA.
Figure 1 is a block diagram illustrating the SaMS infrastructure 10.
The SaMS infrastructure 10 includes CARMA 12 and data providers 14. The
data providers 14 provide input data to CARMA 12 that is processed for
integration into the client database maintained by CARMA. The input data may
originate from external data sources 16 that originate outside the SaMS
infrastructure 10 and internal data sources 18 that reside within the
infrastructure.
The SaMS infrastructure 10 also includes a decision support system (DSS),
which is a large-scale data warehouse that includes programs for collecting,
storing, managing, distributing, and analyzing data. Data from the data
providers
14 is also passed to DSS 20 for integration into the data warehouse. CARMA 12
interacts with DSS 20 in that updates to client profiles are passed by CARMA
12
to DSS ZO in a generalized format.
DSS 20 collects data from the data providers 14 where client
identification is not a concern. Such data may include, for example, the
number
of people who move between a given pair of states, the number of people who
purchase both a car and home stereo in the same year, or the number of women
who own a business and are members of a political party. The data collected by
CA 02287158 1999-10-21
WO 98/49640 PCT/US98/06448
6
DSS 20 varies according to business needs of users of the SaMS infrastructure
10. DSS 20 provides access to this data by business strategy units (BSU) 22. A
BSU is a company's organization that is responsible for formulating business,
marketing, and sales strategy. Each BSU performs strategic queries of data in
the
data warehouse of DSS 20 using analytical tools provided by DSS. The results
of these queries are used by the BSUs 22 to formulate marketing campaigns.
The SaMS infrastructure 10 also includes a contact infrastructure
(CONI) 24. CONI 24 is a software system that uses data extracted from the data
warehouse along with specific strategies from the business strategy units 22
to
generate leads that marketing personnel may use. These leads are deposited
within a centralized lead repository (CLR) 26. The business strategy units 22
specify criteria to CONI that CONI is to use in extracting lead data fram DSS
20.
The lead data identifies client leads (i.e., potential customers who are to be
targeted in a marketing campaign). Client leads are identified by a client
identifier that is stored in DSS 20. CONI 24 generates leads by matching these
client identifiers with a name, address and/or telephone number that are
obtained
from CARMA 12. CONI is described in more detail in copending application
entitled, "SYSTEM AND METHOD FOR AUTOMATED LEAD
GENERATION AND CLIENT CONTACT MANAGEMENT FOR A SALES
AND MARKETING PLATFORM," which was filed on even data herewith,
which is assigned to a common assignee with the present application and which
is explicitly incorporated by reference herein.
The leads that are generated by CONI 24 and stored in the CLR 26
are distributed to one or more telemarketing/direct mail centers (TM/DM
Centers) 28. These centers may include call centers from which telemarketing
agents perform client contact sales and services over the telephone. These
centers may also include direct mail campaign facilities. The agents at the
TM/DM center 28 use the leads provided via CLR 26 and store the results of
contacts made using the leads in the CLR. These results may be fed back to
both
?. . . ,,,
CA 02287158 1999-10-21
WO 98/49640 PCT/US98106448
CARMA 12 and DSS 20. When an agent at one of the TM/DM Centers 28
succeeds in signing up a new customer or making a sale, the order may be
entered in the customer order entry system 30. The customer order entry system
records the order and provisions the order. The customer order entry system 30
also updates DSS 20 to indicate the results of the order. If the order is for
long
distance service, the order is passed to a national local exchange carrier
(LEC)
interface system (NLIS) and quick PIC system 32. These systems 32 pass the
order to the client's LEC 34 so that the LEC can convert the client's PIC at
the
local class 5 switch.
The SaMS infrastructure 10 is described in more detail in
copending application entitled "SYSTEM AND METHOD FOR AUTOMATED
LEAD GENERATION AND CLIENT CONTACT MANAGEMENT FOR A
SALES AND MARKETING PLATFORM," which was filed on even date
herewith, which is assigned to a common assignee with the present application
and which is explicitly incorporated by reference herein.
CARMA 12 may be run on a number of different types of
computer systems. Figure 2 is a block diagram illustrating a computer system
40
that is suitable for running CARMA 12. A mid-range computer that employs the
DEC Alpha processor from Digital Equipment Corporation of Maynard,
Massachusetts, is suitable for running CARMA 12. Computer system 40
includes a central processing unit (CPU) 42 that is responsible for overseeing
operation of the computer system. The CPU may include a number of peripheral
devices, such as a video display 44 and an input device 46. The computer
system
40 may also include a network adapter 48 for interfacing the computer system
with a local area network. A modem 50 may be provided in the computer system
40 to facilitate communications with remote computing resources over
conventional telephone lines. The computer system 40 may include a number of
different types of storage 52, including primary storage and secondary
storage.
The storage 52 holds a client database 56 and a copy of the program code 54
for
CA 02287158 1999-10-21
WO 98/49640 PCT/US98106448
CARMA. Those skilled in the art will appreciate that the computer system 40
may be alternatively a multiprocessor system or a distributed system. The
present invention is not limited to being practiced on a single processor
system.
The client database 56 has a logical architecture like that depicted
in Figure 3. The client database 56 contains a number of different tables,
where
each table contains different information regarding a client. Each client is
assigned a unique client identifier {client id). This client identifier links
information that is kept in the different tables about the client. The linked
records for a client in aggregate, constitute the client profile for the
client. The
three primary tables in the client database 56 are the client table 60, the
address
table 82, and the domestic phone table 90. Each record in the client table 60
contains information about a client, such as client ID, social security
number,
name, and professional title. The address table 82 holds information about the
client's address, whereas the domestic phone table 90 holds information
regarding a client's phone number and phone service.
It should be appreciated that there may be a one to many
relationship between the client table 60 and the address table 82, as well as
between the client table 60 and the domestic phone table 90. A client may have
multiple addresses and multiple phone numbers associated with it. Each of the
addresses has a separate record in the client address table 80 and each of the
domestic phone numbers has a separate record in the domestic phase table 90.
The client table 60 and the address table 82 are linked by an intermediate
table:
the client address table 80. Each address of a client has a record in the
client
address table 80 that is linked to the client table 60 by "clnt id". Each
address
has a status indicator ("adr-stat") within the client address table 80. The
address
status indicator may have a value of "active," "obsolete" or "informational."
This status indicator is useful in tracking a client as a client moves among
addresses. An address identifier ("adr id") is held in the client address
table to
~......_..._...._ ......... _ . ., T . . , , r
CA 02287158 1999-10-21
WO 98/49640 PCT/US98/06448
9
link the record and the client address table to the address record in the
address
table 82.
The client phone table 76 serves as an intermediate table between
the client table 60 and the domestic phone table 90. For each phone number or
client, the client phone table 76 contains a phone number in three fields:
"npa,"
"nxx," and "line."
Suppression tables are also provided for the intermediate tables
(e.g., the client address table 80 and the client phone table 76). In
particular, the
client address supp table 84 holds suppression information regarding a client
address. Similarly, the client phone supp table 88 holds suppression
information
regarding a client phone number. The phone supp table 92 holds suppression
information regarding records stared within the domestic phone table 90.
Analogously, the address supp table 88 holds suppression information for
records
stored in the address table 82. Household enhancement information is stored
within the address enhancement table 86. Enhancement information for clients
may be stored in the client enhancement table 74.
A client account table 66 tracks internal account numbers for the
client. There may be a one to many relationship between the client table 60
and
the client account table 66. In other words, information about multiple
accounts
may be stored for a given client.
A client member table 70 tracks a client's memberships in affiliate
clubs, affinity clubs, and various other clubs. Examples include airline
frequent
flyer clubs, professional organizations, auto clubs, credit cards, travel
clubs,
health clubs, and the like. There may be relationships between records in the
client member table 70 and records in the client table 60.
The client prov detail table 72 holds detailed audit information
regarding the data provider, such as a client's phone, address, and name as
provided by each source. The client enhancement table 74 holds enhancement
information regarding clients. The client language table 78 holds information
CA 02287158 1999-10-21
WO 98/49640 PCT/US98/06448
IO
regarding the natural language that the client speaks andlor understands.
Multiple client language records may be provided for a single client. The
client
list table 62 serves as an intermediate table for linking a client as
identified by a
client identifier with a list record in the list table 61 which defines all
sources
(lists) by which a client has been received.
As was mentioned above, CARMA 12 is able to process input data
for multiple data sources and to update the data in the client database 56
accordingly. This process of handling new input data will be described below
relative to Figures 4 and 5. New input data is processed in load transactions.
Initially, the raw input data is received at CARMA 12 from the data providers
14
(step 120 in Figure 5). As was mentioned above, the data providers may be both
external and internal and may provide a variety of different types of
information.
A scheduler I00 is responsible for invoking the respective stages of
processing
performed by CARMA 12. The scheduler initiates and monitors the data load
process upon receipt of the data. The scheduler initially causes formatting
and
data hygiene to be performed on the raw input data (step 122 in Figure 5).
This
formatting and data hygiene is performed by a stage load process 102 (Figure
4).
The stage load process 102 performs standardization of names and addresses of
clients. The stage load process ensures that client identification (in the
form of a
name, social security number, or other common identifier) is valid and that
certain information, such as mailing address, is valid and in a proper format.
In the preferred embodiment of the present invention, CARMA 12
uses the PostalSoft's TrueName product 104 and the ACE product 105.
Mapping mechanism 103 determines which of the products 104 and 105 should
be uxsed on input data. PostalSoft 104 standardizes, parses, corrects,
translates,
appends, and validates name/address information in the data input from the
data
providers 14. In general, PostalSoft parses all billing names and address
information into standard name and address database attributes. ACE 305 also
performs standard billing address append functionalities, such as the
CA 02287158 1999-10-21
WO 98/49640 PCT/US98/06448
II
identification and attachment of full nine digit zip codes, carry routes,
geographic
match codes and check digits for bar-coding. Street suffix values unit
designators are also standardized by TrueName. TrueName 104 maintains a
reference list of first names and associates a gender code with each first
name
(i. e., male, female).
The preferred embodiment of the present invention also includes a
number of custom coded edits or translations 106 that embellish the PostalSoft
product 104. For example, the name information is always placed at the
beginning of the output. Invalid characters are not permitted in names and
extra
blanks are eliminated in names and addresses. Literals such as "in care oF' or
"attention of are deleted. Repeated names within first name fields and last
name
fields are deleted. Invalid names are eliminated. This may include the
elimination of profanity and repetitive characters. The name components of
input are removed if the hygiene score is below a predefined threshold value.
Stage load process 102 outputs the validated standardized data to
an interim data store 108. This enables a user to view and approve the data
using
the computer system 40 before the data is passed on to a final load process
110.
The final load process 110 performs some additional processing of the data
before data is added to the client database 56.
The final load process 110 entails applying client matching
algorithms 112. These client matching algorithms 112 are applied to determine
if
the client identification information that is provided and the data matches an
existing client in the client database (step 124 in Figure 5). Figure 6 is a
flow
chart illustrating in more detail how the client matching rules are applied.
First,
critical matching criteria is examined for records in the client database 56
and
information contained in the input data. Values that indicate the matching
condition for each of a number of different criteria are assigned (see step
134 in
Figure 6).
CA 02287158 1999-10-21
WO 98/49640 PCT/US98/06448
12
The critical matching criteria include a social security number
matching (SSN) criteria 19. The value for the social security number matching
criteria may be "Y", indicating that there is a match and that both the input
data
and the record in the client database 56 include a populated social security
field.
The value may also be "N" indicating that there is no match but that the input
data and the database record include a social security number value. The value
may lastly be "B", indicating that one or both of the input data or the
database
record do not contain a social security number value.
Last names are compared to determine a value for a last name
match (LNM) matching criteria. A value of "Y" for the LNM criteria indicates
an exact match excluding spaces and special characters, identified
misspellings,
and hyphenated last names for marned women. A value of "N" indicates no
match and that a last name is provided both in the input data and the database
record.
First names are compared in obtaining a value for a first name
match (FNM) criteria. A value of "Y" indicates an exact match including
equivalent nicknames, abbreviations, and identified misspellings. An exact
match may also be found where the first letter of the first name, including
equivalent nicknames and abbreviations, match but only if the input data or
the
database record has a first name as an initial. Lastly, an exact match can be
found if it matches to a nickname table entry. A value of "N" indicates that
there
is no match and that a first name is specified in both the input data and the
database record.
Middle names are compared to yield a value for a middle name
match (MNM) criteria. The MNM criteria may have a value of "Y", which
indicates an exact match, equivalent nicknames and equivalent abbreviations. A
value of "N" indicates that there is no match and that a middle name is
specified
in both the input data and the database record. A value of "B" indicates that
one
~.......... r , ,
CA 02287158 1999-10-21
WO 98/49640 PCT/US98/06448
13
or both of the input data in the database record are not populated with a
middle
name.
Gender is compared in the gender (GDR) matching criteria. A
value of "N" indicates that no match is found between a male, female, or
company genders in both the input data and the database record. A value of "A"
indicates that the input data or the database record is populated with an
ambiguous gender value. A value of "M" indicates that both the input data and
the database record are populated with male gender codes. A value of "F"
indicates that both the input data and the database record are populated with
female gender codes. A value of "C" indicates that both sources are populated
with company gender codes.
Titles of clients are compared to yield a value for the title (TTL)
matching criteria. A value of "Y" indicates an exact match on a courtesy title
or
match of equivalent ambiguous values. For example, the abbreviation "Mrs."
matches "Ms." A value of "N" indicates that there is no match and that both
the
input data and the database record are populated with courtesy titles. A value
of
"B" indicates that the input data or the database record or both are not
populated
with a courtesy title.
Zip codes are compared to yield the value for a zip code matching
criteria (ZIP). A value of "9" indicates an exact match of a full nine-digit
zip
code. A value of "7" indicates a match on the first seven digits of a zip
code. A
value of "5" indicates a match on the first five digits of a zip code A value
of
"N" indicates no match and that both the input data and the database record
are
populated with zip codes.
Street names and street suffixes are compared in the street names
and street suffixes (STR) matching criteria. A value of "Y" indicates an exact
match of street names and street suffixes. A value of "N" indicates no match
and
that both the input data and the database record are populated or that one of
these
CA 02287158 1999-10-21
WO 98/49640 PCT/US98/06448
14
two is not populated. A value of "B" indicates that both the input data and
the
database record are not populated with a street name or a street suffix.
An address number or P.O. Box number is compared to yield the
value for the number (NBR) matching criteria. A value of "Y" indicates an
exact
match. A value of "N" indicates no match and that both the input data and the
database record are populated by the same type of information.
Apartment numbers are compared to yield the value for the
apartment (APT) matching criteria. A value of "Y" indicates an exact match. A
value of "N" indicates that there is not a match and that both the input data
and
the database record contain an apartment number specification. A value of "B"
indicates that the input data or the database record is not populated with an
apartment number.
Phone numbers are compared to yield a value for the phone number
(PHN) matching criteria. A value of "Y" indicates an exact match of phone
numbers. A value of "N" indicates that there is not a match and that both the
input data and the database record contain phone numbers. A value of "B"
indicates that either the input data or the database record do not contain a
phone
number.
Account numbers are compared to yield the value for the account
number (ACC) matching criteria. A value of "Y" indicates an exact match where
both the input data and the database record are populated with an account
number. A value of "N" indicates that the input data and the database record
contain account numbers and that there is no match between the account
numbers. A value of "B" indicates that one or both of the input data and the
database record are not populated with an account number.
Membership numbers are compared to yield a value for the
membership number (MEM) criteria. A value of "Y" indicates an exact match
on a specific membership number. A value of "N" indicates that there is no
match and that both the input data and the database record are populated with
the
CA 02287158 1999-10-21
WO 98/49640 PCT/US98/06448
same type of membership number. A value of "B" indicates that one or both of
the input data and the database record are not populated with the membership
number.
Client id's may be compared to yield a value for the client_id
5 matching criteria. A value of "Y" indicates an exact match where both the
input
data and the database record are populated with client ids. A value of "N"
indicates that there is no match and that both the input data and the database
record are populated with client ids. A value of "B" indicates that one or
both of
the input data and the database record are not populated with a client ID.
10 It should be noted that each of these matching criteria may also
assume a value of "=' indicating that the determination of whether there is a
match or not is not dependent upon that criteria.
The values are utilized by applying match rules using a match rule
tables to determine if there is a match (step 136 in Figure 6). An example of
1 S match rule is as follows:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 scenario result-rule
- Y Y Y M B Y Y Y Y - - - - 00113 MATCH
- Y Y Y M B Y Y Y N - - - - 00114 MATCH
- Y Y Y M B Y Y Y B - - - - 00115 MATCH
- Y Y Y M B Y Y N Y - - - - 00116 MATCH
- Y Y Y M B Y Y N B - - - - 00118 MATCH
1 = SSN 2 = LNM 3 = FNM 4 = MNM 5 = GDR 6 = TTL
7=ZIP 8=STR 9=NBR 10=APT
11=PHN 12=ACC 13=MEM 14=CLN
Each row within the match rule table contains a scenario and a
result (note the columns labeled "scenario" and "result-rule"). Each row may
be
considered a separate rule. Each other column specifies a particular value for
CA' 02287158 1999-10-21
WO 98/49640 PCT/US98I06448
16
one of the 14 match criteria described above (see the Legend above). If the
criteria have the value specified in the columns, then the rule is fulfilled
and the
result of the rule is applied. For example, scenario 113 specifies that if
there is a
last name match (column 2 is "Y"), there is a first name match (column 3 is
"Y"), there is a middle name match (column 4 is "Y"), both the input data and
the database record are populated with male gender codes (column 5 is "M"),
one
or both the sources are not populated with a courtesy title (column 6 is "B"),
there is a zip code match (column 7 is "Y"), there is a street name and street
name suffix match (column 8 is "Y"), there is a number match (column 9 is "Y")
and there is an apartment match (column 10 is "Y"), it is determined that the
input data and the database record match. As a result, a determination is made
in
step 126 of Figure 5 of whether there is a match or not by applying the match
rule tables.
It should be appreciated that there are a number of different
combinations or scenarios within the match rule table that could be
categorized
into the categories set forth in Figure 7. In particular, the match rule table
contains the following combinations: name and address combinations 140, name
and phone combinations 142, name and social security number combinations
144, name and account combinations 146, name and membership number
combinations 148, name and client ID combinations 150, address and phone
combinations 152, address and account combinations 154, address and
membership number combinations 156, phone and account combinations 158,
phone and membership number combinations 160, and account and membership
number combinations I62.
If it is determined in step 126 that there is not a match between the
input data and any database records that hold client profiles, a new record
may
be created and a new client identifier is assigned to the client (step 128 in
Figure
5). The new record is filled in with the data that is provided in the input
data that
has been processed by the stage load process 102.
,,,
CA 02287158 1999-10-21
WO 98/49640 PCT/US98106448
17
In contrast, if a match is found, an overlay process is applied to
determine how to resolve the conflict between the client information contained
in
the input data and the client database record (step 130 in Figure 5). In
general, as
will be described in more detail below, the overlay process applies overlay
rules
and resolution rules to determine how to resolve the conflicts and the data is
updated accordingly within the client database 56 (step 132 in Figure 5). This
overlay process is depicted as overlays 114 in Figure 4 and results in data
that is
passed to the client database 56.
Figure 8 depicts different varieties of overlay rules 164 that are
provided by CARMA 12. There are client overlay rules 166. The general
approach of the client overlay rules is after receiving an indication that
there is a
match, the name fields in the client database 56 are only updated if the input
data
has more complete information. The client overlay rules contain specific rules
directed to fields in the client table 60. The active address overlay rules
I68
I S specify how active address information within the client database 56
should be
overlaid relative to input data that matches. The informational address
overlay
rules I70 specify how informational address information should be overlaid.
The
phone number overlay rules 172 specify how phone number information should
be overlaid. The enhancement overlay rules 174 specify how enhancements
should be overlaid. The list specific database table overlay rules specify
what
database tables are allowed to be updated for any specific load feed. Lastly,
the
client-provider detail overlay rules indicate how client provider information
in
the database 56 should be overlaid.
Once a client database 56 has been updated, the changes may be
replicated by a client database replication process 116 and may be passed on
to a
data harvesting facility for an operational data store managed by the DSS 20.
Changes are captured by a changed data capture process I18 that forwards the
changes to the data harvesting process 96 of the data warehouse of DSS 20.
CA 02287158 1999-10-21
WO 98/49640 PCTIUS98I06448
18
Therefore, CARMA 12 provides an integrated system for client
profile management that provides a number of unique features. CARMA tracks
individual clients as individuals for other than as telephone numbers or
addresses
so that multiple clients that share telephone numbers or addresses may be
tracked. CARMA 12 maintains multiple relationships, including multiple
addresses per client and multiple phone numbers per client. This facilitates
complete tracking of clients having multiple phone numbers or addresses.
CARMA 12 provides continuous ongoing tracking of clients and readily
facilitates changes to client profiles. CARMA 12 includes processing resources
for accepting and using input data of almost any type in any format. Still
further,
CARMA performs effective client matching to avoid duplicate client profiles.
While the present invention has been described with reference to a
preferred embodiment thereof, those skilled in the art will appreciate that
various
changes in form and detail may be made without departing from the intended
scope of the present invention as defined in the appended claims.
r
