SYSTEM AND METHOD FOR TRIGGERING RECIPIENT-SIDE EVENTS

[0001] This application is related to United States Application No. 60/935,1 13, titled "System and Method for Triggering Recipient-Side Events," filed on July 26, 2007, the entire contents of which are incorporated herein by reference.

FIELD OF INVENTION

[0002] The present disclosure relates to data processing and, more particularly, to a method and system for triggering events upon the receipt of an email by a recipient or a multitude of recipients

BACKGROUND

[0003] Email has been touted as the Internet's "killer application". Yet, while email is pervasive and can, therefore, be used to contact a very large number of people, it has not seen much evolution over the past decades. In comparison to the web, for example, which has had a phenomenal progression over the past 20 years, email has remained limited to a simple tool for ad-hoc communications. Over the same time-frame, businesses and individuals have increasingly reoriented their interactions to rely more and more heavily on the Internet. And while the web may have been extended in a number of ways to provide sometimes powerful mechanisms for allowing users to collaborate amongst themselves, users have continued to increasingly rely on email for their exchanges given its familiarity and ubiquity. As a result, while a slew of web-based collaboration and messaging solutions exist and despite the massive efforts undertaken by vendors and employers alike to motivate users to move the bulk of exchanges from email to web-based technologies, these technologies have met but limited adoption and, worse, users are increasingly drowning in the amounts of emails they need to exchange in order to effectively work together.

[0004] In a fundamental way, users are comfortable with email and, more importantly, have organized their lives around it. Ample evidence of this may be found in IT industry

analyst publications, trade magazines and, most interestingly, in scientific literature. The following is but a sample of the available scientific literature on the topic of email's impact on users' daily lives:

- N. Siu et al., "Going with the Flow: Emai Awareness and Task Management," ACM CSCW'06, 2006.

- M. Sampson, "Collaboration Software Clients: Email, IM, Presence, ...," Shared Spaces Research & Consulting, 2004.

- N. Ducheneaut et al., "Email as habitat: an exploration of embedded personal information management," ACM Interactions, 2001.

- G. D. Venolia et al., "Supporting Email Workflow," 2001 , Microsoft Research

- S. Whittaker et al., "Email overload: exploring personal information management of email," Lotus Development Corporation, 1996.

[0005] Given email's predominance -- it is described in some of the above articles as users' "habitat" --, there would, of course, be great motivation to attempt to add functionality to it. And, as is described below, an number of attempts have been made in that direction. However, email's lack of reliability greatly limits its extensibility. Efforts to use email for allowing senders to activate recipient-side functionality, for example, such as by sending executable files to recipients, have been severely curtailed by the fact that such functionality was too easily exploitable by malicious third parties.

[0006] Basically, so long as email lacks pervasive authentication and encryption, it will remain difficult to extend its capabilities. Today, people resort to their browser for reliable functionality since the browser is capable of providing such reliability. Yet, the reason it can do so is that there exists HTTPS. And it's important to note that prior to HTTPS, the web wasn't much of a reliable business tool. It only became such when visitors could trust the web site they were visiting. In the case of email (which is a "push" mechanism in contrast to the web, which is a "pull" mechanism), an equivalent trust-inducing mechanism a-la HTTPS has not yet been widely adopted. The problem is probably due to the greater difficulty of creating trust when things are pushed to a

recipient instead of that person pulling on those same things, as is done in the web. Indeed, a great deal many attempts at securing email have failed. While a great deal has been written on that topic, secure email itself is far from being an appealing topic to most users. Indeed, security is often an afterthought. However, it remains that if email were a trustworthy communication mechanism, a new set of possibilities for email communications would be available.

[0007] Aside from email and the web and partly due to email's unreliability, a great number of alternative ways of communicating between parties have seen the light of day, including peer-to-peer (P2P) technologies such as Instant Messaging (IM). Such technologies have typically a number of important drawbacks. First and foremost they are not as familiar and as integrated into users' daily lives as email. As such, users need to learn an additional interface in order to start using such technologies which, in the vast majority of cases, is simply unrealistic. Users have typically nor the inclination nor, often, the time to learn new software. Another drawback of such products and technologies is that they require users to have a separate additional identity for each P2P service they use in addition to their existing email address, which is impractical for most users since the common contact information printed on most business cards is but a phone number and an email address. Yet another drawback of such technologies is the fact that they most often cannot be made to be auditable or secure, which are important issues in corporate settings.

[0008] Given that all users are already familiar with email and already have an email address, there would be tremendous value in developing mechanisms that would allow the building of additional yet trustworthy, secure and reliable functionality on top of email. Such functionality may include real-time communication mechanisms such as IM or voice or integrated access through email to remotely-managed resources or file- sharing, etc.

[0009] In order to build on to of email, we must first further describe email's makeup.

Email is in fact three distinct technologies:

- The Email Namespace. Much like a phone number, users can have a unique email address identifying them which senders known they can use to reach recipients with. It is estimated that there is currently over a billion email users in the world, with 750M of these being business users. The fact that each and every single one of them can be reached via a unique email address and that each and every one of them understand how to use an email address makes the email namespace extremely valuable. The semantics for email addresses are defined in the Internet Engineer Task Force's (IETF) RFC 2822.

- The Email Transport. When an email is sent to a sender's email server, that server is typically connected to other email servers in the world and will be able to send the sender's email to any recipient in the world. The ubiquity of this transport mechanism makes it a very powerful mechanism for transmitting information to any party. The email transport, which is typically the SMTP protocol defined in the lETF's RFC 2821 , is however highly unreliable and insecure, mostly by design. The world network of email servers -- called a Mail Transport Agent (MTA) in RFC jargon -- has, in recent years, also been subject to a tremendous amount of stress given the rising quantities of spam circulating and that stress has certainly not helped SMTP's reliability or security.

- The Email Client Application. Typically each user accesses his email through an email client application -- called a Mail User Agent (MUA) in RFC jargon -- which allows him to receive email, send email, consult emails, organize his emails, etc. This tool is so central to user's daily lives that it is considered by many in the scientific community to be users' "habitat." Despite the centrality of this tool, email client applications differ greatly in terms of features and capabilities. Recently, such applications are also under stress given the levels of spam. Mostly, however, users are exchanging such a large amount of emails that the inboxes administered by their email client applications have become almost unmanageable, more emails being received than can be dealt with in a reasonable amount of time.

[0010] Extending users' experience with email typically means leveraging the

pervasiveness of its namespace while integrating with existing email client applications and avoiding email's transport's unreliability and insecurity. Regarding the later, a wide variety of solutions have been proposed to address these and other issues. Examples of such proposed solutions may be found in co-pending "System and Method for Warranting Electronic Mail Using a Hybrid Public Key Encryption Scheme" assigned PCT International Publication Number WO 2005/078993, "System and Method for Providing Certified Proof Of Delivery Receipts for Electronic Mail" assigned PCT International Publication Number WO 2007/071040 and "System and Method for End- To-End Electronic Mail Encryption" assigned PCT International Publication Number WO 2007/071041 the entire contents of which are expressly herein incorporated by reference.

[001 1] The following describes a number of mechanisms that have been created to extend email's functionality. For each mechanism, a summary of its basic functionality is provided along with its shortcomings.

[00121 Internal messaging systems

[0013] While SMTP is the standard transport mechanism in between email servers on the Internet, organization may use products that rely on different protocols inside their own infrastructure. As such, a large number of organizations rely on Microsoft's Exchange Server and IBM's Lotus Domino. Such products often rely on mechanisms that address some of SMTP's most important shortcomings, namely security and authentication, and can therefore build rich email experiences in between their internal users. Yet, while such mechanisms work internally, they very often do not function with parties that are not part of the local network.

[00141 Emails with static links to dynamic content

[0015] In order to better bridge the gap between web-based applications and users' reliance on email and, also, in trying to provide functionality that will work whether users are inside a given network or not, a number of products and web-based applications

providers (often referred to as providers of Software-as-a-Service) have resorted to sending email notifications containing static URLs. Typically a user receiving such an email is invited to click on the URL, enter some credentials and get access to a web- based application. Applications and sites such as Webex, Linkedln and Facebook often use such functionality.

[0016] While this mechanism increases email's ability to provide users with extended functionality, it has a number of limitations. First, it requires the user to maintain separate credentials for each site his wants access to. Second, the interface he uses to access the application differs from one application provider to the next, even when the functionality is identical. There are also issues with potential for phishing since the transport being used continues to be SMTP. Furthermore, it remains that any interaction he has with the external application will likely generate data for which the only copy will be stored remotely from his computer. Not to mention that remote storage of information is a sensitive topic for a lot of organizations, especially given regulatory compliance requirements. Additionally, users wanting to use such a mechanism to invite recipients to participate to their service need to go to the application's web site in order to invite those recipients. So while sending static URLs to "extend" email is widely used, it has a number of limitations which limit its ability of truly positively impacting users' email habit.

f0017l Emails with dynamic content

[0018] Hanson et al. propose in US 6,505,233 and US 6,463,461 a mechanism for the use of dynamically-updatable emails -- marketed under the name "Zaplets" -- to allow users to view the latest version of a given piece of information instead of having to exchange emails back-and-forth each time information changes. This works by an initiator contacting a "Zaplet" server and asking the server to send a "Zaplet" to a number of participants. Thereafter each participant gets an email which contains some static content and some content is which is read from the server. Users can also dynamically modify the content within that email. Hence, once the update is done, other

users only need to open the previously-received "Zaplet" to see the latest version of the data.

[0019] While such a mechanism allows greater interactivity through email, it suffers from a number of problems. First, users need to leave their natural "habitat" to active new functionality. Also, like the previous mechanism, there are security issues due to the transport. The remote storage of information suffers also from the same previously- mentioned issues. In addition, there is the inconvenience of having to track down previously-received emails in order to see the latest version of the "Zaplet's" content.

[00201 Email-client-application-supported forms

[0021] Some email client application, such as Microsoft Outlook, for example, enable users to send forms or calendar invites to recipients. And in as far as the recipients' email applications understand these specially-crafted emails, then there can a certain amount of functional benefits to users. The most successful example of the use of these are most likely Outlook meeting invites. They can be sent from within the Outlook calendar and, if recipients' software understand the format of the email containing the invite, they will be prompted for accepting or declining the invitation. The extent to which this mechanism can be used to extend email is, however, limited. Indeed, this mechanism works so long as the impact on the recipient for making the wrong choice (i.e. accepting an invite from a stranger) is fairly limited. In most cases, this limits this technology to confirmation- and poll-like functionality.

[00221 Email attachments

[0023] Another way to extend email is to attach content to emails. Users do this on a daily basis. In fact, abuse of this is one of emails' issues today since users will typically exchange the same document back-and-forth a number of times resulting in a deluge of email and a loss of productivity while users attempt to figure out which email contains the proper version. A few years back, however, the most serious issue with attachments was the ability to send executable files using them. Both email client vendors and email

firewall vendors have since remedied to this. But attachments remain a simple mechanism for extending email.

[0024] Microsoft Groove, for example, uses email attachments to allow senders to invite recipients to Groove workspaces. When the recipient double-clicks on the attachment, it is processed by the Groove application. It remains, though, that the sender needs to have first invited his recipients through the Groove application which means users must first master Groove before inviting recipients and all participants need to have Groove installed to participate.

[0025] Generally, attachments are transactional, like email, not interactive. Their ability to extend email lies only in their use for enabling interactive applications, such as Groove. Not to mention that attachments are transported via SMTP and therefore suffer from the same problem as previously-discussed mechanisms.

[00261 Coalescing namespaces around Email

[0027] Hemar et al. describe in WO 2007/026320 a mechanism for coalescing namespaces around email's namespace. In this mechanism, email is used to allow sender to tie their recipient's collection of namespace identifiers around their email address. For example, if Bob knows Alice's email address and Alice also uses IM and VoIP and has a phone number, then Bob can send Alice an email that will enable her to tie her IM and VoIP identifiers to her email address so that Bob only need to know her email address and still be able to contact here through IM, VoIP or telephone. The mechanism described by Hemar suffers, however, from a number of limitations. First and foremost it relies on email's transport, SMTP, and is therefore unreliable and insecure. In addition, it takes for granted that users actually have multiple accounts with multiple services and that they desire being reached through their email address for all of these. The applicability of this mechanism to the large majority of email users remains unclear.

f00281 Email-transport-based protocols

[0029] Estrada et al. propose in US 2003/0135565, US 2004/0230662, US 2004/0230658, US 2004/0230652 and US 2004/0230793 a mechanism for building a protocol on top of the existing email transport for creating a workspace collaboration mechanism. As such, senders and recipients have a plugin that automatically communicates with the plugins of other users in order to exchange emails containing XML-encoded objects for the purpose of synchronizing the workspaces shared amongst participants. For example, when a user's plugin determines that it has received a piece of information regarding a workspace while still a previous piece was missing, it sends out an email to the plugin of the user having said missing piece of information requesting a copy of that information. The interface given to the user is entirely based on the user's existing email client, Outlook. Hence, users continue to exchange information within their natural "habitat." Security mechanisms can be used to ensure the integrity of the XML-encoded objects.

[0030] While this mechanism appears to positively augment email while allowing users to remain in a familiar application, it remains that there a number of important technical limitations to it. First and foremost, it attempts to implement synchronization over an unreliable protocol, SMTP. By itself this contributes to making this mechanism practically useless given that emails can arbitrarily be dropped, can arrive out-of-order and, in some cases, may never arrive due to firewall rules regardless of the number of times they are sent. Also, in the case of multi-party synchronization, one misbehaving or firewalled plugin has the potential of holding up all workspace participants.. In addition, the fact that emails may automatically be sent on behalf of a user would typically be a cause for concern for most IT departments. Also, given that individual computers do not have synchronized clocks, keeping document versions in sync becomes very difficult. Not to mention that SMTP is an asynchronous protocol and does not, therefore, allow providing any sort of real-time communication capabilities between parties.

[00311 Email infrastructure replacement

[0032] Given the above, it is not surprising that some have suggested to drop SMTP all- together. That is what is suggested by LeVasseur et al. in US 2007/0005713, US 2007/0005714, US 2007/0005715, US 2007/0005716 and US 2007/0005717. A new transport is provided for extending email's capabilities along with interface integration with existing email client applications to ease transition. However, no matter how much integration is provided with existing applications, it remains that SMTP's predominance as the main transport mechanism used across the Internet is such that it is very difficult to see how it could be replaced, especially with a proprietary transport

[00331 Current needs

[0034] There also other existing and proposed mechanisms. However, none of the mechanisms comprehensively and/or realistically extend email's existing capabilities in a significant way. There is, therefore, a need to extend email's capabilities while reusing the existing namespace, transport, and email client applications. More specifically, there is a need for providing a mechanism allowing senders and recipients to exchange specially-crafted data, a trigger, through email that enables access to an extensible set of functionality without requiring the learning of new software or the provisioning of additional identifiers and without incurring any security risks.

[0035] There is thus also a need to reduce the quantity of emails being exchanged by providing mechanisms that enable to building of effective collaboration mechanisms that extend email's existing capabilities. There is thus additionally a need to provide capabilities for building email-initiated real-time communication capabilities. There is thus further a need to augment users' existing email experience with additional functionality while still allowing users to remain in their natural "habitat".

[0036] There is thus a need for a system and method for triggering recipient-side events wherein the sender can trust that only the designated recipient(s) can access a given sender-specified functionality based on an email-transmitted trigger and where the

recipient can authoritatively identify the origin of said trigger as being the sender.

SUMMARY OF THE INVENTION

[0037] An object of the present disclosure is to provide a system and method for triggering recipient-side events that overcome at least one of the previously listed drawbacks and that satisfy at least one of the above-mentioned needs.

[0038] Another object of the present disclosure is to provide a system and method for triggering recipient-side events that enables senders to provide recipients with access to remote resources.

[0039] Another object of the present disclosure is to provide a system and method for triggering recipient-side events that enables senders to establish P2P links with recipients without relying on SMTP other than for the trigger's delivery.

[0040] Another object of the present disclosure is to provide a system and method for triggering recipient-side events that enables extending email's existing capabilities.

[0041 ] Another object of the present disclosure is to provide a system and method for triggering recipient-side events that enables extending email's existing capabilities.

[0042] Another object of the present disclosure is to provide a system and method for triggering recipient-side events that enables extending email's existing capabilities without requiring the sender to modify his existing infrastructure.

[0043] Another object of the present disclosure is to provide a system and method for triggering recipient-side events that enables extending email's existing capabilities that will allow similar functionality between users within a given organization and between users of different organizations.

[0044] Another object of the present disclosure is to provide a system and method for triggering recipient-side events that enables extending email's existing capabilities to reduce email traffic.

[0045] Another object of the present disclosure is to provide a system and method for triggering recipient-side events that enables extending email's existing capabilities to provide collaboration features.

[0046] Another object of the present disclosure is to provide a system and method for triggering recipient-side events that enables extending email's existing capabilities to provide real-time collaboration.

[0047] Another object of the present disclosure is to provide a system and method for triggering recipient-side events that enables extending email's existing capabilities while still allowing users to continue using their current email client application to access new capabilities.

[0048] Another object of the present disclosure is to provide a system and method for triggering recipient-side events that enables extending email's existing capabilities wherein the initial deployment of the triggering mechanism imposes no, or few, perturbations on the existing email infrastructure.

[0049] Another object of the present disclosure is to provide a system and method for triggering recipient-side events that enables extending email's existing capabilities wherein it is difficult for malicious third parties to abuse or hack said system and method.

[0050] At least one of the preceding objects is met, in whole or in part, by the present disclosure, in which there is provided a system and method for triggering recipient-side events.

[0051] According to the present disclosure, there is provided a system for triggering recipient-side events, the system comprising: an email transmission module configured for sending an email; a trigger creation module configured for creating a trigger contemporaneously with the sending of the email; an email reception module configured for receiving an email; and a trigger processing module for processing the trigger received within an email received by the email reception module and enabling the recipient to access a remote module using the trigger's contents.

[0052] According to the present disclosure, there is provided a user interface integrated into an email composition window of an email client application wherein the user interface enables an email sender to select a workspace to which recipients are to be invited.

[0053] According to the present disclosure, there is further provided a method for triggering recipient-side events, the method comprising the steps of: a) creating a trigger according to sender preferences prior to the transmission of the email; b) encrypted the trigger and signing it; and c) including the trigger in the outbound email.

[0054] Preferably, but not necessarily, this disclosure can generally be built on technologies that practice the teachings of the previously-mentioned PCT International Publication Number WO 2005/078993, PCT International Publication Number WO 2007/071040 and PCT International Publication Number WO 2007/071041 . This disclosure could also easily be implemented using other equivalent or similar functionality.

[0055] Preferably, but not necessarily, by using mechanisms which make email reliable

and trustworthy, we can implement functionality based on recipient-side triggers. In sum, the email sent by a sender includes a trigger. When the recipient opens the email (which may first require signature verification, decryption and/or processing of PoD of part of the email or its entirety), the trigger is fired and an event occurs. Such functionality has typically been difficult to achieve partly since email has been unreliable and insecure.

[0056] A recipient-side trigger can typically be used to generate all sorts of events. One possibility is to cause the recipient to have access to a resource directly by virtue of the trigger firing off instead of having to direct him to a website, for example. Another possibility is that the event triggered causes a recipient-side applet to communicate with an application server and provide the recipient with direct functionality with said server (possibly some sender-provisioned application or service), again without having to require the recipient to click on a URL found in an email or something of the sorts. Yet another possibility is to have the event trigger interface with a sender-side component thereby allowing the establishment of a P2P link between the sender and the recipient, with the benefits (contrary to most existing P2P implementations) that the only identifier required for entertaining this P2P relationship is the sender and the recipient's email addresses and that both users do not need to go out their existing environment, their email client application, to access additional functionality.

[0057] The reason the recipient can trust the trigger is that the email received and/or the trigger part of it is trustworthy. This may mean a number of different things, but essentially it means that the trigger mechanism cannot be easily abused by a malicious third party.

[0058] One of the advantages of using such a mechanism instead of relying on websites and the providing of URLs in emails is that it's straight in the recipient's inbox. The recipient doesn't need a separate identity on a website nor does he need to maintain such an identity and be forced to remember passwords and the likes and deal with

different website interfaces for each service he is made to use. He continues to use the environment he is most used to, his email client application. So, in essence, access to a service can be granted based on a right to decrypt a given piece email or piece of information contained in an email (i.e. the trigger could be included as an encrypted string in the body of an otherwise plain-text email). And the effect is that there's no URL to be clicked on the recipient side and there's no need for the sender to copy and paste a URL into an email for sending to the recipient. There are no separate credentials for accessing services, in fact LDAP can be used as a backend for authorizing users to have access to services. Recipients could, nevertheless, be provided with access to the same or equivalent resources using a URL ₁ in case they don't have the necessary software for the email client application or are not authorized to install it.

[0059] Other features of the presently disclosed system and method for triggering recipient-side events will become apparent from the following detailed description taken in conjunction with the accompanying drawings, which illustrate, by way of example, the presently disclosed system and method.

BRIEF DESCRIPTION OF THE DRAWINGS

[0060] A detailed description of preferred embodiments will be given herein below with reference to the following drawings, in which like numbers refer to like elements:

[0061 ] Figure 1 is a simplified block diagram illustrating a system for triggering recipient- side events according to the present disclosure.

[0062] Figure 2 is a simplified block diagram illustrating a system for triggering recipient- side events according to the present disclosure where the trigger grants access to a resource.

[0063] Figure 3 is a simplified block diagram illustrating a system for triggering recipient- side events according to the present disclosure where the trigger establishes a P2P

connection.

[0064] Figure 4 is a simplified block diagram illustrating a system for triggering recipient- side events according to the present disclosure where the trigger grants access to an application.

[0065] Figure 5 is a simplified block diagram illustrating a system for triggering recipient- side events according to the present disclosure wherein there are a multitude of resource grants.

[0066] Figure 6 is a simplified block diagram illustrating a system for triggering recipient- side events according to the present disclosure wherein there are a multitude of P2P connections.

[0067] Figure 7 is a simplified block diagram illustrating a system for triggering recipient- side events according to the present disclosure wherein there are a multitude application accesses.

[0068] Figure 8 is a simplified block diagram illustrating a system for triggering recipient- side events according to the present disclosure wherein a trigger is created remotely in a resource-management configuration.

[0069] Figure 9 is a simplified block diagram illustrating a system for triggering recipient- side events according to the present disclosure wherein a trigger is created remotely in an application access configuration.

[0070] Figure 10 is a simplified block diagram illustrating a system for triggering recipient-side events according to the present disclosure wherein a trigger is created remotely and processed remotely in an application access configuration.

[0071] Figure 1 1 is a simplified block diagram illustrating a system for triggering recipient-side events according to the present disclosure further comprising a Client Application Module.

[0072] Figure 12 is an embodiment illustrating a system for triggering recipient-side events according to the present disclosure where the trigger grants access to a resource.

[0073] Figure 13 is an embodiment illustrating a system for triggering recipient-side events according to the present disclosure where the trigger establishes a P2P connection.

[0074] Figure 14 is an embodiment illustrating a system for triggering recipient-side events according to the present disclosure where the trigger grants access to an application.

[0075] Figure 15 is an embodiment illustrating a system for triggering recipient-side events according to the present disclosure where the trigger grants access to an application and there is a Client Application Module.

[0076] Figure 16 is an embodiment illustrating a system for triggering recipient-side events according to the present disclosure where the trigger grants access to an application, there is a Client Application Module and the trigger is created and processed remotely.

[0077] Figure 17 is an embodiment illustrating a system for triggering recipient-side events according to the present disclosure where the trigger grants access to an application and there is an Common Application Server.

[0078] Figure 18 is a block diagram illustrating the internal architecture of the

Kryptiva(TM) components which implement an embodiment of a system for triggering recipient-side events according to the present disclosure.

[0079] Figure 19 is a block diagram illustrating the Kryptiva(TM) components which implement an embodiment of a system for triggering recipient-side events according to the present disclosure wherein two members each use a separate Kryptiva Application Server.

[0080] Figure 20 is a block diagram illustrating the Kryptiva(TM) components which implement an embodiment of a system for triggering recipient-side events according to the present disclosure wherein a non-member uses the Kryptiva Workspace Manager Online.

[0081 ] Figure 21 is a block diagram illustrating the Kryptiva(TM) components which implement an embodiment of a system for triggering recipient-side events according to the present disclosure wherein two members share the same Kryptiva Application Server.

[0082] Figure 22 is a block diagram illustrating the internal architecture of the Kryptiva Application Server which implements an embodiment of a system for triggering recipient-side events according to the present disclosure.

[0083] Figure 23 is a block diagram illustrating a pilot version of the Kryptiva(TM) components which implement an embodiment of a system for triggering recipient-side events according to the present disclosure.

[0084] Figure 24 is a block diagram illustrating the creation of an application packet according to the method for triggering recipient-side events of the present disclosure.

[0085] Figure 25 is a block diagram illustrating the processing of an application packet

according to the method for triggering recipient-side events of the present disclosure.

[0086] Figure 26 illustrates a network diagram of the Kryptiva components with one Kryptiva Application Server.

[0087] Figure 27 illustrates a network diagram of the Kryptiva components with two Kryptiva Application Servers.

[0088] Figure 28 illustrates a network diagram of the Kryptiva components with a hosted Kryptiva Packaging Server and a hosted Kryptiva Application Server.

[0089] Figure 29 illustrates the Microsoft(R) Outlook composition window with the Kryptiva Packaging Plugin.

[0090] Figure 30 illustrates the Kryptiva Packaging Plugin popup for confirming the workspace name.

[0091 ] Figure 31 illustrates the Kryptiva Packaging Plugin popup for setting recipient passwords.

[0092] Figure 32 illustrates the Kryptiva Workspace Manager icon as off.

[0093] Figure 33 illustrates the Kryptiva Workspace Manager icon as on.

[0094] Figure 34 illustrates the main view of the Kryptiva Workspace Manager.

[0095] Figure 35 illustrates the file-sharing view of the Kryptiva Workspace Manager.

[0096] Figure 36 illustrates the screen-sharing, view of the Kryptiva Workspace Manager.

[0097] Figure 37 illustrates the whiteboarding view of the Kryptiva Workspace Manager.

[0098] Figure 38 illustrates the Microsoft(R) Outlook inbox receiving a workspace invite.

[0099] Figure 39 illustrates the Kryptiva Packaging Plugin popup for joining a workspace.

[0100] Figure 40 illustrates the content of Kryptiva workspace invitation email.

[0101 ] Figure 41 illustrates the Kryptiva Workspace Manager Online password page.

[0102] Figure 42 illustrates the Kryptiva Workspace Manager Online file-sharing page.

[0103] Figure 43 illustrates the Kryptiva Workspace Manager Online screen-sharing page.

[0104] Figure 44 illustrates the Kryptiva Packaging Plugin pilot toolbar.

[0105] Figure 45 illustrates the Kryptiva Packaging Plugin pilot popup for starting applications.

[0106] Figure 46 illustrates the Kryptiva pilot applications.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0107] Figure 1 to 1 1 illustrate the system for triggering recipient-side events of the present disclosure. Figures 12 to 17 illustrate possible embodiments of the present disclosure, Figures 18 to 22 and 24 to 43 illustrate the embodiment of the present disclosure by the Kryptiva(TM) components as of the time of this writing, and Figure 23 and 44 to 46 illustrate an early prototypical embodiment of the present disclosure using

the Kryptiva(TM) components. Figures 22 to 25 illustrate possible embodiments of a proof-of-delivery method of the present disclosure. Some components presented may be replaced and others may be added without departing from the teachings of the present disclosure. Where used, dotted arrows indicate a set of possibilities and dotted boxes are used for presenting components for which interactions of inner components with external components and other inner components are illustrated. Details regarding Kryptiva(TM) components illustrated in some figures may be found in co-pending PCT International Publication Number WO 2005/078993, PCT International Publication Number WO 2007/071040 and PCT International Publication Number WO 2007/071041. The following will therefore cover the operation of only those components which are not already described in said publications.

Basic Network Components

[0108] Emails are typically sent from an email transmission module 101 in a sender unit 105 to the email reception module 102 in a recipient unit 106 (arrow 151 ), possibly using a network 107. Typically, the sender unit 105 is any system, device, workstation, server, appliance, computing platform, or hardware capable of transmitting email, regardless of whether it has an active user directly interacting with it at any point in time. One embodiment of the sender unit 105, a sender station 114, is a typical computer system including hardware such as a CPU, or set of tightly-coupled CPUs, RAM, flash, buses, bus controller or controllers, network interface, peripherals and other hardware components, and configured for running software such as an operating system and applications. The sender station 114 may be a fixed computer devices such as a PC workstation running a popular operating system, such as Windows®, MacOS®, or Linux®, or it may be a portable device such as a Blackberry®, Palm® Treo(TM), or a generic device running an embedded operating system, such as Symbian® or Windows® Mobile(TM), or it may be a server system, or a set of aggregated servers, running a server operating system, such as Windows® Server or Red Hat® Linux®, or it may be any such similar system.

[0109] Similarly to the sender unit 105, the recipient unit 106 may be any system, device, workstation, server, appliance, computing platform, or hardware capable of receiving email and preferably, but not necessarily, of browsing the web, regardless of whether it has an active user directly interacting with it at any point in time. One embodiment of the recipient unit 106 is a recipient station 1 15 having similar characteristics as the sender station 1 14.

[01 10] Emails are typically sent from the sender station 1 14 first to the sender mail server 116. The sender mail server 1 16 then transmits the email to the recipient mail server 1 17. The email is then retrieved from the recipient mail server 1 17 by the recipient station 1 15 for presenting to the recipient.

[0111] With regards to the use of the term "remotely", it is hereby noted that for a unit designated as "unit A" to operate "remotely" from a unit designated as "unit B", then data would need cross over a network interface, or an interface similar to a network interface like a USB or FireWire® interface, whether it be physical or virtual, if it were to be transferred back and forth between unit A and unit B; in other words, the services, resources, and/or interfaces of unit B could only be accessed by unit A via a network. Also, it is worth noting that while the present disclosure uses the term "email", it will be evident to those skilled in the art that the present disclosure may be applicable to other forms of communication which resemble email such as, for example, instant messaging and GSM SMS messages.

f 01121 Basic Kryptiva Components:

[01 13] Part of the following discussion is based on the description of the components, products and services marketed by Kryptiva Inc. as presented in in co-pending PCT International Publication Number WO 2005/078993, PCT International Publication Number WO 2007/071040 and PCT International Publication Number WO 2007/071041. It will be understood that numerous modifications and changes in form and detail may be made of the presently disclosed system and method for triggering recipient-side

events. Therefore, the use of Kryptiva components is meant only as an example disclosure. Numerous other embodiments of the present disclosure and other closely related disclosures may be made without departing from the present disclosure's teachings.

[01 14] The basic Kryptiva components are the Kryptiva Mail Operator 127, the Kryptiva Packaging Plugin 125, the Kryptiva Packaging Server 128 and the Kryptiva Online Services 126. Within the Kryptiva components, users are identified as either members or non-members. Members are users who are typically, but not necessarily, personally registered or who belong to an organization that is registered as Kryptiva customer. Non-members, on the other hand, are typically, but not necessarily, individuals who are not registered with, identified to, or otherwise known to Kryptiva.

[01 15] The Kryptiva Packaging Plugin 125 is the primary means by which a user interacts with Kryptiva's cryptographic functionality. Typically, the Kryptiva Packaging Plugin 125 is implemented such that it hooks to the email client application 124's "send" and "receive" functionality. The Kryptiva Packaging Plugin 125 for Microsoft® Outlook, for example, interfaces with Outlook using COM/ATL in order to be notified of specific user actions, such as when the "send" button is pressed or when new emails appear in folder or when an email is "opened" by way of double-clicking. The Kryptiva Packaging Plugin 125 for Mozilla Thunderbird(TM) and other email client application 124s operate in a similar fashion to the Kryptiva Packaging Plugin 125 for Outlook. Amongst other features, the Kryptiva Packaging Plugin 125 allows the user to select the desired Kryptiva functionality during email composition through a Kryptiva toolbar or visual addition to the email composition window of the email client application 124 and interacts with the Kryptiva Mail Operator 127 to provide the selected functionality as needed

[01 16] The Kryptiva Mail Operator 127 is invisible to the user and implements the low- level cryptographic functionalities of signature, signature verification, encryption and

decryption by interacting with the Kryptiva Packaging Server 128 and the Kryptiva Online Services 126. The Kryptiva Packaging Server 128 is the Kryptiva Mail Operator 127 backend and allows providing services for a given Kryptiva member organization. Decryption of data sent using Kryptiva's cryptographic functionality to user within a given organization, for example, is typically authorized through that organization's Kryptiva Packaging Server 128. Each Kryptiva Packaging Server 128 is therefore typically, though not necessarily, exclusive to a given member organization. The Kryptiva Online Services 126, on the other hand, are accessible to all Kryptiva users and have the general role of public key distribution for Kryptiva's cryptographic functionality and of enabling non-member decryption of Kryptiva-encrypted content.

fO1171 Basic Trigger Components

[01 18] The basic trigger components are illustrated in Figure 1 . Typically, though not necessarily, the trigger creation module 103 creates a trigger prior to the email's transmission and causes the trigger to be included within said email. The trigger processing module 104 processes the trigger after the email is received. Both the trigger creation module 103 and the trigger processing module 104 may be composed of a number of modules and may be split in a number of modules. The action of the trigger creation module 103 results in the trigger-enabled email sent by the email transmission module 101 to result in the trigger firing upon being processed by the trigger processing module 104 if and only if the trigger's origin is cryptographically verified and the recipient is able to access the trigger by way of decryption. In other words, either the trigger is itself encrypted and signed or the email containing it is. The end result is that the sender knows that only the designated recipient can access the trigger and the recipient is capable of verifying the trigger's origin as being the sender. Possibly, the recipient is prompted for confirmation before the trigger is fired. Once fired, the trigger grants access to and/or allows the recipient to connect to a remote module, either immediately or later. Furthermore, the trigger's contents can be used to obtain service or access to a service from said remote module. The remote module accessed using the trigger may be part of a remotely-administered resource such as an application server or a remotely-

administered resource management module or it may even be part of the sender unit 105, thereby allowing the establishing of a real-time P2P link between the recipient unit 106 and the sender unit 105.

[P1191 First Set of Embodiments

[0120] The first set of embodiments is exemplified by Figure 2. In this set of embodiments, use of the trigger enables the recipient to gain access (arrow 152) to a remotely-managed resource managed by a managed resource management module 108 which is typically itself comprised in a managed resource management server 1 18. Figure 5 illustrates the case where a sender provides access to a managed resource to a multitude of recipients. Figure 8 illustrates the case where the sender unit 105 includes a trigger creation request module 1 1 1 instead of a trigger creation module 103 and where the trigger creation module 103 operates remotely from the trigger creation request module 111 to provide it with a trigger (arrow 157). Figure 12 illustrates a practical example of the embodiment of the modules illustrated in Figure 2 wherein the recipient station 1 15 is connected to the managed resource management server 1 18 (arrow 161 ). Typically, though not necessarily, managed resources provide recipients with transactional functionality. The present set of embodiments could, for example, be used to transmit Kerberos tokens by email to recipients, thereby enabling said recipients to access servers which typically would only be accessible to the sender. Other examples of the use of this set of embodiments include: sending checks through email (ex.: pay bills in a B2B setting, etc.), sending "approve" / "disagree" forms (ex.: contract signing), sending "ownership" (ex.: Domain transfer, deeds, assets, etc.), sending Fedex(R) packages (ex.: sender only knows recipient's email address, recipient gets form that he fills-in with address and then the package is sent to that address AFTER it was sent out by the sender), sending access to resource (ex.: email an access to a server), submitting RFP on time, send information requests (ex.: "fill this out to process X" and processing is all done automatically), etc.

r01211 Second Set of Embodiments

[0122] The second set of embodiments is exemplified by Figure 3. In this set of embodiments, use of the trigger enables establishing an interactive (in opposition to asynchronous) P2P link between the sender unit 105 and the recipient unit 106 (arrow 153). This, for example, could be used to invite a recipient to a secure chat session. Figure 6 illustrates the case where the sender establishes P2P connections with a multitude of recipients. Possibly in such a configuration exchanges between recipients are possible through the sender unit 105. Figure 13 illustrates a practical example of the embodiment of the modules illustrated in Figure 3 wherein the sender station 1 14 and the recipient station 115 are connected using a P2P link (arrow 162).

IO1231 Third Set of Embodiments

[0124] The third set of embodiments is exemplified by Figure 4. In this set of embodiments, the sender unit 105 is connected to a sender's application module 109 (arrow 154) and the use of the trigger enables the connection of the recipient unit 106 to a recipient's application module 1 10 (arrow 155), where the sender's application module 109 and the recipient's application module 110 may be connected together (arrow 156). Typically, though not necessarily, an "Application" in this context provides interactive functionality to the recipient; in contrast to the previously-discussed managed resources which are transactional in nature - there is a certain amount of overlap between managed resources and applications and, in some circumstances, the modules may be interchangeable. Figure 7 illustrates the case where the sender enables a multitude of recipients to establishes such connections with a recipient's application module 1 10. Figure 9 illustrates the use of a trigger creation request module 1 11 within this set of embodiments. Figure 10 illustrates an embodiment where the recipient unit 106 includes a trigger processing request module 1 12 instead of a trigger processing module 104 and where the trigger processing request module 1 12 obtains trigger processing by contacting a remote trigger processing module 104 (arrow 158). Figure 1 1 illustrates an embodiment where the sender unit 105 and the recipient unit 106 further include a client application module 1 13 for enhanced application functionality on the client side. Figure 14 illustrates a practical embodiment of the modules illustrated in Figure 4 wherein the

sender station 1 14 is connected to a sender's application server 1 19 (arrow 163), where the recipient station 115 is connected to a recipient's application server 120 (arrow 165) and where the sender's application server 119 and the recipient's application server 120 may be interconnected (arrow 164). Figure 15 illustrates a practical embodiment of the modules illustrated in Figure 1 1. Figure 16 illustrates a practical embodiment combining the modules illustrated in Figure 10 and Figure 1 1. Figure 17 illustrates a practical embodiment of the modules illustrated in Figure 11 where the sender's application module 109 and the recipient's application module 110 are combined into a common application module 121 and where the sender's application server 1 19 and the recipient's application server 120 and combined into a common application server 122. - Define "Application"

[0125] Rich applications built on top of the trigger mechanism typically, though not necessarily, have four components (some of these may be combined, implemented within the same body of code, imported automatically from an online source when needed, etc.): a) a sender-side client application module 1 13; b) a sender's application module 109; c) a recipient-side client application module 1 13; and d) a recipient's application module 110.

The sender's application module 109 and recipient's application module 1 10 are typically, though not necessarily, implemented within an sender's application server 119 and a recipient's application server 120, respectively, or together as a common application server 122 as illustrated earlier. There may be a multitude of common application servers 122 involved in servicing a given trigger, some directly servicing the sender, the recipient or another party and some coordinating with other common application servers 22 for provisioning the services, common application servers 122 may be managed internally by an organization or may be provided by a third party.

[0126] Within this configuration, the email client application 124 is made to be the center

piece of the user's access to trigger-driven applications. As such, trigger-driven applications may be seen by the user as additional items within a given email client application 124 email composition toolbar (ex.: Invite to workspace drop-down menu.) It may also be possible that the trigger creation request module 1 1 1 interacts with a background or foreground desktop application which kicks in when needed to interact with the user to provide him access to applications implemented using the trigger mechanism. It is possible that the options visible to the user through his toolbars depend on the applications enabled in the common application servers 122 he is authorized to access, which could be queried for the list of supported and / or available applications.

[0127] Access to common application server 122 services may be done through a variety of ways. In some cases, the common application server 122 may be used to provide tickets for senders to access common application server 122 services. In other cases, common application server 122 services may be accessed by virtue of having been able to access the trigger as part of decrypting an email containing a trigger. Typically, though not necessarily, triggers are embedded at send time in the email body. It is when processing said body on its arrival that, for example, the trigger processing module 104 is made to trigger events on the recipient's system. Obviously, it may be desirable to provide the recipient with ways to control which events in reaction to triggers are permitted. It may also be desirable to provide such control in a federated fashion for use in corporate environments.

[0128] Apart from servicing applications, common application servers 122 may be used as exchange gateways (proxies) between senders and recipients. As such, much of the functionality now found in P2P technologies may be implemented using common application servers 122, except that common application servers 122 may be hosted by companies and can be made to log transiting traffic and ensure exchanges are secure, therefore solving many of the existing problems with P2P technologies: the need for a third party to proxy transmissions, the insecurity of transmission, the fact that data

transmitted cannot be audited, the fact that P2P networks typically require separate identifiers, etc.

[0129] On the client side, a trigger-based application implemented in client application module 113 can typically: a) access email information; b) run code locally (display dialogs, access resources, etc.); c) trigger server-side events / code; d) cause "triggers" to be added to the email; e) make use of local credentials f) etc.

[0130] Typically, though not necessarily, a trigger would at least be made of: a) a common application server's 122 IP address; b) a port number; c) an application ID; and d) an authorization token.

[0131 ] The present set of embodiments can be used to enable: sending huge files (ex.: ISO of latest OS release), sending references to live applications (ex: share application on sender's desktop with recipient, "send" VM on server, remote IT support, CLI on problem server sent to PDA, ...), establishing VoIP links (ex.: call or call transfer through email), sending links to shared workspaces, sending live video feeds (ex.: exclusive new coverage, web cam to cops, security system to human's BlackBerry, ...), requesting authorization (ex.: once authorization is given after opening the email, the access is automatically granted.) Here is a possible call transfer based on the present embodiment: a) transfer to other person (individual email address) or department (department email address), b) recipient gets: VoIP stream, CRM entry, transcript (or recording or both) of earlier conversation with other person (voice recognition software does best effort transcript).

r0132l Fourth Set of Embodiments

[0133] Figures 18 to 22 and 24 to 43 exemplify the fourth set of embodiments. That is, they illustrate the use of the Kryptiva Packaging Plugin 125, Kryptiva Mail Operator 127, Kryptiva Packaging Server 128, Kryptiva Online Services 126, Kryptiva Workspace Manager 129, Kryptiva Application Server 130, and Kryptiva Workspace Manager Online 132 at the time of this writing to provide what Kryptiva markets as the Kryptiva Collaboration Suite. Figure 18 illustrates the location of the previously-discussed modules withing Kryptiva's components. The Kryptiva Packaging Plugin 125, for example, includes the trigger creation request module 1 1 1 and trigger processing request module 1 12. It communicates with the Kryptiva Workspace Manager 129 (arrow 167) for all workspace-related tasks and communicates with the Kryptiva Mail Operator 127 (arrow 166) for all cryptographic operations. The Kryptiva Mail Operator 127 itself communicates with the Kryptiva Online Services 126 (arrow 168) and the Kryptiva Packaging Server 128 (arrow 169) as needed to perform its operations on behalf of the Kryptiva Packaging Plugin 125. The Kryptiva Workspace Manager 129, in turn, includes the client application module 1 13 and the trigger processing module 104 and communicates with the Kryptiva Application Server 130 (arrow 170) as needed to service workspace-related tasks. The Kryptiva Application Server 130 itself includes the common application module 121 and the trigger creation module 103. Figure 19 illustrates the communication between two member users whose Kryptiva Application Server 130es are interconnected (arrow 171 ). Figure 20 illustrates illustrates the communication between a member and a non-member where the non-member uses the Kryptiva Workspace Manager Online 132 (arrow 172) to interact with the Kryptiva Application Server 130 (arrow 173). In that case, the Kryptiva Workspace Manager Online 132 acts as a replacement for the Kryptiva Workspace Manager 129 on the recipient's behalf. Figure 21 illustrates two member users using the same Kryptiva Application Server 130. Figures 26, 27 and 28 illustrate various network layouts of the Kryptiva components. In those figures, Kryptiva Workspace Manager Online 132 is integrated in the Kryptiva Application Server 130.

[0134] To enable collaboration, the Kryptiva Packaging Plugin 125 provides senders with an interface allowing them to invite recipients to workspaces (Figure 29.) This can be a new workspace or an existing one. Once the name of the workspace is confirmed (Figure 30) and the passwords for non-members are set (Figure 31), the Kryptiva Packaging Plugin 125 communicates with the Kryptiva Mail Operator 127 and the Kryptiva Workspace Manager 129 to create an application packet (the "trigger") for sending along with the outbound email. Referring to Figure 24, the application packet is created as follows: a) the Kryptiva Packaging Plugin 125 requests a Kryptiva Application Server 130 ticket from Kryptiva Mail Operator 127 (arrow 177), which it creates by communicating with the Kryptiva Packaging Server 128; b) the Kryptiva Packaging Plugin 125 requests the creation of an application packet (arrow 178) from the Kryptiva Workspace Manager 129, which it creates by communicating with the Kryptiva Application Server 130; c) the Kryptiva Packaging Plugin 125 requests that the application packet be signed and encrypted (arrow 179) from the Kryptiva Mail Operator 127, which it does by communicating with the Kryptiva Packaging Server 128; and d) once received the packed application packet is inserted into the outbound email and the new outbound email is sent by the Kryptiva Packaging Plugin 125 for packaging (signing mainly) to the Kryptiva Mail Operator 127 (arrow 180).

Finally, the new outbound email is sent to the recipient. In addition to the application packet, the outbound email also includes a URL for contacting the Kryptiva Workspace Manager Online 132 in case the recipient does not or cannot have the Kryptiva Packaging Plugin 125 installed. Figure 40 illustrates an example outbound email with a workspace invite.

[0135] Figure 38 illustrates a user's inbox with a Kryptiva workspace invite. Figure 39 illustrates the popup provided by the Kryptiva Packaging Plugin 125 when the email containing the invite is double-clicked, prompted the user for whether he'd like to join the

workspace. Referring to Figure 25, upon opening the email, the Kryptiva Packaging Plugin 125: a) verifies the received email (arrow 183); b) extracts the application packet and sends it for decryption (arrow 184); c) optionally, if the recipient is a member, the Kryptiva Packaging Plugin 125 also requests a Kryptiva Application Server 130 ticket for authoritatively identifying the recipient with the Kryptiva Application Server 130 (arrow 185); and d) the application packet is provided to the Kryptiva Workspace Manager 129 for connecting to the workspace on the Kryptiva Application Server 130 (arrow 186).

The application packet includes:

- The workspace ID (64 bit)

- The workspace name

- The inviter's name

- The inviter's email address

- The Kryptiva Application Server's 130 IP address

- The Kryptiva Application Server's 130 port number

- A random nonce

[0136] To create the Kryptiva Application Server 130 ticket (arrow 177), the Kryptiva Mail Operator 127 connects to the Kryptiva Packaging Server 128 by the usual means, and logs into the Kryptiva Packaging Server 128 with the appropriate credentials. This allow the Kryptiva Packaging Server 128 to bind the connected user to the information it needs for further processing. When the user requests a Kryptiva Application Server 130 ticket, the following information is provided in the ticket and the ticket is signed by the Kryptiva Packaging Server 128 for verification by the Kryptiva Application Server 130:

- Address and port of Kryptiva Application Server 130 server to contact

- Full name of the user logged into the Kryptiva Packaging Server 128

- Primary email address of the user logged into the Kryptiva Packaging Server 128.

- Key ID associated to the logged-in user.

Note that the Kryptiva Packaging Server 128 never communicates directly with the

Kryptiva Application Server 130, although that could be necessary in some cases. The Kryptiva Packaging Server 128 only knows the address and port number of the Kryptiva Application Server 130 because they are part of its configuration. For example, a Kryptiva Packaging Server 128 may communicate with a Kryptiva Application Server 130 so that, or instruct a Kryptiva Packaging Plugin 125 to the effect that, transfers must be done through a local Kryptiva Application Server 130. For example, if a sender sends a trigger which involves data exchange to another Kryptiva member, then while the sender's Kryptiva Application Server 130 may be involved for the outgoing exchange, it would be important to ensure that the recipient's Kryptiva Application Server 130 is also involved in order for his company to be able to track / log / record the exchange being initiated.

[0137] Armed with this ticket, the recipient can connect to the Kryptiva Application Server 130, and so to can the sender using a ticket provided to him by the Kryptiva Packaging Server 128 to that effect. The Kryptiva Application Server 130 then verifies that the tickets are valid and lets all participants in. Once they are connected to the Kryptiva Application Server 130, it's the sole purpose of the Kryptiva Workspace Manager 129 to interface with the Kryptiva Application Server 130 to provide users with the desired functionality. To do this, the Kryptiva Workspace Manager 129 and the Kryptiva Application Server 130 first negotiate a role for the Kryptiva Application Server 130, the basic role is the workspace role. In that role, the Kryptiva Workspace Manager 129 can chat directly sending chat commands, it can also draw directly by sending drawing commands to the whiteboard.

[0138] The Kryptiva Workspace Manager's 129 interface is illustrated in Figures 34, 35, 36 and 37. It basically allows chatting, file-sharing, screen-sharing and whiteboarding. It also uses a blinking tray icon to notify users of new activity in the workspaces. Figure 32 shows the icon as off and Figure 33 shows the icon as on.

[0139] To send or receive files, the Kryptiva Workspace Manager 129 must ask for a file

upload/download, receive a ticket from the Kryptiva Application Server 130 and start a new connection to the Kryptiva Application Server 130. In this new connection, the Kryptiva Application Server 130 role is negotiated for file upload/download and the ticket just received is used for credentials. After that information about what is to be uploaded/downloaded is exchanged, the actual data is transferred.

[0140] For screen-sharing, the Kryptiva Workspace Manager 129 asks the Kryptiva Application Server 130 to start a screen-share. Here too, the Kryptiva Application Server 130 returns a ticket. Then the Kryptiva Workspace Manager 129 starts a fresh connection to the Kryptiva Collaboration Daemon 133 negotiating the role as screen share and sending the ticket for credentials. Then the socket is closed by the Kryptiva Workspace Manager 129. Note that all socket communications between the Kryptiva Workspace Manager 129 and the Kryptiva Collaboration Daemon 133 are done through a custom tool called ktlstunnel which has a number of atypical properties. Prior to th Kryptiva Workspace Manager 129 closing its socket with the Kryptiva Application Server 130, for instance, ktlstunnel has been instructed to be triggered on disconnection by the Kryptiva Workspace Manager 129 to reconnect to another port, that used by the screen- sharing server (a VNC server). At the same time, on the Kryptiva Application Server 130, the connection is made to a VNC proxy (vnc_reflector) which acts as both a client to the host of the session and as a server to the viewers that are connected. This is almost like if asking a secretary to call for a lawyer and asking her to pass the lawyer once she gets through to him. She calls and gets to talk to the lawyer's secretary then they both agree to pass the phone back so that one is talking to the lawyer directly.

[0141] Bascially, every communication between the Kryptiva Workspace Manager 129 and the Kryptiva Application Server 130 are tunneled in ktlstunnel which encrypts the content using SSL. To do this, the Kryptiva Workspace Manager 129 binds to a socket using a random local port, starts ktlstunnel with the Kryptiva Application Server 130 connection info (address+port) and the local port. First ktlstunnel connects to the Kryptiva Application Server 130 then it connect back to the Kryptiva Workspace

Manager 129 on the local port. During that time, the Kryptiva Workspace Manager 129 listens for connections on the local port. One more address:port is passed to ktlstunnel for vnc so that ktlstunnel reconnects to a different service once the negotiation is done.

[0142] Inside the Kryptiva Workspace Manager 129, there's a communication manager that connects to Kryptiva Application Servers 130, sends message to Kryptiva Application Servers 130, receives answer and event from Kryptiva Application Servers 130. All of this is done asynchronously. There's also a base Ul on which applications sit. Those two modules send events to the workspace manager when something happens. If someone is using his user interface and something is propagated from the Kryptiva Application Server 130 then those events are either treated directly by the workspace manager or passed to workspaces. Each application is then responsible for its own events and Ul.

[0143] Referring to Figure 22, the Kryptiva Collaboration Daemon 133 (Kryptiva Collaboration Daemon) is the central component running on the Kryptiva Application Server 130 and is responsible for providing mechanisms to access and interact with the workspaces created by the users of the system.

[0144] A workspace is a virtual location where the users can exchange documents, chat, share presentations, draw diagrams and access other similar functionality in real-time. A Kryptiva Application Server 130 may host a multitude of such workspaces. Any authorized user may create new workspaces and invite the people whom he intends to collaborate with to join the workspace.

[0145] The Kryptiva Collaboration Daemon 133 is composed of a number of modules:

- The client manager module.

- The workspace manager module.

- The database manager module.

- The ticket manager module.

- The Kryptiva Mail Operator 127 manager module.

- A multitude of application-specific handler modules.

[0146] The client manager module is responsible for interacting with the clients which require access to the functionality of the workspaces hosted on the Kryptiva Application Server 130. In this context, a client is a software agent acting on behalf of a user of the system. It is usually, but not necessarily, the Kryptiva Workspace Manager 129 running on the user's workstation.

[0147] When the Kryptiva Collaboration Daemon 133 starts up, the client manager module starts a thread which listens for incoming network connections from the clients. When such a connection is received, the client module begins interacting with the client to determine which functionality the client requires access to. At the end of this negotiation process, the Kryptiva Collaboration Daemon 133 dispatches the client connection to the appropriate module. This may be one of the application-specific modules, or the workspace manager module.

[0148] The workspace manager module provides access to the core operations of the workspaces. These operations include:

- creating a new workspace.

- inviting users to a workspace.

- connecting to a workspace.

- receiving application events.

- accessing an application in a workspace.

[0149] To create a workspace, the client provides the Kryptiva Collaboration Daemon 133 with a workspace creation ticket previously obtained from a Kryptiva Packaging Server 128. The Kryptiva Collaboration Daemon 133 then forwards this ticket to the ticket manager module to validate the ticket. On success, the Kryptiva Collaboration Daemon 133 interacts with the Kryptiva Application DB 134 (arrow 176) to create a new

workspace. This involves obtaining a unique identifier for new the workspace and the creation of the appropriate tables and data in the database. The identity of the creator of the workspace is also inserted in the user table of the workspace. The Kryptiva Collaboration Daemon 133 then returns the unique identifier of the workspace to the client.

[0150] To invite users to a workspace, the client firsts connect to the workspace in which the users shall be invited. The client then supplies the identity of the users to invite to the workspace. The identity of a user consists in his name, if it is known by the client, his email address, and an authorization token. If the user is a member, the authorization token is the unique identifier of the Kryptiva Application Server 130 of the user. If the user is not a member, the authorization token is a password. The Kryptiva Collaboration Daemon 133 then stores the information provided by the client in the user table of the workspace.

[0151] To join a workspace, the client provides the Kryptiva Collaboration Daemon 133 with the unique identifier of the workspace and its credentials. The credentials consist in the name of the user, his email address, and either a workspace joining ticket or a password.

[0152] If the user is a member, the client will likely provide the Kryptiva Collaboration Daemon 133 with a workspace joining ticket previously obtained from the user's Kryptiva Packaging Server 128. This ticket contains the list of the email addresses of the user. The Kryptiva Collaboration Daemon 133 uses this list of email addresses to locate the entry corresponding to the user in the user table of the workspace. An entry corresponds to the user if the email address field of the entry matches one of the email addresses of the user. If such an entry is found, the Kryptiva Collaboration Daemon 133 validates the ticket using the ticket validation module. If the ticket is valid, the user is authorized to connect to the workspace.

[0153] If a password was provided instead of a workspace joining ticket, the Kryptiva Collaboration Daemon 133 locates the entry corresponding to the user in the user table of the workspace by using the email address of the user. If such an entry is found, the Kryptiva Collaboration Daemon 133 compares the password provided by the client and the password stored in the entry. If the passwords match, the user is authorized to connect to the workspace.

[0154] If the user is authorized to connect to the workspace, the Kryptiva Collaboration Daemon 133 adds the identifier of the workspace being connected to in the list of connected workspaces associated to the client.

[0155] To receive application events in a workspace, the client provides the Kryptiva Collaboration Daemon 133 with the sequence number of the last event it has received from the Kryptiva Collaboration Daemon 133 for this workspace in a previous session. The Kryptiva Collaboration Daemon 133 then retrieves the events in the database whose sequence number is superior to the sequence number provided by the client. Furthermore, the Kryptiva Collaboration Daemon 133 instructs the database module to actively retrieve the events generated by the other users of that workspace starting from this point in time. When such an event is retrieved, it is immediately sent to the client. The client then receives the events of the workspace as they are posted by the other instances of the Kryptiva Collaboration Daemon 133.

[0156] To access an application in a workspace, the client provides the Kryptiva Collaboration Daemon 133 with the identifier of the workspace, the identifier of the application and a operation to execute in the application. The Kryptiva Collaboration Daemon 133 then validates if the client is connected to the workspace and dispatches the request of the client to the appropriate application-specific module. The module receiving the client's request then verifies if the client is authorized to perform the operation and executes the operation on behalf of the client. The results of the operation are returned to the client.

[0157] Possibly, one or more events are generated and posted in the database for the benefit of the other users of the workspace. Possibly, a ticket is generated by the ticket manager module and returned to the client to allow the client to reconnect to the Kryptiva Collaboration Daemon 133 under a special identity to perform further application-specific operations with a higher quality of service.

[0158] The database module is responsible to manage the interactions with the databases associated to the workspaces. For scalability and reliability purposes, the workspaces may be backed by several databases.

[0159] The ticket manager module is responsible for validating and creating tickets which allow the clients to access some functionality of the Kryptiva Collaboration Daemon 133. To validate a ticket generated by a Kryptiva Packaging Server 128, the Kryptiva Collaboration Daemon 133 extracts the identifier of the Kryptiva Packaging Server 128 included in the ticket. Using the Kryptiva Mail Operator 127 manager module, the Kryptiva Collaboration Daemon 133 retrieves the encryption key which corresponds to identifier extracted from the ticket (arrow 174). The Kryptiva Collaboration Daemon 133 validates that the ticket is correctly signed with this key. If the ticket is a workspace creation ticket, the Kryptiva Collaboration Daemon 133 verifies if the identifier extracted from the ticket corresponds to a Kryptiva Packaging Server 128 whose users are authorized to create workspaces on the Kryptiva Application Server 130. If the ticket is a workspace joining ticket, the Kryptiva Collaboration Daemon 133 verifies if the identifier extracted from the ticket matches the identifier of the Kryptiva Packaging Server 128 stored in the entry of the user table which corresponds to the user who is trying to join the workspace.

[0160] To create a ticket to allow the client to reconnect to the Kryptiva Collaboration Daemon 133 with a higher quality of service, the Kryptiva Collaboration Daemon 133 generates a message which contains a long random number, the identifier of the

application to access and the credentials of the user. This message is formatted appropriately to create a ticket. The Kryptiva Collaboration Daemon 133 stores this ticket in the database and returns it the client.

[0161] To validate a ticket created in the previous step, the Kryptiva Collaboration Daemon 133 lookups the ticket in the database. If an exact match is found, the ticket is accepted and deleted from the database to prevent it from being used again.

[0162] The Kryptiva Mail Operator 127 manager module manages the interaction with the Kryptiva Mail Operator 127. It executes the operations requested by the other modules of the Kryptiva Collaboration Daemon 133 and returns the results of the operations to those modules.

[0163] The application-specific modules contain the logic required to implement each application provided by the Kryptiva Collaboration Daemon 133. These modules can be accessed either through the workspace manager module or directly by the client by reconnecting to the Kryptiva Collaboration Daemon 133 with a ticket generated for that purpose. In the latter method, the Kryptiva Collaboration Daemon 133 forks a new process to handle the interactions with the client, which helps the Kryptiva Collaboration Daemon 133 respects the real-time constraints of applications such as desktop-sharing.

[0164] The Kryptiva Workspace Manager Online 132 is similar is terms of functionality to the Kryptiva Workspace Manager 129. The Kryptiva Workspace Manager Online 132 is accessed by clicking on a URL contained in a Kryptiva email containing a workspace. The URL contains an identifier which allows the Kryptiva Workspace Manager Online 132 to identify the workspace being accessed by the user. Upon clicking on that URL, the user is brought to a page which asks the user for his password (Figure 41 ).

[0165] The Kryptiva Workspace Manager Online 132 validates the password provided by the user by interacting with the Kryptiva Collaboration Daemon 133. The Kryptiva

Workspace Manager Online 132 then performs essentially the same operations as the Kryptiva Workspace Manager 129. Figure 42 illustrates the file-sharing view of the Kryptiva Workspace Manager Online 132 and Figure 43 illustrates the screen-sharing functionality.

[0166] Here are some more enhancements and possibilities:

- Presently the Kryptiva Workspace Manager 129 is separate from the email client application 124. The Kryptiva Workspace Manager 129 could, however, be an integral part of the email client application 124 like the Kryptiva Packaging Plugin 125.

- The recipient-side Kryptiva Workspace Manager 129 can be made to query the Kryptiva Application Server 130 for additional applications. This could allow presenting a popup to the recipient requesting whether or not he'd like new applications to execute.

- The recipient-side Kryptiva Workspace Manager 129 may be made to get the recipient- side client application (either in pure binary or in byte code or otherwise) from the Kryptiva Application Server 130. Said applications may of course need to be properly signed in order to avoid abuse.

- Applications could be "embedded" or "linked-to" from within the application packet. Such applications could be run directly or within virtual machines or sandboxes.

- It could be possible to have an HTTP proxy running locally for running specially- designed webpages for displaying in a browser. This would allow reusing existing web applications while avoiding the hassle of the recipient having to create an account on a web server prior to having access to the application. Instead, by virtue of having access to the trigger, the recipient immediately reaches the appropriate web location.

[0167] As is described above, applications could run like plugins to the Kryptiva Packaging Plugin 125 and the Kryptiva Workspace Manager 129, much like Flash Player, Realplayer, Acrobat and others integrate into a web browser. In effect, by using Kryptiva Application Server 130es, the Kryptiva infrastructure then becomes an engine for building additional functionality through plugins to existing Kryptiva components. In other words, the Kryptiva Packaging Plugin's 125 reactions to triggers could be

extended by having plugins to it, and the same goes for the Kryptiva Workspace Manager 129.

r01681 Fifth set of embodiments

[0169] Figures 23 and 44 to 46 exemplify the fifth set of embodiments. That is, they illustrate the use of the Kryptiva Packaging Plugin 125, Kryptiva Mail Operator 127, Kryptiva Packaging Server 128, Kryptiva Online Services 126, and Kryptiva Application Server 130 at the time of an early prototype of this disclosure. Figure 23 illustrates a Kryptiva Packaging Plugin 125 taking the role of the present-day Kryptiva Workspace Manager 129. Figure 44 illustrates the Kryptiva Packaging Plugin 125's toolbar which required selecting the applications before the email was sent. Figure 45 illustrates the opening of the email with the applications and Figure 46 illustrates a user's screen with the applications open.

[0170] It will be understood that numerous modifications and changes in form and detail may be made to the embodiments of the presently disclosed system and method for triggering recipient-side events. It is contemplated that numerous other configurations of the system and method may be used, and the modules of the system and method may be selected from numerous modules other than those specifically disclosed. Therefore, the above description should not be construed as limiting the disclosed system and method, but merely as exemplification of the various embodiments thereof. Those skilled in the art will envisioned numerous modifications within the scope of the present disclosure as defined by the claims appended hereto. In short, it is the intent of the Applicant that the scope of the patent issuing herefrom will be limited only by the scope of the appended claims. Having thus complied with the details and particularity required by the patent laws, what is claimed and desired protected is set forth in the appended claims.