BRPI0621341A2 - communication system and communication method for electronic mail - Google Patents

Abstract

COMMUNICATION SYSTEM, AND, COMMUNICATION METHOD FOR ELECTRONIC MAIL. A system and method of communication transmits electronic mail between multiple users who are senders or recipients of mail, or both. The system and method use and extend Intemet with a server and postal software connected to Intemet. The sender and receiver also have terminals connected to Intemet. The sender uses postal sender software to select transmission with certain premium services. The system and method include payment and accounting functions for the use of premium services. The system and method can operate with multiple postal servers in one or more locations. Communications may use the server and postal software only to process data about the message and / or its transmission. Communications between the Sender, Receiver, and postal server can create qualities like a virtual intranet. Transmitted e-mail uses message data to identify the Sender, authenticate and verify the e-mail, and direct its processing.

Description

"COMMUNICATION SYSTEM, Ε, COMMUNICATION METHOD FOR E-MAIL" BACKGROUND OF THE INVENTION

The present invention relates generally to communication systems and methods. More specifically, it relates to a system and method that enables the public to send and receive e-mail and messages over the Internet with greater guarantees of delivery, security, privacy, priority and maneuverability than conventional email.

The Internet has produced a revolutionary change in information sharing. The growth in e-mail, or e-mail, via the Internet has been spectacularly robust, with similarly strong future forecast expansion. Email usage is exploding because of the proliferation of computing devices of various types, and because of increased availability and access to telecommunications bandwidth. An estimated 31 billion e-mail messages were sent daily during 2002, and this number, increasing by more than 20% per year, is expected to exceed 60 billion per day in 2006.

However, this rapid increase in email has produced significant, and largely unexpected, problems. While email is an easy and inexpensive way to send someone a message or document, those same attributes have led to recipients receiving unexpectedly large and growing amounts of email, both wanted and unwanted.

The explosion in dear email is itself causing an ever increasing overload problem. Of the 31 billion total daily e-mail messages in 2002, an estimated 21 billion per day were e-mail, that is, those recipients judge it to be valuable, whether solicited or unsolicited in nature. And, that dear email volume is expected to reach 36 billion a day in 2006.

Compounding this overload situation is the increasing amount of email that is both unwanted and unsolicited (and sometimes offensive). This growing volume of annoyance email not only frustrates email recipients, but also constrains and constrains optimal development of the Internet email system. Other negative aspects of this hassle email - such as reduced business efficiency, increased costs, and expanded security risks - are well known. See, for example, the discussion of the negative effects of annoyance email in US Patent No. 6,321,261 to Donaldson.

As total email volume grows, the problem of the recipient (and sender) becomes analogous to a regular mailbox that receives much more correspondence than it can contain. Without such significant priority differentiation, a recipient needs to run a time-consuming review of all daily emails in order to find and review the most important ones. Often, the magnitude of this repetitive and uneconomical task drives recipients only to delete all emails, thereby risking the loss of information that is important and thus has value to both recipients and senders alike. This bulky message problem of both hassle and overload email has become so costly that a better email document management system and method is urgently required. And until such a system and method becomes available, the commercial utility of the Internet will remain constrained for many current or potential users.

For example, an area currently constrained is legitimate email marketing - the electronic equivalent of conventional direct mail marketing. Direct mail marketing has been an accepted and effective way of advertising and promoting goods and services for many years, both for consumers and for business. Your electronic counterpart has the potential - as yet unrealized - to grow and develop similar levels of acceptability and business effectiveness. Today, most online advertising is in the form of banner ads, not emails. Of the $ 2.8 billion spent in the US in 1999 for online advertising, banner advertising accounted for 50%, with email accounting for only 3%. Online ad spending has continued to grow rapidly reaching $ 12 billion in 2004 and is estimated to be $ 14.7 billion in 2005, a 23% increase over 2004. However, banner advertising is notoriously inefficient and infested with low ad rates. 'click-thru'. Therefore, there is a need for more effective Internet marketing methods - such as direct email marketing - to gain audience attention, get messages, and increase response rates.

Email not only has a larger foundation than the World Web, but email also has the ability to deliver personalized, media-rich audiences, interactive communication where, and when, they are most receptive - an ability that will elicit a response. much bigger than banner advertising. But email marketing cannot reach its full potential unless there is a better way to manage the growing volume and clutter of email. At the moment, email highways are so "noisy" that it distracts recipients from paying enough attention to legitimate online email advertising. Today, it is difficult for a recipient to understand the importance, value, and priority of a particular email until it is opened and reviewed. And, this process of opening and reviewing is time consuming, and exposes the recipient to technical risks (such as viruses and worms) as well as content risk (such as offensive words and pictures). One embarrassment in email marketing now is the concern that communicated messages will be confused, or associated with worthless annoyance email.

A consequent problem with the Internet mail system - in addition to both annoying and overloading email - is security. The email security process that exists now is inadequate and prevents widespread use of the Internet for many potential business purposes. Many email applications have encryption procedures, but their procedures are too complex for many email users, either unreasonably and / or generally available in precise situations. As such, email security represents another problem looking for an effective solution.

A good example of the security issue is provided by the US Federal Health Insurance Portability and Accountability Act (HIPAA) email security requirements. HIPAA has stated that emails (and facsimiles) that are not secured by encryption are unacceptable for communicating personal health care information (such as diagnostic codes, testing results, and certificates of medical need) between physicians, other caregivers. health, and insurance organizations. When this law went into effect in the United States in October 2003, many health care companies did not yet have any email system that meets HIPAA requirements for reporting triad health care information. Technology is not readily available, or is not acceptably cost effective for many health care providers. This situation continues today, unresolved.

For dear email, there is currently no known solution to the email priority and overload differentiation issues described above.

For the portion of the unwanted, unsolicited, annoying email problem, some vendors provide software filters that block and delete email using various rules applied to email subject lines, sender addresses, and some content. from email. This software may reside on a service provider's server or on the user's computer system. These annoying email blockers allow the customer varying capabilities to adjust filter rules. The abovementioned '267' patent for Donaldson also discusses the various categories of annoyance email control solutions known from 1999. The '267' patent itself describes an active multi-layer defense probe filter located at a conventional firewall barrier configuration between a remote host and a local message transfer agent.

A recent example of such a software filter service is an Internet Service Provider (ISP) using a filter sold under the trademark "Brightmail" within its email system. Filtering and software rules are controlled by the ISP, and the existence of this filter was even unknown to at least some of its clients when the filter was initially activated. Some, but not all, unsolicited email is blocked. Unfortunately, some unwanted and unwanted email is blocked, and some unwanted and unwanted email still passes. Even worse, some ones (and requested and expected emails) are also blocked, and a recipient doesn't know when they were blocked. To see if and what emails are being blocked, a customer should leave their email application, go to their ISP website, enter a particular area of that website, register with user ID ) and password, and scroll through days and lines of emails. To unblock specific senders, a customer must email the sender's email address to the ISP, which is the only entity that can correct the filtering rules.

Included among the many disadvantages of these annoying email filtering services and software are that they:

• Block many emails you want from reaching recipients.

A computer market research firm estimated that this problem is worth $ 3.5 billion in 2003.

• Allow many economically worthless, unwanted, unsolicited and offensive emails to reach recipients. And, these are worth an estimated $ 10 billion business in 2003. • Do not filter or protect email from content risk by any general public standard.

• Do not universally protect email for technical risk.

• They do not provide any publicly accepted priority or value indicators in emails, so recipients can quickly view and automatically sort such higher priority emails from other lower priority emails.

• They do not provide any means to give recipients incentives to open designated priority email.

• Do not provide any integrated email tracking service to senders or recipients.

• Do not offer any officially acknowledged notification of receipt or opening.

• Do not offer any comprehensive security measures other than antivirus shielding. There are well-known email encryption services, but these services are also not part of a full service package that focuses on the hassle of email overload and hassle email described above equally. In addition, most current digital email encryption and signing methods are complex for ordinary email users, including those procedures that are part of current generally available email applications.

• In many cases do not work easily and seamlessly from within the user's email application.

An example of an organization that sought to address these defects is the US Postal Service itself (U.S.P.S.). But, the process of U.S.P.S. requires a sender to leave their own email application, go to the U.S.P.S. website, and compose a letter there. The U.S.P.S. then print the document, put it in an envelope, apply postage and physically deliver it. In 2003, a one-page letter produced in this way cost the sender 50 cents. While some may find this service attractive, it suffers from the fact that the sender cannot use the convenience of their own mailbox (ie their own email application) to forward the document. Second, this system is still primarily a non-electronic physical process with all inherent limitations in physical mail delivery. Third, the recipient cannot make use of their electronic mailbox (ie their email application) to receive the document.

Today, the need for better email security - such as hassle and hassle email problems - is only met with partial solutions. Secure email service providers only focus on secure email services. In addition, these partial services often involve cumbersome procedures including, for example, requiring senders to leave their email applications and registering on the service provider's website.

It is therefore an object of this invention to provide a complete and commercially viable solution to all these email problems without impeding the nature of the Internet.

The invention manages an Internet-based communication system that unlocks the business value of email for businesses and individuals large and small.

Another object of the invention is to authorize all email senders using the system to differentiate and prioritize, sort and secure, special delivery and path, and sort and manage email more effectively.

It is a further object of the invention to create a special yet generally available publicly restricted access communication channel that gives businesses and individuals alike the ability to gain security benefits as an intranet without the usual expense.

It is an additional object of the invention to solve the major problems currently constraining the use of email for business purposes, so that business users can expand their customer service and income opportunities while reducing their email risk and expense.

Brief Description of the Drawings

Figure 1 is a block diagram of an ePost and Internet ePostal Office communication system constructed and operated in accordance with the present invention;

Figures 2A and 2B are an operational block diagram for Sender ePostal operations including Sender ePostal software according to the present invention used in the system shown in Figure 1;

Figures 3A-3C are an operational block diagram for ePostal server software in accordance with the present invention operating as an ePost Office communicating over the Internet between Sender and Receiver as shown in Figure 1;

Figures 4A-1, 4A-2, and 4B are operational block diagrams for Receiver ePostal operations with and without, respectively, Receiver ePostal software according to the present invention used in the system shown in Figure 1;

Figure 5 is a view corresponding to Figure 1 of alternative embodiments of this invention, where Sender and Receiver do not have the ePostal software shown in Figures 2A, 2B, 4A - 1, and 4A-2 on the computer they are currently using, but have ePostal accounts, and may send and receive eLetters through the ePostal system in the ePost Office window, or ePostal website;

Figure 6 is an operational block diagram of sender ePostal operational interactions in the ePost Office "window", or ePostal website, according to the present invention for use in the embodiment shown in Figure 5;

Figure 7 is an operational block diagram of the receiver ePostal operational interactions in the ePost Office window, or ePostal website according to the present invention for use in the embodiment shown in Figure 5;

Figure 8 is a view corresponding to Figures 1 and 9 of another embodiment of the invention where, within a network, ePostal operating elements according to the invention are shared between both Sender / Receiver level and network server level. ;

Figure 9 is a view corresponding to Figure 1 of another embodiment of the invention using various modes of internet connection;

Figure 10 is a view corresponding to Figure 1 of another embodiment of the invention showing a physical delivery option to the Receiver;

Figure 11 is a view corresponding to Figure 1 showing alternative embodiments of the invention for sending ePostal email and related ePostal data from Sender to ePost Office;

Figure 12 is a view corresponding to Figure 1 showing alternative embodiments of the invention for sending ePostal email and related ePostal data from the ePost Office to the Receiver;

Figure 13 is a view corresponding to Figure 1 showing alternative embodiments of the invention for sending ePostal email and related ePostal data directly from Sender to Receiver;

Figures 14A and 14B are an operational block diagram of an exemplary embodiment of steps for user loading, installation and activation of ePostal software;

Figure 15 is a view of an exemplary embodiment for direct communications between the ePostal Client software (Sender and Receiver) and the ePost Office; Figures 16A and 16B are an operational block diagram of an exemplary embodiment of direct communications between Client software and the ePost Office;

Figure 17 is a table showing an exemplary embodiment of message data structures according to the present invention for direct communications between ePostal Client software and ePost Office;

Figures 18A and 18B are an operational flowchart of an exemplary embodiment of the Sender step sequence for processing an eLetter and sending it to the ePost Office;

Figure 19 is a table showing an exemplary embodiment of constructing a custom eLetter header according to the present invention for transmission from the Sender to the ePost Office;

Figures 20A and 20B are an operational flowchart of an exemplary embodiment of the ePost Office sequence of steps for processing an eLetter and sending it to the recipient;

Figure 21 is a table showing an exemplary embodiment of constructing the custom headers of an eLetter in accordance with the present invention for transmission from the Sender to the ePost Office; and

Figures 22A and 22B are an operational flowchart of an exemplary embodiment of the Receiver step sequence for final processing of an eLetter.

Detailed Description of the Invention

Figure 1 shows a communication system 10 according to the present invention that connects many system users (although only two are shown) who are, with respect to any given transaction, either an email sender 12 ("email"). ) and attached documents or files, or a Recipient 14 of that email and attached documents or files. Communication system 10 is described herein as an "ePostal Service" and the email carried on the IOe system operated in accordance with the present invention is also referred to herein as an "eLetter", "document", or simply "mail" . (The term "eLetter" is used only when an email will be or has been processed by this invention. The terms "ePostal", "ePost Office" and "eLetter" used herein are service marks of ePostal, Inc. Services. , from Stamford, Connecticut.) A Sender 12 can send the same email to one Target Recipient 14, or multiple Receivers 14. A given Receiver with access to the ePostal system can also be an eLetters Sender. The illustrated Sender 12 may be a Receiver 14, and vice versa. System 10 includes known telecommunication calls 16 between each Sender or Senders 12 and the Internet 18 by a Sender ISP 19 and between the Internet and each Receiver or Receivers 14 by a Receiver ISP 19.

Sender and Receiver users may typically use computing and processing devices known as PCs (personal computers), as shown in Figure 1 as connected to send email over the Internet and access through an ISP 19, but they may use other communication devices. computing and processing such as servers and hand held devices as well as PCs. These user interface devices are commonly referred to herein as "terminals". It will be appreciated that the terminals may have varying degrees of intelligence, from which they are essentially I / O devices to devices that provide meaningful information processing using resident and / or loaded software. In particular, the terminals may operate as a component of a network with a server and / or together with other connected computers and software, to provide the operational functions described below features of this invention. The terms "Sender" and "Receiver" as used herein therefore mean the terminal and software operable on or by that terminal.

In addition, as shown in Figure 9, although this description in Figure 1 refers to an ISP 19 as an intermediary between Sender / Receiver and the Internet, the current type of email and server access server connection can be any existing alternative providing such Sender / Receiver services, such as corporate and email access servers from corporate intranets or other networks such as extranets, LANs or the like. Conventional fireproof barriers and filters are typically present in this system. Also as shown in Figures 9 and 10, the specific type of physical telecommunication connection may also use various alternatives, such as telephone, cell phone, DSL, cable, satellite or other form of wireless communications, and even physical delivery (Figure 10 ).

The present invention uses, complements and augments the basic known web messaging and SMTP Internet e-mail systems. As used herein, "Internet" is intended to include both. The present invention features what is called here an ePost Office 20 (Figure 1). In its presently preferred form, the ePost Office 20 is a server, or set of servers, running the exemplary software 24, 24 'shown in Figures 3-C, 4B, 6 and 7, and connected to the Internet by telecommunication links. 16. While ePost Office 20 will be described as a server running postal software 24, 24 ', it will be understood that the server may be several servers or equivalent hardware and software. As used herein, the terms "ePost Office", "ePO", "postal server", "electronic postal service" and "postal server and software" encompass all of these variations and other known equivalents.

In practice, all ePO 20 servers or server pools may be located in one physical location. Alternatively, however, individual server sets may be located at multiple locations to which each such server set, running exemplary software 24, 24 ', is capable of performing ePO 20 functions for certain named Senders 12 and recipients 14, which appointments can be changed. As presently preferred, the entire group or network of geographically separated server pools running exemplary software 24, 24 'and connected to each other over the Internet and telecommunication links are coordinated for operational efficiency, availability and redundancy, scalability, services. improved user experience, and security advantages. When so interconnected in a network, the entire group or network of separate sets of ePost 20 Office servers is the ePost 20 Office of Figure 1.

EPost Office 20 communicates and coordinates with and between the Sender 12 and Receiver 14 server or similar PCs (the Sender and Receiver Terminals) running the exemplary software 22, 26 of Figures 2A, 2B, 4A-1 and 4A-2, which is in a preferred form installed on the PCs or servers of Sender 12 and Receiver 14, respectively. The ePost Office 20 operation, in interaction with the ePostal 22, 26 software on the Sender 12 and Receiver 14 terminals, utilizes both the basic Internet email SMTP system and the standard Web messaging HTTP system. . EPostal 22, 26 component software installed and / or operable on the Sender and Receiver PCs or servers is compatible with the operating system and application software (email and browser) on those PCs or servers.

There are several alternatives to how the ePost Office 20 in Figure 1 communicates and coordinates with and between Sender 12 and Receiver 14 in order for the communication system shown in Figure 1 to operate. Alternatives involve different ways for an eLetter to be processed and sent initially by Sender 12, and / or processed by the ePost Office 20, and / or delivered to and finally processed by Receiver 14. One variable in these alternatives is whether or not the message itself. eLetter (its content, rather than information to process the message) passes through the ePost Office 20. The second variable is alternative transmission protocols (and how they are used) to send and deliver the eLetter message and eLetter ePostal data. companions, which are required by the ePost Office 20 and Receiver 14 to process the eLetter from Sender 12 to Receiver 14. Here, "ePostal eLetter data" can also be referred to as "ePostal data", "ePostal data". ePostal "," eLetter message data "," eLetter data "," message data "," message data component "or the like.

Figure 11 shows four basic alternatives a) - d) for sending an eLetter from a Sender 12 to the ePost Office 20, each with a certain set of advantages and disadvantages discussed below. The connections between Sender 12, Sender ISP 19, and ePO 20 are shown in a simplified version of Figures 1, without telecommunication connections 16. While the general information flow to and from an eLetter is from Sender 12 to ePO 20, it is understood as shown in Figure 11 that there may be data transmissions in both directions including facilitating Internet connections that transmit eLetter information and exchanging security and message data.

In Alternative a), the eLetter message and all ePostal data needed to send, process and deliver the eLetter message as an eLetter are sent together by Sender 12 using a standard Internet mail protocol such as SMTP by the mail server. ISP 19 to the ePO mail server 20. This group of possible mail protocols is then referred to simply as SMTP. Advantages of this alternative include: all information is in one package; there is a minimum of transmissions and therefore less associated uncertainties; and since this is the most normal procedure for sending Internet mail, there is therefore less chance that any problems could arise along the transmission path to ePO 20.

In alternative b), the eLetter message and most ePostal processing data is sent as in Alternative a). However, a limited amount of ePostal processing data such as identification and security numbers for Sender 12 and eLetter would also be exchanged by Sender 12 with ePO 20 using some standard TCP application protocol such as HTTP by Sender ISP 19. Advantages of this Alternative include the security benefits that would come from the eLetter message, which could contain encrypted information, being sent separately from the second communication having the ePostal processing data containing the eLetter ID numbers and the decryption key for coded information. However, disadvantages include: more than minimal communications are required, and the user might need to be online when Sender 12 processes eLetter.

In Alternative c), only eLetter message and limited ePostal processing data such as identification and security numbers are sent by Sender 12 via SMTP protocols and Sender ISP mail server 19 to ePO 20. All Other ePostal data to process eLetter is sent directly to ePO 20 via HTTP or some other such protocol. This example is similar to Alternative b), except that there is more ePostal processing data sent directly to ePO 20 over HTTP, and illustrates that with Alternative b) there are many alternatives to the amount of data that can be sent separately, depending on programming and processing functions, all with almost the same results.

In alternative d), all information, including the eLetter message and all ePostal processing data, is sent straight to ePO 20 using an HTTP type protocol. This Alternative does not have the advantages of eLetter being shipped in two separate packages. Its disadvantages include the possible need for Sender 12 to be online when processing eLetter, depending on Sender 12 terminal systems, and the uncertain Internet mail issues that could be experienced with emails being sent in this manner.

If you send an eLetter through ePO 20, using any or a combination of these methods, dynamically selecting which is best depending on the sender situation. If a user is online or online, the preferred way is probably to be Alternative b). This is where Sender 12 communicates with ePO 20 over HTTP or some other such protocol, provides ePO 20 with ePostal data including the eLetter identification number, and gives or obtains from ePO a once-used encryption key. . The key is then used to encode eLetter and other ePostal processing data that is sent to ePO 20 by SMTP and the ISP mail server. However, if the user is not online, or not online, Alternative a) is likely to be used because no communication is required with ePO 20 prior to eLetter processing by Sender 12. Encryption of processing data eLetter and / or ePostal is performed with an encryption key that is stored and reserved for such purposes in Sender 12. Alternative d), however, may be used in a situation where a Sender 12 is always online, and / or The conditions or requirements in Sender 12, ePO 20 or Receiver 14 warrant this.

After an eLetter has been processed in the ePost 20 Office, if sent by ePO 20, the eLetter will be sent from ePO 20 to Receiver 14. Figure 12 shows three basic alternatives e) - g) to send an ePetter 20 eLetter to Receiver 14, each with a certain set of advantages and disadvantages. In Figure 12, the connections between ePO 20, Receiver ISP 19, and Receiver 14 are shown in a simplified version of Figure 1, without telecommunication connections. While the overall flow of information from and about an eLetter is from ePO 20 to Receiver 14, it is understood as shown in Figure 12 that there may be data transmissions in both directions including facilitating Internet connections that transmit eLetter information and exchanging data. safety data and message. In Alternative e), the eLetter message and all ePostal data required to send, process and deliver the message as an eLetter to Receiver 14 are sent together by ePO 20 using SMTP and POP, IMAP or other such mail protocols to the ePostal. Receiver ISP mail server 19, and then to Receiver 14. Advantages of this alternative include:

• All information is in one package.

• There is a minimum of transmissions which means less associated communication uncertainties.

· There is no other communication required that Receiver ISP eLetter 19 receives.

Therefore, Receiver 14 does not have to be or go online to finish eLetter processing, and since this is the most normal procedure for sending Internet mail, there is less chance that any problems could arise along the transmission path. from ePO 20 to the Receiver 14.

In addition, Alternative e), as well as Alternatives f) and g), recognize that Receiver 14's most likely and simplest, and perhaps even unique, means to receive such eLetter messages is from Receiver ISP Mail Server 19.

In Alternative f), the eLetter message and some ePostal processing data such as identification and security numbers for eLetter are sent to Receiver 14 by the Receiver ISP mail server 19. The amount of ePostal data sent with the eLetter may vary depending on the combination of functions of Receiver 14 and ISP 19 Receiver systems. When eLetter arrives at Receiver 14, Receiver 14 then communicates directly with ePO 20 via HTTP or some other such protocol, and ePO 20 gives Recipient 14 all remaining ePostal data required to terminate eLetter processing on Recipient 14. Advantages of this Alternative include the security benefits that would accrue because the eLetter message, which could contain encrypted information, is sent over HTTP separately from the second communication having ePostal data containing identification and security numbers for eLetter. However, disadvantages include: the requirement for a more complex set of communications with ePO 20 than in Alternative e), and Receiver 14 must be able to go online to finish eLetter processing. If Recipient 14 is not online or is not allowed to go online, then Recipient 14 cannot complete eLetter processing and must wait until Recipient 14 is online.

In Alternative g), ePO 20 first sends Receiver 14 an ePO eLetter that has no Sender eLetter message part in it. This ePO eLetter sent by ePO 20 has only limited identification and security numbers for Sender eLetter 12 and informs Receiver 14 that an eLetter is being contained to Receiver 14 in ePO 20. Receiver 14 then communicates with ePO 20 using HTTP or some other such protocol, and ePO 20 gives Receiver 14 the sender eLetter 12 and all the ePostal data required to terminate sender 12 eLetter processing on Receiver 14. Alternative g) has the same disadvantage as a Alternative f), as Receiver 14 might not be or go online to get ePO 20 and the eLetter and ePostal data needed for final processing. Alternative g) however has some security advantage over Alternative f) because no part of the Sender 12 eLetter message is transmitted from ePO 20 to Receiver 14 until Receiver 14 has the required ePostal data to terminate eLetter processing.

In many cases, the preferred form of the ePostal 10 system among these three alternatives is Alternative e). And the simplest with the least communications, has the flexibility of not having to go online for more information, and provides good security. However, there are combinations of Receiver 14 and Receiver 19 ISP system functions where either Alternative f) or Alternative g) is preferred. Such a situation is where Receiver 14 is always or normally online, or most likely would go online if required for ePostal data communications with ePO 20. As mentioned earlier, separate communications from the eLetter message and processing data. ePostal would add some security benefits. As another example, a form of Alternative g) is used when an eLetter is sent to a Receiver who does not have Receiver software 26.

In Figure 13, there are two basic alternatives h) and i) shown for sending an eLetter message from a Sender 12 to Receiver 14, but not by the ePost Office 20. Each alternative has its advantages and disadvantages. The connections between Sender 12, Sender ISP 19, Receiver ISP 19, and Receiver 14 are shown in a simplified version of Figure 1, without telecommunication connections. While the overall flow of information from and about an eLetter is from Sender 12 to Receiver 14 (and some information to and from ePO 20), it is understood as shown in Figure 13 that there may be data transmissions on both and / or all. directions between Sender 12, Receiver 14, and ePO 20 including facilitating Internet connections that transmit eLetter information and exchanging security and message data.

In Alternative h), the eLetter message and most ePostal data needed to send, process and deliver the message as an eLetter are sent together by Sender 12 using standard Internet mail protocols such as SMTP and POP / IMAP to Recipient 19 and Recipient 14 ISPs, without going through the ePost Office 20. However, a limited amount of ePostal processing data such as identification and security numbers for Sender 12 and eLetter, which are essential for processing eLetter, would also be exchanged by Sender 12 directly with ePO 20 using some standard TCP application protocol such as HTTP by Sender ISP 19. After Receiver 14 receives the eLetter message and ePostal data, Receiver 14 then communicates directly with ePO 20 using some standard TCP application protocol such as HTTP by Receiver ISP 19 in order to receive from ePO 20 the remaining limited amount of data. ePostal processing machines that did not have the eLetter message. Receiver 14 then terminates eLetter processing. The advantages and disadvantages of this Alternative h) are discussed below, along with those of Alternative i).

In Alternative i), the eLetter message and only a limited amount of ePostal processing data such as eLetter identification and security numbers are sent along by Sender 12 using standard Internet mail protocols such as SMTP and POP / IMAP to Receiver 19 and Receiver 14 ISP, without passing through the ePost Office 20. However, most ePostal data needed to send, process and deliver the eLetter message as an eLetter would be exchanged by Sender 12 directly with ePO 20. using some standard TCP application protocol such as HTTP by Sender ISP 19. After Receiver 14 receives the eLetter message and limited ePostal data, the Receiver then communicates directly with ePO 20 using some sender application protocol. Standard TCP such as HTTP by Receiver ISP 19, to receive from ePO 20 ePostal processing data that was not with the eLetter message. Receiver 14 then terminates eLetter processing. The advantages and disadvantages of this Alternative i) are discussed below with those of Alternative h).

Alternatives h) and i) are similar and only vary in the amount of ePostal processing data that is sent together with the eLetter message by Sender 12 using standard Internet mail protocols such as SMTP and POP / IMAP to Receiver ISP 19. and Receiver 14, without passing through the ePost 20 Office.

The only advantage these Alternatives could have is where Sender 12 and Receiver 14 for whatever reason would not prefer the eLetter message to go through the ePost Office 20. Alternative i) would have some security advantage over Alternative h) since most The ePostal processing data is not in the same communication transmission with the eLetter message.

However, the disadvantages of Alternatives h) and i) are numerous. First, the number of communications required would make these methods more complex with a greater chance of communication problems. Second, and much more importantly, the eLetter message does not pass through ePO 20, resulting in numerous disadvantages, including:

• ePO 20 cannot screen eLetter on behalf of Sender 12 and Receiver 14 for content and technical risks.

• ePO 20 cannot authenticate Sender 12, verify individual Sender certification, and evaluate eLetter message integrity as reliable on Receiver 14 as it can on ePO 20. This makes Sender 12 authentication, individual Sender certification. , and the assessment of eLetter's integrity under general circumstances is less reliable and therefore less reliable.

• ePO 20 cannot handle return functions for Sender 12 equally.

Therefore, there is a missed opportunity to provide additional value to Sender 12 and monitor the overall security of the ePostal system.

• ePO 20 could not provide Sender 12 and Receiver 14 with time stamps or tracked message records of eLetter message processing times on ePO 20.

• ePO 20 cannot provide Sender 12 with the most authoritative confirmation of ePostal fee for eLetter.

• ePO 20 cannot provide the same degree of non-repudiation for an eLetter that is selected by Sender 12 to be placed in the official ePostal eLetter repository. Standards for such official repositories require a copy of the original eLetter that goes through ePO 20 rather than being given a copy by Sender 12 or Receiver 14.

• Sending an encoded eLetter straight from one Sender 12 to multiple Recipients 14 rather than ePO 20 is much more complex and less secure, as will be shown later in detail about how ePO 20 processes and delivers encoded eLetters to multiple Recipients 14 .

From the foregoing, it is clear that sending an eLetter message through the ePost Office 20 as shown in Figures 11 and 12 has many advantages over sending the eLetter message to Receiver 14 while diverting ePO 20 as shown in Figure 13. Sending through ePO 20 is generally the preferred and most flexible form of the present invention. However, in certain combinations of Sender 12 and Receiver 14 situations, sending a direct eLetter to a Receiver 14 might be preferred. For example, a Receiver 14 may be a client workstation residing within a corporate network, where Receiver ISP 19 is essentially network and Internet mail access servers, and where ePostal network software as shown in Figure 8 operates with network mail servers, Internet access, and other corporate servers.

This software 22, 26 is installed, for example, together with the user opening an account with the ePostal Service, for example at least in part by upload.

Regarding the installation and opening of an Account with the ePost Office 20, there are alternatives to procedures for loading, installing and activating software 22, 26 on Sender 12 and Receiver 14 (the combination of which may also be referred to as the " Client "or" Client "software) before it can be used. The charging, installation and activation process and main alternatives are shown in Figures 14A and 14B. It would be understood by one skilled in the art that the specific steps in the process depend on the Client terminal technical environment including the operating system and email application.

The representative process as shown in Figure 14A begins with a set of steps included in a Load and Install Dl phase. The user initiates the process by deciding to load the software and describes to ePO important software components on the user's terminal such as the operating system, email application and web browser. This download can be done from either the ePost 20 Office website, an ePostal software CD, or any other ePostal media containing the required software that is compatible with the ePost terminal operating system and email application. user. The user terminal loads and saves a Client software installation file 22, 26 that the user terminal runs.

At this time, the user is presented with an end-user service and licensing agreement (EULSA), which the user must accept before upload can continue. EULSA could be introduced later in the process, but the alternative of introducing it at this time is better in order to discontinue the upload process if the user does not accept EULSA so that no additional software is loaded on the user's computer. If EULSA is accepted, the Client installation file loads and installs the rest of the software. Client software 22, 26 then communicates directly with ePO 20 using HTTP or some other such TCP application protocol by checking the online state of ePO 20. This completes the Load and Install Dl phase of installing the software. Client 22, 26.

A D2 Registration phase begins. Client software 22, 26, upon identifying that ePost Office 20 is ready to communicate, prompts the user to create an ePO 20 Account and gives the user an Account Creation screen into which the user enters the information. requested. The Client then transmits this user data to ePO 20 using HTTP or some other such TCP protocol. EPO 20 stores and processes user data, registers this new Account to the user, and transmits Account registration information back to Customer using the same protocol as HTTP that Customer used to communicate with ePO 20. This completes the D2 Registration phase of installing Client software 22, 26.

A Verification D3 phase begins. Client software 22, 26 then presents the user with a Credit Card (CC) screen in which the user enters the requested CC information. Client then transmits this user data to the ePost Office 20 using HTTP or some other such TCP protocol. EPO 20 receives the CC data and verifies that it is a valid CC for which the user could charge the costs for using the ePostal communication system. EPO 20 then transmits to Customer using the same protocol as HTTP that Customer used to communicate with ePO 20 that the Account was verified along with temporary Sender 12 and Receiver 14 identification and security data. An alternative to the foregoing is to provide Customer with temporary Sender 12 and Receiver 14 identification and security information prior to verifying the user's CC data. However, the former is the preferred form of the ePostal 10 system, so CC data is used as an added means of ensuring that the user is a legitimate person to have an ePO 20 Account before Customer receives the identification and security data, although this data has a temporary state. This completes the D3 Verification phase of installing Client software 22, 26.

Next, an Activation D4 phase begins. At this stage Client software 22, 26 is not considered Active by the ePost Office 20. Client is fully installed on the user's terminal, but not enabled for use with the user's email application to send and receive yet. eLetters. It is in a standby mode. At this time, ePO 20 e-mails a D5 Activation eLetter to the user's primary email address on the terminal where Client software 22, 26 is installed, registered and verified. Customer monitors incoming email for Activation eLetter. When the Activation eLetter arrives, Customer identifies it, analyzes the data on it, and stores the new identification and security data. Customer then transmits to ePO 20 using HTTP or some other such TCP application protocol that received the Activation eLetter and the new data. EPO 20 responds to Customer using the same protocol as HTTP that Customer used to communicate with ePO 20 that ePO 20 registered that the new Account is Active. This completes the D4 Activation phase of installing Client software 22, 26. You can now use Client to access all features and benefits of ePostal system.

An alternative to this mode of enabling Client software is not to use an Activation eLetter, but to use D6 direct communications between Client and ePO 20 over HTTP or some other TCP protocol. This can be done after or instead of the step where ePO 20 transmitted to the Customer that the Account had been verified along with the Sender 12 and Recipient 14 identification and security information. EPO 20 is transmitted to Customer using the same protocol as HTTP that Customer used to communicate with ePO 20 non-temporary identification and security data to activate the Account. Use of D5 Activation eLetter is the preferred form of the ePostal 10 system because it confirms that the primary email address provided by the user during the D2 Registration phase of software installation and establishment is valid, providing further confirmation of the legitimacy of the user. and therefore from the Account.

In the two main sections above describing 1) different alternatives for sending and receiving eLetters by or through the ePost Office 20, and 2) installing, registering, verifying and activating Client software 22, 26, there was considerable mention of the use of direct communications. These direct communications or data transmissions are between the Client 22, 26 Sender 12 and Receiver 14 software and ePO 20. There are two main alternative methods for structuring and executing these communications. These alternatives are shown in Figure 15.

The first alternative, "N" (for Normal), outlines what is the normal process and components of client computers communicating securely with 2nd party Internet web servers. The client computer's web browser creates a TCP / IP connection with a user-specified URL and uses HTTP (and HTML) as the TCP application protocol by which to communicate with the web server. This usually happens through port 25 on the server, aided by the use of cookies1, especially to identify to the web server with whom it is communicating. For secure transmissions using HTTPS, encryption is server controlled and makes use of an external third party for encryption keys and digital certificates.

While this same normal type of process can be used for the ePostal communication system 10 of Figure 1, it is not preferred. Instead, the ePostal 10 system process is custom made and shown as Alternative "C" (for Custom) in Figure 15. Security is improved independently of any third party for encryption keys and digital certificates and having a process owner control for encryption. The system is also more flexible if Customer identification is not dependent on the use of cookies that may be deleted, if communications are not solely dependent on a TCP application protocol that might not be available, and if a particular web browser not required. The ePostal communication system 10 is capable of providing the preferred way to structure and execute these communications because of the design of the communication system 10.

The preferred custom form of communication for use in the present invention, shown as "C" in Figure 15, takes advantage of the design of the invention, specifically the fact that Sender 12 and Receiver 14 using Client software 22, 26 may be communicate and transmit data directly to the ePost 20 Office using software 24, 24 ', and vice versa. In effect, the ePostal system 10 can communicate within itself, that is, create a communication network between the ePostal Client software 22, 26 operating at the Sender 12 and Receiver 14 terminals and the software 24, 24 '. ePost 20 Office servers operating on ePostal servers. The ePostal 10 system during these direct communications between ePO 20 and the Client (acting as its own web browser) simulates HTTPS sessions, uses its own session ids at once, establishes its own encryption / decryption keys. session at a time, and is capable of using multiple TCP application protocols by capitalizing on a single message data structure described in more detail below with reference to Figure 17, usable by these protocols. This system in effect creates qualities as a virtual intranet for its users, despite its use of the Internet and its public availability.

These direct communications (which will be called "direct comms", "ePO comms" or "comms") are important for performing the many administrative, help and support, Account maintenance and eLetter functions between Sender 12, ePost 20 and Receiver 14, including:

• Create a new account during software registration;

• Install and activate Client 22, 26 software on a different computer under an existing account;

• Auto-upgrade Client 22, 26 Sender 12, and Receiver 14 software;

• View and edit basic account information stored in ePO 20;

• Buy eLetter credits (eLetter credits are used

to pay to send eLetters);

• Check available eLetter credits and update local Customer record;

• Review eLetter credit balance and credit transaction history;

• Review a credit incentive recipient record earned by opening eLetters;

• Report an eLetter receipt to ePO 20.

• Notify a sender of an eLetter's receipt;

• Report the opening of an eLetter to ePO 20;

• Notify a sender of the opening of an eLetter;

• Review a history of submitted eLetters;

• Review all details belonging to a single submitted eLetter;

• Review a history of incoming eLetters;

• Review all details belonging to a single received eLetter;

• Update local Customer cost list for ePostal services; • Verify and update passwords and passwords;

• Report an eLetter's receipt of a nickname address, which Customer cannot process;

• Reporting the receipt of an eLetter not from a nickname address, which Customer cannot process.

As shown in Figures 16A and 16B, there are five basic steps that Client and ePO 20 use for all of these direct comms: open a Cl communications connection, establish a secure channel C2, authenticate Client C3, transmit C4 messages, and close session C5. Each step is included in several substeps.

Open a Cl communications connection

Customer has stored URL and port information for its direct comms with ePO 20. Not all Senders 12 and recipients 14 need to use the same IP address for ePO 20. As mentioned earlier, there are typically multiple server pools operating at local locations. different physical networks, communicating with Customers and each other. In addition, IP addresses for ePO 20 servers could change from time to time (for example, for security reasons), and Customer would receive the changed ePO 20 information by direct comms. While any standard TCP application protocol may work, it is presently preferred that the Client first attempt to connect using standard HTTP behavior over port 80, since it is most likely to be open. If communications are established, Customer continues to use HTTP for the remainder of the direct comms session. If for some reason HTTP fails, the Client connects using SMTP directly to ePO 20 via port 25 with standard and custom SMTP command tags. For example, with SMTP, when ePO 20 accepts the connection, Customer verifies the connection and sends ePO a standard EHLO SMTP command by which Customer identifies itself, which ePO 20 understands and accepts, and then Customer verifies. If these SMTP communications are established, Customer continues to use SMTP for the remainder of the direct comms session.

Establish a secure channel C2

Customer begins by generating a public / private key pair for this session. Customer submits a request to ePO 20, including the public key of the key pair. Although no key has yet been established to encode this first request message, rather than the alternative of leaving the message plaintext, the ePostal system 10 preferably uses a character draw and substitution to make the message more difficult to read. EPO 20 captures the request and stores the public key. EPO 20 generates and stores both a one-time use session id and symmetric key. Then ePO 20, using Customer's first request public key, encodes the session id and symmetric key, rewrites them as hexadecimal characters, and sends them back to Customer in a response. (In this example and then, references to rewrite data encoded with hexadecimal characters will mean rewriting data encoded with hexadecimal characters or some other similar encoding such as UUEncode to enable transmission of encoded data). Customer receives ePO 20 response and stores session id and symmetric key. The symmetric key generated by these steps will be used to encode and decrypt all data transmissions for the remainder of the communication session. The session id is required to be sent by Customer to ePO 20 on subsequent requests in this session so that ePostal servers can identify the session, and thus also the symmetric key to use. An alternative to encoding direct comms is the use of fixed public / private key pairs between ePO 20 and the Client. However, the ePostal preference uses symmetric encryption that is faster than asymmetric encryption, and because the session-based key is once more secure than reusing new keys. Authenticate C3 Client

Customer constructs a request message with session id and a block of data including a Customer id number, unknown even to the Customer user, and reissue of a user password. The password reprint can either be stored on the Client, or the user can be prompted for the password and a reprint created. The data block is then encoded using the symmetric session key and rewritten as hexadecimal characters. The Client communicates the message to ePO 20, which reads the session id, retrieves the associated symmetric key, and decrypts the data block. EPO 20 authenticates both the Client id number and password reissue to its records and stores that this session is authenticated (or not). EPO 20 then builds and sends a response to the Client that authentication is accepted (or not). This ePO 20 reply message to the Client does not contain the session id because the Client, unlike ePO 20 which sees these direct comms as asynchronous, sends a message to ePO 20 and then waits for a reply. Authentication alternatives include authentication of only or more than two parameters. Preference for the ePostal system in most cases, as explained above, efficiently provides dual Sender 12 authentication. EPO 20 may also periodically change Client ids to improve security.

Broadcast C4 Messages

To this extent direct comms have established only the means to secure later communications from this session and authenticate the Client to ePO 20. The messages transmitted below are those that assist in the current performance of some operational or administrative function that results in the performance of premium services. ePostal features characteristic of the ePostal 10 system. These messages are prepared and transmitted in the same way as the two messages in step C3 above, Authenticate the Customer. Customer builds and sends ePO 20 an order message. The message contains the session id, a data field indicating the size of the encoded data block, and the encoded data block, encoded with the symmetric session key and rewritten in hexadecimal characters. Message data has a unique structure for the ePostal 10 communication system, tailoring its particular data requirements, communication needs and capabilities, and the ePostal 10 communication system of this invention. After ePO 20 receives the order message from Customer, ePO 20 decrypts and processes the data according to the instructions contained within the data block. EPO 20 then prepares a response message for Customer which, like Customer's request message, has a unique structure for the ePostal 10 communication system. The ePO 20 response message for Customer in this step C4, as in step C3 and as mentioned above in step description C3, does not contain the session id because the Client, unlike ePO 20 which sees these direct comms as asynchronous, sends a message to ePO and then waits for a response. The ePO response 20 contains a data field indicating the size of the encoded data block and then the encoded data block, encoded with the symmetric session key and rewritten in hexadecimal characters. From this point in this description of the invention, when data is mentioned as being encoded for any transmission, it will mean that the encoded data block is rewritten in hexadecimal characters or the like to transform encoded data so that it can be transmitted in direct comms as discussed above. Then ePO 20 communicates its response message to the Customer, who decrypts the data block and processes the data according to the instructions contained within the data block.

Close connection C5

When Customer has met its communication needs for this session, Customer communicates ePO 20 with a request message to terminate the session. EPO 20 responds with acceptance. It should be understood throughout this request that where an acceptance is mentioned as the content of an ePO or Customer response that instead a message with a declination to accept, an error message or a similar message could also result. In these other situations, ad hoc measures not belonging to the general process described would be taken subsequently to resolve the problem.

Also, for some direct communications, the set of steps will vary from those discussed above. In many cases, the ePostal 10 system will operate best when you combine step C3 with step C4 and / or step C4 with step C5 in various ways. The particular combination depends on the purposes of the direct communications used and how data combinations and instructions for their use in the data blocks can best be constructed for the most efficient and reliable performance of ePostal functions. For example, it may be preferable to authenticate, process data, and respond to Customer all in a set of request and response communications between Customer and ePO 20.

In the preceding discussion of the steps used by Customer and ePO 20 in their direct communications, a single message structure is used, and the message contains instructions to the recipient of direct comms, either ePO 20 or Customer, on how to process the data. in the messages. The single message structure is exposed and described with reference to Figure 17.

The data fields in direct comms messages are very similar to Customer request messages and ePO 20 response messages. Both are included in a data block encoded with the data block size just before that. The only structural difference between Customer's request messages and ePO 20 response messages, as mentioned above, is that Customer's request messages also contain a session id that is needed so that ePostal servers can identify the session, and therefore also the symmetric key to use. In contrast, ePO 20 reply messages do not contain the session id because the Client, unlike ePO 20 which views these direct comms as asynchronous, sends a message to ePO 20 and then waits for a reply.

The structure of the data block that is encoded is also unique to the ePostal communication system 10 and is shown in Figure 17. First in data block 40 is a random noise block 42 whose size is also known; This data helps in encryption security performance. Then there is a message type 44 that specifies to the recipient the type or purpose of the request or response message; The recipient of this type of message knows what data to expect in the rest of the data block and what to do with it. Then there are pairs of career lengths of data 46 and careers of related data 48; These careers 46, 48 are data that are processed to help perform operational and administrative functions that result in the performance of ePostal features; Depending on the type of message, there could be any number of data career pairs and their lengths. These data fields as described above provide the same structure for request and response messages. With the same message structures within standard TCP protocol wrappers, processing is similar if they are transmitted over HTTP, SMTP, or any other TCP application protocol. Using HTTP, most ePO Customer requests will use an ACQUIRE or PUT command with the data field, and ePO responses will use the ANSWER command with the data field wrapped in standard HTML and body tags to indicate that They are HTML messages. Using SMTP, most requests to ePO will use an EPSA command (a custom SMTP command created for communication system 10 and known to ePO 20) with the data field ending with a space, career end and \ r \ n, and ePO responses will use the ANSWER command with the data field ending with a space, the END row and \ r \ n. There are many possible alternative combinations of how to structure and process data within these request and response messages.

There may be different content or data in the data field and different sequences for the data in the data field; There may be alternative ways to communicate what data the recipient should expect in the message and what to do with it. and there may be other ways to encode these messages. However, because the method explained above is the simplest, most efficient and most flexible way to use multiple TCP protocols, it is the presently preferred structure for ePostal system operation 10.

In the previous discussion of direct communications, step C3 of Figures 16A is Authenticating the Customer. This means that Sender 12 as defined above as the terminal and its ePostal Client software is authenticated. The individual or user who opened the Account with the ePostal software on Sender 12 can also make sure that the person actually submitting the Customer's eLetter. The individual user can also have an Account on more than one terminal with ePostal Client software, such as an office desk and a travel laptop. The individual user can also have multiple Accounts across multiple terminals, making it easier for an individual to work with ePost Office 20 on Personal and Business Accounts on any of their terminals. In addition, the individual user can use multiple email addresses with any of their ePostal Accounts and any of their terminals. For the ePostal 10 system to do this, all id numbers for the individual User Accounts, the terminals with the Client software, and the email addresses must be related to each other at ePost Office 20, so all Direct communications and other methods of ePostal communication systems can also accommodate and track these id numbers and relationships. The alternative to this previous multi-capacity service is to limit the number of Accounts, terminals with Client software, and email addresses that an individual user can have with the ePostal 10 system. While this limiting alternative would be simpler for To manage and track, the currently preferred structure for operating the ePostal 10 system is the Multiple Account, Terminal and Email Address method because it provides the individual user with a much more robust, comprehensive service.

Sender 12 in Figure 1 may choose to send their email over the Internet either in the conventional manner, or using ePost Office 20. To use the ePost Office 20 of this invention, users need to do little more in the form of the invention shown. Figure 1 of what they do when sending or receiving a conventional email. For example, with reference to Figures 2A and 2B, Sender user 12 opens the email application Sle creates an email, Step S2, as usual (with or without attachment) within the email application. The Sender 12 user just needs to click (Step S3) on an icon and proceed through (Step S4) a facility to follow a set of service selections that he wants to apply to e-mail via the ePostal system, clicking to continue, confirm. and send the eLetter from the sender's own PC, all electronically and apparently the same to the sender's user, via sender's own ISP, the Internet 18, and the recipient's ISP, to the recipient's user 14, as shown in Figure 1.

Exemplary Sender software 22 according to the present invention as installed or operable on a Sender PC, or the like, is shown and described in Figures 2A and 2B. The Sender 22 software reflects that the Sender 12 user has subscribed to the ePostal Service and had an account with it. Exemplary software 24, 24 'according to the present invention that implements ePost Office 20 in a manner according to the present invention is shown and described in Figures 2A, 2B, 3A-C, 4B, 6, and 7, respectively. . Exemplary Receiver software 26 according to the present invention as installed on Receiver PC 14, or the like, is shown and described in Figures 4A-1 and 4A-2. Receiver 26 software reflects that Receiver 14 user has subscribed to the ePostal Service and had an account with it. It will be understood by those skilled in the art that specific code implementations of this software 22, 24, 24 'and 26 will depend on the operating environment, for example, the nature of the hardware, system and application software, the nature of the communication system and its protocol. interfaces, and the use of features such as encryption, filters, and firewalls. EPostal System users may have different combinations of operating systems and email and browser software. This invention uses interfaces, add-ons, or various sets of procedures and programming each to connect with different combinations of operating systems and sender or receiver application software (email and browser) that also function to connect over calls to the postal server. .

As shown, or with reference to Figures 1, 2A, 2B, 3A-3C, 4A-1, 4A-2, 4B, 6 and 7, the ePost 20 Office and its software 24, 24 ', in cooperation with the Software 22 and 26, performs the mail processing functions of traditional postal services in a completely electronic process. More specifically, the present invention, as outlined in detail in Figures 2A, 2B, 3A-3C, 4A-1, 4A-2, 4B, 6 and 7, operates to provide:

• Helps Sender 12 users in selecting services to provide;

• Sender eLetters Collection 12 and delivery to ePost Office 20;

• Receipt and acceptance of eLetters by the ePost 20 Office;

• Screening of eLetters for security purposes; • Sender Authentication 12 and Sender 12 user certification;

• Collection of fees to process eLetters by the system;

• Application of services and processing of eLetters;

• Inherent reduction or filtering of the number of potential eLetters;

• Identification, marking and prioritization of eLetters;

• Indication and timestamp of ePost 20 Office processing;

• Guaranteed eLetters receipt, transmission and delivery process;

• Delivery of eLetters to Recipients 14;

• Receiver 14 user certification of openness;

• Collection of Responses / Receipts from Receivers 14, as required;

• Notification to Sender 12 of Receiver 14 responses as required;

• Other special services such as:

- Retain eLetters while Receiver 14 user is away for an extended time from his / her mailbox / computer and email application;

- Provide options for accessing the ePost 20 Office, such as going to the ePost 20 Office "window" or website, rather than working through your own mailbox / email application;

- Enable businesses on their own websites to measure, gather and manage aspects of the ePostal process.

More specifically, exemplary software functions 22 of Sender 12 as set forth or with reference to Figures 2A and 2B include:

• Assist Sender 12 in S4 user within their own email application in selecting which ePostal services are applied to their email such as:

- Special ePostal industry markup, value and priority indicators that differentiate eLetters from all other email;

- Cryptography;

- Sender 12 user certification, instead of just Sender. (Sender Authentication 12 is standard with all eLetters);

- Notifications to Receiver 12 of Receiver 14 and opening of eLetters;

- Opening certification by the user of Receiver 14;

- Prepaid answers for Receiver 14 user to reply to Sender eLetter 12 back by ePostal system;

- Physical copy delivery to Recipient 14 user.

• Preparation and processing for eLetters to be sent to ePost 20 Office:

- Perform accurate and appropriate communications with ePost 20 Office;

- Determine if the Email Recipient has an ePostal account, and if not, identify the sender's choices 12;

- Check if Sender 12 has enough credits to use

the ePostal system, and if not, get more credits;

- Label eLetters with selected services and other information for ePost Office 20;

- Encode eLetters, if required;

- Perform Sender 12 user certification if required;

- Determine appropriate process for sending eLetters and / or eLetter data to ePost Office 20, such as based on standard email SMTP or standard web message HTTP.

• Maintain repository of encoded content proof eLetters, if designated by Sender 12:

• Send eLetters to ePost 20 Office;

• Sort eLetters sent in special ePostal folders;

• Track notifications returned for associated sent eLetters;

• Perform various administrative and maintenance account activities to keep Sender 12 current in such areas as: ePostal services offered, credits required, and security features;

• Assist Sender 12 in managing ePostal communications and interactions with ePost Office 20;

• Work seamlessly with Sender 12 email and browser applications.

With respect to exemplary Sender software 22, described above and shown in Figures 2A and 2B, an additional exemplary sequence of 15 processing steps and presently preferred system structure for operation are described below with reference to Figures 18A and 18B.

Alternatives to starting ePostal services in step SPl in Figure 18A from within an email application and selecting specific services include:

• A user can choose to use the services before or after creating a new email. In any case, the user somehow indicates that he has finished creating his new email, and is ready to send it through the ePostal 10 system. So, while both possibilities for when choosing to use the ePostal 10 system need being handled for the ease of use of the services, both also require the new message window to contain a means for selecting the ePostal process.

• Also from within the new message window, there are alternatives to how to select to use ePostal services by clicking an icon button on a toolbar or a line item in a drop down menu list. Preferably, the ePostal 10 system accommodates both alternatives to provide the most flexible and easy to use services for the user.

• About selecting specific ePostal services to apply to the new eLetter, an alternative process is to give the user one or more continued ePostal service selection screens to choose from, and then a second screen to allow the user to review which services they have selected. and confirm your selection. The ePostal system preferably presents the user with as many screens as possible, for example using only one screen through which the user selects services, reviews, and confirms them for submission. However, in situations such as where the range of services offered to a user is too extensive, or where the user's email application requires an additional screen, then the ePostal 10 system preferably uses the two screen approach.

It is noted that, as already mentioned above, a selection from among the alternatives available to perform ePostal functions depends on the specific operating system, email application, and web browser combination that exist in Sender 12 and Receiver 14. A Specific version of ePostal 22 and 24 software that is present will be one that works with the existing combination of operating system, email application and web browser software. As previously mentioned, the correct ePostal software version is determined at the time of software installation 22 and 24, after the ePost Office 20 reviews user-provided information about your operating system, email application and web browser. and after ePO 20 performs any possible verification on that data.

With respect to exemplary Sender software 22 (described above and shown in Figures 2A and 2B) and the Sender processing sequence and preferred forms (shown in Figures 18A and 18B), Sender 12 begins processing in step SP2 a new eLetter thereafter. The user selects the services to apply and clicks to send the email through the ePostal system. Again, there are alternatives and choices for how Sender 12 does this processing.

Alternatives in implementing data processing

Sender 12 includes how Sender 12 determines the cost of the selected services and the number of ePostal credits required. In ePO 20, there is an official ePostal account balance and credit history bank for each Sender Account 12. Sender 12 may use direct comms at the time of Sender 12 processing to verify with the ePO 20 credit bank that the Sender 12 has enough ePostal credits to cover the new eLetter in step SP3. As an alternative, Sender 12 has a local ePostal credit bank on Sender 12 that tracks the balance and history of ePostal credit usage for each Sender 12 Account in step SP4. Preferably, the ePostal 10 system has both the local bank on Sender 12 and the official credit bank on ePO 20 because Sender 12 may not be online, or able to go online, to use direct comms to check balances. Sender Account Credit Cards in ePO 20. With the local bank in Sender 12, there is then an ability to estimate the official Account credit balances that are kept in ePO 20 without going online. Preferably, Sender 12 checks the credit balance on ePO 20 using direct comms, and if Sender 12 cannot be online, Sender 12 has the local credit bank to estimate Account credit balances for the new eLetter. If the credit balance is not sufficient for a new eLetter in step SP5, Sender 12 software 22 informs the user of the need to purchase new credits and begins the process of buying ePostal credits using direct comms with ePO 20. Another alternative is that the user buys ePostal credits by going to the ePO 20 website using their web browser and then using the ePost 20 Office 24 software as shown in Figures 3A-C. Preferably, both alternatives to purchase credits are available to the user, via direct comms and on the website.

As another alternative implementation of Sender 12 processing of a new eLetter, Sender 12 determines if each of the eLetter Receiver email addresses is associated with any ePost 20 Office User Account, for example by Sender 12 using direct comms with ePO 20. An alternative to checking the status of each Recipient in ePO 20 is not to check the status of the recipient's email address in step SP6. The alternative selected for ePostal 10 system operation depends on the ePostal 10 system administration privacy policy regarding the exposure of user information to others.

Another alternative implementation of the present invention is to reverse the order, that is to verify recipient email addresses and then ePostal credits. In many cases, the order in which the specific steps of processing an eLetter are actually performed is not important. In fact, as will be appreciated by those skilled in the art, there are many alternatives to do so. On the other hand, some processing steps that have an inherent order to them or else they cannot be done. The importance of sequencing depends on the specific processing step that may depend on the software version 22 that was installed on Sender 12, the user-selected ePostal services, and other variables that would be understood by those skilled in the art as indicated in step SP7.

With respect to exemplary Sender software 22 (described above and shown in Figures 2A and 2B) and preferred Sender processing methods (shown in Figures 18A and 18B), sender 12 processing of an eLetter is also dependent on step SP7 of the steps selected to send, process and deliver an eLetter from Sender 12 to Receiver 14 as described above. To recap briefly, the two main alternatives are sending the eLetter message itself either through the ePost 20 Office, or diverting the ePO 20 and sending the eLetter message directly to the Recipient 14. The other alternatives, which are subordinate to these two principals, involve How much of the ePostal data that is required for eLetter's required processing after it has been sent from Sender 12 and for delivery to Receiver 14 is sent with the eLetter message itself. In most cases, the ePostal 10 system is preferably implemented, for the reasons discussed below, as follows:

• Sender 12 sends the eLetter message and most if not all ePostal processing data through the Sender 19 ISP mail server to ePO 20, with the rest sent to ePO 20 via direct ePostal comms.

• Then, ePO 20 sends the eLetter message and most if not all processing data from the Receiver 19 ISP ePostal mail server to Receiver 14, with the rest sent to Receiver 14 via direct ePostal comms.

Typical steps in processing an eLetter on Sender 12 on

SP8 are discussed below and shown in Figures 18A and 18B. They generally belong to all possible alternatives for sending eLetter from Sender 12 to Receiver 14, including the generally preferred implementation, which is to send eLetter's own message and most, if not all, Sender 12 ePostal processing data. by ePO 20 to Receiver 14.

It should be noted that all exemplary shipping and delivery alternatives (including going or not going through ePO) may be implemented using some or all of: • the system structure for operation described above and below to process eLetter on Sender 12;

• the system structure for operation described above and below for processing in ePO 20;

• the system structure for operation described above and below for receiving and processing eLetter by Receiver 14;

• the implementation of direct communications operations that were previously discussed; and

• information communicated by ePO 20 to Sender 12 and Receiver 14 by direct comms, an ePostal eLetter, or other ePostal communications considering which particular implementation of sending an eLetter to Receiver 14 should Sender 12 use.

Shipper 12 processes an eLetter so that the eLetter is prepared with sufficient ePostal data and instructions so that the ePost Office 20 and the ePostal 10 system (including Receiver 14) will generally know how to continue processing and delivery of eLetter to Receiver 14. This data can be added to eLetter at various alternative locations on eLetter such as: within the subject, or body, or as an attachment (which can be thought of as a body part), or as a custom header. Preferably, the ePostal system 10 uses one custom header or multiple custom headers in step SP9. If a private email application in Sender 12 does not allow custom headers or requires data to be elsewhere, then another location would be used.

Sender 12 prepares the custom header in step SP9 to include not only data for processing eLetter in ePO 20, but also data for verifying and authenticating eLetter. Verification indicates that the eLetter message was not changed during transmission from Sender 12 to ePO 20, and authentication indicates that the eLetter actually originated from Sender 12. There are numerous sequences in which the incoming eLetter in ePO 20 can be processed which therefore means There are many different ways that the data in the custom header could be arranged. The preferred arrangement of this invention is that the sequence in ePO 20 first identifies, verifies and authenticates eLetter and then executes the rest of the process. This is because there is no reason to completely process an ePO 20 email if the email is not from an authentic ePostal User Account; such an email would not be an eLetter. Therefore, the data in the custom header for identification, verification and authentication must be available from the custom header before or at least at the same time as the data to process.

The structure of an exemplary custom header is shown and described in Figure 19 as parts 1-3. There are three parts, 19-1, 19-2 and 19-3. Alternatively, these three parts can be treated as all forming a custom header, or they can be three custom headers, or more headers. Preferably, there is a custom three part header. The physical sequence of the three parts in the usual header is not ordinarily that important. However, preferably they are ordered in the logical sequence in which they are used.

Part 1, Figure 19-1 contains ID numbers for Sender 12. These numbers identify Sender 12 in ePO 20 upon eLetter arrival at ePO 20. These numbers tell ePO 20 which encryption key should be used to decrypt Part 2 of the header. usually.

Part 2, Figure 19-2 contains the Message Condense Code (AlDC) value and the encryption key to decrypt Part 3 of the custom header. MDC is used to check eLetter when it arrives at ePO. It is also one of several ways to authenticate that eLetter is from Sender 12. Part 3, Figure 19-3 contains ePostal processing data, including:

• A unique set of data, for example numbers, that identify eLetter and are used to process and track future eLetter-related transactions;

• Data identifying which ePostal services were selected by Sender 12;

• Sender 12 and Receiver 14 data, such as identification numbers and email addresses. The "To", "cc", and "bcc" information is removed from eLetter's headers and put in Part 3, along with their reprint value. The "From" and "Answer to" information is also put into Part 3, along with their reprint value. The ePost 20 Office SMTP email address for this Sender 12 replaces the original recipient email address in the "To" header, allowing the eLetter to be redirected to the ePost 20 Office. Reissues of this data allow modes to verify eLetter security and authenticate Sender 12;

• The encryption key to decrypt eLetter's message body if encryption were a selected service.

Although not shown in Figure 19, it should be understood that any data in Parts 1, 2, and 3 will include data size unless ePO 20 otherwise knows this information. Also, although not shown in Figure 19, random noise can be added to the data in Parts 2 and 3 before it is encoded for security purposes.

As mentioned in the description of direct communications, because there will be data encoded in the custom header, the custom header will be rewritten in hexadecimal code for transmission.

Alternatively, the header may have only two parts instead of three, or more than three parts. Two parts is a minimum since one part is required to be in plain text so that ePO 20 can read Sender ID numbers 12 to know which encryption key is required to decrypt the rest of the custom header. However, three parts provide added security as it allows for other data encryption in Part 3 with another encryption key that adds security and when decrypted can provide additional verification and authentication evidence other than using only data in Part 2. Having more Three-part and more encryption steps can add greater security, but this structure should not be necessary except in unusual situations. The preferred header structure and method of operating the ePostal system 10 is to use a custom three-part header as shown in Figure 19, in step SP9 Figure 18A, and described above.

Exemplary Sender software 22 (described above with reference to Figures 2A and 2B) and Exemplary Sender processing (described above with reference to Figures 18A and 18B) use a custom header as part of eLetter processing, with the information of Original "To / cc / bcc" removed from their headers and placed in Part 3 of the usual header in step SP10 in Figure 18A. An ePO 20 email address in step SP11 is then placed in the "To" header, directing eLetter to ePO 20. An SMTP alternative to sending to eLetter is to use SMTP relay routing that would keep the Receiver addresses. 14 originals in the "To", "cc", and "bcc" headers. In this alternative, an eLetter for each Receiver 14 is received separately in ePO 20, and ePO 20 then processes and forwards each of them to Receivers 14. This alternative, as will be explained more fully later, may simplify some processing of multiple eLetters. ePO 20, but delivery of eLetters to ePO 20 is much more uncertain because there is no guarantee that Sender ISP 19 will relay each or any of the different recipient address eLetters to ePO 20. Therefore, the system ePostal 10 preferably sends, as mentioned above, removing Receiver addresses 14 from the "To", "cc", and "bcc" headers, placing them in Part 3 of the usual header in step SP10, and replacing them with the ePO address 20 specified in step SPll for this Sender 12 in the "To" header that sends the eLetter directly to ePO 20. Using this preferred arrangement, the ePostal system keeps information addressing addressing the current transmission route. This avoids other potential problems that relaying can cause.

The foregoing discussion of exemplary Sender software 22 (Figures 2A and 2B) the preferred Sender processing and arrangements (Figures 18A and 18B), and the previous discussion of Sender 12 preparing a custom header as part of processing an eLetter describes usage encryption and decryption keys. In fact, encryption is needed in many places within the ePostal 10 communication system such as:

• in the eLetter message body when the ePostal encryption service is selected (everywhere here when the encryption or reissue of the eLetter message "body" is mentioned, someone is to understand that "body" means "attachments" equally ).

• eLetter custom headers that contain ePostal processing data;

• in direct communications;

• ePostal system data stored at the Client, network level and ePost Office 20.

As will be appreciated by those skilled in the art, there are many alternatives for performing encryption. For example, significant variables include the encryption algorithm and the encryption key length. The algorithm can be asymmetric or symmetrical, and within these two categories there are several specific alternatives. Alternative algorithms may be publicly and commercially available and / or proprietary to the ePostal 10 system. Additionally, the algorithms used may be included in Sender software 22 or in the cryptographic libraries of Sender 12 terminal operating systems, which libraries are called by the Sender 22 software to be used.

The arrangement for any of the encryption and decryption processes performed by the ePostal 10 system software, whether at a Client, network level or at the ePost Office 20, depends on the Client software, the ePostal network software operating environment ( Figure 8), and ePostal 10 system needs and capabilities for cryptographic system compatibility. The preferred form also depends on the relative security and speed of the encoding / decoding algorithm that is selected. More generally, the preferred way for the ePostal system 10 to encode an eLetter message body is the use of a symmetric algorithm and a key selected to be long enough to provide the desired level of security. The ePostal 10 system uses an algorithm that can be called the Sender 12 operating system. If such an algorithm or library is not available, a sufficient symmetric algorithm is provided in the Sender 22 software. These same alternatives and preferences can apply to all the cryptographic functions performed by the ePostal 10 system such as encryption, decryption, and reprint functions. There are also situations where specific ePostal 10 system needs require some other preferred alternative. An example is when direct communications begin between the Client and ePO 20 - an asymmetric public / private key pair is used. Also, as previously stated, it will be understood that whenever the ePostal communication system 10 has encoded data to be transmitted on the Internet, the encoded data is rewritten in hexadecimal characters or some other similar form such as UUEncode to allow transmission.

Sender Process 12 includes eLetter message body encryption in step SP 13 if the user selected this ePostal services. When the user selects encryption, there are alternatives to requiring or not requiring the user to enter their password for security purposes. Preferably, the ePostal 10 system prefix for this selection does not require the user to enter their password, but also allows the user to change this prefix using the ePostal options and preference screens, which can only be done using their password.

As explained above, for coding, Sender 12 performs encryption with a once strong enough use symmetric key and algorithm using the Sender 12 operating system cryptographic library as the feature. Such a library and algorithm are known to ePO 20. After coding the message in step SP13, Sender 12 puts the symmetric key in Part 3 of the eLetter custom header in step SP 14. It is noted that before coding the message body eLetter, Sender 12 also creates the message body MDC reprint in step SP12.

Sender 12 finishes constructing Part 3 of the custom header in step SP15 including all the exemplary data shown in Figure 19. Sender 12 preferably encodes the entire Part 3 with a once strong enough symmetric key and algorithm using the Sender 12 operating system cryptographic library as the feature in step SP16.

After coding Part 3, Sender 12 builds Part 2 of the custom header at step SP17 by putting the symmetric key used to encode Part 3 into Part 2 at step SPl 8. Sender 12 populates Part 2 as shown in Figure 19 and described above, with the MDC data in step SPl 8. Sender 12 then encodes the custom header Part 2 in step SP21.

There are two alternatives for encoding Part 2 of the custom header in step SP21, which differ depending on the type and source of the encryption key used.

In the first alternative, at the time of activation of Client-to-Sender 12 software, Client stores in Sender 12 an encryption key that can be used to encode Part 2. It can be either an asymmetric public / private key pair type where It encodes Part 2 with a Sender 12 public key that matches the ePO 20 private key to decrypt, or it can be a symmetric type, where ePO 20 also has the symmetric key. The preference of the ePostal 10 system between the asymmetric and symmetrical alternatives is to use a symmetric key because symmetric algorithms are faster and relatively stronger.

In the second alternative, Sender 12, if online, uses direct comms with ePO 20 to obtain from ePO 20 a symmetric use key once to be used by encoding Part 2 of the custom header just for this eLetter.

Preferably, the ePostal system 10 may use both alternatives. If Sender 12 is online, Sender 12 uses direct comms in step SP 19 for ePO 20 to obtain a symmetric use key once and leaves with ePO 20 certain Sender ID numbers linked to the use key once. specific and eLetter. If Sender 12 cannot go online, Sender 12 uses the symmetric key stored in step SP20 to encode Part 2 of the custom header. In either case, the Sender ID numbers 12 in Part 1 of the custom header identify for ePO 20 which encryption key to use to decrypt Part 2 when eLetter and its ePostal processing data in the custom header arrive. to ePO 20. The symmetric key stored on the Client and ePO 20 to encode and decrypt Part 2 may also be changed regularly for security purposes.

Sender 12 completes eLetter processing by placing the Sender 12 identification numbers in Part 1 of the custom header in step SP22. Sender 12 puts the custom header in eLetter at step SP23 and sends the newly processed eLetter to the sender 12 email application "outbox" or outbound email containment folder at step SP24. The email application waits for an email "transport" send / receive event in step SP26, at which time the email application communicates with the Sender 19 ISP mail server to perform the eLetter's current "shipping" shipping from the "outbox". An alternative to this process is that, if possible, Sender 12 puts eLetter in the email application "outbox" before Sender 12 processes it. Then, when the current "transport" send / receive event occurs, Sender 12 processes the eLetter and the eLetter is transported to Sender ISP 19.

The alternative of waiting for the current "transport" send / receive event to process eLetter is preferred because:

• eLetter then does not reside for a while, and cannot be observed, in the email application "outbox" in a processed state;

• Sender terminal 12 is online at the current "transport" event, and Sender 12 may be able to take advantage of eLetter processing that requires Sender terminal 12 to be online.

Although preferred to wait, some operating system, email application, and web browser combinations may not allow Customer to process eLetter in the "transport" event. Therefore, the first alternative to processing before the "transport" event is the selected option. When processing is required to occur prior to the "transport" event, the processed eLetter will remain in the email application "outbox" for now. During this time, Sender 12 is able to retrieve, at the user's request, the processed eLetter from the email application "outbox" and allow the user to make changes to eLetter recipients, subject, body, and services. ePostal services selected for eLetter, including cancellation of ePostal services for eLetter in step SP25.

After eLetter is sent to Sender ISP 19, Sender 12 identifies that eLetter was sent in step SP27, resets all original data to "To", "cc" and "bcc" email addresses in step SP28 , decrypts the eLetter message body if it was encoded in step SP29, and sorts the eLetter in the appropriate ePostal sent items folder in step SP30. It also makes any special choices that could be offered to the user by user options and preference menu items. Sender 12 also updates the local credit bank for the ePostal credits used for the newly submitted eLetter.

With respect to exemplary Sender software 22 (Figures 2A and 2B) and preferred Sender processing steps (Figures 18A and 18B), the following describes exemplary and preferred system structures and arrangements for eLetter selection, movement, and storage in special ePostal folders in step SP31. These ePostal folders are where a copy of a sent eLetter is placed in Sender 12 after it is sent, and where a received eLetter is placed after it is processed in Receiver 14. The basic special folders are therefore ePostal Sent Items folders and Inbox. Other special folders can be created either by Sender 12 using ePostal option and preference screens or by ePO 20 during Client installation, or by direct comms and ePO eLetters. After an eLetter is first placed in an ePostal folder, there are alternatives for moving the eLetter to other folders. An alternative is to allow eLetter to be moved out of your folder to any other folder (including non-eLetter folders) and back again. Alternatively, allow no eLetter movement outside its original folder. The preferred arrangement of the ePostal 10 system, to ensure security of ePostal folders and allow optimum flexibility for eLetter movement and sorting by the ePostal user, is:

• Allow eLetters to be moved to any other ePostal folder.

Allow eLetters to be moved outside ePostal folders to other email folders;

Allow eLetters that have been moved outside an ePostal folder to be moved back to any ePostal folder, if unchanged;

• Do not allow any non-ePostal email to be moved to any ePostal folder in step SP32.

These preferences ensure ePostal folders from any non-ePostal email that is a security risk to ePostal folders. Each eLetter is verified and authenticated as an eLetter before being moved back to an ePostal folder.

With respect to exemplary Sender 22 software (Figures 2A and 2B) and preferred Sender processing steps (Figures 18A and 18B), when selecting services on Sender 12 includes Sender Notification 12. Receipt and Opening (NORO) ) from your eLetter on Receiver 14 and the Receiver 14 user certification as the one that opened eLetter in step SP33, the following describes exemplary alternative system structures and arrangements for delivering these notifications. Alternatives include how many notifications for Sender 12 will occur for a single eLetter, such as notifications to both cases when eLetter is received and when eLetter is opened, or only one notification when eLetter is opened. Alternatives also include how notifications are made to Sender 12. They are either made by eLetter back to Sender 12 and / or Sender 12 by checking the Sender's Sent eLetter History using both the ePostal menu item in the e-mail application. email, or by going to the ePO 20 website, registering, and asking for the information. The preferred arrangement of the ePostal 10 system is to present the range of options to the user in the ePostal options and preferences section of the ePostal menu item in the email application, and allow the user to choose in step SP34.

With respect to exemplary Sender 22 software (Figures 2A and 2B) and preferred Sender processing steps (Figures 18A and 18B), the following describes exemplary alternative system structures and arrangements for providing Receiver 14 with ePostal credit incentives for open Sender eLetters 12. Some of the many alternatives include: not giving incentives to anyone at all, giving every Recipient 14 the same incentive to open an eLetter, varying incentives per individual and group when the ePostal 10 system administration decides , and allow Sender 12 to decide how much incentive Sender 12 will give Receiver 14 to open eLetter. Ideally, the ePostal 10 system provides the ability to operate all of these alternate and other modes, so that the ePostal 10 system and Sender 12 have the most flexibility in using the ePostal "incentives to open eLetter" feature. .

With respect to exemplary Sender software 22 (Figures 2A and 2B) and preferred Sender processing steps (Figures 18A and 18B), the following describes exemplary alternative system structures and methods for ePostal encryption services. Prior to encrypting an eLetter, Sender 12 may require the user to enter their password, or not. Also upon receipt of a coded eLetter, Receiver 14 may require the user to enter their password before the incoming eLetter is decrypted or not. Preferably, ePòstal system 10 installs Client software so that ePostal prefixing is not requiring the password in encryption, but requiring it in decryption. In addition, the user will be allowed to select the other alternatives mentioned in the ePostal user options and preferences menu in step SP34.

More specifically, the exemplary ePost Office 24, 24 'software functions ("ePO" is short for ePost Office) as set forth or with reference to Figures 3Α-C, 4B, 6 and 7 involve managing all operations. processing and administrative services at ePost 20 Office, including:

• Receive email from Senders 12;

• Create email for technical risk;

• Perform sender verification 12;

• Review Sender 12 account for approval to operate Sender email;

• Debit Sender account 12 for the required postage fee;

• Perform content screening;

• Officially receive and sort email from Sender 12;

• Identify if Recipient 14 has an ePostal Services account;

• Prepare sender 12 eLetter for delivery to Receiver 14;

• Process Sender 12 email for all requested services, such as tagging, prioritization, Sender endpoint authentication, individual Sender certification, encryption, notifications, individual Receiver certification, prepaid replies, hard copy delivery, etc. Tagging, prioritization and other security coding prevent fraudulent use of ePostal tags and indicators;

• Perform other special delivery instructions;

• Create an ePost 20 Office processing timestamp; • Send eLetter from Sender 12 to Receiver 14;

• Manage Sender 12 and Receiver 14 accounts for processed eLetters;

• Obtain / record Receiver 14 confirmation of eLetter receipt and opening and individual Recipient certification, if required;

• Credit Receiver 14 incentive account to open eLetters;

• Send notifications from Receiver 14 to Sender 12;

• Perform ongoing Shipper 12 and Shipper 14 account maintenance;

• Communicate with users of Senders 12 and recipients 14 and their ePostal software 22, 26, respectively, as required and appropriate;

• Update ePostal software 22, 26 on Sender 12 / Receiver 14;

• Assist new users in opening ePostal accounts and obtaining and installing Sender / Receiver software;

• Assist Senders 12 in delivering eLetters to non-account recipients and ePostal software;

• Help non-account recipients and ePostal software access eLetters in the ePO window or website;

• Make official analytical determinations of eLetter processing times / dates when requested;

• Perform analytical checks of secure eLetter content when requested.

These services and those described below with the Receiver software, and not provided in the manner of this invention (as an automatic or selectable service provided as a part of an integrated system and service that operates seamlessly with web browser and messaging applications and existing email) by conventional basic Internet and web messaging systems and methods, are referred to here as "premium services".

Also, as cited above and shown in Figure 10, this invention may offer Sender 12 users the option to have their eLetter, after being processed by the ePost Office 20 in any of the ways mentioned here, the hard copy, sealed at an envelope and physically delivered to Receiver 14.

The exemplary ePost Office software 24, 24 'described above and set forth in or with reference to Figures 3A-C, 4B, 6 and 7 may be implemented in alternative ways in the operation of ePost Office software 24, 24' . For ePO software 24, 24 ', an exemplary sequence of processing steps and system structures presently now preferred for operation is described below and shown in Figures 20A and 20B.

• The particular implementation is ePO 20 dependent on how you choose to send, process, and deliver an eLetter from Sender 12 to

Recipient 14 as described for sending, processing and delivering an eLetter.

Alternative exemplary system structures and operating steps for processing an eLetter at ePost Office 20 are discussed below with reference and shown in Figures 20A and 20B. They generally belong to a wide variety of alternatives for sending eLetter from Sender 12 to Receiver 14. In addition, they belong particularly to what is a typically preferred arrangement, which is to send eLetter's own message and most, if not all, ePostal processing data from Sender 12 through ePO 20 to Receiver 14.

It should be noted that all shipping and delivery alternatives (including going or not going through ePO) can be implemented using some or all:

• the various alternative arrangements described above for processing eLetter on Sender 12; • the various alternative arrangements described below for processing in ePO 20;

• the various alternative arrangements described below for Receiver 14 receipt and processing of eLetter;

• the various alternative arrangements described above for direct communications;

• and information communicated by ePO 20 to Sender 12 and Receiver 14 by direct comms, an ePostal eLetter, or other ePostal communications regarding which alternative to send an eLetter to Receiver 14 should be used by Sender 12.

In those alternatives where eLetter does not pass ePO 20, most if not all of the exemplary ePost Office software 24, 24 'operations described above and set forth in or with reference to Figures 3A-C, 4B, 6 and 7 still are executed. However in these alternatives, the ePost 20 Office, instead of managing and executing all of the ePO 20 processing when an eLetter goes through ePO 20, continues to handle all of the processing, but delegates some processing to Sender 12, Receiver 14 and / or for the ePostal network software 28 shown in Figure 8. ePO 20 manages delegated processing and shares ePO 20 processing results with Sender 12, Receiver 14 and ePostal network software 28 through the direct ePostal system comms that were discussed earlier.

EPost Office 20 processes an eLetter using exemplary ePost Office software 24, 24 '. The sequence of steps described below and referred to and / or shown in Figures 20A and 20B are exemplary and may vary depending on factors such as the method used to send and deliver a sender 12 to sender eLetter 14, the amount of processing done by ePO 20 on an eLetter, and the services selected by Sender 12. ePO 20 begins processing an incoming eLetter in step EPl first by identifying whether the incoming email is an eLetter. It is understood that if, at any stage in ePO 20 processing, the expected processing data is not present or wrong, the email is rejected from processing and handled as appropriate to the specific situation. EPO 20, operating with the normally preferred arrangements explained in the Sender software 22 described above, looks for ePostal processing data in eLetter, i.e. the usual SMTP header (Figure 19). The ePO then begins the preferred sequence of identification processing steps in step EP2, verification and authentication in step EP3, and then general processing in step EP4.

EPO 20 analyzes Part 1 of the custom header in step EP5. Reference is again made to Figure 19. In part 1, ePO 20 finds the Sender ID numbers 12 in step EP6 which indicate to ePO 20 the symmetric encryption key to use to decrypt Part 2 of the custom header in step EP7 . Creating and communicating the encryption keys used by Sender 12 in processing an eLetter were discussed with respect to Sender 22 software.

The above ePostal system 10 preferably uses ePO 20 to decrypt Part 2 with the symmetric key in step EP8 described above, store the message body MDC reprint in step EP9, and obtain the symmetric key used to decrypt Part 3 in step EP10.

The previous steps essentially identify the email as an eLetter as reflected in the portion of the operational diagram in Figure 20 denoted "Identification." First, there is the custom header with at least 2 parts that act as an ePostal eLetter custom header. Second, there is a Sender Id number that is recognized as a Sender 12 with an ePostal Account. Third, the symmetric key in ePO that matches the Sender Id number works to decipher Part 2.

The ePostal system 10 preferably uses ePO 20 to decrypt Part 3 with the Part 2 symmetric key in step EPl 1.

EPO identifies the ePostal services selected by Sender 12 in step EP 12. While the processing of some ePostal services is not specifically mentioned below, it is understood that those skilled in the art may modify ePO 20 to perform these services if and when required. .

EPO 20 decrypts the eLetter message body in step EP13 using the symmetric key stored in Part 3 of the custom header if encryption is an ePostal service selected by Sender 12.

This invention contemplates an alternative to decrypting an encoded eLetter message body during processing in ePO 20, that is, that the encoded eLetter is not decrypted. One possible perceived advantage of this alternative, that eLetter has greater security and privacy during ePO 20 processing if not deciphered, is a misperception. Decryption, plain text processing, and re-encryption are all done in a "black box" environment, where there is no possible access by anyone to the ePostal system during processing for eLetter while it is in plain text. . In addition, there are important disadvantages to not deciphering an encoded eLetter while it is being processed in ePO. These include that eLetter must be decrypted in order to be triated for technical risk and content, and that a better validation of message body MDC reprinting can be done if it is decrypted that it performs both message verification and Sender authentication. 12 by ePO 20. Therefore, it is preferred that the ePostal 10 system decrypts all incoming encoded eLetters so that they can be correctly screened for technical risk and content and so that a correct validation of the message body MDC reprint can be done.

EPO 20 protects eLetter for technical risk and content in step EP 14.

EPO 20 creates the message body MDC reprint in step EP 15 and compares this MDC reprint to the MDC reprint stored in Part 2 of the custom header in step EP16. If the result is the same, this verifies that the eLetter content in step EP17 is what was sent by Sender 12.

EPO 20 authenticates Sender 12 in step EP 18. There are many techniques for doing this. In one form, various data can be stored in ePO 20 that is only linked to Sender 12, and when that data is transmitted by Sender 12 to ePO 20 and is screened through encryption during transmission, that data authenticates Sender 12 in ePO 20. In a presently preferred form, the ePostal 10 system uses MDC not only for message verification, but also for Sender authentication 12. MDC authenticates Sender 12 because only Sender 12 can know Part Sender ID numbers 1 12 of the custom header (1) point ePO 20 to the symmetric key which, unlike Sender 12, only ePO 20 would have and (2) verify the message body's MDC reprint. In addition, there are at least two different sets of sender ID numbers 12 in Part 3 of the custom header which when decrypted or reissued match the corresponding sender ID numbers 12 stored in ePO 20. These two analyzes provide two other ways to authenticate Sender 12 in step EP19. As noted above, it is also contemplated that the ePostal 10 system improves security of ePostal processing data by periodically changing not only the symmetric keys that are used with Parts 2 and 3, but also the data sequences in Parts 2 and 3.

EPO 20 posts to eLetter any administrative messages to the Receiver in step EP20 including processing information and messages to recipients without the Receiver 26 software.

EPO 20 creates a new message body MDC reprint in step EP21 if changed because of the addition of any administrative messages.

EPO 20 re-encodes eLetter's message body in step EP22, if encryption was an ePostal service selected by Sender 12. In one form, message body re-encryption uses the same symmetric key as used to encode it. originally, the key that was stored in Part 3 of the sender eLetter's custom header 12. In another form, re-encryption uses a new symmetric key. Preferably, ePO 20 reuses the original symmetric key because encryption security is not diminished by doing so, and less time is spent generating a new key is not required.

The ePO identifies the ePostal services selected by Sender 12, calculates the ePostal credits required for eLetter in step EP23, and adjusts the Sender Account credit balance 12 therefore in step EP25. As discussed above with reference to Sender 22 software, ePO 20 preferably maintains official credit bank records for all ePostal Accounts. If sufficient credits are not available, ePO 20 initiates procedures in step EP26 to ask the user in Sender 12 to purchase more ePostal credits while eLetter is processed. Corporate policy dictates extending un purchased credits to Sender 12 in such a situation.

The present invention contemplates alternatives for ePostal service evaluation, and for how payment for services is made. The main evaluation alternatives include: a periodic subscription fee, an eLetter fee regardless of the services selected as used, and eLetter linked evaluation depending on the services selected as used. At present, evaluation bound in step EP24 is preferred for the ePostal services selected for each eLetter as used. This preference may, of course, vary by customer type and business environment. Alternatives to payment for services include: periodic user billing for services provided, payment for services as used, and advance by various means for a given amount of ePostal credits which are then used when services are used. The ePostal 10 system preferably uses advance payments for a given amount of ePostal credits that are used when services are used. Economical models for this approach that are widely accepted include buying a postage stamp book and completing credits on a mailroom postage meter.

EPO performs administrative checks at step EP27 using data stored in Part 3, such as from Client to Sender 12, and prepares communications as required at step EP28 to Ship from Client 12.

EPO 20 then begins processing the starting eLetter in step EP29 with the exemplary ePO sequence of preferred processing steps and methods as described below and as shown in Figures 20A and 20B. EPO 20 processes a starter eLetter so that the eLetter is prepared with sufficient ePostal data and instructions and in such a way that the eLetter will be delivered by the Receiver 19 ISP to the Receiver 14 and so that the Receiver 14 will know. how to receive and finish eLetter processing. Several alternative implementations exist for the various startup processing steps.

As with Sender 12 processing, and for similar reasons, the ePostal system 10 preferably uses custom headers in step EP30. Again, the number of specific headers is not significant. However, for eLetters sent from ePO 20 to Receiver 14, the preferred form of the ePostal 10 system is two headers, or two parts for a header. For the rest of this exemplary discussion, reference is made to two headers. The preference for two headers may change if the content or processing on Receiver 14 requires more. As with Sender 12, if a particular email application on Receiver 14 does not allow custom headers, requires the data to be somewhere else on eLetter, or does not allow ePostal processing data to be delivered in this way, then another Place or arrangement of delivery is used. EPO 20 is aware of Recipient 14's operating system and email application, and therefore knows such constraints.

EPO 20 prepares the usual headers to include not only data to process eLetter on Receiver 14, but also data to verify and authenticate eLetter. Verification, as with Sender 12, indicates that the eLetter message was not changed during transmission from ePO 20 to Receiver 14. Authentication indicates that the eLetter on Receiver 14 actually comes from ePO 20 and therefore originally before ePO 20, As in the case of Sender 12 processing, Receiver 14 can process the incoming eLetter in numerous alternate sequences. This means that the data in the usual headers can be arranged in many different ways. However, unlike Sender 12 processing, the incoming eLetter to Receiver 14 could have multiple recipient email addresses, while the incoming eLetter from Sender 12 to ePO 20 had only one, ePO 20. Therefore, for processing sequence in Receiver 14, Receiver 14 preferably identifies itself first within the eLetter. Second, verify and authenticate eLetter. Then perform the rest of the processing. This is because, if any of the identification, verification or authentication cannot be done, it is desirable that the Receiver 14 does not process the email. Such an email could not be an eLetter. Therefore, the usual header data that allows the Recipient to identify with eLetter is preferably available before any other data. Then the data for verification and authentication is preferably available from the usual headers before, or at least at the same time as data for processing.

Exemplary custom header structures are shown and described in Figure 21. There are two custom headers 1, 2. Note, alternatively, that these two headers can be treated as both in a two-part custom header, or they could be parsed into three or more custom headers. Preferably, the ePostal 10 system uses two custom headers. Also, the physical sequence of the two headers is not fundamental. However, they should be ordered in the logical sequence in which they are used.

Custom Header 1 is thus best structured to accommodate multiple eLetter recipients (including both Recipient 14 with an email address associated with an ePO 20 User Account and Recipient with an unassociated email address) with a User Account). Alternative arrangements accommodate multiple recipients such as using other types of data structures in a custom header and eLetter, and sending a separate eLetter from ePO 20 to each recipient.

A presently preferred ePostal system arrangement 10 is shown in Figure 21. It enables ePO 20 to receive and send an eLetter for each eLetter sent by Sender 12, which provides operational and safety advantages.

Custom Header 2 is constructed in step EP31 as shown in Figure 21, with ePostal processing data, including:

• The unique set of numbers originally generated by Sender 12 identifies eLetter and is used to process and track transactions relating to eLetter. • The MDC to verify the eLetter is not changed during transmission to Receiver. It is also one of several ways for the Recipient to authenticate that eLetter is from ePO 20 and therefore from Sender 12.

• Data about Sender 12, ePO 20, and Recipients, such as identification numbers and email addresses. The "To", "cc", and "bcc" information is removed from Part 2 of the custom header in Sender eLetter 12 and put into this Custom 2 header, along with its reprint value. The "From" and "Answer to" information is also put into Custom Header 2, along with their reprint value. Reprinting this data allows additional ways to verify eLetter security and authenticate ePO 20 and Sender 12.

• Data identifying the ePostal services selected by Sender 12.

• The decryption key to decrypt eLetter's message body if encryption were a selected service. Preferably, the ePostal system 10 ePO 20 reuses the symmetric key that was stored in Part 3 of the eLetter custom header sent by Sender 12.

Custom Header 2 is then encoded in step EP32 with an encryption key generated in ePO 20. Preferably, the ePostal system 10 uses a symmetric key.

Custom Header 1 is constructed in step EP33 with the ePostal processing data as shown in Figure 21. This Header is included in a series of number pairs, one pair for each recipient email address, regardless of whether the Email address is associated with an ePostal Account or not. The pair of numbers is included with a Receiver ID number and a decryption key in step EP34.

For a Recipient email address that is not associated with an ePostal Account, ePO 20 creates a record for that Recipient address and gives you a Recipient identification number to use for Custom Header 1. This record enables ePO 20 to track eLetter to this recipient email address and any future eLetters and other ePostal 10 system actions relating to this recipient.

The decryption key that is stored in Custom Header 1 is used by Receiver 14 to decrypt Custom Header 2. Preferably, this decryption key is the same symmetric key that ePO 20 generated (as discussed above) and is used to encode. Custom Header 2. This decryption key is the same for each Receiver, because the encoded Custom Header 2 is the same for each Receiver.

The Recipient identification number is one that Recipient 14 recognizes as belonging to Recipient 14 because the Recipient identification number is also stored in Recipient 14. A Recipient without an ePO Account will not recognize the identification number; In fact, such a Receiver will not know what to do with the Custom Header or eLetter because the Receiver does not have Receiver 26 software. This situation is discussed in more detail below with respect to Receiver 26 software.

EPO 20 then, for each pair of numbers, encodes the symmetric key in step EP35 in Custom Header 1. Preferably, for each pair in Custom Header 1, the symmetric key is mixed with different random noise to improve encryption security. Also, ePO 20 preferably uses a different symmetric encryption key to encode the symmetric key in each pair of Receiver numbers. The encryption key used for each Recipient identification number is the one that matches that Recipient identification number in ePO 20 records. (Note that when eLetter arrives at Recipient 14 and Recipient 14 finds a Recipient identification number. In Custom Header 1 that matches a Receiver ID number in Receiver 14's own registration list of such numbers, Receiver 14 uses the decryption key stored with that Receiver ID number to decrypt the symmetric key in Receiver Header 1. Custom 1).

EPO 20 then puts Custom Headers 1 and 2 on the eLetter EP36. Although not shown in Figure 21, it should be understood that any data in Custom Headers 1 and 2 will include the data size unless ePO 20 otherwise knows this information. Also, although not shown in Figure 21, with reference to previous descriptions of preferred alternatives and encryption techniques, the ePostal system 10 preferably uses random noise added to the data in Custom Header 2 (as mentioned earlier about Custom Header 1). before they are coded for enhanced security purposes. In addition, although not shown in Figure 21, the data structure in Custom Header 2 is varied to strengthen additional encryption security. As mentioned above in the description of direct communications, and because data will be encoded there in the usual headers, the usual headers are rewritten in hexadecimal code, or some similarly executed code, so that they can be transmitted.

At this time, if not already done, ePO 20 copies the original "To", "cc", and "bcc" information from Part 3 of the custom header in Sender eLetter 12 into the "To", "eLetter" headers. cc ", and" bcc "in step EP37. EPO, if not already done so, removes the eLetter custom header that was put on eLetter by Sender 12 in step EP38.

Then, in the presently preferred form of the invention, ePO sends the starting eLetter message in step EP39 with its Custom Headers 1 and 2 to send and deliver a Sender 12 to Receiver 14 with all data processing. ePostal required for Recipient 14 to receive, identify, verify, authenticate, and complete processing of eLetter.

Finally, ePO 20 completes all required database record keeping in step e40 for eLetter at this stage of its processing and delivery.

More specifically, exemplary Receiver 14 software functions 26 as set forth in or with reference to Figures 4A-1 and 4A-2 include:

• Identify all eLetters when they are received by Receiver 14;

• Sort and / or separate eLetters apart from all other e-mail either by prefixed or by other recipient 14 custom instructions, such as in special ePostal Inboxes;

• Apply to all incoming eLetters special ePostal markings and priority indicators to visually differentiate them from any other email;

• Perform special custom made non-ePostal email pick such as on known and unknown senders, if designated by Receiver 14;

• Perform other email administration and deletion such as deleting all "non-ePostal and unknown sender" email, if designated by Recipient 14;

• Help Recipient 14 see all selected ePostal services in Sender 12;

• Decipher eLetters when required;

• Maintain repository of encoded content proof eLetters, if designated by Receiver 14;

• Identify certified Senders 12 users;

• Identify eLetters that have been opened; • Manage Receiver 14 credits to open eLetters;

• Send ePost 20 Office notifications of receipt and opening of eLetters;

• Perform and submit Recipient user's ePost 20 Office certification;

• Assist Receiver 14 in responding to Sender 12 prepaid response eLetters;

• Assisting Receiver 14 in communicating and performing various administrative tasks in conjunction with ePost Office 20 which maintains Receiver checking account;

• Work seamlessly with Receiver 14 email and browser applications.

Recipients 14 who do not have ePostal accounts and exemplary software 26 as set forth in or with reference to Figures 4A-1 and 4A-2 can also receive email and access eLetters processed by the ePost Office 20, as shown in Figures 3 and 4. 4B. Sender 12 email received by an Accountless Receiver and ePostal software has limited ePostal system benefits beyond screening for technical risk and content. For example, such an accountless recipient cannot verify that the email was actually processed by the ePost Office, or is from the Sender 12. Therefore, the email lacks the related security benefits of the ePostal 10 system, just as regular email. However, this email may offer such non-account recipients an option to verify that the email was from Sender 12 and processed by the ePost Office 20. The email may provide the non-account recipient with a code that enables that recipient. see the Sender 12 eLetter in the ePost Office window, or Web site 20. These eLetters have many of the features and benefits of the ePostal system such as technical shielding and content, value and priority indicators, Sender 12 terminal authentication. , Sender 12 user certification, encryption, and prepaid responses to Sender 12, but also the significant limitations associated with not being received and residing in the recipient's own email application.

The present invention includes various alternative software arrangements of operation with respect to exemplary Receiver software 26 (described above and set forth in or with reference to Figures 4A-1 and 4A-2) and the preferred Receiver processing sequence sequence (described herein). below and shown in Figures 22A and 22B).

These Receiver 14 alternatives depend on the arrangements chosen to send, process and deliver an eLetter from Sender 12 to Receiver 14 as described above with respect to the alternatives for sending, processing and delivering an eLetter. Alternative arrangements for processing an eLetter at Receiver 14 which are discussed below and shown in Figures 22A and 22B generally pertain to all possible alternatives for sending the eLetter from Sender 12 to Receiver 14. In addition, there is described the normally preferred arrangement. when the eLetter message itself, and most if not all of the Sender 12 ePostal processing data, is sent by ePO 20 to Receiver 14.

Receiver 14 receives and processes an eLetter using Receiver 26 software. Receiver 14 RP1 step sequence (described below and shown in Figures 22A and 22B) is exemplary. It could vary, for example, by the way it used to send and deliver an eLetter from Sender 12 to Receiver 14, the amount of processing done by ePO 20 on an eLetter, the services selected by Sender 12, and the nature of the operating system and application. email at Receiver 14.

In a presently preferred form of the ePostal system 10, the three main processing steps at Receiver 14 are RP2 identification, verification and authentication RP3, and then other general processing RP4. It is understood that if, at any processing stage, the expected processing data is not present or wrong, the email is discarded from further processing and is handled as appropriate for the specific situation step RP10.

The identification step RP2 on Receiver 14 begins with the arrival of an email in the email application on Receiver 14 through some TCP protocol such as POP3. However, if Receiver 14 does not use such an email application, but instead uses another software application such as a web browser for email, the ePostal 26 Receiver software works with this, albeit with a slightly different process than described below (as mentioned with respect to ePostal software installation and preferred activation arrangement). Specifically how, where and when Receiver 14 learns that a new email has arrived is dependent on the nature of Receiver 14's operating system and email application. An exemplary time could be before or after the email is placed in the mail folders of the email application. If in an exemplary manner Recipient 14 learns of the new email after it is placed in an email application mail folder, Recipient 14 protects the email application mail folders for any newly emailed email. arrived.

In a preferred form, when Recipient 14 finds a new email, Recipient 14 first checks in step RP5 whether the incoming email is an eLetter by determining if the "From" address of the email is an address known to him as an authorized "From" address for the ePost Office 20. Second, Recipient 14, as a result of the preferred methods explained in the section on Starter eLetters being processed by ePost Office software 24, 24 ', looks for data from ePostal processing on eLetter, that is if there is an SMTP Custom Header 1 in step RP6. If there is such a header, the email is considered an eLetter for further processing.

Referring to Figure 21, the RP3 verification and authentication step begins with Receiver 14 parsing the eLetter headers and Custom Headers.

Recipient 14 checks for a match of the "Delivered To" address in the email between the "Original To" data fields and the.

"To / cc / bcc" of the email in step RP7. If there is no marriage, there is a possibility of a homonymous address in step RP8. Preferably, the ePostal 10 system, in the case of a possible homonymous address Receiver 14 by direct comms, gives the ePO 20 data indicating a homonym. EPO 20 responds via direct comms back to the Recipient with additional instructions such as the correct Recipient ID numbers and decryption key to continue processing the eLetter.

Recipient 14 then finds the Recipient identification number in step RP1 1 in the Recipient 14 data records with which he is married to the "Delivered to" address in the email. Receiver 14 compares this Receiver ID number to each of the Receiver ID numbers in Custom Header 1 to find the coded symmetric key associated in step RP12. As discussed above, Receiver 14 finds in Receiver 14 data record in step RP13 the symmetric decryption key in step RP14 associated with the Married Receiver identification number in Custom Header 1. Using this symmetric decryption key, the Receiver 14 decrypts the symmetric key encoded in step RPl 5, which is stored in Custom Header 1 and is married to the Marriage Recipient identification number. Receiver 14 also removes random symmetric key noise that has been added for enhanced security as a preferred step of the ePostal 10 system before it is encoded in ePO 20.

Comparing the preceding descriptions regarding encryption, Receiver 14 using the deciphered Custom Header 1 symmetric key decrypts in step RP16 Custom Header 2, making all Custom Header 2 data available for use, such as the list of services. ePostal that Sender 12 has selected.

Recipient 14 identifies the ePostal services in step RP17 selected by Sender 12. Although the processing of some ePostal services is not specifically mentioned below, ePO 20 performs these services if and when needed in Recipient 14 processing using techniques known to those qualified. in technique.

If ePostal encryption services had been selected by Sender 12, the Receiver decrypts the eLetter message body in step RP18 using the symmetric key that is stored in Custom Header 2.

Recipient 14 creates an eLetter message body MDC reprint in step RP19 and compares this to the MDC reprint in message body step RP20 that is stored in Custom Header 2. A marriage of the two MDC reissues verifies that the The message in step RP21 was not changed during transmission from ePO 20 to Receiver 14.

At this time, Receiver 14 can also authenticate ePO 20 as the eLetter sender that arrived at Receiver 14. As with sender 12 eLetter authentication on ePO 20, there are many alternatives to perform this function. Multiple data can be stored on Receiver 14 that is linked to ePO 20 only, and when that data is transmitted by ePO 20 to Receiver 14 and is screened through encryption during transmission, that data authenticates ePO 20 on Receiver 14. The arrangement at present Preferred includes not only using MDC for message verification, but also for ePO authentication 20 in step RP21. The MDC reprint matching that Receiver 14 creates from the message body for the decrypted MDC reprint stored in Custom Header 2 authenticates ePO 20, as well as verifying the message. This is because only ePO 20 can know the Receiver ID number in Custom Header 1 that points Receiver 14 to the symmetric key that only Receiver 14 would have (other than ePO 20). In addition, in a preferred form of the ePostal system 10, there may be any other number of ePO identification numbers in Custom Header 2 which when decrypted or reissued match the corresponding ePO identification numbers 20 stored in Receiver 14. A ePostal 10 system preference is to use two identification numbers. These two analyzes provide two additional ways to authenticate Sender Step 12 in step RP22. It is also preferable to improve security of ePostal processing data by periodically changing not only the symmetric keys that are used with Custom Headers 1 and 2, but also the sequences. data in the custom headers.

With additional reference to Figure 22, the general processing step now begins at Receiver 14.

Recipient 14 prepares eLetter for display to the ePostal Account user by updating the "From" and "Reply to" information on eLetter in step RP23 with the original "From" data that was stored in Custom Header 2.

Recipient 14 prepares eLetter for display by processing the Administrative content in step RP24 that was added to the message body in ePO 20. Preferably, an ePostal Administrative message is placed at the beginning of all eLetter message bodies that are delivered to recipients. in RP38 step that does not have Recipient 26 software. Because without Recipient 14 software the Recipient email application places eLetter in its regular email inbox folder in step RP39 and does not differentiate eLetter From another e-mail, the reasons for the ePostal Admin message are significant and include: • Explaining to the software-less Receiver 26 that eLetter was sent to him by ePO 20 on behalf of the Sender 12 user in step RP40;

• Provide the recipient with information about an ePostal eLetter in step RP41;

• Give the software-less Receiver 26 information on how to obtain the unique codes to read the eLetter if it is encoded in step RP42;

• Provide Recipient 14 with important information to ensure that ePostal services are legally compliant in step RP43.

Exemplary alternatives to Recipient processing include: sending separate eLetters to Recipients 14 without this Administrative content and to Recipients (without Recipient 26 software) with Administrative content; send the same Administrative content to all Recipients whether or not they have Receiver 26 software, and allow both types of Recipients to view the Administrative content; and preferably adding Administrative content to all eLetters while they are being processed in ePO 20, and then having Receiver 14 (with software 26) remove the content before the Receiver 14 user sees the eLetter displayed. Receiver without software 26 has no way of removing Administrative content; This Recipient user will see the Administrative message when eLetter is displayed.

To display to the Recipient 14 user, Recipient 14 adds other Administrative content to the eLetter message body in step RP25, as defined by the data in Custom Header 2. This content would include information for the Recipient 14 user such as:

• the time and date to process eLetter in ePO;

• ePostal services that have been applied to eLetter as requested by Sender 12 (including the ePostal priority class indicator, eLetter opening and receipt notification, any usual incentive given to the Receiver 14 user to open eLetter, encryption , Sender 12 user certification, and prepaid responses);

• How Receiver 14 may use the prepaid answering service or other ePostal features applied to eLetter in step RP37.

In one form, to provide this information, the ePostal system 10 enables Receiver 14 using option and preference screens to choose how to receive this information. It can be provided in a number of ways as explained above, including as content on eLetter itself or shown on a special pop-up ePostal screen as requested by the Receiver user 14.

Continuing to prepare the eLetter for display, Receiver 14, using the information in Custom Header 2, sets the mail message class for this eLetter in step RP26 so that the ePostal priority class indicator that was selected by Sender 12 is displayed. The steps in doing this will depend on the email application in Receiver 14.

At this point, sufficient processing has been completed for Recipient 14 to display eLetter in its ePostal folder.

Receiver 14 chooses eLetter in its ePostal folder in step RP27. As mentioned similarly earlier in the Sender Processing section 12, concerning exemplary Receiver software 26, described above and shown in Figures 4A-1 and 4A-2, there are alternative arrangements for sorting, moving and storing eLetters between ePostal folders. . These incoming ePostal folders receive a copy of an eLetter received at Receiver 14 after it has been processed by Receiver 14. The basic incoming ePostal folder is the ePostal Inbox folder. Other special ePostal folders can be created either by Recipient 14 using ePostal option and preference screens or by ePO 20 during Client installation, or by direct comms and ePO eLetters. In addition and as mentioned elsewhere, Receiver 14, in addition to sorting all eLetters in ePostal folders, can also sort in Receiver 14's user option any other email whose sender's email address has not been a match in the Recipient 14 user's email address book, in a single separate folder, making all such email easy to discard.

As discussed earlier regarding Sender 12 processing, after an eLetter is first placed in an ePostal folder, there are alternatives regarding moving the eLetter to other folders in step RP30. An alternative is to allow eLetter to be moved out of your folder to any other folder (including non-eLetter folders) and back again. Alternatively, allow no eLetter movement outside its original folder. Preferably, to ensure security of ePostal folders and allow optimum flexibility for eLetter movement and sorting by the ePostal user, the eLetter movement:

• Allows eLetters to be moved to any other ePostal folder;

• Allows eLetters to be moved outside of ePostal folders to other email folders;

• Allows to be moved eLetters that have been moved outside an ePostal folder to be returned to any ePostal folder, if unchanged;

• Does not allow any non-ePostal emails to be moved to any ePostal folder in step RP31;

• These preferred methods ensure ePostal folders from any non-ePostal email that is a security risk to eLetters and ePostal folders. Each eLetter would be verified and authenticated as an eLetter before being moved back to an ePostal folder; • When the eLetter has been placed in your ePostal folder, it communicates to the Recipient 14 user that a new eLetter has arrived at step RP28, for example, using a pop up or ringing message, or no communication. While ePostal prefixing is a pop up message, preferably the ePostal 10 system allows the Receiver 14 user to choose the alternative using the ePostal option and preference screens.

If Sender 12 selected the ePostal encryption service, Receiver 14 places the eLetter in its ePostal folder so that the message body cannot be read. Only the information for "To / cc / bcc", "From" and "Subject" is visible. When Recipient 14's user selects eLetter in step RP32, before Recipient 14 displays the eLetter in readable plain text, Recipient 14 asks Recipient 14's user to enter their password for identification and security purposes. When the user enters their password, Receiver 14 displays the eLetter, which had been encoded in plain text readable in step RP33. Receiver 14 as well as Sender 12 may ask ePO 20 to hold in its eLetter repository on ePO 20 this eLetter in step RP34 as well as any other eLetter. Preferably, while presetting is requiring a user to enter their password before seeing an incoming encrypted eLetter in a readable state, the ePostal 10 system allows the user to choose to use the ePostal option and preference screens, whether or not to enter password. is required. In addition to displaying a deciphered eLetter in your ePostal folder, preferably the ePostal 10 system allows Receiver 14 (and Sender 12) to use ePostal option and preference screens to save an encoded version of eLetter to designated ePostal folders. for such encoded eLetters. These stored encoded eLetters can be opened later by Recipient 14 when the Recipient 14 user enters their password. Upon completion of eLetter's identification, verification and authentication, and overall processing, Recipient 14, whether online or as soon as it may be online, preferably uses direct ePostal comms, as described above, to leave ePO 20. know that eLetter reached Receiver 14 in step RP29. These direct comms confirm to ePO 20 that eLetter was delivered and successfully processed by Receiver 14. ePO 20 records this information.

When the Recipient 14 user opens this eLetter, Recipient 14, whether online or as soon as it may be online, preferably uses direct ePostal comms as discussed earlier to confirm to ePO 20 that eLetter was opened in step RP36. If the Sender 12 user had requested Recipient 14 user certification as opening eLetter, Recipient 14 performs certification when eLetter is opened and reports this to ePO 20 via direct comms also in step RP36. EPO 20 records this information.

Regarding eLetter receipt and opening communications, Receiver 14 uses direct comms to notify ePO 20 of receipt and opening regardless of whether Sender 12 has selected to receive the same notifications. If Sender 12 has selected the receipt and open services notification (NORO), there are alternatives to how these notifications are provided to Sender 12. These alternatives include notifications that are given to Sender 12 by ePO 20 or Receiver 14. Preferably, NORO communications are made to Sender 12 through ePO 20 which is the much simpler and safer alternative. In other forms, Sender 12 receives both a receipt and open notification when they occur individually, or only a notification from both after eLetter is opened. In a preferred form, the ePostal system 20 allows Sender 12 to make this choice at the time it selects this ePostal service. Also, when the Receiver 14 user opens eLetter, Receiver 14, preferably at the time of opening, estimates the ePostal (ITO) incentive credit that will be added to the Receiver 14 user Account at ePO 20 (after Receiver 14 using direct comms notifies eLetter opening ePO 20) and adds this estimated credit to the local recipient bank of ePostal credits in step RP35. Receiver 14 also adds to the local credit bank any Sender 12 ITOs that Sender 12 has selected for this eLetter.

This concludes the description of the exemplary sequence of steps of Receiver 14 on receipt and processing of an eLetter, and the description of alternatives and certain preferred arrangements for such processing steps.

Another feature of this invention as shown in Figure 5, as traditional postal services, is that the Sender 12 user can "go" to the ePost Office 20 to send / send eLetters from, and the Receiver 14 user can "go" to the ePost Office. ePost 20 to pick up eLetters from an ePO "box". An example of where this would be valuable is when Sender 12 and Receiver 14 users are away from their terminals that have ePostal software 22, 26. Using any terminal with a web browser, as shown in Figures 6 and 7, they they can go to the ePO website, register, and access your account information and tools to send eLetters and to read, mail, or otherwise operate the eLetters that are contained in ePO to them, just as if they were using their eLetters. terminals themselves with their email, browser and ePostal software.

A variant of the feature described in the previous paragraph and also shown in Figure 5 is where users can "go" to the ePost Office 20 to send / send eLetters and pick up eLetters from an ePO "box", although they do not have ePostal software. installed on any terminal, but as long as they have ePostal accounts open on the ePO website. In this situation equally, as described above, the user, using any terminal with a web browser, as shown in Figures 6 and 7, can go to the ePO website, register, and access their account information and tools for submitting. eLetters and to read, mail, or otherwise operate the eLetters that are contained in ePO for them.

As mentioned earlier and shown in Figure 9, Senders 12 and Receivers 14 may have connection to email services and Internet access other than through an ISP, such as from within a corporate intranet or some other organizational network. Figure 8 shows the corporate intranet example of this non-ISP connection, where ePostal software can operate not only to individual Senders 12 terminals, but also to corporate servers. While corporations are a typical environment for such networks and servers, as is well known, networks of varying size and capabilities operating with varying protocols are used by many entities. For convenience, they are included here by the terms "corporate", "corporate network", "corporate intranet", and "corporate server".

Senders 12 of Figure 8, as shown in Figures 2A and 2B, can send your email with or without using ePostal services. However, with a Network of Senders using ePostal services, the entire organization's ePostal operations are handled much better if the Network ePostal 28 software works with both the Shipper 12 ePostal software and the E-Servers. Corporate mail 13, instead of if ePostal software is only on individual Senders 12 computers. Such a system configuration would include: management of available ePostal features, management of the company's total ePostal credits, communications with the ePost Office 20, and various related data collection and retention activities.

Corporate Sender 12 users are not only individuals, but also groups of business information systems such as accounting and billing. For example, Network ePostal software 28 would help those Information Systems 17 and Corporate Email Servers 13 prepare, send, and provide ePostal services (including ePost Office "postage metering") to business documents submitted. in the form of eLetters such as customer accounts and ads.

Of course, a business and its employees may also be Recipient 14 users, as well as Senders 12, residing within the same corporate network. As with Send operations, when Network ePostal 28 software works with both Receiver ePostal software on recipients 14 and Corporate Email Servers 13, both corporate network and ePostal operations can be more effective and efficient. efficient. An example of a resulting benefit is the exclusion of much lower value, low priority emails from ever entering the corporate network.

Therefore, companies that include elements of this invention not only in their employee jobs, but also in their corporate servers will enjoy in a highly manageable way not only the differentiated, secure, coded and tracked benefits as ePostal Sender users, but also the Benefits as ePostal Recipient users of regaining significant rational control across their networks by having a way to filter, categorize, distribute and eliminate (where appropriate) incoming emails to reduce unnecessary corporate IT processing, technical risk and Internet usage. bandwidth while improving your employees' email productivity.

As discussed above with reference to Figures 1 and 9, this invention may work with Senders and Receivers within an ISP network or within some other network such as a corporate intranet. Network ePostal software 28 referred to in Figure 8 and discussed above can help at the network server level not only with enterprise intranets, but also with other organizational networks and ISP5 where exact features and programming of Network ePostal software for a network. Specific information would vary depending on technical network configurations and organizational needs.

Another significant aspect of the present invention is that sender pay to use ePostal services, just as with conventional postal services, and can get different levels of services for different rates. This in itself has the advantage of prioritizing email, not only in contrast to all conventional email, but also between eLetters of the ePostal system itself. Also, the payment aspect limits the use of the system, which provides an automated market solution to the problem of the growing volume of "free" email traffic; As discussed earlier, this traffic noise has two components: 1) the legitimate and dear email overload, and 2) the unwanted annoyance email. In addition, senders are interested in solving problems that pertain not only to email volumes, but also to email quality. Senders look for the greatest security options that are inherent and optional with the ePostal system; They can also enjoy the benefits of differentiated, secure / encrypted and tracked emails, more productive email management, ease of use, general accessibility, and support on corporate intranets and other networks.

Certain senders will pay to process your most important email through the ePostal system because of "value" - value not only for senders but also for Recipient users 14.

Recipients are much more likely to open eLetters than other regular email. First, only the ePostal system offers its unique set of premium email services. Second, recipients will expect to receive more value and less risk in opening ePetters from the ePostal system than in opening regular email. In general, the ePostal system successfully addresses the recipient of Internet mail issues and general security opportunities, legitimate overhead, priority management, encryption, tracking, ease of use, and annoying email. Some of the many reasons include the following:

• Recipient 14 knows that the sender considers eLetter important enough to pay to send to Recipient, unlike any other Recipient's usual free email. That is, the sender is willing to give up something of value in order to have the Receiver open his eLetter, where as senders of another regular "free" email are not;

• Recipient knows that eLetters are screened for technological risk (viruses and worms) and content risk (offensive material) during processing at the ePost Office. Therefore, the Recipient does not have the anxiety and pain in opening eLetters that he does with regular email;

• Also from a general security standpoint, recipients know that each eLetter has a terminal authentication and sender email address. More specifically, the recipient will know that their own terminal has verified that eLetter came from the ePost Office, which previously verified that the original email was from the sender's terminal and can even certify the individual sender. The ePost Office also gives each eLetter a verifiable processing date and time stamp. Recipients could also ask the sender to have the ePostal system deliver a physical copy of eLetter to the recipient.

• Recipients also find it easier and faster to scan, review, read and administer eLetters due to features such as:

- In the general inbox of an email application, eLetters will be seen more clearly and quickly because they are tagged with ePostal tag and priority tags;

- eLetters can be collected on the receipt and placed in a special ePostal folder (or multiple ePostal folders organized by ePostal priority, sender address, industry, etc.) in the recipient's email application. A specified ePostal folder can even open prefixed;

- When new eLetters arrive, special news is given to the recipient, avoiding delays due to not knowing that these important eLetters are available;

- If the recipient is away from their own terminal for an extended time, they can rent an ePostal mailbox from the ePost Office website where their incoming eLetters can be contained during that time. Using another terminal with a web browser, the recipient can access their ePostal website account and tools to read (and send) their eLetters;

• About coded eLetters, recipients know it's quick and easy without special computer knowledge to receive, decrypt and read coded eLetters processed by the ePostal system. The system will also help Receiver archive coded eLetters for content verification purposes. This is of significant value where encrypted email is required in highly widespread, regulated situations such as the healthcare industry due to HIPAA, and where ease of use is important;

• When dealing with unwanted annoyance email, the ePostal system does not interfere with recipients receiving all of your regular email and will not delete any of the Receiver's non-ePostal email unless recipients choose otherwise. . It will not interfere with other measures of your email security. However, the ePostal system may, if recipients choose, remove and place all non-ePostal and non-Address Book (unknown senders) email in a separate folder. This "junk", unknown, unwanted, annoying "third category" folder could then be easily deleted in bulk;

• As mentioned earlier, recipients with an ePostal account, in addition to having the full range of ePostal features available to receive and administer eLetters, can be credited with an economical incentive to open eLetters. This credit may be used by recipients to send their own eLetters through the ePostal system, or after a certain credit balance is reached, it may be given to recipients periodically;

• All these features work easily and seamlessly from within the recipient's own email application;

• When the ePostal system works in conjunction with business or other organizational network email and Internet access servers, IT departments can regain significant control across their networks by having the network-level medium to filter, categorize, distribute. and eliminate incoming emails where appropriate. This reduces otherwise unnecessary IT processing, technical risk to your network and systems, and bandwidth requirements, all of which save money and maintenance time. It also improves the email productivity of business employees.

Therefore, since recipients assign higher value to eLetters than other e-mail and recipients are much more likely to open eLetters than other e-mail, the value for senders using ePostal will greatly exceed their costs. However, in addition to recipients greatly appreciating eLetters, senders have even more reason to process their most important email through the ePostal system;

• Differentiated eletters. The ePostal system marks eLetter with distinctive service and priority indicators. Senders know, when a recipient scans their email record, the Receiver will not only see that the eLetter has been processed by the ePostal system (and therefore known to the recipient to be safe, credible, and important enough for the sender to pay for its delivery). , but also these priority and service indicators set it apart from all other usual "free" email the recipient has in their Inbox, and from other lower priority (and lower cost) eLetters that came through the ePostal system. . The sender knows that the recipient understands that eLetter has minimal risk of viruses and offensive material, and the eLetter 'sender is verified. The sender also realizes that the recipient can sort eLetters to make them more easily visible and accessible. Therefore, the sender knows that the Recipient is much more likely to open and read ePostal eLetters than regular email. Essentially, the effect of all these features (priority, choice and security indicators) is to put the sender's eLetter "on top" of the regular email recipient's stack. An appropriate analogy is to choose overnight delivery over conventional mail, but not because of faster delivery - but because recipients are better able to look at opening premium delivered "mail containers" before they open regular mail.

• Easy encryption. eLetters can be safely encoded by senders in an extremely fast, easy, and generally available way. Senders do not need to obtain and distribute special digital keys to anyone who might need to send an important encrypted email. This presents a new option, very valuable for senders requiring secure encrypted communications as mentioned above about HIPAA and the healthcare industry. Senders as well as recipients can archive encoded eLetters for content verification purposes;

• eLetter tracking. The sender may request eLetter receipt / opening notification by the recipient. It serves as a valuable Sender record that can be linked to the sender's original eLetter. The sender may even ask for the recipient user's certification as the one who opened it. This is enormously important in facilitating arrangements between businesses and their clients and clients regarding the exchange of information over the Internet. With such records, businesses can finally link their electronic systems to secure electronic delivery and tracking systems, creating huge cost savings, especially with ePostal's generally available security measures;

· Special treatment of recipients. Recipients not only realize value but can also receive incentives to receive / open eLetters, which gives senders even greater assurance that recipients will open their eLetters. Senders can also prepay recipient responses to their eLetters back through the ePostal system, which should attract 15 recipients and increase such responses (and value) to senders;

• Ease and flexibility of use. EPostal services are easy to use for senders. Service selections are all made from within and work seamlessly with the sender's email application. Sent eLetters from the sender can be automatically administered into special folders by priority, recipient, etc., separating them from your regular sent email. And when the sender is not at his own terminal, he can access his ePostal account and tools for sending (and receiving) eLetters on the ePO website;

• While all senders will appreciate features of ePostal, businesses and other organizations will especially value not only the differentiated, secure, encrypted, and tracked email capabilities, but also the effectiveness of the services' increased global communication management as enterprise-level software. ePostal network is working directly with your network level email and internet access servers and other business information systems.

The subsequent result is that this invention offers very significant benefits to email users, senders and recipients, and individuals and businesses. For example, companies will be able, by including the features of this invention on their employee jobs and corporate servers, to derive - as senders - the benefits of differentiated, secure and tracked emails. In addition, as recipients, they will benefit from regaining control across their networks by being able to filter, categorize, distribute and eliminate (where appropriate) incoming email. The result will be reductions in unnecessary processing, technical risk, and bandwidth usage, accompanied by improved email productivity for all employees. In addition to business, networking for other organizations and ISPs would also benefit by including features of this invention on their network servers.

While the invention has been described with respect to its preferred embodiments, it will be understood that various modifications and changes will occur to those skilled in the art of the preceding detailed description and accompanying drawings. For example, while the invention has been described with certain software running or certain hardware in certain locations, it will be understood that the functions described may be distributed in hardware, firmware and software in a manner well known in the art. Additionally, while payment and accounting functions are described as performed by the ePostal server and software, these functions may, in whole or in part, be performed by connections to the ePost 20 e / conventional Office's online banking and credit services. or other system components 10. These modifications and changes are intended to fall within the scope of the appended claims.

Claims (42)

1. A communication system which transmits electronic mail having a message content component and a message data component relating to message content and / or transmission between multiple sender and receiver terminals and both use and extend the Internet; characterized in that it comprises: a postal server and software, calls connecting the sender and receiver terminals and said postal server and software to the Internet, and sender software operable at least at the sender terminal that selectively connects the sender terminal to the postal server over the Internet and said sender connection, said postal server software providing premium mail services, said terminal and sender software providing a selection of said premium services to be performed with respect to the transmitted electronic mail, and said terminal and sender software and said server and postal software communicating with each other, at least in using direct communications. Communication system according to claim 1, characterized in that it further comprises receiving software operable at least on said receiving terminal which processes said incoming mail from said server and postal software over the Internet and said receiving call said terminal. and receiver software communicating with at least one of said terminal and sender software and said terminal and postal software to create a virtual intranet for use by the sender and receiver and for the communication system itself. Communication system according to claim 2, characterized in that at least one of said sender and receiver software is application software stored in said sender and receiver terminals. Communication system according to claim 3, characterized in that the Internet has e-mail application software and operates at the multiple sender and receiver terminals, said sender and receiver software is operable within said e-mail application software. email. Communication system according to claim 2, characterized in that at least one of said sender and receiver software is stored and accessible to the sender and / or receiver on said postal server. Communication system according to claim 2, characterized in that said connections include a network interconnecting said multiple terminals to the Internet, at least one of said sender, receiver and postal software is stored and / or accessible to the sender and / or receiver in said network. Communication system according to claim 1, characterized in that it further comprises payment software operable by at least said terminal and sender software and said server and postal software to authorize and respond for payment for use of said server and software. postal. Communication system according to claim 7, characterized in that said payment software accounts for incentive credits to a receiving terminal in response to the selected e-mail opening at said receiving terminal. Communication system according to claim 7, characterized in that said payment software collects an additional fee in response to the selection of sender software from said server optional services and postal software. Communication system according to claim 1, characterized in that said connection links between the Internet and any of said sender terminal, receiver terminal, and postal server include a telecommunications connection. Communication system according to claim 1, characterized in that said connection links between the Internet and any of said sender terminal, receiver terminal, and postal server include at least one of an ISP, intranet, extranet. , LAN, dial-up, DSL, cable, satellite, cellular, wireless, physical delivery and combinations thereof. Communication system according to claim 1, characterized in that said premium service includes at least one of: authentication of said sender; certification of the identity of the entity operating said sender terminal; certification of the identity of the entity operating said recipient terminal; prioritization of mail sent and received; mail sorting for technical hazards; mail screening for content risks; mail encryption; notification to sender of mail receipt; notification to sender of mail opening; prepaid replies to recipient reply to sender by postal server; delivery of physical copy of mail; personalized incentives for recipients to open mail; verifiable timestamp of postal server processing; content integrity checking, secure storage of premium regular mail; accessible stories of premium mail sent / received; creating a mail containment on said postal server; and payment and accounting for courier services; and combinations of it. Communication system according to claim 12, characterized in that said prioritization is a differentiation between mail processed by said server and postal software and other electronic mail carried on the Internet. Communication system according to claim 12, characterized in that said prioritization includes a differentiation between mail processed by said server and postal software. Communication system according to claim 1, characterized in that said sender and receiver terminals and the Internet may have different combinations of operating systems and Internet software, and wherein the sender and receiver software is adapted to connect by said different combinations by the postal server. Communication system according to any one of claims 1 to 15, characterized in that said postal server includes several servers in at least one location. Communication system according to claim -16, characterized in that said sender, receiver, and postal server software operate to open a communication connection for a transmission session, establish security on said connections, authenticate the sender transmitting said message content and / or message data, and closing the transmission session. Communication system according to claim 17, characterized in that said direct communications use HTTP, SMTP or other receptacle protocols. Communication system according to claim -18, characterized in that said links include ISP content messages are transmitted between said sender and receiver ISPs bypassing said server and postal software, and said data message is communicated, at least in part, using direct communications between said sender and said postal software server and between said receiver and said postal server and software. Communication system according to claim -19, characterized in that said message content communication uses SMTP / POP and / or IMAP protocols by Internet mail servers, and said message data communication at least partly uses HTTP, SMTP, or other receptacle protocols. Communication system according to claim 16, characterized in that said data is formatted as a custom header including a part identifying the sender and / or receiver. Communication system according to claim 21, characterized in that said custom header additionally includes a part authenticating and verifying said message components and a part directing the processing of said message components. Communication system according to claim 16, characterized in that said direct communication between sender and receiver terminals and software and said server and postal service software is normal HTTPS session protocol using cookies, certificates / third party keys, and a single transmission protocol. Communication system according to claim 16, characterized in that said direct communications are customary over connections using HTTP, SMTP, or other receptacle protocols simulating HTTP session with said sender and said receiver using IDs. session, encryption control, alternative transmission protocols, and custom data structure for the transmitted message components. Communication system according to claim 7, characterized in that said payment authorization and accounting includes a upload and installation of a sender / receiver software installation file, installation of said sender and receiver software in said sender and receiver terminals, registration of a sender / receiver account, account verification and credit information for the sender / receiver, and activation by an eLetter or direct communications. An electronic mail communication method having a message content component and a message data component relating to the message and / or its transmission between multiple sender and receiver terminals that both use and extend the Internet, characterized by the fact that understand: connect sender and receiver terminals to the Internet; and selection by the sender of premium communication services with the recipient using an electronic postal service to process at least a portion of the transmitted e-mail message data component. The method of communicating electronic mail according to claim 26, further comprising: interacting by the recipient with said electronic postal service in response to said selection or email communication by the sender. E-mail communication method according to claim 27, characterized in that said call includes telecommunication. E-mail communication method according to claim 27, characterized in that said connection includes networking the multiple sender or receiver terminals. E-mail communication method according to claim 27, characterized in that said selective postal services include payment and accounting services for at least a portion of said premium postal services. A method according to claim 30, characterized in that said payment and accounting services provide incentives to a receiving terminal user for said interaction. E-mail communication method according to any one of claims 26-31, characterized in that at least a portion of the e-mail message data portion is communicated to and from the electronic postal service by direct communications. The method of electronic mail communication according to claim 32, characterized in that said direct and other communications between the sender, receiver and electronic postal service form a virtual intranet. E-mail communication method according to claim 32, characterized in that said electronic postal service is distributed through several servers that communicate with each other, at least in part, by direct communications. E-mail communication method according to claim 32, characterized in that said direct communication uses HTTP, SMTP, or other recipient protocols. E-mail communication method according to claim 35, characterized in that said message components are transmitted between said sender and receiver by ISPs diverting said server and postal software, and said message data component is communicated, at least in part, using direct communications between said sender and said server and postal software and between said receiver and said server and postal software. E-mail communication method according to claim 36, characterized in that said message content component communication uses SMTP / POP and / or IMAP protocols by Internet mail servers, and said component communication. of message data at least in part uses HTTP, SMTP, or other receptacle protocols. The method of e-mail communication according to claim 32, further comprising formatting said e-mail message data as a custom header which partly identifies the sender terminal and / or receiver terminal. . An e-mail communication method according to claim 38, characterized in that said custom header formatting further includes providing parts that authenticate and verify said message components and direct their processing. The method of e-mail communication according to claim 32, wherein said direct communication to and from such e-mail service is normal using HTTP S session protocol cookies, third party certificates / keys, and a single transmission protocol. E-mail communication method according to claim 32, characterized in that said direct communication to and from said electronic postal service is customary with said calls using HTTP, SMTP, or other receptacle protocols simulating HTTP session with. said recipient sender software using session IDs, encryption control, alternative transmission protocols, and custom data structure for the transmitted electronic message components. E-mail communication method according to claim 30, characterized in that said authorization and payment accounting includes a upload and installation of a sender / receiver software installation file, installation of said sender software and recipient at said sender and receiver terminals, registration of a sender / receiver account, account verification and credit information for the sender / receiver, and activation by an eLetter or direct communications.