MXPA06004501A - Deliver-upon-request secure electronic message system - Google Patents

Abstract

A method of delivering electronic mail messages upon requests and managing public-secret key pairs of public key cryptography in an electronic message system. A sending party sends an intend-to-deliver associated with an electronic mail message to an intended receiving party. The intended receiving party responds with a request-for-mail-content to request for the electronic mail message if the intended receiving party determines to do so. The sending party will not deliver the electronic mail message to the intended receiving party if the intended receiving party does not send the request-for-mail-content. A host computer is assigned with a unique name that is registered with authoritative organizations and can be used for establishing a connection to the host computer. The host computer provides the public keys of its account holders to the public. The initial public key of an account holder is certified by the host computer using an account password. The account holder may regenerate a public-secret key pair as often as needed. The new public key is certified by the host computer using the old public key of the account holder and becomes effective for providing to the public.

Description

SECURE SYSTEM OF ELECTRONIC DELIVERY MESSAGES-PQR-SQLICITUD FIELD OF THE INVENTION The present invention relates to electronic message systems, and very specifically it relates to an electronic message system and method that allows a recipient to determine whether he wishes to collect the complete content of an electronic mail message from the source of the electronic message before This is delivered to the recipient's email mailbox, and manages pairs of public-secret keys of public key cryptography to execute the authentication, certification and privacy of the communication.

Definition The above objectives as well as others of the present invention, the various characteristics thereof, as well as the invention itself, can be understood more fully based on the following definition of terms: Term Definition Electronic Message ün message (may contain text, image, audio, voice, video, or combinations thereof) processed in computer systems and delivered over communication networks. Mail Message ün Electronic Message that is Electronic delivered and placed in computer systems waiting for access. Interactive Message An Electronic Message that is Electronic transmitted for interactive communication. Central Computer ün a computer system that includes hardware and software to which its users have access in communication networks. Local Computer A computer system comprising hardware and software in which a user works locally. Apparatus of an electronic device that has the communication ability to send and receive Electronic Messages as a Local Computer but with less computing power or storage capacity, preferably a mobile device that can be connected to communication networks.

Sender A user or a software agent that uses a Local Computer or Communication Device to send an Outgoing Email Message or to initiate an interactive communication over communication networks. Recipient A user or software agent that uses a Local Computer or Communication Device to access an incoming Email Message or to respond to an interactive communication over communication networks. Part that sends a Sender, a Local Computer or Communication Device that a Sender uses, or a Central Computer that manages the Sender's account. Party Receiving a Recipient, a Local Computer or Communication Device that a Recipient uses, or a Central Computer that manages the Recipient's account.

BACKGROUND OF THE INVENTION The Electronic Mail Systems are executed to deliver E-mail Messages as long as the E-Mail Addresses of the Recipients are known. Any Sender can send any Email Message, even if it is not desired, to the Recipient's Inbox and consumes the Recipient's available resources. Furthermore, in the prior art, the sending party only leaves certain non-certified information about the part sent in the Email Message. If the sending party falsifies information, the true source of the Email Message may not be disclosed. As a result, SPAM and e-mail messages that carry computer viruses or malicious programs can spread widely without there being an easy way to track them. One of the key factors of the problems is due to the send-and-go form that exists to deliver E-mail Messages. In the prior art, Public Key Cryptography can be used for authentication and communication certification. Typical steps involved in packing an Email Message encrypted with an Electronic Signature of the Sender are as follows: 1.- Write an Email Message. 2.- Use a summary function algorithm to generate a message digest of the e-mail message written. 3.- Use Public Key Cryptography to encrypt the Message Compendium with the Secret Key of the Sender as the Electronic Signature of the Sender. 4.- Attach the Electronic Signature of the Sender to the Email message written. 5.- Generate a Session Key randomly chosen from Private Key Cryptography. 6.- Use the Private Key Cryptography to encrypt the Composite Email Message and the Electronic Signature of the Sender annexed with the chosen Session Key. 7.- Use Public Key Cryptography to encrypt the Session Key with the Public Key of the Recipient. 8.- Send to the Recipient the encrypted Email Message that includes the Electronic Signature of the Sender and the Encrypted Session Password. And typical steps involved in unpacking an encrypted Email Message that includes an Electronic Signature of the Sender and a Session Key encrypted by the Recipient are as follows: 1.- Use Public Key Cryptography to decrypt the encrypted Session Key with the Secret Key of the Sender, obtain the Session Key. 2. - Use the Private Key Cryptography to decrypt the Encrypted Email Message including the Electronic Signature of the Sender with the Passcode, obtain the Email Message in a format that can be understood and the Electronic Signature of the Sender. 3.- Use the Public Key Cryptography to decrypt the Sender's Electronic Signature with the Public Key of the Sender, obtain the Message Compendium created by the Sender. 4.- Use the same summary function algorithm to generate a new Message Compendium of the received Email Message. 5.- Compare the new Message Compendium with the Message Compendium received to guarantee that the two Message Compendiums are identical. There are two fundamental restrictions in the previous steps, how to obtain the Public Key of a person and how to certify their legitimacy. Some approaches have been proposed, such as exchanging Public Keys in advance between people; use key networks to have other people's Public Keys; obtain Public Keys from third-party servers that maintain the Public Keys of persons; obtain digital certificates of Public Keys from a commercial certification authority through the presentation of people's driving licenses, original birth certificates, passports, or similar to provide the identity of the persons; certify the Public Keys through trusted people with the Electronic Signatures of people in Public Keys of third parties; etc., all this requires uncomfortable procedures in which users have to be involved. Due to the complexity of distributing and certifying Public Keys, this becomes impractical to regenerate Public-Secret Password Pairs for security purposes as people have been doing for the passwords of their Electronic Message Systems accounts. The Interactive Communication Systems Electronics such as Microsoft Instant Messenger or similar, only allow people to communicate with each other through a common service provider. To communicate with someone, the initiator has to make sure that the interviewee has already registered with the identical service provider. People can not communicate as freely as when they use the Electronic Mail System between different service providers. Many Electronic Message Systems choose user IDs and passwords for the authentication of financial services such as transfer funds. One of the biggest drawbacks of using user IDs and passwords is that all the information needed to authorize a transfer of funds could be obtained from a single source, the service provider. The user IDs and passwords of many accounts could be stolen either by cyber hackers or disloyal employees. Because it is more difficult to steal an equivalent amount of information from individuals, one by one, that from a single source, it would be safer to use Public Key Cryptography for the transfer of funds and let each account holder keep his own Secret Key in private. However, the prior art lacks an effective method to distribute, certify and maintain Public Keys. Another drawback of using user IDs and passwords is the lack of certification of the content of the Electronic Message such as the amount of the fund, the beneficiary of the fund, etc. Some Electronic Message Systems do not even have capabilities for authentication. The use of a credit card to pay for goods online is an example. There is NO way by which a merchant can know if the buyer is the true holder of the credit account or if it is just a person who knows someone else's credit card number. Many Electronic Message Systems provide license agreements for services or software and request licenses to click on the "Accept" button on the Local Computers screen of the license holders that denote the acceptance of the license agreements. This approach does not provide authentication of the identities of the license holders or certification of the content of the license agreements. After downloading or receiving computer software from the Electronic Message System of a developer or distributor, the user can not assure if the computer software has been altered with programs integrated by cyber pirates. In the prior art, although many methods are used by computer software vendors to carry out the protection of reproduction rights for their products, the general approach for sellers is to create and provide security keys to the license holders. In the case in which any convict infringes the reproduction rights to redistribute the computer software with a valid security key obtained from the vendor, it is questionable who is the person who actually reveals the security key.

SUMMARY OF THE INVENTION In order to achieve these and other advantages and to overcome the disadvantages of the conventional method according to the purpose of the invention as incorporated herein and broadly described, the present invention provides an electronic message system and method that allows a intended recipient determine whether or not you want to collect the complete content of an email message from the source of the electronic message before it is delivered to the Recipient Email Mailbox, and manage public-secret keys for public key cryptography keys to execute the authentication, certification and privacy of communication. The present invention allows an intended Recipient to see certain basic information of an Email Message and determine whether or not to receive the complete content of the Email Message before delivering it to the Recipient's Electronic Mailbox. Therefore, the Recipient's resources will not be consumed by unwanted e-mail messages. With the present invention, if the Recipient determines to receive the complete content of an Email Message, the Email Message will be collected from the sending party. In order to deliver an Email Message successfully, the Central Computer that originates the delivery of the Email Message must always be within reach and must await the answer of the intended Recipient. In other words, the source of the Email Message can be identified and the identity of the Sender could be more traceable. This feature will eliminate the possibilities of hiding the origins of SPAM and Email Messages that carry computer viruses and malicious programs. The creators of junk mail and cyber pirates, who take advantage of the Electronic Mail Systems to disseminate commercial information or destructive effects, have to reveal their identities, or at least, the identities of their Central Computers. And more likely, the revelation of their true identity would scare malicious or annoying convicts, especially if they have to face the law. The present invention can free users from problems involving the distribution, certification and maintenance of other people's Public Keys. This allows users, from the point of view of the application, without getting involved in the procedures, simply enabling functions such as "sign the message", "seal the message", etc. The present invention allows the Sender, without being concerned about the issues of the Security Keys, to simply decide whether or not to add his Electronic Signature to an Electronic Message to exit, whether or not to maintain a private Electronic Message during the delivery, and ensure that only the intended Recipient can interpret the Electronic Message in an understandable format. The present invention allows the Recipient, without being concerned about the matters of the Security Keys, to protect the content of an Electronic Message against others, to authenticate the identity of the Sender, to guarantee that the Electronic Message has not been modified, and to obtain a certification from the Electronic Message. Email Message that the Sender can not deny later. Furthermore, the present invention allows the Recipient to choose to keep the Electronic Message private during delivery, even if the Sender did not do so, without requiring the Sender to re-elaborate the Email Message. The present invention also allows the user to regenerate the Public-Secret Pairs of Pairs as often as necessary. The corresponding changes will be automatically updated by the system without the intervention of the user, and the new Pair of Secret-Public Keys will be effective immediately. The present invention allows people to communicate interactively with each other without there being the need to add a common service provider. The initiator of an interactive communication does not have to worry about whether the interviewee has an account with the same service provider. People can establish an interactive communication as long as the initiator knows the email address of the interviewee. The present invention provides a method for authenticating the identities of users and certifying the content of the Electronic Messages over communication networks such as the electronic bank., the electronic payment to make purchases, the electronic signature in a contract, etc. The present invention provides a certification method to ensure that the computer software is not tampered with. It also provides a method to track the licensee who illegally distributes computer software by disclosing a Secret Key that only the licensee knows. Another advantage of the present invention is that the sending parties will be responsible for maintaining and delivering the complete content of the E-Mail Messages they initiate. And therefore, the parties that receive will not be faced with an unexpected workload. Furthermore, the present invention establishes that only one copy of each E-mail Message will be collected by each Recipient, one by one, if there are multiple Recipients. As a result, E-mail messages that carry computer viruses and malicious programs can not be spread nor can they be automatically forwarded. With the present invention, due to the possibilities of reducing SPAM and ill-intentioned Electronic Messages, traffic in communication networks can also be improved. These and other objects of the present invention will become obvious to those skilled in the art upon reading the following detailed description of the preferred embodiments. It will be understood that the foregoing general description and the following detailed description are exemplary, and that they are intended to provide a further explanation of the invention as claimed.

BRIEF DESCRIPTION OF THE FIGURES The appended figures are included to provide a further understanding of the invention, and are incorporated in this description and form a part thereof. The figures illustrate embodiments of the invention and, together with the description, serve to explain the principles of the invention. In the figures, Figure 1 is a block diagram illustrating a secure electronic delivery-by-request message system for delivering an Email Message according to one embodiment of the present invention; Figure 2 is a block diagram illustrating a secure electronic delivery-by-request message system for interactive communication in accordance with one embodiment of the present invention; Figure 3 is a block diagram illustrating a secure electronic delivery-by-request message system in which both the Source Message Server and the Destination Message Server are in a single Central Computer to deliver an electronic message of agreement. with one embodiment of the present invention; Figure 4 is a block diagram illustrating a secure electronic delivery-by-request message system where both the Source Message Server and the Destination Message Server are in a single Central Computer for interactive communication in accordance with a embodiment of the present invention; Figure 5 is a block diagram illustrating a secure electronic delivery-per-request message system in terms of the management of Security Keys according to one embodiment of the present invention; and Figure 6 is a block diagram illustrating a secure electronic delivery-by-request message system in terms of the management of Security Keys involving the server of a third party in accordance with an embodiment of the present invention.

DESCRIPTION OF THE PREFERRED MODALITIES Reference will now be made in detail to the preferred embodiments of the present invention, examples of which are illustrated in the appended figures. Whenever possible, the same reference numbers will be used in the figures and the description to refer to similar or equal parts. Figure 1 shows an exemplary embodiment of the present invention for delivering an Email Message. A Source Message Client 11, which is a Local Computer or Communication Device used by a Sender, transmits the Email Message for delivery to a intended Email Address. A Message Server Source 12, which is a Central Computer that manages the Sender's account, receives the Message from the Customer of the Message Source 11 for delivery to the intended Email Address. A Destination Message Server 14, which is a Central Computer that manages an Email Mailbox associated with the intended Email Address to which a Recipient is entitled, receives the Email Message as the final destination. A Destination Message Client 15, which is a Local Computer or Communication Device used by the Recipient, enters the incoming E-Mail Messages in the E-Mail Inbox. The Source Message Client 11, the Source Message Server 12, the Destination Message Server 14, and the Destination Message Client 15 are connected to the communication networks. Each of the Source Message Server 12 and the Destination Message Server 14 is assigned a unique name such as Domain Name that is registered with authoritative organizations and can be used to establish a connection. For a single Central Computer, which functions as a Source Message Server for issuing Email Messages and as a Destination Message Server for the entry of Email Messages, only a single Domain Name is needed. The Source Message Client 11, the Source Message Server 12, the Destination Message Server 14, and the Destination Message Client 15 have capabilities to generate Public-Secret Key Pairs, encrypt and decrypt Electronic Messages using Key Cryptography Public Additionally, both the Message Client Source 11 as the Destination Message Client 15 has capabilities to encrypt and decrypt Electronic Messages using Private Key Cryptography, and create Electronic Message Message Compendiums using a summary function algorithm. The Source 12 Message Server (or Destination Message Server 14) generates a pair of initial Post-Secret Keys when it is configured to provide cryptography services, and regenerates a new Post-Secret Pair of Keys later, whenever necessary . The Source Message Server 12 (or Destination Message Server 14) maintains a Public-Secret Key Set that contains a Post-Secret Pair of Keys and a Key Generation Time, which is the Greenwich Mean Time at which the Pair of Public-Secret Keys is generated, of all the versions. All Secret Keys are kept private by the Source 12 Message Server (or Destination Message Server 14). The Messaging Server Source 12 (or Destination Message Server 14) provides its Public Key Set, which contains the Public Key and the Key Generation Time, to its account holders and other parties as described in the following paragraphs. In addition, the Source 12 Message Server (or Destination Message Server 14) provides a mechanism, such as the use of the File Transfer Protocol (ftp) to exchange files on the Internet, for the public to download their Set of Keys. Most updated public. For a single Central Computer, which functions as a Source Message Server for Outgoing Email Messages and as a Destination Message Server for incoming Email Messages, the Post-Secret Pair of Pairs need only be generated once instead of twice as a Source Message Server and as a separate Destination Message Server. Typical steps for obtaining the Public Key Set of the Source Message Server 12 (or Destination Message Server 14) by the Source Message Client 11 (or Destination Message Client 15) for the first time are the following: 1 - Initially, when the Sender (or Recipient) uses the Source Message Client 11 (or Destination Message Client 15) to establish a new account corresponding to an Email Address with the Messaging Server Source 12 (or Messaging Server). Destination Messages 14), the Source 12 Message Server (or Destination Message Server 14) encrypts its most up-to-date Public Key Set with the associated Secret Key. 2.- The Source Message Server 12 (or Destination Message Server 14) provides, as an Information Flow 22, (or Information Flow 26), the set of Public Keys encrypted to the Message Source Client 11 (or Client). of Destination Message 15). 3. - At the moment of receiving the Set of Keys Public encrypted, the Source Message Client 11 (or Destination Message Client 15) downloads, based on a mechanism provided by the Source 12 Message Server (or Destination Message Server 14) to the public, the Set of Keys Most up-to-date Public Messages from the Source 12 Message Server (or Destination Message Server 14). 4.- The Message Source 11 Client (or Destination Message Client 15) decrypts the Public Keys Set encrypted with the downloaded Public Key to authenticate the identity of the Message Server Source 12 (or Destination Message Server 14), and ensures that the Set of Public Keys obtained from the decryption is identical to the set of Public Keys downloaded. 5.- If the decryption is successful and the two Sets of Public Keys are identical, the Message Source Client 11 (or Destination Message Client 15) will maintain the Public Key Set obtained from the decryption. 6.- If the decryption fails or both Sets of Public Keys are not identical, the Sender (or Recipient) needs to contact the administrators of the Source 12 Message Server (or Destination Message Server 14) to clarify things. The previous steps (1) to (6) only have to be executed once for an account as a user instead of twice as a Sender and a separate Recipient. If the Source Message Client 11 (or Customer of Destiny Message 15) has already published a Set of Public Keys of the Source Message Server 12 (or Destination Message Server 14), the typical steps for updating the Set of Public Keys are the following: 1.- Whenever the Client of Message Source 11 (or Destination Message Client 15) establish a connection to the Source Message Server 12 (or Destination Message Server 14), the Message Source Client 11 (or Destination Message Client 15) provides, as a Flow of Information 21 (or Information Flow 25) the last Key Generation Time received from the Server Source 12 messages (or Destination Message Server 14) to the Source 12 Message Server (or Destination Message Server 14). 2.- The Source 12 Message Server (or Destination Message Server 14) identifies its Secret Key associated with the Key Generation Time, encrypts its Most updated set of Public Keys with the identified Secret Key. 3.- The Message Server 12 Source (or Destination Message Server 14) provides, as a Flow of Information 22 (or Information Flow 26), the Set of Public Keys encrypted to Message Source Client 11 (or Destination Message Client 15). 4.- The Message Source Client 11 (or Customer of Destination Message 15) decrypts the Set of Keys Public encrypted with the last Public Key received from the Source Message Server 12 (or Destination Message Server 14) to authenticate the identity of the Source Message Server 12 (or Destination Message Server 14) and to obtain the Set of Public Keys Most updated of the Source Message Server 12 (or Destination Message Server 14), then updates the maintained Public Key Set of the Source Message Server 12 (or Destination Message Server 14) if necessary. Again, the steps above (1) to (4) only have to be executed once for an account as a user instead of twice as a Sender and a Recipient separately. Each of the Source Message Server 12 and the Destination Message Server 14 maintains a Server Database that contains information records of other Destination Message Servers or Source Message Servers such as Registered Domain Names, Public Keys, Key generation hours, etc. When a Destination Message Server 14 (or Source Message Server 12), referred to as "the initiating party" in the following description, establishes a connection to a Source Message Server 12 (or Destination Message Server 14), named "the responding party" in the following description, using a Registered Domain Name of the responding party, if the initiating party does not have any Set of Public Keys of the responding party, the initiating party will request the party that responds it responds to provide its Set of Public Keys. The typical steps are the following: 1. The initiating party will request the responding party to provide the Set of Public Keys of the responding party. 2.- The responding party encrypts its most updated Set of Public Keys with the associated Secret Key, provides, as an Information Flow 32 (or Information Flow 31), the Set of encrypted Public Keys and a mechanism to download its Set of most updated Public Keys to the party that initiates. 3.- The party that initiates unloads the Set of Public Keys of the responding party. 4.- The initiating party decrypts the Encrypted Public Key Set with the downloaded Public Key, and guarantees that the Set of Public Keys obtained from the decryption is identical to the Set of Public Keys downloaded. If the decryption is successful and the two Public Key Sets are identical, the initiating party adds the Public Key Set derived from the decryption to its Server Database. In the previous case of establishing a connection between the initiating party and the responding party, if the initiating party already has a Set of Public Keys of the responding party in its Server Database, the initiating party will update the Set of Public Keys of the responding party. The typical steps are the following: 1. - The initiating party provides, as a Flow of Information 31 (or Information Flow 32), the last Key Generation Time received from the party that responds to the responding party. 2.- The responding party identifies its Secret Key associated with the Key Generation Time, encrypts its most updated Set of Public Keys with the identified Secret Key, and provides, as an Information Flow 32 (or Information Flow 31) , the Set of Public Keys encrypted to the starting party. 3.- The initiating party decrypts the Encrypted Public Key Set with the last Public Key received from the responding party to authenticate the identity of the responding party and to obtain the most updated Set of Public Keys from the responding party, and then update the Public Key Set of the responding party in its Server Database if necessary. In the previous case of establishing a connection between the initiating party and the responding party, if the responding party does not have any Set of Public Keys of the party initiating in its Server Database, the responding party shall establish a connection to the party that initiates using the Registered Domain Name of the party that initiates to obtain the Set of Public Keys of the party that initiates. The typical steps are as follows: 1. The responding party will request the party that initiates to provide the Registered Domain Name of the initiating party. 2.- The starting party provides, as a Flow of Information 31 (or Information Flow 32) your Registered Domain Name to the responding party. 3.- Immediately after this connection is closed, the responding party will establish a connection with the party that initiates using the Registered Domain Name provided, then follow the steps as in the previous description to obtain the Set of Public Keys of the part that starts by investing the roles of the initiating party and the responding party since the new party that initiates does not have any Set of Public Keys of the new respondent party. In the previous case of the establishment of a connection between the initiating party and the responding party, if the responding party already has a Set of Public Keys of the party initiating in its Server Database, the responding party will update the Set of Public Keys of the part that starts. Typical steps are as follows: 1. The responding party provides, as an Information Flow 32 (or Information Flow 31), the last Key Generation Time received from the party initiating the initiating party. 2.- The initiating party identifies its Secret Key associated with the Key Generation Time, encrypts its most updated Set of Public Keys with the identified Secret Key, and provides, as an Information Flow 31 (or Information Flow 32) , the set of public keys encrypted to the responding party. 3.- The responding party decrypts the Encrypted Public Key Set with the last Public Key received from the party that initiates to authenticate the identity of the initiating party and to obtain the most updated Set of Public Keys of the initiating party, and then update the Public Key Set of the part that starts in its Server Database if necessary. Provided the Destination Message Client 15 (or Source Message Client 11) of the Recipient (or Sender) initially generates or regenerates a Post-Secret Pair of Keys, the Post-Secret Pair of Keys will remain in the Target Message Client 15 (or Source Message Client 11), the Public Key must be reported to, and maintained. in the Destination Message Server 14 (or Source Message Server 12) with whom the Recipient (or Sender) has an account. The Destination Message Server 14 (or Source Message Server 12) maintains a Customer Database that contains the records of the information of the accounts of its users such as the Email Addresses, Public Keys, Key Generation Hours, etc. Typical steps for generating and maintaining a Post-Secret Pair of Initial User Keys are as follows: 1. Initially, when a Recipient (or Sender) establishes an account with a Destination Message Server 14 (or Message Server) Source 12), the Recipient (or Sender) uses a Destination Message Client 15 (or Source Message Client 11) to register on the Destination Message Server 14 (or Source Message Server 12) using the user ID and The password of the Recipient (or Sender). 2. The Destination Message Server 14 (or Source Message Server 12) provides its most updated Set of Public Keys to the Destination Message Client 15 (or Source Message Client 11) as described in previous paragraphs. 3. The Destination Message Client 15 (or Source Message Client 11) generates a pair of initial Post-Secret Keys, and maintains a Set of Public-Secret Keys that contains the Post-Secret Pair of Keys and the Time of Password. Key generation. 4.- The Destination Message Client 15 (or the Source Message Client 11) keeps the Secret Key private. 5. - The Destination Message Client 15 (or Message Server Source 11) encrypts the password of the Recipient (or Sender) and a Set of Public Keys, which contains the Public Key and the Generation Time of the Recipient (or Sender's) Password, with the Public Key of the Messaging Server of Destination 14 (or Source Server 12). 6.- The Destination Message Client 15 (or Source Message Client 11) reports, as an Information Flow 25 (or Information Flow 21), the password and Public Key Set encrypted to the Destination Message Server 14 (or Source Server 12). 7. The Destination Message Server 14 (or Source Message Server 12) decrypts the password and Public Key Set encrypted with the Secret Key of the Destination Message Server 14 (or Source Message Server 12), and ensures that the password is legitimate. 8.- If the decryption is successful and the password is legitimate, the Destination Message Server 14 (or Source Message Server 12) adds the Set of Public Keys associated with the Recipient's account (or Sender) to its Customer Database. 9.- If the decryption fails or the password is not legitimate, the administrators of the Destination Message Server 14 (or Source Message Server 12) need to clarify things. As a common practice, the user usually works on a single Local Computer or Communication Device, which functions as a Source Message Client for Outgoing Electronic Messages and as a Destination Message Client for incoming Email Messages from the account of a user, to communicate with a single Central Computer, which functions as a Source Message Server for outgoing E-mail Messages and as a Destination Message Server for incoming E-mail Messages from the accounts of its users Therefore, steps above (1) to (9) only have to be executed once for an account as a user instead of twice as a Sender and a Recipient separately.

Typical steps to regenerate and maintain the User's Post-Secret Password Pair are as follows: 1.- Whenever the Destination Message Client 15 (or Source Message Client 11) regenerates the Post-Secret Pair of Recipient Keys. (or Sender) associated with the Recipient's (or Sender's) account, the Destination Message Client 15 (or Source Message Client 11) will keep the new Set of Keys PublishSecret as the most current version at the same time that all the Sets of Previous Public-Secret Keys. 2.- The Destination Message Client 15 (or Source Message Client 11) keeps all the Secret Keys private. 3. The Destination Message Client 15 (or Source Message Client 11) encrypts the new Set of Public Keys of the Recipient (or Sender) with the last Secret Key of the Recipient (or Sender). 4. - The Destination Message Client 15 (or Message Client Source 11) reports, as an Information Flow 25 (or Information Flow 21), the new Set of Public Keys encrypted to the Destination Message Server 14 (or Source Message Server 12). 5.- The Destination Message Server 14 (or Source Message Server 12) decrypts the new Public Keys Encrypted with the last Public Key of the Recipient (or Sender) to authenticate the identity of the Recipient (or Sender) and obtain the new Set of Public Keys of the Recipient (or Sender). 6.- If the decryption is successful, the Destination Message Server 14 (or Source Message Server 12) updates the Public Key Set associated with the Recipient's (or Sender's) account in its Customer Database. 1 . - If the decryption fails, the administrators of the Destination Message Server 14 (or Source Message Server 12) need to clarify things. Again, usually the previous steps (1) to (7) only have to be executed once as a user instead of twice as a Sender and a Recipient separately. Based on the above description, the Source Message Server 12 and the Destination Message Server 14 maintain the Public Key Set of their account holder; the Message Source Client 11 and the Destination Message Client 15 of the user maintain the Set of Public Keys of the Source Message Server 12 and the Destination Message Server 14 that manage the user's account; and the Source Message Server 12 and the Destination Message Server 14 maintain the Public Key Set of the other as long as a connection has been established; Public Key Sets maintained are necessary to deliver an Email Message in a secure manner. The typical steps for delivering an Email Message from a Sender to an intended Recipient are as follows: 1. The Sender uses a Source Message Client 11 to compose an Email Message to deliver it to an Email Address at that the Recipient is entitled, and specifies a due condition of the Email Message such as "after delivered to all Recipients", on a fixed date, or a combination of both, etc. 2.- The Message Source Client 11 establishes a connection with a Source Message Server 12 with whom the Sender has an account, receives (an Information Flow 22) and updates the Public Key Set of the Source Message Server 12 as described in the previous paragraphs. 3.- The Message 11 Source Client transmits (an Information Flow 21) the Email Message to the Message Server 12 Source. 4. - At the moment of receiving the Email Message, the Message Server 12 Source keeps it in an Outgoing Email Mailbox specifically assigned to the Sender's account. 5.- The Message Server Source 12 creates an Attempt-of-Delivery that is an Email Message that contains the name of the Sender, the Email Address of the Sender, a subject, a date of sending, some identification codes of the Email Message, the Registered Domain Name of the Source Message Server 12, and the Set of Public Keys of the Source Message Server 12, the Set of Public Keys associated with the Sender's account, etc. 6. The Messaging Server Source 12 sends (an Information Flow 23) the Intent-of-Delivery to the Email Address. The typical procedure is to deliver the Delivery Attempt, as does the Simple Mail Transfer Protocol (SMTP) for an Email Message in the prior art, in a transport service environment that provides an inter-communication environment. -process that covers the communication networks. In the inter-process communication environment, the Intent-of-Delivery is transported through some Intermediate Message Transporters, which receive an Email Message from a Central Computer and transport the received Email Message to another Computer. Central for delivery to the E-Mail Address, until arriving at a Destination Message Server 14, which manages an Electronic Mailbox associated with the E-Mail Address, as the final destination. 1 . - At the moment of receiving the Intent-of-Delivery, the Destination Message Server 14 encrypts the Set of Public Keys of the Recipient with the Secret Key of the Destination Message Server 14. 8. - The Destination Message Server 14 establishes a connection to the Message Server 12 Source using the Registered Domain Name of the Message Server Source 12, provides (an Information Flow 31) the Set of Encrypted Public Keys of the Recipient and the Registered Domain Name of the Destination Message Server 14 to the Message Server Source 12. The Destination Message Server 14 and the Source Message Server 12 also update the Public Key Set of the other, as described in the previous paragraphs. 9.- After receiving the Set of Encrypted Public Keys from the Recipient and updating the Set of Public Keys of the Destination Message Server 14, the Source 12 Message Server will decrypt the Enciphered Public Keys Set of the Recipient with the Public Key of the Destination Message Server 14 to obtain and maintain the Set of Public Keys of the Recipient. 10.- After providing the Enciphered Public Key Set of the Recipient to the Source Message Server 12, the Destination Message Server 14 will append the Key Generation Time of the Set of Public Keys of the Recipient to the Attempt-to-Delivery, and will deposit the Intent-of-Delivery in an Electronic Mailbox so that the Recipient has access. 11. The Recipient uses a Destination Message Client 15 to establish a connection to the Destination Message Server 14, receive (an Information Flow 26) and update the Public Key Set of the Destination Message Server 14 as described in previous paragraphs, having access (an Information Flow 26) to the incoming Mailbox of the Recipient for any incoming Email Messages including the Attempt-to-Delivery. 12.- If the Recipient determines to receive the Email Message corresponding to the Attempt-to-Delivery, the Recipient uses the Destination Message Client 15 to identify the Secret Key of the Recipient associated with the Key Generation Time annexed in the Attempt-to-Delivery. 13. - The Destination Message Client 15 creates authentication information, which is a series of data codes encrypted with the identified Secret Key. 14.- The Destination Message Client 15 creates a Mail-Content-Request which is an Electronic Message containing the identification codes of the Electronic Mail Message, the Recipient's Electronic Mail Address, and the authentication information. 15. The Destination Message Client 15 establishes a connection to the Source Message Server 12 using the Registered Domain Name of the Source Message Server 12, and provides (an Information Flow 27) the Content-Request-of -Mail to Message Server Source 12. 16.- At the moment of receiving the Request-of-Content-of-Mail, the Message Server Source 12 identifies the Public Key of the Recipient using the identification codes of the Email Message and The Recipient's Email Address, decrypts the authentication information with the identified Public Key to authenticate the identity of the Recipient. 17.- If the identity of the Recipient is successfully authenticated, the Source Message Server 12 provides (an Information Flow 28) the Email Message to the Destination Message Client 15, and records a delivery status such as "delivered to xxx "associated with the Email Message. 18.- If there are multiple Recipients, the previous steps (7) to (17) should be executed for each Recipient separately. 19.- Based on the expiration condition of the Email Message, the Source Message Server 12 deletes the Email Message from the Outgoing Mailbox of the Sender. When the Destination Message Client 15 sends a Mail-Content-Request, even if the Sender did not encrypt the Email Message, the Recipient may order (an Information Flow 27) to the Source Message Server 12 that Do it. Typical steps are the following: 1. When the Destination Message Client 15 sends a Mail-Content-Request to the Server of Messages Source 12, Destination Message Client 15 adds to the Mail-Content-Request an instruction to encrypt the Email Message. 2.- After receiving the Mail-Content-Request and authenticating the identity of the Recipient as in the previous description, based on the encryption instruction, the Source Message Server 12 randomly chooses a Password of Private Key Cryptography Session, encrypts the E-mail Message with the Session Key chosen using the Private Key Cryptography, and then encrypts the Session Key with the Public Key of the Recipient using Public Key Cryptography. 3. The Messaging Server Source 12 provides (an Information Flow 28) the encrypted Email Message and the encrypted Session Password to the Destination Message Client 15. 4.- After receiving the encrypted Email Message and the Encrypted Session Key, the Destination Message Client 15 decrypts the Session Key encrypted with the Secret Key of the Recipient to obtain the Session Key, and then decrypts the Email Message encrypted with the Login Key to obtain the Message of Electronic Mail in a format that can be understood. For convenience, the Recipient may provide a list of Email Addresses to the Destination Message Server 14 and authorize the Destination Message Server 14 to automatically collect all the Email Messages sent from the listed Email Addresses. The typical steps are as follows: 1. Initially, the Recipient uses the Destination Message Client 15 to provide (an Information Flow 25) a list of Mail Addresses Electronic to the Destination Message Server 14. 2. - At the time of receiving an Attempt-to-Delivery for the Recipient, the Destination Message Server 14 verifies the Sender's Email Address against the list of Email Addresses. If the The sender's e-mail address is covered by the list of e-mail addresses, the Destination Message Server 14 will provide (a Flow of Information 31) the Set of Public Keys of the Destination Message Server 14, instead of the Set of Keys Public of the Recipient, to the Message Server Source 12. 3.- After, the Destination Message Server 14 sends (an Information Flow 31) a Mail-Content-Request that contains authentication information, which is created using the Password Secret of the Destination Message Server 14, to the Message Server 12 Source. 4.- The Message Server 12 decrypts the authentication information with the Public Key of the Destination Message Server 14 and responds (an Information Flow 32 or 23) with the E-Mail Message to the Destination Message Server 14. 5.- After receiving the E-mail Message, the Destination Message Server 14 deposits it in the e-mail inbox of the recipient.

Recipient waiting for the Recipient to enter it. To perform the functions of authenticating the identity of the Sender, certifying the content of the Email Message, and encrypting the Email Message for the purpose of privacy, the basic delivery steps are similar to those described above, but with some differences in the packaging of the Outgoing E-mail Message in the Source Message Client 11 and the unpacking of the Incoming E-mail Message in the Destination Message Client 15. Before encrypting an E-Mail Message so that only the Recipient if it can be decrypted, the Message Client 11 of the Sender must have the Public Key of the Recipient which can be obtained from the Destiny Message Server 14 of the Recipient. As described in the preceding paragraphs, the Source Message Server 12 may have the Registered Domain Name and the Public Key Set of the Destination Message Server 14 when the Destination Message Server 14 responds to the Attempt-to-Deliver. The Source Message Server 12 can write the Registered Domain Name and the Public Key Set in the delivery status of the Outgoing Email Message so that the Source Message Client 11 can obtain them from there. In addition, the Destination Message Client 15 can also provide the Registered Domain Name and the Public Key Set of the Destination Message Server 14 when a Mail-Content-Request is sent to the Source 12 Message Server. Therefore, for each transmission of an Email Message to an Email Address, the Source Message Client 11 can obtain and maintain the Registered Domain Name and the Public Key Set of the Destination Message Server 14 that it manages. the email address. If the Message 11 Source Client does not have the Registered Domain Name and the Set of Public Keys of the Destination Message Server 14 associated with an Email Address, the typical steps to obtain the information are the following: 1. - The Message Source Client 11 creates a Request-for -Name-Domain, which is an Electronic Message that contains an Email Address to request for the Registered Domain Name assigned to the Destination Message Server 14 that manages the incoming Email Mailbox associated with the Address of Email. 2. The Source Message Client 11 transmits (an Information Flow 21) the Domain-Name Request to the Messaging Server Source 12. 3.- The Messaging Server Source 12 retains the Domain-Name Request as an Outgoing Email Message, and also delivers it (an Information Flow 23) to the Email Address as if delivering an Intent-to-Delivery. 4. - At the moment of receiving the Domain-Name-Request as the final destination, the Destination Message Server 14 does not deposit it in any Mailbox but establishes a connection with the Message Server 12 Source 5.- The Destination Message Server 14 provides its Registered Domain Name and the Set of Public Keys to the Source 12 Message Server. 6.- The Source 12 Message Server stores the Registered Domain Name and the Set of Keys. Public of the Destination Message Server 14 for the delivery status of the Domain-Name Request as well as for an Outgoing Email Message. 7.- The Sender uses the Source Message Client 11 to obtain the Registered Domain Name and Public Key Set of the Destination Message Server 14 from the Source Message Server 12. Therefore, the Message Source Client 11 may have the Registered Domain Name and the Public Key Set of the Destination Message Server 14 before packing an Outgoing Email Message. The typical steps to pack an Outgoing E-mail Message for the purpose of authenticating the identity of the Sender, certifying the content of the message, and protecting it against curious people are the following: 1.- The Message Source 11 Client creates a Message Compendium of the Email Message using a summary function algorithm. 2.- The Message 11 Source Client encrypts the Compendium of Message with the Secret Key of the Sender to create the Electronic Signature of a Sender. The Sender's Electronic Signature is attached to the Email Message. To simplify the following description, the term "Signed Email Message" will be used to represent the original Email Message to which the Sender's Electronic Signature is attached. 3.- The Message Source Client 11 randomly chooses a Private Key Cryptography Session Key, and encrypts the Email Message signed with the chosen Session Key using Private Key Cryptography. To simplify the following description, the term "Encrypted and signed e-mail message" will be used to represent the e-mail message signed after encryption. 4. In what corresponds to the Recipient, the Message Source Client 11 establishes a connection with the Destination Message Server 14 using its Registered Domain Name, and provides (an Information Flow 34) the Recipient's Email Address and the last Key Generation Time received from the Destination Message Server 14 to the Destination Message Server 14 to request the Set of Public Keys from the Recipient. 5. - In what corresponds to the Recipient's E-Mail Address, the Destination Message Server 14 will ask to retrieve the Set of Public Keys of the Recipient from its Customer Database, it identifies the Secret Key associated with the Time of Recipient. Key generation received from the Message Source 11 Client, and encrypts the Set of Public Keys recovered with the identified Secret Key. 6. - The Destination Message Server 14 provides (an Information Flow 33) the Set of Public Keys encrypted to the Message Source Client 11. 7.- The Message Source 11 Client decrypts the Enciphered Public Keys Set of the Recipient with the last Public Key received from the Destination Message Server 14 to authenticate the identity of the Destination Message Server 14 and obtain the Set of Public Keys from the Recipient. 8.- The Message 11 Source Client encrypts the Session Key with the Public Key of the Recipient using Public Key Cryptography. 9.- The encrypted and signed e-mail message and the encrypted session key result in a packaged e-mail message. The Message 11 Source Client transmits (an Information Flow 21) the outgoing Email Message packaged to the Message Server Source 12, and the Source Message Server 12 sends the Attempt-to-Delivery to the intended Email Address similar to the processing of an Email Message without the Electronic Signature of the Sender and the encryption of the Email Message as described in the previous paragraphs. If there are multiple Recipients, the previous steps (4) to (9) should be executed for each Recipient. The Source Message Client 11 will provide an encrypted Session Key for each Recipient to the Source Message Server 12. And the Source Message Server 12 will provide the corresponding encrypted Session Key to each Recipient sending a Content-Request Mail. The typical steps to unpack the encrypted and signed Email Message in the Destination Message Client 15 are the following: 1.- After receiving the Mail Message Encrypted and signed electronic and encrypted Session Code, the Destination Message Client 15 will decrypt the Session Key encrypted with the Secret Key of the Recipient to obtain the Session Password. 2.- The Destination Message Client 15 will decrypt the Encrypted Email Message signed with the Passcode to obtain the Email Message in a format that can be understood and the Electronic Signature of the Sender. 3.- The Destination Message Client 15 decrypts the Sender's Electronic Signature with the Public Key of the Sender, which is obtained from the Delivery Attempt, to authenticate the identity of the Sender and obtain the Message Compendium of the Mail Message. Original electronic 4. The Destination Message Client 15 then generates again a Message Compendium of the Email Message received using the same summary function algorithm. 5.- Finally, the Destination Message Client ensures that the two Message Compendiums are identical. Based on the above description, it is obvious that there are many advantages of the present invention, and some of the main ones are the following: 1. - The intended recipient can avoid receiving an unwanted e-mail message by not sending a request- of-Content-of-Mail. 2.- The Recipient does not have to open the Intent-of-Delivery but can see the basic information in a list format. Other information in the Intent-of-Delivery will be processed automatically by the system that has greater capacity to show the risks incorporated in the Email Message. 3.- The Email Message will be compiled from a Central Computer that is authenticated and to which a unique Domain Name registered with authoritative organizations has been assigned. Therefore, the source of the Email Message can be identified and tracked if necessary. 4. - The Post-Secret Pair of Keys can be regenerated as often as necessary, and the previous Post-Secret Pair of Keys can be removed and become obsolete before a convict can disintegrate it. 5.- Whenever a Pair of Post-Secret Keys is regenerated, the system will automatically update the corresponding changes. The new Pair of Secret-Public Keys becomes immediately effective without causing confusion in any pending procedure associated with a previous Post-Secret Pair of Keys. 6.- The user's first public key is certified with the user's password by the Central Computer that manages the user's account. 1 . - Any new Public Key is certified by authenticating the identity of the owner with a previous Public Key using Public Key Cryptography. 8.- The Central Computer that manages the accounts of the users is the party with greater authority to provide the Public Keys of its account holders to the public. 9.- The Central Computer, which is responsible for providing Public Keys to the public, is assigned a Unique domain name registered with authoritative organizations and can be tracked if necessary. 10.- People do not have to exchange or maintain the Public Keys of other people which can be regenerated periodically. 11.- People can obtain the Keys Most updated public of other people of the Central Computers which are more accessible than people. 12.- Each User Public Key only has to be maintained by the user and the Central Computer that manages the user's account. 13.- The Central Computer that provides services only has to maintain the Public Keys of the users for their user accounts. 14.- The maintenance of a huge amount of Public Keys of people, an impractical or impossible task for a few central computers, is distributed among lots of computers Centrals 15.- There is no need for a third party to be involved in the maintenance, provisioning, distribution or certification of Public Keys. 16.- After the initial configuration, without considering the issues of the security keys, the Sender can simply choose, from an application point of view, "sign" and "seal" a Mail Message Electronic Figure 2 shows another application of the modality of figure 1 for interactive communication. The methods to manage the Public-Secret Pairs including the initial generation, regeneration, maintenance, updating, provisioning, obtaining, and certification of the Public Keys are identical to those shown in the description of Figure 1. Typical steps to establish an interactive communication such as voice conversation in communication networks are the following: 1. Initially, when the Destination Message Client 15 is connected to the communication networks, the Recipient can use the Destination Message Client 15 to establish a connection to the Destination Message Server 14, and reporting (an Information Flow 25) the IP Address of the Destination Message Client 15, either fixed or temporarily assigned, as a status indicator Online to the Message Server of Destination 14.

Before disconnecting from communication networks, the Destination Message Client 15 should report to the Destination Message Server 14 that is offline. 2. - When a Sender intends to have an interactive communication in the communication networks with a intended Recipient, the Sender uses the Source Message Client 11 to create a Call-to-Communicate, which is an Electronic Message that contains the IP Address. of the Message Source 11 Client, to invite the intended Recipient to establish an interactive communication. 3. The Message 11 Source Client transmits (an Information Flow 21) the Call-to-Communication to the Source Message Server 12. Next, the Message Source 11 Client continues to connect to communication networks awaiting responses. 4. - At the moment of receiving the Call-of-Communication, the Message Server Source 12 creates an Intent-of-Communication which is an Electronic Message that contains the name of the Sender, the Email Address of the Sender, some codes Identification of the Call-of-Communication, the IP Address of the Message Source Client 11, the Registered Domain Name and the Set of Public Keys of the Source Message Server 12, the Set of Public Keys of the Sender, etc. 5.- The Message Server Source 12 delivery (a Information Flow 23) Intent-of-Communication to Destination Message Server 14 of the Recipient as well as delivery of an Intent-of-Delivery, as explained in the description of Figure 1. 6.- At the moment of receiving the Intent-of-Communication, the Message Server of Destination 14 does not deposit the Attempt-of-Communication in the Recipient's Inbox, but establishes a connection with the Source Message Server 12 using the Registered Domain Name of the Messaging Server Source 12. 7.- The Destination Message Server 14 and the Source Message Server 12 will authenticate the mutual identity and update the Public Key Set of the other party as explained in the description of Figure 1. 8.- If the Destination Message Client 15 of the intended Recipient is online, the Destination Message Server 14 will send (an Information Flow 31) an Online Notification, which is an Electronic Message containing the Set of Keys Public Addresses Encrypted with the Secret Password of the Destination Message Server 14, to the Message Server Source 12. If the Destination Message Client 15 of the intended Recipient is not online, none reports online or reports offline, the Destination Message Server 14 will send to the Source Message Server 12 (an Information Flow 31) an Offline Notification, which is an Electronic Message notifying that the intended Recipient not available. 9.- At the moment of receiving the Online Notification or the Off-line Notification, the Source Message Server 12 establishes a connection with the Message Source 11 Client using the IP address of the Message Source 11 Client, the Message Server Source 12 provides its Encrypted Public Key Set with its Secret Key to the Message Source Client 11 so that the Message Source 11 Client can authenticate the identity of the Source Message Server 12 as in the case where the Message Source 11 Client establishes a connection to the Source Message Server 12, as explained in the description of Figure 1. 10.- If the Source Message Server 12 receives an Online Notification from the Destination Message Server 14, it will decrypt the Set of Keys. Public Encrypted of the Recipient with the Public Key of the Destination Message Server 14 to obtain the Set of Public Keys of the Recipient, encrypt The Set of Public Keys of the Recipient with the Secret Key of the Message Server Source 12, then provides (an Information Flow 22) an Online Notification that includes the Set of recently encrypted Public Keys of the Recipient to the Customer of Message Source 11. If Messaging Server Source 12 receives an Online Notification from the Destination Message Server 14, it will pass the Online Notification to the Customer of Source Message 11. 11.- At the time of receiving the Notification In Line of the Message Server Source 12, the Message Source Client 11 decrypts the Enciphered Public Key Set of the Recipient with the Public Key of the Message Server 12 Source, preserves the Set of Public Keys of the Recipient waiting for an additional response. At the time of receiving the Offline Notification of the Source Message Server 12, the Message Source 11 Client sends a perceptible, visual or audible alarm, and provides options for the Sender to choose among them: leave an Email Message, in voice or text, to the Recipient as explained in the description of Figure 1, call again, etc. 12. At the other end, after sending an Online Notification to the Source Message Server 12, the Destination Message Server 14 establishes a connection with the Destination Client 15 using the IP address of the Message Client of the Destination Client. Destination 15, and then pass the Intent-of-Communication (an Information Flow 26) to the Destination Message Client 15. 13.- At the time of receiving the Intent-of-Communication, the Destination Message Client 15 will launch a perceptible, visual or audible alarm, and provides options for the Recipient to choose among them: establish an interactive communication; respond with a message such as "call later" or "return the call" or "please leave a voice message", "remove my name from your call list", etc., or simply ignore the attempt Communication 14.- If the Recipient chooses to establish an interactive communication, the Recipient uses the Destination Message Client 15 to create the authentication information, which is a series of data codes such as the name of the Recipient encrypted with the Secret Key of the Addressee. The Destination Message Client 15 establishes a connection to the Source Message Client 11 using the IP Address of the Message Source 11 Client, provides (an Information Flow 29) the Recipient's Email Address and the authentication information to the Client. of Message Source 11. 15.- If the Customer of Source Message 11 has already received the Public Key of the Recipient when it receives the authentication information, it will authenticate the identity of the Recipient through the decryption of the authentication information with the Public Key of the Recipient, then will launch an Electronic Message such as "ready for interactive communication" on the display screen of the Message Source Client 11, and then the Sender and the Recipient can begin their interactive communication (Information Flows 29 and 30). 16.- If the Message Source Client 11 has not received the Public Key from the Recipient when it receives the authentication information, it will send an Electronic Message such as "awaiting authentication ..." to the Destination Message Client 15, it will wait until it receives the Public Key from the Recipient, then it will execute step (15). 17.- If the Recipient chooses to respond to the Sender with a message instead of establishing an interactive communication, the Destination Message Client 15 can be used to send the message similar to the establishment of an interactive communication but with some differences such as the following : (a) the Destination Message Client 15 sends a short encrypted message such as "call later", "call back", etc. instead of the name of the Recipient to the Customer of Message Source 11; (b) the Source Message Client 11 throws the short message instead of a "ready for interactive communication"; (c) the connection between the Destination Message Client 15 and the Source Message Client 11 will be closed after the short message is sent. Because both the Source Message Client 11 and the Destination Message Client 15 have the Public Key of the other party, the sending party can encrypt an Electronic Interactive Message with the Public Key of the receiving party., and the receiving party can decrypt the Electronic Interactive Message encrypted with the Secret Key of the receiving party. In other words, interactive communication can be kept private. Based on the above description, it is obvious that there are many advantages of the present invention with respect to interactive communication and some of the most important are: 1.- The use of Email Addresses to establish an interactive communication can eliminate the requirement of that both the Sender and the Recipient reach an agreement regarding a common service provider. 2.- A voice message, generally of a large size in data, will not be downloaded into the Recipient's Email Mailbox but will be kept in the Sender's Source 12 Message Server allowing the intended Recipient to determine if he wants to listen or not the voice message 3.- The source of an unwanted voice message can be identified. Figure 3 shows a special case of Figure 1, where the Source and Destination Message Server 326 is a single Central Computer that executes the functions of a Sender's Source Message Server and a Recipient's Destination Message Server for deliver an Email Message. In this case, the execution steps are the same as those explained in the description of Figure 1 with the exception that the procedures between the Source Message Server and the Destination Message Server are carried out internally or they omit. The Source Message Server and the Destination Message Server do not have to authenticate the identity of the other party. Both the Recipient and the Sender can easily obtain the Set of Public Keys from the other party through the Source and Destination Message Server 326. Figure 4 shows a special case of the figure 2, wherein the Source and Destination Message Server 326 is a single Central Computer that executes the functions of a Sender's Source Message Server and a Recipient's Destination Message Server to establish an interactive communication. In this case, the execution steps are the same as those explained in the description of Figure 2 with the exception that the procedures between the Source Message Server and the Destination Message Server are carried out internally or are omitted. The Source Message Server and the Destination Message Server do not need to authenticate the identity of the other party, and the delivery of the Intent-of-Communication, the Online Notification, the Out-of-Line Notification, etc. It will be faster. Both the Sender and the Recipient can easily obtain the Public Key Set from the other party via the Source and Destination Message Server 326. Figure 5 shows an alternative embodiment of the present invention in terms of Security Key Management. . The 512 Combined Message Server is a Central Computer that executes the functions of both a Source Message Server and a Destination Message Server, and has the ability to automatically respond to incoming Electronic Messages in an instant and to initiate Electronic Messages. of exit. The Combined Message Client 511 is a Local Computer or Communication Device that a user employs to communicate with the Combined Message Server 512. The 511 Combined Message Client performs functions of a Source Message Client and a Destination Message Client. Methods for managing Key Pairs Public-Secret including the initial generation, regeneration, maintenance, updating, provisioning, procurement and certification of Public Keys are identical to those explained in the description of Figure 1. Initially, when a user uses a 511 Combined Message Client to configure a new account with a 512 Combined Message Server, the 512 Combined Message Server encrypts its Public Key Set with its Secret Key and provides (an Information Flow 522) the Public Key Encrypted Message Set to the 511 Combined Message Client The Combined Message Server 512 also provides a mechanism for the 511 Combined Message Client to download the Public Key Set of the 512 Combined Message Server. The 511 Combined Message Client decrypts the Public Key Ensemble encrypted with the downloaded Public Key. to obtain the Public Key Set received, ce rtificando the Set of Public Keys received through its comparison with the Set of Public Keys downloaded. The Combined Message Client 511 encrypts the password of the user's account and the Public Key Set of the user with the Public Key of the Combined Message Server 512, reports (an Information Flow 521) the password and the Encrypted Public Key Set to the Combined Message Server 512. The Combined Message Server 512 decrypts the password and Public Key Set encrypted with the Secret Key of the Combined Message Server 512 and certifies the set of Public Keys received by verifying the received password. Therefore, both the user and the Combined Message Server 512 have the Public Key Set of the other party. Both the user and the Messaging Server Combined 512 can generate a new Pair of Public-Secret Keys whenever necessary. Whenever the user uses the Combined Message Client 511 to register on the Combined Message Server 512, the Combined Message Client 511 provides (an Information Flow 521) the last Key Generation Time received from the Combined Message Server 512 at Combined Message Server 512. The Combined Message Server 512 identifies its Secret Key associated with the Key Generation Time, encrypts its most updated Public Key Set with the identified Secret Key, and provides (an Information Flow 522) the Public Key Set encrypted to the 511 Combined Message Client. The 511 Combined Message Client decrypts the Encrypted Public Key Set with the last Public Key received from the Combined Message Server 512 to authenticate the identity of the Combined Message Server 512 and obtain the most updated Public Key Set of the Combined Message Server 512. Whenever the user uses the Combined Message 511 Client for generate a new Public-Secret Pair of Keys, the 511 Combined Message Client will establish a connection to the 512 Combined Message Server, encrypt the new Public Key Set with the user's last Secret Key, and report (an Information Flow 521 ) the new set of Public Keys encrypted to the Combi Message Server 512. The 512 Combined Message Server decrypts the new set of encrypted Public Keys with the last Public Key of the user to authenticate the identity of the user and obtain the new Set of Public Keys of the user. Therefore, both the user and the 512 Combined Message Server can maintain the most up-to-date version of the Public Key Set of the other party and can establish secure communication with authentication of identities and certification of message content. An exemplary application of Figure 5 is the transfer of bank funds in communication networks. In addition to the management of Pairs of Public-Secret Keys as described above, typical additional steps are the following: 1. - The user specifies a transfer-request that is an Electronic Message that contains information such as the identification of the account, the amount of the fund, the beneficiary of the fund, the date, etc. 2. - The 511 Combined Message Client creates a Message Compendium of the request-of-transfer using a summary function algorithm. 3.- The 511 Combined Messages Client encrypts the Message Compendium, as a User's Electronic Signature, where the User's Secret Key uses Public Key Cryptography. The User's Electronic Signature will be attached to the transfer request. To simplify the following description, the term "signed transfer request" will be used to represent the original transfer request with the electronic signature of the attached user. 4.- Then, the 511 Combined Message Client randomly chooses a Private Key Cryptography Session Key, and encrypts the transfer request signed with the chosen Session Key using Private Key Cryptography. To simplify the following description, the term "signed and encrypted transfer request" will be used to represent the signed transfer request after the encryption. 5. The 511 Combined Message Client encrypts the Session Password with the Public Key of the 512 Combined Message Server using Public Key Cryptography. The encrypted and signed transfer-request and the encrypted Session Key results in a loaded Electronic Message. 6. The Combined Message Client 511 transmits (an Information Flow 521) the Electronic Message loaded to the Combined Message Server 512. 7. - Upon receiving the Electronic Message loaded, the Combined Message Server 512 decrypts the Password of Session encrypted with the Secret Password of the Combined Message Server 512 to obtain the Session Key. 8. The Combined Messaging Server 512 decrypts the transfer-encrypted request signed with the Session Password, obtains the transfer-request in an understandable format and the User's Electronic Signature. 9. The Combined Message Server 512 decrypts the User's Electronic Signature with the User's Public Key to authenticate the identity of the user and obtain the Message Compendium of the original transfer request. 10. The Combined Message Server 512 generates again a Message Compendium of the received request-transfer. 11.- Finally, the Combined Message Server 512 ensures that the two Message Compendiums are identical as the certification of the transfer-request. Based on the above description, it is obvious that there are many advantages of the present invention for an online service such as electronic banking, and some advantages are: 1.- The transfer of funds can be done as a procedure that requires the Secret Key of the account holder that even the same bank does not have.

In case all of the bank's account information is stolen from the bank by an intruder cyber pirate or unfair bank employees, the stolen account information is still insufficient to extract funds from the bank's accounts. 2.- The bank can maintain the signed transfer request of the user as a transaction record that authenticates the identity of the user and certifies the content of the transfer request. 3. - Any confidential information of accounts in the specification of the Request-of-Transfer is encrypted and protected against intruders during transmission in communication networks. 4.- Both the bank and the account holders can regenerate their Public-Secret Pairs as often as necessary, and the previous Public-Secret Pairs can be withdrawn and become obsolete before a convict can possibly disintegrate them. Another exemplary application of Figure 5 is to license computer software in an Electronic Message System. In addition to the management of Public-Secret Pairs of keys as described above, additional typical steps for said application are the following: 1. Initially, the software vendor uses a summary function algorithm to create a Message Compendium of the computer software (called the Product Compendium in the following description), and a Message Compendium of a software license agreement associated with the software of computation (called Compendium of License of the seller in the following description). 2. The user uses a Combined Message Client 511 to establish a connection to a Combined Message Server 512. 3. The Combined Message Server 512 provides (an Information Flow 522) a software license agreement to the Customer of Messages Combined 511. 4.- After viewing the software license agreement and accepting the content, the user can simply click on an "Agree and sign" button on the 511 Combined Message Client display screen. Client 511 Merge Message will create a Message Compendium (named User's License Compendium in the following description) of the software license agreement using the summary function algorithm equal to that used by the vendor and encrypt the user's License Compendium with the Secret password of the user as the User's Electronic Signature. Then, the Combined Message Client 511 provides (an Information Flow 521) the User's Electronic Signature to the Combined Message Server 512.

. - Upon receipt of the User's Electronic Signature, the 512 Combined Message Server decrypts the User's Electronic Signature with the User's Public Key to authenticate the user's identity and obtain the user's License Compendium. The Combined Message Server 512 ensures that the User's License Compendium is identical to the Vendor's License Compendium, registers the User's Electronic Signature and the Public Key Set of the associated user for tracking purposes. 6. The Combined Message Server 512 encrypts the Compendium of the Product with the User's Public Key and provides (an Information Flow 522) the Compendium of the encrypted Product, as a License Key, to the Combined Message Client 511. The Server Messaging 512 registers the associated User's License Key and Public Key Set for tracking purposes. 7.- If the computer software is properly designed, you can use three main properties of the License Key: (a) only the person who has a unique Secret Key can decrypt the License Key (to use the computer software) ); (b) the decrypted License Key, a Compendium of the Product, may be used to certify a specific computer software (to license specific computer software only); and (c) the Product Key can be used to ensure that the computer software is not tampered with (virus-proof or cyber-pirate-proof). The way in which computer software can be designed for the use of the properties of a License Key is beyond the scope of the present invention which focuses solely on the method for creating said License Key. Based on the above description, it is obvious that there are many advantages of the present invention to create a License Key that can uniquely authenticate the identity of a user and certify the content of the computer software. Some of the main advantages are: 1.- The vendor allows the computer software to be distributed freely, for example, through distributors or between users, to reduce the workload of the vendor's computation, but controls the licenses through the Issuance of License Keys, which only have small data sizes, in an Electronic Message System. 2.- If any person infringes the reproduction rights and distributes the computer software with a Secret Key to decrypt the License Key, the license key of the License Key can be traced because the licensee is the only person who has the license. Secret key that is even unknown to the seller. Figure 6 shows another alternative embodiment of the present invention in terms of the management of Security Keys involving the server of a third party. For example, a buyer intends to use an electronic payment account to pay merchandise to an electronic store. The 512 Combined Message Server is a Central Computer that provides electronic payment account services. The Service Message Server 614 is a Central Computer that provides the public with electronic purchase services. The 511 Combined Message Client is a Central Computer or Communication Device that a user uses to communicate with the 512 Combined Message Server with whom the user has an account. The user also uses the Combined Message Client 511 to communicate with the Service Message Server 614 to purchase merchandise. The methods for managing Public-Secret Pairs including the initial generation, regeneration, maintenance, updating, provisioning, obtaining and certification of Public Keys are identical to those explained in the description of Figure 1. Very specifically, the management of public-secret key pairs between the combined message client 511 and the combined message server 512 is identical to the case explained in the description of figure 5. and the management of public key pairs between the server Combined Message Board 512 and Service Message Server 614 is identical to the case between a Source Message Server and a Destination Message Server whenever a connection is established as explained in the description of Figure 1. Typical additional steps for said application they are the following: 1.- Whenever a user uses a Combined Message Client 511 to register in a Combined Message Server 512 that manages an electronic payment account of the user, in addition to providing (an Information Flow 522) the Public Key Set of the Combined Message Server 512 to the Combined Message Client 511 as explained in the description of Figure 5, the Combined Message Server 512 also provides (an Information Flow 522) its Registered Domain Name to the Combined Message Client 511. 2.- When the user uses the Combined Message Client 511 to establish a connection to a Service Message Server 614 that provides the public with electronic purchasing services, the Service Message Server 614 provides its Public Key Set (an Information Flow 633) to the 511 Combined Message Client. 3. - The user can specify a purchase order, which it is an Electronic Message that contains the ordered article, the amount of the payment, the Registered Domain Name of the Combined Message Server 512, the identification of the user's payment account, etc. 4. - The 511 Combined Message Client creates a Message Compendium of the purchase order using a summary function algorithm, and then encrypts the Message Compendium, as an Electronic Signature, with the user's Secret Key using Public Key Cryptography. The User's Electronic Signature will be attached to the purchase order. To simplify the following description, the term "signed purchase order" will be used to represent the original purchase order with the attached Electronic Signature. 5. - The 511 Combined Message Client will randomly choose a Private Key Cryptography Session Key, and encrypts the purchase order signed with the chosen Session Key using the Private Key Cryptography. To simplify the following description, the term "encrypted and signed purchase order" will be used to represent the signed purchase order after encryption. 6.- The Combined Message Client 511 encrypts the session key with the Public Key of the Service Message Server 614 using Public Key Cryptography. The encrypted and signed purchase order and the encrypted Session Key result in an Electronic Message loaded. 1 . - The Combined Message Client 511 delivers (an Information Flow 634) the Electronic Message loaded to the Service Message Server 614. 8.- At the time of receiving the Electronic Message from the Combined Message Client 511, the Service Messages 614 decrypts the Session Key encrypted with the Secret Password of the Message Server Service 614 to obtain the Session Code. 9.- The Service Message Server 614 decrypts the purchase order encrypted and signed with the Session Code, obtains the purchase order in an understandable format and the User's Electronic Signature. 10. The Service Message Server 614 establishes a connection with the Message Server Combined 512 using the Registered Domain Name of the Combined Message Server 512. The Service Message Server 614 and the Combined Message Server 512 authenticate the mutual identity and update the Public Key Set of the other as well as between a Message Server Source and a Destination Message Server as explained in the description of Figure 1. 11.- The Service Message Server 614 provides (an Information Flow 631) the identification of the user's payment account to request the Public Key. of the user. 12. The Combined Message Server 512 identifies the User's Public Key corresponding to the identification of the user's payment account, encrypts the Set of Public Keys of the user with the Secret Password of the Combined Message Server 512, and provides (a Information Flow 632) the set of public encrypted keys of the user to the Service Message Server 614. 13.- The Service Message Server 614 decrypts the set of encrypted Public Keys of the user with the Public Key of the Combined Message Server 512 to obtain the set of public keys of the user. 14.- The Service Message Server 614 decrypts the User's Electronic Signature with the User's Public Key to authenticate the identity of the user and obtain the Message Compendium of the original purchase order. 15. The Service Message Server 614 generates again a Message Compendium of the received purchase order. 16.- Finally, the Message Server of Service 614 ensures that the two Message Compendiums are identical as the certification of the purchase order. Based on the above description, many additional advantages of the present invention become obvious and some of them are: 1.- From the point of view of the electronic store, the identity of the user (buyer) is authenticated and the order Purchase is certified using the secret password of the user which only the user knows. Thus, no counterfeiter can use the payment account of another person knowing only the identification of the account such as the credit card number, and the true user can not deny the purchase order later. 2.- From the point of view of the user, unlike holders of credit accounts concerned about the possibility of being charged extra or re-charged to the same charge by some dishonest sellers after it is provided the credit card number, not only the payment terms should be certified by a Secret Password known only by the user, but also the user can regenerate a new Pair of Secret-Public Keys and remove the previous one after the completion of the transaction. 3.- The service provider, who manages the payment account, is the party with the most authority to provide the public with the Public Key of its account holder. 4. - The service provider of the payment account, who is responsible for providing the public with the user's Public Key, can be traced based on a unique Domain Name registered by the service provider with authoritative organizations. The present invention provides a system and method for delivering an E-mail Message in a form of delivery-by-request and improved management of Cryptography Security Keys. Although the above description contains many specifications, these should not be construed as limitations on the scope of the invention, but rather as an exemplification of the preferred embodiments thereof. Other variations are possible. For example, if necessary and with sufficient computing system power, the present invention can be used for the realization of a video conference involving multiple attendees with Interactive Electronic Messages that contain text, images, audio, voice and video where only the individual Recipient can decrypt the Electronic Interactive Messages with each Secret Key separately. It will be apparent to those skilled in the art that various modifications and variations may be made to the present invention without departing from the scope or spirit of the invention. By virtue of the foregoing, it is intended that the present invention encompass the modifications and variations of this invention as long as they are within the scope of the invention and its equivalent.

Claims (30)

NOVELTY OF THE INVENTION Having described the present invention, it is considered as a novelty and, therefore, the content of the following is claimed as a priority: CLAIMS

1. A method for providing an e-mail message from a sending party to a receiving party, comprising: sending a delivery-attempt containing certain basic information of the e-mail message by the sending party to the party that receives; respond to the delivery attempt with a mail-content request containing delivery instructions by the party receiving the sending party if the receiving party so determines; and respond to the request-of-mail-containing with the email message by the party sending to the party receiving.

2. - The method according to claim 1, characterized in that the receiving party can avoid receiving the e-mail message by not sending the mail-content-request.

3. - The method according to claim 1, wherein the sending party can be identified as the source of the email message.

4. - The method according to claim 1, further comprising: providing a public key public key cryptography by the party receiving the sending party at the time of receiving the delivery attempt; provide authentication information, which is a series of encrypted data codes with a secret key associated with the public key, by the party that receives the sending party when the mail-content-request is sent; decrypt the authentication information with a public key, which is an element selected from the group consisting of the public key provided by the receiving party and a source that the sending party considers reliable, by the sending party at the time of receive the authentication information; and respond to the request-of-content-mail with the e-mail message by the sending party if and only if the decryption of the authentication information is successful.

5. The method according to claim 4, characterized in that the sending party will not respond with the e-mail message to a party unless the party provides authentication information that the sending party can decrypt successfully.

6. A method for managing public-secret key pairs of public-key cryptography, comprising: assigning a unique name to a central computer that manages a user's account, where the unique name is registered with authoritative organizations and can use to establish a connection to the central computer in communication networks; certify a user's public key through the central computer using a user account password; and provide the public with the user's public key through the central computer.

7. - The method according to claim 6, characterized in that the central computer, which manages the user's account, is the party with the greatest authority to provide the public with the public key.

8. - The method according to claim 6, wherein the public key is certified by the central computer that is the party with the greatest authority to provide the public with the public key.

9. - The method according to claim 6, characterized in that the central computer, which is responsible for providing the public with the public key, can be tracked if necessary.

10. - The method according to claim 6, characterized in that the maintenance of a huge account of public keys of persons, a task impractical or impossible to perform by a few central computers, is distributed to a plurality of central computers.

11. The method according to claim 6, characterized in that the central computer only needs to maintain the public keys of its user accounts among the public keys of all people.

12. The method according to claim 6, characterized because people do not need to keep other people's public keys.

13. The method according to claim 6, characterized in that the public keys of the persons can be obtained from central computers that are available at all times.

14. The method according to claim 6, further comprising: encrypting the public key of the user with a secret key of the central computer by the central computer; obtain the public key of the central computer by connecting to the central computer or an authoritative organization where the central computer is registered by means of the inquiry of the user's public key by the applicant; and decrypt the encrypted public key of the user with the public key of the central computer by the applicant.

15. The method according to claim 14, characterized in that the applicant can ensure that the user's public key is legitimate by authenticating the identity of the central computer.

16. The method according to claim 6, further comprising: registering a key generation time provided that a public-secret key pair, consisting of a public key and a public key cryptographic secret key, is initially generated or subsequently regenerated by the user; report a set of public keys, which consists of a public key of the user and an associated key generation time, by the user to the central computer whenever a pair of public-secret keys of the user is generated; certify the user's new public key through the central computer whenever a new set of public keys is reported; provide the public with a more updated set of public keys of the user through the central computer; and informing the user through the central computer about a provisioning event of a set of public keys of the user to a requesting party.

17. The method according to claim 16, characterized in that the report comprises: encrypting the set of public keys, which contains the public key and the associated key generation time, with the last secret key of the user; and provide the set of public keys encrypted to the central computer.

18. The method according to claim 16, characterized in that the certification comprises: decrypting a set of encrypted public keys, this is reported by the user, with the last public key of the user.

19. The method according to claim 16, characterized in that the information comprises: providing a key generation time, which is associated with the set of public keys provided to the requesting party, to the user through the central computer .

20. The method according to claim 16, characterized in that the user can regenerate a new public-secret key pair whenever necessary and can remove a previous public-secret key pair so that the key-pair public-secret before it becomes obsolete before a convict can possibly disintegrate it.

21. The method according to claim 16, characterized in that the user can identify an appropriate secret key for a pending procedure that was initiated before a public-secret key pair was regenerated.

22. The method according to claim 6, further comprising: providing the unique name of the central computer to the user through the central computer; provide the unique name and account identification to a central computer of a third party by the user; connect to the central computer through a central computer of a third party; and obtain the public key of the user, this is associated with the identification of the account, of the central computer through the central computer of a third party.

23. The method according to claim 22, characterized in that the central computer of a third party can obtain the public key of a person from a central computer that manages an account of the person.

24. The method according to claim 6, which further comprises: requesting the user to encrypt the information with the user's secret key before sending the information to the central computer, and decrypt the information encrypted with the user's public key through the central computer.

25. The method according to claim 24, characterized in that the central computer can authenticate the identity of the user and can guarantee that the information has not been modified. 26.- The method according to claim 16, which further comprises: requesting the user to encrypt the information with a more updated secret key of the user before sending the information to the central computer; and decrypting the encrypted information with a public key associated with the user's most current secret key through the central computer. 27. The method according to claim 26, characterized in that the central computer can authenticate the identity of the user and can ensure that the information has not been modified at the same time that the public-secret key pair of the user is regenerated with so much as often as necessary. 28. The method according to claim 6, further comprising: encrypting the information with a public key of the user through the central computer; provide the encrypted information to the user through the central computer; and request the user to decrypt the information encrypted with the user's secret key before performing an additional action that only the user is authorized to execute. 29. The method according to claim 28, characterized in that the additional action can be executed by the user only. 30. The method according to claim 28, characterized in that the user can be tracked in case an additional action is executed by an unauthorized party. SUMMARY OF THE INVENTION A method for delivering emails at the time of your request and for managing public-secret key cryptography key pairs in an electronic message system; a sending party may send a delivery attempt associated with an e-mail message to a intended receiving party; the party that receives allegedly responds with a request-of-content-of-mail to request the e-mail message if the intended recipient so determines; the sending party will not deliver the e-mail message to the intended party if the intended recipient does not send the mail-content request; a central computer is assigned a unique name • that is registered with authoritative organizations and can be used to establish a connection to the central computer; the central computer provides the public with public keys of its account holders; The initial public key of an account holder is certified by the central computer using an account password; the account holder can regenerate a public-secret key pair as often as necessary; The new public key is certified by the central computer using the previous public key of the account holder and goes into effect for its provision to the public.