Systems and method for secure delivery of files to authorized recipients

[0001] This invention generally relates to the secure delivery of electronic documents, and more specifically to methods and systems for verifying and confirming the receipt of files by an independent recipient using automatic speech recognition and biometric identification of the caller's voice.

Background of the invention [0002] Email allows a person (or even an automated robot) to quickly and easily electronically send messages or other information such as, for example, a set of photos, sound recording, formatted documents to other email users anywhere in the world. Anything that is available as a file can be attached to an email as an attachment, such as a folder on your hard disk or shared folders on the network. E-mail attachments can be image files, documents, spreadsheets, mp3 files, programs and the like. After attaching files to an email, an email as well as an attachment can be sent via a communication network (e.g. Internet) to other computer systems. The receiving user or other users who have access to the attached files can download the file to local storage systems for further processing.

[0003] The serious risk associated with the exchange of electronic information through open and unsecured networks, in particular via the Internet, means that an unauthorized person may engage in electronic communications and gain access to certain information, such as e-mail and impersonate the unauthorized recipient of such electronic communications.

[0004] There is often a need to provide electronic documents to a specific recipient and to be sure that the document was received only by the recipient and not by another person. Similarly, you often need to provide an electronic document to an independent recipient, then

- obtaining confirmation that the designated recipient, after receiving the document, has actually opened it and reviewed the content.

[0005] In various legal and security applications, it may be necessary to secure the delivery of documents to a designated recipient by verifying and confirming receipt of such provided documents to the designated recipient. In addition, in these types of applications it is generally important that the recipient cannot easily deny receiving or viewing the document.

[0006] Previous attempts to secure the delivery of electronic documents and files to designated and authorized recipients, e.g. attached to e-mails, and obtaining acknowledgment of receipt by designated persons had some disadvantages. The first limitation is that in general the delivery confirmation cannot positively show that the recipient has seen, read and in any other way became aware of the content of the received document. For example, according to earlier methods based on the presentation of private information about the recipient or on the digital signing of the confirmation of the message, the intended recipient may later disown confirmation [0007]. For example, the intended recipient may claim that such private information as the password had to be compromised and was provided by another recipient. In addition, the sender of the e-mail may receive automatic confirmation that the e-mail has been correctly delivered to the recipient's server and that the e-mail has been opened, but there is no verification and confirmation that the person who had access and opened the files attached to the e-mail is actually the intended recipient: in addition, there is no confirmation of opening the document, e.g. if, being both the intended recipient and another person, he actually opened or read the files or documents attached to the e-mail. In such a situation, the intended recipient can confirm that the e-mail has been received, but later deny that he was aware of all the e-mail content and / or the content of the files attached to the e-mail.

[0008] Although most modern email systems have the ability to configure email to send messages to the sender confirming receipt and opening of the email by the recipient (presumably, by the intended recipient), there is no equivalent mechanism to inform the sender that the file

- attached to the e-mail was opened by the recipient. In addition, there is no mechanism ensuring and confirming the e-mail sender that all files attached to the e-mail, even after attaching and saving for further processing, have been opened and that the authorized intended recipient had access to the files concerned.

[0009] US2003 / 0135740 to Talmor et al. Proposes a solution to authenticate electronic messages sent over the network using biometric control of the sender and recipient.

[0010] Consequently, there was a need to obtain a method and system enabling senders of electronic documents and files attached to e-mails to provide, verify and confirm in the assurance, verification and confirmation attached to the e-mail indisputably deliver these documents and files to the intended recipient.

Summary of the Invention [0011] The main purpose of this invention is to remedy the shortcomings of the previous solutions as described herein above.

[0012] An additional object of the invention is to provide an improved method and system for securing the delivery of electronic documents and files to the intended recipient.

[0013] Furthermore, the object of the invention is to provide an improved method and system for securing the delivery of electronic documents and files to intended recipients, adapted to verify the identity of the person requesting access to the file before providing the user access to the content of the file.

[0014] An additional object of the invention is to provide an improved method and systems ensuring delivery of electronic documents and files to the intended recipient, adapted to provide the sender of the file with undisputed confirmation of access to the file content by the intended recipient.

[0015] Further, another object of the invention is to provide an improved method and security systems for delivering electronic documents and files to the intended recipient using a voice seal.

[0016] Obtaining these and other related purposes is accomplished by coding the file in which it is to be sent via the computer network to the intended recipient, for authenticating the recipient and confirming receipt of the given file by the given intended recipient using biometric identification voice, method confirming the steps,

- coding key selection;

- associating the voice control ticket with the given coding key;

- specifying the address of the given voice control ticket containing at least the given coding key;

- encoding the file to be sent using the given encryption key; and,

- associating a given voice control ticket address with a given file by decoding a file encoded in accordance with the previous method, given method containing steps,

- recovering the address from the voice control ticket from the given file and decoding the address of the voice control ticket;

- recovering the voice control text associated with the given voice control ticket at the given address of the voice control ticket;

- sending readout of the given voice control text;

- receiving the decoding key, if the voice seal of the given record matches the voice seal assigned to the given voice control ticket; and,

- decoding a given file using a decoding key, and using the method of authenticating the recipient of the file encoded according to the previous method containing the steps,

- at the request of a given recipient, sending the voice check text associated with the voice control ticket whose address was received in the given request;

- after receiving the read text from a given recipient,

- recovering a voice seal from a given read text;

- comparing the given recovered voice seal with the voice seal associated with the recipient; and, if the recovered voice seal corresponds to the voice seal associated with the recipient, sending to the recipient a coding key associated with the given voice control ticket.

[0017] Further benefits of the present invention will become apparent to those skilled in the art upon examination of the drawings and detailed description. It is assumed that all additional benefits will be included here.

Brief description of the drawings [0018]

Figure 1 is an example showing how a user can record the voice of another person who wants to send a document according to the method of the invention.

Figure 2 illustrates an example of a system for determining and storing voice seals.

Figure 3 illustrates how, according to the invention, the voice control ticket associated with the encoded file to be transmitted is downloaded from the sender's computer to the voice control server.

Figure 4 shows a particular example of the invention where the sender attaches to the e-mail a coded file associated with the voice control ticket stored on the voice control server.

Figure 5 shows an example of voice control ticket processing when the recipient receives an encoded file containing the address or URL of the voice control ticket.

Figure 6 illustrates an example of a general algorithm for coding a document to be transmitted.

Figure 7 illustrates the main steps of the method according to the invention for confirming receipt of a file by the intended recipient, for checking the identity of the recipient and for providing the encryption key to the authorized recipient.

Figure 8 illustrates an example of the algorithm used to encode the address in the file name.

Detailed description of the preferred implementation [0019] According to the invention, a method and system for securing access to an electronically transmitted file will be discussed, and for verification and confirmation that the intended recipient has received and opened the file and that it will not be disclosed to anyone else. The basic principle is to combine a coding key with the recipient's voice seal, so that the encrypted file received by the recipient can be decoded using the coding key, key

- the coding is sent to the recipient after he has read the pre-determined text, if the voice seal in the read text corresponds to the voice seal of the recipient.

[0020] As is generally known, most biometric solutions create user voice seals, patterns of unique voice characteristics of a person, created when a user signs on to the system. All subsequent attempts to access the system require the user to speak, so that the voice sample can be once again compared with a previously registered pattern. For example, a reference to this topic is US Patent 6,529,871, filed by Kanevsky, entitled "Apparatus and methods for caller verification / identification / classification using non-acoustic and / or acoustic models and databases".

[0021] Figure 1 is an example showing how a user can record the voice of another person who wants to send a document according to the method of the invention. In this example, a portion of the telephone conversation is recorded in the voice database. As shown, user 100 having telephone 105 may call user 110 having telephone 115 via a standard switched telephone network (PSTN) 120. In this case, user 100 is designated as the sender and user 110 is designated as the recipient. During the conversation, the sender 100 may register a portion of the conversation so as to later define the voice seal of the recipient 110. In the preferred solution, the sender 100 registers the record of the recipient in the database of registered voices. Still in the preferred implementation, each recipient's voice record includes the recipient's name, the recipient's voice seal identifier, and the recipient's voice recording, as illustrated in reference to 125. The voice record database can be stored locally on the sender's computer or mobile device 130 or on a remote server (not shown) ) available through a public network, e.g. the Internet or a private network.

[0022] After registering the recipient's voice sample, the sender must specify the recipient's voice stamp. This can be done locally on the indicated server or on the specified voice checking server. For the sake of clarity, the determination of the voice seal and storage of the voice seal is performed on a specific voice check server as shown in figure 2. After

- the sender has recorded the recipient's voice sample as the recipient's voice record, the sample is sent, totally or in part, through a private or public network 200 e.g. Internet to a specific voice control server 205. Further, in the preferred solution, the voice sample is sent as an anonymous audio file. The voice check server 205 processes the voice sample, calculates and stores the voice seal of the recipient by assigning an identifier (ID) to the voice seal. The voice seal and its associated identifier are locally stored in the voice seal database 210. The voice seal ID is then sent to the sender's computer 130 where it is stored locally. For example, the voice tag ID may be stored in the recipient's voice record, as discussed above.

[0023] To encode the file to be sent, the sender 100 must first receive a sample of the recipient's voice and a voice seal identifier, as said above. Then the sender should create a voice control ticket. The sender may also make a request to a voice check server or a third party server for a voice check ticket. The voice check ticket mainly consists of a voice seal ID and coding key, as well as text to check the voice. The encryption key associated with the voice check ticket is used by the sender to encode the file to be sent. The voice check ticket is sent to the voice check server, and then sent back to the address or URL indicated in the voice check ticket, e.g. the address from which the voice check ticket can be downloaded. The address or URL of the voice control ticket is encoded in the name of the encoded file being sent.

[0024] Figure 3 illustrates how, according to the invention, the voice control ticket associated with the encoded file to be sent is downloaded from the sender's computer 130 to the voice control server 205. After the sender's computer has sent the voice check ticket to the voice check server, the voice check ticket should preferably be stored in the voice check ticket database 300 of the voice check server 205. As shown, voice control server 205 responds to the sender's computer 130 by sending the address or URL of the voice check ticket, e.g. the address or URL from which the ticket can be

- 7 EP 1 908 249 B1 to download. The address or URL is preferably stored in the reserved field of the local copy of the voice check ticket on the sender's computer 130.

[0025] Figure 4 shows an example of the use of this invention, where the sender, Lewis Carroll, attaches to the e-mail a coded file associated with the voice control ticket stored on the voice control server. When an email is received, the voice check ticket must be available to the recipient (Jane R. Friday) to verify its ID, to confirm receipt of the file, and to decode the file. This figure also illustrates how the address or URL of the voice check ticket (e.g. hyperlink<a href="http://www.woicecherk.com/tickets/R7KWW56T.vct">"Http://www.woicecherk.com/tickets/R7KWW56T.vct"</a>) can be encoded in the name of the attached file using specific lexicography. For example, a given lexicography involves replacing characters or a group of characters used in URL lexicography, such as ": //" and "/", by characters in lexicography of file names as ";" and "," respectively. According to the invention, when the e-mail recipient clicks on the attached file icon associated with the voice check ticket, the name of the attached file will be processed and the URL of the voice control ticket will be extracted and decoded from the same file name. With the use of the extracted URL, a hyperlink is launched that allows access and execution of the voice control on the voice control server and confirmation operations of the voice control ticket required to verify the receipt of the file by the intended recipient, as well as the receipt from the voice control server of the encryption key necessary for decoding the received file.

[0026] Figure 5 shows an example of processing a voice checking ticket when the recipient receives an encoded file containing the address or URL of the voice checking ticket. When the recipient 110 accesses the voice check ticket, the voice check ticket database 205 on the voice check server 205 retrieves the voice check text from the voice check ticket and then sends it from the voice control server to the recipient's computer or mobile device 400. The received text for checking the voice is displayed to the recipient to read aloud to obtain confirmation of receipt of the file and to verify the identification of the caller. As discussed above, the recipient is asked to read the text aloud to verify using speech recognition systems and to identify the voice and confirm that the recipient is

- a person authorized to open the file. After reading aloud the received text for the voice check, the recipient's speech 110 is preferably registered on the recipient's computer 400 and sent to the voice check server 205. The statements received on the voice check server 205 are decoded by the speech recognition system and compared with the text for checking the voice on the ticket voice checking. In addition, the voice seal of the received speech is calculated and comparable with the recorded voice seal file corresponding to the same voice seal identifier. If the result of both comparisons is positive, the identification of the intended recipient is verified, which causes the encryption key to be sent to the recipient's computer 400 to decode the file. By accessing and receiving the voice check ticket stored on the voice check server 205, the sender 100 obtains undisputed confirmation of receipt of the file by the intended recipient 110, or the awareness of the unsuccessful attempt to open the file by unauthorized recipients or impersonators.

[0027] Figure 6 illustrates an example of a general algorithm for coding a document to be transmitted. Depending on the implementation, the algorithm can be divided into several modules running on one or different computers or servers. According to the example in Figure 6, the algorithm is divided into three different parts, a module for the sender's computer 600 (or a network server available to the sender), a security server module (605) and a voice checking server module (610). After selecting, by entering via the keyboard, selecting from the list or other similar method of the interface the recipient name to which the document or file should be sent (step 615), the computer module at the sender 600 determines whether the voice stamp of the selected recipient already exists (step 620). For example, the sender's computer module 600 may store a table in which recipient names are associated with recipient identifiers (IDs) so that such identifiers can be used to select a particular voice seal from the voice seal database stored on the voice checking server. According to this example, checking whether a recipient's voice seal exists includes checking the recipient's name table in the table. If there is no voice seal for the selected recipient, the sender's computer module 600 receives the recipient's recording via the network interface, telephone system

Or any equivalent system (step 625). The recipient's recording is sent to the voice check server module from which it receives the appropriate ID (step 630). The voice checking server module 610 obtains a voice seal from the received recording of the recipient, specifies the identifier (ID) and stores this voice seal along with the corresponding identifier in the voice seal database (step 635). Note that, alternatively, the recipient can send the audio recording of his voice directly to the 610 voice check server module.

[0028] If a voice seal has been assigned to the selected recipient, the sender's computer module 600 sends a request to send the encryption key and voice check ticket (VCT) to the security server module 605 (step 640). As mentioned above, the security server module (605) can be connected to the sender's computer module 600 so that the encryption key generated in the sender's computer and the voice control ticket are also created on the sender's computer. Security server module 605 generates a coding key (step 645) for use by a standard predefined coding algorithm, for example a public key algorithm such as RSA. The encryption key is received by the sender using the sender's computer module 600 (step 650), which is used to encode the sent file (step 655). In addition, the server module 605 generates a voice check ticket (step 660). As discussed above, each voice check ticket should contain a voice seal identifier (ID), coding key, and voice check text. The voice seal identifier is determined by the sender's computer module 600 according to the selected recipient, while the coding key and voice control text are determined by the security server module 605. The coding keys are randomly generated according to a standard key generation algorithm. Voice check texts can be generated in a different way. For example, the text of the voice check may be written by the sender as a declaration by the recipient that the encoded file has been received. The voice check text can also be selected by the sender, e.g. by copying part of the email text to which the encoded file is attached. Alternatively, the voice check text may be generated automatically by the voice check server module 610, e.g. by random

Selecting text from a library of documents saved or downloaded from a given server.

[0029] Next, a voice check ticket (step 665) is sent to the voice check server module 610 to store the voice check ticket in the database (step 670). The voice check server module 610 returns the address or URL of the saved voice check ticket to the security server module 605 (step 675), which in turn sends the address or URL of the saved voice check ticket to the sender's computer module 600 (step 665). The address or URL of the saved voice check ticket is then encoded in the name of the file being transferred (step 680, in the sender's computer module 600. At this point, the file is ready for transmission because it is encoded and contains information allowing the intended recipient to decode it.

[0030] Figure 7 illustrates the main steps of the method according to the invention for confirming receipt of a file by the intended recipient, for verifying the identification of the recipient and for providing the coding key to the authorized recipient. Preferably, such an algorithm includes two different parts, the first of which is marked as 700 is implemented on the recipient's computer or mobile device, and the second is marked as 705 is implemented on the voice checking server. Upon receipt of the file encoded according to the method of the invention as described in reference to figure 6, for example as an e-mail attachment, the file name will be processed (step 710), and the address or URL of the voice check ticket is read and decoded from the name of the file being processed (step 715). Reading and decoding the address or URL from the processed file depends on the lexicography used in the encoding step. An example of lexicography, coding and decoding is described below. After receiving the address or URL, the voice check ticket is read (step 720) to get the voice check text contained in the voice check ticket (step 725). The text for checking the voice is displayed on the computer screen of the recipient so that he can read it aloud. The voice of the recipient reading the text is sent to the voice check server as an audio signal (step 730) in the form of an analog or digital signal. The received audio signal is processed into text by the voice check server (step 735) according to the standard speech recognition algorithm and

- a test comparing the processed text and the control text is performed (step 740). If the processed text differs from the control text, the recipient's request is rejected, otherwise if the processed text is identical to the control text, the voice seal of the received audio signal is determined (step 745). This voice seal is then compared to the seal assigned to the recipient's ID stored in the voice seal database on the voice check server (step 750). For example, the recipient ID can be sent by the recipient himself along with the audio recording. If the voice seals are different, the recipient's request is rejected, otherwise the voice check server sends the encryption key to the recipient's computer or mobile device (step 755), so that the received files are decoded on the recipient's computer (step760). In a given application of the invention, the voice check ticket voice check text is automatically changed to another text by the voice check server, so different voice check texts are sent for each attempt to access the file for identification. According to this solution, the voice check text is modified when the recipient is identified and the decoding key is sent to the recipient. Alternatively, in another embodiment of the invention, after identifying the recipient and sending the recipient the encryption key for the first time, the voice check ticket is automatically deleted and deleted from the voice check server, so after further decoding of the file further attempts to decode the same file will fail.

[0031] For encoding the address or URL in the file name, a specific lexicography has been specified for the message so as to avoid specific characters that can be blocked by the file naming system, e.g., n \ n in Microsoft Windows (Windows is a trademark of Microsoft Corporation), and / or encoding addresses to reduce their size. The coding address can be in any form, e.g. logical address, private network address or internet address, however, for purposes of illustration, the address given in the description below is based on URL addressing.

[0032] Figure 8 illustrates an example of an algorithm used to encode an address in a file name. As Figure 8a shows, the first step involves obtaining the original file name (step 800), e.g. file name and ticket address or URL

- checking the voice. The address is then encoded (step 810) and combined with the original file name using the specified separators (step 815) before the file name is changed to the name consisting of the original file name and the encoded address (step 820).

[0033] Figure 8b discusses an example of the coding algorithm referred to as step 810 in Figure 8a. The variable i is reset (step 825) and the ith character is downloaded from the address stream (step 830). A test is performed to determine whether the downloaded character is correct or whether its use due to file naming rules on the user's device is prohibited (step 835). If the downloaded character is a character that can be used when creating the file name, then the value of variable i is increased by one (step 850) and a test is performed to determine whether the variable i has reached its maximum value, which means that all characters in the address string have been processed (step 855). If the variable i has not reached its maximum value, the last four steps of the algorithm are repeated (steps 830 to 850). Otherwise, if the variable i has reached its maximum value, the process is stopped. If the character retrieved from the address string according to the rules for creating file names is not allowed, then the correct character or group of characters is selected from the lexicographic table 84.5 and this character or group of characters replaces the forbidden character (step 840). Then the value of the variable i is increased by one and the same text is executed as described earlier to determine whether the variable i has reached its maximum value.

[0034] As an illustration of the algorithm described above, let's consider the case of the text file name "Biometric.txt" that the user wants to send to someone else as an encoded email attachment, using a lexicographic table to encode the voice check ticket address in the file name , wherein":

// "is assigned to"; "

"/" is assigned to ",".

[0035] In order to obtain a voice check ticket allowing to open a file, it is necessary to access the voice check ticket corresponding to that file. For the purposes of illustration, assume that the voice check ticket can be downloaded from the following URL:

<a href="http://www.voicecheck.com/ticketS/R7KWW56.vct">http://www.voicecheck.com/ticketS/R7KWW56.vct</a>

[0036] Before the sender of the document "Biometric.txt" sends or attaches the document, select an option such as "encode file" that allows the file to be encoded to generate a voice check ticket and receive the address or URL of that check ticket voice.

[0037] The file name is modified according to the algorithm illustrated in figure 8. First, by using the previous lexicographic table, the address is coded as follows:

http;<a href="http://www.voicecheck.com.tickets.R7KWW56.vct">www.voicecheck.com.tickets.R7KWW56.vct</a> [0038] Then the coded address is combined with the file name.

In this example, the coded address is enclosed in brackets that were used as separators.

Then the coded address is placed before the dot of the extension of the original file name as follows:

Biornetric (http;<a href="http://www.voicecheck.com.tickets.R7KWW56.vct">www.voicecheck.com.tickets.R7KWW56.vct</a>) .txt and the file name is changed to the modified file name.

[0039] It should be noted that, for purposes of illustration, this coded algorithm is very simplified. Preferred should contain a replacement of the reserved character sequence into a single one for more compact code, e.g. by replacing "http: /" with the symbol "H!".

[0040] Among the advantages of the invention, it should be noted that

- the sender protects the files sent to the recipient by ensuring and obtaining confirmation that these files have been opened only by the intended recipient;

- the sender of the file receives an indisputable confirmation of receipt of the file by the intended recipient, and is also informed about an unsuccessful attempt to open the file by unauthorized recipients, including impersonators; and

- by recognizing your voice, the user can selectively protect any file from unauthorized access by other people.

[0041] Naturally, to meet local or specific requirements, a qualified person may introduce into the above-described solution many modifications and changes, all of which are included in the scope of protection of the invention as defined in the following claims.

- EP 1 908 249 B1