Abstract:
Systems that provide users with a model for designing, implementing, complying with, and proving compliance with, message life cycle management policies are disclosed. Such a model may be based on the notion of folders upon which policies are defined, new restrictions on such folders, mechanisms to assure that users have such folders, and mechanisms to establish how well users are complying with the policies by determining how they are filing items into the folders. The concept can be extended to other mutually exclusive grouping mechanisms.

Description:
BACKGROUND  
       [0001]     Electronic messages such as e-mail and instant messages have become a dominant form of communication in most businesses today. Because they have become so ubiquitous and so critical to every phase of business, proper management of such messages has become essential. High profile legal and regulatory cases have been won and lost on the basis of electronic messages that have been incorrectly retained, and managed.  
         [0002]     A key technical inhibitor to companies avoiding such problems in the future is a lack of policy-based, cohesive message life-cycle management capabilities. Enforcing a life-cycle management policy manually tends to be cumbersome and ineffective. Systems that automatically enforce such policies, however, typically do not respect content. Ensuring that important items are kept is often difficult. There is often no advanced warning of expiring items, and a user can typically recover expired items from a “dumpster.” 
         [0003]     In existing systems, message life-cycle management is typically a layer atop the message store and hence can provide limited functionality and few guarantees that the policies are being enforced. For example, a message deletion request that goes directly against the store without going through the message life-cycle management software may delete a message that has specifically been requested to be preserved. Furthermore, the policies are often so complicated that users cannot easily comply with them. Even if they could, there is typically no efficient way to tell whether users are following a policy.  
         [0004]     Another shortcoming of existing systems is that discovery tends to be time-consuming and expensive. Discovery refers to searching for certain items or classes of items, typically in response to a request for same in the context of litigation or a regulatory-related action. Discovery tends to be difficult because e-mails tend to be numerous and exist in many different locations.  
       SUMMARY  
       [0005]     Systems that provide users with a model for designing, implementing, complying with, and proving compliance with message life cycle management policies are described and claimed herein. Such a model may be based on the notion of “folders” upon which policies are defined, new restrictions on such folders, mechanisms to assure that users have such folders, and mechanisms to establish how well users are complying with such policies by determining how the users are filing items into the folders. It should be understood that the concept can be extended to other grouping mechanisms. Such grouping mechanisms may be mutually exclusive, though it is possible to have overlapping grouping mechanisms and to enforce multiple policies on a single item.  
         [0006]     A folder may be the unit of policy definition and enforcement. This is the most simple and intuitive message grouping mechanism available to users and therefore the mechanism with which it is easiest for them to comply. Such folders may be automatically created by a daemon process on a regular basis so all users routinely get the updated set of folders into which they should be classifying items such as e-mail messages, calendar items, notes, etc. Such folders may have special properties imparted to them by the fact that they are part of the message lifecycle system. Policies on those folders, such as retention and deletion rules, may supersede not only the user&#39;s request but also any rules or policies put on them by another mechanism.  
         [0007]     An email life cycle system as disclosed herein may allow users to classify content by dragging items into special “Organizational” folders in the mailbox used for filing e-mail. An “Organizational” folder, as that term is used herein, refers to a folder that is used for the purposes of classifying items in order to ensure that the appropriate email lifecycle policies are enforced. An Organizational folder may have a quota associated with it. A system administrator may create an Organizational folder and “push” it into a user&#39;s mailbox. The system may provide a web page list of folders from which a user can select. Thus, an Organizational folder may be chosen by the user.  
         [0008]     Policies may be configurable by a system administrator. E-mail that is no longer needed may be deleted, with configurable expiration policies. E-mail that needs to be kept may be retained by copying it to a “repository.” A “repository,” as that term is used herein, refers to a controlled storage location for the purpose of maintaining items in compliance with a policy. Summary reports may be provided to show how well users are complying with life-cycle management policy. A discovery tool may be provided for performing enhanced searches. 
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0009]      FIG. 1  is a flowchart of an example method for management and administration of message life-cycle management policies and administration.  
         [0010]      FIG. 2  depicts a user interface for creating a new e-mail lifecycle folder.  
         [0011]      FIGS. 3 and 4  depict user interfaces for creating new e-mail lifecycle content settings.  
         [0012]      FIG. 5  depicts linking the settings for an ELC folder to the settings for a mailbox.  
         [0013]      FIG. 6  depicts a user interface for adding an organizational folder to a mailbox.  
         [0014]      FIG. 7  depicts a user interface for displaying an ELC assistant schedule.  
         [0015]      FIG. 8  depicts a mailbox folder display including a number of Organizational folders.  
         [0016]      FIG. 9  depicts a user interface that enables a user to classify content.  
         [0017]      FIG. 10  depicts a user interface for a discovery tool.  
         [0018]      FIG. 11  is a block diagram showing an example computing environment in which aspects of the invention may be implemented. 
     
    
     DETAILED DESCRIPTION  
       [0019]     Mailbox folders are a natural way for users to classify important information. Accordingly, as disclosed herein, an “Organizational” folder may be the way in which messages are grouped for policy enforcement. The creation of grouping mechanisms for messages may include: 1) the collections to which policies are applied; 2) policies that can be applied to that grouping; and 3) mechanisms to prove adherence to the policies.  
         [0020]     An Organizational folder, may have several special properties. First, policies may be associated with Organizational folders (similar to the way in which properties are applied to folders in a general file system, or by storing the information in a corporate metadata repository such as LDAP, or Active Directory). Second, only an administrator can change the policy settings on these folders. Third, users may be prevented from renaming, moving, or (in most cases) deleting this folder type. Fourth, an administrator can enter a URL or text describing the policy. The e-mail lifecycle service (ELC) will then stamp this information on the folders in the user&#39;s mailbox and the messaging client can display this text to the user. This enables administrators to inform users about general corporate e-mail lifecycle policies as well as information about policies that apply to “Organizational” folders in a natural and intuitive manner. Fifth, a scheduled service may scan the metadata repository settings and compare to the settings in the user&#39;s mailbox. The service may install new folders into the user&#39;s mailbox as dictated in the metadata repository, change policy settings in the mailbox if the setting in the metadata repository have changed, and rename the mailbox folder if the folder name has changed. By creating this simple model, companies can enforce standard records management policies on the folders uniformly across the company, deploy certain policy folders administratively to users, and prevent these folders from being modified or deleted by the user.  
         [0021]     In some businesses, however, a records administrator cannot handle the work load to determine the folders needed by each user. As a result, users may also be given a mechanism whereby they can allocate an “Organizational” folder to their mailbox. While the user has this folder, the company&#39;s policies are enforced upon it. Since the user requested the folder, he/she may be allowed to delete it whenever the user deems it necessary. However, the user may not be allowed to rename or move the folder.  
         [0022]     The following are examples of policies that can be defined on content grouped via an “Organizational” folder. An “AutoCopy” policy may be provided whereby messages may be copied on a per-folder basis to an alternate message repository, which may support SMTP. This enables certain messages to be retained for a specific period of time regardless of user action, or action to that user.  
         [0023]     A “Review Before Deletion” or “cascading expiration” policy may be provided for creating a compliant records-management policy that demonstrates due diligence in retaining information. Accordingly, it may be desirable to provide a mechanism by which items that will be removed in the near future are highlighted in some way, allowing the user to review and take action to keep any needed items. For example, users may be given the ability to review messages that will be deleted in the near future before the disposal occurs by moving message to be delete into a “Cleanup Review” folder (the folder name is configurable) from its original location in the mailbox. The message may remain in this folder for a specific period of time during which the user may review and save any needed items before they are automatically deleted. Optionally, the E-mail Lifecycle service can send warning e-mails to users giving them information about the items that will expire in the near future. Administrators can customize these warning e-mails by customizing the subject and report text.  
         [0024]     An “Expiration” policy may be provided whereby messages that are no longer needed for business or regulatory reasons are automatically disposed of on a per-folder basis once they reach a certain age. This prevents them from taking up space and increasing message management costs or surviving past their designated expiration time.  
         [0025]     A “Preservation” policy may be provided whereby messages may be retained in the user&#39;s mailbox on a per-folder basis. The user cannot delete these messages until they reach the end of its retention period.  
         [0026]     A “per-folder quota” policy may be provided to limit the amount of data that may be placed in a folder and its subfolders. This enables much more fine-grained storage quota support to allow administrators to controls how users utilize their mailbox storage in the presence of E-mail Lifecycle folders.  
         [0027]     To establish a baseline set of policies for “everything else,” a policy can be created that applies to all folders for which a policy has not already been defined.  
         [0028]     Any or all of the above-described policies may be applied, by default, to any message in the associated folder. However, different message types often require different policies. For example, an e-mail related to a certain subject may need to be retained for three years, whereas a voicemail attachment may be considered useful only for 90 days. It may be desirable, therefore, that multiple policy entries can be created for the same folder if they each specify different message classes. Hence there can be a policy for e-mail and another for voice mails.  
         [0029]     Another policy would be restricting deletion of messages from a “dumpster.” It is common in messaging systems to support a “dumpster,” into which deleted items are placed temporarily. This allows users to quickly recover these items from accidental deletion errors. It is also used as an alternate mechanism to retain messages for a longer period of time by ensuring that messages remain in the system long enough to be captured by a backup process. A “dumpster” is also useful for companies that wish to recover messages during investigations of corporate policy violations. Today a user can delete an item from their mailbox and then delete it from their “dumpster,” negating the aforementioned benefits. Preventing users from deleting items from the dumpster protects these benefits.  
         [0030]     To track compliance, one may record when an item was filed into an “Organizational” folder. Providing the information as to when an item was categorized helps to demonstrate that a company&#39;s recordkeeping practices are accurate and compliant.  
         [0031]      FIG. 1  is a flowchart of an example method  200  for management and administration of message life-cycle management policies and administration. At  202 , a new ELC mailbox folder may be created.  FIG. 2  depicts a user interface for creating a new ELC folder. An email lifecycle folder is a folder in a mailbox with settings that control the content the folder contains. As shown in  FIG. 2 , a user, such as a system administrator, can choose a default mailbox folder (e.g., Inbox) to apply e-mail lifecycle settings to, or the administrator can create a custom Organizational folder. The administrator can supply a name for the folder, and a storage limit for the folder and its subfolders. The administrator can also supply a name for the e-mail lifecycle folder to be displayed. The administrator can also supply the text of a comment that can be displayed when the folder is viewed in the document viewer or e-mail client. The administrator can indicate (such as by checking or unchecking a box, for example) whether end-users should be allowed to minimize the comment when the folder is viewed in Outlook. After the administrator supplies the information, the administrator can cause the system to create the folder by clicking the “Create” button. The user interface may also include a “Cancel” button that enables the administrator to cancel the creation of an ELC folder, and a “Help” button that causes the system to provide explanatory information to the administrator.  
         [0032]     At  204 , ELC content settings are created for the folder. ELC content settings may provide a way to control the lifespan of items within a specified message type. For example, a content setting may be created to cause items to expire based on age and to be automatically copied to another location for storage. Content settings may also provide a manner to copy in item to an archive, as discussed below. It should be understood that the concept of content settings may be generalized to the enforcement of some type of policy upon items tied together by some sort of grouping mechanism (e.g., a folder).  
         [0033]      FIGS. 3 and 4  depict user interfaces for creating new e-mail lifecycle content settings. As shown in  FIG. 3 , the administrator may supply a message type (e.g., voicemail). The administrator may also supply an expiration period (i.e., a period after which the message is deemed “expired”). The period may be specified in days, for example, or any other unit of time. The administrator may define when the expiration period starts (e.g., when the item is moved to the folder), and may specify an action to be taken when the message expires (e.g., permanently delete the item). The administrator may also specify the name of an Organizational folder to which the messages should be moved upon expiration. The administrator may supply a name for the ELC content settings to be displayed in the Microsoft Exchange System Manager. The user interface may also include a “Cancel” button that enables the administrator to cancel the creation of content settings, a “Help” button that causes the system to provide explanatory information to the administrator, and a “Next” button that enables the administrator to move onto a next screen.  
         [0034]     As shown in  FIG. 4 , the administrator may select whether to automatically forward a copy of items of the specified message type to another location (e.g., by checking/unchecking a box, for example). The administrator may supply a name associated with the location (e.g., a name of a folder to which the items are to be autocopied). The administrator can assign a label to the copy of the message, and specify a message format associated with the message. The user interface may also include a “Cancel” button that enables the administrator to cancel the creation of content settings, a “Help” button that causes the system to provide explanatory information to the administrator, a “Next” button that enables the administrator to move onto a next screen, and a “Back” button that enables the administrator to move back to a previous screen.  
         [0035]     At  205 , the folder may be linked to a policy, which is effectively a grouping mechanism for folders. This policy is then applied to a mailbox, at  206 , by linking the settings for the folder to the settings for the mailbox. As shown in  FIG. 5 , settings associated with a mailbox  300  may be defined at  302 . A new mailbox policy, which is used to group folders, may be created at  304 . The new folders may then be linked to the mailbox policy at  306 . The mailbox policy may then be applied to the mailbox  300  at  308 . Thus, a link may be formed from the folder and content settings, via the policy, to the mailbox settings. As shown, the mailbox  300  may include a default folder (e.g., Inbox)  310  and an Organizational Folder (e.g., Legal Docs)  320 . A first set of content settings  312  may be defined for the default folder  310  (e.g., delete all e-mails after 365 days). A second set of content settings  322  may be defined for the Organization folder  320  (e.g., copy all voicemails to archive).  
         [0036]     The administrator may “push” the folders to the mailbox, or the end-user may pull one or more Organizational folders into his or her mailbox. To pull folders, the end-user may navigate to a user-interface, such as an opt-in web page, for example, that enables the user to select from a number of available Organizational Folders. An example of such a user interface is depicted in  FIG. 6 . As shown, the end-user may be presented with a list of available Organizational folders. Each such folder may have an associated name. The user interface may also provide a respective description of each of the available folders. The description may be provided in any language, such as Latin, for example, and the language in which the description is given need not be the same as the language in which the name is given. The end-user can select one or more folders to be added to the end-user&#39;s mailbox by checking respective boxes associated with the folders to be added. The user interface may include a button that the end-user can select to cause the system to add the selected folders to the end-user&#39;s mailbox.  
         [0037]     The ELC service may then be instructed to act upon these settings by creating, at  208 , the appropriate folders in the mailbox and enforcing, at  210 , the life-cycle management policies associated with those folders. The ELC service may launch an “ELC assistant,” according to a schedule, to enforce the life-cycle management policies.  FIG. 7  depicts a user interface for displaying and defining such a schedule. The system administrator can define any desired schedule accordingly to which the ELC assistant is to run.  
         [0038]     If the end-user selected one or more Organizational folders to be added to the mailbox, the selected folders may be added immediately upon the end-user&#39;s selection of the “Add to Outlook” button. If the system administrator arranged for the folders to be pushed to the end-user&#39;s mailbox, the next time the ELC assistant runs, the ELC assistant will create the necessary folders in the mailbox.  FIG. 8  depicts an end-user&#39;s mailbox folder display after a number of Organizational folders have been added to the end-user&#39;s mailbox. As shown, for example, one or more Organizational folders (e.g., Business Critical Long T, Business Value, Client Contracts, and Pilot Plans) may exist under a collective folder named “My Organizational Folders.” 
         [0039]      FIG. 9  depicts a user interface that enables a user to classify content. As described above, Organizational folders may be provisioned in mailboxes. Preferably, these folders cannot be moved, renamed, or deleted. Lifecycle management policies may be enforced on a per-folder basis. A user may classify items by dragging them into folders. As described above, Outlook can display a description of the policy, as shown in  FIG. 9 .  
         [0040]     Each time the ELC assistant is run, it determines which emails are no longer needed (i.e., have expired) and which need to be kept. E-mails that have expired can be deleted. Expiration policies may be configurable per message type (e.g., e-mail, appointment, voicemail, etc.) within a folder and may be based on message age/size. Policy actions may include deleting a message (which may include permanently deleting an item, or moving a “deleted” item to a location from which it may be recovered), moving a message to another folder, marking a message as expired, and logging only. Optionally, an e-mail listing soon-to-be-deleted items can be sent out to all end-users of the mailbox system, or to those end-users whose mailboxes have items that are soon to be deleted. A log listing each expired item may be maintained.  
         [0041]     E-mails that need to be kept can be autocopied to a repository (i.e., Exchange, SharePoint, or KVS, for example). An item sent to the repository may be stamped with a label to note how it was classified. A log listing each autocopied item may be maintained.  
         [0042]     Logs can be maintained, and summary reports can be provided, to show the extent of (non)compliance with the lifecycle management policies. Logs may be kept locally, or in a Microsoft Office Manager or system center for data consolidation and viewing. Reports can include statistics to show the number of items and amount of data in different e-mail filing folders. Users who are not following a policy can also be listed.  
         [0043]      FIG. 10  depicts a user interface for a discovery tool that enables a system administrator to search through items across multiple mailboxes. The discovery tool may scan all messages and attachments. As shown, the system may enable the administrator to search on any number of message document properties. For example, the system may enable the administrator to perform full-text, keyword searches, and to restrict a search by Mailbox/DL and/or date range. The system enables the administrator to name the search, and to designate an “output mailbox” to which the results are to be exported. It should be understood that search results may be gathered in any number of ways, and that exporting search results to a mailbox is merely an example.  
         [0044]     Search results may be “triaged” with Outlook/OWA, for example. OWA (Outlook Web Access) allows a client with a compatible browser to access Exchange Server folders. “Triage,” as that term is used herein, refers to a records management discovery process that sifts through matched items to determine which items are, in fact, items of interest. As the items are contained in a separate mailbox, a special review tool need not be provided. That is, a standard email client such as Outlook or OWA may be employed.  
         [0045]     The user interface may also enable the administrator to request (by checking a box, for example) a detailed audit log associated with the search.  
       EXAMPLE COMPUTING ENVIRONMENT  
       [0046]      FIG. 11  and the following discussion are intended to provide a brief general description of a suitable computing environment in which an example embodiment of the invention may be implemented. It should be understood, however, that handheld, portable, and other computing devices of all kinds are contemplated for use in connection with the present invention. While a general purpose computer is described below, this is but one example. The present invention also may be operable on a thin client having network server interoperability and interaction. Thus, an example embodiment of the invention may be implemented in an environment of networked hosted services in which very little or minimal client resources are implicated, e.g., a networked environment in which the client device serves merely as a browser or interface to the World Wide Web.  
         [0047]     Although not required, the invention can be implemented via an application programming interface (API), for use by a developer or tester, and/or included within the network browsing software which will be described in the general context of computer-executable instructions, such as program modules, being executed by one or more computers (e.g., client workstations, servers, or other devices). Generally, program modules include routines, programs, objects, components, data structures and the like that perform particular tasks or implement particular abstract data types. Typically, the functionality of the program modules may be combined or distributed as desired in various embodiments. Moreover, those skilled in the art will appreciate that the invention may be practiced with other computer system configurations. Other well known computing systems, environments, and/or configurations that may be suitable for use with the invention include, but are not limited to, personal computers (PCs), automated teller machines, server computers, hand-held or laptop devices, multi-processor systems, microprocessor-based systems, programmable consumer electronics, network PCs, minicomputers, mainframe computers, and the like. An embodiment of the invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network or other data transmission medium. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.  
         [0048]      FIG. 11  thus illustrates an example of a suitable computing system environment  100  in which the invention may be implemented, although as made clear above, the computing system environment  100  is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the invention. Neither should the computing environment  100  be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the exemplary operating environment  100 .  
         [0049]     With reference to  FIG. 11 , an example system for implementing the invention includes a general purpose computing device in the form of a computer  110 . Components of computer  110  may include, but are not limited to, a processing unit  120 , a system memory  130 , and a system bus  121  that couples various system components including the system memory to the processing unit  120 . The system bus  121  may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. By way of example, and not limitation, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus (also known as Mezzanine bus).  
         [0050]     Computer  110  typically includes a variety of computer readable media. Computer readable media can be any available media that can be accessed by computer  110  and includes both volatile and nonvolatile, removable and non-removable media. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media. Computer storage media includes both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, random access memory (RAM), read-only memory (ROM), Electrically-Erasable Programmable Read-Only Memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CDROM), digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by computer  110 . Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, radio frequency (RF), infrared, and other wireless media. Combinations of any of the above should also be included within the scope of computer readable media.  
         [0051]     The system memory  130  includes computer storage media in the form of volatile and/or nonvolatile memory such as ROM  131  and RAM  132 . A basic input/output system  133  (BIOS), containing the basic routines that help to transfer information between elements within computer  110 , such as during start-up, is typically stored in ROM  131 . RAM  132  typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit  120 . By way of example, and not limitation,  FIG. 11  illustrates operating system  134 , application programs  135 , other program modules  136 , and program data  137 . RAM  132  may contain other data and/or program modules.  
         [0052]     The computer  110  may also include other removable/non-removable, volatile/nonvolatile computer storage media. By way of example only,  FIG. 11  illustrates a hard disk drive  141  that reads from or writes to non-removable, nonvolatile magnetic media, a magnetic disk drive  151  that reads from or writes to a removable, nonvolatile magnetic disk  152 , and an optical disk drive  155  that reads from or writes to a removable, nonvolatile optical disk  156 , such as a CD ROM or other optical media. Other removable/non-removable, volatile/nonvolatile computer storage media that can be used in the example operating environment include, but are not limited to, magnetic tape cassettes, flash memory cards, digital versatile disks, digital video tape, solid state RAM, solid state ROM, and the like. The hard disk drive  141  is typically connected to the system bus  121  through a non-removable memory interface such as interface  140 , and magnetic disk drive  151  and optical disk drive  155  are typically connected to the system bus  121  by a removable memory interface, such as interface  150 .  
         [0053]     The drives and their associated computer storage media discussed above and illustrated in  FIG. 11  provide storage of computer readable instructions, data structures, program modules and other data for the computer  110 . In  FIG. 11 , for example, hard disk drive  141  is illustrated as storing operating system  144 , application programs  145 , other program modules  146 , and program data  147 . Note that these components can either be the same as or different from operating system  134 , application programs  135 , other program modules  136 , and program data  137 . Operating system  144 , application programs  145 , other program modules  146 , and program data  147  are given different numbers here to illustrate that, at a minimum, they are different copies. A user may enter commands and information into the computer  110  through input devices such as a keyboard  162  and pointing device  161 , commonly referred to as a mouse, trackball or touch pad. Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to the processing unit  120   a - f  through a user input interface  160  that is coupled to the system bus  121 , but may be connected by other interface and bus structures, such as a parallel port, game port or a universal serial bus (USB).  
         [0054]     A monitor  191  or other type of display device is also connected to the system bus  121  via an interface, such as a video interface  190 . In addition to monitor  191 , computers may also include other peripheral output devices such as speakers  197  and printer  196 , which may be connected through an output peripheral interface  195 .  
         [0055]     The computer  110  may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer  180 . The remote computer  180  may be a personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer  110 , although only a memory storage device  181  has been illustrated in  FIG. 11 . The logical connections depicted in  FIG. 11  include a local area network (LAN)  171  and a wide area network (WAN)  173 , but may also include other networks. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Internet.  
         [0056]     When used in a LAN networking environment, the computer  110  is connected to the LAN  171  through a network interface or adapter  170 . When used in a WAN networking environment, the computer  110  typically includes a modem  172  or other means for establishing communications over the WAN  173 , such as the Internet. The modem  172 , which may be internal or external, may be connected to the system bus  121  via the user input interface  160 , or other appropriate mechanism. In a networked environment, program modules depicted relative to the computer  110 , or portions thereof, may be stored in the remote memory storage device. By way of example, and not limitation,  FIG. 11  illustrates remote application programs  185  as residing on memory device  181 . It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.  
         [0057]     One of ordinary skill in the art can appreciate that a computer  110  or other client devices can be deployed as part of a computer network. In this regard, the present invention pertains to any computer system having any number of memory or storage units, and any number of applications and processes occurring across any number of storage units or volumes. An embodiment of the present invention may apply to an environment with server computers and client computers deployed in a network environment, having remote or local storage. The present invention may also apply to a standalone computing device, having programming language functionality, interpretation and execution capabilities.