AU2005274636A1

AU2005274636A1 - Identity theft protection and notification system

Info

Publication number: AU2005274636A1
Application number: AU2005274636A
Authority: AU
Inventors: Igor D. Divjak; David W. Foster; John A. Willis
Original assignee: ID ALARM Inc
Current assignee: ID ALARM Inc
Priority date: 2004-08-20
Filing date: 2005-08-19
Publication date: 2006-02-23
Also published as: KR20070063514A; IL181358A0; MX2007002024A; EP1779588A1; WO2006017937A1; JP2008512008A; CA2565177A1; NZ553284A

Description

WO 2006/017937 PCT/CA2005/001265 1 IDENTITY THEFT PROTECTION AND NOTIFICATION SYSTEM 2 3 FIELD OF THE INVENTION: 4 5 [0001] The present invention relates to a secure monitoring system and methods for the 6 notification of identity usage. 7 8 BACKGROUND OF THE INVENTION 9 [0002] Personal information and identification are generally regarded as important and 10 worthy of at least a minimum attempt for security. People need identification for driving, 11 obtaining medical care and applying for jobs. Identification is also required by credit card 12 companies and banks to authorize the use of their services and also by government officials 13 for border security and airline travel security. 14 [0003] Credit agencies monitor the activity of people through their identification and the 15 use of various services such as a credit card for day-to-day purchases. This activity is 16 evaluated and people are given a credit rating which is essentially a "report card" for their 17 ability to pay back loans and other credit purchases they may require. Therefore the use of 18 sensitive identification information greatly affects a person's ability to mortgage property or 19 establish credit for making large purchases. 20 [0004] Ifa person's identification has been misplaced or stolen, it could be used by an 21 unauthorized person in various fraudulent ways. This activity could lead to negative results 22 applied against the person's credit rating and/or other undesired outcomes. The advent of 23 electronic commerce (E-commerce) has presented further challenges in protecting identity 24 information since identification numbers (i.e. phone numbers, social security numbers, credit 25 card numbers etc.) may be sent over public networks and information may be stored in an 26 electronic database which is connected to such a public network. 27 [0005] The Internet enabled World Wide Web provides wide access to information 28 flowing across its supporting infrastructure allowing a person's identity to be essentially 29 "stolen" since any unauthorized use of their personal information can be accomplished 30 quickly and in many different locations which may or may not be significantly remote to the -1- WO 2006/017937 PCT/CA2005/001265 1 person's place of residence. By the time the person realizes that unauthorized activity has 2 occurred, the damage has often already been done and it is up to the person to rectify any 3 incorrect or fraudulent activity. 4 [0006] Credit report services such as Equifax attempt to deal with identification theft by 5 providing an automated credit watch service, Equifax Credit WatchT. This service monitors 6 subscribing users' credit reports and provides alerts to the customers when activity occurs 7 relating to their credit reports. The alerts are presented to the customer either within 24 hours 8 or 7 days depending on the level of service paid for. A delay of even 24 hours is sufficient to 9 allow a person's identification to be used in many ways and many times. Therefore, although 10 monitoring is done, it is not nearly as responsive as necessary to track E-commerce activities. 11 Furthermore, credit report monitoring mainly relates to financial information and does not 12 encompass unauthorized use of other forms of identification such as a passport or driver's 13 license. 14 [0007] There exist various systems which monitor transaction activity and credit report 15 activity, namely those taught in U.S. 2003/0195859 Al to Lawrence, U.S. 2002/0133462 Al 16 to Shteyn, U.S. Patent No. 6,064,990 to Goldsmith, U.S. 2002/0169747 to Chapman et al., 17 and U.S. 2002/0087460 Al to Hornung. These documents teach various methods of tracking 18 a user's credit rating and/or transaction activities and notifying them of these changes. To 19 identify and notify the user, these systems require the storage of sensitive information. The 20 systems are typically connected to public networks such as the World Wide Web and, 21 therefore, this sensitive information is also prone to security risks and theft. The information 22 stored is available to unauthorized personnel through fraudulent activities and.thus the 23 information is not secure. 24 [0008] To protect the transfer and storage of sensitive information, it is well known to 25 encrypt and decrypt the information at the endpoints of the transmission. U.S. Patent No. 26 6,012,144 to Pickett teaches "slicing" and encrypting data before transmission wherein each 27 "slice" is decrypted and re-assembled at the receiving end. However, although the 28 transmission of the sensitive data is secure, the issue remains as to the storage of the intact 29 information. U.S. patent application publication, No. U.S. 2003/0070101 Al to Buscemi 30 provides a method for encrypting information and distributing a public key to decrypt. The 31 key is distributed first to the owner of the information and can be redistributed as they desire. -2- WO 2006/017937 PCT/CA2005/001265 1 Again this method requires the storage of the intact confidential information which is prone 2 to theft and/or unauthorized access. 3 [0009] It is therefore an object of the present invention to obviate or mitigate at least 4 some of the above mentioned disadvantages. More specifically, a system and method is 5 therefore required that can provide secure monitoring and protect sensitive information both 6 in storage and during communication. 7 8 SUMMARY OF THE INVENTION 9 [0010] In one aspect, the present invention provides a secure method for notifying a 10 subscriber of the use of a piece of identification by a verifier comprising the steps of 11 registering the subscriber with an alert system, storing identification information or data to be 12 protected and corresponding contact information of the subscriber, registering a verifier with 13 the same alert system, providing the verifier with an interface to submit a verification query 14 for verifying identification data of the subscriber, sending the query to the alert system, and 15 the alert system notifying the subscriber of the query for identification data. The subscriber 16 may then authorize or refuse the query made by the verifier. 17 [00111] In another aspect, the present invention provides a secure method for the 18 transmission of sensitive information between the subscribers of the alert system comprising 19 the steps of a first subscriber sending a notification to the alert system, the alert system 20 sending the notification to the authorized contact information provided by the second 21 subscriber and the second subscriber receiving the notification from the first subscriber. 22 [0012] In yet another aspect, the present invention provides a method for monitoring the 23 use of an access code using an alert system comprising the steps of gaining access to a 24 restricted site through a security access system, the site being, e.g., a building, data server, 25 etc.; the security access system submitting a verification query to the alert system to verify 26 the identity of a subscriber, and the alert system notifying the subscriber of the access. 27 [0013] In yet another aspect, the present invention provides a secure method for 28 authenticating correspondence between a verifier and a plurality of subscribers using the alert -3- WO 2006/017937 PCT/CA2005/001265 1 system. The verifier posts a message to be sent to a bulk list of recipients each being 2 associated with a unique identifier such as a numeric or alphanumeric identification number, 3 the identifiers are encoded and compared with subscriber information contained in the alert 4 system database, the alert system sends notification to the matched subscribers of the 5 existence of the message, stores the unmatched contact addresses for later non-subscriber 6 inquiry, the subscribers receive the notification and they follow steps to view the posted 7 message. This method ensures that the message received by the subscriber is from a trusted 8 source. 9 [0014] In yet another aspect, the present invention provides a secure method for a 10 subscriber to filter all or a pre-selected set of electronic mail using the alert system. The 11 subscriber is directed to the alert system whereby such email is received by the server of the 12 alert system. The alert system notifies the subscriber of incoming mail and provides a 13 response option. If the subscriber chooses not to accept messages from the particular sender, 14 the sender's address is blocked by the alert system and the message is not delivered and all 15 subsequent messages from such sender are locked without notification otherwise. If the 16 subscriber chooses to accept messages from the particular sender, then the message is 17 delivered. The subscriber can choose to accept messages based on defined preferences. 18 [0015] In yet another aspect, the present invention provides at least a pair of security S19 levels for establishing a set of core identification numbers and linking other identification 20 numbers to the core identification numbers using the alert system. The alert system receives 21 encoded versions of the other identification numbers with an encoded version of at least one 22 of the core' identification numbers and matches this encoded core identification number with S23 subscriber information in the alert system database, sends a notification to the subscriber of 24 the existence of the other identification number, the subscriber provides the identification 25 number to the alert system, the alert system encodes this number and compares with the other 26 identification number received to verify the legitimacy of the other identification number 27 wherein if the other identification number is verified it is linked to the core identification 28 numbers of that subscriber. 29 [0016] In one aspect, the present invention provides a method of identity monitoring 30 comprising the steps of a notification system storing identification information and contact 31 information for each of at least one subscriber, the identification information being stored in a -4- WO 2006/017937 PCT/CA2005/001265 1 secure manner; the notification system receiving a query from a verifier indicative of the use 2 of queried identification information; the notification system using the query to retrieve 3 contact information corresponding to the queried identification information if the queried 4 identification information corresponds to one of the at least one subscriber; and if retrieved, 5 the notification system using the contact information to notify the one of the at least one 6 subscriber of the use of the queried identification information. 7 [0017] In another aspect, the present invention provides a notification system for identity 8 monitoring comprising a storage device for storing identification information and contact 9 information for each of at least one subscriber, the identification information being stored in a 10 secure manner; an interface adapted to enable a verifier to submit a query indicative of the 11 use of queried identification information; and a server connected to the interface and the 12 storage device, the server capable of receiving the query from the interface and transmitting a 13 notification message to each of the at least one subscriber over a communication channel, the 14 server using the query to retrieve contact information corresponding to the queried 15 identification information if the queried identification information corresponds to one of the 16 at least one subscriber; and if retrieved, the server using the contact information to notify the 17 one of the one of the at least one subscriber of the use of the queried identification 18 information. 19 [0018] In yet another aspect, the present invention provides a method of monitoring 20 information belonging to a first correspondent by a second correspondent, the second 21 correspondent having permission to act on behalf of the first correspondent, the method 22 comprising the steps of a notification system storing the information belonging to the first 23 correspondent and contact information belonging to the second correspondent; the 24 notification system receiving a query from a third correspondent indicative of the use of 25 queried information; the notification system using the query to retrieve the contact 26 information if the queried information equals the information belonging to the first 27 correspondent; and if retrieved, the notification system using the contact information to notify 28 the second correspondent of the use of the information. 29 [0019] In yet another aspect, the present invention provides a system for monitoring 30 information belonging to a first correspondent by a second correspondent, the second 31 correspondent having permission to act on behalf of the first correspondent, the system -5- WO 2006/017937 PCT/CA2005/001265 1 comprising a storage device for storing the information belonging to the first 2 correspondent and contact information belonging to the second correspondent; an interface 3 adapted to enable a third correspondent to submit a query indicative of the use of queried 4 information; and a server connected to the interface and the storage device, the server capable 5 of receiving the query from the interface and transmitting a notification message to the 6 second correspondent over a communication channel, the server using the query to retrieve 7 the contact information if the queried information equals the information belonging to the 8 first correspondent; and if retrieved, the server using the contact information to notify the 9 second correspondent of the use of the queried information. 10 11 BRIEF DESCRIPTION OF THE DRAWINGS 12 [0020] Embodiments of the invention will now be described by way of example only 13 with reference to the appended drawings wherein: 14 [0021] Figure 1 is a block-type diagram of an identity monitoring system. 15 [0022] Figure 2 is a schematic diagram of an implementation of the system of Fig 1 16 providing notification via Email and wirelessly through a cellular phone. 17 [0023] Figure 3 is a block-type diagram of an encryption function. 18 [0024] Figure 4 is a schematic representation of a database. 19 [0025] Figure 5 is a schematic representation of a login page provided by a web-browser. 20 [0026] Figure 6 is a schematic representation of an information entry interface for 21 supplying the input of Figure 3. 22 [0027] Figure 7 is a flow chart showing the general steps in an identity monitoring 23 procedure. 24 [0028] Figure 8 is a flow chart shoWing the subscriber registration procedure of Fig 7. 25 [0029] Figure 9 is a flow chart showing the verifier registration procedure of Fig 7. -6- WO 2006/017937 PCT/CA2005/001265 1 [0030] Figure 10 is a flow chart showing the notification procedure of Fig 7. 2 [0031] Figure 11 is a flow chart showing the encryption procedure of Fig 10. 3 [0032] Figure 12 is a flow chart showing the subscriber response procedure of Fig 7. 4 [0033] Figure 13 is a flow chart showing the unmatched category filing procedure of Fig 5 12. 6 [0034] Figure 14 is a block-type diagram illustrating a second embodiment of the present 7 invention involving the transmission of information between multiple subscribers. 8 [0035] Figure 15 is a flow chart showing a secure bulk message posting procedure. 9 [0036] Figure 16 is a flow chart showing a bulk message inquiry procedure for non 10 subscribers. 11 [0037] Figure 17 is a flow chart showing a bulk message inquired procedure for 12 subscribers. 13 [0038] Figure 18 is a flow chart showing an email filtering procedure. 14 [0039] Figure 19 is a schematic representation of a pair of security levels. 15 10040] Figure 20 is a flow chart showing a process for linking other identification 16 numbers to the core identification numbers of Figure 19. 17 [0041] Figure 21 is a flow chart showing a solicitation procedure using the unmatched 18 identification numbers of Figure 20. 19 [0042] Figure 22 is a schematic representation of an embodiment of the identity 20 monitoring system utilising notarized registration. 21 [0043] Figure 23 is a flow chart showing a notarized registration procedure. 22 [0044] Figure 24 is a flow chart showing the steps in an embodiment of the identity 23 monitoring system utilising random charge registration. -7- WO 2006/017937 PCT/CA2005/001265 1 [0045] Figure 25 is a schematic representation of an embodiment of the identity 2 monitoring system comprising a verification mailbox. 3 [0046] Figure 26 is a flow chart showing a procedure for handling verification attempts 4 using the mailbox of Figure 25. 5 6 DETAILED DESCRIPTION OF THE INVENTION 7 [0047] Referring therefore to Figure 1, a secure communication system for identity 8 monitoring 10 ("the system") is generally comprised of a number of correspondents, for 9 example, a verifier 12, a notification or alert system 14 and a subscriber 16. A verifier or 10 verification entity 12 is any entity that needs to verify the identity of the subscriber 16 that 11 they are dealing with. These entities may include but shall not be limited to credit card 12 merchants, credit card issuers, banks, loan companies, employers, insurance companies, 13 health care providers, landlords, leasing companies, rental companies or government agencies 14 such as immigration, customs, law enforcement, social security and department of motor 15 vehicles. 16 [0048] A subscriber 16 is a person or organization who is the authorized holder of 17 personal or sensitive information and wishes to be notified of any use of that personal or 18 sensitive information. The personal or sensitive information may belong to the subscriber 16 19 or a dependant of the subscriber 16 such as a child or a deceased relative. Subscribers 16 20 may include but shall not be limited to an individual (i.e. a consumer/citizen), or a business 21 organization that uses various identification/registration numbers and credit cards. 22 [0049] Subscriber 16 may also comprise any entity having the right or permission to act 23 on another's behalf, such as an executor or power of attorney. Such subscribers may for 24 example hold power of attorney or otherwise be acting on behalf of, for example, the estate of 25 a deceased person or for someone who is otherwise incapacitated, e.g. someone who is 26 infirmed. Similarly, a parent or guardian of a child may also be considered someone acting 27 on another's behalf Therefore, although the child may be a minor, a responsible adult may 28 subscribe to the system 10 on their behalf A subscriber 16 may be registered or unregistered. -8- WO 2006/017937 PCT/CA2005/001265 1 A registered subscriber 16 is a subscriber 16 that has registered with, and been verified by the 2 alert system 14. 3 [0050] An alert system 14 facilitates the monitoring process and possesses the ability to 4 securely correlate identification data with the contact information of a subscriber 16. 5 [0051] By way of illustration, an electronic implementation of the network used to 6 implement the system 10 via the Internet and World Wide Web is shown in Figure 2. Every 7 entity involved in the system 10 is connected to the World Wide Web through existing 8 Internet infrastructure (Internet) 20. This may be provided through an available 9 communication means such as a digital subscriber line (DSL) or an equivalent internet 10 service provider (ISP) such as dial-up or cable providers. The verifier 12 has a computer 22 11 connected to the Internet 20 and in the particular embodiment illustrated in Figure 2, is 12 verifying a loan application by checking the authenticity of a driver's license 24. It will be 13 appreciated that the system 10 may be implemented over any communication channel or 14 network using any infrastructure supporting such a communication channel or network and 15 the invention should not be limited to the Internet and World Wide Web as illustrated in 16 Figure 2. For example the system 10 may be implemented over a local area network (LAN), 17 intranet, wide area network (WAN) etc. Any reference herein to a specific network or 18 infrastructure is purely for illustrative purposes and is not intended to limit the invention. 19 [0052] The alert system 14 has a computer (server) 26 with a suitable processor (not 20 shown). The server 26 is connected to a communication network such as the Internet 20 and 21 coordinates the notification and alert procedures of the alert system 14. The server 26 22 includes an interface to enable a human to interact with the alert system 14. For example, the 23 interface may comprise a website or other means for communicating with the alert system 14. 24 The subscriber 16 is preferably notified by receiving both an Email message accessible via a 25 personal computer 25 and by receiving a second message such as a text message via a 26 wireless device 28. However it will be appreciated the subscriber 16 may also receive a 27 notification message via an Email message only, a text message only or may receive any 28 number of notification messages via any number of acceptable devices. According to the 29 example shown in Figure 2, a wireless service provider 27 is connected to the Internet 20 and 30 communicates to the wireless device 28 by wireless transmission and to the personal 31 computer 25 via the Internet 20 or similar computer network. -9- WO 2006/017937 PCT/CA2005/001265 1 [0053] The server 26 may include an encryption module 30 to enable the encryption of 2 data for secure storage. Figure 3 shows a functional representation of an encryption module 3 30. The encryption module 30 applies an encryption function 34 to an input 32 to generate an 4 encrypted output 36. The input 32 generally comprises data which is to be securely stored on 5 the server 26. Once the input 32 is converted into an encrypted output 36, the input 32 is 6 preferably deleted and cannot be retrieved. Thus, even if the database 40 is accessed by an 7 unauthorized party, only encrypted information as opposed to authentic identification data 8 can be accessed. It will be appreciated that the encryption module 30 may reside on the 9 server 26 or may be implemented separately as desired. 10 [0054] Data stored by the alert system 14 is preferably stored in a storage device, such as 11 a database 40, shown in Figure 4. Preferably, an encrypted output 36 is stored with an 12 indicator 42 and associated contact information 38. This group of information will 13 hereinafter be referred to as an entry 44. The contact information stored in the database 40 14 can be used by the alert system 14 for notifying subscribers 16 by way of a query related to 15 the use of their identification data. A person skilled in the art would understand that many 16 entries 44 can be stored in the database 40. The indicator 42 can be classified as an "M" 17 which means that the entry 44 is matched or a "U" which means the entry 44 is unmatched. 18 If classified as matched, the entry 44 has been entered into the database 40 by the alert system 19 14 and corresponds to a registered subscriber 16, wherein the alert system 14 can contact that 20 subscriber 16 if that the securely stored information is part of a query made by a verifier 12. 21 If classified as unmatched, the entry 44 is normally incomplete, and has been entered into the 22 database 40 by the alert system 14 upon receipt of a query from a verifier 12 that does not 23 relate to a registered subscriber 16. In this case, the unmatched entry 44 may be retained for 24 other purposes as discussed below. 25 [0055] A verifier 12 can query and interact with the alert system 14 through various 26 interfaces. A login interface 50 is shown in Figure 5 and a verification interface 60 is shown 27 in Figure 6. The interfaces 50, 60 may be accessed by the verifier 12 via an application 28 program interface (API) which is loaded on their computer 22 once they have registered with 29 the alert system 14 or via a website hosted by the server 26. The login interface 50 includes a 30 usemrname entry box 52 and a password entry box 54. The login interface 50 is used to 31 provide access to the verification interface 60 and preferably provides secure access such as -10- WO 2006/017937 PCT/CA2005/001265 1 through a secure sockets layer (SSL) connection. The verification interface 60 is also 2 preferably implemented using a secure connection to the alert system 14 such as through an 3 SSL connection. 4 [0056] The verification interface 60 may be provided by the API or via the website 5 hosted by the server 26. The verification interface 60 has an identification number entry box 6 62, a message entry box 64, a status box 66 and is supported by the encryption module 30. It 7 will be appreciated that the interfaces 50, 60 depicted in the figures are intended only for 8 illustration purposes and that any interface that provides a similar functionality can be 9 provided by the API or the website hosted by the server 26. It will also be appreciated that 10 the interfaces 50, 60 may be implemented in various languages to facilitate verification and 11 notification between subscribers and verifiers of different languages. For example, interfaces 12 50,60 may include language translation functionality for allowing a verification in one 13 language to appear as a notification in another language. 14 [0057] The general steps involved in the notification and alert procedure 700 are 15 illustrated in Figure 7. The database 40 is built by collecting entries 44. These entries 44 are 16 collected during the subscriber registration procedure 702. The database 40 is accessed by a 17 verifier 12 once they have completed the verifier registration procedure 704. The registration 18 procedures occur using a verification entity 705 external to the system 10. The verification 19 entity 705 receives a request for verification along with the entity's information and verifies 20 the identity of an entity trying to register with the alert system 14 and indicates to the alert 21 system 14 whether or not the entity trying to register has supplied valid information. With a 22 populated database 40, the notification procedure 706 can be executed which encourages and 23 facilitates the subscriber response procedure 708. 24 [0058] The subscriber registration procedure 702 is illustrated in Figure 8. To register 25 with the alert system 14, the subscriber 16 may begin by communicating with the alert system 26 14, preferably by accessing a website hosted by the server 800. The website is preferably 27 accessed securely using a secure connection such as an SSL connection to ensure the 28 information provided during the registration procedure 702 is kept secure. It will be 29 appreciated that the website may be accessed by some other party on behalf of the subscriber 30 16 if permission is so granted. Upon communication with the alert system, the subscriber 16 -11- WO 2006/017937 PCT/CA2005/001265 1 is presented with a set of options if applicable, or can directly register with the alert system 2 .14. 3 [0059] In this example, upon accessing the website 800 the subscriber 16 has three 4 options which are: to begin the registration procedure 802, "stake your.claim" 804 or to do 5 an identification search 806. The "stake your claim" option 804 is a service which may be 6 provided by the alert system 14 to unregistered users to ensure that other parties cannot 7 register with the alert system 14 using their identification data. The identification search 8 option 806 is a service which may be provided by the alert system 14 to allow unregistered 9 users the opportunity to submit a query to determine whether or not an identification number 10 corresponding to their personal information has been filed as unmatched in the database and 11 therefore an attempt has been made by a verifier 12 to verify that particular identification 12 number. 13 [0060] To "stake your claim", the unregistered user may submit a identification number 14 corresponding to a piece of personal information (i.e. a credit card number etc.) as well as 15 contact information to the website 808 which uses the encryption module 30 to generate an 16 output 36 for submission to the database 40. The identification number is stored for future 17 reference such that if another party attempts to register that number, both parties are notified 18 of the dispute which should be dealt with before either party can register with the alert 19 systeml4. The unregistered user is then asked whether they want to subscribe to the service 20 812. If they choose "No" then the system 10 thanks them for the inquiry 813 and asks them 21 to consider registering in the future. If they choose "Yes" then the registration option 802 is 22 automatically executed. 23 [0061] If an unregistered user chooses to perform an identification search 806, they input 24 the identification number of interest 814 and the system encrypts the number and searches the 25 database 40 for any unmatched entries that contain the encrypted number 815. This allows an 26 .unregistered user to identify whether any verifier 12 has attempted to validate a transaction 27 using their identification. Any matches are displayed 816 to the unregistered user and they 28 are asked whether they would like to register 812 based on the activity which has occurred 29 using their identification. If they choose "No", then the system 10 thanks them for the 30 inquiry 813 and asks them to consider registering in the future. If they choose "Yes" then the 31 registration option 802 is automatically executed. - 12- WO 2006/017937 PCT/CA2005/001265 1 [0062] Depending upon the choices presented by the alert system 14, the registration 2 option 802 is either presented automatically or is initially chosen by the potential subscriber 3 16 of the alert system 14. The subscriber 16 provides a set of information required by the 4 alert system 818 to allow the alert system 14 to determine the authenticity of the identity of 5 the potential subscriber 16. In this example, the alert system 14 would generate and send a 6 registered letter to the subscriber 16 to authenticate with a verification entity 705. The 7 information preferably includes a name, address, phone number and payment method. The 8 subscriber 16 can also provide a desired username and.password 820 if required. 9 [00631 Using the information submitted, the alert system 14 preferably generates a unique 10 reference number and issue a letter addressed to the subscriber 16. The letter is preferably 11 sent by registered mail. The subscriber 16 will typically be requested to present photo 12 identification to pick up the registered letter, and thereby have access to the reference 13 number. The subscriber 16 then submits this reference number to the alert system 16 to 14 authenticate the registration of the subscriber 16. 15 10064] In this example, the subscriber 16 takes the registered letter to the verification 16 entity 705 with the reference number, proof of identity and the identification being verified. 17 The verification entity 705 can be any trusted third party verifying agent such as the local 18 police or other government agency. The manual verification allows a trusted third party to 19 validate the verification. The verification entity 705 communicates with the alert system 14 20 to.indicate whether or not the verification was successful 822. If verification is successful, 21 the verification entity 705 sends the identification number to the alert system 14 for input into 22 the system. If the verification is unsuccessful, the verification entity sends an error 23 notification to the alert system 14. Although the subscriber verification procedure described 24 herein is done manually with a registered letter sent to the subscriber 16 who would typically 25 take that registered letter to the verification entity 705, it will be appreciated that the 26 verification procedure may alternatively be done electronically. For example, electronic 27 verification can be implemented using a trusted and secure verification entity 705 which is 28 communicated with via a telephone, the Internet or other communication media. It will 29 further be appreciated that verification may be accomplished without the use of a verification 30 entity 705 wherein the reference number obtained upon receipt of the registered letter can be 31 communicated to the alert system 14 by the subscriber 16 thereby verifying the registration. -13- WO 2006/017937 PCT/CA2005/001265 1 [0065] If the verification entity 705 rejects the registration, the alert system 14 provides a 2 message indicating that the subscriber 16 cannot be registered 824. If the verification entity 3 705 authorizes the registration, the subscriber 16 is asked to input the identification 4 number(s) they want to protect 826 and the alert system 14 stores this information with the 5 contact information in the database 40. Preferably, the alert system 14 deletes the 6 information provided during step 818 so that no sensitive information is stored. In this 7 example, the subscriber 16 would input the number of their issued driver's license 24. The 8 subscriber 16 may also wish to protect multiple identification numbers or to create sub 9 accounts involving dependants such as minors or for deceased relatives. The alert system 14 10 would typically allow the subscriber 16 to protect any number of identification numbers as 11 well as monitoring the identities of dependants or the deceased by offering sub-accounts as an 12 enhanced service to their account. The subscriber 16 is then asked to input a desired contact 13 information 828. The contact information can be a phone number, email address or any other 14 contact information but for maximum anonymity it is most desirable to provide an 15 anonymous email address which cannot be linked to any name or address. In this example, 16 the driver's license number is encrypted and stored with the contact information in the 17 database 40. 18 [00661 When encryption of the data is used by the alert system 14, the encryption 19 procedure 1100 shown in Figure 11 may be used. Following submission of the identification 20 number 826, the encryption module 30 captures the string to be encrypted 1102. To encrypt 21 the string, the encryption module 30 in the present example applies a 512-bit hash function 22 1104. This hash function takes the string which is of an arbitrary finite length and maps it to 23 a string of a fixed 512-bit length 1106. The encrypted value 36 is a compact representation of 24 the input string 32 and can be used as if it were uniquely identifiable with that string. 25 Therefore the encrypted output 36 is unique to the input 32 but does not contain the actual 26 identification number, in this case the actual driver's license number. However a portion of 27 the identification number such as the last 4 digits may be retained to indicate to the customer 28 which identification number has been used. After encryption, the input string 32 is deleted 29 and the output 36 which is an encrypted string is saved in the database 40. 30 [0067] Preferably, the encryption module 30 generates a multiple field hash of the 31 particular identification number. For example, a three field hash may be used, the three fields - 14- WO 2006/017937 PCT/CA2005/001265 1 corresponding to the issuer of the identification, the type of identification, and the 2 identification number itself In the example described herein, a three field hash would 3 include the government body as issuer, driver's license as type, and the particular number 4 unique to the card 24 respectively. A multiple field hash may be used to better distinguish 5 between different identification pieces that have similar numbers. For example, by including 6 a hash of both the issuer and type, two driver's licenses in different states and provinces 7 having the same number are still unique. Any number of hash fields can be used depending 8 on the particular use of the system 10. 9 [0068] Referring again to Figure 8, once the encrypted identification number and contact 10 information has been input into the database 40, the setup is completed 830 and the 11 subscriber 16 is now registered. It will be appreciated that the subscriber registration 12 procedure 702 may also be done through other media other than an Internet based website 13 such as the telephone and shall not be limited to such methods. It will also be appreciated 14 that although the encryption module 30 herein applies a one-way 512-bit hash function 1104, 15 any encryption method (E.g. public-key encryption, two-way hash functions etc.) may be 16 used to enable secure communication and storage. Furthermore, any reference to specific 17 security measures particularly the encryption method described herein is provided for 18 illustrative purposes only and is not intended to limit the invention. 19 [0069] However, in the preferred embodiment of the present invention described herein, 20 one-way encryption is preferred. One-way encryption stores information in an encrypted 21 form and contains no function for decrypting the information to its original state. According 22 to the example described herein, incoming queries are also in their encrypted form and thus 23 compared to the stored encrypted value. This is preferable as only the encrypted versions of 24 the information are stored and in the event of unauthorized access to the stored information in 25 the database 40, only an encrypted version (and not the actual identification number) can be 26 fraudulently obtained. 27 [00701 The verifier registration procedure 704 is shown in Figure 9. To register with the 28 alert system 14, the subscriber 16 would typically begin by communicating with the alert 29 system 14, preferably by accessing a website hosted by the server 900. The website is 30 preferably accessed securely using a secure connection such as an SSL connection to ensure 31 the information provided during the registration procedure 704 is kept secure. The website is - 15- WO 2006/017937 PCT/CA2005/001265 1 accessed through a secure connection such as an SSL connection to ensure the information 2 provided during the registration procedure 704 is kept secure. Similar to the subscriber 3 registration procedure 702, upon communication with the alert system 14, the verifier may be 4 presented with a list of options or may proceed directly to the registration procedure. In this 5 example, upon accessing the website 900 the verifier 12 has two options. Firstly, if the 6 verifier 12 has not registered with the alert system 14, they can choose to register902. If the 7 verifier 12 has been registered previously, they can also choose to add additional verifier 8 accounts 904. 9 [0071] When the verifier 12 chooses to register 902, they are first asked to provide 10 information regarding their organization 906 for verification purposes. The information 11 provided preferably includes but is not limited to an organization name, address, phone 12 number and payment information. If the organization is a single person, then the 13 organization name is simply their own name. The verifier 12 may then choose an 14 administrative username and password 908. Each account has one administrative access for 15 modifying and.governing the account. If the verifier 12 is a single person then the account 16 would typically have only administrative access. 17 [0072] Using the information submitted, the alert system 14 determines the authenticity 18 of the verifier's information 910. The alert system 14 may automatically approve a verifier 19 12 in the case of large entities or upon agreements with trusted bodies such as the government 20 or a bank. In other cases, the alert system 14 .may require verification similar to that done for 21 subscribers. For example, the alert system 14 can send a registered letter to the verifier 12. 22 The verifier 12 would typically be required to present photo identification to pick up the 23 registered letter which includes a reference number. The reference number is used by the 24 verifier 12 to inform the alert system 14 that the correct entity has received the registered 25 letter and therefore can be registered. In one example, the verifier 12 supplies the verification 26 entity 705 with the reference number and proof of identity to validate their existence similar 27 to the subscriber verification procedure. Again, although the verification procedure described 28 herein is done manually by the verifier 12 and the verification entity 705, it will be 29 appreciated that secure electronic verification through a third party verification entity may 30 also be used if necessary or required. -16- WO 2006/017937 PCT/CA2005/001265 1 [0073] In the case of a verifier 12 not pre-authorized by the alert system 14, presentation 2 of the reference number found in the registered letter informs the alert system 14 whether or 3 not the account has been verified 910. If verification has not occurred, the alert system 14 4 provides a message indicating that the verifier's organization cannot be verified 912. If 5 verification has occurred, the verifier 12 is asked to input the subscriber account information 6 for the administrative subscriber account 914. This information may include but is not 7 limited to a location, contact name and contact information. This information is used by the 8 alert system 14 to attach a message to an alert allowing the subscriber 16 to contact the 9 verifier 12 for authorization purposes or possible disputes. 10 [0074] Preferably, the verifier 12 is next asked whether they would like to add additional 11 verifier accounts other than the administrative one 916. These additional verifier accounts 12 can be provided to employees of the organization who require the ability to verify 13 identification. If the verifier 12 wishes to add additional accounts, the input procedure 914 is 14 repeated. Steps 914 and 916 are repeated for each additional verifier account that is required. 15 Once the verifier 12 does not want to add any more additional verifier accounts, it is 16 informed that additional verifier accounts can be added at a later date by accessing the 17 website and choosing that option 904. With the account(s) set up, the verifier 12 is instructed 18 to download the application program interface (API) 918 from the alert system 14. It will be 19 appreciated that the API may also be loaded on the computer 22 of the verifier 12 via a 20 recordable medium such as a compact disc and does not necessarily need to be acquired via a 21 website. The API includes the information entry interface 60 supported by the encryption 22 module 30. The verifier 12 can run the API directly from their computer 22 to verify 23 identification or can access the verification interface 60 by accessing the website. Once the 24 API has been acquired, the registration setup is finished 920. It will be appreciated that the 25 verifier registration procedure 704 may also be done through media other than an Internet. 26 based website such as via the telephone and shall not be limited to such methods. 27 [0075] In this example, upon accessing the website 900 and if the verifier 12 has 28 previously been registered and has administrative access, they can choose to add additional 29 verifier accounts 904. The verifier 12 would typically provide an administrative username 30 and password to login 922. The verifier 12 then inputs the required information 924 for the 31 first new verifier account. The information may include but is not limited to location, name -17- WO 2006/017937 PCT/CA2005/001265 1 and contact information similar to during the registration procedure. The verifier 12 is then 2 asked whether or not they would like to add another account 926. If they wish to add another 3 account, steps 924 and 926 are repeated. When the verifier 12 has finished adding new 4 accounts, they would typically logout 928. The login information, including the username 5 and password is protected during storage to prevent fraudulent access to the alert system 14. 6 This can be accomplished using encryption or other security methods as described above. In 7 one embodiment, the passwords are one-way encrypted using the encryption module 30 so 8 that the actual password entered by the verifier 12 is not stored by the alert system 14. It will 9 be appreciated that any password protection method may be used and should not be limited to 10 one-way encryption. 11 [0076] When a verifier 12 has been registered with the alert system 12, they can use the 12 system 10 to verify whether a person providing their identification 24 is the authorized owner 13 of that identification 24. A typical notification procedure 706 is shown in Figure 10. The 14 verifier 12 begins by either accessing the website 1000 if they do not wish to use the API or 15 do not have a copy or by accessing the API from their location 1002 via their computer 22. If 16 the verifier 12 chooses to perform the notification procedure 706 by accessing the website 17 1000 they would typically be required to first provide the username and password and login 18 1004. 19 [0077] At this point, either the website or the API launches the information entry 20 interface 60 and the verifier 12 inputs the identification number to be verified 1006. The 21 identification number may in one example be acquired from the driver's license 24 provided 22 to the verifier 12. The interface 60 then allows the verifier 12 to attach a message 1008 23 which may be displayed to the subscriber 16 upon receiving notification. In this example, by 24 default, the message may include who is sending the notification and their contact 25 information to enable a response, but the verifier 12 can choose to provide additional details 26 in the message at this point. At this point, the verifier 12 indicates whether a passive or 27 active response is required for authorization. 28 [0078] To enhance security, the alert system 14 can instruct the verifier 12 to enter a 29 password provided by the alert system 14 in the API for each verification 1009. In this 30 example, the password is embedded in an image on the interface 60 requiring a verifier 12 to 31 extract the password from the image. The password is typically distorted such that it cannot -18- WO 2006/017937 PCT/CA2005/001265 1 be read by optical character recognition (OCR) methods thereby preventing automated mass 2 verification inquiries. Therefore the alert system 14 can allow the verifier 12 to authorize 3 each individual verification inquiry to provide further security to the alert system 14. The 4 verifier 12 then submits the notification 1010, and in this example, the identification number 5 is encrypted 1100 before it is sent to the server 1014. It will be appreciated that other 6 methods for providing a verification password may be used and the invention should not be 7 limited to image embedded passwords. 8 [00791 If the alert system 14 utilizes encryption, any identification numbers stored by the 9 alert system 14 are encrypted using the same encryption procedure 1100 applied during 10 registration. Therefore if, using the present example, the driver's license number 24 is stored 11 in the database 40 by a registered subscriber 16, the encrypted output 36 can be compared to 12 the encrypted value sent to the alert system 14 in step 1014. The alert system 14 preferably 13 compares and stores encrypted identification numbers providing security from fraudulent 14 activities such as "hacking" into the database 40 by unauthorized personnel since no sensitive 15 information is actually stored by the database 40. 16 [0080] In the next step, the subscriber 16 is notified of the use of identification data 17 belonging to them. For example, in one embodiment, the notification is sent to the subscriber 18 16 via an Email notification through the Internet 20 which can be accessed through the 19 personal computer 25 as well as by sending a message via wireless transmission to a wireless 20 device 28. In one embodiment, to help prevent mass-enquiries via the interface 60, a quota is 21 tracked by the alert system 14 such that only registered verifiers 12 who have not exceeded 22 their quota can initiate a notification. The quotas are reasonably implemented such that the 23 quotawould typically only be exceeded through unauthorized mass-enquiries. This prevents 24 the subscriber 16 from receiving excessive, unnecessary notifications generally known as 25 "SPAM". 26 [0081] In this particular example, to enable receipt of the wireless message, the wireless 27 service provider 27 transmits a signal to the subscriber's wireless device 28. If the verifier 12 28 indicated that a passive response is required by the subscriber 16, then they may proceed with 29 the transaction 1018 and the authorization will follow up 1020 at a later time. This can occur 30 when the authorization procedure occurs over a fixed period of time and the notification 31 procedure 706 is only a part of the authorization. For example, a passive response may be - 19.

WO 2006/017937 PCT/CA2005/001265 1 desirable for mortgage approvals, loan approvals, or job applications. If the verifier 12 2 indicated that an active response is required by the subscriber 16, they may wait for the 3 response 1022 before proceeding with the transaction. 4 [0082] An active response can be required for more immediate authorization procedures 5 such as credit card purchases where the merchant requires a substantially instant approval to 6 approve the transaction: The active response is particularly relevant to on-line transactions 7 such as purchases using a credit card. The subscriber 16 would be capable of receiving the 8 Email notification since they are already on-line therefore allowing immediate response to the 9 notification. 10 [00831 Making reference now to Figure 12, an example of the subscriber response 11 procedure 708 is shown. The response procedure 708 begins with the alert system 14 12 receiving the incoming identification number 1200, preferably in an encrypted form as in this 13 example. This number is compared to the listed numbers in the database 1202 to indicate 14 whether or not there is a match 1204. If the identification number matches, the alert system 15 14 prepares an alert 1206. In this example, the portion of the identification number that was 16 retained indicates the type of identification being used. The alert in this case includes a 17 message to the subscriber that for example "the identification number ending with 1234" (the 18 portion of the number retained) is being used for verification by the name supplied by the 19 verifier 12 and they can be contacted at the contact information provided by the verifier 12. 20 The message may also indicate if appropriate, whether or not an immediate response is 21 required. The contact information associated with the matched entry 44 is identified 1208 22 and the message is sent 1210 to the contact information 38. 23 [0084] In one embodiment, the subscriber 16 may receive the alert 1212 by Email and 24 additionally by their wireless device 28 and if the response is intended to be passive, they 25 may respond at their leisure 1214 or if the response is intended to be active, a mandatory 26 response is required 1216. The subscriber 16 can respond to the alert by any method they 27 choose, and may be dictated by the nature of the contact information provided by the verifier 28 12. For instance, if the verifier 12 supplies an Email address as their contact information, the 29 subscriber 16 may be required to locate a computer with such capabilities if their wireless 30 device 28 does not support Email. Alternatively, if the transaction is an on-line transaction, 31 the notification may be received instantly to the Email address and the subscriber 16 can -20- WO 2006/017937 PCT/CA2005/001265 1 respond immediately since they would typically be connected to the Internet 20 to initiate the 2 transaction. 3 [0085] The next step involves matching the incoming identification data with data found 4 in the database 40. In this particular example, if the alert system 14 cannot find a match for 5 the incoming encrypted identification number, it may enter the encrypted value in the 6 database 40 and mark it as unmatched 1218. The indicator 42 would typically be marked as a 7 "U". This procedure 1218 is shown in Figure 13. The unmatched procedure 1218 begins by 8 receiving the encrypted identification number and any other information that may have been 9 supplied with the identification number 1300. An entry 44 is then made in the database 40 10 with the entry 44 marked "U" 1302. The information is checked to determine whether or not 11 any contact information was supplied 1304. If there was contact information supplied, the 12 alert system 14 prepares a notification 1306 and sends this. notification to the contact 13 information 1308. This notification indicates that a piece of the person's identification has 14 been used and that if they want to obtain the alert service they can follow the indicated 15 directions. Once the notification is sent 1308 or if there was no contact information found, 16 the entry is made available in the database 40 for future "stake your claim" and unregistered 17 customer searches 1310. 18 [0086] Referring again to Figure 10, the notification procedure 706 can finish once the 19 response procedure 708 has occurred. This is most critical in the case of an active response. 20 The verifier 12 has been waiting for a response 1022 and would typically eventually receive 21 an authorization from the subscriber 16 or a rejection from the alert system 14 due to an 22 unmatched entry or if a prescribed amount of time has elapsed 1024. If the transaction has 23 not been authorized, it may be rejected 1026 by the verifier 12. If the transaction has been 24 authorized via approval from the subscriber 16, the transaction is approved 1028 by the 25 verifier 12. 26 [0087] In another embodiment of the present invention, the system 10 may be 27 implemented to allow the transmission of sensitive information between various subscribers 28 16 as shown in Figure 14. The security incorporated into the alert system 14 is used to verify 29 that the second subscriber who is receiving the sensitive information from the first subscriber 30 is the correct recipient. The notification received by the second subscriber may include 31 contact information to contact the first subscriber for further conversation. It will be -21- WO 2006/017937 PCT/CA2005/001265 1 appreciated that the second embodiment may be achieved using the secure transmission and 2 storage of subscriber information as well as the notification procedure described herein 3 according to example given illustrating the present invention and need not be reiterated. 4 [0088] In yet another embodiment of the present invention, the system 10 may be 5 implemented for security tracking such as for using access codes. For example, the verifier 6 12 according to this embodiment can be a security access card and when that card is used to 7 gain access, (to a building, vehicle, safe deposit box etc.) a verification and notification 8 procedure as described herein according to the example given illustrating the present 9 invention is initiated such that the subscriber 16 may receive a notification of their security 10 access card being used for access a particular zone such as a building or vehicle. Such an 11 embodiment may be suitable for but shall not be limited to buildings with controlled access 12 and can notify the authorized holder of the use of their security access card and to monitor 13 this use. It will be appreciated that the use of the system 10 for building security may use the 14 elements described herein according to the example given illustrating the present invention 15 and these elements need not be reiterated. 16 [0089] In another embodiment, a verifier 12 may also wish to send bulk email 17 correspondence which may include or request sensitive identification information belonging 18 to their customers through a secure channel. By allowing their customers to view the 19 message contained in the bulk email through this secure channel, the customer can be 20 confident that the correspondence originated from a trusted source and that the identity of the 21 verifier 12 has not been misused. The customer can then, for example, proceed to provide 22 sensitive information, if requested, with confidence that the sensitive information may be 23 exchanged with the proper recipient. As well, the verifier 12 can also attempt to ensure that 24 its customers are not misguided through unauthorized correspondence. 25 [0090] In yet another embodiment of the present invention, the system 10 may be 26 implemented for secure correspondence between verifiers 12 and their customers which may 27 include one or many subscribers 16 using the alert system 14. Referring now to Figure 15, a 28 secure bulk message posting procedure 1500 is shown. 29 [0091] The verifier 12 may access their account and post a bulk message on the server 30 1502. This bulk message is intended to be received by a verifier-supplied list of recipients. -22- WO 2006/017937 PCT/CA2005/001265 1 The verifier 12 may provide an identification number associated with the customer, a contact 2 email address or any suitable information as required by the alert system 14 for verification 3 purposes. These numbers are preferably encrypted using the procedures described above and 4 this encrypted data is compared with the encrypted entries of the database 1504. 5 [00921 The alert system 14 may then perform a sorting procedure 1506 to identify 6 verified subscribers 16 from non-subscribers. Any unmatched entries from the sorting 7 procedure 1506 can be stored in an unmatched database for later inquiry 1508. The matched 8 entries are associated with subscribers 16 and the alert system 14 generates a bulk notification 9 message 1510 which is sent to these subscribers 1512. A subscriber 16 may receive the 10 notification indicating that they have received an email from the indicated verifier 12 and 11 may be given instructions to view the message 1514. The subscriber 16 may then use the 12 notification to follow the steps given to retrieve the message. An exemplary set of steps for 13 retrieving the message would be for the subscriber 16 to follow a hyperlink requiring them to 14 first logon to the server 26, and the alert system 14 would redirect the subscriber 16 to the, 15 posted message. 16 [0093] By incorporating the above procedure 1500, the verifier 12 can provide electronic 17 correspondence through a secure channel whereby a subscriber 16 can distinguish between 18 authorized (or legitimate) emails from unauthorized emails they may receive based on the 19 fact that the latter would not have been posted to the alert system 14. The identity of the 20 verifier 12 as well as the identity of the subscriber 16 can therefore be protected while 21 encouraging confidence that electronic correspondence between the two parties 12, 16 can be 22 achieved in a secure fashion. 23 [0094] The aforementioned unmatched entries provided by the verifier 12 can be used by 24 the alert system 14 to allow access to unverified users (i.e. non-subscribers) who wish to view 25 the bulk email. The verifier 12 may send a notice to such individuals (or entities) that bulk 26 messages have been securely posted on the alert system 14 and redirect them to the system 27 website. Alternatively, the alert system 14 may provide notice to these individuals that they 28 may receive the message through a secure channel (i.e. the alert system 14). This could be 29 provided by the verifier 12 as an added service to their customers while helping to protect 30 their own identity. A procedure for non-subscribers to inquire about bulk messages 1600 is 31 shown in Figure 16. -23- WO 2006/017937 PCT/CA2005/001265 1 [0095] Upon receiving a notification that they were a recipient of a bulk email message, 2 the non-subscriber is directed to access the website 1602. The non-subscriber may then 3 preferably input relevant information 1604 such as the email address in which the bulk email 4 was intended to be sent to or the identification number associated with the verifier 12. It will 5 be appreciated that if the identification number is used, the number would be encrypted.by 6 the alert system 14 to allow comparison with encrypted versions of the identification number 7 stored by the alert system 14. For illustrative purposes, it may be assumed that the non 8 subscriber inputs their email address. 9 [0096] The unmatched bulk recipients list is then scanned by the alert system 1606 and a 10 set of instructions is provided to the non-subscriber if their email address is included in the 11 list. Typically the non-subscriber may be performing this procedure upon receipt of some 12 form of notification. However the list is preferably scanned each time in the event that 13 regular inquiries are desired by the non-subscriber to check for pending bulk email messages. 14 [0097] Upon receiving the set of instructions, the non-subscriber may follow the set of 15 instructions, thereby gaining access to the message sent to them 1608. The non-subscriber 16 may then be asked by the alert system 14 if they would like to register 1610 with the alert 17 system 14 for both secure email purposes and other benefits associated with being a 18 subscriber 16. If the non-subscriber wishes not to register, they would typically finish their 19 session with the website 1612. If they do wish to register they would be redirected to the 20 registration procedure 702, particularly step 802 shown in Figure 8. 21 [0098] A subscriber 16 may also wish to verify the authenticity of email messages that 22 they perceive to be bulk email correspondence from a legitimate company requesting 23 information. A procedure for performing a bulk message inquiry 1700 is shown in Figure 17. 24 The subscriber 16 first logs on to their existing account 1702 with the alert system 14 and 25 then performs an email inquiry 1704. This may be done using any suitable information 26 provided by the subscriber 16 such as, but not limited to, the email address from which the 27 email was sent, the company name etc. The alert system 14 may check their database 40 to 28 determine whether or not the information corresponds to a registered verifier 12 and whether 29 or not the bulk message they have received was sent correctly. Any results produced by the 30 alert system 14 are returned to the subscriber 1706. The alert system 14 therefore may -24- WO 2006/017937 PCT/CA2005/001265 1 provide an additional service to their subscribers 16 to inquire about any email they receive 2 which requires the exchange of sensitive information. 3 [0099] Subscribers 16 may wish to extend the notification capabilities of the alert system 4 14 to handle other email messages or even the entirety of messages they receive at a specific 5 email address. In yet another embodiment of the present invention, the alert system 14 may 6 offer as an added service, the capability of filtering email to prevent a subscriber 16 from 7 receiving unwanted messages commonly referred to as "SPAM". 8 [00100] A procedure for filtering a subscriber's email through the alert system 14 is shown 9 in Figure 18 and is generally denoted numeral 1800. The procedure 1800 is initiated by the 10 subscriber 16 choosing to incorporate the email filtering with their account 1802. The 11 subscriber 16 may simply change their user preferences for re-directing incoming mail 12 through the alert system 1804. The preferences may include varying degrees of filtering and 13 different security levels depending on the needs of the subscriber. Upon activating this 14 preference, the email sent to the specified account, which would preferably be the email 15 address used for the subscriber's contact information, is received by the server 1806 of the 16 alert system 14. 17 [00101] The alert system 14 may notify the subscriber 16 that a particular entity has sent 18 them an email 1808 with an option to accept or block the sender. The subscriber 16 may 19 respond to the notification 1810 to enable the alert system 14 to filter future messages from 20 the particular sender. The alert system 14 may collect the responses and determine whether 21 or not the subscriber 16 wishes to accept future messages from the indicated sender 1812. If 22 the subscriber chooses not to accept, the sender's message is blocked 1814 whereas if the 23 sender is accepted they become an "allowable" sender 1816. 24 [00102] It will be appreciated that the subscriber 16 may be able to impose restrictions to 25 limit acceptance of messages from the sender using criteria such as the number of 26 correspondences received in a specified time period. Alternatively, the criteria may be based 27 on a select list of "keywords" etc. This allows the subscriber 16 and the alert system 14 to 28 impose restrictions on marketing and solicitation which may be of interest to the subscriber 29 16 such that an undesirable amount or type of incoming email is avoided. -25- WO 2006/017937 PCT/CA2005/001265 1 [00103] In another embodiment of the present invention, various levels of protection may 2 be defined to not only enable a subscriber to protect a particular piece of identification from 3 the day of subscribing with the alert system 14 onwards, but also activity pertaining to their 4 identity that may have occurred prior to subscribing. An example of varying security levels 5 is shown in Figure 19. The security levels shown include a core ID level 70, a linked ID 6 level 72 and a real-time alert service level 74. 7 [00104] The core ID level 70 in this embodiment represents the core level of protection. 8 When a subscriber 16 chooses to register with the alert system 14, they may typically provide 9 a core set of identification numbers such as a driver's license, social security number and/or 10 passport number. It is well known that these core identification numbers are typically the 11 primary sources of identification required when verifying one's identity. To establish the 12 core ID level 70, the subscriber 16 would register with the alert system 14 as described 13 herein. Upon subscribing it is preferable to have the subscriber 16 present at least two pieces 14 of core identification. For example, the subscriber may be requested to provide a social 15 insurance number and a driver's license number. However it is most preferable to provide 16 three pieces of core identification to further include, for instance, a passport number. The 17 alert system 14 may proceed to verify the core identification numbers by sending a registered 18 letter to the subscriber 16 (or other suitable method for verification) to ensure that the 19 subscriber 16 is the true owner of the identification number presented, as previously 20 described with respect to the present invention. 21 [00105] The establishment of the core ID level 70 provides the basic service. The 22 subscriber 16 would typically employ the alert system 14 to provide real time alert service 74 23 also as described above. At the time of subscribing, the alert system 14 in this embodiment 24 would preferably not automatically link other identification numbers such as a credit card 25 number, bank account number, health card number etc. to the core identification. It is 26 conceivable that a properly verified subscriber 16 may wish to link another person's credit 27 card number, for example, to their account such that they may be the individual that receives 28 notification of the use of that credit card number, thereby enabling fraudulent activity through 29 the secure communication channel. This example depends on the situation where the 30 legitimate owner of the credit card has not subscribed to the alert system's service. -26- WO 2006/017937 PCT/CA2005/001265 1 Nonetheless, to offer the maximum protection for these "other" identification numbers, it is 2 preferable to add a second security level, namely the linked ID level 72. 3 [00106] The linked ID level 72 takes advantage of the above described secure 4 communication channel provided by the alert system 14 between the verifier 12 and the 5 subscriber 16. A subscriber 16 in this embodiment is assumed to have legitimate ownership 6 of the core identification numbers protected by the core ID level 70 upon subscribing. It is 7 generally known that to obtain credit cards, bank accounts etc., a person typically needs to 8 present at least one piece of identification which would be associated with a core set of 9 identification numbers. For instance, to sign up for a credit card, the issuing institution would 10 typically ask for a social insurance number and driver's license number. Since these 11 identification numbers are preferably those which are designated as core identification 12 numbers by the alert system 14, the linked ID level 72 may use the core ID level 70 to add 13 additional identification numbers to a subscriber's account. However, the linked ID level 72 14 preferably initiates this operation through the verifier 12. 15 [00107] A procedure 2000 for linking a subscriber's other identification numbers with 16 their core identification numbers is shown in Figure 20. As mentioned above, the linked ID 17 level 72 preferably operates upon registration of the core identification numbers 2002. In this 18 case, the subscriber's account utilizes the real-time alert service level 74 and as such, their 19 core identification continues to utilize the basic protection 2004. It is preferable for the 20 linked ID level 72 to receive a set of account numbers 2006 from a verifier 12 to enable 21 subscribers 16 to protect account numbers held by the verifier 12. In this scenario, it is 22 assumed that the verifier 12 has registered with the alert system 14. The alert system 14 23 would receive this list of account numbers using any suitable means, preferably by having 24 access to a database that is compatible with its existing database 40, and begin a matching 25 process 2008. 26 100108] In the preferred case, the database provided by the verifier 12 contains, for each 27 entry (wherein each entry represents a customer), encrypted versions of the account number, 28 and an encrypted version of at least one of the core identification numbers that would expect 29 to be stored at the core ID level 70. According to the secure communication channel 30 described above, the verifier 12 would, for example, use the API which they have obtained 31 upon registration to encrypt a database containing the entries listed above and send this -27- WO 2006/017937 PCT/CA2005/001265 1 encrypted version of the database to the alert system 14. This would ensure that the actual 2 identification numbers never become available and thus susceptible to fraudulent activity. 3 The alert system 14 would then receive the encrypted database and compare encrypted 4 versions of the core identification numbers with those stored in their database 40. The alert 5 system 14, for each entry, would determine whether or not the account number is linked to 6 existing core identification 2010. 7 [00109] If an entry does not match, the entry would preferably be placed in an unmatched 8 list 2012. This would allow the alert system 14 and/or the verifier 12 to determine which of 9 the verifier's customers do not use the alert system 14. The use of such entries will be 10 discussed later. 11 [00110] Upon matching an entry with a subscriber 16, the alert system 14 may notify the 12 subscriber 16 of the existence of the account in question 2014. A preferable way to notify the 13 subscriber 16 is to send an alert through the real-time alert service level 74 indicating that an 14 account (without divulging the actual number) exists with the applicable institution (the 15 verifier 12). The alert system 14 would preferably ask the subscriber 16 if they would like to 16 link this account number with their service (the subscriber 16 may be encouraged by the 17 verifier 12 to do this as well) wherein through the usual secure means described herein, the 18 subscriber 16 would be asked to enter the account number they know belongs to the account 19 in question 2016. 20 [00111] There may be the case, for example, that a large bank wants to verify their 21 customer's accounts and an account exists that has been opened under a false name. The 22 bank can then use the alert system 14 to not only audit their accounts but also to encourage 23 the use of the alert system 14 and even provide this as an added service to their customers. 24 [00112] The subscriber 16 may enter the account number in any suitable manner but 25 preferably this would take place through thealert system's secure website. This number may 26 be encrypted (if applicable) by the alert system 14, and compared 2018 to the account number 27 provided by the verifier 12. If the encrypted values are matched then the account number 28 known to the subscriber 16 is also the account known to the verifier 12 under the name of the 29 subscriber 16. Therefore since the subscriber 16 is known to be legitimately linked to the 30 core ID level 70, by entering the additional account number, they can verify that existing -28- WO 2006/017937 PCT/CA2005/001265 1 accounts are legitimate 2020. If the account number is legitimate, the alert system 14 would 2 preferably link this account number with the core ID level 70 by incorporating it into the 3 linked ID level 72. This account number can then utilize the real-time alert service level 74 4 to obtain live notification of the use of that account number (as described herein). The 5 subscriber 16 therefore may verify account numbers that exist or may have existed in the past 6 as well as accounts opened in their name without consent. In any case, using the herein 7 described secure communication channel, the verifier 12 is able to audit accounts and 8 likewise the subscriber 16 may perform an audit of accounts that may be linked to their core 9 identification. 10 [00113] If the account number entered by the subscriber 16 does not match the account 11 number provided by the verifier 12, the subscriber 16 may be given the opportunity to contact 12 the verifier 12 to investigate the existence of the account 2024. If a subscriber 16 has more 13 than one account with a particular institution, they may be given the option to enter all known 14 account numbers with that institution to avoid unnecessary "false alarms". 15 [00114] As shown in Figure 20, the process outlined according to steps 2010 - 2024 would 16 typically be repeated for each entry in the database provided by the verifier 12 so that each 17 customer they wish to audit is dealt with in turn by the alert system 14. 18 [00115] Step 2012 which involves placing unmatched entries into an unmatched list is 19 shown in greater detail in Figure 21. During the iterative procedure exemplified in Figure 20, 20 an unmatched account number would preferably be set aside 2100 by the alert system 14 for 21 later solicitation. Most preferably, a separate database of unmatched entries would be 22 generated and populated with these unmatched entries 2102. Upon completion of the 23 matching process 2008 (shown in Figure 20), the unmatched database may be used to notify 24 the verifier's customers to complete an audit of the account numbers that exist or to offer the 25 alert system's service thereto. The alert system 14 may then determine who may use this 26 unmatched database 2104. If the verifier 12 is willing to be responsible for notifying 27 unmatched customers, the unmatched database may be synchronized with the verifier 2106 to 28 ensure the verifier 12 obtains the necessary information to determine which of their 29 customers currently does not use the alert system 14. In this case they may wish to notify 30 these customers 2108 and encourage use of the alert system 14 as an added service, to 31 complete their audit of existing accounts, or for any other suitable reason. -29- WO 2006/017937 PCT/CA2005/001265 1 [00116] The verifier 12 may therefore form a partnership with the alert system 14 such that 2 in using the secure communication channel provided by the alert system 14, the verifier 12 3 can offer added service to their customers while promoting the use of real-time alerts for the 4 customer's benefit. In some cases, it would be most beneficial for the verifier 12 to 5 incorporate the use of the alert system 14 with their own service as a measure of security and 6 ultimately as a form of insurance. 7 [00117] If the alert system 14 is to be responsible for the unmatched entries, they may use 8 the database to contact potential subscribers to promote use of the system on behalf of 9 themselves or in partnership with the verifier 12 and other verifiers. 10 [00118] Using the security levels illustrated in Figure 19, a secure system is provided that 11 can be used to not only protect the most valuable core identification, but also to link other 12 identification to these core identification numbers to ensure the legitimacy of activity 13 associated with a person's name, core identification, other identification etc. A subscriber 16 14 can therefore determine accounts that may exist that they are not aware of or may have 15 forgotten about. The subscriber 16 may also link jurisdictional identification numbers such 16 as out-of-province/state driver's licenses to a core driver's license or different social security 17 numbers resulting from dual citizenship. Within the link ID level 72, there may also be sub 18 links such that a piece of identification can link to identification numbers in the link ID level 19 72 which in turn are linked to the core ID level 70. In any case, the chain of ownership of all 20 types of identification can be traced back to the legitimate owner, namely the subscriber 16. 21 A verifier 12 can also use the structure shown in Figure 19 to perform audits on accounts they 22 have or can offer the use of the alert system 14 as an added service or in a partnership to 23 promote the use of the alert system 14 with their customers. 24 [00119] In yet another embodiment, registration of subscribers 12 and verifiers 14 can be 25 performed by a notary 80 as shown in Figure 22. The notary 80 may be a lawyer or other 26 certified entity that is known by, and registered with the alert system 14. The notary 80 is 27 provided with a notary interface 82 that may comprise an API or be accessible through the 28 alert system's website. The use of registered notaries 80 localizes the point of entry for 29 subscribers 12 and verifiers 16 that wish to register with the alert system 14. The alert system 30 14 may then be confident that a legal means has been used to authenticate the identity of the -30- WO 2006/017937 PCT/CA2005/001265 1 entity wishing to register with the system, in an attempt to inhibit fraudulent use of the alert 2 system 14. 3 [00120] The use of a notary 80 also enables the creation of a notarized database 140 of 4 registered subscribers 12 that use the alert system 14. This notarized database 140 stores a 5 list of all encrypted identification numbers that have been registered through the legally 6 recognized notary 80. Any number of notaries 80 may be registered with the alert system 14, 7 and this may depend on, e.g., geographical convenience, co-marketing initiatives between the 8 notaries 80 and the alert system 14, etc. 9 [00121] The notary interface 82 may be any interface that enables the notary 80 to submit 10 a verification confirmation to the alert system 14, and that is capable of performing the 11 encryption function shown in Figure 3. The identification number is preferably encrypted 12 prior to submission thereof to the alert system 14, so that the encrypted version may be 13 compared with the encrypted version awaiting verification. This also helps to ensure that the 14 subscriber 16 has used a registered notary 80, since only registered notaries 80 are provided 15 access to the notary interface 82 by the alert system. 16 [00122] A notarized verification procedure 2300 is shown in Figure 23. The following 17 exemplifies the registration of a subscriber 16, however, it will be appreciated that a similar 18 procedure may be used to verify the identity of a verifier 12 and a notary 80. When a 19 verification of the subscriber 16 is requested 2302 during the registration procedure 702 20 described above, the alert system 14 may prompt the subscriber 16 to visit a registered notary 21 80 in order to complete the registration procedure 702. Preferably, once the subscriber 16 has 22 entered their information and chosen a username and password, the alert system 14 requests 23 that the subscriber 16 visit one of a provided list of registered notaries 80 and notifies the 24 subscriber 16 that their information may be held for a particular number of days (e.g. 3 25 business days) pending the submission of a verification confirmation by one of the notaries 26 80. 27 [00123] The subscriber 16 would then visit one of the registered notaries 80 at step 2304. 28 The notary 80 would typically require suitable confirmation of the identity of the subscriber 29 16, such as photo identification and proof of possession of the identification that the 30 subscriber 16 wishes to protect. When the notary 80 is satisfied that the identification -31- WO 2006/017937 PCT/CA2005/001265 1 number legally belongs to the subscriber 16, they "notarize" the identification of the 2 subscriber 16 at step 2306 by accessing the notary interface 82 and submitting a verification 3 confirmation at step 2308. This preferably includes the steps of logging onto the notary 4 interface 82 by loading an API or entering a password through a web interface, entering the 5 identification number with personal information related thereto, and executing submission of 6 the confirmation that includes an encryption of the identification number and transmission of 7 this encrypted version with the associated personal information to the alert system 14. 8 [00124] The alert system 14 would then receive the verification confirmation at step 2310, 9 which it can then check against pending registration attempts. Since the identification 10 number has been encrypted at both ends with the same encryption function 34, the notarized 11 confirmation would be accepted, and the alert system 14 would add the subscriber 16 to the 12 notarized database 140 at step 2312, by completing the registration procedure at step 2314. 13 [00125] In yet another embodiment, the alert system 14 may be used to provide a separate 14 service for monitoring the use of financial accounts such as credit cards and bank accounts. 15 Such a service may be provided to subscribers 12 who only wish to track the use of their 16 credit and debit cards, or wish to separate the monitoring of these cards from the monitoring 17 of core pieces of identification such as driver's licenses and passports. An example showing 18 the registration of a subscriber 16 for a separate credit card alert service is shown in Figure 24 19 and generally denoted by numeral 2400. 20 [00126] In this example, the subscriber 2402 chooses the credit card alert service option at 21 step 2404. This option may be provided through the alert system's website described above, 22 or through a separate website. The credit card alert service webpage would then load at step 23 2404 and the registration of the subscriber 16 would begin at 2406. Registration preferably 24 begins as described above. However, to verify that the credit card belongs to the subscriber 25 16, the alert system 14 would add a random charge to credit card at step 2408. The random 26 charge is preferably included as at least part of the registration fee, and is preferably a 27 random value within a predetermined range, e.g., between $4 and $5. 28 [001271 Once the random charge has been added to the credit card being registered, the 29 subscriber 16 would then be prompted to access their credit card statement to uncover the 30 exact amount of the random charge at step 2410. Once the subscriber 16 accesses their -32- WO 2006/017937 PCT/CA2005/001265 1 statement, and uncovers the amount of the random charge, they would enter this value at step 2 2412 to complete the registration of their credit card at step 2414. 3 [00128] For example, the alert system 14 may have charged $4.24 to the credit card being 4 registered. If the subscriber legitimately owns the credit card, they are able to access their 5 credit card statement online or when received by mail. This enables them to identify the 6 exact amount that was "randomly" charged to their credit card. The subscriber 16 would then 7 enter this amount (e.g. 4.24) to establish that they legally own the credit card, and to complete 8 the registration process. It will be appreciated that the verification of a bank account may be 9 accomplished using a random deposit which also requires the subscriber 16 to access account 10 information. 11 [00129] It will also be appreciated that the registration of the separate service may 12 alternatively be verified through the notary 80 at the time in which other identification is 13 being verified. This would bypass the random charge procedure 2400, and would verify the 14 subscriber 16 for both the standard monitoring service and the separate service for their 15 financial accounts at the same time. The random charge procedure 2400 may then be used 16 later to add another credit card or bank account number to the separate service. 17 [00130] Alternatively, the separate service may be implemented such that verifiers do not 18 need to have access to the alert system website or API. In such an implementation, the 19 identification numbers would not be encrypted at the verifier 12, but would be sent over a 20 secure connection, e.g. an SSL connection, to the alert system 14, wherein the identification 21 numbers would then be encrypted in order to compare with entries in the database 40 (or 22 140). This is preferably used for specific application such as verifying credit cards wherein 23 the SSL connection provides an adequate layer of protection, and enables non-registered 24 verifiers to use the alert system 14. 25 [00131] In yet another embodiment, the alert system 14 may track verification attempts 26 made by a verifier 12, using an identification (ID) mailbox 90 as shown in Figure 25. The ID 27 mailbox 90 sorts and stores records associated with verification attempts into a series of 28 accounts 92. Each account 92 is associated with a particular encrypted version of an 29 identification number, and maintains a list of verification attempts that have been made for 30 that identification number. -33- WO 2006/017937 PCT/CA2005/001265 1 [00132] A procedure for handling verification attempts using the ID mailbox 90 is shown 2 in Figure 26 and generally denoted by numeral 2600. For each a verification attempt made 3 by a verifier 12, the alert system 14 preferably receives this attempt in a message requesting 4 verification of an encrypted version of the identification number as described above (step 5 2602). In this embodiment, the encrypted version of the identification number is preferably 6 checked against the contents of the notarized database 140 at step 2604. The alert system 14 7 then determines whether or not the identification number belongs to a registered subscriber 8 16 at step 2606. If the received encrypted version of the identification number matches an 9 entry in the notarized database 140, an alert is generated and sent as usual at step 2608. A 10 record is then created of the verification attempt, and this record is added to the ID mailbox 11 account 92 that is associated with that particular subscriber 16 at step 2610. Preferably, an ID 12 mailbox account 92 is created upon registration of the subscriber, and thereafter, verification 13 attempt records are automatically added to the account 92. 14 [00133] If the received encrypted version of the identification number does not match an 15 entry in the notarized database 140, the ID mailbox is accessed and the alert system 14 16 checks for an existing account 92 that is associated with the encrypted version of the 17 identification number at step 2612. At step 2614, the alert system determines if an account 18 92 exists, and if so, a record of the verification attempt is added to that particular account 92. 19 If an account does not exist, a new ID mailbox account 92 is created and a record of this first 20 verification attempt is added to the mailbox at step 2618 and the alert system 14 then 21 continues its operations at step 2620. 22 [00134] The ID mailbox 90 provides an auditable record of verification attempts made by 23 a verifier 12. This may be valuable to the verifier 12 at a later time should they be 24 unwittingly implicated in a fraud, because a particular identification was used, through them, 25 by an unauthorized user. If the verifier 12 becomes involved in an investigation of the fraud, 26 they would possess a record showing that they attempted to alert the authorized holder of the 27 identification immediately, to prove that they were not an active participant in the fraudulent 28 activity. Since the ID mailbox 90 stores only encrypted versions of the identification 29 numbers, the anonymity of the subscriber would also not be compromised. 30 [00135] The ID mailbox 90 is also useful to subscribers 12 when registering with the alert 31 system 14. Once the subscriber 16 is verified, e.g., by a notary 80, they can access their ID - 34- WO 2006/017937 PCT/CA2005/001265 1 mailbox account 92 and reveal use of their identification prior to subscribing. This can be 2 checked against old statements or records to identify if there has been past fraudulent use of 3 that identification. 4 [00136] The records stored in the accounts 92 also help to prevent a registered subscriber 5 16 from participating in their own fraudulent scheme, such as that of claiming someone else 6 has used their credit card but it was in fact them. The records could show that the subscriber 7 16 was alerted to the use of the credit card and accepted that use. 8 [00137] In yet another embodiment, in addition to the contact information, a subscriber 16 9 may elect to have an important date stored in the database 140 (or 40). This date may then be 10 used by the alert system 14 to return a specific response to a query by a verifier 12. For 11 example, a birth date may be stored by the alert system 14 and associated with a particular 12 subscriber's identity. This birth date could then be returned to a verifier 12, either upon 13 request or automatically, in order to check the age of majority etc. as required. As another 14 example, the date of death may be stored in this manner to provide the verifier 12 with this 15 date, in an attempt to uncover fraudulent transactions that have occurred on or after the date 16 of death, which may be suspect. 17 [00138] In yet another embodiment, the system 10 may be used by subscribers 12 that act 18 on another's behalf (as described above), to monitor. only the identities of the deceased and/or 19 minors. Such a system may be implemented to provide accessibility to identity monitoring 20 for those who otherwise could not benefit from such services. This may enable any third 21 party, having the proper authority, to monitor their dependents' identification numbers. 22 [00139] An example may be a system 10 for monitoring the identities of the deceased. In 23 such an embodiment, the subscribers 12 would preferably be one of a relative, power of 24 attorney, or executor of the deceased's estate, although any third party having the proper 25 authority to act on their behalf may also be used. In this example, an executor of the 26 deceased's will can register with the alert system 14 in order to monitor the use of 27 identification belonging to the deceased. Since the identity of a deceased person should not 28 be used subsequent to the death of the individual, the executor may be able to track any 29 fraudulent use of their client's identification. Such a service would provide protection to the 30 family of the deceased individual as well as help to hinder the use of "expired" identification. -35- WO 2006/017937 PCT/CA2005/001265 1 It will be appreciated that this embodiment may be implemented using any of the above 2 described features as desired. For example, for tracking the identity of a deceased individual, 3 the system 10 may be implemented without storing encrypted versions of the deceased's 4 identification. 5 [001401 The above illustrates that the system 10 may be implemented in any number of 6 ways depending on the application. The system 10 enables the monitoring of identification 7 as well as secure communication between correspondents, and is preferably implemented 8 using a secure means for storing sensitive information and securely associating this sensitive 9 information with contact information for the particular correspondent. 10 [00141] Although the invention has been described with reference to certain specific 11 embodiments, various modifications thereof will be apparent to those skilled in the art 12 without departing from the spirit and scope of the invention as outlined in the claims 13 appended hereto. The entire disclosures of all references recited above are incorporated 14 herein by reference. -36.

Claims

What is claimed is:

1. A method of identity monitoring comprising the steps of:

a notification system storing identification information and contact information for each of at least one subscriber, said identification being stored in a secure manner;

said notification system receiving a query from a verifier indicative of the use of queried identification information;

said notification system using said query to retrieve contact information corresponding to said queried identification information if said queried identification information corresponds to one of said at least one subscriber; and

if retrieved, said notification system using said contact information to notify said one of said at least one subscriber of the use of said queried identification information.

2. The method of claim 1 wherein said notification system stores an encrypted version of said identification information.

3. The method of claim 2 wherein said encrypted version is computed using a one-way hash function.

4. The method of claim 3 wherein said hash function comprises a plurality of fields, each of which corresponds to a portion of said identification information.

5. The method of claim 4 comprising three fields corresponding to an identification issuer, an identification type and an identification number respectively.

6. The method of claim 1 wherein said contact information is one or more of an email address and telephone number.

7. The method of claim 1 wherein said query is received through an interface accessible by said verifier, and upon receiving said query said interface altering said identification information to match a representation thereof as securely stored by said notification system.

8. The method of claim 1 wherein prior to said notification system securely storing said identification information, the identity of said at least one subscriber is verified through a verification entity in order to register said at least one subscriber with said notification system.

9. The method of claim 8 wherein said verification entity is a notary, said notary being registered with said notification system, and said identification information and said contact information being stored by said notification system in a notarized database.

10. The method of claim 1 further comprising the step of said notification system generating a record of said query and storing said record in a mailbox, said mailbox containing an account corresponding to said second correspondent.

11. The method of claim 10 wherein if said contact information is not retrieved, a record of said query is stored in an account in said mailbox that corresponds to a non- subscriber.

12. The method of claim 11 wherein said non-subscriber gains access its respective account upon becoming one of said at least one subscriber.

13. The method of claim 1 wherein said identification information corresponds to a credit card, and prior to said notification system securely storing said identification information, the identity of each of said at least one subscriber being verified by said notification system applying a random charge to said credit card, having each of said at least one subscriber uncover said random charge by accessing personal records corresponding to said credit card, and prompting each of said at least one subscriber to enter a value indicative of said random charge.

14. The method of claim 1 wherein said identification information corresponds to a financial account, and prior to said notification system securely storing said identification information, the identity of each of said at least one subscriber being verified by said notification system applying a random deposit to said financial account, having said at least one subscriber uncover said random deposit by accessing personal records corresponding to said financial account, and prompting each of said at least one subscriber to enter a value indicative of said random deposit.

15. The method of claim 1 wherein said identification information corresponds to an access card, said notification system notifying said one of said at least one subscriber of the use of said access card for obtaining access to a building.

16. The method of claim 1 wherein said verifier is another of said at least one subscriber and upon said step of notifying said one of said at least one subscriber comprises sending a message indicative of the desire of said another of said at least one subscriber to securely exchange correspondence with said one of said at least one subscriber.

17. The method of claim 1 wherein said query includes a message having identification information corresponding to each of a plurality of subscribers, said notification system using said query to retrieve contact information corresponding to said identification information if said identification information corresponds to at least one of said plurality of subscribers, and said notification system sending said message to each retrieved contact information.

18. A notification system for identity monitoring comprising:

a storage device for storing identification information and contact information for each of at least one subscriber, said identification information being stored in a secure manner;

an interface adapted to enable a verifier to submit a query indicative of the use of queried identification information; and

a server connected to said interface and said storage device, said server capable of receiving said query from said interface and transmitting a notification message to each of said at least one subscriber over a communication channel, said server using said query to retrieve contact information corresponding to said queried identification information if said queried identification information corresponds to one of said at least one subscriber; and if retrieved, said server using said contact information to notify said one of said one of said at least one subscriber of the use of said queried identification information.

19. The system of claim 18 wherein said notification system stores an encrypted version \ of said identification information.

.

20. The system of claim 19 wherein said encrypted version is computed using a one-way hash function.

21. The system of claim 20 wherein said hash function comprises a plurality of fields, each of which corresponds to a portion of said identification information.

22. The system of claim 21 comprising three fields corresponding to an identification issuer, an identification type and an identification number respectively.

23. The system of claim 18 wherein said contact information is one or more of an email address and telephone number.

24. The system of claim 18 wherein said interface is adapted to alter said identification information to match a representation thereof as securely stored by said notification system.

25. The system of claim 18 further comprising a registration interface, said registration interface being used by a verification entity for verifying the identity of said at least one subscriber in order to register said at least one subscriber with said notification system.

26. The system of claim 25 wherein said verification entity is a notary, said notary being registered with said notification system.

27. The system of claim 18 further comprising a mailbox and wherein said server generates a record of said query and stores said record in said mailbox, said mailbox containing an account corresponding to each of said at least one subscriber.

28. The system of claim 27 wherein if said contact information is not retrieved, a record of said query is stored in an account in said mailbox that corresponds to a non- subscriber.

29. The system of claim 28 wherein said non-subscriber may gain access to its respective account upon becoming one of said at least one subscriber.

30. The system of claim 18 wherein said identification information corresponds to a credit card, and said server verifies said credit card by said server applying a random charge to said credit card, having each of said at least one subscriber uncover said random charge by accessing personal records corresponding to said credit card, and prompting each of said at least one subscriber to enter a value indicative of said random charge.

31. The system of claim 18 wherein said identification information corresponds to a financial account, and said server verifies said financial account by applying a random deposit to said financial account, having said at least one subscriber uncover said random deposit by accessing personal records corresponding to said financial account, and prompting each of said at least one subscriber to enter a value indicative of said random deposit.

32. The system of claim 18 wherein said identification information corresponds to an access card, said server notifying said one of said at least one subscriber of the use of said access card for obtaining access to a building.

33. The system of claim 18 wherein said verifier is another of said at least one subscriber and upon notifying said one of said at least one subscriber, said server sends a message indicative of the desire of said another of said at least one subscriber to securely exchange correspondence with said one of said at least one subscriber.

34. The system of claim 18 wherein said query includes a message having identification information corresponding to each of a plurality of subscribers, said notification system using said query to retrieve contact information corresponding to said identification information if said identification information corresponds to at least one of said plurality of subscribers, and said notification system sending said message to each retrieved contact information.

35. A method of monitoring information belonging to a first correspondent by a second correspondent, said second correspondent having permission to act on behalf of said first correspondent, said method comprising the steps of:

a notification system storing said information belonging to said first correspondent and contact information belonging to said second correspondent; said notification system receiving a query from a third correspondent indicative of the use of queried information;

said notification system using said query to retrieve said contact information if said queried information equals said information belonging to said first correspondent; and

if retrieved, said notification system using said contact information to notify said second correspondent of the use of said information.

36. The system of claim 35 wherein said first correspondent is deceased.

37. A system for monitoring information belonging to a first correspondent by a second correspondent, said second correspondent having permission to act on behalf of said first correspondent, said system comprising:

a storage device for storing said information belonging to said first correspondent and contact information belonging to said second correspondent;

an interface adapted to enable a third correspondent to submit a query indicative of the use of queried information; and

a server connected to said interface and said storage device, said server capable of receiving said query from said interface and transmitting a notification message to said second correspondent over a communication channel, said server using said query to retrieve said contact information if said queried information equals said information belonging to said first correspondent; and if retrieved, said server using said contact information to notify said second correspondent of the use of said queried information.