AU761129B2 - Self-destructing document and E-mail messaging system - Google Patents

Description

S&F Ref: 452073D1

AUSTRALIA

PATENTS ACT 1990 COMPLETE SPECIFICATION FOR A STANDARD PATENT

ORIGINAL

Name and Address of Applicant: Actual Inventor(s): Purdue Pharma LP 100 Connecticut Avenue Norwalk Connecticut 06856 United States of America Howard R Udell Stuart D Baker Cary S Kappel Greg M Sherman William Ries Spruson Ferguson St Martins Tower 31 Market Street Sydney NSW 2000 ee ee oeooe *oo °eooe .1111.

.1 11 eooee Address for Service: Invention Title: Self-destructing Document and E-mail Messaging System The following statement is a full description of this invention, including the best method of performing it known to me/us:- 5845c SELF-DESTRUCTING DOCUMENT AND E-MAIL MESSAGING SYSTEM This app lication claims priority of United States Provisional Application Serial No.

60/049,853, entitled Self-destructing Document and E-mail Messaging System, filed June 17, 1997, the entire disclosure of which is hereby incorporated by reference.

Field of the Invention The present invention relates to the field of electronically created documents.. including electronic mail ("e-mail") messaging, and to the field of document retention and deletion.

Backgrund of the Invention E-mail messaging systems are widely used by businesses and individuals throughout the world. E-mail systems allow a user to send electonic mes sages to other users, and :to receive electronic messages fromn other users. An e-mail system can be configured to provide messaging services to users connected to a local area network (LAN), and can be configured to allow users to send/receive messages to/from users outside the LAN via an external network such as the Internet. E-mail systems also allow users to save, copy, and forward messages received over the e-mail system.

25 The ease with. which e-mail systems allow. users to save, copy, and forward messages has had the unintended consequence of hampering document retention policies.

Typically, a document retention policy is implemented by a business to insure that documents generated or received by the business are retained for a specified period of time and then destroyed. Moreover, different document retention periods may be specified for different types of documents. One of the goals of a document retention policy is to provide a systematic method for retaining and destroying documents so that the business can identify with some certainty which classes of documents from a given time period still exist An effective document retention policy is also valuable- in the context of litigation. In such a context it is important that a business has a consistent policy regarding the retention and destru ction of documents, and that the business implements this policy.

For example, if a business' document retention policy states that letter are to be retained for a period of three years, and if it consistently follows this policy, it will be a 2 less vulnerable to a charge that a particular 5-year-old letter was destroyed because the letter was harmful to the business' litigation position. In addition, if the document retention policy is not consistently followed, and only some documents from a particular time period are discarded, it is possible that the remaining documents will provide an incomplete or inaccurate picture of events occurring during that time.

Systems that enforce document retention policies with regard to computer files are-well known. Typically, these systems periodically scan the files in the networkand delete files which were created prior to a specified date. Since such systems operate on a network, however, they cannot delete files which are stored on the hard drives of individual computers. In order to access these files, a document retention program must be installed on each individual computer. However, even if the document retention system is installed on each individual computer, the system will still be unable to delete files that are stored on floppy disks or other external media. Moreover, these systems cannot delete files which have been transferred to computers outside of the network via e-mail. Thus, for example, files which have been transferred to an employee's home computer or laptop, or to a third party, will not be deleted by conventional document retention systems.

Summary of the Invention In accordance with a first embodiment of the present invention, a self-destructing o, document and e-mail messaging system is provided that automatically destroys documents or e-mail messages at a predetermined time by attaching an executable module such as a "virus" to the document or e-mail message.

Computer viruses are well known. Generally, a computer virus is a portion of executable code or program which attaches itself to a host file. For example, "appending viruses" operate by attaching themselves to the end of a host program and causing the host program to execute the virus code prior to execution of the host program. In contrast "prepending viruses" attach themselves to the beginning of the host program. Other types of viruses are located in interior portions of the host program. Another classes of viruses are known as "macro" viruses. These viruses are macros embedded in text documents which can be configured to execute whenever the document is opened, created, or saved. Typically, the term Trojan horse is used to refer to a virus which remains with its host file or program, and does not travel to other files or programs.

In accordance with the first embodiment of the present invention, an executable module in the form of a Trojan horse is attached to a file (such as an e-mail message or document) when it is created. The executable module contains a portion of executable code or an executable program which instructs the computer to overwrite and/or delete the file to which the executable module is attached at a desired time. In this manner, the executable module sets a limit on the lifetime of the document or e-mail message.

Since the executable module is attached to the file, it will travel with the file even when the file is copied, forwarded, or saved to disks or tape drives.

In accordance with a further aspect of the first embodiment of the invention, the executable module executes each time that a file to which it is attached is opened. The executable module determines whether a condition precedent to file deletion has been met. If the condition precedent is met, the executable module instructs the computer to overwrite the file with null data, and then to save, close or delete the file.

In this manner, the present invention provides a number of advantages over prior art systems. For example, since the executable module is attached to the file and is executed whenever the file is opened, the system according to the present invention can enforce a document retention policy even if the file has been stored on external media such as floppy disks, or on a non-network computer. This is because the executable module travels with the file, and is executed whenever, and wherever, the file is opened.

In accordance with a second embodiment of the present invention, a self destructing e- •""mail messaging system is provided which automatically attaches an executable module to each e-mail message or e-mail message attachment which is created. The executable module contains a portion of executable code or an executable program which instructs the computer to overwrite and/or delete the message (and/or message attachment) to which the executable module is attached at a desired time. The executable module •:travels with the message as the message is transmitted to its addressee because the executable module is attached to the message. Moreover, the executable module remains attached to the message even when the message is copied, forwarded to another •addressee, or saved to disks or other external media.

In accordance with a third embodiment of the present invention, a document security system includes a virtual container into which one or more digital objects are "placed." In this regard, the term "digital object" is used broadly, and includes documents (such as spreadsheets, charts/graphs, word processor documents, ASCII text files, images, and other data files), programs, and anything else which can be stored on a computer.

The document security system includes a container creator and a container opener. The container creator and the container opener are implemented in one or more software programs which are executed on a computer. The container opener allows a user to set a limit on the valid lifetime of the digital objects in the container. These "lifetime controls" may include, for example, an expiration date, an expiration date and time, a fixed number of times in which the document can be opened, or other limits. When the container is opened by the container opener, the container opener checks the lifetime controls. If they are valid, the digital objects contained within the container are accessible for display or execution by the user. If, however, the lifetime controls are invalid, the container opener will immediately destroy the digital object.

An advantage of the document s ecurity system including the container creator and the container opener is that, in certain environments, it provides a more robust enforcement of lifetime controls than a self-destructing document containing an executable module.

This is because the ability of current word processing and spreadsheet programs to execute an executable module varies widely from product to product. Therefore, for example, a self-destructing document which includes an executable module which is executable by Microsoft WordTM will not self destruct if opened, for example, as a simple ASCII file which is not configured to recognize and execute the executable module. In contrast, with the document security system, the documents are secured within a container which is opened by the container opener, and the container opener, when used, can enforce the lifetime controls against any document in the container, regardless of its type.

In accordance with a further aspect of the document security system in accordance with the third embodiment of the present invention, each digital object within the container may. have independent lifetime controls. In accordance with this feature, when a single object within the container expires, it can be destroyed, while the other objects remain intact.

In accordance with still another embodiment of the document security system, the digital object is a self-destructing document created in accordance with the first or second embodiments of the present invention.

In accordance with a still further aspect of this embodiment, the container, its contents, and its lifetime controls can be secured against a user who wishes to subvert the security system. This security is effected through the use of encryption technology.

Specifically, the container creator is configured to encrypt the objects within the container, and the container opener is configured to decrypt the objects. In this manner, if a user opens one of the objects without utilizing the container opener, the object will be unreadable.

In accordance with a further aspect of the first and second embodiments, the selfdestructing document or e-mail message is encrypted, either by the executable module or by another utility, and the executable module is configured to decrypt the document or e-mail message only if the lifetime of the document or e-mail message has not expired.

In accordance with another embodiment of the present invention, a self-destructing document is created by embedding a plurality of executable modules into a document or e-mail message, wherein each module is executable by a different word processing or e-mail system. For example, a document could include a first module which is executable by a first system and a second-module which is executable by a second system. The document itself could be a document native to either system. In accordance with this embodiment, the lifetime controls for the document will be enforced regardless of whether it is opened in the first system or the second system.

In accordance with another embodiment of the invention, an Internet commerce system is provided which employs the virtual containers. In accordance with this embodiment, a. party who wishes to sell an electronically transmittable product over the Internet places the product into a virtual container using a container creator utility which.

encrypts the product and sets lifetime controls for the product. A potential buyer of the product who wishes to sample the product prior to purchasing it, obtains a copy of the container along with an container opener utility from the seller. The container opener utility allows the potential buyer to view and use the product only until a preselected expiration date. The container opener does not, in this embodiment, allow the user to remove the product from the virtual container. In accordance with. a preferred aspect of this embodiment, the product is deleted by the container opener if the container is opened after the expiration date. -In accordance with yet another aspect of this embodiment, -if the seller receives payment for the product prior to the expiration date, :the seller will transmit a unique key to the buyer. The container opener could be configured to release the product from the container upon receiving the key.

Brief Description of the Drawings Figure 1 shows an illustrative prior art environment in which the present invention can be implemented.

6 Figures 2(a) and 2(b) show e-mail messages in accordance with-the present invention which include pre-pending and appending viruses, respectively.

Figure 3 is a flow chart of an illustrative method for creating a self-destructing e-mail message in accordance with an illustrative embodiment of the present invention.

Figure 4 is a flow chart of a macro virus which is embedded in the self-destructing email message of Figure 3.

Figures 5(a) through 5(c) illustrate a graphical user interface for a self-destructing document in accordance with an embodiment of the present invention which is implemented for a Microsoft Excel"~" document.

Figures 6(a) through 6(c) illustrate a graphical user interface for a self-destructing document in accordance with an embodiment of the present invention which is implemented for a Microsoft Wordm document.

Figures 7(a) through 7(e) illustrate a graphical user interface for a self-destructing email message in accordance with an embodiment of the present invention which is implemented in Microsoft Outlook"~'.

0: 0. 0:Figure 8(a) shows a document set virtual container in accordance with an embodiment 0 of the present invention.

Figure 8(b) shows a virtual container proxy in accordance with an embodiment of the present invention.

0 Figures 9(a) and 9(b) show a further embodiment of the document set virtual container of the present invention.

Figure I10(a) shows an illustrative header format for a document set container configured to hold a single document Figure I10(b) shows. an illustrative header format for a document set container configured to hold multiple documents.

Figure 11 illustrates a graphical user interface for a container creator utility and a container opener utility.

Figure 12 is an illustrative flow chart for adding a document to the document set container of Figure Figure 13 is an illustrative flow chart for extractinga document from the document set container of Figure Detailed Description of the Preferred Embodiments Figure I shows an illustrative prior art environment in which the present invention can be utilized. A local area network I (LAIN 1) includes a plurality of office computers 10.1-10.6 (hereinafter referred to collectively as computers 10) and a server 20. Each computer 10 includes a respective primary storage facility 12 (such as a hard drive) and a respective secondary storage facility 14 (such as a. floppy disk or CD Rom drive).

The server 20 similarly includes a primary network storage facility 22 (such as a hard drive) and a secondary network storage facility 24 (such as a tape or CD Romn drive).

The data on the primary and secondary network storage facilities 22, 24 is shared in that it can be accessed by all of the computers 10. In contrast, the data on the primary and secondary storage facilities 12, 14 of each computer 10 is private in that it is accessed only by its respective computer 10. The server 20 provides Internet access to out- ofnetwork computers, such as home computer 40, via transmission lines 50. Home computer 40 includes a primary storage facility 42 and a secondary storage facility 44.

The LAN I supports an electronic mail messaging service which allows each computer to send messages within the LAN I to other computers 10 and to send messages outside the LAN i to out of network computers such as home computer 40. The configuration shown in Figure I is illustrative of typical LANs which are often used in businesses. As one of ordinary skill in the art will appreciate, however, the present invention may be implemented with a variety of network configurations. Moreover, the e-mail messaging system of the present invention is equally applicable to non-network applications in which, for example, e-mail messages are sent and received by a stand- 6:06% alone computer via a modem or other connection. In addition, the document retention and deletion features of the present invention may be implemented on a stand-alone 0: computer, with or without a modem or other connection to external computers.

Some of the document retention and destruction problems which can be alleviated in accordance with the present invention will now be explained with reference to the configuration of Figure 1.

For purposes of illustration, assume that local area network 1 is installed in a business which has adopted a document retention policy that requires that documents which are more than two years old be destroyed. Typically, such a document retention policy will be implemented by installing a program on the server 20 which periodically scans the primary network storage facility 22, and deletes documents which have a creation date which is more than two years earlier than the current scanning date. One of the problems with a program of this type is that it fails to adequately account for -copies of the documents which are not stored in the network storage facilities.

For example, assume user- I creates a document on computer 10. 1, and stores it on the network storage facility 22. Then, a week later, user- I copies the document onto the hard drive 12. 1 of computer 10. 1, and onto a floppy disk via the secondary storage facility 14. 1. Moreover, since the document is on the primary network storage facility 22, user-2, may, without the knowledge of user-i1, copy the document onto primary storage facility 12.2 of computer 10.2, and onto another floppy disk via the secondary storage facility 14.2. In this manner, five copies of the document have been created, only one of which can be accessed and deleted by the network document retention program.

The above-referenced problem is further complicated by the fact that the LAN of Figure 20 I provides electronic messaging services. As a result, user- I can create an e-mail message and send it outside of the LAN to computer 40 via Internet servers 2 -Moreover, previously created document files can be inserted into e-mail messages as attachments. This creates additional problems. For example, the e-mail messages and their attachments may be sent outside of the LAN to third parties who are not aware of the b usiness's document retention policy. In any case, even if the e-mail is merely sent to an employee's home computer, the home computer will not be accessed by the network document retention program.

Typically, enforcement of document retention policies with regard to documents which are not stored on network storage facilities requires each employee to search each directory of their individual hard drives, as well as each of their floppy disks or other secondary storage mediums.' In addition, due to the ability of the e-mail system to include documents as attachments to e-mail messages, older documents may be hidden in recent e-mail miessages, making these documents difficult to identify and delete. The employees must also be required to search their laptops and home computers for business files. Moreover, even if each employee is diligent in perforrming these timeconsuming tasks, there will remain the possibility that documents continue to exist on third party computers..

Another problem associated with the implementation of a document retention policy is that conventionally, when a document is deleted from a storage medium, the document itself is not removed. Instead, the computer merely removes the pointer to the document which indicates the document's location in the storage medium. The.

document itself remains in the storage medium until the computer overwrites it with another document. Consequently, for employees to insure that a document-is actually deleted, they must overwrite the document with null characters and then delete. the document, further increasing the time associated with enforcing the document retention.

policy.

Executable Modules Embedded in a Document or E-Mail Message In accordance with the present invention, a self-destructing document system is provided which attaches. an executable module to a document. In accordance with another embodiment of the present invention, a self destructing e-mail messaging system is provided which attaches an executable module to an electronic message or message attachments when the message or message attachment is created. The executable module can be attached to the message or document in any known. manner.

For example, referring to Figure 2, the executable module can be attached as a prepending virus (Fig. 2A), as an appending virus (Fig. 2B), or in any known manner.

The module itself can be created in any known manner by utilizing, for example, assembly languages, higher level programming languages, or macros. The attached .004:20 executable module causes the document or message to self-destruct once a predetermined condition is met. In this manner, the executable module sets "lietime *else:controls" which control the lifetime of the document. In the above-referencedillustration, for example, the executable module would be programmed to delete the documnent or message to which it is attached if the current date was more than two years later than the creation date of the document or message. In accordance with a further SP* embodiment of the present invention,'the executable module would overwrite the document or message to which it is attached with null characters all "XY"s) prior sees*:to deleting the document or message.

In accordance with further embodiments of the present invention, the overwriting and/or deleting of the document or message may be predicated on the occurrence of other or additional conditions. For example, the system could be configured to overwrite and/or delete the message or document when the document i) is closed, or ii) is opened for a second time, thereby creating a document which can be read only one time before it is destroyed. Alternatively, the system could be configured to overwrite and/or delete the message or document when an attempt to copy, forward, or print the message or documhent is made. Moreover, -the systemn could be configured to block any attempt to print or copy the message o r document thereby creating a document which can be viewed, but not printed. These additional lifetime controls could also be triggered by an event, so that the print or copy block is lifted if a password or key is input, or so that the print or copy block is imposed after a predetermined time period or other event.

In accordance with another embodiment of the present invention, the system could allow a LAN administrator to predetermine the overwrite/delete condition(s) so as to impose a document retention policy on all system users, and on all documents or messages created by system users. Similarly, the system could be configured to allow each user to choose whether a particular document or message includes an overwrite/delete condition. Moreover, the user could be allowed to choose from a variety of overwrite/delete conditions. This could be implemented, for example, through a tools menu.

An exemplary method for implementing a self-destructing electronic document or providing a self-destructing electronic messaging system will now be described. While the illustrative embodiment described herein is illustrated for Microsoft Word T M Microsoft ExcelTM, and Microsoft OutlookTM environments, one of ordinary skill in the art will appreciate that the present invention may be implemented in a variety of *2 environments and in a variety of ways.

Figures 3 and 4 illustrate the implementation of a self-destructing electronic messaging system for Microsoft Word T 6.0 documents. Referring to Figure 3, at step 200, a user initiates the creation of a document or message on, for example, office computer 10.1 of Figure 1. At step 220, the system creates an "AutoOpen" macro and saves the macro 25 in the "Normal.dot" file. In accordance with the Microsoft WordM architecture, a macro created with the title AutoOpen will execute each time a Word document is opened. The instructions referenced at step 220, which are written in the WordBasicTM programming language, are saved as an AutoOpen macro in the normal.dot template i* file. Normal.dot is a template which is designated by the Word T program as a storage file for global macros. At step 230, the normal.dot file, which includes the AutoOpen macro, is copied to a file named "message.dot" Then, at step 240, the AutoOpen macro is deleted from the normal.dot file. At steps 250-260, the message.dot file is opened and the user is prompted to insert the text of the document or message. Then, at steps 270, the message.dot file, which now includes the document or message as well as a copy of the normal.dot file, is saved. The copy of the normal.dot file, in turn, includes Sthe AutoOpen macro. At steps 280-290, the message.dot file is renamed message.doc, and then sent as an electronic mail message or electronic mail message attachment.

11 The electronic mail message is sent, for example, over the Internet to Home Computer via LAN server 20 and Internet servers 30. The AutoOpen macro, which is embedded in the message.doc file, will execute when the file message.doc is opened by the addressee of the message. Figure 4 is a flow chart for the AutoOpen macro which is embedded in the message.doc file. At step 310, the DateSerial 0 function returns a serial value representative of the creation date of the message as the variable "created." The argument for the function DateSerial is set at the time the AutoOpen macro is created (steps 210 and 220 of Figure and has been arbitrarily indicated as June 1997 in Figures 3 and 4. At step 320, the TodayO function returns a serial value representative of the current date as the variable "curdate". The serial values returned by these functions are integers between 1 and 802074, with 1 corresponding to December 31, 1899 and 802074 corresponding to December 31,.4095. At step 330, the variable "difference" is set as the difference between the "curdate" and "created." Consequently, the variable "difference" is equal to the number of days which have elapsed between the creation of the message.doc file and the current date in which the document has been opened.

Steps 340 through 360 constitute an "If, Then" Statement which determines whether the time elapsed between the creation date and the current date has exceeded a predetermined threshold. For purposes of illustration, the threshold has been set at days. At step 340, the variable "difference" is compared to the value 60. If "difference" is greater than 60, if more than 60 days have elapsed since the message.doc file was created, then steps 350, 360, and 370 are executed. At step 350, an EditReplace.Find function is performed. This function will replace each character of 25 the message.doc file with a null character (which has been arbitrarily set as Then, at step 360, the message.doc file, which has been rewritten as a series of"X" characters equal to the number of text characters in the file, is saved and closed. In this manner, S the memory locations from which the message.doc file was retrieved are overwritten with null characters. In contrast, if, at step 340, the variable "Difference" is less than or equal to 60, then execution jumps to step 370 and the addressee of the message is able to freely view and edit the message.

Naturally, the macro shown in Figure 4 can be modified to perform additional functions. For example, the macro could be modified to delete the message.doc file 35 after it is saved by utilizing the FileNameFromWindow$O function to retrieve the location of the message.doc file at the time it is opened, and then utilizing the Kill function to delete the file. In addition, the macro could be modified to allow the user who is opening the message.doc file to defer message deletion.

Figures 5(a) through 5(c) and Table 1, infra, show a self-destructing document system which is illustrated with regard to Microsoft Excel T M documents. Referring to Table 1, an illustrative Visual Basic

T

M program for creating a self-destructing Excel document is shown which includes a user interface implemented for a Microsoft Windows

T

m environment. The implementation shown utilizes the "auto_open" and "auto_close" routine supported by Microsoft Excel

T

In accordance with the illustrated embodiment, these routines are resident in a "book.xlt" template in the xlstart subdirectory of Microsoft ExcelT

M

In this manner, bookxlt, with the auto_open and autoclose routines, are used as a template for each Microsoft ExcelT M document that is created. These routines are therefore resident in the Excel document itself.

Each time an Excel document is created, the program of Table I is embedded as a macro in the document. When the document is closed, the auto_close routine is implemented. After reading the variables "lcdata" and "lcmode" from the custom document properties (Table 1, lines 23-26), the program checks to see that lifetime controls have not yet been set for the document (Table 1, line 28). If lifetime controls have already been implemented, then the auto_close routine is exited (Table 1, line 29). If lifetime controls have not been implemented, then the program asks the user whether he/she wishes to implement lifetime controls (Figure 5a). If they do, then the program asks the user to input an expiration date for the document (Figure 5(b) and Table 1, lines 35-36). The expiration date is then stored as "lcdata" and "lcmode" is set to (Table 1, lines 37-38). If the user does not wish to implement lifetime controls, then "lcmode" is set to and "lcdata" is set to (Table 1, lines 39-41). The values of"lcmode" and "lcdata" are stored within the ExcelT document as custom document properties.

When an Excel T M document containing the embedded program is opened, the auto_open macro (Table 1, lines 2-20) is executed. The values of "lcmode" and "lcdata" are read from the custom document properties (Table 1, lines If "lcmode" is equal to (line and the current date is after the date in "lcdata" (line 10), then the name of the document is stored in the variable "fn" (line 12), a message i stating that the document is no longer valid is displayed as a message box on the display screen of the computer (Figure 5(c) and Table 1, line 14), and the document is closed and deleted (lines 15-16). While the program of Table 1 does not overwrite the 35 Excel document with null data before deleting it, such a function could be easily added Susing, for example, the Clear method in the Visual Basic T M programming language, as described below: If DateValue(Date) DateValue(lcdata) Then Range("Al").Select Range(Selection, Selection.SpecialCells(xlLastCell)).Select Selection.Clear ActiveWorkbook.Save Figures 6a through 6c and Tables 2(a,b) show a self-destructing document system which is illustrated with regard to Microsoft Word 97 T M documents. Referring to Tables an illustrative Visual BasicTM program for creating a self-destructing Word 97 document is shown which includes a user interface implemented for a Microsoft Windows environment. The implementation shown utilizes the FileSave, and FileSaveAs macros to initiate the lifetime controls, and utilizes the AutoOpen macro to enforce the lifetime controls. In accordance with the illustrated embodiment, the program of Table 2 is embedded as a template in the document.

Each time a Word 97T document is created, the program of Table 2 is embedded in the document. The program resides in an external document template on the author's workstation, and is copied into the new document by use of the AutoNew macro shown in Table 2c. This macro executes the function "InstallSDD", which reads the program of Table 2 from template SDD.dot and copies its contents, using the Microsoft Word Organizer object, into the new document. Use of this method insures the embedded program is encapsulated within the document, in accordance with this embodiment of the present invention.

When the new document is saved (FileSave or FileSaveAS, Table 2b), the variable "lcmode" is read. If "lcmode" is undefined this is the first time the document has been saved), then the routine "pflmplementLifetimeControls" (Table 2a) is invoked, and the program asks the user whether he/she wishes to implement lifetime controls (Figure 6a, Table 2a). If they do, then the program asks the user to input an expiration date for the document (Figure 6(b) and Table 2a). The expiration date is then stored as "lcdata" and "lcmode" is set to (Table 2a). If the user does not wish to implement lifetime controls, then "lcmode" is set to and "ledata" is set to (Table 2a). The values of"lcmode" and "lcdata" are stored within the Word 97 T M document as document variables.

35 When a Word 97 T M document containing the embedded program is opened, the AutoOpen macro (Table 2b) is executed. The values of "lcmode" and "lcdata" are read using the "pfGetLcmode" and "pfGetLcdata" functions (Table 2a, 2b). If"lcmode" is equal to (Table 2b), and the current date is after the date in "lcdata", then the name of the document is stored in the variable doc (line 12), the variable "rng" is set to the length of the document, the document is overwritten with null data (ret=mg.Delete) and then deleted (Kill(dlg.name)), and a message stating that the document is no longer valid is displayed as a message box on the display screen of the computer (Figure 6(c) and Table 2b) Figures 7(a) through and Table 3 illustrate a self-destructing document system which is illustrated with regard to Microsoft Outlook T 98. Referring to Tables 3, an illustrative Visual Basic program for creating a self-destructing Outlook M 98 e-mail message is shown which includes a user interface implemented for a Microsoft Windows environment Referring to Figures 7(a) and a tab entitled "Selfdestruct" 73 is added to the default e-mail message template. Figure 7(a) shows the conventional "message" tab 74 which is displayed when a user wishes to create.an email message. The tab 74 includes the e-mail message text 76 and the address of the recipient of the e-mail 77. Figure 7(b) shows the self-destruct tab, which includes a toggle box 71 which indicates whether the message will be a self-destructing message, and a date box 72 in which the destruction date is entered. As explained below, the destruction date is embedded in the e-mail message and retrieved and processed when the e-mail message is opened.

Outlook 98 supports Outlook Items (individual objects such as messages, calendar entries, tasks, etc.) which support Visual Basic code. A collection of events are defined S. for each Item and Visual Basic code may be written to conform to each event. In the SOutlook object model, an e-mail message is known as a "Mailltem". OutlookTM allows a programmer to intercept and modify application behaviors, and both message-creation and message-opening behaviors can be intercepted and modified.

S. Table 3 illustrates a Visual Basic program which is embedded in an e-mail message and which is executed whenever an e-mail message is opened by using the ItemOpen function. When an e-mail message is created, and a check is entered in the toggle box 71 and a date is entered in the date box 72 of the self-destruct tab 73, then the value of the toggle box 71 is stored in "Item.UserProperties("DoDestruct")," and the date entered in the date box 72 is stored in "Item.UserProperties("DestructDate")." These values are embedded in the e-mail message along with the program of Table 3. When the e-mail message is opened, the embedded program Function Item_Open is automatically executed. Referring to Table 3, if the DoDestruct property is False 35 the message is not a self-destructing message), then the program is exited and the e- Smail message is opened. However, if the DoDestruct property is True, then the program checks to see if the message is expired by implementing the function "itemExpired," which in turn, implements the function "daysTilDestruct." The function daysTilDestruct subtracts the current date from the value of "DestructDate", and returns the difference in days. The value returned by the function daysTilDestruct is stored in the variable "dt" in the function itemExpired.- If "dt" is less than or equal to zero, then the function "itemExpired" returns the boolean value True to the function Item -Open, the text of the message is overwritten with the text "This message is no longer available" as shown in Figure and the message "This message is no longer available" is displayed in a dialog box as shown in Figure If "dt" is greater than 1, then* "itemExpired" returns the boo lean value False, and the message "This message will destruct in [daysTilDestruct] days" is displayed in a dialog box as shown in Figure 7(c).

TABLES J THROUG~H 3.

Attribute VBName "Module V" Sub auto -open() On Error GoTo ehEnd: Dim Icmade As String Icmode ActiveWorkbook.CustomDocumentProperties("lcmode") Dim lcdata As String Icdata ActiveWorkbook.CustomDocumentProperties("cdata") On Error Resume Next If lcmode Then If Date Value(Date) Date Value(lcdata) Then Dim fn As String fni Active Workbook.Nanie Dim ret ret MsgBox("" fn is no longer valid.", vbCritical vbOKOnly, "Purdue/SDD") Active Workbook.Close (False) Kill (fn) End If End If ehEnd: End Sub Sub auto close() On rr-r G~oehImplement: Dim lcmade As String *lcmodd ActiveWorkbook.CustomDocumentProperties("lcmode") Dim Icdata As String lcdata Active Workbook.CustomDocumentProperties("lcdata") *On Error Resume Next If lcmode Then Exit Sub End If ehlmplement: Dim ret ret MsgBox("Would you like to implement lifetime controls in this workbook?", vbQuestion vbYesNo, "Purdue/SDD") If ret vbYes Then cdata 'InputBox("Please enter the expiration date for this workbook.", "Purdue/SDD-, Date) s0 ret Active Workbook.CustomDocumentProperties.Add("cmode", False, msoPropertyTypeString, ret Active Workbook.CustomDocumentPropertiesAdd("lcdata", False, msoPropertyTypeString, lcdata) Elself ret vbNo Then ret ActiveWorkbook.CustomDocumentProprties.Add("cmode", False, msoPropertyTypeString, ret ActiveWorkbook.CustomDocumentProperties.Add("lcdata", False, msoPropertyTypeString, EndlIf End Sub

IABLE

Attribute V13_Name "Utilities!' Public Function pfGetLcmode(doc As Document) As String On Error GoTo ehUndefined Dim lcmode As String lcmnode doc.Variables("lcmode') pfGetLcmode lcmode Exit Function.

ehUndefined: pfGetLcmode End Function Public Function pfGetLcdata(doc As Document) As String On Error GoTo ehUndefined Dim lcdata As String Icdata. doc.Variables("lcdata") pf~etLcdata lcdata Exit Function ehUndefined: pfGetLcdata= End Function Public Function pflmplementLifetimeControls(doc As.Document) As Boolean Dim ret ret =Msgeox("Would you like to implement lifetime controls in this document?", vbQuestion vbYesNo, "PurdueISDD") .*If ret =vbYes Then **35 ret doc.Variables.Add("lcmode", Dim data As String data lnputBox("Please enter the expiration date of this document.", "Purdue/SDD", Date) ret =doc.Variables.AddC'lcdata", data) Elself ret vbNo Then ret doc.Variables.Add("lcmode", End If pfSetLc True End Function TABLE 2A Sub FileSaveo Attribute FileSave.VB_-Description "Saves the active document or template" Attribute FileSave.VBProcData.VBInvokeFunc "Normnal.NewMacros.FileSave" Dim lcmode As String Imode =pftjetLcmode(ActiveDocument) Dim ret As Boolean ret pflmplementLifetimeControls(ActiveDocumeflt) Else End If ActiveDocuxnent.Save End Sub Sub FileSaveAs() Attribute FileSaveAs.VB Description "Saves a copy of the document in a separate fle" Attribute FileSaveAs.VB_-ProcData.VBInvokeFunc "Normal.NewMacros.FileSaveAs" Dim lcmode As String lcmode pfGetLcmode(ActiveDocument) if lcmode ""Then Dim ret As Boolean ret pflmplcmentLifetimeControls(ActiveDocument) Else End If Dialogs(wdDialogFileSaveAs).Show End Sub Sub AutoOpeno Dim doc As Document.

Set doc ActiveDocument Dim lcmode As String lcmode pfGetLcmode(doc) Dim lcdata As String Icdata pfGetLcdata(doc) If lcmode Then If DateValue(Date) DateValue(lcdata) Then Dim mg As Range Set rng doc.Content() ret rng.Delete() doc.Close (wdSaveChanges) Kill (dlg.Name) ret MsgBox("This document is no longer valid." Chr(13) "It has been destroyed.", vbCritical vbQKOnly, "Purdue/SDD") Exit Sub End If End If End Sub TABLE2M AutoNewo Call InstallSDD End Sub Sub InstallSDDO Dim tPath As String tPath =Options.DefaultFilePath(wdUserTemplatesPath) .tPath tPatb "'\SDD.dot" On Error GoTo effHandler Application.QrganizerCopy- Source:--tPath, Destination:=ActiveDocument.Name,- Name:="SDDModule",_ :Object:--wdOrganizerObjectProjectltems Exit Sub effHandler: MsgBox "Could not load self-destructing document module." Exit Sub End Sub TABLE2 Function Item_Open( If Item.UserProperties ("DoDestruct").Value False Then Item Open True Exit Function End If If itemExpired 0 Then Item.Body "This message is no longer available." Item.Save 0 MsgBox ("This message is no longer available.") Else MsgBox ("This message will destruct in daysTilDestruct days.") End If End Function Function itemExpired dt daysTilDestruct If dt Then itemExpired True Else itemExpired False End If End Function Function daysTilDestruct daysTilDestruct DateDiff Now 0, Item.UserProperties ("DestructDate").Value) End Function TABLE 3 Moreover, the executable modules in accordance with the self-destructing documents set forth above can also utilize encryption techniques to prevent a user from defeating the lifetime controls, for example, by opening a self-destructing document with an application which is incapable of executing the executable module. In accordance with 35 such an embodiment, when a document is first saved or closed, the executable module will encrypt the document Then, when the document is subsequently opened, the executable module will decrypt the document only if the lifetime controls are valid.

Moreover, if the document is opened with an application which is incapable of executing the executable module, then the document will remain encrypted, and the S 40 user will be unable to view the document. As an example, if a user attempts to open a i self-destructing Microsoft WordM document using the WordPerfectm application, the WordPerfect M application will not execute the Microsoft Word T M AutoOpen or File Open macro, and the document will be opened regardless of whether the lifetime controls of the document are valid. However, if the self-destructing Microsoft Word

T

document had been previously encrypted by the AutoClose, FileSave or FileSaveAs macros (using, for example, an exclusive-or polyalphabetic cipher as described below), then the document would remain encrypted unless the user opened the file using an application which executes the macro (which would include the corresponding decryption algorithm for the exclusive-or polyalphabetic cipher). The selection of an appropriate encryption technique would be dependent on the degree of security desired, and the ability of the macro or script used to implement it.

VIRTUAL CONTAINER S A document security system in accordance with the present invention which employs virtual containers will now be described.

In accordance with a first embodiment of the document security system illustrated in Figure 8a, a document set container 500 is used to store one or more documents 5 10 (or other digital objects), each with independent lifetime controls 520. A utility is installed on any computer where a user wishes to open and. display the- contents of the container.

That utility validates the lifetime controls of a document- before displaying it to the user.

If the lifetime controls are valid;~ then the document is extracted from the container is available for use by the user. If the lifetime controls are invalid, the document is destroyed by, for example, overwriting the document with null data.

In accordance with a second embodiment of the document security system shown in Figure a container proxy 500' can be used to store a single document 5 10' (or other digital object). A proxy handler is installed on any computer where a user wishes to open and display the document in the proxy container. Unlike a document set container, the operation of a proxy is invisible to the user-unless the document's lifetime controls 520' are invalid. In order to provide this transparency, the proxy is named or otherwise encoded to appear as a normal instance of a document, and the operating system mechanism that associates documents with their applications is altered to associate the document with the proxy handler instead. The proxy handler will transitively complete the association between the document and the application if "~*the lifetime controls are valid. This embodiment takes advantage of the fact that when a file is accessed, for example by clicking with a mouse on a file from a Windows desktop, from a Windows 95 document icon in "My Computer", or. from the file manager in Windows 3. 1, the operating system will attempt to associate the file with an application, such as MicrosoftTm~ Word, Microsoft ExcelTM, or WordPerfectTm. In accordance with the container proxy, the container proxy utility is interposed between the operating system and the application, so that when a user accesses a container proxy *.35 (which will appear to the user as an ordinary document), the operating system will invoke the container opener to automatically open the container and, if the lifetime controls are valid, will start the application and open the document in the container. If the lifetime controls are invalid, the document is destroyed by, for example, overwriting the document with null data and/or deleting the document. In accordance with. fiuther embodiments of the container proxy, the system can be configured to automatically return the document to the container proxy when the application is closed.

Various embodiments of the document set container (DS container) will now be discussed. In Accordance with a first embodiment of the DS container, a container opener utility and a container creator utility are provided. The container creator utility resides on the computer of a user who wishes to create a DS container, and, as its name suggests, is operable to create a DS container, to specify lifetime controls, and to. place a document in the DS container. The container opener utility resides on the computer of a user who wishes to open a DS container, and is operable to open the DS container, to check the validity of the lifetime controls, and to extract the document from the DS container if the lifetime- controls a re valid. If the lifetime controls, are, invalid, the document is destroyed by, for. example, overwriting the document with null data. In accordance with one embodiment, the DS container contains only one document. In accordance with further embodiments, multiple documents can be stored in a single container, and each document may have its own lifetime controls. In situations in which it is desirable to allow a user to open, but not create, a DS container, the container opener utility can be installed on a computer without the container creator utility. Regardless of the number of documents which reside in the DS container, an unopened DS container appears to a user as a single file, and includes header information (including, for example, the lifetime controls) as well as the document or documents themselves.

In accordance with a fuirther aspect of the multiple document DS container in accordance with the present invention, the DS container may include a container header, which contains control information for the container, and which refers to two singly-linked lists of streams. The first 'linked list contains active streams, and the second contains inactive streams. Active streams correspond to documents which still have valid lifetime controls and inactive streams correspond to documents which have invalid lifetime controls, or which have been removed (deleted) from the container.

Both active and inactive streams have headers that contain lifetime control (and preferably encryption information as described below) for their corresponding streams.

These stream headers each contain a reference to the next stream in its list (whether active or inactive), or an indicator that this stream is the last in its list. Each stream is a contiguous block of binary data.

When a stream is invalidated or is removed from the container, its stream header is marked as inactive, moved to the inactive stream list, and the stream itself is overwritten with null data. When a new stream is added to the container, an inactive stream can be reactivated and used if it is of sufficient. length to contain the new stream.

If no inactive stream is available or sufficient to contain -the new stream, a new stream can be created and activated in the container. If a container experiences many changes to the active and inactive stream lists, it may become fragmented. In other words, as documents expire and are replaced with null data, the active documents may be sandwiched between one or more inactive documents which simply comprise null data.

In a preferred embodiment of the invention, the. container creator utility can detect this condition and compact the container when required.

Figures 9(a) and illustrate the active/inactive stream embodiment of the present invention. Figure 9(a) shows a virtual container which has been created with three documents contained therein. As shown in Figure the container headerincludes creation information (such as the name of the container, the default lifetime controls for the container, the date the container was created, the date the container was last modified DM 804, and the date the container was last accessed), information regarding the active stream (such as a pointer to the first document in the active stream and the number of documents in the active stream), and information regarding the inactive stream (such as a pointer to the first document in the inactive stream and the number of documents in the inactive stream). Each document in the container includes a document header including lifetime control information and a pointer to the next document in its respective stream. Since the container has just been created, all three documents are in the active stream, and the container header includes an active streamn sub-header which includes a pointer to the first document and an indication that three documents are in the active stream. The inactive stream sub-header includes null 25 information. Then, in Figure two new documents documents 4 and 5) have been added to the container, and document 2 has expired. While the active stream container sub-header still points to document 1, the pointer in the document I header now points to document 3 instead of document 2. Moreover, the inactive stream container subheader now points to document 2.

As set forth above, a virtual container in accordance with the present invention contains one or more documents that should be destroyed when they are no longer valid (as determined by their lifetime controls). In general, the cost of the effort needed to defeat *.these controls should exceed the value of extending the valid life of the documents.

In accordance with a preferred embodiment of the present invention, the documents within the virtual container are encrypted in order to prevent unauthorized access to a document in the container, and to prevent a user from defeating the lifetime controls for a document. These encryption techniques can be used, for example, with any of the virtual containers described herein, including the DS containers of Figures 8a, 9a, and 9b, and the proxy containers of Figure 8b.

In accordance with a fur-ther embodiment of the present invention, the system allows an author to select from several levels of security, based on the perceived value of the documents contained within. In general, as the level of security increases, so does the effort required. to defeat it-and so does the cost and complexity of the security itself.

Before describing how encryption can be used in the virtual container, some basic principles of encryption technology will be discussed.

An Overview Qf Encrpion Tecnlgies In general, encryption technologies-which are formally called cryptosystems-are composed of two fundamental components: the algorithm and the keys. The algorithm is a mathematical function that transforms data. The keys "direct" the exact nature of the transformation.

Encryption algorithms can either be open or closed. Open algorithms are published by their designers, peer reviewed by academia, and vetted through commercial implementations. Closed algorithms are proprietary works that the designers don't want the public to understand or use. In general, the encryption algorithms used in commercial products are "open" algorithms. An encryption algorithm which has been published, reviewed, and remained in use after being widely implemented for a long period of time can generally be considered a secure algorithm because it has presumably been dissected by major research universities and attacked by computer science students around the world without it being c'omp .romised.

The strength of an effective cryptosystem is generally derived from its keys. Assuming that the encryption algorithm is sound (as discussed above), the security of the cryptosystem, relies on the creation of appropriate keys, and the carefuil guarding of their secrecy. One important measure of appropriateness is the length of a keytypically denoted in bits. A short key facilitates rapid encryption and decryption, but encrypted messages are easier to break. A long key requires lengthy encryption and decryption processes, but may be essentially impossible to break. This perception is so pervasive that the U.S. Government allows the free and open use of any encryption algorithm, but applies strict limits to the length of the keys.

While a variety of open and closed encryption techniques can be used in accordance with the present invention, a brief discussion of four encryption technologies will be provided herein: symmetric algorithms, public-key algorithms, digital signatures, and one-way hashes.

Symmetric algorithms generally rely on a single key to encrypt and decrypt a message.

These algorithms can be simple to understand and use, and provide a relatively high level of security if used properly. However, both parties must agree on the key before communicating, without accidentally divulging the key to any other party. Moreover, the key must be kept secret forever, or older messages can be decrypted at a later date.

Symmetric algorithms are particularly appropriate for transient messages-messages that aren't saved after communication is complete. If the message isn't saved, there is no opportunity to decrypt the message later, should the key be compromised. A popular symmetric algorithm -is, the. Data Encryption Standard, which is an ANSI and ISO standard, and has been in use for over twenty years.

Public-key algorithms use a pair of keys--one called the public key and one called the private key. Either the public or the private key can be used to encrypt a message, and the other key is used to decrypt that message. Only the private key can decrypt a message encrypted by the public key, and only the public key can decrypt a message encrypted by the private key. Moreover, it is essentially impossible to devise an alternate private key, given the public key. Typically, the public key of any pair is published in some well-known, trusted, location (perhaps a database or directory on the Internet), while the owner retains the private key. A common 'scenario which is appropriate for public key encryption is as follows: Alice would like to send Bob a secret message. Alice can acquire Bob's public key from a trusted source. She uses that key to encrypt her message to Bob. When Bob receives the encrypted me ssage, he can decrypt it using his private key. If a) Alice has acquired Bob's authentic public key (and not a forgery), and b) Bob is the only holder of his private key (no one has a copy of it), then Alice is guaranteed that only Bob can read her message. A popular publickey algorithm is the RSA Cryptosystem, owned by RSA Data Security, Inc.

Digital signatures are designed to authenticate the identity of a message's author.

Although there are many ways to implement digital signatures, public key encryption is very common. We can extend the scenario discussed above as follows. Alice would like to send Bob a private message, and she would like him to be assured that it is from her. After all, the previous scenario doesn't guarantee that Bob received the message from Alice; it only assured Alice that her secret message to Bob was unreadable by anyone else. So, Alice first encrypts the message to Bob with her private key. Then, she encrypts that (already encrypted) miessage again using his public key, as above.

When Bob receives the message, he first decrypts it using his private key. Then, to assure that the message is really from Alice, he acquires her public key from a trusted source. He uses that key to decrypt her message. If a) Bob is confident that Alice's keys haven't been compromised through copy or forgery (as discussed above for. Bob), and b) Alice is confident that Bob's keys haven't been compromised, then Alice is still guaranteed that only Bob can read her message and Bob is guaranteed that the message is from Alice. RSA Data Security, Inc. produces a widely-used digital signature algorithm.

Whiile di gital signatures are a reliable way to prove identity in the digital realm, there are certain instances in which authorship of a document should be proved without requiring transfer of the entire (potentially large) document. One-way hashes provide an excellent solution. They are mathematical functions that transfonm any dataset (document or otherwise) into a small stream of binary information. An important property of one-way hash functions is that the function shouldn't produce two identical hashes from two different sources. Significant academic and commercial research effort has been expended to create one-way hashes that. preserve ths property. IM5 is a well-known one-way hash function that creates a 128-bit hash.

Application gf Encryp~io~ Tehnology LQ Virtual Cntiners In accordance with a preferred embodiment of the invention, the virtual container *:document security system allows a user (and/or a system administrator) to select from seea leesoSeuiy. is lvlo euiymgtnt nld n nrpino the document. Its security derives from the requirement that a recipient of the container use the container. opener to display documents. However, any one of several commercially-available binary file editors can be used to open the container itself as a sing le document, and thereby view the contents of the documents. Similarly, since most word processing programs allow a user to retrieve ASCII text from documents, such programs could be used to open the container as a single document, and view any text contained therein.

A second level of security could be a form of symmetric encryption called an exclusiveor polyalphabetic cipher. This encryption algorithm is simple to implement in software, and it operates extremely quickly. This encryption algorithm uses a single key, both to encrypt and decrypt documents. This key can be "hard-coded" into the software, it can be distributed with the software and changed periodically by the user, or it can be acquired from a trusted source each time it is required. In accordance with this method, the document is encrypted by an exclusive-or-ing the document with the key [Document] XOR [key] [Encrypted Document]). As an example, the container opener and container creator utilities could include a single, "hard-coded" symmetric key for both encryption and decryption. An author of a document encrypts the document and optionally its lifetime controls using the container creator. When'the author wishes to distribute the document, he forwards the encrypted document in the virtual container. The recipient decrypts the documeit and its lifetime controls using the container opener utility. The container opener utility checks the lifetime controls, and if valid, displays the document to the recipient. If the lifetime controls are not valid, the container opener utility destroys the document.

A further level of security might utilize a central authority (CA) to further insure the security of the document. In accordance with a first embodiment of a CA system, the author sends the document and its lifetime controls to the CA. The CA returns a unique identifier for that document. -When the author wishes to distribute the document, he forwards the unique identifier to the recipient. The recipient sends that unique identifier to the CA to review the document. The CA checks the lifetime controls, and ifvalid, returns the document to the requester. The requester receives and displays the document. While the use of a CA enhances security, it has the disadvantage of requiring the intervention of a central authority.

A further embodiment of the CA system utilizes one-way hashes. In accordance with this embodiment, the author sends the document and its lifetime controls to a CA. The CA hashes the lifetime controls, and combines the original lifetime controls, the hashed lifetime controls, and the documents into one container. The CA encrypts that container with its private key and returns the package to the author. When the author wishes to distribute the document, he forwards the CA-signed container to the recipient.

The recipient opens the container with the CA's public key, and checks the lifetime i ""controls. If they are invalid, the container is destroyed. If they are valid, it hashes them and compares that hash against the one stored in the container. If the hashes don't match, the container is destroyed. If the hashes do match, and the lifetime controls are valid, the document is displayed.

A still further embodiment of the CA system utilizes one-way hashes and a symmetric key. In accordance with this embodiment, the author sends the document and its lifetime controls to the CA. The CA creates a unique symmetric key (hereinafter DK) and encrypts the document. It records the DK and a unique identifier (hereinafter DKID) for it in its database.' The CA hashes the original lifetime controls, and creates a container containing the original lifetime controls, the hashed lifetime controls, the encrypted document, and the DKID. It signs that package with its private key and returns the package to the author. When the author wishes to distribute the document, he forwards the CA-signed package. The recipient opens the package with the CA's public key. He sends the original lifetime controls, the hashed lifetime controls, and the DKID to the CA. The CA checks the lifetime controls. If there are invalid, the CA stops. If they are valid, it hashes them and compares that hash against the hash received from the recipient If the hashes don't match, the CA stops. If the hashes do match, and the lifetime controls are valid, the CA returns the DK which corresponds to the DKID to the recipient. The recipient decrypts the document with the DK, and the document is displayed.

A problem with this embodiment is that the recipient can defeat the system by creating new lifetime controls, hashing them, and sending the hashed new lifetime controls to the CA with the container's original DKID. This problem can be alleviated in accordance with a further aspect of this embodiment in which the CA creates-an encrypted sub-container of the original lifetime controls, the hashed lifetime controls, and the DKID. The encryption key(s) symmetric keys or a public and private keys are known only to the CA. The recipient (who does not have access to the key(s) to the subcontainer) sends the sub-container back to the CA. Then, when the CA decrypts the sub-container it can be confident that the lifetime controls, the hashed lifetime controls, and the DKID retrieved from the sub-container were created and encrypted by the CA.

SAn Implementationf the irtual Container in the JavaT Programming Language An illustrative implementation of a DS container containing one document, and employing an exclusive-or polyalphabetic cipher, will now be described in which the Scontainer creator and container opener utilities are programmed in the JavaTM 25 programming language. The container creator and creator opener are implemented using the data and file stream classes which form part of the standard I/O package of the Java programming language. Each object of a particular stream class corresponds to a set of contiguous bytes of memory.

A DS container in accordance with this embodiment includes a container header, which contains control information for the container, and a document header for the document in the container. While this embodiment of the DS container is configured to hold only a single document, additional embodiments described infra are capable of holding an unlimited number of documents. Referring to Figure 10a, in accordance with a preferred implementation of this single document DS container embodiment, the Scontainer header includes the name of the container CNAME 701, the date the container was created DC 703, the date the container was last modified DM 705, the date the container was last accessed DLA 704, and the number of documents in the container 706 (either 0 or The container also includes one document 710. The document has a header which includes the document name (707), the lifetime controls for the document (708), and the length of the document (709). In accordance with this embodiment, the DC 703, DM 704, and DLA 705 fields allow a user to determine the date that the container was created, the date it was lasf modified, and the date it was last accessed, as explained below with regard to the view method of Table Naturally, the container created, last modified, and last accessed fields can be omitted from the container header if this functionality is not desired.

Referring to Table infra, a DS container is created by invoking the method "public static int create(String envelopefilename)," which includes as its argument the string "envelopefilename." If "envelopefilename" is an existing file name, or if it has a null value, an error is returned, otherwise the program proceeds to create a new container.

An object "fos" is defined in FileOutputStream for holding the destination filename "envelopefilename." A corresponding object "dos" is defined in DataOutputStream for holding the destination data corresponding the object "dos" (which is "envelopefilename"). The program then creates the header which will be stored in the DataOutputStream object "dos". In this regard, an object "eh" is defined in class SdeEnvelopeHeader, and the "dname" field of the class SdeEnvelopeheader is set to the string "envelopefilename," and the "d_created", "d_lastmodified", and "d last accessed" fields are set to the current date. Then, the method "writeTo" is invoked (Table which writes the container name, the container creation date, the date the container was last modified, the date the container was last accessed, and the number of documents in the container (currently to the object "dos", thereby creating the container header for the newly created container. In this manner, the 25 container will appear as a single file bearing the name contained in the "envelope name" field.

.Referring to Table in order to add a document to a container, the method addDocument is invoked. The method addDocument takes "envelopefilename", "documentfilename", and "expires" as parameters. If any of the parameters are null, an oi error is returned. If the no container named "envelopefilename" exists, the "create" method (Table is invoked to create a container. If no document named "documentfilename" exists, then an error is returned. Otherwise, an object "fis"of FilelnputStream is defined for the "envelopefilename" and an object "dis" of 35 DatalnputStream is defined for the data corresponding to the "envelopefilename" (DataInputStream(fis)). In this manner, the container named "envelopename" is opened in "fis" and "dis". Then, a temporary container is created named "[envelopefilename].tmp." In this regard, an object "fos"ofFileOutputStream is defined for the "[envelopefilename].tmp" and an object "dos" of DataOutputStream is defined for the data corresponding to the "envelopefilename" (DataInputStream(fos)).

In order to update the envelope header, an object "eh" of SdeEnvelopeHeader is then created, and the contents of "dis" (which is the container header for "envelopefilename") is read into "eh" by the method "readFrom" (Table Referring again to Table the objects "d_last_modified" and "dtotal_documents" of class SdeEnvelopeHeader are updated, and the updated envelope header (eh) is written to object "dos" of DataOutputStream.

In order to update the document header, the object "filedoc" of File is set to the path of "documentfilename", and the variable "length" is set to equal the length of the file located at "file_doc." The object "fis_doc" of FilelnputStream is set hold the file "documentfilename". An object "dh" of SdeDocumentHeader is then created, and the "dname" field of the class SdeDocumentHeader is set to the string "documentfilename", the "d_expired" field is set to the value of the parameter "expires", and the "d_total_bytes" field is set to the value of the variable "length".

Then, the method "writeTo" is invoked (Table which writes the document name, the expiration date, and the document length to the object dos, thereby creating the document header for the document.

i Then, the document is read into the variable "ch" (int ch =fis_doc.read), and is encrypted by performing an exclusive-or function on The encrypted document is then written to the object "dos". In this manner, the updated envelope header, the document header, and the encrypted document have been written to contiguous locations in memory using the DataOutputStream function, and a DS container containing one encrypted document has been created. The original container (envelopefilename) is then deleted, and the updated container ("[envelopefilename].tmp") is renamed "envelopefilename." In this manner, the container will appear as a single file bearing the name contained in the CNAME 71 field of the container, and will include the container header, the document header, and the document.

An implementation of the DS container opener will now be described with regard to Tables 5(a) and Table 5(a) illustrates a program for viewing the container header Sof a DS container created in accordance with Tables 4(a) through The method "view" includes two parameters, the string "envelopename" and the PrintStream "ps".

If the neither "envelopename"or "documentfilename" are "null", and if a container named "envelopename" exists, an object "fis"ofFilelnputStream is defined for the "envelopefilename" and an object "dis" of DataInputStream is defined for the data corresponding to the "envelopefilename" (DataInputStream(fis)). In this manner, the container named "envelopename" is opened in "fis" and "dis". An object "eh" of SdeEnvelopeHeader is then created, and the contents of "dis" (which is the container header for "envelopefilename") is read into "eh" by the method "readFrom" (Table Finally, the container header information is printed using the method "println." Table 5(b) illustrates a program for opening a DS container created in accordance with Tables 4(a) through The method "extractDocument" includes two parameters, the strings "envelopefilename" and "documentfilename." If the neither "envelopename" or "documentfilename" are "null", and if a container named "envelopename" exists, an object "fis"of FileInputStream is defined for the "envelopefilename" and an object "dis" of DatalnputStream is defined for the data corresponding to the "envelopefilename" (DatalnputStream(fis)). In this manner, the container named "envelopename" is opened in "fis" and "dis". An object eh of SdeEnvelopeHeader is then created, and the contents of dis in class SdeEnvelopeHeader (which is the container header for "envelopefilename") is read into "eh" by the method readFrom (Table An object "eh" of SdeDocumentHeader is then created, and the contents of "dis" in class SdeDocumentHeader (which is the document header) is read into "dh" by the method readFrom (Table The field "d_name" is then compared with "documentname", and if they are the same, the program proceeds to check the expiration date of the document "documentname." Using the Date method "before", if the date in the field "d_expires" is before the current date, the variable "valid" is set to False. If not, the path of the document is put into an object "file_doc" of the class File.

Assuming that the document "documentname" exists, and the document is not expired, the object "file_doc" is set to a new path: "[documentfilename].x", and the object "fos_doc" of FileOutputStream is set to the FileOutputStream(file_doc). In this manner, a temporary file "fos_doc" is created of the class FileOutputStream. The document is then read, one byte at a time, into the variable Each byte, in turn, is S. i decrypted by performing an XOR function on and written to "fos_doc". If the document doesn't exist, "fos_doc" is set to a null value, and the program indicates that the file is not found. If the document exists, but is expired, the "valid" variable is set to FALSE. This prevents "fos_doc" from being associated with the document, prevents 35 decryption of the document, and causes the program to indicate that the document is expired. In order to overwrite the document in order to destroy it, the following instructions can be inserted in Table if(valid=False) for (long 1=0, l<dh.d_total_bytes; int ch 0 fos_doc.write(ch) Figures 1 and 1 illustrate a simple graphical user interface that can be used to implement both the single document DS container described above with regard to tables 4 and 5, and the multiple document DS container described below with regard to Figures 12 and 13. In order to create a DS container, a user clicks on the "New" button 1510. A dialog box (not shown) will then appear which will prompt the user to enter a container name. Once the container name has been entered, a DS container will be created, and the container name will appear on the banner 1500. In Figures 1 I(a) and 11 the container name is "demo.env", and the container is stored as a file "demo.env" in the directory. In order to add a document to a DS container, a user clicks on the "Add" button 1520. A file menu (not shown) will then appear which will allow the user to either browse the available directories for the desired document, or to enter the path and document name directly. Once the document has been chosen, and an expiration date has been entered in box 1540, the document will be added to the container. Once the document has been successfully added to the container, the name of the document, the length of the document, and the expiration date of the document *i will be displayed in the box 1550. Referring to Figure 1 if the container "demo.env" is opened after the expiration date of the document "demo.txt", the document will be automatically overwritten with null data, and a message will appear in box 1550 indicating that the document is expired. In order to extract a document from the container, the document is selected by clicking on the document in the box 1550, and then clicking the Extract button 1530. The document will then be extracted from the container and stored in a designated directory in the computer. If a document is expired, the system will not allow that document to be selected in the box 1550.

As set forth above, in accordance with further embodiments of the DS container, the *container can be expanded and reduced to hold multiple documents and other digital objects. New documents (or other digital objects) can be added to the container, existing documents in the container can be updated or deleted, and multiple containers can be merged. Each document within the container can have independent lifetime controls and differing levels of security.

In order to provide this functionality, the DS container is modeled as a virtual file system within a single file. A virtual file system is a unit of storage that appears as a 31 single file to the external world, while its internal representation really manages many files and their control information. Although virtual file systems conventionally include hierarchical directory structures, a flat-single directory-structure is preferably used for the DS container, in accordance with the preferred embodiment of invention, DS container supports the following operations: i) creating a new DS container; ii) adding a new document to the DS container with independent lifetime controls and security; iii) updating the content of an existing document in the DS container without changing the lifetime controls or security; iv) updating the lifetime controls or security of an existing document in the DS container; v) deleting an existing document from the DS container; vi) invalidating an existing document in the DS container according to its lifetime controls, and deleting it from the DS container; and vii) destroying the DS container.

A DS container in accordance with this embodiment includes a container header, which contains control information for the container, and a document header for each document in the container.

*:Referring to Figure 10b, in accordance with a preferred implementation of this embodiment, the container header includes the name of the container CNAME 801, the default lifetime controls for the container DLC 802, the date the container was created DC 803, the date the container was last modified DM 804, the date the container was last accessed DLA 805, and the number of documents in the container 806. Figure illustrates a DS container which includes two documents 904.1 and 904.1. Each document has a header which includes the document name (901.1 or 901.2), the lifetime controls for the document (902.1 or 902.2), and the length of the document (903.1 or 903.2). In accordance with this embodiment, the DLC 802 contained in the envelope header is used as the default lifetime control when documents are added to the container. The DC 803, DM 804, and DLA 805 fields allow a user to determine the S" date that the container was created, and the date it was last modified, and the date it was last accessed, -by implementing a routine similar to the view method of Table Naturally, the default lifetime control, container created, last modified, and last S"accessed fields can be omitted from the container header if this functionality is not desired.

Since the DS container of Figure 10b is implemented in a similar manner to the DS container of Figures 1 Oa and Tables 4a through 5b, a detailed discussion of the manner in which this embodiment can be programmed will not be provided herein.

Referring to the flow chart of Figure 12, in order to add a document to an existing IDS container, the existing DS container is opened (step 10 10) and the container header (including the container name, default lifetime controls, date created, date last-,.

modified, date last accessed, and number of documents) is read. Then, at step 1030, a header for the new document to be added is created, including the document name, the lifetime controls for the document, and the document length. The document header and the document itself are then appended to the end of the container (steps 1040 and 1050), the values of the last accessed, last modified, and total number of documents fields are updated (step 1060), and the new values written as the new container header. In accordance with the flowchart of Figure 12, the updated container overwrites the original container. This is in contrast to the embodiment of Tables 4a through 5b in which the updated container is created as a new file, and the original container. is subsequently deleted. Naturally, the embodiment of Figures l0b and 13 could be modified -to employ the- method of Tables 4a through 5b overwriting the original container) and vice versa.

Referring to the flow chart of Figure 13, in order to extract a document from the DS .:container of Figure l Ob, the container is opened (step 11I10), and the container header is read. Then, at step 1120, the document header for the first document in the container is read from the container. At step 113 0, the name of the document to be extracted is compared to the name -in the dname field 90 1, and if they are the same, the program proceeds to step 1140. If they are not the same, the program proceeds to step 1150.

Assuming the current document name in the dname field is the same as the requested document, the program, at step 1140, determines whether the lifetime controls for the document are valid whether the current date is after the expiration date). If the lifetime controls are valid, the current document is extracted. If the lifetime controls are not valid, the document is deleted. An illustrative code segment for deleting the document is shown below, wherein the function getTotalByteso retrieves the document length from the document header for the current document.

public void nullifyDocumentContent(SdeDocumentlleader dh) throws IQException long bytesToNullify dh.getTotalByteso; for (long I 0; 1 bytesToNullify; write(0); If the current document is not the requested document, the program, at step 1150, skips over the current document's content, to the next document header,.or the end of the envelope. Illustrative code for implementing this- fuinction is as follows: public void skipDocumentContent(SdeDocumentHeader dli) throws lOException long bytesToSkip dh.getTotalByteso; for. (long I1 0; 1 bytesToSkip; int ch reado; In this manner, the program reads past the current document-so that when the program returns to step' 1120, it is set to read the document header for the next document in the container.

After the document has been extracted, the last accessed field in the container header is updated (step 1160), and the updated container header overwrites the container header 20 fields 801 through 806, (step 1170) and the container is closed (step 1180).

TABLES -4 TH1ROUGH B public static int create(String envelopefilename) if envelopefilename null) return(CREATEFAILBADPA RAM);' if envelopeExists(envelopefilename)) return(CREATEFAILBADPARAM); try FileOutputStream fos =new FileOutputStreaxn(envelopeflename); 6:00DataOutputStreamn dos =new DataOutputStream(fos); :SdeEnvelopeHeader eh =new SdeEnvelopeHeadero; eb.d-created new Dateo; eh-d-last-modified new Dateo; eh.d -last -accessed new DatnO; eh.writeTo(dos); dos.flusho; fos.closeo;

IAIEA

public static int addDocument( String envelopefilenaxne, String documentfilename, Date expires if( envelopefilenanie null I documentfilename null I expires null) return(ADDFAILBADPA RAM); if (envelopeExists(envelopefilename) false) create(envelopef ilenanie); if( documentExists(documentfilename) false) return(ADDFAILBADPARAM); try FilelnputStream fis =new FilelnputStream(envelopefilename); DatalnputStream dis =new DatalnputStream(fis); FileOutputStream fos new FileOutputStream(envelopefiename "tp) DataOutputStream. dos =new DataOutputStream(fos); SdeEnvelopeHeader elh new SdeEnvelopeHeadero; eh.readFrom(dis); eh.d last modified new Dateo; eh.d total documents++; eh.writeTo(dos); *.30 File file doc new File(documentfilenane); long length file doc. lengtho; FilelnputStreai fis-doc =new FilelnputStream(filejloc); SdeDocumentHeader dli new SdeDocunientHeadero; dh.d name documentfilenamne; dh4dexpires expires; *dh.d -total -bytes length; dh.writeTo(dos); while (true) int ch fis-doc.reado; *if (ch -1 break; ch dos.write(cb); :fis -doc.closeo; dos.flusho; fos.closeo; fis.closeO; File file orig new File(envelopefilenarne); file orig.deleteo; File file -new new File(envelopefilename "tp) file-new.renameTo(file-orig); catch OException ioe) return(ADD FAILIQEXCEPTION); retum(ADD OK); TABLE4Q class SdeEnvelopeHeader public String d-name null; public Date d-created null; public Date d-last-modified null; public Date d-last-accessed null; public long d-total-documents 0; public boolean writeTo(DataOutputStream dos) throws IQException dos.writeUTF(d name); dos.writeLong(dcreated.getTimeo); dos.writeLong(d last-modified.getTimeo); dos.writeLong(d last accessed.getTimeO); dos.writeLong(d -total ocuments); return(true); public boolean readFrom(DatalnputStream dis) throws lOException d -name dis.readUTFO; long c dis.readLongo; d-created new Date(c); long Im dis.readLongo; d-last-modified new Date(lm); 30 long la dis.readLongo; d-last-accessed new Date(la); d-total -documents =dis.readLongo; return(true); class SdeDocumentHeader 40 public String d -name null; public Date d-expires null; *public long d_total bytes 0; public boolean writeTo(Data~utputStream dos) throws IQException :dos.writeUTF(d. name); dos.writeLong(dexpires.getTimeo); dos.writeLong(d total bytes); return(true); public boolean readFrom(DatalnputStream dis) throws lOException d -name =dis.readUTFO; long e dis.readLongo; dexpires new Date(e); d-total bytes =dis.readLongo; return(true); TABLE 4T public static int VIEWOK public static int VIEWFAILBADPARAM 1; public static int VIEW_-FAILIQEXCEPTION 2; public static int view(String envelopefilenarne, PrintStream ps) if envelopefilename null 11 ps null) return(VIEWFAILBADPARAM); if envelopeExists(envelopefilena'ne) false) return(EXTRACTFAILBAD._PARAM); try FilelnputStream fis new -FilelnputStream(envelopefilename); DatalnputStream dis new DatainputStream(fis); SdeEnvelopel-eader eh =new SdeEnvelopeHeadero; eh.readFrom(dis); ps.println("Enve lope: eh.d -name ps.println("Created: eh.d-created.to Stringo); .:ps.println("Last modified: eh.d-last-modified.toStringo); ps.println(C'Last accessed: eh.d -last -accessed.toStringo); ps.printin("Contains: eh.d-total-documents document(s)."); fis.closeo; catch lOException ioe) return(VIEWFAILIOEXCEPTION); retun( VIIEW OK); TABLE public static mnt extractDocument(String envelopef ilename, String documentf ilenamne) if( envelopefilename null 11 documentfilename null) return(EXTRACTFAILBADPARAM); :if( envelopeExists(envelopefilename) false) return(EXTRACTFAILBADPARAM); boolean valid true; int invalid-reason ETATFAILUNKOWN; try FilelnputStream fis new FilelnputStream(envelopefienaine); DatainputStream dis =new DatalnputStreani(fss); SdeEnvelopel-eader eh new SdeEnvelopeHeadero; ch.readFrom(dis);, SdeDocumentl-eader dh =new SdeDocumentHeaderO; dh.readfromn(dis); if dh.d nanie.equalslgnoreCase(documentfilename) false) valid =false; invalid-reason

EXTRACTFAILNOTOUND;

if dh.d expires.before(new Dateo)) valid false; invalid-reason EXTRACTFAILINVALID; File file-doc new File(documentfilename); if (file -doc.existso) file-doc new File(documentfilename +11x; FileOutputStreani fos-doc null; if (valid) fos-doc new FileOutputStream(file-doc); for (long I 0; 1 dh.d total bytes; int ch dis.reado; if valid) chA' fos doc.write(ch); if (valid) fos-doc.closeo; fis.closeQ; catch (IQException ioe) return(EXTRACTFAILIOEXCEPTION); if (valid) else return(EXTRACTOK); so retum(invalid reason); TABLE It should be noted, however, that while the exemplary embodiments shown above provide a Java stream-based approach to virtual containers, with a relatively simple Graphical User Interface, a simple encryption technique, and lifetime controls which comprise an expiration date, it should be noted that the invention encompasses a broad array of additional implementations which may. be simpler or more complex.-. In this regard, the user interface could comprise a more complex GUI,- or could comprise a simple comimand line interface without graphics. Similarly, the virtual containers could' also be implemented using the Java serialization mechanism, or could be implemented in another language altogether, such as The lifetime controls, moreover, could be modified to be a function of the number of times a document has been extracted or the number times it has been modified. Moreover, the lifetime controls can be used to convert the document to a read-only document after a specified period of time or to prevent the document from being-copied or printed.

Internet Commerce Application Qf Virtual Containers In accordance with another embodiment of the invention, an Internet commerce system is provided which employs the virtual containers. In accordance with this embodiment, a party who wishes to sell an electronically transmittable product over the Internet places the product into a virtual container using a container creator utility which encrypts the product and sets lifetime controls for the product. In this regard, the seller may wish to allow a potential buyer to view or otherwise use the product for a limited trial period, and to destroy the product after this trial period if a purchase is not made.

A potential buyer of the product who wishes to sampl *e the product prior to purchasing it, obtains a copy of the container along with an container opener utility from the seller.

The container opener utility allows the buyer to view or use the product while maintaining the product in the virtual container. The container opener utility, however, can be configured to prevent the user from printing product (or any portion thereof), from copying the product (or any portion thereof), or modifying the product. If the buyer attempts to view the product without using the container opener, he/she will be unable to decrypt the product. In any event, once the lifetime controls for the product become invalid after a period of time specified by the seller), any subsequent attempt to open the container with the container opener will result in the destruction of the product. It should be noted that the product could be any form of electronic media which can be transmitted in digital form, including, for example, documents, photographs, images, and programs.

In accordance with a further aspect of this embodiment, the buyer can purchase the product prior to the expiration of the lifetime controls by, for example, transmitting his/her credit card information to the seller. After receiving and/or validating the payment information, the seller transmits a purchase key to the buyer. The container opener is configured to recognize the purchase key (which is preferably unique to the 39 particular instance of the product delivered to that particular buyer), and to allow the buyer to extract the product from the container if the purchase key is valid..

Use of Software Components for Virtual Containers and Emibedded Executable Modules In each of the exemplary embodiments set forth. above, the self-destructing documents have been implemented in application specific programs so that a different program was used to implement a self-destructing WordTm document than a self-destructing ExcelTm document. To avoid this repetitive (re-)development process, the Self Destructing Document, or for that matter, the Virtual Container system, can be implemented as a software. component. A software component is an easily-reusable unit of software that.typically provides one simple service.

The Component Object Model (COM) is the Microsoft standard for software component technology. It defines a standard for packaging software for easy reuse. A typical COM component contains two broad categories of content: the functionality of the component implemented as a set of methods (functions), and descriptive information about the component and its functionality. Collectively, this content is referred to as the component's interface. It should be noted that this term is used differently than then the term "user interface." A user interface is typically a graphical display of windows, menus, buttons, and the like that allow a user to interact with the functionality of an application. An "interface", however, more broadly refers to the point(s) of entry into a unit of software (the methods, or functions).

COM components can be used to implement user interface elements, such as. buttons and lists. They can also be used to provide services without a user interface. For example, a COM component could provide mathematical functions to compute sines and cosines.

Although there are subtle technical differences between components and objects, they represent two very similar concepts. As such, this document uses the terms interchangeably in conformance with the idiom of the trade press and technical reference material.

Further, the term control is often used to describe a component that does have a user interface associated with it. In particular, Microsoft uses the term ActiveX Control to describe a special class of COM components that typically have user interfaces.

When a COM component is used to extend the functionality of an existing application, the component is said to be embedded in that application's document Such a component is often referred to as an embedded object. In this regard, we note that Word 9 7 TM, ExcelTM, and Outlook98 T each include support for Visual Basic applications through a library of COM objects.

Application extensions implemented with embedded object techniques generally require the COM component to be installed on the document author's computer.

Further, any user that receives a copy of the document must also generally have the COM component installed on his or her computer to utilize the extended functionality.

In broad strokes, a COM component for a virtual container can be implemented as follows.

1. First, specify the interface for the component. The interface describes each of the services offered by the component. In the case of an SDE component, the services might include CreateEnvelope, AddDocumentToEnvelope, and ExtractDocumentFromEnvelope.

2. Implement each of the services of the component, using a programming 20 language such as Java, or Visual Basic.

3. Use the programming language's development tool to create the COM component.

25 4. Install the COM component on the user's workstation. Implement the small amount of scripting require to invoke the component's services.

It should be noted, however, that the Microsoft COM component standard has been described herein, software components standards promulgated by other manufacturers may also be used.

While there have been described what are presently believed to be the preferred embodiments of the invention, those skilled in the art will realize that changes and Smodifications may be made thereto without departing from the spirit of the invention.

It is intended to claim all such modifications that fall within the scope of the invention.

Claims (27)

1. A virtual container system comprising: a CPU; an electronic memory operatively connected to the CPU, said memory containing an encrypted digital object contained within a virtual container, the virtual container containing information indicative of a lifetime control for the digital object; a key; a computer program executable by the CPU to decrypt the digital object with the key if the lifetime control is valid.

2. The virtual container system of claim 1 wherein the key is maintained in a separate location remote from the electronic memory and unavailable to the program.

3. The virtual container system of claim 2 wherein the key is made available to the program as a function of a user request.

4. The virtual container system of claim 3 wherein the key is a purchase key and the request includes payment.

5. The virtual container system of claim 4 wherein the payment is credit card information,

6. The virtual container system of claim 1 wherein the program is further executable to modify the lifetime control.

7. The virtual container system of claim 6 wherein the program is further executable to modify the lifetime control by eliminating the lifetime control so that the digital object does not expire,

8. The virtual container system of claim 6 wherein the program is further executable to modify the lifetime control by changing an expiration date. 42

9. The virtual container system of claim 6 wherein the program is further executable to modify the lifetime control by changing a number of times the digital object can be opened. The virtual container system of claimi wherein the lifetime control is an expiration date,

11. The virtual container system of claim 1 wherein the lifetime control is a number of times the digital object is opened.

12. The virtual container system of claim I fur-ther comprising: a container creator utility executable to create the virtual container with a header portion containing the information indicative of the lifetime control and a digital object portion containing the digital object; and, a container opener utility executable to determine whether the lifetime control is valid.

13. The virtual container system of' claim 9 wherein the container creator is further executable to encrypt the digital object and write the encrypted digital object into the digital object portion of the virtual container.

14. The virtual container system of claim 10 wherein the container opener is further executable to read the encrypted digital object and decrypt the digital object if the lifetime control is valid. The virtual container system of claim 9 further comprising a software object for displaying the contents of the digital object.

16. The virtual container system of claim 9 wherein the container opener utility is further executable to destroy the digital object if the lifetime control is not valid. V 43

17. The virtual container system of claim 9 wherein the container opener utility is further executable to overwrite the digital object with null data if the lifetime control is not valid.

18. The virtual container system of claim 1 whereinl the virtual container resides in contiguous locations in the electronic memory,

19. The virtual container system of claim I wherein the processor further comprises a client processor and a server processor and the data storage device further comprises a client data storage device and a server data storage device. The virtual container system of claim 19 wherein the server processor further comprises a server program executable by the server processor to distribute the digital object and the key as a function of user requests.

21.A method for transmitting an expiring digital object to a recipient comprising the steps of: I.:...:creating a virtual container with a header portion and a digital obj ect portion; encrypting a digital object; writing the encrypted digital object into the digital object portion; selecting a lifetime control for the digital object; writing information indicative of the lifetime control into the header portion of the virtual container, transmitting the virtual container to a recipient.

22. The method of claim 21 further comprising the steps of reading the lifetime control; decrypting the digital object if the lifetime control is valid.

23. The method of claim 21 further comprising the steps of: providing a kcey; using the key to modify the Lifetime control. S 44

24. The method of claim 23 flurther comprising the step of accepting payment before providing the key, The method of claim 23 wherein the using step further comprises eliminating the lifetime control.

26. The method of claim 23 wherein the using step further comprises changing the lifetime control.

27. The method of claim 22 further comprising the step of destroying the digital object if the lifetime control is not valid, 28, The method of claim 27 wherein the destroying step further comprises overwriting the digital object with null data.

29. The method of claim 21 wherein the transmitting step further comprises transmitting the virtual container via the Internet. The method of claim 21 wherein the creating step further comprises the steps of: creating a container header with information regarding the container including a container name; creating a digital object header for each of a plurality of digital objects, the digital object header containing information regarding the digital object including a name of the digital object; storing each digital object adjacent to its respective digital object header in the virtual container. 3 1. The method of claim 30 wherein the step of writing the information indicative of the lifetime control includes, for each digital object, writing the information for said digital object into the container header,

32. The method of claim 30 wherein the step of writing the information indicative of the lifetime control includes, for each digital object, writing the information for said digital object into the digital object header for said digital object.

33. The method of claim 21 wherein the creating step further comprises: creating the virtual container in contiguous locations in an electronic memory.

34. A method for extracting information from a virtual container, comprising the steps of: reading information indicative of a lifetime control from a header portion of a virtual container, the virtual container including the header portion and a digital object portion, the digital object portion containing an encrypted digital object; determining, based upon said information, if the lifetime control is valid; reading the digital object from the digital object portion and decrypting the digital object if the lifetime control is valid. The method of claim 34 further comprising overwriting the digital object portion of the virtual container with null data if the lifetime control is invalid. S: 20 36. The method of claim 34 wherein the virtual container resides in contiguous o• locations in an electronic memory. DATED this fourteenth Day ofMarch, 2003 Purdue Pharma LP Patent Attorneys for the Applicant SPRUSON FERGUSON 9% *eoo o [R:\LIBQ] 1750.doc:eaa