Abstract:
A new system and method have been invented to allow a sender/author/user who wishes to send e-mail or a calendar meeting document to someone and make it available to her or his assistant or manager without the need of the sender/author/user finding out who the assistant or manager is. That is, the system and method of the present invention allows the sender/author/user to choose a select number of recipients or even the role who are able to decrypt the email/attached document. Further, the new system and method provides a sender/author/user to choose which level of authority each user or user role.

Description:
FIELD OF THE INVENTION 
       [0001]    The invention relates generally to encrypting data, and, more particularly, to a system and method for encrypting data so that named recipients, as well as certain derivable unnamed recipients, may have the ability to receive and decrypt the encrypted content. 
       BACKGROUND OF THE INVENTION 
       [0002]    Encryption, or the process of converting ordinary information (“plaintext”) into something unintelligible (“ciphertext”), has been used for centuries to allow a user/sender/author to convey sensitive or confidential information to other parties so that such information, if intercepted by another who is not intended to receive or to read the information, is unintelligible to the unintended recipient. The encrypted information, data or content, once received by the intended parties, must be decrypted in order for the intended parties to understand the information. Decryption is the reverse from encryption and is the process of moving the encrypted information from the unintelligible ciphertext back to plaintext. 
         [0003]    Cryptography has been important over the years but maybe never more critical than in this modern era of electronic communication. For example, in the present day, people work and operate in an environment of sending and receiving much information—in the form of, e.g., emails, text messages, instant messages, blogs or other web communications. It is not unusual for a worker to rarely pick up a pen or pencil as much work is done online. Further, the speeds and bandwidths available today allow for many electronic files to be easily sent or transferred from a sender to one or more intended recipients. This has made industry much more efficient. 
         [0004]    However, there is an increased risk that an electronic file will be intercepted by an unintended recipient. Due to the proliferation of wireless communications, this risk has increased in recent years. 
         [0005]    The inadvertent disclosure of data can pose a serious issue such as by exposing a company&#39;s trade secrets or other confidential information to a party who may use it to the company&#39;s disadvantage. As such, many times, a sender will choose to encrypt the content prior to sending. 
         [0006]    Encryption forms and levels vary in forms of complexity as well as ease of use. For instance, an electronic file (e.g., such as a word processing document) may be encrypted by the author utilizing the application&#39;s (e.g., work processing application) encryption mechanism. By way of example, in a most basic form, an author may password protect an electronic file (the password being used as the cipher to the encrypted file, the application having an encryption algorithm to transform the plaintext into ciphertext), send the encrypted file, and convey the password to the recipients by way of a separate manner—such as by telephone or a separate email. The recipients then, when opening the file and being challenged for the password may use the password to open the encrypted file. This is well-known as are other forms of cryptography such as symmetric key cryptography and public key (Diffie-Hellman or asymmetric key) cryptography. 
         [0007]    There are many levels of encryption. For instance, a database can be encrypted, a file or document can be encrypted as noted above, or a field can be encrypted. 
         [0008]    The most popular level of information to encrypt is e-mail as it is most prolific form of electronic communication. For many people, e-mail is often a substitute for a real conversation. Therefore, similar to the real world where one can shut the door and have a private conversation, e-mail correspondence needs the same capability. To accommodate this need, many email clients provide the ability to encrypt mail before a user sends it, after the user receives it, or before the user saves it. One example of a very popular and highly successful email client is IBM&#39;s Lotus® Notes® client which works in conjunction with IBM&#39;s Lotus® Domino server software. A description of Lotus Notes and Lotus Domino can be found here: http://www-142.ibm.com/sofrware.sw-lotus/products/product4.nsf/wdocs/noteshomepage?OpenDocument&amp;ewesite=notes 
         [0009]    Email client software is installed on a client computer  520 , seen in  FIG. 5 , and works in conjunction with server software installed on the server shown as numeral  540  in the  FIG. 5 . In the basic installation, the client computer  520  communicates with server  540  as well as other computers  534 ,  534 A,  534 B  534 C. 
         [0010]    An email client may use a form of the public key encryption noted above. For mail encryption, a user encrypts a mail message before he/she sends the message, Notes uses the recipient&#39;s public key to transform the plaintext of the message body to ciphertext. Once received, the recipient&#39;s private key decrypts the message. The private key is part of the user&#39;s ID file. Therefore, without the right ID file, the message body looks like gibberish. Of course, messages aren&#39;t safe if that ID file is lost or stolen; however, if the ID owner has applied a password (one that is difficult to guess, such as a string of random alpha-numeric characters) to his ID file, encrypted messages remain safe. 
         [0011]    An example of the UI which allows a user to make such selections is shown in  FIG. 1  where a user can encrypt mail before he sends it through a manual option, or automatically by selecting the encryption setting in his user preferences. To use the manual setting: 
       1. The user opens the message he wants to send in edit mode; 
     2. The user chooses Actions—Delivery Options (the pictorial shown as  100  in FIG. 1); 
     3. The user selects the Encrypt option  102 ; and 
     4. The user then clicks OK  104 . 
       [0012]    The message is encrypted using the encryption algorithm of the email client. This option applies to the current message; future messages are not encrypted unless this delivery option is selected. If, however, the user wishes all outgoing messages encrypted automatically, and the email client allows that option, the user makes the following user preference selection as shown in  FIG. 2 : 
       1. Choose File—Tools—User Preferences. 
     2. Select Mail in the User Preferences dialog box shown in the UI screen  200   
     3. Select Encrypt sent mail  202 . 
     4. Click OK  204 . 
       [0013]    Once this option is set, the email client encrypts all outgoing messages. If the recipient&#39;s public key is not available, which is often the case for Internet mail, a warning message may appear. This message allows the user to continue sending this message or cancel it. 
         [0014]    Incoming messages may also be encrypted. For instance, in Lotus Notes, this option is found in the user&#39;s Person document in the Public Address Book. To encrypt all incoming mail, a user performs the following steps (as shown in  FIG. 3 ): 
       1. Open the Public Address Book. 
     2. Open the user&#39;s Person document  300   
       [0000]    
       
         
           
             3. Click the Edit person button. 
           
         
       
     
       4. In the “Encrypt incoming mail” field  302 , select Yes. 
       [0016]    Enabling this option automatically encrypts all received mail with the user&#39;s public key. Decryption relies on the user&#39;s private key, which is part of the user ID file. 
         [0017]    The previous description provides some background to the email encryption/decryption process in an email system. One of the problems of the present day encryption systems, however, is that only the listed recipients are able to decrypt the email message or calendar invitation. This is a problem as it is often the case that the author wants the data to be readable by additional parties. The most typical case of this is to allow an executive&#39;s administrative assistant or the recipient&#39;s manager to also read the encrypted data. 
         [0018]    The state of the art is cumbersome. Presently, if a user wishes, for example, to send e-mail or a calendar meeting document to someone and make it available to his or her assistant or manager, the user needs to first identify who his or her assistant or manager is (typically by searching a user interface for a directory) and then enter the assistant&#39;s or manager&#39;s name as an e-mail recipient to allow them to read the mail. This is wasted effort to locate the name. It is also unnecessary for the assistant or manager to actually receive the e-mail in his or her own mailbox because the assistant or manager many times reads the mail directly out of the executive&#39;s mailbox. 
         [0019]    An alternative approach is for the assistant or manager to use the principal&#39;s/executive&#39;s credentials, i.e, use his or her password. This behavior is prohibited by many organizations for numerous security reasons. For instance, it allows the assistant or manager to impersonate the principal in sending emails as well as in signing the communications. Additionally, it may allow the administrative assistant or manager to read documents he or she is not authorized to read. That is, it doesn&#39;t give the author/sender control allowing some messages to be read by the assistant or manager and others to be protected from the assistant or manager. 
         [0020]    Another alternative approach, which allows the assistant to read incoming messages without allowing the assistant to send outgoing messages under the premise that it is from the principal, is for the assistant and the principal to share an encryption public/private key but not to share a signing public/private key. This is only available in some software systems (most systems combining the encryption and signing credentials into a single credential). This solves the impersonation problem but still does not solve the granularity problem. That is, it doesn&#39;t give the author/sender control allowing some messages to be read by the assistant, some messages to be edited and replied to by the assistant while others to be protected from the assistant. 
         [0021]    In view of the foregoing, a need exists to overcome these problems by providing a system and method for an end user to encrypt an email or other data and send that communication to a recipient, and to choose specific people and/or roles who should be able to read the content in the email or communication. 
       SUMMARY OF THE INVENTION 
       [0022]    The invention is to provide a system and method which allows an author to encrypt content and to allow the author to specify particular parties who shall have authorization to access the content. The system and method of the present invention shall further allow the author to specify related parties or particular roles which shall have the authorization to access the content. 
         [0023]    The system and method of the present invention further allows the user to select the granularity of authorization for a particular recipient, related parties or particular roles. For instance, an author may choose to give the role of administrative assistant the authority of to read one email or other document but choose not to give the role the ability to read another. 
         [0024]    In one embodiment of the present invention, the author/sender can elect to allow the related parties of explicit names/parties to read the encrypted data when encrypting content. Alternatively, the author/sender can elect to not allow the related parties of explicit names/parties to read the encrypted data when encrypting content. 
         [0025]    In a second embodiment, the system and method allow the author to automatically allow parties who are related to the explicitly listed names in the “encrypted for” list when encrypting data by choosing the related parties. In the preferred embodiment, a checkbox in the UI when sending encrypted e-mail of whether to “Allow Reading by Recipient&#39;s Assistants” or alternatively to choose a role of a party who has some or all access rights. 
         [0026]    In a third embodiment, the system and method allow the author to create a personal contact record so that the system and method will automatically allow encrypt for parties identified in the personal contact record and in the manner specified in the personal contact record. For example, the personal contact record may specify that “whenever I encrypt for Joe Smith, also automatically include a key for Mary Jones”. 
         [0027]    The system of the present invention comprises a UI interface for receiving the author&#39;s input choices as to the parties having various levels of authorization, a name parsing mechanism which identifies and verifies the names chosen by the author/sender, a role identification module for receiving the roles having some level of authorization which are associated with the identified recipients, a look up module to identify and verify the parties which are associated with the authorized recipients, and an authorization module to authorize the associated parties or roles to access the encrypted content. 
         [0028]    In another embodiment, if the user indicates to include the additional parties, their names can be automatically obtained from canonical sources such as a LDAP lookup of the “assistant” field on the executive&#39;s/recipient&#39;s directory record. Their names can then be included in the “encrypted for” list resulting in the data being readable by the additional party, typically by including the assistant&#39;s public key when encrypting the data. 
         [0029]    This approach allows an author to have control over who can read the content, easily allowing reading by assistants and other related parties which is a common use case. 
         [0030]    There are multiple mechanisms for obtaining the data necessary to encrypt for the additional party. There are also multiple UI mechanisms that could be used to indicate to include additional parties. 
         [0031]    For the UI, the indication could be a setting for the entire document (i.e., add the assistant for all the recipients) or it could be a setting chosen for each recipient. The setting could also be a sticky preference or set each time authoring. 
         [0032]    For the retrieving the data, the additional name(s) would typically be done by a directory lookup by a central directory. These lookup could be for the “assistant” or it could be a specially created field in the directory indicating the “additional encrypted readers” for a user. 
         [0033]    The information could also (either alternatively or in addition) come from local data, such as a personally created contact record where a user indicates “whenever I encrypt for Joe Smith also automatically include the key for Mary Jones”. 
         [0034]    Alternatively, one could also include in the executive&#39;s directory record the additional public key to use (assuming public key encryption) when encrypting data for the executive rather than actual additional person names. With this mechanism, multiple assistants who all have access to the private key for the additional public key could each decrypt the data. The advantage of this mechanism is that it is easier to encrypt for a group of people (such as assistants) where the actual membership changes over time. 
         [0035]    Additionally, when sending an encrypted message that includes additional parties not in the recipient list (such as administrative assistants), the message could contain the names of the additional parties (either retrievable from the encrypted info/keys in some encryption schemes or explicitly added by means such as “X-header” extensions to the message) so that any “reply with history” could continue to be decryptable by the additional parties if the person creating the “reply with history” so desired. 
         [0036]    In another embodiment, a document such as an Excel spreadsheet is encrypted on a single machine by listing the names of the people who can decrypt it and checking the “and their executive assistants” checkbox. 
         [0037]    The illustrative aspects of the present invention are designed to solve one or more of the problems herein described and/or one or more other problems not discussed. 
     
    
     
       BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS 
         [0038]    These and other features of the invention will be more readily understood from the following detailed description of the various aspects of the invention taken in conjunction with the accompanying drawings that depict various embodiments of the invention, in which: 
           [0039]      FIG. 1  is a pictorial diagram showing a prior art user interface challenge or pop-up for a user or author to elect to encrypt or not encrypt content prior to transmission. 
           [0040]      FIG. 2  is another pictorial diagram showing a prior art user interface challenge or pop-up for a user or author to elect to encrypt or not encrypt content prior to transmission. 
           [0041]      FIG. 3  is another pictorial diagram showing a prior art user interface challenge or pop-up for a user or author. 
           [0042]      FIG. 4  is a pictorial diagram of an executive&#39;s directory record. 
           [0043]      FIG. 5  is a pictorial diagram showing a computer system user which interacts with other computers through a network; 
           [0044]      FIG. 6  is a pictorial diagram showing a network and the sender and the intended recipients and authorized roles. 
           [0045]      FIG. 7  is a pictorial diagram showing the user interface of an email message having the UI elements for making encrypted content available to derivable related parties. 
           [0046]      FIG. 8  is a pictorial diagram showing a example directory record. 
           [0047]      FIG. 9  shows a flowchart of a method of the present invention. 
           [0048]      FIG. 10  shows a flowchart of another method of the present invention. 
       
    
    
       [0049]    It is noted that the drawings are not to scale. The drawings are intended to depict only typical aspects of the invention, and therefore should not be considered as limiting the scope of the invention. In the drawings, like numbering represents like elements between the drawings. 
       DETAILED DESCRIPTION OF THE INVENTION 
       [0050]    As used herein, unless otherwise noted, the term “set” means one or more (i.e., at least one) and the phrase “any solution” means any now known or later developed solution. Additionally, the term “data store” means any type of memory, storage device, storage system, and/or the like, which can temporarily or permanently store electronic data, and which can be included in a storage and/or memory hierarchy (collectively referred to herein as a “memory hierarchy”) for a computer system. 
         [0051]    With reference to the accompanying drawings, a detailed description of the present invention will be provided.  FIG. 5  is a block diagram showing the components of a general purpose computer system  520  connected to an electronic network  500 , such as a computer network. The computer network  500  can also be a public network, such as the Internet or Metropolitan Area Network (MAN), or other private network, such as a corporate Local Area Network (LAN) or Wide Area Network (WAN), or a virtual private network (VPN). As shown in  FIG. 5 , the computer system  520  includes a central processing unit (CPU)  525  connected to a system memory  515 . The system memory  515  typically contains an operating system  516 , a BIOS (basic input/output system) driver  518 , and application programs  522 . Operating System (OS)  516  may be one of many operating systems such as those for personal computers as Linux, Microsoft Windows, Mac and Unix. (An OS is a software program that manages the hardware and software resources of a computer and performs basic tasks, such as controlling and allocating memory, prioritizing the processing of instructions, controlling input and output devices, facilitating networking, and managing files.) In addition, the computer system  520  contains input devices  524  such as a mouse and a keyboard  532 , and output devices such as a printer  530  and a display monitor  528 . 
         [0052]    The computer system generally includes a communications interface  526 , such as an Ethernet card, to communicate to the electronic network  500 . Other computer systems  534 ,  534 A,  534 B and  534 C may also be connected to the electronic network  500 . One skilled in the art would recognize that the above system describes the typical components of a computer system connected to an electronic network. It should be appreciated that many other similar configurations are within the abilities of one skilled in the art and all of these configurations could be used with the methods of the present invention. 
         [0053]    Furthermore, one skilled in the art would recognize that the other computer systems  534 B and  534 C could consist of a database server and/or an application software server connected to databases  536 A/ 536 B and  536 C, respectively for performing tasks requested by computer  520  or other computers  534  and  534 A. Further, other computers  534  and  534 A, in this example, could be personal computers assigned to other personnel within the company or organization. 
         [0054]    In addition, one skilled in the art would recognize that the “computer” implemented invention described further herein may include components that are not computers per se but include devices such as Internet appliances and Programmable Logic Controllers (PLCs) that may be used to provide one or more of the functionalities discussed herein. Also, computer or computer-like devices and communication devices may include PDAs or personal digital assistants (e.g., Blackberries) or cellular phones. Furthermore, “electronic” networks are generically used to refer to the communications network connecting the processing sites of the present invention, including implementation by using optical or other equivalent technologies. 
         [0055]    One skilled in the art would recognize that other system configurations and data structures and electronic/data signals could be provided to implement the functionality of the present invention. All such configurations and data structures are considered to be within the scope of the present invention. 
         [0056]    Within the network  500  of  FIG. 5 , represented by a cloud, in the preferred embodiment, the Lotus Domino server  540  resides and is connected to computer  520 , and other computers  534 ,  534 A,  534 B, and  534 C. It should be noted that one skilled in the art would recognize that the server  540 , while residing in the network cloud  500  of the present example, could be connected to any computer directly, by way of one or more interconnected corporate network or one or more Internet network and it will still perform in the same manner. As noted above, in the preferred embodiment, the server  540  of the present invention is an IBM® Domino® Server. In addition, in the preferred embodiment, the computers ( 520 ,  534 ,  534 A,  534 B and  534 C) each have an IBM® Lotus Notes® client application installed thereon so that the server  540  and the computers ( 520 ,  534 ,  534 A,  534 B and  534 C) may communicate utilizing specified protocols and functions. For the purposes of this application, these will be called “Email clients”  542 . More information may be obtained regarding IBM Lotus Domino and Notes software at www.ibm.com or, more specifically, at http://www-142.ibm.com/software/sw-lotus/products/product4.nsf/wdocs/noteshomepage?OpenDocument&amp;ewesite=notes. 
         [0057]    According to the present invention, user at computer  520  communicates with other computers  534 ,  534 A,  534 B and  534 C via well known networking protocols and systems. And, it is well known that an email or other e-communication may be encrypted or decrypted. Generally, this is typically done by listing the recipients of the e-mail (To, CC, BCC) and marking the e-mail to be encrypted (with a mark in a checkbox or similar gesture). While it is sometimes the case that the author wants the encrypted data to be readable solely by the listed parties, it is often the case that the author wants the data to be readable by additional parties. The present state of the art is cumbersome as was discussed in the background of the invention. The present invention solves by providing an easy way to allow an author/sender to add additional encrypted readers (typically having a relationship with one of the recipients) and the invention provides other advantages. 
         [0058]    Referring again to the figures,  FIG. 6  illustrates a network having numerous clients  621 ,  685 A,  685 B,  685 C,  685 D. These clients are similar to the components to  FIG. 5  and have the basic components of any computer system known today such as the OS, memory, applications, I/O components—among other functions. However, there are significant distinctions to be explained in great detail below. 
         [0059]    In  FIG. 6 , computer  621  is connected to network cloud  600 . Computer  621 , as shown in the  FIG. 6 , comprises an associating module  640 , a UI module  650 , a deriving module  660 , a look up module  620 , an encryption module  630 , an email client  665 , a local directory table  610 , a name parser  634 , a role identification module  636 , and an authorization module  632 . Each and all of these modules can be in software form or hardware form in the computer system and are connected to one another. 
         [0060]    The email client  665 , sometimes also called a mail user agent (MUA), is a computer program that is used to read and send e-mail. There are many different types of email clients, such as IBM Lotus Notes, Mozilla Thunderbird, and Microsoft Office Outlook. Most email clients use the Simple Mail Transport Protocol (SMTP) to send emails. 
         [0061]    UI (user interface) module  650  is the aggregate of means by which people (the users) interact with a particular machine, device, computer program or other complex tool (the system). The user interface provides means of input, allowing the users to manipulate the system, and output, allowing the system to produce the effects of the users&#39; manipulation. An example of a UI for an email client is shown in  FIG. 7 . 
         [0062]    UI  700  illustrates the familiar fields of a user interface. Command line  702  allows a user to select commands associated with the email client (in the present example) such as “File”, “Edit”, “View” etc. The command bar may be editable so that the user may customize which commands are available on the command bar. Each command, such as “File”, may be a drop-down—allowing the user to select further options. The command selections are used by the application to take actions on the document which the user is working on. 
         [0063]    Basic icon bar  704  has numerous icons which pictorially illustrate an action which a user may wish to select and take. For example, a user may wish to print the document being worked on. If the user selects the icon having the printer pictorial ( 740 ), the printer component is enabled and interacts with a printer driver and the document is printed. Other well known icons may be “Open Document”  742  or “File Save”  744 . 
         [0064]    Command line  706  is more specific to the application which the user is using. For instance, at the far left, is the “Send” command button  705  which would be specific to an email client such as the Lotus Notes or Microsoft Office Outlook email clients. Other command buttons are shown to the right of the Send button, such as a paper clip pictorial icon  746  which indicates an attachment to the email document. 
         [0065]    Input fields  708 ,  710  and  712  receive intended specifically named recipient data from the sender/user/author. The specifically named recipients are those persons who the sender wishes to receive and have the ability to decrypt the content. The specifically named recipients could be direct recipients (in field  708 ), or carbon copied recipients (in field  710 ) or blind carbon copied recipients (in field  712 ). 
         [0066]    Subject field  714  allows the user to identify the subject of the email. Content field  716  allows the user to input the information. 
         [0067]    The “open book” icon  728 ,  730 ,  732  indicates a look up capability is available to the user. The open book icon, generally located directly to the left of the associated addressee field, as shown in  FIG. 7 , allows the user to select that capability. 
         [0068]    It should be noted that the look up capability—that is the examination of the specific named addressee information, using that information to discover the email addresses of the specific named addressees, and auto-populating the addressee fields—is different than the associating capability of the present invention. 
         [0069]    Also, new to this invention, check boxes  750  and  752 . Checkbox  750  allows the sender to quickly choose to encrypt the email for all named recipients and checkbox  752  allows the sender to quickly choose to allow reading by each recipient&#39;s assistant. This user interface feature of the present invention allows an author to indicate whether to automatically add related parties to the explicitly listed names in the “encrypted for” list (in this case the named recipients) when encrypting data. 
         [0070]    If the user interface indicates to include the additional parties, their names can be automatically obtained from canonical sources such as a LDAP lookup of the “assistant” field on the executive&#39;s/recipient&#39;s directory record. Their names can then be included in the “encrypted for” list resulting in the data being readable by the additional parties, typically by including the various assistants&#39; public keys when encrypting the data. 
         [0071]    This approach allows an author to have control over who can read the content, easily allowing reading by assistants and other related parties which is a common use case. 
         [0072]    Drop-down boxes  754  and  756  allow the author to have more granular control over which recipients&#39; assistants (or other role) are additional encrypted readers and their names are included in the “encrypted for” list. The setting could also be a sticky preference. 
         [0073]    It should be noted that the recipient&#39;s assistant is the most typical scenario in today&#39;s business but certainly it could be another party, such as a manager, a peer, a person who assists the recipient but is not technically his/her assistant, and so forth. It also should be noted that this is being discussed in the context of email but the invention applies to other types of files as well, such as calendar invites, office productivity tool files (e.g., a Microsoft Excel spreadsheet) and others. In the case of the example of the office productivity tool files like a Microsoft Excel spreadsheet, these files do not necessarily need to be transmitted but can remain local to a machine as many times multiple users share the machine and the file can be encrypted on the single machine by listing the names of the people who can decrypt it and checking the “and their executive assistants” checkbox. 
         [0074]      FIG. 8  shows an example of a Directory Record  800 . At  802 , a “Name” field filled with a name such as “Mary Smith” at field  801  identifying the owner of the record. Email address  804  receives an email address in field  805  such as “Mary Smith hotmail.com”. At  806 , “Serial Number” could be filled with a serial number as “123456” at  807 . At  808 , there may be information associated with the user such as the user&#39;s address “1 Maple Street, Anywhere, USA” in  809 . Field  810  identifies or associates the person with a role  810  based upon the Role Identification noted in field  812 . 
         [0075]    As shown in  FIG. 4 , an example of an executive&#39;s directory record  400  has similar fields as the directory record of  FIG. 8 , such as name  401 / 402 , email address  404 / 405 , serial number  406 / 407 , address  408 / 409  and role information  410 / 412 . In addition, it has three additional fields: additional encrypted readers  414 / 418 , additional public keys  416 / 420 , and special rules  424 / 422 . These provide greater power and ease to the encryption process. 
         [0076]    The additional encrypted readers field  414 / 418  lists additional encrypted readers to be added to the “encrypted for” list for any file which was encrypted for the executive—in this example—John Jones. In this case, it is the role “administrative assistant” as sometimes an executive will have turnover in the administrative assistant role or may have multiple administrative assistants. Anytime a file is encrypted for John Jones, the public keys of any and all of the administrative assistants listed as supporting him so that they may read the encrypted document. This was discussed to some degree above. 
         [0077]    Another new concept is the use of additional public keys  416 / 420 . The inclusion in the executive&#39;s directory record the additional public key to use (assuming public key encryption) when encrypting data for the executive rather than actual additional person names. With this mechanism, multiple assistants who all have access to the private key for the additional public key could each decrypt the data. The advantage of this mechanism is that it is easier to encrypt for a group of people (such as assistants) where the actual membership changes over time. 
         [0078]    Finally, special rules field  424 / 422  allows the executive to have special rules associated files he has encrypted. In this example, if he encrypted a file for Joe Smith, a key is automatically included for Mary Jones. 
         [0079]    Referring back to  FIG. 6 , look up module  620  is connected to both the local directory table  610  and the network directory table  680  so that the look up module may utilize the look up capabilities on either or both of the directory tables. 
         [0080]    Deriving module  660  retrieves the addressee information from the email client  665  as input by the user in the addressee fields  708 ,  710  and  712 . The deriving module  660  utilizes name parser  634  to parse the addressee fields  708 ,  710  and  712  and accesses the look up module  620  to identify the addressees as well as the associated parties or roles by reviewing such information from either the local name directory  610  or the network directory table  680 . The deriving module  660 , having received instructions from the user regarding roles associated with the named intended recipients and the authorized roles, derives the associated roles of that specific named recipient with assistance from role identification module  636  and authorization module  632 . 
         [0081]      FIGS. 9 and 10  illustrate flowcharts  900  and  1000  showing steps of the method of the present invention. At  902 , the present invention receives the named recipient identification data. At  906 , the system receives the authorized roles. At  910 , the system encrypts the data according to the received input and, at  912 , the encrypted data is sent. 
         [0082]    In  FIG. 10 , the intended recipient, or an authorized role, receives the encrypted data at  1002  in the process  1000 . At  1004 , the intended recipient, or authorized role, decrypts the data and at  1006  accesses the data. 
         [0083]    Additionally, when sending an encrypted message that includes additional parties not in the recipient list (such as administrative assistants), the message could contain the names of the additional parties (either retrievable from the encrypted info/keys in some encryption schemes or explicitly added by means such as “X-header” extensions to the message) so that any “reply with history” could continue to be decryptable by the additional parties if the person creating the “reply with history” so desired. 
         [0084]    The foregoing description of various aspects of the invention has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed, and obviously, many modifications and variations are possible. Such modifications and variations that may be apparent to an individual in the art are included within the scope of the invention as defined by the accompanying claims.