WO2002039224A2 - Methods for distributed trust environment - Google Patents

Abstract

A system (100) for controlling digital information from a sender (104) to one or more recipients (108), comprising of: a packager (120) for packing digital information in accordance with a sender specified set of rules and access level information; one or more secured delivery engines (116) for delivering said packed digital information from said sender to said one or more recipients; and a rendering program (124) for manipulating said delivered digital information in accordance with said rules and said access level information associated with each of said recipients.

Description

Specification

METHODS FOR DISTRIBUTED TRUST ENVIRONMENT

PRIORITY CLAIM

This application claims priority to a provisional application entitled "Trusted Messaging" filed on November 7, 2000, having an application number 60/246,420, and to a provisional application entitled "Military Distributed Trust Environment" filed on November 7, 2000, having an application number 60/246,338.

BACKGROUND OF THE INVENTION

Field of the Invention

The present invention generally relates to methods for controlling the delivery of digital information and for controlling the manipulation of such information after its delivery, in particular, methods for the delivery and manipulation of digital information in a distributed trust environment having different levels of access and control.

Description of the Prior Art The delivery of digital information such as email messages is rapidly becoming a ubiquitous form of communication and may represent one of the, if not the fastest technology adoption trend in history. In order to stay competitive, every organization must adapt to the email explosion while simultaneously protecting themselves from the risks of open communications. Example risks include the unauthorized access to and/or use of email systems and message content, stolen or misappropriated individual and/or organizational identities, and the unauthorized modification of email messages including attachments. Governments have similar concerns and may have more stringent security and trust requirements in many instances.

Given the increasing ubiquity of electronic messaging and email, individuals share similar concerns and risks as well. For example, individuals may wish to preserve the privacy or confidentiality of their email messages and attachments and may wish to ensure that their electronic identities are not stolen or otherwise misused.

Though email is fast, cost-efficient, and convenient, as typically implemented, email may expose enterprises and individuals to extreme risk. Some of these risks include: 1) the inability to control email messages and attachments after transmission, 2) the loss of communications privacy and trust, and 3) increased corporate and individual liability from uncontrolled digital communications. The inability to control message content, for example, may lead to the disclosure of sensitive personal, corporate, and/or governmental information. Email users may not trust messages when they cannot be certain of the integrity of message content and/or the identity of the sender or receiver. Lack of message control, therefore, may lead to increased liability, for example, when individual healthcare or financial records are received and read by parties lacking the authority to do so. More specifically, referring to Fig. 1, a scenario illustrating present day email communication is illustrated. Here, the sender 10 wishes to communicate via email a private message 12 to an intended receiver 14 (or group) and not beyond, and wishes to be assured that the message only be used in a manner specified. The private message travels from a first mail server 16 to the internet and to the mail server 20 of the intended receiver. However, referring to Fig. 2, the intended receiver can use the private message in ways unintended by the sender. For example, the intended receiver may distribute electronic or print copies of the message, reply to the email message and including unintended receivers, or forwarding the message to unintended or unauthorized receivers. Furthermore, referring to Fig. 3, the privacy of the email message can be compromised by its context alone (i.e., subject / sender identity). For example, in an open work environment 24, unintended personnel can view the email message just from the sender or subject line information 26 presented on the screen to glean private and confidential information. Also, referring to Fig. 4, an email message could be unintentionally sent to an unintended receiver with a mistake in the email address; valuable company, governmental, and or individual information could be lost and or greatly compromised. The lack of predictability, the lack of certainty regarding email messages, their senders, recipients, contents, attachments, and/or intermediaries remain a concern for individuals and organizations. Moreover, in an environment (such as in a military operation) where there are a number of players each having a different level of clearance (therefore access) to sensitive digital information, a system is needed to control access to the same digital information by different players (having different levels of clearance) and allow different types of action be acted upon that digital information in accordance with the levels of clearance. For example, a person having a low clearance level should only have the ability to view the sensitive digital information while a person having a high clearance level should have the ability to view and manipulate the digital information. Furthermore, as circumstances change, a player's level of clearance may change as well.

All of these problems associated the delivery of sensitive digital information provide the impetus and desire for a distributed trust environment.

SUMMARY OF THE INVENTION

It is therefore an object of the present invention to provide methods for achieving infrastructure security by protecting digital information in any format thus enabling the secure transmission of protected information over both secure and insecure channels. It is another object of the present invention to provide methods for monitoring use of digital information, including use associated with and/or in the context of access in view of changing circumstances.

It is another object of the present invention to control access to digital information in accordance with levels of clearance associated with recipient. It is still another object of the present invention to provide methods for controlling the manipulation

(including the viewing, the forwarding, or the replying) of digital information.

Briefly, in a presently preferred embodiments of the present invention, a system for controlling digital information from a sender to one or more recipients is presented, comprising of: (i) a packager for packing digital information in accordance with a sender-specified set of rules and access level information; (ii) one or more secured delivery engines for delivering said packed digital information from said sender to said one or more recipients; and (iii) a rendering program for manipulating said delivered digital information in accordance with said rules and said access level information associated with each of said recipients. An advantage of the present invention is that it provides methods for achieving infrastructure security by protecting digital information in any format thus enabling the secure transmission of protected information over both secure and insecure channels.

Another advantage of the present invention is that it provides methods for monitoring use of digital information, including use associated with and/or in the context of access in view of changing circumstances.

Still another advantage of the present invention is that it controls access to digital information in accordance with levels of clearance associated with recipient. Still yet another advantage of the present invention is that it provides methods for controlling the manipulation (including the viewing, the forwarding, or the replying) of digital information.

Note that all references to email message in this disclosure may also be considered as reference digital information of all types (not limited to email messages).

Further note that the current invention transitions common email from a public chat to a private dialogue. An email sender can protect selected email messages and attachments by specifying rules that a recipient must comply with in order to access the message and attachments. Messages and attachments are packaged into secure containers along with rules governing their use by an authorized messaging program. The secure containers are transmitted using normal email channels, however upon receipt the body and attachments can only be accessed when using an authorized rendering program and handled by the recipient in a manner specified by the sender. For example, if the sender specifies a rule that states a recipient can only view the body and attachments of an email, then the recipient is prohibited by the trusted email rendering program from cutting or copying the message or from printing it. The system provides an approach to managing the trusted authorization of message packaging and rendering programs. Furthermore, the system provides a tracking function that can monitor and report the status of email transmissions. The system does not require that a company or individual scrap their current email system. Secure email seamlessly integrates into existing mail clients and requires no special processing by backend mail servers. This allows the existing email network becomes the foundation to integrate secure communications process and persistent content protection into email communications, inside and outside an organization.

The rule-based nature of secure email can implement virtually any privacy policy as required by governments, contracts, markets or end users. Rules attached to e-email protect the rights to the intellectual property and ideas contained in email messages and attachments. At the time the email is generated, access and usage rules, as defined by the sender, are attached to the email. The sender can control an extensible list that defines things like how and when the email and attachments can be used, e.g., a sender can provide direct control over intended uses that may include viewing, printing, copying, editing and duplication. Trusted email can maximize the efficiency of email communications while providing the full confidence that intellectual property; confidential communication, and financial information are exchanged and shared with minimum risk.

Regardless of where the secure emailand attachments are sent, the contents remain protected and the systems persistently controls access to and use of email messages, both on-line and off-line. Even after the message is delivered, and the recipients have downloaded and opened the email on their local machines, the email is still governed by rule set by the sender.

Secure email has a built in audit trail that can monitor and report the status of email transmissions. This audit trail could be used to verify that a message was delivered, in authentic and unaltered form. The audit function can also determine and report the fact that a message was opened at the destination. The trusted email audit features are significant in those circumstances where message delivery status and acceptance may be required. The audit trail provides a full-featured protection process in case an intended recipient repudiates message delivery.

Note that the present invention relates to exchanging electronic messages in a cryptographically secure container (non-limiting examples of which are disclosed US Pat. No. 5,715,403 issued to Stefik on 2/03/1998; US Pat. No. 5,638,443 issued to Stefik et al. on 6/10/1997; US Pat. No. 5,634,012 issued to Stefik et al. on 5/27/1997; US Pat. No. 5,629,980 issued to Stefik et al. on 5/13/1997; and, US Pat. No. 5,845,281 issued to Benson et al. on 12/1/1998; which are incorporated herein by reference). One embodiment that provides offline availability for secured information and offline evaluation and/or enforcement of rules associated with the secured information, is disclosed in US patents issued to InterTrust™ ("the InterTrust patents") incorporated by reference herein and includes the following patents: U.S. Patent No. 6,185,683 to Ginter, et al.; U.S. Patent No. 6,138,119 to Hall et al.; U.S. Patent No. 6,112,181 to Shear et al.; U.S. Patent No. 5,982,891 to Ginter et al.; U.S. Patent No. 5,949,876 to Ginter et al.; U.S. Patent No. 5,920,861 to Hall et al.; U.S. Patent No. 5,917,912 to Ginter et al.; U.S. Patent No. 5,915,019 to Ginter et al.; U.S. Patent No. 5,910,987 to Ginter et al.; U.S. Patent No. 5,892,900 to Ginter et al.; and pending application WIPO Publication WO9,810,381 Al to Shear et al. The processes described herein may also be compatible with applications based on and/or interacting with software and or hardware instantiations of the Common Security Data Architecture, its APIs and services, as described, for example, in CDSA Explained, ISBN 1-85912-231-0, Document Number 901, UK: The Open Group, January 1999; Common Security: CDSA and CSSM, Version 2 (with corrigenda) ISBN: 1- 85812-202-7, Document Number C914, UK: The Open Group, May 2000, presently available at: http://www.opengroup.Org/pubs/catalog/c914.htm#medium3.

The present invention also relates to electronic rules securely associated with electronic messages and means for enforcing those rules whenever and wherever access and/or use of protected information is requested. These and other features and advantages of the present invention will become well understood upon examining the figures and reading the following detailed description of the invention.

IN THE DRAWINGS

Fig. 1 is an illustration of a prior art process for sending email from a creator/sender to a receiver(s); Fig. 2 is an illustration of a prior art process where an unintended receiver reads forwarded email;

Fig. 3 is an illustration of a prior art process where portions of the email message are compromised in an open work environment;

Fig. 4 is an illustration of a prior art process where the email is mistakenly addressed for the wrong person; Fig. 5 is a block diagram of an embodiment of a messaging system; and

Fig. 6 is a block architecture diagram of an embodiment of a trusted messaging system client.

Fig. 7 is a block diagram of an embodiment for creating a secured email message;

Fig. 8 is a block diagram of an embodiment for viewing a secured email message;

Fig. 9 is a screen shot of an embodiment of a settings panel that includes profiles, intents and message field replacement;

Fig. 10 is a block diagram of a rule selection process; and

Fig. 11 is a table illustrating an example of the membership and access layout in a distributed trust environment.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

In a presently preferred embodiments of the present invention, an non-limiting example embodiment of a messaging system 100 is shown in Fig. 5. A sender 104 and receiver 108 have a trusted computing base ("TCB") 128 associated with each of their computers, said TCB 128 having a software tamper resistant secure execution facility known to those skilled in the arts. A TCB 128 may rely in part on hardware tamper resistant techniques known to those skilled in the arts. One example of a TCB 128 is disclosed in US patent No. 5,715,403 issued to Stefik on 2/03/1998; US Patent No. 5,638,443 issued to Stefik et al. on 6/10/1997; US Pat. No. 5,634,012 issued to Stefik et al. on 5/27/1997; and, US Pat. No. 5,629,980 issued to Stefik et al. on 5/13/1997 which are incorporated herein by reference. Another example is disclosed in US Pat. No. 5,845,281 issued to Benson et al. on 12/1/1998 which is also incorporated herein by reference. One embodiment of TCB 128 is an "InterRights Point" software installation that includes a protected processing environment as disclosed in the InterTrust patents, hi a related embodiment, the TCB functions are more fully integrated with the operating system, one example of which is the Virtual Distribution Environment (VDE) disclosed in the InterTrust patents. Using a messaging program 116, the sender 104 composes a message, which may include one or plural attachments. The messaging program 116 formats and passes the message to the TCB 128-1 using the application program interface (API) of the TCB 128.

Some embodiments could gather some message and/or packager information from a MAPI mail client 112 or a stand-alone packager application program 120. In some embodiments the messaging program 116, MAPI mail client 112, and/or stand-alone packager program 120 would operate together with TCB 128-1 on a common computer/appliance 110-1. In other embodiments, the messaging program 116, MAPI mail client 112, and/or stand-alone packager would be distributed on separate computer/appliance and interact remotely with TCB 128-1.

The messaging program 116 includes a packager routine and rules compiler routine. The packager routine gathers the message and any attachments and sends them to the API of the TCB 128-1. The rules associated with the packaged message and/or attachments are compiled and passed to the TCB 128-1 for inclusion in a cryptographically secure container ("CSC") 132. The CSC protects the message and attachments during transport through the Internet, private networks, including corporate networks ("intranets") and private networks among value chain parts, often referred to as "extranets," for example. Once in the CSC 132, the message is passed to the receiving party 108. With the assistance of a rendering program 124, the TCB 128-2 of the receiver decodes the CSC 132 and controls subsequent access to the message and/or attachments. The rendering program 124 allows the receiver 108 to view and manipulate the message and any attachments in accordance with the rules provided by the sender 104. In some embodiments the rendering program 124 would operate together with TCB 128-2 on a common computer/appliance 110-2. 108. In other embodiments, the rendering program 124 would be distributed on a separate computer/appliance and interact remotely with TCB 128-2.

The messaging program 116 and/or the stand-alone packager 120 is authorized to exchange messages with the rendering program 124. Authorization to exchange messages is based in part on authorization to use the TCB 128 and the presence of a protected digital data structure(s) stored within TCB 128. One or more protected digital data structures authorizes messaging program 116 and/or the stand-alone packager 120 to allow sender 104 according to rules to encode messages and attachments within a CSC 132 and to include within the CSC 132 a protected digital control mechanism that allows an authorized rendering program 124 to authenticate that the receiver 108 of the message is the intended recipient. Similarly, the presence of one or more protected digital structures stored within TCB 128 authorizes the rendering program 120 using the protected digital control mechanism transported within CSC 132 to only decode and render messages that are intended for receiver 108.

In one embodiment authorization to exchange messages is provided by a centralized rights manager program ("RM") 134. RM 134 may create, modify, store, and distribute protected digital data structures used by TCBs to manage rights. Non-limiting examples of rights managed within a protected digital data structure include authorizations, membership cards, budgets, and persistent ownership rights. In this example, a user authorized to use TCB 128, must also be authorized by the RM 134 to use messaging program 116, stand-alone packager 120, and/or rendering program 124. In some embodiments the RM 134 may be a stand-alone program or in other embodiments the functions of RM 134 may be incorporated via API's or other suitable mechanisms into existing centralized authorization systems such as Novell's directory services products, or other directory systems using enterprise directory system (e.g. x.500), or Lightweight Directory Access Protocol (LDAP). The entity that controls the RM 134 may provide certain policies to authenticate the identity of the user including their email address. Non-limiting examples of the policies used by the controlling entity may include procedures that incorporate x.509 certificates or other digital certificate authority schemes. Some embodiments of the RM may include API's to facilitate this access to 3rd party systems that provide certificate and key management services. The RM 134 controlling entity is also responsible for causing the RM 134 to distribute securely a protected digital data structure to TCB 128, which grants authorization to use the messaging program 116, the stand-alone packager 120, and/or the rendering program 124.

In another embodiment authorization to exchange messages is provided in an initial peer-to-peer exchange of authorization information between the messaging program 116 and the rendering program 124. In this example, a sender 104 and a receiver 108 must first be authorized to use TCB 128-1 and TCB 128-2 respectively, the sender 104 and the receiver 108 securely registers certain identifying information about themselves including their email address to TCB 128-1 and TCB 128-2 respectively, the sender 104 then invites the receiver 108 to exchange messages. Authorization is passed within a protected digital data structure inside a CSC 132 from the receiver 108 back to the sender 104. In another embodiment, at least some rules and/or associated "objects" or files related to the message may be sent in a CSC to receiver 108 by a third party. Non-limiting examples of said third parties include providers of financial clearing and/or processing services. Non-limiting examples of the financial clearing rules and/or associated information include one or more instantiations of electronic money, payment, stored value, credit, notational currency, digital cash, and other currency and payment related electronic files or "objects". An example financial clearinghouse 140 may send a rule or payment object in a CSC 132 to the message receiver 108. hi one embodiment, the TCB 128 includes means for receiving, assessing the integrity and authorized source of the payment-related information, and as necessary, associating the payment information with rules provided by sender 104 if payment for access and/or use of the message and/or one or plural attachments is required by sender's 104 rules. The sender 104 can choose rules to regulate access to the message and attachments by the receiver

108 and or other parties. The messaging program 116 gathers the rules and passes them to the TCB 128 for inclusion with the CSC 132. These rules are persistent, such that the receiver 108 or other parties cannot violate the rules at any time in the future. For example, a rule may prevent the receiver 108 from forwarding, printing, copying or saving the message such that another recipient who is not authorized by sender 104 is prevented from accessing and/or using the message and one or plural attachments. Some embodiments can sunset and sunrise the rules to make them applicable during a time period.

The rules are embodied in intents or verbs that the TCB 128 applies to the message and/or attachments inside the CSC 132. Non-limiting example embodiments of verbs or intents are disclosed in US Pat. No. 5,715,403 issued to Stefik on 2/03/1998; US Pat. No. 5,638,443 issued to Stefik et al. on 6/10/1997; US Pat. No. 5,634,012 issued to Stefik et al. on 5/27/1997; and US Pat. No. 5,629,980 issued to Stefik et al. on 5/13/1997. Other intent or verb embodiments are disclosed in the InterTrust patents. For example, a "save" intent could be specified to allow the receiver 108 to save an attachment locally outside the protection of the TCB and any CSCs. Once saved, the control of the unprotected saved version is lost.

A usage clearinghouse 136 audits a message as it is packaged and sent by sender 104 and/or received and accessed by receiver 108. Information from the TCB 128 of the sender and receiver is available to the clearinghouse 136. This audit information can be used to check compliance with the rules, and as a foundation for value-added services, such as "certified delivery", "non-repudiation", and other value-added services.

In another embodiment, the messaging program accesses the facilities of the TCB through abstraction layer as shown in Figure 6. The abstraction layer provides an API consisting of messaging related functions, non-limiting examples of which include "package this message", "package this attachment" "package these rules", and any other trusted functions and/or capabilities provided by messaging program 116. As illustrated in Figure 6, computer or appliance is a hardware context on which operating systems and applications are run. Non-limiting examples of computers or appliances include PCs, Macs, Windows CE machines, cell phones, personal digital assistants, game machines, digital cable boxes, WebTV, and other devices. The operating system controls the hardware and peripheral devices and provides services to and a software execution context for applications and other software. Operating systems include various Microsoft Windows versions including XP, MAC OS, Linux, Unix, and other operating systems. In one embodiment, the TCB 212 may be thought of as a middleware operating system extension that provides security and trust related services to applications that use its services which are accessed through a TCB API 216.

Conventional mail clients make no use of TCB services, for example a first mail client 224-1 interfaces with the OS 208 exclusively. Figure 6 also shows that the trusted messaging system may be integrated .with any number of mail clients. In one embodiment, a second mail client 224-2 may obtain services from the TCB through the TCB API 216. However, in some embodiments many TCB API calls are required to accomplish common and repetitive tasks, such as packaging rules, messages, and/or attachments in one or more CSCs. A third and n"¹ mail clients 224-3, 224-n are enabled to make use of TCB services through a trusted mail client abstraction layer API 220, which is in contrast to the second mail client 224-2 that makes use of the TCB services directly through the TCB-API 216. The first mail client 224-1 makes no use ofthe TCB 212.

Figure 6 also shows that a mail client may present its information and services to a user through a graphical user interface (GUI) 232 that may vary from mail-client-to-mail-client. In addition, there may be a need to "localize" the presentation for different languages using a localization method, such as files that contain certain presentation information in the language of choice. The information in these localization files is then used by the mail client GUI interface 232.

One benefit of the abstraction layer API 220 is that it makes the task of creating an interface between a mail client 224 and TCB services 212 much easier because higher level functional calls to abstraction layer API 220 may hide the underlying complexity of multiple TCB API 216 calls per function. The programmer then is free to concentrate on the particular issues in interfacing with the mail client at hand. An advantage of the present invention(s) is that programmers who are already familiar with mail clients are less likely to have to learn the details and complexities of the TCB API 216. In addition, enhancement, modification, bug fixing are enhanced since in many cases one need only change the abstraction layer 220 once to provide these improvements to users of many different mail clients 224, assuming that the abstraction layer calls themselves do not require alteration.

Solutions to Contextual Problems In the implementation of the preferred embodiments, a number of issues are presented and resolved including the resolution of contextual problems. More specifically, the description provided below provide methods used by messaging program 116, stand-alone packager 120 and/or rendering program 124 to to resolve various issues related to protecting electronic messages from unauthorized access and use . Solutions to Contextual Problems - Providing for auditable email path tracking, credentialed and trusted email applications, and email clearinghouse services

The chain of repackaging authority for the contents of an email message can be traced. This is to be accomplished by associating two attributes for each content object (or some other suitable object) within a message. Each repackaging of the contents of a message by messaging program 116 and/or by the standalone packager 120 will causes an instantiation of one or more content objects. The first attribute will be assigned a value containing a unique Object ID for the latest instantiation of the content object. The second attribute will be assigned the full parentage (each Object ID which has included it in this path) of all prior instantiations. In the case of an object that is a re-packaging of previously packaged content, the newly packaged content's second attribute will get the full Object ID set from the prior packaging's second attribute (the second attribute's value) as well as the Object ID of that previously packaged content (the first attribute's value). Repackaging authority, within messaging program 116 and/or the stand alone client 120, is handled by a custom intent, that is, by a verb or controlled action that is not standard verb of, and/or known to a TCB, but which in the preferred TCB embodiment has been in part programmed and certified by the provider of the preferred embodiment TCB .

One or more application credentials are relied upon for the security of the messaging program 116, the stand-alone packager 120, and the rendering program 124 applications In order to ensure the integrity of the said applications using a TCB instance, the provider of the TCB may evaluate the security, trustedness, and/or functionality of a proposed trusted application, and upon determining that the application is secure, trustable, and performs certain controlled actions in accordance with the TCB verb(s) or intent(s), the TCB provider associates with the certifiable application one or more trusted credential such as a "digital certificate" or signed object. This certificate or signed object is referred to as an "application credential" whose presence and/or validity may be checked by the TCB at least one or more times as the certified or credentialed application uses capabilities of the TCB through the TCB API 216 or through an abstraction layer API comprised at least in part of higher level or more holistic function call. In turn, the abstraction layer uses one or more TCB API 216 calls to accomplish the higher level tasks. In one embodiment, the application credential(s) associated with messaging program 116 and/or stand-alone packager 120 are known in a trusted and protected manner by rendering program 124. The application credential(s) associated with the certified messaging program 116 and/or the stand-alone packager 120 are stored in each CSC prepared by said programs so that the rendering program 124 can readily tell CSCs prepared by said programs. In the presently preferred embodiment the rendering program 124 will only be process those CSCs created by messaging program 116 and or stand-alone packager 120. Similarly, other 3^rd-party CSC rendering programs are not to process CSCs created by messaging program 116 and/or stand-alone packager 120. In the presently preferred embodiment, one non-limiting example of a CSC is an InterTrust™ DigiBox secure container. A clearinghouse needs to be involved for processing and reporting the audit trail, which in the presently preferred embodiment is at least in part described in the aforementioned WIPO publication WO9,810,381, Shear, et al. Audit/usage records are created at the time the email is secured within the CSC by the TCB (see Fig.7) and again when the email is first viewed (the CSC is opened and content is presented after the authorization rules are met) (see Fig. 8). At the sender's option, an audit record can be produced each time the email or attached files are viewed, printed, or saved.

Solutions to Contextual Problems - Providing for email Subject Line replacement

The real subject line of an email message is saved in a protected fashion and replaced by a non- informative subject line during public transport, after receipt by the intended recipient the original subject line is restored In one embodiment, this is accomplished in messaging program 116 and/or stand-alone packager 120 by providing the sender 104 with a dialog (something similar to Fig. 9) to specify the non- informative subject line to use. In some embodiments the non-informative text may be stored as a default subject line available to sender 104 each time stand-alone packager 120 and/or messaging program 116 is used. The messaging program 116 and/or the stand-alone packager 120, creates a replacement message that contains the non-informative subject line along with an attached CSC file that contains the original subject line along with other components of the message. The replacement message is then submitted by messaging program 116 and/or stand-alone packager 120 to sender 104 email client via some standard interface, for example the Messaging Application Program Interface (MAPI) proposed by Microsoft™ and now implemented by many email system vendors or some other suitable interface. It is noted that MAPI includes functions for harvesting the real subject line of a message, thus an advantage of subject line replacement is to protect the sender 104 and receiver 108 from unwanted tracking of the subject of exchanged messages. Upon receipt of the replacement message by receiver 108, the rendering program 124, according to rules decodes the message in the CSC and the real subject line is made available by replacing the default subject line in the rendered message.

Solutions to Contextual Problems - Providing for Sender Name/Address Replacement

The real sender's name and address is saved in a protected fashion and replaced by a non- informative name and/or address during public transport, after receipt by the intended recipient the original name and address is restored. In one embodiment, this is accomplished in messaging program 116 and/or stand-alone packager 120 by providing the sender 104 with a dialog (something similar to Fig. 9) to specify the non-informative name and address to use.

How to modify the name and email address for the "sender" varies somewhat by email client. Willful replacement of sender information with incorrect or invalid sender information is known as spoofing, and may at some point be considered illegal or subject to control by some governmental bodies. Conventional mail clients allow changing the sender information for all messages through a manual process. For example, the name and email address of the sender is established via a properties panel in Microsoft™ Outlook 2000™. The panel for Outlook 2000 is available via "Tools"/"Services"/"Properties" where the User Information section is changed to supply a different name and email Address. In one embodiment, it is stored in the Registry in entry "Office\Outlook\OMI Account Manager\Accounts\00000001".

In one embodiment, this is accomplished in messaging program 116 and/or stand-alone packager 120 by providing the sender 104 with a dialog (something similar to Fig. 9) to specify the non-informative name and address to use. The messaging program 116 and/or the stand-alone packager 120, creates a replacement message that contains the non-informative name and address along with an attached CSC file that contains the original name address and along with other components of the message. The replacement message is then submitted by messaging program 116 and/or stand-alone packager 120 to sender 104 email client via some standard interface, for example the Messaging Application Program Interface (MAPI) proposed by Microsoft™ and now implemented by many email system vendors or some other suitable interface. Upon receipt of the replacement message by receiver 108, the rendering program 124, according to rules decodes the message in the CSC and the real subject name and address is made available by replacing the spoofed name and address in the rendered message.

Solutions to Contextual Problems - Other Fields

Other fields in the message header could be replaced by default values. The rendering application in conjunction with the TCB would replace the default values with the real values. For example, for a message sent to many receivers could have the other receivers suppressed until viewing such that viewing the message during transport would only reveal one of the receivers. In one example, a medical specialist's doctor's office may send a trusted email to a patient and choose to mask who the sender is less so that some interloper cannot infer from the sender what medical condition(s) the patient might have.

Solutions to Contextual Problems - Rule profiles (named collections of rules^')

A rule profile is a named collection of rules, specified by a sender 104 or established by some other enterprise, governmental or institutional body and selected by sender 104, for controlling how a receiver 108 may use an email. Selection of one of the predetermined groups of rules applies those rules to the message more efficiently and consistently. Rules specify how and when an email may be used. Rules include but are not limited to specification for the handling of messages that allow or disallow for printing, viewing, saving into the clear (unencrypted), as well as a time range when such actions are valid, so called "sunrise" and

"sunset" dates, and the consequences of these actions, e.g. auditing or financial payment,. For example, a patient profile may allow viewing a note from the attending physician, but not printing the note, the note is available for the next 10 days, and if the note is view an audit record is created. In one embodiment, sender 104 provides a list of e-mail recipients to messaging program 116 and/or stand-alone packager 120 and selects a rule profile. Messaging program 116 and/or stand-alone packager 120 processes the recipient list and applies the rules contained in the selected rules profile to message packaged for each recipient. Rule profiles are stored in Extensible Markup Language (XML) (non-limiting example details of which are provided in Appendices 1, 2, and 3) anticipating that the set of rules/options covered in a profile will likely grow over time (see Figs. 9 and 10). XML is defined via http://www.w3.org/XML/ as a vendor- independent standard. Microsoft extensions may also be used in the implementation and they are documented at http://msdn.microsoft.com/XML. Referring to Appendix 1, the first line identifies this as an Email Settings XML and identifies the namespace to use (for datatypes). The second line begins the definition of the "Individual" settings, which in one embodiment indicates which of a possible hierarchy of rules profiles the present instance belongs. Rules profiles might reflect any class distinctions), one example of which might be a hierarchical Corporate/Department/Individual settings of options in a rules profile. In this example, Corporate settings would overrule Department settings which would overrule Individual settings. Distinctions would be made between "defaults" being specified at a higher level vs. a required value being specified at a higher level. For example, Corporate settings in a given profile might default secured emails to expire (sunset) after 1 year while requiring that those emails NOT have SAVE intent enabled. This would allow Individuals to set their corresponding profile to a different sunset date but would NOT allow them to enable the SAVE intent. The third line describes the "Ind_Print" option attribute. It is labeled "Ind_Print" anticipating the hierarchy of options described above to allow for "Corp_Print" and "Dept_Print" option attributes. It is defined as an integer ("int") datatype using the specified XML NameSpace ("xmlns"). It is assigned a value of 1 and the attribute description is terminated (</Ind_Print>). In interpreting the XML representation of a rules profile, the messaging program 116 and/or the stand-alone packager 120 interprets a value of 1 to mean that the intent is enabled and a value of 0 means the intent is disabled. These interpretations in the preferred embodiment then drive the building of a rule or rules by the messaging program 116 and/or the stand-alone packager 120 that can be stored and transported in a CSC These rules are subsequently interpreted and enforced by the TCB whenever the CSC is opened. The fourth line describes the "Ind View" intent option attribute. See the description of the third line for the details. The 1 indicates "View" is to be enabled. The fifth line describes the "Ind_Edit" intent option attribute. The value of 0 indicates the "Edit" option is NOT to be enabled. The sixth line describes the "Ind_Save" intent option attribute. The value of 1 indicates the "Save" option is to be enabled. The seventh line describes the "frιd_Reply" intent option attribute. The value of 0 indicates the "Reply" option is NOT to be enabled. The eighth line describes the "Ind Forward" intent option attribute. The value of 0 indicates the "Forward" option is NOT to be enabled. The ninth line describes the "Ind_Sender_Name" replacement value. It is defined as a string. It has the value "Default" which would become the sender name on the email if the next attribute (Ind_Sender_NameJOverride) is enabled (has a value of 1). The tenth line describes the "Ind_Sender_Name_Override" option attribute. It is an integer ("int") assigned a value of 1. When interpreting the XML representation of a rules profile, the messaging program 116 and/or the stand-alone packager 120 considers the value of 1 for this attribute to request that the sender's name on the email be replaced during the "Make Secure" operation so that the value specified in the attribute "ϊnd_Sender_Name" is shown instead. Only after the rendering program 124 caused the successful opening by a TCB of a CSC according to rules will the actual sender name be displayed when the email is opened. The eleventh line describes the "Ind_Subject" line option attribute. It is defined as a string and the value assigned, "TRUSTDATA Secure Message" in this case, is to be the value assigned as the subject line of the email replacing the actual subject line. The actual subject line would only be visible once the CSC was opened by the trusted viewer or rendering application. The value is only used to replace the actual value if the next attribute "Ind_Subject_Override" has the value of 1. The twelfth line describes the "Ind_Subject_Override" option attribute. It is defined as an integer. When it is assigned a value of 1 (as in this example), it indicates the value of the attribute "Ind_Subject" should be used to override the actual entered subject line for the email message. A value of 0 for "Subject_Override" indicates the actual entered subject line should be used. The thirteenth line describes the "Ind_Sunrise" option attribute. It is defined as a dateTime attribute. The value assigned indicates the earliest time (GMT) at which the email may opened. The fourteenth line describes the "lhd_Sunset" option attribute. It is defined as a dateTime attribute. The value assigned indicates the latest time (GMT) at which the email may be opened. The fifteenth and sixteenth lines provide closure to the elements defined. In another embodiment the XML representation includes: (1) validity date in days from packaging date/time - this option would allow a number of days to be specified for the validity period. The sunrise date would be assigned as the packaging date and the sunset days would be calculated to be the number of days as specified in this attribute after the packaging date. (2) usage auditing options - What audit records should be prepared from use of this email Options include but are not limited to combinations of; at packaging time, on first open, on every open, on first save, on every save, on every print, on first print, no auditing at all.

Solutions to Contextual Problems - Recipient level ID test

In one embodiment the messaging program 116, stand-alone packager 120, and or rendering program 124 will provide a recipient level ID test will authenticate that the specified recipient email address has one or more associated valid TCB UserfiOs. An email address may have one or more valid TCB UseriODs This is defined as allowing many UseriODs for one email address to allow for eventual web-based email access and shared file access where the intended recipient may have UserlDs on many different TCBs for the same user (e.g., work computer, home computer, notebook computer, etc.). The alternative of many email addresses associated with the same UserlD seems attractive at first glance (lots of people have more than one email address). However, it would make for a not readily detected means of getting unauthorized access to emails intended for others if someone could add their own email address to a list for someone else's UserlD. In general, secure control of the address book mapping of email address and UserlD is important. The selected profile(s) chosen will be authenticated against the selected recipients at the time the CSC is formed to ensure class and/or group membership. This requires not just an address book but something that lets the messaging program tell what groups a given recipient belongs to and what groups and profiles are valid combinations. In the preferred embodiment, a protected digital data structure that we refer to as a "Digital Credential Object" may represent, signify, warrant, and/or attest to any one or more identity characteristics, attributes, and/or memberships. We refer to these identity characteristics, attributes, and/or memberships equivalently as "memberships." The DCO contains data elements for the name of the DCO, one or more memberships, information that may include cryptographic information indicating the authority that associated the membership with the entity, and information that may include cryptographic information indicating the entity with whom the one or more memberships are associated, and any other fields providing relevant information. Since the DCO is never released from or directly exposed for manipulation outside the control of the TCB, there is no requirement for the calculation of either an integrity check, such as a checksum or cryptographic message digest, and/or the validation of an integrity check using other cryptographic means. In the presently preferred embodiment these DCOs are "Membership Cards" as described, for example, in the aforementioned U.S. Patent No. 6,112,181 to Shear, et al.

Solutions to Contextual Problems - Membership identification

In one embodiment the messaging program 116, stand-alone packager 120, and or rendering program 124 will allow email to be sent to general membership groups where that group could expand or contract over time and the access to attachments sent with historical messages to be enabled without having to be a specific recipient. There is both a revocation mechanism (the presence of a revocation of a membership indicates the membership is no longer valid) as well as a way of expiring memberships (date range limits). A given individual can have many memberships. A general membership management application could be of use beyond secure emails and files. A membership can be granted for free or for some information (filling out a survey for example) or for some payment. This membership mechanism may be used to assign a membership specific to each authorized user of our secure email products and automatically include a test for this membership in every rule of every email/file we package. One non limiting benefit of this mechanism would allow RM 134 to quickly revoke that user's access to all secure emails/files should circumstances warrant.

Solutions to Contextual Problems - Each email message may have one or more specific membership cards. In one embodiment RM 134 will provide membership cards in the form of a protected digital data structure with expiration dates. This will be coordinated with the use of the date validity range mechanism and may be revoked using appropriate revocation token(s) also provide by RM 134. Messaging program 116, stand-alone packager 120 and rendering program 124 will process membership cards according to rules. The use of memberships per email message is primarily to enable revocation of a given recipient's authorization to read a given email message. In some embodiments the memberships would be delivered to the recipients via the same CSC that included the email message. In other embodiments, revocations could be sent in CSCs later either from the sender or potentially from an administrator, such as RM 134. All of this requires that the rules defined in the CSC for the email include a test for the membership in addition to whatever other tests are appropriate.

Expired and/or revoked membership cards and other objects may be deleted by a utility application. In one embodiment, function calls in the API allow membership cards (or other objects) to be found and examined for validity. If invalid, the membership card is deleted. For example, a membership card may have exceeded its validity date. Upon its next use, the membership card is deleted.

Solutions to Contextual Problems - Unique application ID used to restrict access to a particular rendering application^

In one embodiment an identifying application ID or application IDs would be associated with rendering program 124 and would protect the email messages. This mechanism is managed between the messaging program 124 or the stand-alone 120 and the TCB. The messaging program 124 and the standalone packager 120 always includes an identifying application ID(s) in CSCs said program cause to be created by a TCB. The rendering program 124 and TCB always test for the presence of that application ID(s) (see Figs. 7 and 8) before the receiver 108 can view the message and any attachments. Third party rendering programs do not work with CSCs created by the messaging program because the third party rendering program does not have the proper application ID. By use of the application ID, a rendering program that may be generally be able to process a CSC is prevented from processing CSC from messaging program 116 and stand-alone packager 120.

Solutions to Contextual Problems - Body of the message replaced by non-informative body In one embodiment the messaging program 116 and/or the stand-alone packager 120 causes replacement message to include instruction or directions for obtaining a TCB and/or appropriate rights and controls, perhaps from RM 134. The TCB is software that can be downloaded for use in decoding a message. Using the MAPI functions, the messaging program 116 and/or the stand-alone packager 120 obtains the body of the email message and includes it in the CSC as part of the content. The messaging program 116 and/or the stand-alone packager 120 then replaces that body portion of the email message with either blanks (an empty message) or with user/administrator supplied text (if there is some provided) (see Fi - 7)

Solutions to Contextual Problems - Secure "Reply" capability In one embodiment the messaging program 116, stand-alone packager 120, and/or rendering program 124 provide for the specification and enforcement of rules that specify that the set of "reply" recipients cannot be expanded Reply can be to some or all, but not more than, the list of authorized recipients The set of recipients and the UserlD test that we infer to include in the rules that govern access to the message is constrained to be just those in the original email's recipient list and the sender Even if the email user sends the message m a CSC to some other email address, the other receiving email address won't have a UserlD that is m the rules specified and therefore won't be able to access the message

In one embodiment this is implemented as a protected object within the CSC that is removed from the container by the rendeπng program 124.

Reply capability can be specified with or without decoding of the message such that a reply can be made without a TCB. Without decodmg, the recipient cannot read the body of the message Rules in the reply email limit it to being read by the same set of people who received the original or a proper subset of that group. The email could be delivered to others (perhaps by mistake) but the rules enforced by the TCB would prevent those others from reading the message

Edit capability can be specified as to identified parts of the email. Such that some portions of the header or body of the message can be edited while other portions cannot For example, the attachments could be editable while the email body could not

Reply without Edit capability means that reply text is entered without any edit access to the original email text This is most likely to be done by leveraging the fact that we do have editing capability for the body of emails with the messaging program A rule will allow viewing and replying to the message, but will not allow editing or deleting text m the email body.

Reply with Edit capability is more complex since that implies that the body of the email can be changed This could range from limiting changes to being additions (no modification of existing text but allow m-hne addition) to full edit capability (deleting original text or modifying it). There may be distinct options for those types of controls. When the options include modification and deletion of original text, it is essentially the creation of a new document more so than a forwarding of the original and should imply a SAVE intent for the forwarding author.

Attachments have more complex processing. There are content viewers for a wide variety of attachment file types (e.g., the content viewer from INSO™). These content viewers do not, however, support CSC that are opened by TCBs. Some editors have options for tracking changes (MS Word for example) but these off-the-shelf editors are not used. We could use "Contrast" sorts of tools to identify differences for text but the range of files types is large enough we would need a lot of such tools. The "Contrast" sort of approach is also "after the fact" which is not generally a well-received ergonomics choice. Among the non-limiting example uses of the trusted messaging system disclosed herein is to conduct asynchronous electronic commerce transactions. One non-limiting example is a trusted messaging-based Electronic Data Interchange ("EDI") system. Generally, an EDI system may in part be comprised of a data structure or form with standardized fields. There may be plural forms defined either because there are plural variant forms for a given purpose and/or transaction, and/or there may be many forms-based transactions necessary to accomplish the commerce functions of the system. For example, there may be variant healthcare claim forms that differ in the arrangement and sequencing of the fields. In another example, there may be claim forms and payment forms, the latter resulting in, and/or constituting instructions for a funds transfer system, two non-limiting examples of which are the S.W.I.F.T network and the Automated Clearinghouse ("ACH") system. The trusted messaging system disclosed here provides the basic capabilities of prior art EDI systems. CSCs can be used to securely transport the EDI information from one party to another and to provide authentication and non-repudiation of sending and receiving parties. Using the trusted messaging system disclosed herein, the sender may create rules that govern the access and/or used of field specific information. In one non-limiting example, a healthcare claims form may be sent to a person or process that can only view and/or modify selected portions of the information contained in the form. Such differential access and rights may depend at least in part on rules that are conditional on the presence and/or absence of credential information securely associated with the receiving person or process. Said credential information may be represented, contained, conveyed, and/or stored in various kinds of objects, non-limiting examples of which are digital certificates known to those skilled in the relevant arts and "membership cards" or "membership objects" is, for example, disclosed in aforementioned U.S. patent No. 6,112,181, Shear, et al. The present invention(s) enable "acceptance of terms" using protected digital objects comprised at least in part by HTML, XML, JAVA, and/or Active X code. In addition, one or plural preferred embodiment clearinghouse(s) may handle charges for non-digital goods and services via the payment processing systems interfaces disclosed in the InterTrust Patents. The security of EDI transactions would be enhanced though the use of time-based thresholds such as "sunrise/sunset" parameters, In this non-limiting example, a given EDI transaction would be valid only during a certain pre-specified time interval.

Solutions to Contextual Problems - Secure "Forward" capability

In one embodiment the messaging program 116, stand-alone packager 120, and/or rendering program 124 provide for the specification of rules that grant authority to forward a message. Authority to forward may be limited only to new recipients within a specified set of domains. Domain in this context means the email domain (the part after the @ in the email address). For example, dconley@trustdatasolutions.com is in the domain trustdatasolutions.com. This technique may be used to limit the forwarding to addresses within a company or other organization, for example.

The rights of the original receiver define the maximum rights of anyone the original receiver forwards the message to. Rules may require subsequent receivers get a more limited set of intents. The forward intent can be specified with or without an edit intent (same concepts as with Reply above). The edit intent can be specified as to identified parts of the email, such as: attachments and email body.

Solutions to Contextual Problems - Code Reuse

In one embodiment the messaging program 116 provides for the reuse of the rules profiles and rules selection dialogs found in the messaging program 116 to allow creation of a CSC for any file. These dialogs are used in a stand-alone packager. This allows the stand-alone packager 120 to apply rules governing their use to any file whether sent as email attachments or not. In another embodiment, The code that invokes the packager routine and rules compiler routine of the messaging program is also reused. Since there isn't a "recipients" list per se with files, we add dialogs to prompt for authorized UserlDs or memberships to the stand-alone packager. The file packager works both as a plug-in to some MS Office products (e.g., Word, Excel, etc.) in addition to being available as a standalone executable, which can prompt for the file to be packaged (most software routines are reused across these two settings).

Plug-in to many email clients. For the purpose of viewing the secured package as received by many different types of email clients, we have built the presently preferred embodiment of a rendering program on the common Messaging Application Programming Interface (MAPI) implemented by all the major email clients; however, other rendering program embodiments are also envisioned as well.

Solutions to Contextual Problems - Usage (view, print, save, etc.) tracking/auditing.

Usage can be both governed in terms of who is allowed to use (view, print, save are separate types of usage intents with separate authorization rules) and what if any audit trail (usage records) are created to document this (see Fig. 8).

Solutions to Contextual Problems - Authentication of intended recipient

In one embodiment the messaging program 116, stand-alone packager 120, and/or rendering program 124 utilize the user ID of the TCB (i.e., UserlD) and Password for authentication of the user.

Support degrees of authentication, including one or more of the following: password, biometrics, cardkey, and others. Each of these techniques require our rendering programs to test for a higher level of authentication. In the default case, we trust the UserlD PASSWOP - scheme of authentication used by the TCB. When additional authentication is required, we note this requirement in the packaged CSC (as a value in an additional attribute on the container object (or perhaps the content object)). Our Rendering program then tests for that attribute value to decide if additional authentication is required.

There are at least two different non-limiting choices for managing the additional authentication. One choice is to place the signature(s) to match (biometric or other) inside the CSC and test against them before invoking the other authorization tests. A second choice is to interact with an authentication service (perhaps via a directory service) which would manage the signature(s) to be tested against. In any case, we would interact with the biometric device or cardkey or other in the conventional ways suggested by the makers of those products.

Solutions to Contextual Problems - Full usage rights for email "originator"

In one embodiment the messaging program 116, stand-alone packager 120, and/or rendering program 124 provide for the specification and enforcement of full usage rights of the embedded content may always be granted to the originator of the new secured email. Rule may be applied by default to allow the "originator" full access to the content regardless of additional specified rules. The originator must have an option to allow "sunset" emails to become unreadable by the originator also.

While the present invention has been described with reference to certain preferred embodiments, it is to be understood that the present invention is not to be limited to such specific embodiments. Rather, it is the inventor's intention that the invention be understood and construed in its broadest meaning as reflected by the following claims. Thus, these claims are to be understood as incorporating and not only the preferred embodiment described herein but all those other and further alterations and modifications as would be apparent to those of ordinary skill in the art.

Distributed Trust Environment

Example uses of the Distributed Trust Environment ("DTE"): as a general purpose platform, the Distributed Trust Environment may be deployed to support a multitude of tactical and strategic military, diplomatic, and/or political objectives. In one example, digital information may be persistently protected using the facilities of the DTE. More specifically, TCBs and associated information security and trust applications provide mechanisms to effectively control dissemination, access, and/or use of military-related digital information, non-limiting examples of which include imagery and geospatial digital information within one or more levels of security and trust, within (re)defmable limits by class of digital information user.

A feature of the invention(s) disclosed herein is that certain TCB technologies originally developed to provide a secure and trusted context for commerce (eBusiness) are equally applicable to high-security situations such as for military uses including battlefield uses. Another feature of the present invention(s) is that eBusiness TCB capabilities can be applied to monitoring and documenting battlefield use of imagery and geospatial digital information.

In one example application, the DTE and its TCB technologies may be used to simulate a classified environment with a presently unclassified commerce system, including governing the secure and trusted access to protected digital information through usage rules that may vary according to military/diplomatic coalition class and/or status.

In a hypothetical real-world example, an non-limiting demonstrable real-world example may include the use of the Distributed Trust Environment for military applications to address the following example requirements and or situations: (i) requirement to quickly disseminate U.S. imagery and geospatial information to a variety of battlefield related participants with multiple usage rules that vary according to coalition status and/or class membership; (ii) among a coalition group in whom there are varying degrees in confidence, non-limiting examples of which may include (a) representative battlefield participants; (b) unified commands; (c) tactical commands and units; (d) NATO; (e) coalition partners (long-time and onetime allies); and (f) UN and other non-governmental organizations ("NGOs"); (iii) create secure and trusted audit trail for monitoring actual use of digital information, including without limitation imagery and geospatial products; (iv) aid in planning and resource allocation, including communications resources and/or digital information resources; and (v) establish a dynamic feedback loop that is comprised at least in part of information, judgments, conclusions based on the analysis of actual digital information use, including without limitation: number & type of end users, frequency and duration of use, sources utilized, timeliness, preferred digital information form formats, etc.

The inventions may be better understood though the following non-limiting example scenario and embodiment that is based upon a hypothetical renewal of conflict with Iraq over its military actions against Kuwait at some future point. Coalition partners participating in the conflict (any number of coalition partners may be participants in the system(s) disclosed herein: UK, Canada, Saudi Arabia, and Kuwait. Coalition partners not participating in the conflict Syria and France. By-stander countries to be influenced (any number of by-standers countries may participate in the system(s) disclosed herein: Iran, UAE, Jordan, and Russia. US action is undertaken with support of UN. Active involvement by Red Cross and World Health Organization and potentially other non-governmental organizations (NGOs). Active program of public disclosure of some or all imagery and maps as may be decided by the relevant authorities. All country names, tactical situations, strategies, scenarios, rules governing access and/or use of protected digital information, and/or rules governing any consequences of authorized use and/or access are entirely hypothetical and are presented herein only to better illustrate the diverse capabilities of the Military Distributed Trust Environment.

Operational Concepts The operational concepts underlying the example disclosed herein includes (without limitation) 1. One assumed example environment includes client server and/or distributed, peer-to-peer applications, services, and network connections

2 Residing on networks may be one or more sources of protected battlefield related digital information, including imagery and geospatial libraries of historical digital information and/or realtime and/or near-realtime digital information sources Non-limiting examples of digital information include battle-related messages, orders, intelligence, and any other battlefield relevant digital information

3 Level of access Different levels of secret clearance and/or access may be supported by, for example, digital credentials indicating level of secret clearance, cryptographicly Secure Containers ("CSC") having cryptographic algorithms and/or parameters that vary according to the secrecy authoπzation of the intended recιpιent(s)

4. Access and/or usage restrictions applied to some recipients and/or category of digital formation (l) Specific classes and/ or types of digital information, (n) Rules that restrict use to "Display Only", (in) Rules that prevent printing and/or storage of protected battlefield related information, (iv) Rules that make protected battlefield information available only at prescribed times/peπods.

5. Authoπzed users and/or recipient of protected battlefield digital information A participant's access to hbraπes and/or sources of protected battlefield information may be conditional on the presence and/or absence of pre-specified digital credential objects (MCO).

6. Certain participants and/or classes of participants may retrieve only products they are authorized to access and use them subject to rules governing usage

In our preferred embodiment, the Distributed Trust Environment is a distributed, peer-to-peer application for governing the authoπzed access and use of digital mformation in any format in a military context, up to and including hot battlefield contexts The DTE relies on a Trusted Computing Base (TCB) to evaluate requests to access protected information and to then make that information available to the requestor, non-limiting examples of which include individuals, both military and civilian, devices, appliances, software applications, processes, and artificial intelligences The DTE also relies on cryptographically secure software containers to protect digital information and/or rules governing authorized use from unauthorized disclosure, use, and/or modification.

The features and capabilities of the DTE include, but are by no means limited to (l) Automated means for restricting access to protected digital information to requestors having one or more Military Credential Objects (MCO), nonlmutmg examples of which include so-called digital certificates and "membership cards" disclosed in U.S. Patent No. 6,112,181 to Shear et aLEnsuring that only authorized requestors access and use protected digital information, (n) Digital information rendenng components that ensure that only authoπzed uses of digital information take place; (in) Digital mformation usage auditing and reporting with non-repudiation; and (iv) Other features and functions noted elsewhere this document. Credential-based Access Control

Given the magnitude, geography and political sensitivity of a military conflict, different national and/or regional alliances dictate different coalition alignments. Depending in part upon the particular coalition alignment, varying degrees of trust and access may be required for various national or regional participant and with those participants, for various individuals, organizations, military and diplomatic elements, and other participating entities.

In the preferred embodiment, a protected digital data structure that we refer to as a "Military Credential Object" may represent, signify, warrant, and/or attest to any one or more identity characteristics, attributes, and/or memberships. We refer to these identity characteristics, attributes, and/or memberships equivalently as "memberships." The MCO contains data elements for the name of the MCO, one or more memberships, information that may include cryptographic information indicating the authority that associated the membership with the entity, and information that may include cryptographic information indicating the entity with whom the one or more memberships are associated, and any other fields providing relevant information. Since the MCO is never released from or directly exposed for manipulation outside the DTE, the DTE does not require the calculation of either integrity check, such as a checksum or cryptographic message digest, and/or the validation of an integrity check using cryptographic means.

Membership Structure In one non-limiting example, seven fundamental membership groups are defined together with an overall determination of their access to battlefield-relevant digital information as follows: (i) Trusted Allies (Highest Access - Full Functionality); (ii) Fighting Coalition Partners (Operational Combat Access); (iii) By- standing Coalition Partners (Non-Combat Access); (iv) By-standers to Be Influenced (Informational Access); (v) Affiliates Not-Participating (Operational Access Not Allowed); (vi) Humanitarian Affiliates (Focused Dissemination); and (vii) Public/Media Outlets (Controlled/Balanced Dissemination).

The first four membership groups represent the direct sphere of influence surrounding the actual battlefield or other related military-relevant operations. These members have varying degrees of access to protected digital information. Access to protected digital information can range from full access down through viewing, printing modifying, local storage and printing. The lowest or most restrictive access (other than total denial of access) is to view (display) the digital information, to execute a software executable or interpretable, to play digital audio, and to present/play digital video information.

The fifth membership, Affiliates Not-Participating, is the null group used to demonstrate that this membership group cannot open a cryptographically secure container even though they may have an operable system and under other circumstances would have access to information. Israel, for example, might be a good candidate member. To enhance this point, this membership (and all memberships) could be given access to the Public/Media files as well.

Two other non-limiting example classes may also be participants in and/or receive battlefield- relevant protected digital information: (1) Humanitarian Affiliates - Image files and other digital information could be disseminated, with full or partial access, to assist in the logistic and support processes associated with a humanitarian situation caused by the military conflict. These protected files could contain photographs or satellite images of refugee migration paths and logistical plans. Dissemination could be specifically controlled by MCOs as well as time/access controls on the encapsulated content packages provided by the Command authority to Humanitarian organizations. Though most members could have access to the Humanitarian information, access to this protected digital information should not be assumed to be a default condition for all members. It should be selectable since in combat situations, refugees, and their support, at times have become a political football. The Command authority may want to restrict access accordingly.

(2) Public Media — Image files, news reports and other protected digital information could be disseminated to assist in the public relations and news control of a combat situation. Though declassified and informational in the public context, the dissemination, timing, authenticity and balanced access to combat news is probably a significant issue to the Command authority. By controlling Military Credential Objects and deploying them to "authorized" organizations, Command authority news reports can be launched at a fixed time, verified as authentic and focused to trusted outlets. During a conflict, Internet spoofing is fully anticipated as a disinformation vehicle by an enemy. News releases from an authorized and authenticated source to a predetermined, authorized, and authenticated membership group could minimize the use of the Internet as a means of an enemy disseminating false or misleading information.

Class Membership Granularity (Depth) Within each membership grouping or class, individual entities can be identified and unique content streams can be directed to that individual entity. Inside the "By-standers to be influenced" membership group, for example, participants associated with each country could be individually identifiable using an appropriate MCO or combination of MCOs. A practical real world example would be the country of Jordan. Due to the proximity of Jordan to Israel, the Command authority may want to individually encapsulate a communique to Jordan that only Jordan, or a selectable group and Jordan, would have access to.

Class Membership MCO Redistribution

Using the processes associated with class membership definition and deployment, members could be allowed to redistribute their one or more Military Credential Objects to authorized and authenticated recipients. For example, in the case of the UK, they could be allowed to redistribute their MCO(s) to their units m the field. This capability is significant because though coalition combat is "cooperative", each country wants to maintain its control over its own military command process. Giving the UK the ability and requirement to distribute then^* Military Credential Objects could reduce the πsk that in the present example, the US/UN Command authority would be accused of withholding mformation or access to information.^' The above example shows the UK (a full access partner) having MCO redistribution capabilities, MCO but redistribution capability applies to all membership groups as well. For the purposes of the demonstration, governmental membership redistribution should be limited to only the US, UK and Canada.

In the case of the Public/Media, the appropnate MCOs would be given to organizations including, but not limited to UPI, BBC, AP, MS-NBC, CBS, and CNN etc Each, in turn, would redistribute the appropriate MCOs mside their own information, security, and trust infrastructures

Class Membership/MCO Lifecycle (Sunnse/Sunset)

In addition to digital mformation protection provided by the TCB and its associated applications and services, MCOs can also be used to add an additional layer of access protection in the combat scenaπo. In traditional battle operations, the encryption process usually changes every four to six hours Adapting the

MCO process to this methodology could be quite beneficial. Using a timed sequence to the validity peπod of physical secuπty tokens, including encryption tokens or cards, the Command authoπty may protect the intelligence process from compromise In the event a forward unit is overrun, and the encryption tokens are captured, in less than four hours the card expires and secure communications are reestablished Generating membership cards with fixed penods of operation could provide the same sort of combat adaptability that exists in traditional cipher processes The concept would be that even if a machine (a forward deployed laptop) were captured, MCO updates would render the machine useless and out of the πsk profile for the Command authoπty

Using the preferred TCB embodiment, the operational MCOs could be structured on the following single day rotation (all times GMT/Six Hour Rotation) (l) Blue MCO Deployment (All Classes), valid 0000 to 0615, (u) Green MCO Deployment (All Classes), valid 0600 to 1215, (in) Red MCO Deployment (All Classes), valid 1200 to 1815, and (iv) Black MCO Deployment (All Classes), valid 1800 to 0015

Digital Information Protection The following section describes some additional features and benefits of the present mventιon(s).

Digital Information Type

In the preferred DTE embodiment, any kind, type, or format of digital mformation may be protected to ensure that access and/or use is in accordance with rules securely associated with the protected information. For example, m addition to image and geospatial files, most battlefield processes include a variety of text-based elements that align with or expound on the image information. Additionally, depending upon the nature of the "end user" application (the image rendenng application), unique file types may be generated as well. The operational image type may be propπetary to a specific military or national secuπty application Images, video, audio, software, multimedia may contain information in hidden channels using watermarking technologies known and/or presently unknown (classified) publicly. Information carried in wartermarks may be any kind of information that can be encoded using the available watermarking bandwidth, for example, watermarked information that indicates using cryptographic means the integrity of the watermarked file, its creator and/or owner, and any control information that may be used by the preferred embodiment DTE as disclosed in U.S. Patent 5,943,422, Van Wie et al. However, the image type disseminated to the Humanitarian or Public/Media members may be a standard file type (JPEG, GIF, Bit Map, Text etc.) The same or different watermarking methods may be used for these kinds of files as for those distributed to parties such that a much higher level of security and trust is required. Generating digital information in these file types or other common file types would be done by a function in the Command Authority.

Digital Information Delivery System

A. A Demand Driven Digital Information Distπbution (3DID) System

Protected information may be transmitted over any channel capable of carrying the required bandwidth. In one non-limiting example, is the distribution system may be a satellite-based high rate burst transmission channel. In this example, all systems in the field may have download access, capacity and processing capability. Securely encapsulated digital information could be packaged and delivered using such a transmission system. One of the distinct values of our process is that CSCs can be delivered m "Broadcast" mode if required. Because MCOs may control access to the CSCs locally, so that even if a CSC was received at a location not intended by the sender, access could not occur. This broadcast burst "preemptive" delivery could be an important military advantage in a hot conflict where the example satellite-based high rate burst transmission channel goes into full transmit mode. In these circumstances, the protection provided by CSCs, rules making access at least m part conditional on the presence and/or absence of combinations of MCOs, and a TCB to evaluate and enforce the rules when access is required probably provided much significantly increased security, reliability, and trustedness. B . Elements of a Deployed DTE

For the demonstration we should comply with this assumed content and CSC delivery process, however we can also conceptualize how other systems initiation or delivery vehicles could be used. An example would be the use of CD based systems that are forward deployed with the combat units. These CSC protected CDs could have a base set of images and battle plans that set the baseline. Depending upon the application, these could be the templates upon which "Modify/Overlay" images could be rendered. This could be used in a battlefield configuration where the CDs are the base images (accessed through Membership) and the updates or overlays are delivered via a 3DID system. The updates/overlays are delivered in CSCs and controlled by Memberships as well. The CD configuration could apply to a small "infield" unit that had minimal local storage (e.g., A hand held unit with a CD reader, max RAM, Fast Processor, Hard Drive with OS, IRP and a Single Application and COM/LPT ports only.)

C. Public/Media Delivery

The primary difference between the operational CSCs and the Public Media CSCs is in the classification level of the contents. The Public/Media CSCs would contain non-classified material but they still require CSC control. The reason to encapsulate and disseminate unclassified CSCs is to control the timing of the release of information and to ensure authenticity. The Public/Media Memberships would allow opening a CSC at the prescribed time and the recipient would know that it came only from the Command authority. By default all memberships should be allowed access to the Public/Media CSCs.

D. Email/Web Back-Up/Redundancy

Though not part of the demonstration application, it should be noted that in the event that the 5D system is down or inaccessible to one or all members, the web and traditional email systems could be used to send CSCs to the field. Under all circumstances, the web and email could be used to deliver the Public Media CSCs.

Content Lifecvcle Each element of content could be assigned a date/time driven lifecycle. At generation, the encapsulated information could have a Sunrise and Sunset (SR SS) parameter that could be set by the Command authority. In most cases, the SR/SS parameter would be utilized and a predetermined time "No earlier than" access and "Access Denied After" value would be set. In the case of base overlays (standard geographic image with no overlays or intelligence attached) the SR/SS value could be set to immediate access and infinite life. In a hot delivery, content would be defaulted to an immediate access option.

Controlled Actions

In several embodiments, the DTE TCB enforces rules specifying which actions, "verbs", or "intents" will be allowed. In one embodiment disclosed in US patent No. 5,715,403 issued to Stefik on 2/03/1998; US Patent No. 5,638,443 issued to Stefik et al. on 6/10/1997; US Pat. No. 5,634,012 issued to Stefik et al. on 5/27/1997; and, US Pat. No. 5,629,980 issued to Stefik et al. on 5/13/1997 which are incorporated herein by reference., a Digial Property Rights Language is the means for expressing governed actions. U.S. Patent No. 5,892,900 to Ginter et al., discloses a Rights Management Language, while the presently prefeπed embodiment uses "intents" to describe governed actions and/or their consequences. The DTE TCB can govern a broad range of actions, verbs, and/or intents, including, but not limited to: Access/Display

A digital information rendering process akin to the View intent.

A. Modify/Overlay In an imaging application whose actions are governed by the TCB, "ModifyOverlay" is a base imaging application function that allows local users to overlay and modify the image files once retrieved and decrypted from the CSC.

B. Store

A governed action like "Save/Save As." Allows authorized users to store a copy of the information, especially a copy that has been modified/overlaid, in a CSC.

C. Print

A governed action akin to the Print intent.

D. Copy

A governed action that allows local users to select, cut and paste all or part of files once released and decrypted from the CSC.

E. Forward

Forward may refer to the ability of a local user to repackage (CSC) and transmit the files from the local location. This may mean access to a local packager that takes the image information (possibly after modification), assigns some DRM rules and repackages it for transmission. A non-limiting example would be a battlefield update process. A CSC arrives at the local system, is opened and annotated with the latest local information (e.g. 57MM Guns marked by the X's, 43MM marked by the Y's). The local user would repackage this information and transmit it to other elements and the Command authority.

Conceptually this forward capability could be controlled by allowing the local DRM packager to operate subject to membership parameters. The DRM packaging process may exist in all distributed applications, however it is not accessible unless the membership authorized it.

Content Usage Auditing & Evaluation

The following section describes the utilization parameters included in the prefeπed embodiment for tracking usage. A. Immediate versus Deferred Usage Reporting

In the preferred embodiment of the DTE, a Commander and/ or other authorities may choose between immediate usage gathering (processing) and deferred usage gathering (processing). Of course, immediate processing could become a communication bottleneck depending upon available bandwidth. However, a Commander would also like to know if a field unit received and opened a particular file. In a secure channel, the communication of CSCs containing usage information may entail a transport accessible parameter indicating the communications priority assigned to the CSC communication task.

B . Number & Type of End Users

An example Command authoπty way request that the DTE provide a usage report that gathers identity and membership elements about the end user. Information aggregated at the Command authority would provide the analysis element.

C. Frequency of Use Report

The DTE may provide a usage report that gathers initial and subsequent access events including, for example, the number of times the file was printed etc. Information aggregated at the Command authority would provide the analysis element.

D . Duration of Use Report

The DTE may provide a usage report that gathers information pertaining to the peπod of time that a file was open for each access event. Information aggregated at the Command authority would provide the analysis element. E. Authentication

The issue of authentication is important to intelligence and its use m combat operations. A variety of authentication elements may be involved.

The mvention(s) disclosed herein may be used to create a wide variety of battlefield relevant applications. The following describes certain elements of one non-limiting DTE application. Content Files

Operational Content CSC - Contains a classified image whose access (display) and utilization are driven by the membership rules. The image is combat operations related picture. Not accessible by members of the Affiliates Not-participating, Humamtanan or Public/Media groupings. Use of the content (Modify, Overlay, Print etc.) will be governed by rules affecting each membership group. Purpose: Deploy a fully operable content file with restricted use and access as directed by Membership rules. Access and use restπcted based on predetermined relationship to the combat operations. (See Fig. 11)

Humanitarian Content CSC - Contains a classified image whose access (display) and utilization are driven by the membership rules. The image could depict a Humanitarian event, possibly a refugee migration. Membership access is selectable by the Command authority at the time of generation. Not necessarily available to all members and definitely not available to the Public/Media members. Use of the content

(Modify, Overlay, Pπnt etc.) will be governed as directed by the Command authonty . (See Fig. 11) Purpose: Deploy a limited focus content file with restricted use and access as directed by Membership rules. Access and use limited to other non-combat related issues (refugee support and exploitation). (See Fig. 11)

Restπcted Access CSC - Contains a classified image whose access (display) and utilization are driven by the specific membership rules. The image could depict a non-combat event, possibly an Israeli troop deployment/staging on the West Bank of the Jordan River. Membership access is specifically directed by the Command authority at the time of generation. Available only to the Trusted Allies and the Specific affected Member (Jordan). Not available to any member outside these limits. Use of the content (Modify, Overlay, Print etc.) will be governed as directed by the Command authority. (See Fig. 11) Purpose: Deploy a specifically focused content file with directed use and access as governed by Membership rules. Under normal circumstances, Jordan can only display files. Only Jordan and the Trusted Allies are allowed access. In this case, Jordan is allowed full access and use of the directed file. (See Fig. 11)

Public Access CSC - Contains an unclassified image/text file that is intended for full public disclosure and dissemination. The image/text could depict or describe any event, possibly medal award ceremony. Membership access is controlled in order for the Command authority to affect dissemination time and source authenticity. All membership groups would also be provided access to this file. Purpose: Deploy a public relations/media content file whose dissemination timing and source authenticity can be controlled by the Command authoπty. At a fixed future time, only those with authorized Membership status can open the file. Assumed to be available to all members in the chain of command. (See Fig. 11) While the present invention has been described with reference to certain preferred embodiments, it is to be understood that the present invention is not to be limited to such specific embodiments. Rather, it is the inventor's intention that the invention be understood and construed in its broadest meaning as reflected by the following claims. Thus, these claims are to be understood as incorporating and not only the preferred embodiment descπbed herein but all those other and further alterations and modifications as would be apparent to those of ordinary skill m the art.

APPENDIX 1 XML-Encoded Default Rules Profile

Email_Settings x lns :dt="urn: schemas-microsoft-com-. datatypes'^ <Individual>

<Ind_Print dt:dt="int" xmlns •.dt= "urn:scliemas-microsoft- com: atatypes " >l</lnd_Print>

<lnd_View dt:dt="int" xmlns :dt="urn:schemas-microsoft- com: datatypes " >l</lnd_View>

<Ind_Edit dt:dt="int" xmlns :dt= "urn: schemas-microsoft- com: datatypes" >0</lnd_Edit>

<Ind_Save dt:dt="int" xmlns :dt= "urn: schemas-microsof - com: datatypes " >l</lnd_Save>

<Ind_ eply dt:dt="int" xmlns : dt="urn: schemas-microsoft- com: datatypes " >0</Ind_Reply>

<Ind_For ard dt:dt="int" xmlns :dt="urn:schemas-microsoft- com: datatypes " >0</Ind_Forward>

<Ind_Sender_Name dt :dt="string" xmlns :dt="urn: schemas- microsoft-com: datatypes ">Default</lnd_Sender_Name>

<Ind_Sender_Name_Override dt:dt="int" xmlns :dt= "urn: schemas- microsoft-com: datatypes " >l</Ind_Sender_Name_Override>

<Ind_Subject dt :dt="string" xmlns :dt= "urn: schemas-microsoft- com: datatypes" >TRUSTDATA Secure Message</Ind_Subject>

<Ind_Sub ect_Override dt:dt="int" xmlns :dt="urn: schemas- microsoft-com: datatypes " >l</lnd_Subject__Override>

_<Ind_Sunrise dt :dt="dateTime" xmlns : dt= "ur : schemas-microsoft- com: datatypes" >2000-09-25T12 :12 :41.000</Ind_Sunrise>

<Ind_Sunset d :dt="dateTime" xmlns : dt="urn: schemas-microsoft- corndatatypes">2000-12-14T12 : 12 : 37.000</lnd_Sunset>

</Individual> </Email_Settings> Copyright © 2000 TrustData Solutions Corporation. All Rights Reserved. APPENDIX 2 XML-Encoded Healthcare Provider Rules Profile

<Email_Settings xmlns :dt= "urn: schemas-microsof t-com -. datatypes " > < Individual >

<Ind_Print dt:dt="int" xmlns :dt= "urn: schemas -microsoft- corn : datatypes " > 0 < / Ind_Print >

<Ind_View dt:dt="int" xmlns :dt= "urn: schemas-microsof t- com: datatypes ">l</Ind_Vie >

<Ind_Edit dt:dt="int" xmlns :dt="urn: schemas-microsof t- com : datatypes " > 0 < / Ind_Edi t >

<Ind_Save dt:dt="int" xmlns :dt= "urn: schemas-microsof t- com: datatypes ">l</lnd_Save>

<lnd_Reply dt:dt="int" xmlns :dt= "urn: schemas-microsof - com : datatypes "> 0 < / Ind_Reply>

<Ind_Porward dt:dt="int" xmlns :dt= "urn: schemas -microsoft - com : datatypes "> 0 < / Ind_For ard>

<Ind_Sender_Name dt :dt=" string" xmlns :dt="urn: schemas- microsof t - com : atatypes " >Dr . XYZ</ Ind_Sender_Name>

<Ind_Sender_Name_Override dt:dt="int" xmlns : dt= "urn: schemas- microsof t - com : da atypes " >1 < / Ind_Sender_Name_Overri de >

<Ind_Subject dt :dt="string" xmlns :dt= "urn: schemas -microsoft- com: datatypes ">HIV Results</Ind_Subject>

<Ind_Subject_Override dt:dt="int" xmlns :dt= "urn: schemas- microsof t-com : datatypes ">l</lnd_Subject_Override>

<Ind_Sunrise dt :dt= "dateTime" xmlns :dt= "urn: schemas-microsof t- com: datatypes" >2000-09-18T10: 26: 13.000</lnd_Sunrise>

<Ind_Sunset dt :dt=" dateTime" xmlns :dt="urn: schemas-microsof t- com: datatypes" >2001-02 -08T10 :26:08.000</lnd_Sunset>

</lndividual> </Email_Settings> Copyright © 2000 TrustData Solutions Corporation. All Rights Reserved. APPENDIX 3 XML-Encoded Healthcare Patient Rules Profile

<Email_Settingsxmlns:dt="um:schemas-microsoft-com:datatypes"> <lndividual>

<Ind_Print dt-.dt="int" xmlns :dt= "urn: schemas-microsof t- com: datatypes ">l</lnd_Print>

<Ind_View dt-.dt="int" xmlns :dt="urn:schemas-microsoft- com: datatypes" >0</lnd_View>

<Ind_Edit dt:dt="int" xmlns :dt="urn:schemas-microsoft- com: datatypes ">0</lnd_Edit>

<Ind_Save dt:dt="int" xmlns :dt= "urn: schemas-microsof t- com: datatypes ">l</lnd_Save>

<Ind_Reply dt:dt="int" xmlns :dt= "urn: schemas-microsof t- com : datatypes " >0< /Ind_Reply>

<Ind_Forward dt:dt="int" xmlns :dt="urn:schemas-microsof t- com : datatypes " >0< /Ind_For ard>

<Ind_Sender_Name dt :dt=" string" xmlns :dt=" urn: schemas- microsof t-com:datatypes" >John Doe</lnd_Sender_Name>

<Ind_Sender_Name__Override dt:dt="int" xmlns :dt= "urn: schemas - microsoft - com : dat types " > 1< /Ind_Sender_Name_Override>

<Ind_Subject dt :dt="string" xmlns :dt= "urn: schemas-microsof t- com: datatypes ">Payment Method</Ind_Sub ect>

<Ind_Sub ect_Override dt:dt="int" xmlns :dt= "urn: schemas- microsof t-com : datatypes ">l</Ind_Subject_Override>

<Ind_Sunrise dt :dt=" dateTime" xmlns :dt= "urn: schemas-microsof t- com : datatypes ">2000 -12 -06T11: 10 :32.000</Ind_Sunrise>

<Ind_Sunset dt :dt= "dateTime" xmlns :dt="urn: schemas -microsoft- corn -.datatypes ">2000-12 -20T11: 10 : 36.000</lnd_Sunset>

</ Individual > </Email_Settings> Copyright © 2000 TrustData Solutions Co oration. All Rights Reserved.

Claims

What we claim are:

CLAIMS 1. A system for controlling digital information from a sender to one or more recipients, comprising of: a packager for packing digital information in accordance with a sender-specified set of rules and access level information; one or more secured delivery engines for delivering said packed digital mformation from said sender to said one or more recipients; and a rendering program for manipulating said delivered digital information in accordance with said rules and said access level information associated with each of said recipients.

2. A system as recited in claim 1 further comprising a monitoπng program for monitoring use of said digital information.

3. A system as recited in claim 2 further comprising a reporting program for reporting the use of said digital information.

4. A system as recited m claim 2 wherein said monitoπng program may monitor one or more of the following types of information: types of users, number of users, frequency of use, time of use, duration or use and type of use.

5. A system as recited claim 1 wherein said rules may authorize one or more of the following actions: view, modify, overlay, store, pπnt, copy, and forward.

6. A system as recited in claim 1 wherein said access level information is implemented as membership information.

7. A system as recited m claim 6 wherein said membership information being a credential object having a protected data structure.

8. A system as recited in claim 7 wherein said credential object being redistributable to other recipients.

9. A system as recited m claim 1 wherein access to said digital mformation is time-controlled.

10. A system as recited in claim 1 wherein said system is a military-grade system.

11. A military system for controlling digital information from a sender to one or more recipients, comprising of: a packager for packing digital information in accordance with a sender-specified set of rules and access level information; one or more secured delivery engines for delivering said packed digital information from said sender to said one or more recipients; a rendering program for manipulating said delivered digital information in accordance with said rules and said access level information associated with each of said recipients; a monitoring program for monitoring use of said digital information; and a reporting program for reporting the use of said digital information.

12. A system as recited in claim 11 wherein said monitoring program may monitor one or more of the following types of information: types of users, number of users, frequency of use, time of use, duration or use and type of use.

13. A system as recited in claim 11 wherein said rules may authorize one or more of the following actions: view, modify, overlay, store, print, copy, and forward.

14. A system as recited in claim 11 wherein said access level information is implemented as membership information.

15. A system as recited in claim 14 wherein said membership information being a credential object having a protected data structure.

16. A system as recited in claim 15 wherein said credential object being redistributable to other recipients.

17. A system as recited in claim 11 wherein access to said digital information is time-controlled.

18. A military system for controlling digital information from a sender to one or more recipients, comprising of: a packager for packing digital information in accordance with a sender-specified set of rules and membership information; one or more secured delivery engines for delivering said packed digital information from said sender to said one or more recipients; a rendering program for manipulating said delivered digital information in accordance with said rules and said membership information associated with each of said recipients; a monitoring program for monitoring use of said digital information; and a reporting program for reporting the use of said digital information.

19. A system as recited in claim 18 wherein said monitoring program may monitor one or more of the following types of information: types of users, number of users, frequency of use, time of use, duration or use and type of use.

20. A system as recited in claim 18 wherein said rules may authorize one or more of the following actions: view, modify, overlay, store, print, copy, and forward.

21. A system as recited in claim 18 wherein said membership information being a credential object having a protected data structure.

22. A system as recited in claim 21 wherein said credential object being redistributable to other recipients.

23. A system as recited in claim 18 wherein access to said digital information is time-controlled.