Single retention policy

[0001] The invention relates generally to data archival and retention, and specifically, to implementing retention policies for related data objects.

[0002] Retention-based archiving applications are used to ensure compliance with certain legal obligations. A retention-based archiving application or similar program is typically installed on a client or server for the purpose of identifying the appropriate retention policy for data objects stored on the client or server. The specific archive and/or retention policy for a data object may differ depending upon the content or other attributes for the object. Software for an enterprise resource planning (ERP) system, a retention-based archiving application, or similar applications may be responsible for determining the appropriate retention policy for a data object. Once a retention policy has been determined for an object, the information about that policy may be stored in metadata associated with the object. This retention information may include metadata describing how long to retain the object in archive storage, i.e., the retention interval for that object. The retention information is then sent along with the data object to the archive store, which enforces a retention policy based upon the retention information.

[0003] Retention policy information is usually specific for the system that assigned the policy. For example, one ERP may determine the appropriate retention policy for one document in a group of documents, whereas another retention-based archiving application may determine a a retention policy for another document in the group. Both the ERP and the retention-based archiving application may in fact have determined retention policies with the same retention interval, but because the respective retention policies were assigned by different systems, the retention information metadata will differ. This creates redundancy and maintenance problems for the archive store.

[0004] In another example, when a financial document is archived and stored in an archive store, it will be assigned a retention policy by an ERP, which will determine the retention interval and disposing method. However, the repository may already store other files related to the archived document, such as scanned originals. These related files may have been assigned separate retention policies, which may or may not be consistent with the retention policy assigned to the financial document. What is therefore needed is a way to reconcile the different retention policies for related documents.

[0008] The invention is a system and method for implementing a single retention policy for related data objects, regardless of the system or application that may have previously determined and/or assigned a retention policy or policies to the related objects. The invention ensures that related objects are subject to the same retention interval.

[0009] It should be appreciated that the invention can be implemented in numerous ways, including as a process, an apparatus, a system, a device, a method, a computer readable medium such as a computer readable storage medium containing computer readable instructions or computer program code, or as a computer program product comprising a computer usable medium having a computer readable program code embodied therein.

[0010] In the context of this document, a computer usable medium or computer readable medium may be any medium that can contain or store the program for use by or in connection with the instruction execution system, apparatus or device. For example, the computer readable storage medium or computer usable medium may be, but is not limited to, a random access memory (RAM), read-only memory (ROM), or a persistent store, such as a mass storage device, hard drives, CDROM, DVDROM, tape, erasable programmable read-only memory (EPROM or flash memory), or any magnetic, electromagnetic, infrared, optical, or electrical system, apparatus or device for storing information. Alternatively or additionally, the computer readable storage medium or computer usable medium may be any combination of these devices or even paper or another suitable medium upon which the program code is printed, as the program code can be electronically captured, via, for instance, optical scanning of the paper or other medium, then compiled, interpreted, or otherwise processed in a suitable manner, if necessary, and then stored in a computer memory.

[0011] Applications, software programs or computer readable instructions may be referred to as components or modules. Applications may be hardwired or hard coded in hardware or take the form of software executing on a general purpose computer such that when the software is loaded into and/or executed by the computer, the computer becomes an apparatus for practicing the invention. Applications may also be downloaded in whole or in part through the use of a software development kit or toolkit that enables the creation and implementation of the invention. In this specification, these implementations, or any other form that the invention may take, may be referred to as techniques. In general, the order of the steps of disclosed processes may be altered within the scope of the invention.

[0012] FIG. 1 is a block diagram illustrating an embodiment of a system for implementing a single retention policy. In the example shown, client computer or workstation 101 is coupled to server 111 and archive store 121 over a network 131. Network 131 may be a local network, a wide area network (WAN), the Internet, a wired network, a wireless network, or a direct connection. Client computer 101 and server 111 may each store data objects for archiving. On client computer 101, identification of data objects for archiving may be performed by a retention-based archiving application 105, which may also be a client computer version of a ERP system. Similarly, on server 111, a retention-based archiving application 115 or ERP may be responsible for identifying which data objects should be archived from server 111. Moreover, the example below will describe an embodiment in which the server 111 and the client computer 101 both utilize a retention-based archiving application rather than an ERP. One skilled in the art, however, will appreciate that the server 111 and client computer 101 can both utilize an ERP, or that one may use a retention-based archiving application and the other may use an ERP. The retention-based archiving application 105 on client computer 101 may not be the same as the retention-based archiving application 115 on server 111. In an embodiment, even if these applications differ, both application 105 and application 115 may identify data objects for archiving and may calculate and associate metadata with each respective data object. This metadata may describe the appropriate retention policy for the associated data object.

[0013] The system may also include an archive store 121. Data objects from client computer 101 or server 111 may be sent to archive store 121 for storage. In an embodiment, archive store 121 communicates with retention-based archiving application 105 or retention-based archiving 115 using an archive connector software layer 125. The connector layer 125 may be responsible for receiving data objects for archiving, and sending the data objects to a repository by calling the archive store 121 API. In this embodiment, the connector layer communicates directly with the retention-based archiving application. The archive store 121 may also assign retention policies directly through a retention-based archiving application with the use of archive connector software layer 125.

[0014] FIG. 2 is a flow diagram illustrating an embodiment of a method for implementing a single retention policy for data objects stored in an archive store. One will appreciate that even though the following example refers to a single archive store, the method embodiment will work with related data objects stored in different locations as well.

[0015] One will appreciate that during the archive process, each archived data object is typically associated with retention information metadata. This metadata may include the following types of information about the data object: (1) content attributes, e.g., whether the object is a MS Word document, an Adobe PDF file or a binary image; (2) business-related attributes, i.e., the object's name, creation/modification date, author, etc.; or (3) retention-related attributes, i.e., a retention policy identifier (policy ID), retention interval, name of the applicable legal policy or hold on the object, disposal method, etc. Some or all of these types of metadata is sent with the data object to the archive store during archival. The archive store uses this information to enforce the retention policy for the prescribed retention interval. However, the invention can make use of this metadata in order to match related objects and assign a single retention policy.

[0016] In an embodiment, the following method is performed by the archive store 121. However, one will appreciate that a software layer, or archiving connector layer 125 on archive store 121 may perform the following method. As discussed previously, the connector layer 125 may be responsible for receiving data objects for archiving, and sending the data objects to a repository by calling the archive store API. In an embodiment, the archive store 121 may be acting through a retention-based archiving application that may also be responsible for assigning retention policies. In an embodiment, the retention-based archiving application may communicate with an archiving connector layer 125 in order to perform the method of FIG. 2.

[0017] In 201 of FIG. 2, at least two data objects are received by the archive store 121, each data object associated with metadata assigned or calculated by a respective retention-based archiving application. In other words, each data object will have retention information assigned prior to archival, but the respective retention policy appropriate for this retention information has not been attached or enforced. The archive store 121 will perform the function of attaching the appropriate retention policy for each data object.

[0018] In 203 of FIG. 2, the archive store 121 reads the respective metadata associated with each data object. In 205 of FIG. 2, the archive store 121 determines whether the metadata for each respective data object contains retention interval information, or whether the metadata for each respective data object contains a policy ID. If both the respective metadata for both objects contain retention interval information, then in 207 of FIG. 2, the archive store 121 determines whether the retention interval information for each data object matches. This may require querying the policies already being enforced by the archive store 121, and seeing if any of these existing policies have the same retention interval information for each data object. If so, then in 209 of FIG. 2, the archive store 121 will assign a single retention policy with the same retention interval to the two data objects. If the retention interval information for each data object do not match, then in 211 of FIG. 2, the archive store 121 will attach a new retention policy appropriate for each object based upon their respective retention interval information.

[0019] If in 205 of FIG. 2, the archive store determines that the metadata for each respective data object contains a policy ID instead of retention interval information, then in 217 of FIG. 2, the archive store 121 determines whether the policy ID for both data objects matches an existing retention policy. This may require querying the policies already being enforced by the archive store, and determining whether any of these existing policies has the same policy ID as the two data objects. If an existing retention policy matches the policy ID for both data objects, then in 219 of FIG. 2, the archive store 121 will assign that retention policy to the two data objects. If the archive store cannot locate a matching retention policy for the data objects' policy IDs, then in 211 of FIG. 2, the archive store 121 will attach a new retention policy appropriate for each object based upon their respective metadata. One will appreciate that if the metadata for one of the data objects contains a policy ID matching an existing retention policy, then that data object will be assigned the existing retention policy, even if the policy ID for the other data object does not match any existing retention policy. For the non-matching data object, the archive store 121 may assign a new retention policy appropriate for the non-matching data object.

[0020] One skilled in the art will appreciate that the method described above is merely exemplary, and that variations are possible. For example, the archive store 121 may be configured to only match retention interval information as illustrated in 207-211 in FIG. 2. This configuration may ignore policy IDs for data objects. Similarly, the archive store 121 may be configured to only match policy IDs and ignore retention intervals. In an embodiment, the metadata for data objects may contain both retention interval information and policy IDs. In this embodiment, the archive store 121 may be configured to only match retention interval information or only match policy IDs. Deciding which configuration to use may be set by an administrator, or may be a default setting of the archive store 121. In an embodiment, the archive store 121 may be configured to match other metadata instead of retention interval information or policy IDs. For example, the archive store may be configured to assign a single retention policy based upon matching content or business-related attributes, or a combination of content, business-related and/or retention-related attributes. The method described herein contemplates matching any common metadata for archived objects in order to assign and enforce a single retention policy for matched objects.

[0021] In an embodiment, the method of FIG. 2 may be performed upon the receipt of a single data object. In this embodiment, the archive store 121 will already manage one or more retention policies. In 201 of FIG. 2, the archive store 121 may receive a single data object with associated metadata. In 203 of FIG. 2, the archive store reads the metadata. In 205 of FIG. 2, the archive store 121 determines whether the data object's metadata includes retention interval information or policy ID information. If the data object's metadata includes retention interval information, then in 207 of FIG. 2, the archive store 121 will match this retention interval information with any of the retention policies it is already managing. This may require querying the policies already being enforced by the archive store 121, and determining whether any of these existing policies has the same retention interval as the received data object. If the retention interval information of the data object's metadata matches the retention interval information for a policy that the archive store is already managing, then in 209 of FIG. 2, the archive store 121 will assign the matching retention policy to the data object. However, if the archive store 121 cannot locate a matching retention policy, then it may assign a new policy in 211 of FIG. 2. The new policy may be based upon information from the data object's metadata.

[0022] If in 205 of FIG. 2, the data object's metadata contains a policy ID, then in 217 of FIG. 2, the archive store 121 will attempt to match the metadata policy ID with any of the retention policies that the archive store 121 is already managing. This may require querying the policies already being enforced by the archive store 121, and determining whether any of these existing policies has the same policy ID as the received data object. If there is a matching retention policy, then in 217 of FIG. 2, the archive store 121 will assign the matching retention policy to the data object. If there is no matching retention policy, then in 219 of FIG. 2, the archive store 121 will assign a new policy based upon the data object's metadata. One will appreciate that some metadata may include both retention interval information and policy ID information. In such situations, the archive store 121 may be configured to match retention interval information, rather than policy ID information, or vice-versa. In an embodiment, the archive store 121 may first attempt to match retention interval information, and if unsuccessful, then may attempt to match policy ID information.

[0023] One will appreciate that in the description above and throughout, numerous specific details are set forth in order to provide a thorough understanding of the invention. It will be evident, however, to one of ordinary skill in the art, that the invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form to facilitate explanation. The description of the preferred embodiments is not intended to limit the scope of the claims appended hereto. Further, in the methods disclosed herein, various steps are disclosed illustrating some of the functions of the invention. One will appreciate that these steps are merely exemplary and are not meant to be limiting in any way. Other steps and functions may be contemplated without departing from this disclosure or the scope of the invention.