CA2354089A1 - Secure data exchange - Google Patents

Abstract

The present invention provides a system whereby businesses, including professional List Providers, can register their customer or client lists, or prospect lists, with a central Secure Data Exchange, to thereby become part of the central main client/customer list. Such businesses, which are therefore List Owners, by definition, can also have access, on a selective and screened basis, to records from the central main client/customer list.
In this manner, such List Owners also become List Users. Access can also be had to the central main client/customer list by business who are not List Owners, but who are therefore, by definition, List Users.

Description

i FIELD OF THE INVENTION
The present invention relates to computer databases, and more particularly to computer databases of the customer lists, and even more particularly to a system for exchanging and storing computer databases, such as customer or client lists, including prospective customers and prospective clients, for exchange of the data in the databases by those List Owners who have contributed such lists, and for supply of the lists to List Users.
BACKGROUND OF THE INVENTION
Virtually all businesses have a client/customer list that is relied on to reach clients or customers for ongoing business purposes.
Accordingly, it is desirable to keep such client/customer lists updated and correct, which is quite difficult since the information in these databases changes quite frequently. Indeed, it is widely accepted in the business of list providers that 30~-40$ of data in such client/customer lists becomes outdated and therefore incorrect each year.
Further, many companies use client/customer lists provided by others, such as professional List Providers, as prospective client/customer lists. In the case of companies prospecting for business, or especially in the case of professional List Providers, it is imperative that the data in their lists be as accurate as possible; however, often it is not.

It is an object of the present invention to provide a Secure Data Exchange system whereby businesses, including professional List Providers, can accurately update and maintain their client/customer lists, and can expand their client/customer lists, using data provided by other businesses.
SU1~1ARY OF THE INVENTION
The present invention provides a system whereby businesses, including professional List Providers, can register their customer or client lists, or prospect lists, with a central Secure Data Exchange, to thereby become part of the central main client/customer list. Such businesses, which are therefore List Owners, by definition, can also have access, on a selective and screened basis, to records from the central main client/customer list. In this manner, such List Owners also become List Users. Access can also be had to the central main client/customer list by business who are not List Owners, but who are therefore, by definition, List Users.
Other advantages, features and characteristics of the present invention, as well as methods of operation and functions of the related elements of the structure, and the combination of parts and economies of manufacture, will become more apparent upon consideration of the following detailed description and the appended claims with reference to the accompanying drawings, the latter of which is briefly described hereinbelow.

2 BRIEF DESCRIPTION OF THE DRAWINGS
The novel features which are believed to be characteristic of the Secure Data Exchange according to the present invention, as to its structure, organization, use and method of operation, together with further objectives and advantages thereof, will be better understood from the following drawings in which a presently preferred embodiment of the invention will now be illustrated by way of example. It is expressly understood, however, that the drawings are for the purpose of illustration and description only, and are not intended as a definition of the limits of the invention. In the accompanying drawings:
Figure 1 is a chart showing the overall relationships of the various databases in the overall Secure Data Exchange system according to the present invention;
Figure 2 is a diagrammatic representation of the records submitted by the various List Owners, which records are part of the overall database entitled "actual list", which is the central main client/customer list;
Figure 3A is the first page of the flow chart indicating how a List User would select a .list from the central main client/customer list of the Secure Data Exchange;
Figure 3B is a continuation of the flow chart of Figure 3A;

3 Figure 3C is a continuation of the flow chart of Figure 3B;
Figure 3D is a continuation of the flow chart of Figure 3C;
Figure 4 is a diagrammatic representation of the operations of a List Owner can perform;
Figure 5 is a diagrammatic representation of the operations that a system administrator in the Secure Data Exchange can perform;
Figure 6 is a diagrammatic representation of the operations of a List User can perform;
Figure 7A is a flow chart of the steps that take place when a list is submitted by a List Owner;
Figure 78 is a continuation of the flow chart of Figure 7A;
Figure 8 is a diagrammatic representation of the four list permission levels;
Figure 9A is a diagrammatic representation that expands on the diagrammatic representation of Figure 7;
Figure 9B is the second page of the diagrammatic representation of Figure 8A.

4 i DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT
GENERAL EXPLANATION
Reference will now be made to Figure 1 which is a chart showing the overall relationships of the various databases in the overall Secure data Exchange system of the present invention. The "Actual List" is a compilation of all customer/client databases received from List Owners. List Owners are businesses that have existing client/customer lists (or databases) that have been provided to be included in the central main client/customer database.
If a List Owner also updates its client databases using the central main client/customer database, then it is a List User. In this manner, the numerous List Owners associative with the Secure Data Exchange are exchanging data in order to update and maintain their client/customer databases. Also, a List User may merely update its client databases using the central main client/customer database without providing its existing client/customer lists.
In the case where new records are added to the database; e-mail addresses cannot be provided as the user has not necessarily established a relationship with the List Owner and accordingly use of e-mail addresses so provided could be considered spamming.
It should be noted that there is a charge for each piece of data received by a List User, and there is a credit received by a List Owner by each piece of data gained by a List User.

5 Reference will now be made to Figure 2 which is a diagrammatic representation of the records submitted by the various List Owners, which records are part of the overall database entitled "actual list", or in other words, the central main client/customer list. The records submitted by the various List Owners are compiled together into one large customer/client database, having numerous fields, the types of which. fields will be explained in greater detail subsequently, including customer name, address, phone number, e-mail address, SIC code, and so on. The overall customer/client database has a number of records equal to the sum of the number of data records in all of the client/customer lists submitted by all of the List Owners. Duplicate data records belonging to more than one List Owner are maintained for various reasons, with the main reason being the List Owner can decide to make it necessary for a List User to request permission from a list provider to obtain information about their records. Accordingly, each List Owners records must be kept intact . In the event that a List Owner refuses to give permission to exchange data from its records to a List User, then the system can find another List Owner with a record that matches the criteria of the List User.
The customer or client databases are received from each List Owner in an electronic format, typically over a computer network such as the Internet, and are in standard format conforming Section 25 of the United States Postal Service standards.
All List Owners are not equal. Some List Owners have high quality data and will maintain high quality data while other List Owners have poor quality data and will keep having poor quality data entered into their

6 lists, such as from product reply cards and the like. It is possible to do an initial grading of the data from a new List Owner or a revised list from a List Owner in order to determine the quality of the data. This can be done on an on-going basis to provide quality check of the quality of the data provided by each List Owner, and each List Owner can be rated from this quality check.
There are also compilers of lists who sell such lists, and who routinely include false records (seed addresses) in. their lists in order to catch users of their lists who use the obtained lists improperly, such as using the list more than once. The present system will not find a match in the master database for each of these false records, and will therefore prevent questioning of the false records or in other words will identify the "seeds". Once identified as a seed, it can be used for its intended purpose, or not included. Further, the present system can include its own "seed addresses", if desired.
TYPES OF FIELDS IN "ACTUAL LIST"
4 main field typese 1) Primary fields Contains the key search indicators such as company name, contact name (business or residence), street address, city, province, zip/postal, phone, fax and email. The data will be parsed similar to the requirements for section 25 of the USPS standards.
2) Enhanced fields

7 Would contain appended information such as long/lat, SIC codes, number of employees, annual sales, credit info, ticker symbol, linkage codes - head office / branch / subsidiary, 3) Extended fields Allocation of for example up to 50 fields. A base code list of l, 000+ most likely codes to be used, for example: square footage of warehousing space, number of hospital beds etc. Up to 50 of these codes can be assigned within each list submitted by the owner. Allows addition of new codes, submitted by user to Site Administrator for approval.
4) Email field Stores the Email addresses) of the List Owner.
Reference will again be made to Figure 1, which shows that in addition to the "actual list", or in other words, the central main client/customer list, there is an "interface list". The interface list is a subset of the actual list, and has the same records, but each record only has a few fields of information, as set forth subsequently. In this manner, a List User can view the interface list and use this data to order a list and generate a price for such a list, without actually seeing the full data from the actual list, which might be restricted. The actual list is maintained on a remote server that is separated from the interface list and is accessed through a secure server tunnel, thus presenting an increased level of security. The Appendix "A" portion of the Detailed Description expands on particulars of the actual list and interface list.
Figure 1 also shows that the various other databases are maintained related to the quote actual list quote, including a "List Owners"

8 database that identifies all of the List Owners registered with the Secure Data Exchange and stores information about these List Owners; a "Price Code"
database used to track the price of each piece of data retrieved by a List User; a "Commissions" database used to calculate commissions payable to the List Owner who provided the record retrieved by a List User and commissions payable to the Secure Data Exchange; an "Activities Record" database that records all activities with the "Interface List"; a "User Permissions"
database that outlines the four permission levels related to the records of the "Actual List" that were supplied by a particular List Owner; a "Billing Details" database; a "Request List" database that logs requests found in the "Activities Record" database; a "List Users" database that identifies all of the List Users of the Secure Data Exchange; and a "Billing Records" database.
SELECTING A LIST
Reference will now be made to Figures 3A through 3D, which represent a flow chart indicating how a List User would select, or in other words create, a list from the central main client/customer list of the Secure Data Exchange. The List User interfaces with the "Interface List" and, as can be seen in Figure 3A, enters various parameters such as the type of usage, priority of selection, desired number of return records, minutes for recency and cost, and so on. Also, as can be seen in Figure 3B, the List User also specifies whether a business database will be used or a personal (home address) database will be used. The particular parameters entered make up a request profile that is stored for possible subsequent modification.
The List User's usage description and an agreement to the statement truthfulness are also entered. The request profile of the List User is submitted and the details all had intended list that is generated as for the

9 user criteria is said to the best user via e-mail. The List User is given the option of accepting that list or revising the specified parameters in the request profile and resubmitting the request profile"
As can be seen in Figure 3C, the system must determine the permission request level associated with each record that has been requested.
If permission is granted, then the List User can be provided with the permitted records. If permission is refused, the system will attempt to find other records that match the same criteria as the refused records. It is also possible that for a manual grant of permission by the List Owner, there may be a significant delay in an answer being provided. In this case, permission is considered to be refused until permission is specifically granted. A time limit can be set to contact the requesting List User to determine whether the requesting List User wishes to try to find a new record (the next occurrence of a matching record). A more thorough explanation of the "Permissions Setup" can be found in Figures 8, 9A and 9b, as referenced below.
WHAT LIST OWNERS, ADMINISTRATORS, AND LIST USERS CAN DO
The operations that a List Owner can perform are set forth in Figure 4; the operations that a system administrator in the Secure Data Exchange can perform are set forth in Figure 5; and the operations that a List Owner can perform are set forth in Figure 6.
SUBMITTING A LIST
Reference will now be made to figures 7A and 7B, which show the various steps for a list owner to submit a list to the "Secure Data Exchange"

for inclusion in the master list. The list owner first has the chance to verify the list format. Once the list owner has verified the list format, the list owner sets properties for the list, enters the setup for the list, submits a request for new field headings, if appropriate, sets the user permission, and acknowledges compliance with regulations regarding use of the system. The list owner then downloads the new or updated list, which list is transferred behind a firewall. The submitted list is compiled into the "Secure Data Exchange" format and is stored in a "stand-alone" table. It is not integrated into the master list until it has been tested against the master list for accuracy.
A verification e-mail is sent to the list owner, who subsequently responds by indicating that the format of the list is either rejected or approved. If the format is rejected, the system discards the list. The list owner has the option of re-submitting another list or an amended list. If the format is approved, the system administrator must then manually review and approve the list for inclusion in the master list. After approval, the provided list is entered into the master list . The system sends e-mails to all users in relevant interest groups that new data that are now available so that they will have an opportunity to obtain this information. An,e-mail is said to the list owner who submitted the list informing them of the date of posting of the list. If the system administrator does not approve the list for inclusion in the master list, the list owner has the option of re-submitting another list or an amended list.

PERMISSION SET UP
The overview of the "Permissions Setup" used to assign permission levels to each record of a submitted database list is shown in Figure 8, and is expanded on in Figures 9A and 9B.
APPENDIX "A"
Technical Outline: The Secure Data Exchange Data arrangement:
Apart from several tables of data needed to track user activity, user orders, list providers activities, etc., there are only 2 data sets within this system, namely Actual List and Interface List.
Actual List: The actual list contains all the actual data that the companies submit, and the users desire. This is not part of the Interface table to permit us to 'hide' the useful data behind a second secure data server. The actual list contains the information which is the actual information desired for purchase by the users. It is linked to the Interface form via the ListID value.
The fields of the data in the Actual List will include: ListID, LastName, Firstname, Street Number, Street name, Street Type, State/Prov, City, Country, etc...

To ensure the data are easily maintained, it will be Hashed into several parallel SQLServer databases. Index files will be maintained in a related database. This index database will be used to create the initial list of matched entries based on location, SIC, etc...
Interface List: This list contains all entries from all list providers. An entry is maintained in this list even if there are 3 or 4 (or more) identical entries. When a user queries the list to select the entries requested, they can establish picking criteria - entries more accurate that a specific date, or entries below a specific price, or entries from a specific list provider. Each of these criteria could cause any of the 3 or 9 entries to be the selected entry for some criteria. This table will contain the following fields:
ListID - our internal unique identifier of this entry GroupID - this ID is assigned to entries which are deemed to be non-unique (ie. 5 providers submit an address for Bill Smith - they all have the same groupID) OwnerID - the ID that ties this entry back to the provider who submitted it.
Confidence Date - the date the information was obtained or validated.
Submission Date - the date the information was entered into this system.
SIC - the classification codes used to describe this entry, for searching.

Price Code - the price code assigned to this entry by the list provider.
Contains Email - Boolean value stating if this entry contains an email address.
Contains Address - Boolean value stating if this entry contains an address.
Additional Classification Field - this field would hold searchable data which classifies this record accordingly (ie. Interested in snow boarding).
END OF APPENDIX "A"
Other variations of the above principles will be apparent to those who are knowledgeable in the field of the invention, and such variations are considered to be within the scope of the present invention.
Further, other modifications and alterations may bemused in the design and implementation of the system of the present invention without departing from the spirit and scope of the invention.

Claims