WO2003007525A2

WO2003007525A2 - Integrating electronic storage facilities

Info

Publication number: WO2003007525A2
Application number: PCT/US2002/021463
Authority: WO
Inventors: Robert Craig Murphy; Karen Diane Carter; Ceryl T. Medua; Rhadee Resma; Richard Mervin Sharp; Brian Harry Wong; Claudia Lucille Woodruff
Original assignee: Sabre Inc.
Priority date: 2001-07-10
Filing date: 2002-07-09
Publication date: 2003-01-23
Also published as: AU2002354665A1; EP1412884A2; WO2003007525A3; EP1412884A4

Abstract

A CDNA system (145) creates one central repository, a master DNA (MDNA) index (155), which enables multiple intra- and/or inter-company electronic storage facilities (110), (120), (130) to share data by assigning to each customer and storing in the master DNA (MDNA) index (155) a unique identification number, i.e., a customer DNA (CDNA) number. Each data source also assigns to each customer and stores in the corresponding electronic storage facility a unique identification number, i.e., a customer ID, for uniquely identifying the customer information stored in the electronic storage facility. Furthermore, each electronic storage facility is identified by a data storage identifier. For each electronic storage facility that stores customer information, the master DNA (MDNA) index (155) cross references the CDNA ID of the customer with a data storage identifier and a customer ID for retrieving the customer information stored in the electronic storage facility.

Description

SYSTEM AND METHOD FOR INTEGRATING ELECTRONIC STORAGE

FACILITIES

DESCRIPTION OF THE INVENTION

Field of the Invention

[001] The present invention relates to systems and methods for indexing information to facilitate the sharing of data between electronic storage facilities.

Background of the Invention

[002] In a business there may exist multiple electronic storage facilities (e.g., databases) for storing information on customers. For example, a company that provides multiple services to customers may have separate electronic storage facilities for each service provided to store customer information. As another example, a company with multiple locations may have separate electronic storage facilities at each company location.

[003] Oftentimes, the storage facilities within a company duplicate information and have no capability for sharing data. Therefore, when there is a need to update information, each storage facility must be accessed individually. Furthermore, the inability to share information limits the ability of a company to consolidate customer information and fully exploit targeted marketing opportunities.

[004] In addition, the inability of separate companies to efficiently share customer information with each other further limits their opportunities to consolidate customer information for targeted marketing opportunities. That is, separate businesses may store different information on the same customers. It would be advantageous if companies could efficiently share customer information. [005] Consolidating data from multiple storage facilities into a single storage facility would take tremendous effort and require massive disk space. Therefore, it is desirable to provide a system and method for accessing information across multiple storage facilities.

SUMMARY OF THE INVENTION

[006] In accordance with the present invention, a method for sharing customer information among a plurality of electronic storage facilities is provided. The method comprises receiving identifying information on a customer from an electronic storage facility and determining whether an identifier exists in a master data store for the customer based on the received identifying information. The method further compπses assigning an identifier based on a result of the determination and cross-referencing the assigned identifier with the received identifying information.

[007] Additional objects and advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. The objects and advantages of the invention will be realized and attained by means of the elements and combinations particularly pointed out in the appended claims.

[008] It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed.

BRIEF DESCRIPTION OF THE DRAWINGS

[009] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate one embodiment of the invention and together with the description, serve to explain the principles of the invention.

[010] Fig. 1 illustrates an environment for practicing the present invention.

[011] Fig. 2 illustrates an exemplary MDNA index. [012] Fig. 3 illustrates a method of assigning a CDNA ID.

[013] Fig. 4 illustrates a method of retrieving data source IDs and corresponding customer IDs.

[014] Fig. 5 illustrates exemplary customer information stored at an electronic storage facility.

[015] Fig. 6 illustrates a method of deleting a customer ID from the MDNA index.

[016] Fig. 7 illustrates an exemplary state of an MDNA index.

DESCRIPTION OF THE EMBODIMENTS

[017] Reference will now be made in detail to the present embodiment of the invention, an example of which is illustrated in the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts.

[018] Fig. 1 illustrates an environment 100 in which to practice the method of the present invention. The environment 100 comprises multiple electronic storage facilities 110, 120, 130 for storing customer information. The customer information may be stored by a company that maintains multiple storage facilities. In this case, data sources 115, 125, and 135 may correspond to separate business units within a company. Alternatively, data sources 115, 125, and 135 may correspond to multiple companies that desire to share information with each other. The data sources 115, 125, and 135 are connected via a communication link 140, which also connects the data sources 115, 125, 135 to a CDNA system 145. In an alternate embodiment, the data sources 115, 125, and 135 and the CDNA system 145 may be connected using communications techniques used to provide wireless transmission, for example, satellite. Furthermore, the data sources 115, 125, 135, and the CDNA system 145 may communicate via a COBRA (Common Object Request Broker Architecture) framework.

[019] The CDNA system 145 of the present invention creates one central repository, the master DNA (MDNA) index 155, which enables multiple intra- and/or inter-company electronic storage facilities 110, 120, 130 to share data by assigning to each customer and storing in the master DNA (MDNA) index 155 a unique identification number (i.e., a customer DNA (CDNA) number). Each data source also assigns to each customer and stores in the corresponding electronic storage facility a unique identification number (i.e., a customer ID) for uniquely identifying the customer information stored in the electronic storage facility. Furthermore, each electronic storage facility is identified by a data storage identifier, i.e., data storage ID.

[020] For each electronic storage facility that stores customer information, the master DNA (MDNA) index 155 cross references the CDNA ID of the customer with the data storage ID and corresponding customer ID for retrieving the customer information stored in the electronic storage facility. As mentioned above, the customer ID uniquely identifies the customer information stored in the electronic storage facility. For example, when an electronic storage facility stores customer information in a database, a primary key uniquely identifies the customer information and therefore may serve as the customer ID in the CDNA system 145. The CDNA system 145 of the present invention may also cross-reference the CDNA ID of a customer with other information (e.g., name, address, credit card number, phone number, email address, etc.) regarding the customer.

[021] Because of disk space concerns and data coordination concerns, the MDNA index 155 does not store all the information on a customer that the electronic storage facilities 110, 120, 130 may store on the customer. Instead, the MDNA index 155 stores enough information to allow for the retrieval of the desired information from the electronic storage facilities 110, 120, 130, as described below in greater detail. As stated above, the MDNA index 155 may also store other information about a customer to serve as a definitive source of common data about the customer (e.g., address, phone number, email, etc.).

[022] Fig. 2 illustrates an exemplary MDNA index 155 comprising multiple tables 210, 230, 250 consisting of multiple records 215, 235, 255, having multiple fields 220, 240, 260, respectively. A method for building a MDNA index 155 will be described in greater detail below. Each record in a table consists of information about a particular customer. For example, each record in the Cross Reference Table 210 consists of the storage location of information on a customer. For instance, information on a customer with a CDNA ID of 3 is stored in electronic storage facility 120; information on a customer with a CDNA ID of 105 is stored in electronic storage facility 110, and so on.

[023] Furthermore, each record in table 210 provides the customer ID for retrieving the customer information from the electronic storage facility where the customer information is stored. For example, table 210 illustrates that customer ID "CBK01" will retrieve information on a customer with a CDNA ID of 71 from electronic storage facility 120.

[024] Still further, there may be multiple records with the same CDNA ID. This may occur because information regarding a customer is stored in multiple electronic storage facilities. This may also occur because the customer may be identified by more than one customer ID within the same electronic storage facility. As shown in table 210, there exist two records for a customer corresponding to a CDNA ID of 3, indicating that information on the customer is stored in multiple electronic storage facilities identified by data storage identifiers 120 and 130. Furthermore, there exists two records for a customer with a CDNA ID of 71 , indicating that information on the customer is stored in a single electronic storage facility 120 under two different customer IDs, i.e., CBK01 and RYT51.

[025] When a request for information is received, the CDNA system 145 may use table 210 stored in the CDNA index 155 to determine where information on a customer is stored and returns the customer ID provided by table 210. Information on the customer may then be retrieved from the electronic storage facility storing the customer information using the customer ID. A method for retrieving information from the CDNA index 155 will be discussed in greater detail below with reference to Fig. 4. By providing a table that provides information on where customer information is stored and further providing information on how to retrieve the customer information, the CDNA system 145 is able to facilitate the sharing of data between multiple electronic storage facilities.

[026] That the CDNA system 145 facilitates the sharing of data between multiple electronic storage facilities is illustrated by the following example. If information on a particular customer (e.g., customer "A") is stored in electronic storage facility 120 and information on another customer (e.g., customer "B") is stored in data source 110, the CDNA system 145 can facilitate the sharing of this data by first generating a CDNA ID, e.g., 71 , for customer A and a CDNA ID, e.g., 235, for customer B and storing these CDNA IDs in the MDNA index 155, as shown in Fig. 2. The CDNA system 145 further stores in the MDNA index 155 the customer IDs needed to retrieve the customer information stored in the electronic storage facilities. That is, if customer ID "CBK01" retrieves information regarding customer A stored in electronic storage facility 120, then, as illustrated in Fig. 2, the MDNA index 155 cross references with customer A, having a CDNA ID of 71 , the electronic storage facility that contains information on customer A and the corresponding customer ID for retrieving information on customer A stored in the electronic storage facility. Similarly, the MDNA index 155 cross references with customer B, having a CDNA ID of 235, the electronic storage facility that contains information on customer B and the corresponding customer ID for retrieving information on customer B stored in the electronic storage facility. Based on the information stored in the MDNA index 155 of Fig. 2, it is readily determined that information on customer A, having a CDNA ID of 71 , is stored in data source 120. Similarly, it is readily determined that information on customer B, having a CDNA ID of 235, is stored in data source 110. To access the information on customer A stored in data source 120, the CDNA system 145 provides the data source identifier 120 and the customer ID CBK01. To access the information on customer B stored in data source 140, the CDNA system 145 provides the data source identifier 110 and the customer ID, "Jane Doe."

[027] Since the CDNA index 155 may further cross-reference the CDNA ID of a customer with other core information (e.g., name, address, etc.) regarding the customer, the MDNA index 155 may comprise additional tables such as a Customer Name Table 250 and a Customer Phone Table 230 as shown in Fig. 2. Other tables may also exist in the MDNA index 155. For example, a customer address table that cross-references a CDNA ID with an address may exist in the MDNA index 145. Fields of the customer address table may include a street number field, a street name field, a city name field, a state name field, and a zip code field. In addition, a customer email table or a customer credit card table may exist in the MDNA index 155. The customer email table may cross-reference a CDNA ID with an email address. The customer credit card table may cross-reference a CDNA ID with a credit card number.

[028] As discussed above, the CDNA system 145 assigns a unique identification number, a CDNA ID, to each customer referenced in the MDNA index 155. Once a CDNA ID has been assigned to a customer, that number is thereafter used to reference data associated with that customer in the MDNA index 155. Fig. 3 illustrates an exemplary method of generating a CDNA ID. The process of creating a CDNA ID begins when a data source 115, 125, 135 makes a request 302 to add a customer ID number to the MDNA index 155 by supplying its data storage ID, the customer ID, and customer data to the CDNA system 145. The data storage ID is an identifier for the requesting system. The customer data may consist of attributes such as the customer's name and address.

[029] The request to add a customer ID to the MDNA index 155 may be initiated after the data source 115, 125, 135 stores new information regarding a customer in its electronic storage facility. For example, some data sources 115, 125, 135 assign different customer IDs each time a customer completes a transaction. For instance, a company that sells products may assign a new customer ID number each time a product is sold, regardless of whether a customer purchasing the product has previously purchased a product from the company. Therefore, each time the same customer buys a product from the company, the company assigns a new customer ID number for the transaction, even though the customer is the same. Thus, a customer may have several different customer IDs corresponding to the customer stored in a company's electronic storage facility. Fig. 5 illustrates an exemplary table 500 which may be stored in an electronic storage facility. The table consists of records 510, having indexes 520. Each record corresponds to a new transaction, i.e., the sale of a product. Therefore, each time a customer purchases a product, the company stores in its electronic storage facility 110, 120, 130 a record having a transaction number, the customer's name and address, and the product sold, for example. Each time a record in created, the company requests storage of the transaction number, i.e., the customer ID, in the MDNA index 155. As illustrated in Fig. 5, the same customer may have multiple customer IDs. For example, customer "Susan Hill" has customer IDs 201 and 203. Other data sources 115, 125, 135 may provide one customer ID for the same customer and update information on the customer referencing the customer ID.

[030] At steps 305 and 310, the CDNA system 145 checks the data storage ID to determine whether the requesting system is an authorized system. If the requesting system is not an authorized system, i.e., "NO" at step 310, the CDNA system 145 denies access to the MDNA index 155. If the requesting system is an authorized system, i.e., "YES" at step 310, then the CDNA system 145 checks the customer ID to determine whether the customer ID exists in the MDNA index 155 at step 320. If the customer ID already exists in the MDNA index 155, i.e., "YES" at step 325, then the CDNA system 145 returns a message informing the requesting system that the customer ID already exists.

[031] If the customer ID does not exist in the MDNA index 155, i.e., "NO" at step 325, then the CDNA system 145 transforms and cleans the customer data to a standardized form at step 340. For example, assume a data source supplies customer data that reads: "123 Main St. Apt. 354." The CDNA system 145 may transform and clean the customer data to read: "123 Main Street 354." As another example, assume a data source supplies customer data including a phone number that reads: "1-(234)-567-8901." The CDNA system 145 may transform and clean the phone number to read: "12345678901. At step 350, the CDNA system 145 compares the standardized customer data with existing customer data in the MDNA index 155 to determine whether a CDNA ID exists for the customer. The standardizing and comparison process may be performed using Trillium.

[032] If the CDNA system 145 matches the standardized customer data with customer data already existing in the CDNA index 155, i.e., "YES" at step 355, then the CDNA ID is retrieved for that customer and cross- referenced in the MDNA index 155 with the data storage ID and customer ID provided by the requesting system at step 360. For example, the CDNA system 145 may create a record in table 210, for example, using the CDNA ID retrieved and the data storage ID and customer ID provided by the requesting system.

[033] If there is no match, i.e., "NO" at step 355, then the standardized customer data is added to the MDNA index 155 and the CDNA system 145 assigns a CDNA ID for the customer at step 365. A CDNA ID may be assigned sequentially or may be derived using an algorithm based on the customer data, for example. The CDNA ID and the customer ID are then cross referenced in the MDNA index 145 at step 370. An exemplary program specification for performing the above steps is illustrated in the appendix by an addindex() function.

[034] The MDNA index is continually updated each time a subscribing data source creates and stores a new customer ID or other information related to a customer. A subscribing data source is a data source 115, 125, 135 that has authority to add data to and retrieve data from the MDNA index 155. Each time a subscribing data source creates and stores a new customer ID or other information, the data source transmits information to the CDNA system 145 for storage in the MDNA index 155. If a CDNA ID already exists for a customer, then the CDNA systems cross-references the CDNA ID in the MDNA index 155 with the data source ID and the customer ID provided by the requesting system, i.e., step 360 in Fig. 3.

[035] A subscribing data source may also request to delete a customer ID from the MDNA index 155. As illustrated in Fig. 6, a data source initiates a delete request by transmitting its data storage ID and the customer ID to be deleted to the CDNA system 145. At steps 605 and 610, the CDNA system 145 checks the data storage ID to determine whether the requesting system is an authorized system. If the requesting system is not an authorized system, i.e., "NO" at step 610, the CDNA system 145 denies access to the MDNA index 155. If the requesting system is an authorized system, i.e., "YES" at step 610, then the CDNA system 145 checks the customer ID to determine whether the customer ID exists in the MDNA index 155 at step 620. If the customer ID does not exist in the MDNA index 155, i.e., "NO" at step 625, then the CDNA system 145 returns a message to the requesting data source that the deletion was unsuccessful at step 630. If the customer ID exists in the MDNA index 155, i.e., "YES" at step 625, then the CDNA system 145 retrieves the CDNA ID and deletes the customer ID from the MDNA index 155 at step 635.

[036] Processing proceeds to step 640, where the CDNA system 145 uses the CDNA ID, to determine whether other customer IDs are cross- referenced with the CDNA ID in the MDNA index 155. If there are no other customer IDs, i.e., "NO" at step 640, then the customer data associated with the CDNA ID is deleted from the MDNA index 155. If there exists other customer IDs, i.e., "YES" at step 640, then the other customer IDs and other customer data stored in the MDNA index 155 are retained and processing ends. An exemplary program specification for performing the above steps is illustrated in the appendix by a deleteindex() function.

[037] Using the MDNA index 155, a subscribing data source may retrieve information on customers stored in other data sources. Fig. 4 illustrates the steps performed to retrieve information on a customer from other data sources. The process starts when a requesting system transmits 402 a data storage ID and a customer ID to the CDNA system 145. At steps 405 and 410, the CDNA system 145 checks the data storage ID to determine whether the requesting system is an authorized system. If the requesting system is not an authorized system, i.e., "NO" at step 410, the CDNA system 145 denies access to the requesting system at step 415. If the requesting system is an authorized system, i.e., "YES" at step 410, the CDNA system 145 checks the customer ID to determine whether the customer ID exists in the MDNA index 155 at step 420. If the customer ID does not exists in the MDNA index 155, i.e., "NO" at step 425, then the CDNA system 45 returns an error message to the requesting system.

[038] If the customer ID exists in the MDNA index 155, i.e., "YES" at step 425, then the CDNA system 145 cross references the customer ID to determine the CDNA ID for the customer at step 435. The MDNA index 145 is then queried at step 440 to determine if other customer IDs for different data sources exist for the customer having the CDNA ID determined at step 435. If other customer IDs exist, i.e., "YES" at step 445, then the CDNA system 145 returns a list of customer IDs and corresponding data storages IDs to the requesting system at step 455. Otherwise, the CDNA system may return a response indicating that no other customer IDs exist at step 450. An exemplary program specification for performing the above steps is illustrated in the appendix by a getindex() function.

[039] As discussed above, the MDNA index 155 may cross- reference the CDNA IDs of customers with other core information (e.g., name, address, etc.) regarding the customer. A data source 115, 125, 135 may transmit information to the CDNA system 145 to request a change of this core information. For example, if a customer's address changes, a data source may transmit a request to the CDNA system 145 to update the customer's address in the MDNA index 155. The CDNA system 145 may also inform other data sources via communication link 140 of the change to a customer's core information. An exemplary program specification for performing the above steps is illustrated in the appendix by a modifycustomer() function.

[040] An additional feature of the CDNA system 145 is the periodic housekeeping of the tables in the MDNA index 155 to remove multiple CDNA IDs for a customer. A customer may have multiple CDNA IDs because the CDNA system 145 was unable to match the standardized customer data at step 355 with existing data in the MDNA index 155 due to an initial misspelling, for example, in the customer data. Because the CDNA system 145 may be unable to match the standardized customer data with existing data in the MDNA index 155, a new CDNA ID may be assigned to a customer that may already exist in the MDNA index 155.

[041] Therefore, to ensure that customers have only one CDNA ID in the MDNA index 155, the CDNA system 145 may query electronic storage facilities, retrieving information on the customers to possibly match the customers in the MDNA index 155. Fig. 7 illustrates an example of this process. Assume the MDNA index 155 comprises a customer name table 710 including a record for "John Doe" having a CDNA ID of 518 and a record for "James Doe" having a CDNA ID of 620. The MDNA index 155 further includes a cross reference table 705 comprising records that include the location of information (i.e., data storage facility 120 and 130) on "John Doe" and "James Doe" and the corresponding customer ID. Assume that "John Doe" and "James Doe" are the same customer, however, data source 120 mistakenly stored the name "James Doe" in its data storage facility 130 when it created a record for "John Doe". Therefore, the CDNA system 145 assigned a new CDNA ID for "James Doe" when the data storage facility 130 transmitted the customer data (i.e., "James Doe"), the customer ID, and its data storage identifier to the CDNA system 145. The CDNA system 145 may solve this problem by retrieving information from the data storage facilities on "John Doe" and "James Doe." Table 720 and 730 illustrates data stored in data storage facilities 120 and 130, respectively. When the CDNA system 145 retrieves the social security number (SSN) from the data storage facilities for "John Doe" and "James Doe" using the customer IDs stored in the MDNA index 155, the CDNA system 145 can determine that "John Doe" and "James Doe" are the same customer because they have the same address and same SSN. The CDNA system 145 may then assign a common CDNA ID to all records from "John Doe" and "James Doe" in the MDNA index 155.

[042] Other embodiments of the invention will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the invention being indicated by the following claims.

Claims

WHAT IS CLAIMED IS:

1. A method for sharing customer information among a plurality of electronic storage facilities comprising: receiving identifying information on a customer from an electronic storage facility; determining whether an identifier exists in a master data store for the customer based on the received identifying information; assigning an identifier based on a result of the determination; and cross-referencing the assigned identifier with the received identifying information.

2. The method according to claim 1 , further comprising: retrieving identifying information from the master data store based on an identifier.

3. The method according to claim 1 , wherein identifying information includes a storage identifier to identify an electronic storage. facility transmitting identifying information, a customer identifier for identifying customer information in the electronic storage facility; and customer data for matching a customer with existing customers in the master data store.

4. The method according to claim 3, wherein customer data includes a customer's name and address.

5. The method according to claim 1 , wherein determining comprises: standardizing the received identifying information; and comparing the standardized identifying information to existing data in the master data store.

6. The method according to claim 1 , wherein cross-referencing comprises: creating a record in a table having a first and second field wherein the first field stores the assigned identifier and the second field stores the identifying information.

7. A computer for sharing customer information among a plurality of electronic storage facilities, the computer comprising: a memory having program instructions; and a processor, responsive to the programming instructions, configured to: receive identifying information on a customer from an electronic storage facility; determine whether an identifier exists in a master data store for the customer based on the received identifying information; assign an identifier based on a result of the determination; cross-reference the assigned identifier with the received identifying information.

8. The computer of claim 7, wherein the processor is further configured to: retrieve identifying information from the master data store based on an identifier.

9. The computer of claim 7, wherein identifying information includes a storage identifier to identify an electronic storage facility transmitting identifying information, a customer identifier for identifying customer information in the electronic storage facility; and customer data for matching a customer with existing customers in the master data store.

10. The computer of claim 9, wherein customer data includes a customer's name and address.

11. The computer of claim 7, wherein determine comprises: standardize the received identifying information; and compare the standardized identifying information to existing data in the master data store.

12. The computer of claim 7, wherein cross-reference comprises: create a record in a table having a first and second field wherein the first field stores the assigned identifier and the second field stores the identifying information.

13. A system for sharing customer information among a plurality of electronic storage facilities, the system comprising: means for receiving identifying information on a customer from an electronic storage facility; means for determining whether an identifier exists in a master data store for the customer based on the received identifying information; means for assigning an identifier based on a result of the determination; means for cross-referencing the assigned identifier with the received identifying information.

14. The system of claim 13, further comprising: means for retrieving identifying information from the master data store based on an identifier.

15. The system of claim 13, wherein identifying information includes a storage identifier to identify an electronic storage facility transmitting identifying information, a customer identifier for identifying customer information in the electronic storage facility; and customer data for matching a customer with existing customers in the master data store.

16. The system of claim 15, wherein customer data includes a customer's name and address.

17. The system of claim 13, wherein means for determining comprises: means for standardizing the received identifying information; and means for comparing the standardized identifying information to existing data in the master data store.

18. The system of claim 13, wherein means for cross-referencing comprises: means for creating a record in a table having a first and second field wherein the first field stores the assigned identifier and the second field stores the identifying information. APPENDIX

ADDINDEXO

Description

Add index(es) to Customer DNA system.

Input Parameters eiaCd

CustomerDataSeq (see cdna.idl for structure)

Return Values void

Exceptions Thrown

ErrorB::CDNAException

Note: If at least one system key exists in the cross-reference table, the other index(es) may be added to the cross-reference table. The customer data may not be processed because there is no guarantee that it is more accurate or complete than the existing customer data.

Procedure

1.0 Validate EIA

2.0 For CustomerSeq. length

2.1 If customer. key already exists

2.1.1 Write to error log, continue with next customer

2.2 If customer does not have minimum fields

2.2.1 Write to error log, continue with next customer

2.3 convertOut = TB::convert(CustomerSeq[n] )

2.4 parseln = (selected fields from) convertOut

2.5 parseOut = TB::parse(parseln)

2.6 geoCountry = parseOut. country

2.7 geocodeOut = TB::geocode(parseOut, geoCountry)

2.8 matchData = (selected fields from ) geocodeOut

2.9 createWindow as follows:

2.9.1 if matchData.fqtv

2.9.1.1 fqtvs = Pfqtv::queryFqtv(matchData.fqtv)

2.9.1.2 custs = Pcust::query(fqtv[n].cdnald)

2.9.1.3 for each custs

2.9.1.3.1 windowltem[next].fields = cust[n].fields // assuming cust 'null

2.9.1.3.2 addToWindow(windowltem)

2.9.2 if matchData. email

2.9.2.1 emails = Pemail::queryEmailAddr(matchData. email)

2.9.2.2 custs = Pcust::query(email[n].cdnald)

2.9.2.2.1 windowltem[next].fields = cust[n].fields // assuming cust

2.9.2.2.2 addToWindow(windowltem)

2.9.3 Repeat as above with document, creditcard, phone

2.9.4 If matchData.candCd does not contain spaces (address available)

2.9.4.1 cands = Pcand::queryCandCd(matchData.candCd)

2.9.4.2 custs = Pcust::query(cand[n].cdnald) 2.9.4.2.1 windowltem[next].fields = cust[n].fields

2.10 matchOut = match (match Data, window)

2.11 if no match

2.11.1 pcustomer = (selected fields from) matchOut 2.11.2 cdnald = Pcustomer: :add(pcustomer)

2.12 if more than one match

2.12.1 matched = select best one (based on criteria tbd) 2.12.2 cdnald = matched. cdnald

2.13 else (only one matched) 2.13.1 cdnald = matched. cdnald

2.14 todayDate = Time::today()

2.15 PXRef::add(cdnald, clientsystemkey, todayDate) 3.0 Return

DELETEINDEXO

Description

Delete customer index(es) to Customer DNA system. If the last reference to a specific customer, then this method may invoke the deleteCustomer method.

Input Parameters eiaCd

SystemKeySeq // See cdna.idl for structure

Return Values void

Exceptions Thrown

ErrorB::CDNAException

Procedure

1.0 Validate Eia

2.0 For systmKeySeq. length

2.1 xref = Pxref::querγKey(systemKey[n])

2.2 cdnald = xref.cdnald

2.3 Pxref::delete(xref)

2.4 Xrefs = Pxref::queryKey(cdnald)

2.5 If no xrefs returned

2.5.1 Pcust.delete(cdnald) 3.0 Return successful GETINDEXO

Description

Retrieve the Indexes to a specific customer

Input Parameters eiaCd SystemKeyData

Return Values

SystemKeyDataSeq

Exceptions Thrown

ErrorB::CDNAException

Procedure

1.0 Validate Eia

2.0 xref = Pxref.queryKey(SystemKey)

3.0 xrefs = Pxref.queryKey(xref.cdnald)

4.0 systemKeyDate[n] = xrefs[n].systemKeyData

5.0 return SystemKeyData

VAL1DEIA

Description

Validates the external interfacing application (EIA) code

Input Parameters

EiaCd

Return Values bool

Exceptions Thrown

ErrorB::CDNAException

Procedure

1.0 Initialized Indicator = FALSE

2.0 eia_var = eiaFactory->query(eiaCd)

3.0 If (!PS_is_nil())

3.1 Indicator = TRUE 4.0 Return Indicator

VALIDDQCTYPEΠ

Description

Validates the documentation type before allowing a document to be added.

Input Parameters docType Return Values bool

Exceptions Thrown

ErrorB: :CDNAException Procedure

1.0 Initialized Indicator = FALSE

2.0 docType_var = docTypeFactory->query(docType)

3.0 If (!PS_is_nil())

3.1 Indicator = TRUE 4.0 Return Indicator

MODIFYCUSTOMERΠ

Description

Update customer data.

Input Parameters eiaCd

SystemKeyData

Customer

Return Values void

Exceptions Thrown

ErrorB::CDNAException

Procedure

1.0 Validate Eia

2.0 cdnald = Pxref::queryKey(systemKeyData) 3.0 If no record, throw error exception 4.0 oldCust = Pcust::query(custld)

5.0 If address or phone fields exists in customer (fields to update include address or phone fields)

5.1 Convertln = (fields from) customer

5.2 convertOut = TB::convert(convertln )

5.3 parseln = (selected fields from) convertOut

5.4 parseOut = TB::parse(parseln)

5.5 geoCountry = parseOut.country

5.6 geocodeOut = TB::geocode(parseOut, geoCountry)

5.7 cdnald =Pxref::queryKey( SystemKeyData ) // Find existing customer record

5.8 oldCust.address = geocodeOut.address

5.9 oldCust.phone = geocodeOut.phone (// do we add the phone or replace??) 6.0 Pemail::add(customer.emailAddr) // Do only if customer.emailAddr is not null , of course.. 7.0 Pother: :add(customer.other) // for creditcard, document etc. 8.0 createWindow as follows:

8.1 if match Data. fqtv

8.1.1 fqtvs = Pfqtv::queryFqtv(matchData.fqtv)

8.1.2 custs = Pcust::query(fqtv[n]. cdnald)

8.1.3 for each custs

8.1.3.1 windowltem[next].fields = cust[n].fields // assuming cust Inull

8.1.3.2 addToWindow(windowltem)

8.2 if matchData. email

8.2.1 emails = Pemail::queryEmailAddr(matchData.email)

8.2.2 custs = Pcust::query(email[n]. cdnald)

8.2.2.1 windowltem[next].fields = cust[n].fields // assuming cust

8.2.2.2 addToWindow(windowltem)

8.3 Repeat as above with document, creditcard, phone

8.4 If matchData.candCd does not contain spaces (address available)

8.4.1 cands = Pcand::queryCandCd(matchData.candCd)

8.4.2 custs = Pcust::query(cand[n]. cdnald) 8.4.2.1 windowltem[next].fields = cust[n].fields

9.0 matchOut = match(matchData, window) 10.0 if no match

10.1 pcustomer = (selected fields from) matchOut

10.2 cdnald = Pcustomer::add(pcustomer) 11.0 if more than one match

11.1 matched = select best one (based on criteria tbd)

11.2 cdnald = matched. cdnald 12.0 else (only one matched)

12.1 cdnald = matched. cdnald

13.0 todayDate = Time: :today()

14.0 PXRef::add(cdnald, clientsystemkey, todayDate)

15.0 Return successful

TCONVERTO

Description

This is a general purpose driver to encapsulate formatting and manipulating the data and files for the Trillium Converter callable module

Input Parameters customerData

Return Values convertOut

Exceptions Thrown

ErrorB::CDNAException

Procedure

This module will prepare the various buffers for the Converter. The convertOut is the output from the converter callable module.

TPARSEO

Description

This is a general purpose driver to encapsulate formatting and manipulating the data and files for the Trillium Parser callable module

Input Parameters parseln

Return Values parseOut

Exceptions Thrown

ErrorB::CDNAException

Procedure

This module will prepare the various buffers for the Parser. The parseOut is the output from the converter callable module.

TGEOCODEO

Description

This is a general purpose driver to encapsulate formatting and manipulating the data and files for the Trillium Geocoder(s) callable module

Input Parameters Data

ParseOut, country

Return Values convertOut

Exceptions Thrown

ErrorB::CDNAException

Procedure

This module will prepare the various buffers for the geocoder. The geocodeOut is the output from the geocoder callable module. There are requirements specific per country.

CUSTOMER DNA IDL

// File: cdna.idl (Customer DNA IDL)

// Description: Interface specification for the CDNA services

module CDNA

{ struct Address

{ string stAddrl ; string stAddr2; string geolinel ; // For city, state, zip, country etc string geoline2;

// Null flags boolean stAddrl NULL; boolean stAddr2NULL; boolean geolinel NULL; boolean geoline2NULL;

};

struct Document

{ string cryCode; string type; string number;

}; struct SystemKeyData

{ string client; string clientSystemKey;

}; typedef sequence <SystemKeyData> SystemKeyDataSeq;

struct CDNACustomer

{ SystemKeyData key; string name;

Address address; string fqtvNr; string phone; string creditCard; string emailAddr;

Document document;

// Null flags

// NOTE: no nameNULL - name is mandatory;

// At lease one of the following must be false (i.e. present) boolean addressNULL; boolean fqtvNrNULL; boolean phoneNULL; boolean creditCard NULL; boolean emailAddrNULL; boolean documentNuII;

}; typedef sequence <CDNACustomer> CDNACustomerSeq;

struct TCustomer // To be standardized by Trillium only { string name;

Address address;

// Null flags

// NOTE: no null flags - name and address is mandatory

}; typedef sequence <TCustomer> TCustomerSeq;

typedef sequence <string> standardizedCustSeq;

//

// Interface Begin //

exception CDNAException

{ unsigned short code; string dateTime; string name; string desc;

};

interface CDNASession; interface CDNASessionFactory;

interface CDNASessionFactory

{

CDNASession create(in string name);

};

interface CDNASession

{

// Add a cross-reference item //(with optional additional system keys) void addCDNAXref(in string eiaCd, in CDNACustomerSeq customers) raises (CDNAException);

// Deleting cross reference item void deleteCDNAXref (in string eiaCd, in SystemKeyDataSeq keys) raises (CDNAException);

// Customer data maintenance void modifyCustomerData(in string eiaCd, in CDNACustomerSeq customers) raises (CDNAException);

// Retrieve cross-reference items for a customer SystemKeyDataSeq getCDNAXref(in string eiaCd, in SystemKeyData key) raises (CDNAException);

// Convert, Parse, and Geocode customer name and address standardizedCustSeq standardize(in string eiaCd, in TCustomerSeq tCustomers) raises (CDNAException);

}; };