Method and apparatus for private messaging among users supported by independent and interoperating couriers

A private messaging system including multiple interoperating, yet potentially competing, trusted couriers. A method and apparatus are provided for the purpose of distributing a trusted courier such that foreground and background messages are handled independently by separate components.

TECHNICAL FIELD

This invention pertains in general to electronic messaging such as electronic mail (‘email’) and similar communication, and in particular to providing message privacy services.

BACKGROUND OF THE INVENTION

U.S. Provisional Patent Application 60/466,910 entitled SYSTEM, METHOD, AND APPARATUS FOR SIMPLIFIED PRIVATE MESSAGING by the present inventors, (hereinafter referred to as ‘the foundation disclosure’) describes a distributed system of client and server software capabilities that cooperate to provide messaging privacy services. That system, which is being marketed under the name ArmorPost, makes two significant assumptions about its operating environment.

First, the Trusted Courier is a single network element owned by a single entity. While this serves the needs of that single entity, and provides effective service for all users, it is not possible to establish competing yet inter-operating message privacy services using the single-Courier design described in the foundation disclosure. Further, it may be difficult for security-sensitive organizations to deploy a Trusted Courier as described in the foundation disclosure inside their enterprise networks and thereby exert a measure of control over their private messaging traffic.

What is needed, then, is an extension to the system described in the foundation disclosure which allows for multiple Trusted Couriers to operate independently of one another with respect to their own users, yet interoperate with one another to transport Private Messages and related services among their disparate user communities.

Second, the Trusted Courier represents a nexus through which both Private Messages and their corresponding Access Restrictions Messages flow. The fact that these messages are sent separately in time provides substantial security. However, an even greater degree of assurance against abuse of the Trusted Courier's unique position in the network can be achieved by routing those two messages through completely separate elements.

What is needed, then, is an extension to the system described in the foundation disclosure which allows for any Trusted Courier to be distributed across two network servers, which may be further distributed even to two physical sites separated by a significant distance, such that encrypted message content flows through one server while corresponding content key material flows through the other.

It is thus a principal aim of the present invention to create architectures and protocols for distributing and replicating the Trusted Courier, thereby enhancing its applicability and trustworthiness.

SUMMARY OF THE INVENTION

The present invention provides a private messaging system using trusted couriers to relay private messages as well as key material used to protect the private messages that is enhanced by the deployment of multiple independent yet interoperating Trusted Couriers. Preferably, the independent trusted couriers may be operated by independent organizations, some of which may compete with one another for users and others of which may support closed user communities. The present invention contemplates that any of these independent organizations may choose to operate multiple trusted couriers itself, whether for the purpose of aligning traffic distribution with enterprise network architecture, for the purpose of providing greater capacity than is achievable in a single node, or for any other reason.

It is also contemplated that any single trusted courier may be deployed in such a way as to separate the handling of private message content and access restrictions messages that contain key material. While the basic methods for such handling are described in Provisional Application 60/466,910, the present invention provides enhanced methods that ensure the two messages which correspond with one another are not handled in the same network element. In other words, key material used to protect a particular private message is handled by a set of network elements that are at least partially and preferably wholly independent of the network elements used to convey the private message.

The above and other advantages of the present invention are carried out in one form by a system of cooperating elements, each of which applies cryptographic and other procedural means as specified below to effect the desired distribution and replication of trusted couriers, while continuing to ensure the privacy of each message as it is conveyed from its sender to its recipients across multiple couriers and courier partitions, as well as continuing to permit the establishment and enforcement of access restrictions by that sender.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

InFIG. 1Multi-Courier Private Messaging System100represents the system in accordance with the present invention. Four major elements make up this system. First, End-to-End Messaging Infrastructure101represents the messaging backbone to which the Private Messaging capability of the foundation disclosure, as enhanced by the present invention, is added. This Infrastructure can be any messaging system that allows users and/or software entities to exchange messages with one another. It is preferably the Internet-standard email service, but may also be implemented as an instant messaging service, a wireless short message service (SMS), any other messaging service, or any combination of these. Second, Packet Network102forms the foundation for all communication among elements, including End-to-End Messaging Infrastructure101and the messages exchanged thereon, but also supporting other non-messaging interactions such as web browsing. This element is preferably an Internet-based network, and may be the Internet itself, another network like it, or a composite of networks using multiple inter-networking technologies.

Third, connected to End-to-End Messaging Infrastructure101and Packet Network102are one or more Agents110, which are computer software applications and devices which enable the Private Messaging capability for an end user. Each Agent110is a composite of some existing Messaging Client112, an Information Security component111, an interface113to the Messaging Infrastructure101, and an interface114to the Packet Network102. Agent110and its components are described in detail in the foundation disclosure, and are used here exactly as they are there.

Fourth, also connected to Messaging Infrastructure101and Packet Network102are a plurality of Trusted Couriers103. These fill the same functional role as the Trusted Courier described in the foundation disclosure. However, where that system included only a single Trusted Courier, here any number may appear. This replication of the function satisfies the multiple ownership and traffic dispersion goals cited above.

In the present invention each Trusted Courier103comprises a Background and a Foreground element, such that Background and Foreground signaling as defined in the foundation disclosure are handled in completely separate Courier elements. This enhances the security of the system because with foreground and background signaling handled separately, the content of any single Private or Restricted Message cannot be decrypted by any Trusted Courier. This satisfies the distribution goal cited above.

Each Trusted Courier103comprises two elements. Trusted Courier Foreground Element120is substantially identical in every way to Trusted Courier120from the foundation disclosure. Trusted Courier Background Element130is based on Trusted Courier120from the foundation disclosure, and its Information Security module131is substantially identical to Information Security module121from the foundation disclosure. Trusted Courier Background Element130differs from the previous Trusted Courier120in that it lacks an Account Management module; no such module is necessary in Trusted Courier background element130because the Account Management module122in its corresponding Trusted Courier foreground element120serves for the entire Trusted Courier103. It also differs in that it has no Interface123to Messaging Infrastructure101; because Trusted Courier background element130handles only background element signaling, it interacts directly with Agents110and other Trusted Courier background elements130only via its Interface124and Packet Network102.

Note that there is no direct interface within Trusted Courier103between Courier foreground element120and Courier background element130. This attribute prevents abuse of Trusted Courier103's sensitive position in the message flow network. The few interactions that are required between Courier foreground element120and Courier background element130, which will become clear as the methods of the present invention are explained below, take place through Packet Network102on their respective Interfaces124. This interface choice also provides a great deal of architectural flexibility in the deployment of Trusted Couriers103. Courier foreground element120and Courier background element130may be situated as close to or as far from one another as their operator deems appropriate. For example, they may be deployed in the same room on the same Internet access interface, in different cities, or using any topology in between. It is also conceivable that they may be implemented as separate processes in the same computer, although this is not expected to be common or advisable due to security concerns. The foundation disclosure details the structure and functionality of Agents110and Trusted Courier Elements120/130, which description is incorporated herein by reference.

FIG. 2shows a schematic summary of the possible topologies in which the multiple Trusted Couriers103of Multi-Courier Private Messaging System100may be arranged relative to one another. This figure depicts four distinct organizational roles a Trusted Courier103might play in the network, along with two distinct inter-Courier relationships. The organizational roles represent different sets of constraints on certain significant behaviors, which make each particular role suitable for certain types of organization. The relationships pertain to how these Couriers interact with one another to form networks. Note that these relationships represent meaningful interactions, not direct communication links. All communication takes place via Packet Network102. Also note that Agents110are not shown in this diagram, but are instead implied. Each User and Agent is registered with and served by a single Courier. Thus each Trusted Courier103forms an island of service, and with respect to the Private Messaging service acts as a gateway for its registered Agents/Users. The relationships among Trusted Couriers103represented inFIG. 2insulates those Agents110from one another, particularly with respect to encryption/authentication certificates.

As was stated in the foundation disclosure, simplification of the User's encryption/authentication experience is a significant benefit of the Private Messaging system, and this is accomplished by having the Trusted Courier act as a proxy for all other correspondents. This leads directly to the purpose of Relationships201(indicated by bold lines inFIG. 2), which are between one Trusted Courier103and another Trusted Courier103which certifies the authenticity of the first by signing its encryption/authentication certificate. In order for every Agent110served by a Courier103to trust messages from every Agent110served by every other Courier103, there exists a network of certificate authenticity in which every Trusted Courier103participates. This network is depicted inFIG. 2as a pure hierarchy. Note that each Trusted Courier103has exactly one Relationship201superior, and may have many Relationship201inferiors. No peer Relationships201may exist, as there is no meaning within a certification hierarchy for such peering. Thus the Couriers103, each of which is a Certificate Authority for its Agents110and any other Couriers103which subtend it, form a conventional Certificate Authority tree via their Relationships201with one another. At the top of this tree is Root Courier200, which acts as the root Certificate Authority for the entire network. Conventional Public-Key Infrastructure technologies and techniques, well known to those skilled in the art, are used to form this tree.

The Root Courier200role is filled by exactly one Trusted Courier103in the network. In the preferred embodiment, this is the Trusted Courier103operated by the authors of the present invention, although the business environment will dictate whether this continues to be the case.

Public Courier210and Private Courier220represent Couriers103that are operated by different classes of organization, and which have different constraints on their service domain. A Public Courier is permitted to serve any User without constraints, while a Private Courier is constrained to serve only those Users whose addresses fall within the same network namespace as the Private Courier. For example, a Private Courier in a particular Internet Domain Name would only serve Users whose email addresses are also in that same Internet Domain Name. Typically, a major ISP or carrier would operate a Public Courier, while an Enterprise or small ISP would operate a Private Courier. For example, Public Courier210might be a major ISP serving numerous Users in multiple domains, while Private Couriers211and212, which subtend it in the CA hierarchy, might be particular Enterprises that are customers of that ISP but operate their own Couriers for security reasons. As another example, Private Courier220might be the first Courier placed in service by a large Enterprise, which later installed Private Couriers221and222to diversify their traffic.

Behaviorally, the primary difference between Public and Private Couriers is how they handle recipient addresses that are not registered. A Public Courier will invite these Users according to the procedures in the foundation disclosure. Because there are no domain constraints on a Public Courier, this practice carries a risk of inviting a User who is already Registered in some other Courier, Public or Private.FIG. 9depicts this situation, which will be described below. On the other hand, a Private Courier will Defer the message to its Relationship201superior because its domain of service is constrained. The superior Courier, and its superiors up to Root Courier200if necessary, will resolve the unknown recipient address. This situation is depicted inFIG. 8, which will be described below. Note that Root Courier200is also a Public Courier.

While the Relationship201hierarchy is appropriate for certificate authentication, it is not optimal for traffic flow. Relationships202(indicated by non-bold lines inFIG. 2) represent the opportunity for flow of Private/Restricted Messages, Access Restrictions Messages, and other traffic between Couriers103so related on behalf of their Agents110. For such traffic to flow, the Couriers103involved have previously exchanged encryption/authentication certificates with one another so that information privacy and authenticity are ensured. Note that these certificates are governed by the certificate authenticity hierarchy formed of Relationships201, so every participating Trusted Courier103may be assured of the others by validating the certificates up to the Root Courier200. This exchange process is called Introduction, and the mechanics of it are depicted inFIG. 8, which will be described below. Here it is sufficient to note that any Courier103may be introduced to any other Courier103, thus forming a traffic mesh according to the demand of the Agents110involved. Thus an optimal network is formed dynamically. Note that a Relationship202is automatically formed in parallel with every Relationship201as a corollary to the certificate authentication process. Additional Relationships202form as demanded by the traffic flow, and may appear anywhere.

Certain regulatory environments may exist which constrain the any-to-any formation of Relationships202. In such situations a Gateway Courier230role is conceived which focuses all Introduction activity, and therefore all inter-Courier traffic, on itself for a particular segment of the network for which it is responsible. Note inFIG. 2how Private Couriers231and232have no Relationships202which bypass Gateway Courier230. Formation of this topology is a special case of the procedures described below, and requires no additional procedures. Gateway Courier230may also be either a Private Courier or a Public Courier, as the relevant behavioral characteristics for determining Public vs. Private or Gateway vs. non-Gateway are orthogonal to one another.

InFIGS. 3 through 9we find the major methods which operate in the Multi-Courier Private Messaging System100that are different from or in addition to the procedures in the foundation disclosure. As Invitation remains unchanged from the foundation disclosure, we begin with Registration inFIG. 3. The change appears at the end of the process, but the description here will recap in abbreviated form the steps that have not changed as well.

Registration begins with step301, in which the registering user receives an Invitation as described in the context of the foundation disclosure'sFIG. 4. Imbedded in the Invitation message is a referral link, and in step302the user follows this link with a web browser and fills out the resulting form. Step303condenses the retrieval and submittal of the form, which appear as steps503-506in the foundation disclosure'sFIG. 5.

Upon receipt of the completed form in step303, Trusted Courier foreground element120will at step304create the user's account, and at step305construct an Agent Installer for the user. The Agent Installer is a software application that will install an Agent110in the user's computer or device. The Agent Installer package is downloaded to the user's computer or device in step306, through the same secure path used by the registration form in step303. The Agent Installer is executed in the User's computer or device at step307. The foregoing steps304-307correspond exactly to steps507-510in the foundation disclosure'sFIG. 5.

During installation, the installer establishes that it has landed in the right place, so its first action at step308will be to validate its configuration as described in step511of the foundation disclosure'sFIG. 5, and prompt the User for a local password as described in step512of the foundation disclosure'sFIG. 5. The User will create and enter the requested local password at step309, and the Agent Installer will store it and create the necessary encryption keys at step310; these steps correspond exactly to steps513-515in the foundation disclosure'sFIG. 5.

Next, the Agent Installer and Trusted Courier foreground element120will in steps311-313exchange keys with one another and store the results of the exchange, in exactly the manner as described in detail for steps516-520of the foundation disclosure'sFIG. 5. The foundation procedure concludes with an Agent Alive Indication message being sent by the Agent Installer to Trusted Courier foreground element120in steps314-315, corresponding exactly with final steps521-522of the foundation disclosure'sFIG. 5.

At this point, however, the present invention continues so as to ensure that both Trusted Courier foreground Element120and Trusted Courier background element130are operating with the same data regarding the Registering User and Agent110. Step316shows Trusted Courier foreground element120sending a Distribute Account message to Trusted Courier background element130. This message carries the User's and Agent's addresses, along with encryption keys for both Courier and Agent. The Registration procedure concludes at step317with Trusted Courier background element130activating its view of the User's account.

Note that both foreground element and background elements will operate with the same keys, including the Courier-end private key. While this is perhaps unconventional compared with prior-art public-key cryptography, it permits Agent110to be somewhat simpler than would be the case if Trusted Courier foreground element120and Trusted Courier background element130used separate keys to communicate with Agent110. In particular it avoids the necessity to execute the Key Replacement procedure with both halves of the Trusted Courier103.

FIG. 4depicts an exemplary process of replacing cryptographic keys. Functionally, steps401-409correspond exactly to steps601-609of the foundation disclosure'sFIG. 6, and so are not detailed further. However, due to the separation of foreground element and background element steps402and407are extended as described here, and additional steps410-412are required to synchronize the two elements in the Courier. Trusted Courier foreground element120drives the Key Replacement process from the perspective of Trusted Courier103, but Trusted Courier background element130participates in two ways. First, because Agent110can only receive background messages from Trusted Courier background element130, the Notice to Rekey and Exchange Keys messages are relayed through it. Therefore steps402and407, respectively, depict these messages going not directly to Agent110but to Trusted Courier background element130, which performs a relay function in steps402aand407a. The messages then go to Agent110at steps402band407b, respectively. Note that the Exchange Keys message in step404and the Rekeying Complete message in step409, though logically background messages, can nevertheless be sent straight into Trusted Courier foreground element120by Agent110due to the nature of the underlying messaging protocols. Second, because Trusted Courier background element130does not participate logically in the Key Replacement that concludes at step409, it is informed of the result by Trusted Courier foreground element120. The latter does so at step410, conveying to the former in step411a background element Key Replacement message that carries the new keys for both Trusted Courier103and Agent110. Trusted Courier background element130records these new keys in its database at step412.

The observant reader will note that in neither the Registration process ofFIG. 3nor the Key Replacement process ofFIG. 4does Trusted Courier background element130respond to Trusted Courier foreground element120after receiving the database updates. The principle being followed here is that Courier background element130is subservient to Courier foreground element120and cannot have any opportunity to reject the update. In addition, the absence of any routine signaling from Courier background element130to Courier foreground element120contributes further to the prevention of any potential abuse whereby Courier background element130might relay an Access Restrictions Message to Courier foreground element120and subvert the separation.

With multiple Trusted Couriers103in the network, it is inevitable that Users will migrate among them in certain situations. As the network of Couriers owned by a single operator grows, for example, that operator will want to distribute the Users among the various Couriers103for appropriate load balancing and optimal traffic flow. Public Couriers as well will tend to compete with one another for Users, so some churn is to be expected in the network. Both situations require a controlled mechanism for moving a User's Registration from one Courier103to another. The procedure used to do this will optimally involve the operators of both Couriers103(even when they are the same entity), so that no question will arise as to whether a particular transfer was appropriate. It should never be possible for the operator of a Trusted Courier103to ‘slam’ a User's Registration unilaterally. Further, while a User should be able to trigger a transfer, the process itself should be handled automatically without additional User intervention.

FIG. 5depicts a Registration Transfer procedure that satisfies these requirements. The process begins with the operator(s) of the two involved Trusted Couriers103agreeing at step501to perform the transfer of a particular User. This is a business-process step that may or may not involve automation but definitely involves human decisions. As such the details of this part of the procedure will vary among different operators and are not further specified here. In the case of a User-initiated transfer, this decision step also offers the operator of the old Courier103an opportunity to attempt various marketing actions that might retain the customer.

Once the transfer is agreed, the respective operators will set the system to perform it. In step502, the operator of the Courier103that will gain the User, termed here the ‘new’ one, will through an administrative action record the transferring User's messaging address such that ‘new’ Courier foreground element120will accept the transfer and execute the automated steps involved. At the same time, in step503the operator of the Courier103that will lose the User, termed here the ‘old’ one, will through an administrative action initiate the automated portion of the procedure. Note that this implies the ‘old’ Courier103and its operator cooperate in the transfer, in fact to the point of actively relinquishing the User. Between this and the continued use of cryptographic authentication throughout the process, slamming is quite impossible.

The automatic portion of the Registration Transfer procedure commences then at step504, wherein the ‘old’ Courier foreground element120transmits the User's subscription data and Agent key to ‘new’ Courier foreground element120in a Transfer Subscription message. Note that, as with Registration and Key Replacement, Courier foreground element120drives the process, only informing Courier background element130after certain key steps. Note also that this message is preferably encrypted to protect its sensitive content, as are all others in the system of the present invention and the foundation disclosure.

Upon arrival of the Transfer Subscription message, ‘new’ Courier foreground element120at step505creates a database entry for the transferring User using the information in the message. At step506it creates new keys for itself which are to be used in communicating with the User's Agent110. At this point ‘new’ Courier background element130needs to know about this User, so step507conveys the necessary information in a Distribute Account message that is substantially identical to the one in step316ofFIG. 3. ‘New’ Courier background element130records this information in step507ato activate this User's support there.

Now that ‘new’ Trusted Courier103is prepared to accept the transferring User, ‘new’ Courier foreground element120informs ‘old’ Courier foreground element120of the parameters required for Agent110to access the new account by sending a Configuration Update message to ‘old’ Courier foreground element120at step508. These parameters include network names and addresses for the servers that comprise ‘new’ Trusted Courier103, as well as the messaging addresses and encryption/authentication certificate to be used by Agent110when communicating with ‘new’ Courier103. Because this information goes first to ‘old’ Courier103and not directly to Agent110from ‘new’ Courier103, slamming by arbitrary would-be ‘new’ Couriers103is prevented.

The next several steps in the Registration Transfer are actually a special case of the Key Replacement procedure, in which the ‘old’ Courier103commands Agent110to exchange keys with ‘new’ Courier103. At steps509-511, the Notice to Rekey message is sent from ‘old’ Courier foreground element120, through ‘old’ Courier background element130acting as a relay, to Agent110, just as it is in steps402-402bofFIG. 4. The difference here is that this message also carries the new configuration data pointing to ‘new’ Courier103, which was conveyed previously in the Configuration Update message at step508. Agent110acts upon the Notice to Rekey at step512by creating new keys for itself, just as it does in step403ofFIG. 4. In addition, at step513it acts upon the new configuration data in the message by changing its own configuration so that it refers to ‘new’ Courier103. All subsequent interactions with a Trusted Courier103will thus take place with ‘new’ Courier103.

The remainder of the Key Replacement is the same as inFIG. 4. Steps514-521, in which Agent110and ‘new’ Courier103exchange their new keys and record them accordingly, are substantially identical to steps404-409. Similarly, the Background Key Replacement that occurs in steps522and522a, whereby ‘new’ Courier foreground element120informs ‘new’ Courier background element130of the completed Key Replacement, is substantially identical to the one in steps411and412.

Because the aforementioned Key Replacement occurs in the context of the ongoing Registration Transfer, ‘old’ Courier Pair103as the originator of the transaction is still unaware at this point that it has been completed. Therefore the new state of affairs are propagated back to ‘old’ Courier103. The Transfer Complete message in step523provides this closure. This message is sent from ‘new’ Courier foreground element120to ‘old’ Courier foreground element120in parallel with the background element Key Replacement in step522. Upon arrival, ‘new’ Courier foreground element120at step524changes the User's database entry so that it refers to ‘new’ Courier103as the correct handler for this address, and propagates this change to ‘old’ Courier background element130in steps525and526. Note that the Distribute Account message in step525is semantically identical to message of the same name in step507, although the specific update to the account data is different in each case. At any rate, subsequent attempts to send a message to the transferred User or the corresponding Agent110via the ‘old’ Courier103will therefore be rerouted to the ‘new’ Courier103. At this point the User and corresponding Agent110are safely hosted on ‘new’ Trusted Courier103and no longer hosted on ‘old’ Trusted Courier103.

As long as the User's Registration status is active and stable, that is, not in the process of executing one of the preceding procedures, the corresponding Agent110may create and send Private or Restricted messages to correspondents via the Trusted Courier103with which Agent110is associated.FIG. 6depicts exemplary processes which are followed to do so when both sender and recipients are served by the same Courier103. This diagram is derived fromFIG. 7of the foundation disclosure, condensed for brevity where no change has been made and enhanced where necessary to describe what changes in the context of the present invention.

First, at step601the sending User and Agent110will prepare the message, including composing it, marking it as Private or Restricted as appropriate, and commanding that it be sent. Also embodied in this step are the various conversion, encryption, and formatting actions that take place afterward, including construction and storage of the ARM Record. Though combined into a single step here, these items are substantially identical to steps701-705ofFIG. 7in the foundation disclosure.

The Private or Restricted message thus prepared, it is set aside for the moment so the ARM Record can be sent first. Step602provides for the construction of an Access Restrictions Message using the same recipient lists as the Private or Restricted message being processed, and containing the corresponding ARM Record. As detailed in the foundation disclosure, it is via this separate message that the ARM Record is conveyed to the recipients of the Private or Restricted message such that end-to-end message privacy is assured. In step603, the Access Restrictions Message so composed is signed and encrypted according to the S/MIME email encryption standard (IETF document RFC1847) and sent to Trusted Courier Background130. Step604shows the Access Restrictions Message being transported to Courier background element130and carrying both the Message Identifier and the Content Encryption Key, which are elements of the ARM Record. Upon arrival of the Access Restrictions Message at Courier background element130, at step605it is decrypted and validated. These steps602-605taken together are substantially identical to steps706-710of the foundation disclosure.

At this point the order of processing differs due to the separation of background and foreground handling into distinct elements. Where in the foundation disclosure it is the Access Restrictions Message that triggers Invitation of any unknown recipients, in the present invention that message is handled in Courier background element130and is held pending Registration of unknown recipients by Courier foreground element120.

Thus for each recipient in the message header that is a Registered address, Courier background element130will in steps606and607find the appropriate set of keys, use them to create the S/MIME signature and transport encryption for the Access Request Message, and send the signed and encrypted Access Request Message to that recipient. Step608depicts this message in transit to the recipient, whose Agent110will in step609decrypt and validate the Access Restrictions Message, then store the enclosed ARM Record. These steps are substantially identical to steps718-721inFIG. 7of the foundation disclosure. Again, this sequence is repeated for each known recipient.

Now in step610, Courier background element130will make a copy of the Access Restrictions Message for each recipient that isn't already Registered in the system, creating a new database entry for each one in preparation for their eventual Registration. Step611depicts Courier background element130quiescing at this point to await notice from Courier foreground element120that the Registration has completed; this occurs, as usual, for each of the relevant addresses. Processing will resume at step628, but first the foreground handling is described. Note that good server hygiene practice will dictate that an implementation audit these outstanding messages and clean up any that have not been released within a reasonable time.

Returning to the sender's Agent110, the foreground message with the actual encrypted content, which was prepared previously in step601, is wrapped in an S/MIME package (signed and encrypted) in step612and sent to the Courier foreground element120in step613. Courier foreground element120unwraps the S/MIME package (decrypt and validate) in step614. This sequence is substantially identical to steps722-726inFIG. 7of the foundation disclosure. Note that the Courier Receipt and corresponding process steps described in the foundation disclosure are implied here, though not shown inFIG. 6for the sake of brevity.

Now Trusted Courier foreground element120steps through the list of recipients' addresses in the header, determining which refer to registered users and which are unregistered as did Trusted Courier background element130above. For each Registered recipient address, Courier foreground element120will retrieve the correct keys in step615, rewrap the foreground message in an S/MIME package (signed and encrypted) in step616, and send it to the corresponding Agent110in step617. This sequence is substantially identical to steps727,729, and730inFIG. 7of the foundation disclosure. As these messages arrive at their respective destinations, each recipient's Agent110will decrypt and validate the S/MIME package in step618, find in step619the ARM Record stored previously at step609, and use the content encryption key kept there to decrypt and present the message in step620. This sequence is an abbreviated depiction of the detailed process described in the foundation disclosure. Specifically, steps615-620here are meant to be substantially identical to steps727-738there.

The following sequence is repeated for each unknown recipient. Upon recognizing that the recipient address is not Registered, at step621the foreground message at hand will be copied into a new database entry created in anticipation of the addressee's eventual Registration. Courier foreground element120will then, in step622, initiate the process of Inviting the recipient to Register. This process is described in full in the foundation disclosure; it is used here exactly as it is there, and is represented here as a message flowing to the addressee in step623. Following Invitation, the User's natural response is Registration, depicted here as an interaction between Agent110and Courier foreground element120in step624. This process has already been described in the context ofFIG. 3. Note that the final steps of Registration include notifications at both Courier foreground element120and Courier background element130. These final steps are used as triggers by which each element detects that Registration is complete. Thus at step625, Courier foreground element120makes this detection, and so at step626it releases the held copy of the foreground message previously stored for the particular recipient whose Registration has just concluded. At step627, then, Courier foreground element120returns to step615and processes the message for transmission to the recipient. Similarly, at step628Courier background element130detects the completed Registration, at step629releases the held Access Restrictions Message for that recipient, and at step630returns to step606to process the background message for transmission to the recipient's Agent110. Once again, these steps are repeated for every Invited recipient that completes Registration. For those that don't after a reasonable time, implementations should practice good hygiene and purge them.

The remaining diagrams depict various message flow scenarios involving multiple Couriers103. So that these next sections do not entail the complication of describing the looping over multiple recipients, each scenario is shown with only a single recipient. However, it should be apparent that the system supports multiple recipients per message, and in fact the multi-recipient looping is implied in each of the cases that follow.

FIG. 7depicts the scenario in which the sender and the recipient are Registered in different Couriers103, and those Couriers103both have been Introduced to one another. Note that Introduction scenarios are depicted inFIGS. 8 and 9, and will be described later. For now, the inter-Courier routing of messages will be clearer if we start with them already Introduced.

The message flow begins as usual in step701with the preparation of a Private or Restricted message. Steps701-705, in which the message is created and prepared, and the Access Restrictions Message is sent to Courier background element130, are substantially identical to steps601-605inFIG. 6. In step706, however, the process differs because Courier background element130detects that the recipient address is served in another Courier103. This detection can take one of two forms. If the sender's Courier103is Private (refer back toFIG. 2), that the recipient's domain is different from the sender's domain will denote that a different Courier103serves the recipient. If the sender's Courier103is Public, it can know a different Courier103serves this specific recipient address if a previous Introduction has taken place as described inFIG. 9for this recipient. Any Courier103, Public or Private, may also make this detection if the recipient's domain matches that of a Private Courier103that is subordinate to the current one according to the certification hierarchy described inFIG. 2.

Once the sender's Courier background element130has determined the recipient's Courier background element130, it will at step707imbed the Access Restrictions Message in an Inter-Courier message addressed to the recipient's Courier background element130, and rewrap it in an S/MIME package (signed and encrypted) suitable for the destination Courier. The encryption key is found in the certificate provided by the recipient's Courier background element130during the aforementioned Introduction, while the signature key is that of the sender's Courier background element130. Note that, unlike the certificates for Agent110communication, which are allocated per Registered address for both Courier and Agent, each Courier103Introduces itself to all other Couriers103using the same certificate.

In step708the Access Restrictions Message, imbedded in the Inter-Courier message, is transported from the sender's Courier background element130to the recipient's Courier background element103. Upon arrival, at step709this message is unwrapped, decrypted, and validated as usual. Steps710-713, wherein the background message is rewrapped and transported to the recipient Agent110, and there saved for future use, are substantially identical to steps606-609inFIG. 6

Similarly, the foreground processing continues substantially identically to the single-Courier case, with steps714-716moving the Private or Restricted message into the sender's Courier foreground element120. At step717, the same routing decision that is made at step706in the sender's Courier background element130is made in the sender's Courier foreground element130. This brings to the fore the point that Introductions are propagated in parallel to both elements of a Trusted Courier103so that they can both make the same routing decisions using the same criteria. This is an important attribute of the present invention, because it allows each Courier foreground element120and corresponding Courier background element130to operate in parallel with a minimum of synchronization points. All of these synchronization points have already been described inFIGS. 3,4, and5with respect to Registration and the procedures that affect a User's account. No synchronization between Courier foreground element120and Courier background element130is required during message flow or Introduction, thus eliminating any opportunity to compromise Private and Restricted messages.

Because of the aforementioned parallelism, transport of the foreground message from the sender's Courier foreground element120to the recipient's Courier foreground element120is substantially identical to transport of the background message between the two Courier background elements130. Steps717-720are thus the same in the two Courier foreground elements120as steps706-709in the two Courier background elements130. As well, once the foreground message has arrived at the recipient's Courier foreground element120, processing steps721-726to move it into Agent110and there present it to the User are substantially identical to steps615-620inFIG. 6.

The simplicity of this description demonstrates the ease with which the present invention handles the steady state message flow in the traffic mesh network ofFIG. 2. However, to establish this network requires Introduction procedures.FIG. 8depicts the scenario in which the sender's Trusted Courier103is a Private Courier, not permitted to serve Users outside its domain, that has not been Introduced to the recipient's Trusted Courier103.

InFIG. 8. it should be noted that the foreground and background processing occur independently of one another and have essentially the same shape. This lack of interdependence is an important feature of the present invention. The parallelism will be exploited in the following description as well, by providing a single description for both foreground and background paths and noting that both are alike.

As usual then, steps801-803prepare the message and transport the background component (the Access Restrictions Message) to the sender's Courier background element130, while steps815-816transport the foreground component to the sender's Courier foreground element120. This sequence is substantially identical to steps701-705and714-716inFIG. 7, although they are depicted in an even further condensed form.

At steps804in Courier background element130and817in Courier foreground element120, the critical decision is made that the recipient's address cannot be served in this Trusted Courier103, and is not known to be served in any other Trusted Courier103that has been Introduced to this one. Since this is a Private Courier, the decision is quite simple: the domain of the recipient's address does not match the domain of the sender's Courier103, nor does it match the domain of any other Courier103to which this one has been Introduced. Therefore, the message is Deferred to the superior Courier103. Refer to the discussion of the certification hierarchy in the context ofFIG. 2for a definition of the superior for each Trusted Courier103.

Deferral takes the form of wrapping the message at hand in an Inter-Courier message, performing the S/MIME signature and encryption using appropriate keys, and sending the package to the appropriate member of the superior Courier103. Steps805-806and818-819depict this action. Note that in both foreground and background, the Inter-Courier package carries not only the corresponding message, but in this case it also carries the certificate of the sender's Courier103in order to begin the Introduction. As the package is propagated to the proper Courier103for the recipient, this certificate will go along and serve to Introduce each member of the recipient's Courier103to the corresponding member of the sender's Courier103.

One or more Superior Couriers103act upon the message as it is Deferred. At steps807and820, the decision is made that this message should be directed to the corresponding member of the recipient's Courier103. In this scenario that decision is substantially identical to the one made in steps706and717ofFIG. 7. However, it is also possible that the immediate superior also does not know the recipient Courier103, and executes another Deferral to its superior. Deferral can continue until the first Public Courier103is reached, which may be the Root Courier as described in the context ofFIG. 2.FIG. 9details what happens at that point. Once a superior Courier103is reached at which the actual recipient's Courier103has been Introduced previously, the message is processed and relayed accordingly. Thus, steps808-811and821-826are substantially identical to steps707-713and718-726ofFIG. 7.

The members of the recipient's Courier103have not yet completed their processing, however. Noting at steps812and827that an Introduction was carried by the message, the certificate and address from that Introduction are captured in a new database entry for future reference. Subsequent messages addressed to recipients in the domain of the sender's Courier103in this scenario will be routed directly to that Courier103now that it has Introduced itself. The Introduction is then completed back to the first Courier103in order to close the loop. To do so the recipient's Courier background element130and Courier foreground element120each create an Introduction message and send it to the sender's Courier background element130and Courier foreground element120respectively in steps813and828. These Introduction messages contain the certificate and address of the recipient's Courier103. Upon arrival in the sender's Courier103, these Introduction messages are consumed, and a new database entry is made for the recipient's Courier103, its address and certificate. Note that no coordination is required between the foreground and background planes, because they are each handled independently of one another, providing the same information without synchronization points in the protocol.

InFIG. 8Introduction is driven by Deferral of a message from a Private Courier103to its superior Courier103. This works well within and among Private Couriers103, but as soon as the message reaches a Public Courier103, whether by Deferral or directly from an Agent110served there, and a recipient address is unknown at that Public Courier103, Invitation will take place as previously described. However, because multiple Public Couriers103may exist in the network, and because not all Private Couriers103are known to all Public Couriers103, it is quite possible for the Invitation to arrive at an existing Agent110that is Registered in a Courier103other than the Invitation's source. This is potentially a very confusing situation for the User, so appropriate automatic handling of the unwanted Invitation is required at Agent110.FIG. 9depicts this scenario, and the following paragraphs describe the necessary processing.

Beginning at step901, and continuing through step908,FIG. 9depicts what appears to be an ordinary message flow involving a single Trusted Courier103and a recipient whose address is unknown there. The processing in this sequence is substantially identical to steps601-605,610-614, and621-623inFIG. 6, depicted here in a highly condensed fashion. Note, however, a small difference between the Introduction message in step908and that of the foundation disclosure: the sender's Courier foreground element120includes its Introduction certificate in the message, and signs the entire Invitation. This change is actually a benefit even without the multi-Courier network, because it allows invited recipients an opportunity to validate the authenticity of the message. Nevertheless, while it would have been useful before it is critical here in order to trigger Introductions between the members of the sender's and recipient's Couriers103.

The key action in triggering these Introductions takes place in step909. The Agent110which receives the Invitation from the sender's Courier foreground element103knows itself to be Registered already in a different Courier103. Therefore, it rejects the unwanted Invitation by forwarding it to both members of its Courier103. No User action is required unless Agent110is implemented in a loosely-coupled fashion as described in the foundation disclosure; even in that case the only action required is to open the message, whereupon the Agent110software is called and the process continues.

The background rejection occurs first, with Agent110forwarding the Invitation and its Introduction certificate to its (the recipient's) Courier background element130in an Invitation Reject message at step910. Though not explicit in the diagram, this message is wrapped in the usual S/MIME package (signed and encrypted) for proper transport protection and authentication. Upon receiving, decrypting, and validating this message, the recipient's Courier background element130at step911extracts the Introduction certificate and creates a database entry for the sender's Courier background element130to which it points. Next, in step912an Introduction message is sent from the recipient's Courier background element130to the sender's Courier background element130, encrypted using the latter's certificate and carrying with it the former's certificate. In addition, this Introduction message carries the original forwarded Invitation for correlation purposes. Upon receiving, decrypting, and validating this message, the sender's Courier background element130will at step913conclude the Introduction by creating a database entry for the recipient's Courier background element130and storing the received certificate there.

After the Introduction is complete between the two Courier Backgrounds130, the pending Access Restrictions Message is handled. Remember that the sender's Courier background element130is holding that message, and awaiting notice from the corresponding Courier foreground element120that the addressed recipient has Registered. In order for the sender's Courier background element130to know that the recently completed Introduction is relevant to the pending message, the forwarded Invitation carried by the Introduction message in step912is consulted. The original recipient's address is available there, so the sender's Courier background element130can correlate the Introduction to the held message. Therefore, at step914, it stops waiting for a Registration that will not occur, and instead records in the database entry for the recipient address that subsequent messages should be relayed to the just-introduced Courier background element130. The pending Access Restrictions Message is released, to be relayed in the usual S/MIME package to the recipient's Courier background element130via the InterCourier Message in step915. The processing and signaling in steps916-918, which move the Access Restrictions Message the rest of the way to its destination, are substantially identical to steps709-713ofFIG. 7.

With the background rejection complete, the foreground rejection can now be described. The steps taken are substantially identical to those of the previous paragraph, except that the messages flow through and the actions are taken by the respective Courier Foregrounds120. The Invitation Reject message in step919is substantially identical to the one in step910, and the remainder of the Introduction in steps920-922is the same as steps911-913. Similarly, canceling the Registration and releasing the held message in step923is the same as canceling the Registration and releasing the held message in step914. Finally, now that the recipient's address is correlated with the correct Courier foreground element120, the inter-Courier message propagation and final delivery shown in steps924-929are substantially identical to the same processing and signaling in steps717-726inFIG. 7.

Note how the background and foreground rejections propagate independently of one another, as well as how the Introductions and message releases they trigger also flow without interaction between the various background and foreground elements of the Trusted Couriers103that are involved. This is yet another example of the robust interlock-free protocol design intended in the present invention. While the Foreground Invitation Reject in step919is shown being sent after arrival and processing of the Access Restrictions Message in step918, this is a descriptive convenience rather than a protocol requirement. In fact, in the preferred embodiment the Foreground Invitation Reject in step919is sent immediately after the Background Invitation Reject in step910, thereby allowing Agent110to quiesce while the rest of the system does its work. Then the messages that arrive as a result will be handled asynchronously, just as they normally are in other scenarios.

The invention has been described above with reference to preferred embodiments. It is not intended that the invention be limited to the specific embodiments shown and described, but that the invention be limited in scope only by the claims appended hereto. It will be evident to those skilled in the art that various substitutions, modifications, and extensions may be made to the embodiments as well as to various technologies which are utilized in the embodiments. In particular, those skilled in the art will recognize that the scenarios posed above are elementary in nature, and a working system will support numerous and various combinations of those scenarios in order to provide the described services. That the infinitude of possible topologies, combinations, and scenario orderings are not explicitly enumerated here should not imply that they have not been adequately disclosed by the descriptions of fundamental elements given here. It will also be appreciated by those skilled in the art that such substitutions, modifications, and extensions fall within the spirit and scope of the invention, and it is intended that the invention as set forth in the claims appended hereto includes all such substitutions, modifications, and extensions.