CA2264912C - Method and system for establishing and maintaining user-controlled anonymous communications - Google Patents

Abstract

A system for establishing anonymous communications includes a plurality of party terminals (300), a plurality of requestor terminals (400), and a central controller (200). The system receives and stores party data about respective parties. Upon receiving criteria for parties of interest from a requestor terminal (400) and authorization from respective parties, the central controller (200) releases to the requestor party associated with the parties.
The system also establishes communication channels between parties and the requestor, while maintaining their anonymity. Communications are through the public switched telephone network (110).

Description

WO 98/1055810152025CA 02264912 1999-03-05PCT/US97/ 15320- 1 -METHOD AND SYSTEM FOR ESTABLISHING AND MAINTAININGUSER-CONTROLLED ANONYMOUS COMMUNICATIONSR UN OF IN ENTIONField of the inventionThe present invention relates to establishing anonymous communicationsbetween two or more parties. More specifically, the invention relates to controllingthe release of confidential or sensitive information of at least one of the parties inestablishing anonymous communications.Description of the Related ArtThe need for anonymous communications can be found in everyday situations.Police hotlines solicit tips from the public to help solve a crime, often withoutrequiring callers to give their names. Cash rewards are often offered for the return ofmissing items with no questions asked.One form of anonymity involves "shielded identity," where a trusted agentknows the identity of a masked party, but does not reveal that identity to others exceptunder very special circumstances. Unless otherwise specified, the tenn "anonymity“is used throughout this application interchangeably with the notion of shieldedidentity.Shielded identity appears in a wide range of useful and commercial functions.A company might run an employment advertisement in a newspaper with a blindP.O. box known only to the publisher. A grand jury could hear testimony fiom awitness whose identity is known only to the prosecutor and the judge, but is concealedfrom the jurors, the accused, and opposing counsel. A person could identify acriminal suspect from a lineup of people who carmot see him. A recruiter couldcontact potential candidates for a job opening without revealing the client's name.Witness protection programs are designed to shield the true identity of witnessesenrolled in the programs. A sexual harassment hotline could be set up for victims ofsexual harassment to call in with their complaints, while promising to protect thecallers‘ identities. iThe above examples illustrate the need for anonymity or shielded identity dueW0 98/105581015202530CA 02264912 1999-03-05PCT/U S97/15320- 2 _to a fear of exposure. The need for anonymity can also be motivated by a desire forprivacy. For instance, donors may wish to make an anonymous charitablecontribution, an adoption agency typically shields the identity of a child's birthmother, a Catholic confessional offers anonymous unburdening of the soul, and localphone companies maintain millions of unlisted telephone numbers accessible only byspecial operators.The concepts of anonymity and shielded identity do not lend themselves toconventional communication systems. While it is possible to send and receiveanonymous messages, such as a postcard with no return address or a call placed froma pay phone, it is difficult for parties engaged in multiple communication episodes toremain anonymous from one another. In general, conventional communicationsystems are premised upon the notion that communicating parties know each other's 'identity. For the purposes of this invention, the term "communications system‘? refersto any system that facilitates an ongoing cycle of messages and responses.Most current communications systems, whether written or oral, do not permitan ongoing, multi-party, shielded identity dialogue. For example, letters need anaddress to be delivered, calling someone on the phone requires a phone number, andmeeting face-to-face provides for visual identification. The process involved in mostongoing communication systems is simply not conducive to retaining concealedidentities.Yet, in some cases, concealing identity can actually encourage or facilitatecommunication between unwilling or cautious parties. For example, a partynegotiating a peace treaty with another may be unwilling to reveal his identitybecause, if the negotiations fail, that party might be exposed or subjected to potentialblackmail.One specific example of the need for concealing identities is in theemployment search process, where the release of the name of the hiring company (orthe position involved) could be damaging to the company. The hiring company mightbe concerned about how potential competitors would use the knowledge that thecompany is searching for employees to upset customers who are relying on thestability of the company. Mere speculation that a company is searching for a newW0 98/ 105581015202530CA 02204912 1999-03-05PCT/US97/15320_ 3 _president could dramatically reduce the price of the company's stock. To findpotential candidates for the vacant position, the company could engage anemployment search firm to discretely find potential candidates without disclosing tothe market, or even potential candidates, the company's identity until the companydecides to confide in or hire a particular candidate.In engaging such employment search firms, however, a hiring company entailssome risk that the search firm will prematurely or indiscriminately reveal thecompany's identity to a potential candidate. Search firms are generally compensatedbased upon the number of successful placements, and thus are motivated to makevacant positions appear as attractive as possible to potential candidates. In doing so,search finns could be tempted to reveal enough information about the company forpotential candidates to discover the identity of the company, or, for that matter, thefirms may reveal the company's identity itself. Accordingly, hiring companies cannotbe counted upon to maintain effective control of what information is released topotential candidates, and thus are unable to instill any satisfactory degree ofconfidence in their clients about the confidential status of their search for jobreplacements.The use of search firms also creates inefficiencies. In dealing with a searchfirm, candidates looking for a new job may engage in a dialogue with the search firm,asking a series of detailed questions about the particular job, company expectations,various qualification criteria, benefits, options, perks, and other factors, all without thecandidate knowing the name of the hiring company. In response, the search firm mayreveal, from general to specific, information about the hiring company. For instance,in response to questions, the search firm may successively reveal that the hiringcompany is a Fortune 500 company, a transportation company, an airline,headquartered in the Midwest, and, finally, that it is United Airlines. In return, thecandidate may also authorize the search firm to release information about itself. Forinstance, the search firm may disclose that the candidate is employed at a smallsoftware company, that he is the head of a software development group of sevenprogrammers, then that he is earning $75,000 plus a $20,000 bonus in his current job,then that he is located in the Stamford, CT area and then finally his identity.W0 98/ 105581015’202530CA 02264912 1999-03-05PCT/US97/ 15320_ 4 -From the outside, these actions may appear to be a type of "dance," whereeach party seeks to learn the necessary information to keep the process movingforward. To answer any difficult questions, the search firm, trusted by both parties,facilitates an assisted dialogue between the candidate and the company.By creating this additional layer in the communication process, however, theamount of effort and expense incurred by the hiring party and the candidatesincreases. Further, using such a search firm creates delays in communicatinginformation between the company and the candidates and increases the likelihood thatmisunderstandings may occur.In addition, the success of a search firm to fill a position is limited by thenumber of candidates that the search firm contacts. Search firms may target onlycertain individuals while overlooking many other qualified candidates who, ifcontacted, would have been very interested in considering the available positions. Assuch, search firms often do not reach a large pool of potential candidates. Searchfirms also know that the candidates most qualified for jobs are those that are currentlyemployed. Recruiters would love to be able to show these coveted employees evenbetter opportunities. Unfortunately, search firms have no way of identifying andcontacting these prime candidates. Present systems for recruiting typically rely on thecandidate to present himself to the recruiter - at a substantial risk to the employee. Nosystem currently gives an employee the incentive and protection he needs to feelcomfortable submitting his resume.Another area in which shield identity may be desirable is dating. For example,a person could serve as a match-maker _by setting up two people with whom he isacquainted on a blind date. Before agreeing to go on the date, each acquaintance mayask the match-maker questions about the other person and instruct the match-makernot to reveal his/her identity without prior authorization. Once each of theacquaintances feels comfortable about the other person, he/she may authorize thematch-maker to reveal his/her identity and agree to the date.Again, however, the use of match-makers suffers from the same drawbacks asthe search firms. There is little or no control over what information match—makersdisclose. For instance, a match-maker may feel greater loyalty to one of theW0 98/ 105581015202530CA 02204912 1999-03-05PC'I‘/US97/ 15320- 5 -acquaintances and willingly divulge the identity of the other acquaintance. Also,using match-makers slows down the communication process and can result inmiscommunication. Finally, the number of people that a match-maker can set up islimited by the number of people to whom the match—maker is acquainted.Attempts have been made to automate the employment search process andmatchmaking process. For instance, U.S. Patent No. 5,164,897 discloses anautomated method for selecting personnel matching certain job criteria. Databasesstoring employee qualifications are searched to identify which personnel havequalifications matching search criteria. Such a system, however, does not provideanonymous communications between the employer and the employee and does notprovide control over the release of information stored within those systems to others.Thus, there is a need for a system that allows users to exercise control over the releaseof information to others and that provides efficient anonymous communication.SUMMARY QF ILHE INVENTJQI3Accordingly, the present invention is directed to a communications methodand system that obviates problems due to limitations and disadvantages of the priorart.A goal of the invention is to provide a communication system incorporating acentral database of information supplied by one or more of parties and managed by acentral administrator, where all parties to the system can manage and control therelease of any or all information about themselves or their identities, and where such asystem allows for electronic-based communications between the parties without thenecessity of revealing the identity of either party.Another goal of the invention to allow parties to submit criteria for searching atrusted agent's confidential database and receive a count of the number of records thatsatisfy the criteria, without revealing the identities of the parties associated with thoserecords.A further goal of the invention is to allow a system administrator to send arequest for authorization to release information about a party to a searching party.Other goals of the invention are to provide a system that encryptscommunications between parties to maintain the anonymity of the parties; toW0 98/ 1055810I5202530CA 02264912 1999-03-05PCT/U S97! 15320_ 6 _authenticate searchable information contained in a central database for release toparties; to allow one or both parties to receive compensation for contributing ormaintaining information accessible in a database; and to allow one party to apply acustomized scoring algorithm to information contained about other parties in adatabase. .Still other goals of this invention are to provide a system for a trusted agent toact as an anonymous remailer or communicate via e-mail or other electronic meanswith specific outside parties requested or identified by one of the parties to validateinformation about the parties.Yet another goal of the invention is to be able to store and authenticate suchinformation that may be provided by outside parties in a central database whileallowing the outside parties to retain control over the release of respective informationto other parties.This invention meets these goals by allowing a party to maintain effectivecontrol over the timing and release of certain information stored in a database,including the party's identity and other relevant data about the party, to another party.This controlled release of identity can be performed gradually in a series of stepswhere the party authorizes release of more and more information. The invention alsoauthenticates information stored in the database before releasing the information,thereby improving the reliability of the released information. Finally, the inventionestablishes a communications charmel between a party and a requestor while notnecessarily revealing the identity of the party and/or the requestor to each other. Thecontrolled release of information in the invention allows for new improvements in thequality of the communication process when one party to the process would suffersignificant costs or be exposed to significant risks if their identity were releasedprematurely or indiscriminately.To achieve these and other objects, and in accordance with the purposes of theinvention, as embodied and broadly described, one aspect of the invention includes amethod for providing the controlled release of information in a communicationsystem. In this method, party data corresponding to at least one party is securelymaintained in the system. A request for party data that is securely maintained in theWO 98/105581015202530CA 02264912 1999-03-05PCT/US97/ 15320_ 7 _system is received from a requestor. Each party is queried to specify which respectiveparty data the system is authorized to release to a requestor. Only the requested partydata that respective parties have authorized the system to release is transmitted to therequestor, while the anonymity of the respective parties is maintained.In another aspect, the invention includes an apparatus for providing thecontrolled release of information. This apparatus includes a device for securelymaintaining party data corresponding to at least one party; a device for receiving,from a requestor, a request for party data contained in the means for securelymaintaining party data; a device for querying each party to specify which respectiveparty data is authorized for release; and a device for transmitting to the requestor onlythe requested party data that respective parties have authorized for release, whilesecurely maintaining the anonymity of the respective parties.QRIEE DESQRIPTIQN OF TEE DRAWINQSThe accompanying drawings provide a fiirther understanding of the inventionand are incorporated in and constitute a part of this specification. The drawingsillustrate preferred embodiments of the invention, and, together with the description,serve to explain the principles of the invention.In the drawings:Fig. 1 illustrates one embodiment of the present invention;Fig. 2A illustrates a block diagram of the central controller of the system inaccordance with the embodiment in Fig. 1;Fig. 2B illustrates the contents of a party data database and a requestor datadatabase in accordance with the embodiment in Fig. 1;Fig. 2C illustrates the contents of a verification database and an accountdatabase in accordance with the embodiment in Fig. 1;Fig. 3 illustrates a block diagram of a party terminal in accordance with theembodiment in Fig. 1;Fig. 4 illustrates a block diagram of a requestor terminal in accordance withthe embodiment in Fig. 1;Fig. 5 illustrates a flow diagram of a preferred method for establishinganonymous communications in accordance with this invention;W0 98/ 105581015202530CA 02264912 1999-03-05PCT/US97/15320_ 3 _Figs. 6A-6B illustrate a flow diagram of a preferred method for searching forand releasing party data in accordance with this invention;Fig. 7 illustrates a flow diagram of a preferred method for verifying theauthenticity and accuracy of party data in accordance with this invention;Fig. 8 illustrates a flow diagram of a preferred method for opening acommunications channel between a party and a requestor in accordance with thisinvention; andFig. 9 illustrates a detailed flow diagram of a preferred method for transmittingparty and requestor information in a communications channel in accordance with thisinvention.‘ DETAILED QESCRIPTION OF THE INVEETIONSystem StructureFig. 1 illustrates one embodiment of an anonymous communication system100 according to this invention. System 100 identifies parties having characteristicsof interest to a requestor, releases certain infonnation about the identified parties tothe requestor with authorization fiom the parties, releases certain information aboutthe requestor to the identified parties with authorization from the requestor, andprovides a communications channel between the identified parties and the requestorwhile maintaining their anonymity. For example, system 100 can be used to allow anemployer (the requestor) to communicate with prospective candidates (the parties)whose background satisfies employment criteria provided by the employer withoutrevealing the identity of the employer or the identities of the candidates. In a specificexample, a software company may want to hire a programmer with 5+ yearsexperience in writing C++, who is willing to live in Seattle, who will work 12-14 hourdays 6 days a week, who will work for between $100,000 to $150,000 in salary plusbonuses, and who wants the opportunity to work for a startup with stock options in apublicly-traded company that could effectively double his salary. System 100 couldidentify a dozen candidates from resumes stored in a database, release informationabout these candidates only as authorized to the company, and deliver messagesbetween the company and candidates without the company ever knowing thecandidates identities. Although the invention can be used in connection with otherWO 98/105581015202530CA 02264912 1999-03-05PCT/U S97/ 15320- 9 _applications, for the purpose of illustration, the employment search example is usedthroughout the specification to describe the invention.System 100 includes a public switched phone network 110, a central controller200, party terminals 300, and requestor terminals 400. Central controller 200, partyterminals 300, and requestor terminal 400 preferably connect to network 110 throughrespective two-way communication links. Parties (e.g., candidates) access system 100through respective party terminals 300, and a requestor (e.g., an employer) accessessystem 100 through requestor terminal 400. The flow of data from terminals 300 and400 is preferably limited and controlled by central controller 200.Under the control of central controller 200, public switched telephone network110 routes data to and from central controller 200, party terminals 300, and requestorterminal 400. In a preferred embodiment, network 110 comprises acommercially-implemented network of computer-controlled telephone switchesoperated by, for example, a telephone company. Network 110 may also includecommunication networks other than a public switched telephone network, such as awireless telephone network, a paging network, or the Internet.Central controller 200 controls the flow of data to and from party terminals300 and requestor terminal 400. Preferably, central controller 200 stores andauthenticates the authorship of "party data" and "requestor data" received from partyterminals 300 and requestor terminal 400, respectively. “Party data" comprises dataabout or corresponding to a respective party. "Requestor data" comprises data aboutor corresponding to the requestor. In the employment search example, party datawould include infonnation that may be of interest to an employer about respectivecandidates, such as a candidate's identity, the candidate's address, the candidate's vitalstatistics, the candidate's work experience, the candidate's educational background,and the candidate's interests.In one embodiment used with an employment system, each party fills out anelectronic form that gets converted into an HTML format. This presents the party’semployment history as a “hyper-resume.” When released to a requestor, this resumeallows the requestor to get more information about certain areas of a party's history.The hyper-links can point to additional text, QuickTime video, JPG photos or audioW0 98/ 105581015202530CA 02264912 1999-03-05PCT/US97/15320- _clips, allowing for a rich presentation of information about the party. Requestor datawould include information about the employer, such as the employer's identity, thenumber of its employees, the locations of its offices, the industry in which theemployer operates, the positions available and their job descriptions, fiscalinformation about the employer, and the history of the employer. The requestor data iscollected and stored using similar techniques to those outlined above for anemployee’s employment history.In addition, central controller 200 controls the release of requestor data and _party data that the requestor and respective parties, respectively, have authorized forrelease. Central controller 200 also establishes a communications channel betweenparty terminals 300 and requestor terminal 400, while maintaining the anonymity ofthe parties using party terminals 300 and the requestor using requestor terminal 400.The structure of controller 200 is described in greater detail below in connection withFig. 2A.Party terminal 300 provides a party with an interface to system 100.Preferably, party terminal 300 allows a party to enter party data and transmits it tocentral controller 200 via network 110. Party terminal 300 also allows a party toindicate which of the entered party data system 100 is authorized to release to arequestor, view requestor data, and communicate anonymously with the requestor atrequestor terminal 400. The structure of party terminal 300 is described in greaterdetail in connection with Fig. 3.Requestor tenninal 400 provides a requestor with an interface to system 100.In a preferred embodiment, requestor terminal 400 allows a requestor to enterrequestor data and transmits the requestor data to central controller 200 via network110. Requestor terminal 400 also allows a requestor to enter search criteria aboutparties of interest, to indicate which of the entered requestor data system 100 isauthorized to release to a particular party, view party data, and communicate withparties at party terminals 300. The structure of requestor terminal 400 is described ingreater detail in connection with Fig. 4.Fig. 2A illustrates a block diagram of central controller 200. As shown in Fig.2A, central controller 200 includes CPU 205, cryptographic processor 210, RAM 215,WO 981105581015202530CA 02264912 1999-03-05PCT/US97/ 15320_ 1 1 _ROM 220, network interface 245, and data storage device 250. Data storage device250 includes a plurality of databases, including party data database 255, requestor datadatabase 260, verification database 270, and account database 275, as well as programinstructions (not shown) for CPU 205. CPU 205 is connected to each of the elementsof central controller 200.The databases in data storage device 25 O are preferably implemented asstandard relational databases capable of supporting searching and storing multimediainformation such as text, video, QuickTime movies, photographs, and audio. Fig. 2Billustrates exemplary record layouts for party data database 255 and requestor datadatabase 260, and Fig. 2C illustrates record layouts for verification database 270 andaccount database 275. Each record layout preferably comprises a two-dimensionalarray of information with one colurrm for "Field Name" and another column for "FieldCharacteristic." The rows correspond to respective fields.The "authorization profile" field 256 preferably comprises a list of rules forreleasing party or requestor data. For example, the rules could simply include a list ofcompanies to which party data is not to be released, or include characteristics ofcertain companies to which party data can be released, such as companies that are inthe Fortune 500 and have stock option plans.Verification database 270 preferably includes cross—referencing fields (notshown) to party data database 255 and requestor data database 260. This allowsindexing by verified information as well as other types of searches.CPU 205 executes program instructions stored in RAM 215, ROM 220, anddata storage device 250 to perform various functions described in connection withFigs. 5-9. In a preferred embodiment, CPU 205 is programmed to maintain data,including party data and requestor data, in storage device 250. CPU 205 receivesparty data and requestor data from network 110 through network interface 245 andstores the received party data and requestor data in databases 255 and 260,respectively. CPU 205 is also programmed to receive and store information in partydatabase 255 and requestor database 260 indicating which of the party data andrequestor data respective parties and requestors have authorized for release. Uponreceipt of a request for authentication, CPU 205 transmits a verification request to aWO 98/105581015202530CA 02264912 1999-03-05PCT/U S97/15320- 12 _verification authority to authenticate the origin, authorship, and integrity of the partydata and requestor data stored in databases 255 and 260, respectively, and maintains arecord of the verification request in database 270.CPU 205 is also preferably programmed to search databases 255 and 260 andtransmit information in response to the search. CPU 205 receives a search requestcontaining certain criteria and searches the databases of storage device 250 to findmatches. Based upon the search, CPU 205 releases certain information to therequestor and the parties. Also, CPU 205 preferably assigns pseudonyms to eachparty and requestor, and stores the pseudonyms in databases 255 and 260,respectively. The pseudonyms can include coded identifiers, web page addresses,bulletin board addresses, pager numbers, telephone numbers, e—mail addresses, voicemail addresses, facsimile telephone numbers, and postal mail addresses.CPU 205 receives search criteria pertaining to parties of interest to therequestor and searches database 255 to identify parties whose party data satisfies thesearch criteria. There are a number of search techniques that can be used includingkeyword, firzzy logic, and natural language search tools. For example, an employercould search for candidates with the following criteria: "two years of patent writingexperience and lives in New England." CPU 205 compares the criteria against eachparty registered with the system using one or more search algorithms and transmits tothe requestor the number of parties identified. If CPU 205 receives a request for partydata corresponding to the identified parties, CPU 205 transmits to requestor terminal400 the party data that the identified parties previously authorized for release alongwith respective pseudonyms. CPU 205 can also transmit queries to party terminals300 inquiring whether respective parties authorize the release of additional party data.If CPU 205 receives a request for requestor data from a party, CPU 205 transmits tothe appropriate party terminal 300 the request data that the requestor previouslyauthorized for release, along with a pseudonym corresponding to the requestor.CPU 205 is preferably also programmed to provide an anonymouscommunications charmel between party terminals 300 and requestor terminal 400.CPU 205 receives a request for an anonymous communications channel along with apseudonym of a party and a requestor. In one embodiment, CPU 205 establishesW0 98/105581015202530CA 02264912 1999-03-05PCT/US97l15320-13-either a rea1—time or non-real-time communications channel between the party and therequestor corresponding to the received pseudonyms. For example, CPU 205 couldtransmit control signals to configure network 110 to provide a direct telephoneconnection between the party and the requestor at their respective terminals 300 and400, thereby establishing a real-time communications channel. In another example,CPU 205 could receive and store electronic mail messages in electronic mailboxesassigned to the party and the requestor for their retrieval, thereby establishing anon-real-time communications channel.CPU 205 preferably comprises a conventional hi gh-speed processor capable ofexecuting program instructions to perform the functions described herein. Althoughcentral controller 200 is described as being implemented with a single CPU 205, inalternative embodiments, central controller 200 could be implemented with a pluralityof processors operating in parallel or in series.RAM 215 and ROM 220 preferably comprise standard commercially-availableintegrated circuit chips. Data storage device 250 preferably comprises static memorycapable of storing large volumes of data, such as one or more floppy disks, hard disks,CDS, or magnetic tapes.Network interface 245 connects CPU 205 to network 110. Interface 245receives data streams from CPU 205 and network 110 formatted according torespective communication protocols. Interface 245 reformats the data streamsappropriately and relays the data streams to network 110 and CPU 205, respectively.Interface 245 preferably accommodates several different communication protocols.Cryptographic processor 210 is programmed to encrypt, decrypt, and Aauthenticate the stored data in each of the databases described above. Cryptographicprocessor 210 encrypts and decrypts data received by and transmitted from CPU 205.In a preferred embodiment, all party data and requestor data are encrypted beforebeing transmitted onto network 110. Also, processor 210 encrypts the data beforeCPU 205 transmits such data via network 110. Any encrypted data received by CPU205 is decrypted by processor 210. The cryptographic protocols used bycryptographic processor 210 a described below in the section entitled "CryptographicProtocols."W0 98/ 105581015202530CA 02264912 1999-03-05PCT/US97/15320- -Fig. 3 illustrates a block diagram of party terminal 300, according to oneembodiment of the invention. Party terminal 300 includes CPU 305, which isconnected to RAM 310, ROM 315, video driver 325, cryptographic processor 335,communication port 340, input device 345, and data storage device 360. Videomonitor 330 is connected to video driver 325, and modem 350 is connected tocommunication port 340 and public switched phone network 110.CPU 305 executes program instructions stored in RAM 310, ROM 315, andinformation storage 370 to carry out various functions associated with party terminal300. In a preferred embodiment, CPU 305 is programmed to receive data from inputdevice 345, receive data from communication port 340, output queries and receiveddata to video driver 325 for display on video monitor 330, and output data tocommunication port 340 for transmission by modem 350. CPU 305 preferablytransmits the data to cryptographic processor 335 for encryption before outputtingdata to communication port 340 for transmission to network 110. When CPU 305receives encrypted data, CPU 305 transmits the encrypted data to cryptographicprocessor 335 for decryption.CPU 305 preferably comprises a high-speed processor capable of performingthe functions described herein. RAM 310 and ROM 315 comprise standardcommercially—available integrated circuit chips. Information storage 370 comprisesstatic memory capable of storing large volumes of data, such as one or more of floppydisks, hard disks, CDs, or magnetic tapes. Information storage 370 stores programinstructions and received data. ’Video driver 325 relays received video and text data from CPU 305 to videomonitor 330 for display. Video monitor 330 is preferably a high resolution videomonitor capable of displaying both text and graphics. Cryptographic processor 335encrypts and decrypts data in accordance with conventional encryption/decryptiontechniques and is preferably capable of decrypting code encrypted by cryptographicprocessor 210. Communication port 340 relays data between CPU 305 and modem350 in accordance with conventional techniques. Modern 350 preferably comprises ahigh-speed data transmitter and receiver. Input device 345 comprises any data entrydevice for allowing a party to enter data, such as a keyboard, a mouse, a video camera,W0 98l105581015202530CA 02264912 1999-03-05PCTIUS97l15320- 15 _or a microphone. The operation of party terminal 300 is described in greater detail inconnection with Figs. 5-9.Fig. 4 illustrates a block diagram of requestor terminal 400 according to theinvention. Terminal 400 in Fig. 4 includes CPU 405, which is connected to RAM410, ROM 415, video driver 425, cryptographic processor 435, communication port440, input device 445, and data storage device 460. Video monitor 430 is connectedto video driver 425, and modem 450 is connected to communication port 440 andpublic switched telephone network 110.Terminals 300 and 400 are shown in Figs. 3 and 4 to be structurally similar,though different reference numerals are used. As such, a more detailed description ofterminal 400 can be obtained by referring to the above description of terminal 300. Ina preferred embodiment, however, terminals 300 are used by parties, whereas terminal400 is used by a requestor.Qryptographic ProtocolsAs described above, system 100 encrypts data before transferring such databetween system users (including both parties and requestors) and central controller200, thereby providing various levels of security and privacy protection. As usedthroughout this section, the term "users" refers to both parties and requestors. A bookentitled Applied Cryptography: Protocols, Algorithms, And Source Code In C byBruce Schneier (2d Ed, John Wiley & Sons, Inc., 1996) describes in detail numerouscryptographic protocols that can be used. These protocols can be understood from thefollowing basic overview.The following notation is used throughout the description of cryptographicprotocols:PKEA: refers to the public encryption key of user A. This can be an RSApublic key or a key for some other public key encryption scheme.SKEA: refers to the secret decryption key corresponding to encryption keyPKEA.PKSA: refers to the public component of user A's signature key. This can be aDSS key or a key for some other public key signature scheme. It canalso be the same key as PKEA in public key systems like RSA.WO 98/10558.1015202530SKSA:EPKE(M) 5DsKE(C)5EK(M):DK(C):SsKs(M)3H(M):A,B :CA 02264912 1999-03-05PCTIU S97! 15320- _refers to the private signature key corresponding to PKSA. It can alsobe the same key as SKEA in public key systems like RSA.refers to the encryption of the plain text message M with the publicencryption key PKE.refers to the decryption of the cipher-text message C with the secretdecryption key SKE.refers to the encryption of message M with a symmetric encryptionalgorithm and key K. It is apparent fi'om the context whether theprotocol uses public key or symmetric key encryption.refers to the decryption of the cipher-text message C with a symmetricencryption algorithm and key K.refers to signature of message M with secret signature key SKS.refers to the hash of the message M with a cryptographic hash functionlike MD5 or SHA.refers to the concatenation of A and B. This is commonly used whendescribing messages.Public key encryption systems are usually several orders of magnitude slowerthan private (symmetric) key encryption systems. As a result, central controller 200preferably uses the following protocol or the like to encrypt messages. Suppose thatAlice wants to encrypt a message M so that only Bob can read it.1. Alice obtains Bob's public encryption key, PKEB, generates a randomsyrmnetric encryption key K, and encrypts it with Bob's public key.2. Alice encrypts the message M with the key K using a symmetric encryptionalgorithm, like Triple-DES or IDEA, and sendsMo = EPKEB(K)aCwhere C=EK(M).3. Bob decrypts the key K using his private decryption keyK = DsKEa(Ep1<Ea(K))and uses the key to decrypt the messageM = Dx(C) = Dx(Ex(M))-The bulk of the encryption is done using the symmetric encryption algorithm,W0 98/10558S1015202530CA 02264912 1999-03-05PCT/US97/15320_ 17 -which is orders of magnitude faster than the public key encryption algorithm. When auser encrypts a message to central controller 200 using central controller 200's publickey, it is assumed that the user and central controller 200 carry out the above protocol.Typical signature schemes (e.g. RSA or DSS) use a key pair for creatingsignatures and verifying them. One part of the pair, the private part, is used forgenerating signatures. The transformation for generating a signature is defined in sucha way that only someone who knows the private part of the key pair can generate asignature. Hence, only the owner of the key pair can generate signatures.The other part of the pair, the public part, is used to verify signatures. Anyone,including the owner of the key pair, can use the public component to verify that asignature is valid. However, it is computationally infeasible to use the publiccomponent to forge a signature.One example of such a signature scheme is the RSA public-key encryptionsystem. In such a system, each user has a public key consisting of a modulus n and anexponent e, where n is a product of two secret primes p and q. The private componentis an exponent d such that ea’ =1 (mod(p-l)(q-1)).To sign a message M with an RSA key pair, the user computesS = M‘ (mod n).where the result S is the signature. In order to verify the signature, a user simplycomputesS‘ = M“ = M (mod n).The signature verifies correctly if the result of computing S‘ (mod n) is the messagethat the signature is for, i.e. S‘ = M (mod n). Thus, a user must know d in order togenerate a signature.Public key signature schemes, however, are slow and a user can only signmessages that are smaller than n (when encoded in the ring Z/nZ). One solution is tohash the message M with a cryptographic hashing scheme (e.g. MD5 or SHA), andthen sign the hash. The resulting hash is usually much smaller than the message andhence easier to sign.In addition, generating two messages with the same hash is computationallyinfeasible, so it is extremely difficult to generate two messages which will have theW0 98/105581015202530CA 02264912 1999-03-05PCT/US97/ 15320_ 13 -same signature. Therefore, the following protocol is an RSA-like signature protocolwhich will preferably be used whenever a user or central controller 200 needs to signand verify messages and will be known as SsKs(M):1. Alice generates a message M which she wishes to sign.2. Alice computes h = H(M), the one-way hash of M with a predeterminedhashing algorithm.3. Alice computesS=h“ (mod n)which is her signature. Hence,SSKSA(M) = (H(M))SKSA (mod 11)-The following protocol can be used by any user to verify Alice's signature:1. Bob receives a message M and corresponding signature S, which he wants toverify. He believes that Alice generated the signature.2. Bob computes M‘ = SPKSA (modn ) where n is Alice's public modulus (it isspecified as part of PKSA).3. Bob verifies that M = M’. If they match, then Alice's signature verifiessuccessfiilly. Otherwise the verification fails.Most of the protocols described require public encryption keys or privatesignature keys (or both). Each user communicating with central controller 200 shouldreceive encrypted messages from central controller 200 and sign messages that theysend to central controller 200. Hence, each user in the system requires apublic/private encryption key pair and a public/private signature key pair. As notedabove, these pairs could be the same pair in systems like RSA.Generating a key pair, either signature or encryption, depends heavily upon theintended algorithm. A brief example for generating RSA encryption (and signature)keys is shown below.1. Central controller 200 determines the size for the public key. Typically, a768-bit key is the recommended minimum, but 1024-bits provide a betterminimum.2. Central controller 200 generates two primes p and q such that p >sqrt(pq) > q,and p and q are not close together (i.e. they are both roughly sqrt(n) in size, butW0 98l105581015202530CA 02264912 1999-03-05PCT/US97/15320_ 19 -different in size by two or three bits).3. Central controller 200 computes n = pq. This is the public modulus.4. Central controller 200 chooses a public exponent e. Common choices are 3,17, and 65537 (2“+l).5. Central controller 200 computes the private exponent a’ by finding a’ such thated = 1 (mod (p-l) (q-1)).Central controller 200 can do this using the extended Euclidean Algorithm.6. Central controller 200 publishes n and e as the public key. e is the publicexponent which people use to encrypt messages to the public key user (a party,requestor or central controller 200) or to verify the signature (if the pair is thesignature pair). The secret exponent, d, is what is used to decrypt messagessent to the user or to generate signatures.The primes that central controller 200 chooses are preferably chosen atrandom. If an attacker can determine p and q, then the attacker can also determine d.Several tests exist for determining whether a randomly chosen number m is prime ornot. Typically one chooses a random number m and then uses primality tests todetermine the first prime greater than or equal to m.When encrypting a message to be transmitted or verifying a signature, thereneeds to be a way of verifying the appropriate public key. One common way is toimplement a hierarchical certification system in which each valid public key has acorresponding key certificate. The key certificate is signed by another user's privatesignature key higher up in the key hierarchy. At the top of the hierarchy is the privatesignature key of the certificate authority, whom everyone automatically trusts. In thiscase, the certificate authority would be central controller 200.The purpose of a certificate is to bind together in some authenticated way apublic key, and a set of statements about this public key. The most importantstatement made is usually who owns the public key. Other potentially importantstatements might deal with what the key is and is not authorized to do, and when thekey expires.The best—known standard for key certificates is X.509. More detailedinformation on the construction of X.509 certificates can be found in CCITT, DractW0 98/ 10558'1015202530CA 02264912 1999-03-05PCTfUS97/ 15320_ 20 _Recommendation X.509, "The Directory-Authentication Framework," ConsultationCommittee, International Telephone and Telegraph, InternationalTelecommunications Union, Geneva, 1989 or RSA Laboratories, "PKCS #6:Extended—Certificate Syntax Standard," Version 1.5, Nov 1993.In a preferred embodiment of the invention, central controller 200 has at leastone signature key pair for which everyone using the system knows the publicsignature key. In one embodiment of the invention, central controller 200 will use twosignature key pairs: one key pair for signing key certificates and one key pair for usein the rest of the protocols described. Central controller 200 keeps the certificateauthority signature pair under lock and key except for when a key certificate needs tobe signed.‘ On the other hand, the other signature key pair is available at all times.Each time a new user (a party or requestor) registers with central controller200, the certificate authority signature key is used by central controller 200 to sign aunique signature key pair for the user. This needs to be done before a user uses theirsignature key pair for the first time. In one embodiment of the invention, centralcontroller 200 generates a signature key pair and signed key certificate for the user. Inan alternate embodiment, the user creates his own key pairs.Once a user involved in the system has a signed key certificate for his publicsignature key, he can then use that signature key to sign a key certificate for his publicencryption key. Central controller 200, acting as the certificate authority, can alsosign the key certificates for encryption keys. This has the advantage of reducing thenumber of signature verifications. In an embodiment of the present invention, thesame method for generating signature key pairs is used for generating encryption keypairs.A user follows the following basic protocol when registering with centralcontroller 200. Suppose that Alice is such a user:1. Alice obtains a signature key pair.2. Alice generates a key certificate for her public signature key, sends a copy ofthe certificate and the public key to central controller 200, and asks centralcontroller 200 to sign the certificate.3. Central controller 200 sends Alice a copy of the signed certificate.CA 02264912 1999-03-05WO 98/10558 PCT/US97l15320_ 21 _4. Alice obtains an encryption key pair.5. Alice generates a key certificate for her public encryption key and signs it withher private signature key.6. Alice sends a copy of her public encryption key, along with a copy of the5 signed key certificate, to central controller 200.1015202530After carrying out this protocol, Alice has a signed signature key and a signedencryption key. Furthermore, any user who wishes to send an encrypted message toAlice or verify her signature can obtain the public key component from centralcontroller 200.For most of the protocols described used in the invention, it is assumed thatcentral controller 200 stores signatures and the public components for all signaturekeys used in the system. In addition, it is assumed that each user has a copy of thepublic components of both of the central controller 200's signature keys. Mostcommunication in system 100 occurs between parties and central controller 200 andbetween requestors and central controller 200. Where a requestor and a partycommunicate directly, each obtains copies of the other user's public signature andencryption keys from central controller 200.System 100 may be prone to attempted infiltration, or "attacks," if therequester and central controller 200 do not use an interlock protocol. Schneier et al.,"Automatic Event-Stream Notarization Using Digital Signatures," in Advances inCryptology, Proceedings of the Cambridge Protocols Workshop 96, Springer—Verlag,1996. The interlock protocol "locks" the signatures generated by both users of aprotocol to a particular instance of the protocol. This is accomplished by having eachuser sign a packet which the other user randomly generates. This causes the protocolto be non-deterrninistic and hence the signatures from one instance do not apply toanother. The interlock protocol is described briefly below. Suppose that a partywishes to send a message C to central controller 200:1. The party generates a random number R0 and sendsM0 = R0, SsKs,,(R0) to Central controller 200.2. Central controller 200 verifies the party's signature. Central controller 200then generates a random number R, and sendsCA 02264912 1999-03-05W0 98/ 10558 PCT/US97/15320_ 22 _M1 = Rn SSKSm(H(M0)9Rl)to the party.3. The party verifies central controller 200's signature. Central controller 200then sends5 M2 = C>sSKSv(H(Ml)sC)1015202530to central controller 200.The party and central controller 200 both sign packets using values whichcannot be known before the protocol starts. Central controller 200 carmot predict R0,so it carmot predict what M0 will look like. Similarly, the party cannot predict R, so hecannot predict what M, will look like. Hence, each of them must see the packetsbefore they generate the signatures which means that anyone trying to impersonate theparty must have the capability of generating signatures on his behalf. This effectivelythwarts a replay attack, which can be used to prevent an attacker from gaininginformation as demonstrates next.Suppose an attacker Eve observes a party sending some encrypted packets tocentral controller 200. Although Eve does not know what the packets contain, shemight be able to determine that they contain a resume. If a period of time passes inwhich the party and central controller 200 do not communicate and then centralcontroller 200 sends the party an encrypted message, Eve's confidence thatthe partysent a resume should increase. Now, if Eve were to send the same encrypted messageto central controller 200 that the party originally sent, eventually central controller200 will send another encrypted message to the party. The attack that Eve (acting as arequestor) can mount is that she could submit one or more legitimate search requeststo central controller 200 and wait for the results. By paying attention to how the sizeof the response to the request varies, Eve can deduce some information about theparty's data. This sort of attack violates the party's privacy. By using the interlockprotocol, Eve cannot replay the party's packets to central controller 200 because shewon't be able to complete the interlock protocol.System OpgggtiggThe operation of system 100 is now described in connection with the flowdiagrams shown in Figs. 5, 6, 7, 8 and 9. Fig. 5 illustrates a flow diagram of a methodWO 98/105581015202530CA 02264912 1999-03-05PCT/US97/15320- _for providing anonymous communication in accordance with one embodiment of theinvention.As shown in Fig. 5, central controller 200 receives encrypted party data andencrypted requestor data (step 500). Such encrypted party data and requestor datapreferably originates from party terminals 300 and requestor terminal 400,respectively. In one embodiment, party terminals 300 prompt respective parties toenter party data by displaying requests for information on video monitor 330. Forinstance, in the employment search example, video monitor 330 would requestinformation that may be of interest to an employer, such as the candidate's identity,the candidate's address, the candidate's vital statistics, the candidate's workexperience, the candidate's educational background, and the candidate's interests. Theparty would enter party data using input device 345. Cryptographic processor 335would encrypt the entered party data and modem 350 would transmit the encryptedparty data to central controller 200 via network 110.Requester terminal 400 preferably operates in a similar manner to prompt arequestor for requestor data, receive and encrypt the requestor data, and transmitencrypted requestor data to central controller 200. Central controller 200 also assignsa pseudonym to each party and requestor whose party data and requestor data is storedin databases 255 and 260, respectively.After receiving the encrypted party data and requestor data, cryptographicprocessor 210 of central controller 200 decrypts the received data (step 500). CPU205 of central controller 200 stores the decrypted data in databases 255 and 260,respectively (step 500).Central controller 200 receives a search request to identify those parties whoseparty data satisfies certain criteria (step 510). In a preferred embodiment, the searchrequest originates from requestor terminal 400, where a requestor entered the searchrequest. Before requestor terminal 400 transmits the search request, cryptographicprocessor 435 of terminal 400 preferably encrypts the search request. Cryptographicprocessor 210 decrypts the encrypted search request upon receipt at central controller200. Central controller 200 then searches party data database 255 and, in response tothe search, transmits certain information to requestor terminal 400 and party terminalW0 98/ 105581015202530CA 02264912 1999-03-05PCT/U S97! 15320-24-300 (step 510).Figs. 6A and 6B illustrate a flow diagram showing step 510 in more detail.First, central controller 200 receives search criteria from requestor terminal 400 (step600). This search criteria may include, for example, certain employmentqualifications or educational background that an employer is interested in.In response, central controller 200 searches database 255 for party datasatisfying the search criteria (step 610). Controller 200 then transmits to requestorterminal 400 the results of the search, e.g., number of parties that it found to haveparty data satisfying the criteria (step 620). Alternatively, the number of partieswould be transmitted to requestor terminal 400 along with pseudonyms for each ofthose parties.Depending on the number of parties found, the requestor may refine or modifythe search criteria. If the requestor chooses to modify the search criteria, the requestorenters the new search criteria into requestor terminal 400, which transmits the searchcriteria to central controller 200 (step 630), and steps 610 and 620 are repeated.Otherwise, central controller 200 determines whether the requestor requestsparty data about those parties found as a result of the search (step 640). Centralcontroller 200 does not transmit any further data to the requestor at requestor terminal400 and the transmission ends (step 645).If the requestor chooses to request party data (step 640), the requestor entersthe party data request into requestor terminal 400, which transmits the request tocentral controller 200. Central controller 200 transmits an authorization request toparty terminals 400 for authorization to release respective parties‘ party data (step650)The party receiving the request for authorization can indicate whether toauthorize central controller 200 to release some or all of its party data by entering oneof three responses into party terminal 300 (step 660). The responses are sent tocentral controller 200. If central controller 200 receives a response that indicates thatthe party does not authorize release of any party data, central controller 200 does notprovide any party data to requestor terminal 400, and the transaction ends (step 661).WO 98/105581015202530CA 02264912 1999-03-05PCT/US97/15320_ 25 _If, on the other hand, central controller 200 receives a response that indicates that theparty authorizes release of some or all of its party data, central controller 200transmits that party data to requestor terminal 400 for the requestor (step 662).Central controller 200 could also receive a response asking for data about therequestor before authorizing release of its party data (step 663). If so, centralcontroller 200 transmits a query to the requestor at requestor terminal 400 asking forauthorization to release requestor data to the party (step 670). If requestor does notauthorize release of any requestor data to the party (step 680), central controller 200does not release any requestor data to the party and the transaction ends (step 685). Ifthe requestor does authorize release of some or all of the requestor data to the party(step 680), central controller 200 transmits the authorized requestor data to the party(step 690). Central controller 200 then awaits the party's response to see whethercentral controller 200 is authorized to release party data.To ensure the parties‘ authorization to release their party data is valid,permission certificates can be used in an alternate embodiment of the presentinvention. For example, in an employment system embodiment, parties who use thesystem may not want anyone to know they are hunting for a job. Candidates may notwant any of the people they work with to know. As a result, the party would likeexplicit control over who sees their resume. Therefore, whenever central controller200 gets a request for a release of party data, central controller 200 needs to obtainexplicit permission from the party to send the party's data to the requestor. When aparty decides to release his party data, he can be sure his data will be released only tothe requestor making the request. The following is a preferred protocol for a party toissue a permission certificate:1. A requestor "A" submits a request to release party data J and to centralcontroller 200 in order to find out more about the party.2. Central controller 200 assigns a unique transaction ID, T, to the request andcreates a modified request J '=(J ,T). The transaction ID, T, helps ensure thateach job description (and hence permission certificate) is unique.3. Central controller encrypts J‘ using the party's public encryption key and sendsthe encrypted message to the party. Central controller sendsW098/105585 4.5.1015 6.7.20CA 02264912 1999-03-05PCT/US97/15320- -Mo = EPKEA(J'9SSKST(PKEAaJ'))to the party. The party's public key is included as part of the information thatcentral controller 200 signs so a third party carmot forward a copy of a jobdescription they received from central controller 200 to another party.The party decrypts the message to retrieve J‘, verifies central controller 200'ssignature, reads the request, and decides if he wants to release his party data. Ifhe doesn't, then he stops the protocol here.The party generates a message M containing the following information:* A pre-defined string which states that he gives his permission torelease his party data to the requestor.* A hash of the request H(J'). Note, this is unique to this permissioncertificate since the transaction ID is unique to the job description.* A string which states the details about how he wants her party datareleased, whether or not he wishes to remain anonymous, etc.The party signs the message, encrypts it using central controller 200's publicencryption key and sends it to central controller 200. Hence, she sendsM. = EPKET(M9sSKSA(M))to central controller 200.Central controller 200 decrypts the message to retrieve M, verifies the party'ssignature, and transmits the party's data to the requestor.Because the party signs the message that central controller 200 sent him in thefirst step, his signature will only work for the job description that central controller200 sent him. Hence, central controller 200 cannot use the permission certificate for adifferent job description. This assumes, of course, that the request to release party25 data contains information unique to that request, such as a transaction ID number.Central controller 200 embeds the transaction ID in the request to release party datamessage.In an alternative embodiment, central controller 200 could assign a differenttransaction ID to each request and party. Hence, two different parties cannot easily30 check that they are getting the same request by comparing transaction IDs.W0 98/ 105581015202530CA 02264912 1999-03-05PCT/US97/15320-27..The same protocol can be used in any other situation which also requires apermission certificate. For example, central controller 200 needs to obtain permissionfrom a requestor before releasing his requestor data to a party.Returning to Fig. 5, central controller 200 can receive an authenticationrequest to verify the authenticity of the origin, authorship, and/or integrity of partydata or requestor data (step 520). Upon receiving this request, central controller 200verifies the data and transmits a verification status to the party or requestor requestingdata verification (step 520). Step 520 is described in greater detail in connection withFig. 7. Central controller 200 receives a verification request from a requestor forverification of party data (step 700). As described above, this verification mayinclude verifying the authenticity of any one of the origin, authorship, and integrity ofthe party data stored in databases 255.In response, central controller 200 transmits a verification status request to averification authority to verify the party data (step 710). For instance, in theemployment services example, the party data to be verified may include a universityfrom which a candidate received an advanced degree. In that case, central controller200 could transmit a verification status request to the candidate's purportededucational institution to verify that the candidate did, in fact, receive an advanceddegree from that institution.When central controller 200 receives a response to its request indicating theverification status of the party data, central controller 200 stores the verification statusin verification database 270 (step 720), and transmits that verification status to therequestor at requestor terminal 400 (step 730).The method shown in Fig. 7 could be adapted to verify requestor data. In thatcase, central controller 200 receives a request from a party to verify requestor data andtransmits a request to a verification authority. When central controller 200 receivesthe verification status from the verification authority, it transmits the verificationstatus to the party.Returning to Fig. 5, central controller 200 can establish an anonymouscommunications channel between a party and requestor (step 530). In this way, theparty and the requestor can reveal or request information to. and from each other. AsW0 98/ 10558.1015202530CA 02264912 1999-03-05PCT/US97/15320-2g_described above, the communications channel can be real-time or non-real—time. F i g.8 shows a flow diagram illustrating one embodiment of a method for opening acommunications channel between party terminal 300 and requestor terminal 400 andi Fig. 9 shows a flow diagram illustrating one embodiment of a method for managingthe communication between party terminal 300 and requestor terminal 400.After receiving a communications channel request from a requestor to open acommunications charmel with a party (step 800), central controller 200 transmits acommunication request to the party at party terminal 300 (step 810). Preferably, thecommunication request asks the party whether it agrees to engage in a real-time ornon—real-time communication with the requestor.If central controller 200 receives a response indicating that the party does notagree to engage in communication with the requestor (step 820), then centralcontroller 200 does not open the communications channel and the transaction ends(step 830). If central controller 200 receives a response indicating that the partyagrees to the request (step 820), central controller 200 opens a communicationscharmel between party terminal 300 and requestor terminal 400 (step 840). Thecommunications charmel can be set up as either a real-time or non-real-timeconnection including an audio system (i.e., a telephone system), an electronicmessaging system, and a video communication system. In one embodiment, thecommunications channel includes a modification processor for modifying voiceand/or video.After opening the communications charmel, central controller 200 debits therequestor's billing account stored in database 275 and transmits a bill to the requestor(step 850). Central controller 200 could also collect payment from the requestor usingother payment methods including: on-file credit card, periodic statement billing,account debit, and digital cash. Further, in one embodiment, central controller 200transmits payments to parties for party activities including: allowing centralcontroller 200 to maintain party data in party data database 255, communicating withrequestors, and releasing party data.Fig. 9 illustrates a flow diagram of the method of step 5 30 for establishing acommunications channel, in accordance with one embodiment of the invention.W0 98/ 105581015202530CA 02264912 1999-03-05PCT/US97/15320_ -Central controller 200 receives a message from a requestor addressed to a particularparty by pseudonym (step 900). Central controller 200 processes the message toremove any information that would reveal the identity of the requestor (step 910) inorder to maintain the requestor's anonymity. Central controller 200 transmits theprocessed message to the party at party terminal 300 (step 920). Central controller200 receives a response to the message from the party, removes any information thatwould reveal the identity of the party (step 940), and transmits the processed responseto the requestor (step 950).. Removing identity information may also include the use of voice and/or videomodification processors in step 910 and 940. Steps 900-950 are repeated to allowmultiple messages to pass between the party and the requestor, while maintaining theanonymity of the party and requestor. In one embodiment, central controller 200 ‘debits the requestor billing account according to the usage of the communicationschannel between the party and the requestor (step not shown). Central controller 200can measure usage of the communications channel using one of several methods,including: number of messages exchanged, time that central controller 200 maintainsthe communications charmel, the requestor's status (i.e., premium customers pay less),and geographic location of party terminal 300 and/or requestor terminal 400.Central controller 200 collects payment for certain transactions performed. Inaccordance with one embodiment of the invention, central controller 200 transmits abill to the requestor at requestor terminal 400 for each transaction and debits therequestors account (step 540), which is stored in database 275 of central controller200. In alternative embodiments, the payment scheme can be modified or varied tocharge either the requestor or the party or both for various transactions executed bysystem 100, and particularly central controller 200. In a further embodiment, thepayment scheme involves paying the party for submitting information to centralcontroller 200, opening a communications channel, and/or releasing party data to arequestor. In one embodiment of the system, a party is payed each time he authorizesthe release of his party data to a requestor. Central controller 200 will monitor thetransactions to ensure that parties do not release information to the same requestormore than once in a given period of time.W0 98/ 105581015202530CA 02264912 1999-03-05PCT/US97/ 15320-30-As stated earlier, maintaining the anonymity of the party and requestor can beimportant to their communications. For example, an employer may not want itscompetitors to know that it is looking to expand its staff because it may give them anadvantage. An attacker may attempt to examine the message traffic coming in and outof central controller 200 to expose the identity of a user of the system. A way toprevent this type of attack is to use an anonymous mix protocol duringcommunication between a party or requester and central controller 200.An anonymous mix uses a protocol to make it very difficult for anyone totrace the path of a message which passes through the mix. The anonymous mix takesoutgoing messages from central controller 200 and randomly varies both the length ofthe message as well as the timing of its delivery. An incoming message of twohundred kilobytes, for example, might be expanded to three hundred kilobytes byadding random characters at the end. An attacker would thus be unable to correlate(by length of message) the incoming requestor query with requests to release partydata sent to the various parties. By adding a random time delay in the processing ofincoming requests, central controller 200 also prevents an attacker from correlating(based on time) incoming requests with outgoing requests. An example of theanonymous protocol employed in the present invention is set forth below.Notation and Conventions for this protocol:a. PKE,,KU(X) represents the public-key encryption of X under public keyPKU.b. SIGNsK.,(X) represents the digital signature of X under private key SKU.c. Em} (X) represents the symmetric encryption of X under key K.,.d. PKU represents the public key of user U.e. SKU represents the private key of user U.f. DU represents the identification number of user U.g. X,Y represents the concatenation of X with Y.Keys used in this protocol:a. PKM is the anonymous mix public key.b. ID, is Bob's ID.c. PKB is Bob's public key.W0 98/ 10558'1015202530CA 02264912 1999-03-05PCT/U S97/ 15320_ 31 _(1. SK,, is Bob's private key.When Alice sends Bob a message through anonymous mix , the followingsteps could take place:a. Alice wishes to send message T to Bob anonymously. She first forms:K, = a random session key.P0 = an all-zero string of some random length.X0 = PKEm.(Ko)-M, = X.,,EK0(ID,,,P,,,T).Alice then sends Mo to the anonymous mix 180. Note that Alice may also haveencrypted and digitally signed the message she's sending to Bob. This has no bearingat all on how the anonymous mix processes it. P, disguises the size of the message,making it difficult, or virtually impossible, to correlate incoming messages withoutgoing messages.b. The anonymous mix receives M0. Using X0, anonymous mix decodesthe random session key K0 using anonymous mix private key SKM and then using K,,1133, T and P0 are decrypted. The anonymous mix looks up Bob's public key fromIDB, and then forms:K, = a random session key.P. = an all-zero string of some random length.X. = PKEm,(K,).M. = X,,EK,(P.,T)Anonymous mix waits some random amount of time before sending M, to Bob.During this time, it is processing many other messages, both sending and receivingthem.c. Bob receives M,. He decrypts it using his private key, SK, and recovers T. Hethen does whatever he needs to with T.In order to make messages that pass through an intermediary anonymous mixanonymous, a large volume of messages coming in and out are reviewed. A randomdelay involved in forwarding those messages may also be required. Otherwise, it ispossible for an opponent to watch messages going into and coming out of anonymousmix, using this information to determine the source and destination of each message.W0 98/ 105581015202530CA 02264912 1999-03-05PCT/US97/ 15320-32-Similarly, messages must be encrypted to the anonymous mix, so that the messagescan be decrypted and re-encrypted with a different key. Also, messages may need tobe broken into many pieces or padded with large blocks of data, to avoid havingmessage lengths give away information. Anonymous mix either knows everyone'spublic keys or their public keys are sent along with their identities. Every user isassumed to know anonymous mix's public keys. The anonymous mix, used incombination with encryption and digital signatures discussed earlier, provides a highlevel of anonymity for both parties and requestors.Anonymity may also serve to prevent a requestor and party from contactingeach other outside the system in order to ensure that payment is received for bringingthe two together. In this embodiment, central controller 200 forces anonymity byblinding one or both parties. The requestor, for example, may not see the name of theparty until the requestor's account has been debited.Figs. 8 and 9 illustrate a method in which a communications channel betweena party and requestor is established and managed by system 100 without either theparty or the requestor learning the other's identity. While Figs. 8 and 9 illustratemethods in which central controller 200 establishes the communications charmel at arequestor's request, in alternative embodiments, a communications channel can beestablished at a party's request. In that case, central controller 200 receives a requestfor a communications channel from party tenninal 300, transmits the request torequestor terminal 400, and establishes a communications charmel in accordance withthe requestor's response.While the invention, as embodied and described in connection with system100, can be applied to the employment search process, the invention can also beapplied to a variety of other areas involving anonymous communications. Forinstance, system 100 can be used in connection with matchmaking (i.e., providingdating services). People, or "parties," interested in dating can enter personal data, or"party data," about themselves at party terminals 300. For each party, the party datamay include the party's identity, the party's vital statistics, the party's background, andthe party's interests. Central controller 200 and party terminals 300 receive andtransmit the party data in the manner described above.W0 98ll05581015202530CA 02264912 1999-03-05PCT/US97/15320_ 33 _People, or "requestors," who would like to find parties whose personal datasatisfies their interests or tastes can enter a search request at requestor terminal 400.In one embodiment, requestors enter data, or "requestor data," about themselves atrequest terminal 400, which encrypts and transmits the requestor data to centralcontroller 200. In addition, each requestor enters, at request terminal 400, a searchrequest specifying attributes about people that the requestor would like to date. Forinstance, the search request may specify that the requestor is interested in identifyingmen that are at least 6' tall and are college-educated. Request terminal 400 encryptsthe search request and transmits the encrypted search request to central controller 200for processing, as described above.In response to the search request, central controller 200 preferably transmits torequestor terminal 400 the number of people found to satisfy the criteria in therequest, as described above in connection with Fig. 6A. In the example given above,central controller 200 would transmit to requestor terminal 400 the number of peoplewho indicated that they are men, 6' tall, and college-educated, as revealed by partydata database 255. Central controller 200 releases party data and requestor data to therequestor and parties, respectively, in the marmer described above in connection withFig. 6B. Central controller 200 can verify data, as described in connection with Fig.7, and open a communications channel between a requestor and a party, as describedin connection with Figs. 8 and 9. When central controller 200 opens thecommunications channel, the requestor and the party can exchange adequateinformation about themselves to decide whether to agree to a date without subjectingthemselves to any risk if either should decide not to agree to the date.The employment search and dating services examples demonstrate how theinvention can: allow a requestor to search for parties meeting certain criteria, allowparties to control the release of information about themselves, and provide acommunications channel between a requestor and the parties while maintaining theanonymity of the parties and the requestor from each other. The invention, however,is not limited to those types of applications. Other applications include finding andinterviewing consultants or freelancers for a specific project, auditioning actors andactresses, seeking a merger partner, and engaging in various commerce-basedW0 98/ 10558l0IS202530CA 02264912 1999-03-05PCT/US97/15320-34-applications in which controlled anonymity by any party would be beneficial.The invention can be used in applications where the system establishes acommunications charmel between parties and authenticates information about theparties, while maintaining the anonymity of at least one of the parties. In oneembodiment, system 100, as described above, could be used for such applications.This embodiment allows two parties to communicate while each party is ensured thatthe infonnation being communicated is valid. For example, in the case of a"whist1e-blowing" application (outlined below) an employer can be certain that theinformation he receives is from an employee within his organization. The methodsillustrated by the flow diagrams of Figs. 5-9 could be readily adapted for theseapplications. .By way of example, system 100 could be used as a "whistle-blowing" systemto allow employees of a company to anonymously report legal and policy violationswithout risking retribution by the company's management. The employee reporting aviolation would preferably enter, into party terminal 300, data about the violation anddata that can be independently verified as originating from the employee claiming theviolation. The employee is referred to hereafter as the "party" and the data entered intoparty terminal 300 is referred to hereafier as the "party data." In one embodiment, theparty data may include an employee identification number uniquely identifying eachemployee of the company. Party terminal 300 encrypts and transmits the party data tocentral controller 200, preferably in the manner described above.A company representative, referred to as the "requester," would use requestorterminal 400 to access the party data stored in central controller 200. After accessingthe party data about the violation, the requestor could submit a request at requestorterminal 400 to have some or all of the party data authenticated. For example, centralcontroller 200 could verify that the party is, in fact, an employee of the company bycomparing an employee identification number contained in the party data with a list ofactive company employee identification numbers. If the number matches, centralcontroller 200 would transmit a response to requestor terminal 400 confirming that theparty is an active employee of the company.The requestor, or the party, could enter a request into requestor terminal 400,WO 98/105581015202530CA 02264912 1999-03-05PCTIUS97/15320-35 -or party terminal 300, for central controller 200 to open a communications charmelwith the party, or the requestor. Central controller 200 would open a communicationscharmel, as described above in connection with Figs. 8 and 9, to allow the party andthe requestor to communicate, while maintaining the party's anonymity. This wouldallow the employer to question the employee about details relating to the incident in 'question, without the employee revealing his identity.In another example, system 100 could be used as a system to allow parties toremain anonymous while negotiating an agreement. For instance, criminals, or ruleoffenders, anonymously offer to turn themselves in, while negotiating favorabletreatment. In this case, the criminals, or rule offenders, would represent the "parties"and law enforcement, or rule enforcers, would represent the "requestors." In apreferred embodiment, a party would enter, at party terminal 300, information ("partydata") about his violation and data that can be independently verified as originatingfrom the party claiming the violation. The party data can include the pa.rty's identity,which is preferably only used by system 100 for verification purposes. Party terminal300 would encrypt and transmit the party data to central controller 200, in the mannerdescribed above. A requestor would use requestor terminal 400 to access the partydata stored in central controller 200.The requestor could enter a request for authentication of the party data intorequestor terminal 300, which would transmit the request to central controller 200.Central controller 200 would verify some or all of the party data, as described above,and transmit a verification status message to requestor terminal 400. Upon requestfrom either party terminal 300 or requestor terminal 400, central controller canestablish an anonymous communications channel with the other terminal, providedthat the party and the requestor agree to engage in the communications channel. Asdescribed above, this communications channel can be real-time or non-real-time.Under the “plea bargaining" example, the invention allows the requestor andthe party to negotiate the terms of the party's sentence or punishment for committingthe violation before the party reveals his identity. If negotiations fails, the party doesnot subject himself to any risk that the requestor will learn his identity simply becauseW0 98ll055810CA 02264912 1999-03-05PCTIUS97/15320- 35 -he initiated communication. The requestor, of course, can use whatever informationthe party revealed about himself during the course of the negotiation to learn theidentity of the party.Besides the whistle-blowing and plea bargaining examples, the invention alsoapplies to other applications, such as authenticated phone-based tip lines and licensingnegotiations where a licensee does not want to reveal the size of his company for fearof being charged more by the licensor.ConclusionIt will be apparent to those skilled in the art that various modifications andvariations can be made in the system and method of the present invention withoutdeparting from the spirit or scope of the invention. The present invention cover themodifications and variations of this invention provided they come within the scope ofthe appended claims and their equivalents.

Claims (54)

1. A method for facilitating an exchange of information between a first party and a second party, comprising the steps of:
receiving first party information data from said first party;
storing said first party information data in a secure database;
receiving, from said first party, at least one rule for releasing said first party information data;
storing said at least one rule;
receiving, from said second party, a search request to the secure database, said search request comprising at least one search criterion to be satisfied;
determining second party data relevant to said at least one rule;
processing said search request from said second party to determine if said first party information data satisfies said at least one search criterion;
if said first party information data satisfies said at least one search criterion, them:
communicating to said second party that said at least one search criterion has been satisfied;
receiving a request from said second party for said first party information data, determining, based on said second party data, whether said at least one rule has been satisfied; and if said at least one rule has been satisfied, providing. to said second party, said first party information data for which said at least one rule has been satisfied.

2. The method according to claim 1, further comprising the step of:
authenticating authorship of said first party information data.

3. The method according to claim 1, wherein the step of receiving first party information data comprises the substeps of:
receiving first party information data in encrypted form; and decrypting the received first party information data.

4. The method according to claim 1, further comprising the step of authenticating authorship of the search request.

5. The method according to claim 1, wherein the step of determining second party data further comprising the steps of:
receiving second party data corresponding to the second party; and receiving, from said second party, at least one rule for releasing said second party data.

6. The method according to claim 1, wherein the communicating step further comprises the step of:
communicating to the second palty a pseudonym corresponding to said first party.

7. The method according to claim 1, further comprising the steps of:
receiving from said second party a request to provide a communication channel with said first party;
communicating, to said first party, said request to provide said communication channel; and providing said communication channel between said first party and said second party, if said first party agrees to said request to provide said communication channel.

8. The method according to claim 7, wherein the step of providing a communication channel comprises providing an asynchronous communication channel.

9. The method according to claim 8, wherein the step of providing an asynchronous communication channel comprises the step of using a cryptographic protocol.

10. The method according to claim 7, wherein the step of providing a communication channel comprises providing a real-time communication channel.

11. The method according to claim 1, further comprising the steps of:
receiving from said second party, a request to verify whether said first party information data is accurate; and verifying the accuracy of the first party information data.

12. The method according to claim 5 further comprising the step of authenticating authorship of the received second party data.

13. The method according to claim 1. wherein the step of receiving at least one rule further comprises the step of receiving from said first party at least one rule specifying at least one second party to whom the first party authorizes the system to release said first party information data.

14. The method according to claim 1, wherein the step of receiving at least one rule further comprises the step of:
receiving, from said first party, a rule that an authorization be obtained from said first party before said first party information data is released; the method further comprising the steps of:
after receiving the request from the second party for said first party information data, communicating to said first party, said second party data and a request for authorization to release said first party information data; and receiving a response, from said first party, to said request for authorization.

15. The method according to claim 1, further comprising the steps of:
receiving from said first party a request for said second part data;
determining whether said second party has authorized release of said second party data to said first party; and it said second party has authorized the release of said second party data to said first party releasing to said first party said second party.

16. The method according to claim 15, wherein the step of releasing the second party data comprises the substep of preventing release of the second party data that the second party has not authorized for release.

17. The method according to claim 1, wherein the step of providing said first party information data further comprising the steps of:
encrypting the first party information data: and communicating to the second party, the encrypted first party information data.

18. The method according to claim 1, further comprising the step of receiving, from said first party. a payment for at least one of storing and communicating said first party information data.

19. The method according to claim 1, further comprising the step of receiving, from the second party. a payment for at least one of receiving from said second party a search request and providing the first party information data.

20. The method according to claim 1, further comprising the step of transmitting a payment to said first party for at least one of storing and communicating said first party information data.

21. The method according to claim 7, further comprising the step of receiving, from at least one of the second party and the first party, a payment for providing the communication channel.

22. The method of claim 1, wherein the first party is a job candidate and the second party is an employer.

23. The method of claim 22, wherein the first party information data comprises at least one of an identity of the job candidate, an address of the job candidate. at least one vital statistic of the job candidate. a description of a work experience of the job candidate.

an educational background of the job candidate, an interest of the job candidate, a résumé
of the job candidate, a list of at least one publication written by the job candidate, and a list of at least one award received by the job candidate.

24. The method of claim 1, wherein the first party is an employee and the second party is an employer of said employee.

25. The method of claim 24, wherein the first party information data comprises a description of a violation of a policy of the employer.

26. The method of claim 1, wherein the first party and the second party are individuals seeking, a personal relationship.

27. The method of claim 26, wherein the first party information data comprises at least one of an identity of the first party, an address of the first party, a vital statistic of the first party. a work experience of the first party, an educational background of the first party, and an interest of the first party.

28. An apparatus for facilitating an exchange of information between a first party and a second party, comprising:
a storage device; and a processor connected to the storage device, the storage device storing a program for controlling the processor and for storing a secure database; and the processor operative with the program to:
receive. from said first party, first party information data and at least one rule for releasing said first party information data;
store said first party information data and said at least one rule in said storage device;
receive from said second party. a search request to said secure database, said search request comprising at least one search criterion to be satisfied;
process said search request from said second party to determine if said first party information data satisfies said at least one search criterion;
communicate to said second party that said at least one search criterion has been satisfied;
receive a request from said second party for said first party information data:
determine second party data relevant to said least one rule;
determine, based on said second party data, whether said at least one rule has been satisfied; and provide, to said second party, said first party information data for which said at least one rule has been satisfied.

29. The apparatus according to claim 28, wherein said processor is further operative with said program to:
authenticate authorship of said first party information data.

30. The apparatus according to claim 28, wherein the processor is further operative with the program to:
receive first party information data in encrypted form; and decrypt the received first party information data.

31. The apparatus according to claim 28, wherein the processor is further operative with the program to:
authenticate authorship of the search request.

32. The apparatus according to claim 28, wherein the processor is further operative with the program to:
receive second party data corresponding to the second party;
receive, from said second party, at least one rule for releasing said second party data.

33. The apparatus according to claim 28, wherein the processor is further operative with the program to:
communicate to the second party a pseudonym corresponding to said first party.

34. The apparatus according to claim 28, wherein the processor is further operative with the program to:
receive from said second party a request to provide a communication channel with said first party;
communicate, to said first party, said request to provide said communications channel; and provide said communication channel between said second party and said first party.

35. The apparatus according to claim 34, wherein said communication channel comprises an asynchronous communication channel.

36. The apparatus according to claim 35, wherein the asynchronous communication channel utilizes a cryptographic protocol.

37. The apparatus according to claim 34, wherein said communication channel comprises a real-time communication channel.

38. The apparatus according to claim 28, wherein the processor is further operative with the program to:
receive. from said second party, a request to verify whether said first party information data is accurate; and verify the accuracy of the first party information data.

39. The apparatus according to claim 32, wherein the processor is further operative with the program to:
authenticate authorship of the received second party data.

40. The apparatus according to claim 28, wherein said at least one rule further comprises a list of at least one second party to whom the first party authorizes the release of said first party information data.

41. The apparatus according to claim 28, wherein the processor is further operative with the program to:
receive, from said first party, a rule that an authorization be obtained from said first party before said first party information data is released;
communicate, to said first party, said second party data and a request for authorization to release said first party information data: and receive a response, from said first party, to said request for authorization.

42. The apparatus according to claim 28, wherein the processor is further operative with the program to:
receive from said first party a request for said second party data;
determine whether said second party has authorized release of said second party data to said first party; and release to said first party the second party data.

43. The apparatus according to claim 42, wherein the means for releasing the second party data comprises means for preventing releasing the second party data that the second party has not authorized for release.

44. The apparatus according to claim 28, wherein the processor is further operative with the program to:
encrypt the first party information data; and communicate, to the second party, the encrypted first party information data.

45. The apparatus according to claim 28. wherein the processor is further operative with the program to receive from said first party, an electronic payment for at least one of receiving and storing first party information data.

46. The apparatus according to claim 28, wherein the processor is further operative with the program to receive, from said second party, an electronic payment for at least one of receiving from said second party a search request and providing the first party information data.

47. The apparatus according to claim 28, wherein the processor is further operative with the program to transmit an electronic payment to said first party for one of storing and communicating the first party information data.

48. The apparatus according to claim 34, wherein the processor is further operative with the program to receive, from at least one of the second party and the first party, an electronic payment for providing the communication channel.

49. The apparatus of claim 28, wherein the first party is a job candidate and the second party is an employer.

50. The apparatus of claim 49, wherein the first party information data comprises at least one of an identity of the job candidate, an address of the job candidate, at least one vital statistic of the job candidate, a description of a work experience of the job candidate. an educational background of the job candidate, an interest of the job candidate, a résumé of the job candidate. a list of at least one publication written by the job candidate, and a list of at least one awar 'received by the job candidate.

51. The apparatus of claim 28, wherein the first party is an employee and the second party is an employer of said employee.

52. The apparatus of claim 51, wherein the first party information data comprises a description of a violation of a policy of the employer.

53. The apparatus of claim 28, wherein the first party and the second party are individuals seeking a personal relationship.

54. The apparatus of claim 53, wherein the first party information data comprises at least one of an identity of the first party, an address of the first party, a vital statistic of the first party, a work experience of the first party, an educational background of the first party, and an interest of the first party.