Method and apparatus for a non-revealing do-not-contact list system
A method and apparatus for a non-revealing do-not-contact list system in which a do-not-contact list of one-way hashed consumer contact information is provided to a set of one or more entities. The set of entities determine whether certain consumers wish to be contacted with the do-not-contact list without discovering actual consumer contact information.
Latest Unspam, LLC Patents:
This application is a divisional of application Ser. No. 12/259,941, filed Oct. 28, 2008, which is a divisional of application Ser. No. 10/671,119, filed Sep. 24, 2003, which claims the benefit of U.S. Provisional Application No. 60/442,273 filed Jan. 23, 2003, which are each hereby incorporated by reference.
BACKGROUND OF THE INVENTION1. Field of the Invention
The invention relates to the field of communications. More specifically, the invention relates to security of communication information.
2. Prior Art
According to the Direct Marketing Association (DMA), in 2001 telemarketing accounted for $660 billion in sales. Consumer advocates estimate that more than 24 million calls are made daily by telemarketers (some households receive as many as 21 calls a week). In spite of their popularity with businesses, the telephone calls, which often interrupt people in their homes at inopportune times, are near the top of many consumers' lists of complaints.
In response to these complaints, twenty-seven state governments (Alabama, Alaska, Arkansas, California, Colorado, Connecticut, Florida, Georgia, Idaho, Illinois, Indiana, Kansas, Kentucky, Louisiana, Massachusetts, Maine, Minnesota, Missouri, New York, Oklahoma, Oregon, Pennsylvania, Tennessee, Texas, Vermont, Wisconsin, and Wyoming) have passed legislation creating so-called “do-not-call” lists. The lists, which have been extremely popular among consumers, allow citizens of a state to register their phone number as off-limits to telemarketing calls. Marketers who do not respect the lists face substantial liability. According to the DMA, being on the list can reduce the number of telemarketing calls a consumer receives by as much as 80%.
Because of their success, most of the remaining states are considering similar legislation. In addition, current Federal law requires telemarketers to maintain an internal do-not-call list for customers who ask to not receive phone calls, and the Federal Trade Commission (FTC) recently proposed creating a national do-not-call list.
In response to the need to limit liability faced by telemarketers who violate the various state- and Federally-mandated do-not-call lists, several technologies have been invented to manage the out-going calls and ensure compliance with the law. For example, U.S. Pat. No. 6,330,317, to Garfinkel, entitled “Call Blocking System,” describes a system that automatically blocks outgoing calls to consumers who appear on either a company's internal or legally-mandated external do-not-call lists. The system interacts with a company's telephone system and automatically stops calls to phone numbers in a do-not-call database before they are dialed.
In addition, U.S. Pat. No. 6,130,937, to Fotta, entitled “System and Process for Automatic Storage, Enforcement and Override of Consumer Do-Not-Call Requests,” describes a system and process for a company to manage do-not-call lists. The system described allows companies to efficiently store, update, and, when appropriate, override a do-not-call list. The list contains the telephone numbers of individuals who have expressed a desire not to be contacted. The system integrates both the company's internal do-not-call lists as well as any external lists, such as those mandated by various state laws.
The various solutions to creating and managing do-not-call lists currently go a long way toward solving the problem of unwanted telemarketing calls, but do not translate well to other communications media. The current embodiment of all do-not-call list technology inherently reveals the telephone numbers on the lists. At the present time, this is not a problem for do-not-call lists because 1) telephone numbers are already widely published in directories such as the white pages, and 2) making a telephone call is currently fairly expensive. A telemarketer must pay bandwidth fees to a telephone company, lease a telephone line, install equipment, and staff a call center in order to conduct business. In addition, inherent to the medium, only one telephone call can be made per phone line at any given time, necessarily limiting the number of phone calls that can be made by a telemarketer in any period. Joining a do-not-call list therefore does not risk subjecting a phone number to more phone calls from “rogue” telemarketers.
However, looking beyond phone calls and telemarketers, the current systems and technology for creating and managing do-not-call lists will not suffice for emerging, less-expensive, more-efficient communications media.
BRIEF SUMMARY OF THE INVENTIONA method and apparatus for a non-revealing do-not-contact list system is described. According to one aspect of the invention, a do-not-contact list of one-way hashed consumer contact information is provided to a set of one or more entities. The set of entities determine whether certain consumers wish to be contacted with the do-not-contact list without discovering actual consumer contact information.
These and other aspects of the present invention will be better described with reference to the Detailed Description and the accompanying Figures.
The invention may best be understood by referring to the following description and accompanying drawings that are used to illustrate embodiments of the invention. In the drawings:
In the following description, numerous specific details and implementations are set forth to provide a thorough understanding of the invention. However, it is understood that the invention may be practiced without the specific details of some of the implementations and embodiments. In other instances, well-known and understood circuit, structures, and techniques have not been described in detail so as not to obscure the invention.
Overview
A method and apparatus for creating, implementing, and administering non-revealing do-not-contact lists is described. These non-revealing do-not-contact lists allow the benefits of do-not-call lists to be brought to more-efficient communications media. In addition, the non-revealing do-not-contact list provides notice to entities to not send communications to entries on the non-revealing do-not-contact list without revealing the identities of the devices, their addresses, user accounts, contact numbers, etc. Communications media where such lists may be valuable include, but are not limited to, electronic mail (e-mail), instant messaging, web sites, domain systems, mobile phones, facsimile machines, etc.
Returning to
The Client Do-Not-Contact List Applications (400) in
In another embodiment of the invention, the information can be stored on a compact disc (CD), digital video disc (DVD), or other storage media and delivered via postal mail or some other physical means. The Client Do-Not-Contact List Application (400) can incorporate new information into the Client Do-Not-Contact List whether it is received via the network or some other means.
Once the latest version of the Client Do-Not-Contact List is downloaded and sorted by the Client Do-Not-Contact List Application, the Client Do-Not-Contact List Application can check any contact information stored on the client's machine against the Client Do-Not-Contact List. The entries to be checked can be stored on the client's machine in files or other forms of existing lists, or they can be entered and checked in real time. As shown in
If multiple one-way hashes were used in one embodiment of the invention, the Client Do-Not-Contact List records are sorted by the type of hash used and then each client entry is encrypted once for each hash and checked against the portion of the Client Do-Not-Contact List that was encrypted using the same hashing scheme. If there is not a match, the control flows to block 470. In an alternative embodiment of the invention, the Client DNC list is not sorted. If there is a match between the encrypted client entry and a Client Do-Not-Contact List hash then the Client Do-Not-Contact List Application looks up the unencrypted client entry using the reference key and reports that the entry appears on the Client Do-Not-Contact List (460). The Client Do-Not-Contact List Application can issue this report on the screen of the client's computer, in a file that is generated as soon as the check is done, by returning a value that the check failed to the application that called the Client Application, or by automatically purging the entry from the file or files on the client's machine. If there are additional client entries to be checked, then control flows from block 470 to 430 and the process is repeated. If there are no additional client entries to be checked, the Client Application exits (480).
While the flow diagram shows a particular order of operations performed by certain embodiments of the invention, it should be understood that such order is exemplary (e.g., alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, etc.). Some alternative embodiments of the Client Application are described in greater detail herein.
Client do-not-Contact List Application Implementations
The resulting hashed entries are compared against the Client Do-Not-Contact List (421). If a match is found, the Client Do-Not-Contact List Application returns a value indicating the newly entered information is restricted (451). In that case, in the example of a web site that registers users, the web site can then alert the attempted registrant that he or she is not allowed to register or take other appropriate action. This could be appropriate, for example, for a child attempting to register for a web site that sold adult materials. In the case of the message-monitoring client, the offending message may be quarantined and the client alerted. If there is no match, if the Client Do-Not-Contact List were created using multiple hash schemes then the client entry is hashed one time for each hash scheme (431). Each resulting hash is then compared only against the portion of the Client Do-Not-Contact List encrypted with the same scheme. The Client Do-Not-Contact List Application can return a result indicating the entry does not appear on the Client Do-Not-Contact List (441). In this case, the registration or message delivery would be allowed to continue. The version of the Client Do-Not-Contact List Application described in
New records retrieved for the Client Do-Not-Contact List, whether delivered via the network or manually through some other media, are added to any previously existing Client Do-Not-Contact List records. The records are sorted within categories by the additional or demographic information, and then sorted alphabetically by the alphanumeric value of each record's hash (497). In one embodiment of the invention, the sorting is accomplished using an industry standard sorting scheme (e.g., bubble sort, selection sort, merge sort, quick sort, etc). Alternative data organization or sorting schemes could be used to speed up matching, sorting, or additions within the Client Do-Not-Contact List. In the same way that records can be downloaded and added, entries that have been marked to be removed are downloaded at the time the Client Do-Not-Contact List Application requests an update and purged from the Client Do-Not-Contact List (487). The process of removal, according to one embodiment of the invention, is illustrated in
Additional records can be added to the Client Do-Not-Contact List locally. This may be appropriate if clients keep their own internal do-not-contact list.
Also illustrated in
Do-not-E-Mail List Implementations
In one implementation of the invention, a do-not-e-mail (DNE) list (i.e., a do-not-contact list of e-mail addresses) is created. E-mail is provided as an example, however the same techniques described herein could be used to create a do-not-contact list for other forms of communications medium (e.g., online messenger, telephone, cell phone, etc.). The e-mail implementation allows individuals to place their addresses on a DNE list, and the list to be published publicly without risk of the individuals' addresses being revealed.
Since e-mail addresses are inherently different from telephone numbers, traditional do-not-call lists which are successful because a telemarketer is limited by the expense and time required to make a phone call do not protect other contact information such as e-mail addresses. A bulk e-mailer working on a single personal computer can send literally millions of electronic messages in an hour at a significantly lesser expense than phone calls. This difference explains why the white pages can publish nearly every phone number in the country without the numbers being overwhelmed by telephone calls, but the equivalent of the white pages will never exist for e-mail addresses. If it did, those e-mail addresses could be so overwhelmed by bulk e-mail as to become unusable.
DNE lists are a way to reduce or eliminate unwanted unsolicited e-mail in that they could serve to alert online marketers which e-mail addresses are off-limits, the same way do-not-call lists alert telemarketers which phone numbers are off-limits. However, a DNE list must be secure and require a fundamentally different implementation than do-not-call lists, because publishing a DNE list in the clear, the way do-not-call lists currently are, would provide the addresses to rogue marketers, thus exposing all of the contact information for abuse.
An e-mail is sent to the address that was entered in order to verify the address belongs to the consumer who entered it and he or she in fact wants to be included on the DNE list (161). If the consumer does not respond to the verification e-mail within a specified period of time (in the example, 24 hours), the information that was entered is deleted from temporary storage (181). If the e-mail address is verified within the specified period of time, the information is passed to the one-way hash engine (191) and then deleted from temporary storage (181). The entry continues as described in
An alternative embodiment of the DNE list allows parents to indicate the e-mail addresses that belong to their children and should not be targeted by marketers.
In this embodiment of the invention, a parent's address is stored and associated with the Master Do-Not-Contact List record in order to provide verification if, in the future, there is a request to remove the child's address from the Master Do-Not-Contact list. The system can also automatically check the list of minors and remove the records of any of those who have reached the age of majority in the specified jurisdiction. After a parent's e-mail address is provided, standard checks are performed to ensure the email address is valid (143). If an address is found to have an invalid format, then control flows back to block 133 where the parent is asked to re-enter the address. Otherwise, the information entered is stored and a confirmation message is sent to the parent's address (172). If confirmation is received within a specified period of time then the information is retrieved from storage and sent to the One-Way Hash Engine (192) and down the chain of control specified in
Continuing with the DNE list example, the Client Do-Not-Contact List Application can be kept on the computers or other devices of e-mail marketers. The marketers can use the Client Do-Not-Contact List Application to periodically check their bulk e-mail lists to ensure addresses they send e-mail to have not requested to be kept free of so called “spam.” Additionally, web sites selling adult products can use the Client Do-Not-Contact List Application to check to see if an e-mail address belongs to a minor before granting access to their sites. Or, in an alternative embodiment, the Client Application may integrate with a client's mail server and check messages as they are sent by the client. If the address of one of the outgoing messages appears on the Client Do-Not-Contact List then the Client Application can stop the message from being sent and issue a report to the client. DNC lists may also be used to keep others from making on-line purchases (of any type), avoid selling to people with bad credit, etc. by checking before granting access to a site and before soliciting.
In an additional embodiment, an entire category of consumers may be placed in a do-not-contact list. For example, a category such as youth, elderly, age group, nationality, gender, ethnicity, area, city, town, state, county, country, area code, zip code, email address, email provider, internet service provider, school email address provider, library email address provider, government sector email address, etc. Thus, the entries in the do-not-contact list (e.g., the master do-not-contact list or the client do-not-contact list) may be sorted according to category or demographic information as previously discussed. An entry belonging to the category listed in the do-not-contact list would be indicated as an entry of a consumer that should not be contacted. In addition, the entry may be an entry of information of a particular group or category of consumers (as opposed to a particular consumer) and a match of this particular category of consumers against the do-not-contact list would indicate that the entire group or all consumers sharing the particular characteristic or demographic information of the group belongs to the do-not-contact list. Thus, when an entry, either of a particular consumer or of a particular category, that matches a category in the do-not-contact list, that entry belongs to a particular consumer or a particular category of consumer that do not wish to be contacted. Appropriate actions such as reporting, removal, or purging of the entry may be followed as previously described.
ADDITIONAL EMBODIMENTSWhile the invention has been described in terms of several embodiments, those skilled in the art will recognize that the invention is not limited to the embodiments described. The method and apparatus of the invention can be practiced with modification and alteration with the spirit and scope of the appended claims. The descriptions provided are thus to be regarded as illustrative instead of limiting on the invention.
Claims
1. A computer implemented method comprising:
- collecting, by a data collection system, a plurality of contact information of a a plurality of consumers that do not wish to be contacted via the plurality of contact information respectively;
- encrypting, by a one-way hash engine, the plurality of contact information of the collected by the data collection system to generate a plurality of encrypted values of the plurality of contact information to conceal the plurality of contact information;
- storing, by a master do-not-contact list server, the plurality of encrypted values of the plurality of contact information in a master do-not-contact list;
- comparing an encrypted value from a client do-not-contact list application of a client machine against the plurality of encrypted values of the master do-not-contact list;
- determining that the encrypted value from the client do-not-contact list application matches one of the plurality of encrypted values on the master do-not-contact list; and
- responsive to the determination that the encrypted value from the client do-not-contact list application matches one of the plurality of encrypted values on the master do-not-contact list, determining that the consumer corresponding to the encrypted value from the client do-not-contact list application should not be contacted via the contact information of the consumer.
2. The method as in claim 1 further comprising:
- further responsive to the determination that the encrypted value from the client do-not-contact list application matches one of the plurality of encrypted values on the master do-not-contact list, causing the contact information of the consumer corresponding to that encrypted value to be at least one of automatically purged from a contact list, purged from a client's machine, blocked from entering a contact list, and reported that the contact information of the consumer is on the master do-not-contact list.
3. The method as in claim 1 wherein each of the plurality of contact information of the plurality of consumers includes at least one of an email address, a user identifier, a domain name, an instant message identifier, a telephone number, and an information that identifies an individual communication device or account.
4. The method as in claim 1 wherein each of the plurality of contact information of the plurality of consumers includes demographic information or a category of a set of entries fitting a particular characteristic.
5. A non-revealing do-not-contact system comprising:
- a client machine communicable with a master do-not-contact list server;
- a do-not-contact list client application of the client machine configured to receive a set of one or more unique hashed values from the master do-not-contact list server that have been generated by a hashing of a respective one of a set of one or more contact information of one or more consumers collected by a data collection system and transferred to the master do-not-contact list server, and wherein each one of the set of unique hashed values are hashed in a manner such that the respective contact information is concealed, and wherein the one or more consumers do not wish to be contacted via the one or more contact information respectively;
- wherein the client machine includes a storage to store a client do-not contact list, wherein the client do-not contact list is to include the set of unique hashed values received from the master do-not-contact list server;
- wherein the do-not-contact list application of the client machine is further configured to:
- hash a client contact information to generate a client hash value;
- compare the client hash value with the set of unique hashed values of the client do-not-contact list to determine whether the client hash value is included on the client do-not-contact list; and
- determine to not make contact via the client contact information upon a determination that the client hash value is included on the client do-not-contact list.
6. The system as in claim 4, further comprising:
- a master do-not-contact list database communicable with the master do-not-contact list server to store the unique hashed values for the master do-not-contact list server.
7. The system as in claim 5 wherein each respective one of the set of unique hash values is further associated with consumer demographic information and wherein the hashed client entry associates with consumer demographic information.
8. The system as in claim 5 wherein the do-not-contact list client application is deployed on multiple remote computers of at least one of individuals, businesses, and clients, that send unsolicited communications or store or use the contact information of the one or more consumers.
9. A method comprising:
- causing, by a do-not-contact list client application of a client machine, a contact information of a first consumer to be hashed by a first one-way hash engine to convert the contact information of the first consumer into a hashed client contact entry;
- causing, by the do-not-contact list client application of the client machine, the hashed client contact entry to be compared against a client do-not-contact list, wherein the client do-not-contact list is created at least partially by using a set of one or more hashed values retrieved through a master do-not-contact list server that were collected by a data collection system and hashed by a second one-way hash engine communicable with the data collection system and transferred to the master do-not-contact list server, the set of hashed values representing a set of one or more contact information of consumers who do not wish to be contacted, and wherein the set of hashed values are hashed in a manner that conceals the set of contact information respectively;
- determining, by the do-not-contact list client application of the client machine, that the hashed client contact entry matches one of the set of hashed values on the client do-not-contact list retrieved through the master do-not-contact list server; and
- determining, by the do-not-contact list client application of the client machine, that the first consumer should not be contacted via the contact information in response to the determination that the hashed client contact entry matches one of the set of hashed values on the client do-not-contact list that were retrieved through the master do-not-contact list server.
10. The method as in claim 9 wherein the contact information of the first consumer is collected by the client machine and is hashed by the first one-way hash engine connected to the client machine.
11. The method as in claim 9 wherein the contact information of the first consumer is collected by the client machine, hashed by the one-way hash engine residing in the client machine, and compared to the hashed values retrieved through the master do-not-contact list server on the client machine.
12. The method as in claim 9 further comprises causing the do-not-contact list client application of the client machine to be in communication with the master do-not-contact list server to retrieve at least one hashed value from the master-do-not contact list server to create the client do-not-contact list.
13. The method as in claim 9 further comprises causing the one-way has engine to include at least one one-way hashing scheme being selected from a group consisting of SHA-0, SHA-1, SHA-256, SHA-384, SHA-512, MD2, MD4, MD5, RIPEMD-160, RIPEMD-128/256/320, HAS160, HAS-V, HAVAL, Tiger, Panama, Snefru-2, GOST-Hash, BRS-H1/H20, and Whirlpool.
| 5963646 | October 5, 1999 | Fielder et al. |
| 6130937 | October 10, 2000 | Fotta |
| 6321267 | November 20, 2001 | Donaldson |
| 6330317 | December 11, 2001 | Garfinkel |
| 6397224 | May 28, 2002 | Zubeldia et al. |
| 6615348 | September 2, 2003 | Gibbs |
| 6868498 | March 15, 2005 | Katsikas |
| 7007068 | February 28, 2006 | Morkel |
| 7099444 | August 29, 2006 | Russell |
| 7117358 | October 3, 2006 | Bandini et al. |
| 7133898 | November 7, 2006 | Malik |
| 7158630 | January 2, 2007 | Fotta et al. |
| 7162738 | January 9, 2007 | Dickinson et al. |
| 7174453 | February 6, 2007 | Lu |
| 7305445 | December 4, 2007 | Singh et al. |
| 7389413 | June 17, 2008 | Bandini et al. |
| 7444380 | October 28, 2008 | Diamond |
| 7461263 | December 2, 2008 | Prince |
| 20020004900 | January 10, 2002 | Patel |
| 20020052921 | May 2, 2002 | Morkel |
| 20020059385 | May 16, 2002 | Lin |
| 20020069116 | June 6, 2002 | Ohashi et al. |
| 20020111920 | August 15, 2002 | Tresser |
| 20020143632 | October 3, 2002 | Walter et al. |
| 20020147846 | October 10, 2002 | Oizumi |
| 20020198786 | December 26, 2002 | Tripp et al. |
| 20030004787 | January 2, 2003 | Tripp et al. |
| 20030009698 | January 9, 2003 | Lindeman et al. |
| 20030212566 | November 13, 2003 | Fergusson et al. |
| 20030225841 | December 4, 2003 | Song et al. |
| 20040024823 | February 5, 2004 | Del Monte |
| 20040054887 | March 18, 2004 | Paulsen et al. |
| 20040073617 | April 15, 2004 | Milliken et al. |
| 20040117451 | June 17, 2004 | Chung |
| 20050074114 | April 7, 2005 | Fotta et al. |
| 20050246344 | November 3, 2005 | Keller et al. |
| 01/18631 | March 2001 | WO |
| WO 01/18631 | March 2001 | WO |
- Shane Hird, Technical Solutions for controlling Spam, Proceedings of Auug, 2002, pp. 1-17.
- Livingston, Ben, Possible modifications to Washington, “anti-spam” law, Internet Newsgroup, Jan. 31, 2002, 2 pages.
- Eugene Volokh, The Volokh Conspiracy, http://volokh.com/2003—06—15—volokh—archive.html, Jun. 2003, pp. 1-5.
- Declan McCullagh, “Bill Would Let Spamees Sue Spammers,” http://www.news.com/2102-1028—3-1016779.html, Jun. 2003, pp. 1-3.
- News Report, “FTC Launches Do Not Call Registry”, http://www.govtech.com/gt/print—article.php?id=58555, Jul. 2003, pp. 1.
- FTC, “National Do not Email Registry A report to Congress”, Jun. 2004, pp. 1-60.
- Saul Hansell, “Technology; The Bandwagon to Fight Spam Hits a Bump”, nytimes.com, Aug. 2003, pp. 1-3.
- Hallam-Baker, Phillip, [CPE] Re: [Asrg] Re: [Politech] Congress finally poised to vote on anti-spam bill [sp], IETF ARGF Mailing List Online, Nov. 21, 2003, 2 pages.
- Sachs, David, “Charles Hudson's Weblog” Internet Citation Online, Jun. 6, 2003, 2 pages.
- PCT International Search Report and Written Opinion for International Application No. PCT/US2004/00408, mailed Sep. 30, 2004, 20 pages.
- International Preliminary Examination Report (IPER) for International Application No. PCT/US2004/00408, mailed Feb. 13, 2006, 4 pages.
- Cindy J. Lackey, State Official's Guide to Internet Privacy, The Council of State Governments, 2002, pp. 1-127.
- “FTC Business Alert”, Federal Trade Commission, Apr. 2002, pp. 1.
- Lorrie Faith Cranor et al, Spam!, Communication of the ACM, 1998, pp. 1-10.
- Examiner's Report, Canadian Application No. 2,514,122, dated Feb. 17, 2012, 3 pages.
- Examiner's Report, Canadian Application No. 2,514,122, dated Mar. 25, 2013, 3 pages.
Type: Grant
Filed: May 10, 2011
Date of Patent: Dec 2, 2014
Patent Publication Number: 20110289321
Assignee: Unspam, LLC (Park City, UT)
Inventor: Matthew B. Prince (San Francisco, CA)
Primary Examiner: David García Cervetti
Assistant Examiner: Shanto M Abedin
Application Number: 13/104,931
International Classification: G06F 21/20 (20060101); G06F 15/16 (20060101); H04M 3/38 (20060101); H04L 12/58 (20060101);
