Automated records management with enforcement of a mandatory minimum retention record

Abstract

A records management system and method includes a file plan that has one or more segments associated with compliance data. Data stored in these segments of the file plan have a mandatory minimum retention period during which they cannot be modified or deleted. Additionally, the information about the mandatory minimum retention period may not be altered or removed.

Description

RELATED APPLICATIONS

The present Application claims priority to and is a Continuation-in-Part of application Ser. No. 10/834,100 (Attorney Docket No. 69341-011) entitled ENTERPRISE CONTENT MANAGEMENT NETWORK-ATTACHED SYSTEM, the contents of which are incorporated herein, by reference, in their entirety.

BACKGROUND

1. Field

The present disclosure relates generally to records management and, more particularly, to automated records management in compliance with external rules.

2. Related Art

Records management has become increasingly essential to the success and future of a business. Technological advances have given rise to greater reliance on electronic information in dispersed data systems. The amount of information to be gathered has also increased. For example, the Internet and its e-mail and web-based content gathering capabilities have aided the proliferation of data such as never before seen. The increasing amount of hard copy information has aided this proliferation as well.

Along with technological advances and the widespread propagation of data, a new age of corporate governance has also resulted in a greater emphasis on records management. Emphasis on issues such as corporate governance have led to large-scale corporate liability and corporate failures. Greater focus is being given to corporations and their executives, as well as corporate compliance with new laws enacted as a part of this new age of corporate governance

Corporate non-compliance is a major source of corporate liability, resulting in increased complexity for records management systems. Many compliance policies have been embodied in legislation. The Sarbanes-Oxley Act (SOX), SEC 17a-4 and the Health Insurance Portability and Accountability Act of 1996 (HIPAA) are examples of such legislation. Due to the many regulations such as these, it may be deemed necessary for a corporation to manage and maintain its records in a particular manner. For example, some legislation mandates that content must be stored on certain types of media (e.g., non-rewritable medium); while other legislation prescribes particular auditing and/or content characteristics.

A significant number of companies now maintain formal records management programs, and it is widely agreed that such programs are important to the continued success of a business. However, current records management programs may not address the needs of today's businesses in that they have not been updated in accordance with technological advances. For example, many of today's records management programs do not support or manage electronic records.

Current records management programs may also lack protections that promote the consistent application and enforcement of records management policies. For example, some information technology systems may not be structured to support desired records management policies such as retention periods or retention events. Moreover, records may be incorrectly classified due to differences of opinion among users that manually perform classification operations.

Records management programs may also lack timely retention and disposition policies. Accordingly, where records are inaccessible or destroyed too soon, a business may be unable to produce such records in court to defend a claim, and such records may be costly to recreate if even possible. Where records are kept longer than required, avoidable and costly storage costs may result.

One particular instance in which current records management programs have been deficient relates to ensuring necessary records are maintained for a minimum retention period. For example, the Nuclear Regulatory Commission (NRC) has rules regarding how long certain documents about a power plant must be retained. Similarly, there are currently rules and regulations governing how long certain broker and trader records must be retained by securities trading companies.

In the past, records management software applications and systems have enforced document retention policies in a manner that could be easily circumvented by users or administrators. Thus, even though a document or container may have been defined as having a certain minimum retention period, there was no secure enforcement of that period for all users of the system. In other words, someone with the appropriate privileges would have been allowed to change the disposition schedule for that document or over-ride the disposition in some other manner. Such a system does not properly ensure compliance with retention policies or rules.

There have been hardware-based storage solutions developed that attempt to impose mandatory retention policies. Such storage solutions typically include a network attached storage system having a user interface that an administrator can use to create and define a storage hierarchy within the system. As part of the definition process, certain parts of the storage hierarchy are assigned fixed retention periods. For example, a directory may be created such that any file eventually stored in that directory would be retained for five years. Such a system will usually include some type of firewall between the network interface and the physical storage devices. The firewall is configured to only allow file manipulation commands that do not violate the retention definitions.

While the hardware-based storage solution described above enforces more data security than the records management software solution, it has its own deficiencies as well. The differences can be summarized by recognizing that a storage solution is not as robust and varied as a records management software application. For example, many compliance strategies and rules require event-based compliance such as “5 years after case closed”, “2 years after invoice paid”, 1“year after audit performed”, etc. Even these simple event-based retention policies cannot be defined within current storage management solutions. Other, more complex, retention policies cannot be handled either by current hardware-based storage system solutions. By “event-based”, it is meant that some event, possibly variable in nature, occurs sometime in the future that starts the running of the retention period.

Accordingly, there remains a need for a records management system that has the flexibility and capabilities of current records management applications but that also securely enforces minimum retention periods for appropriate records and documents.

SUMMARY

One aspect of the present invention relates to a records management system that includes a network attached data storage system coupled to a network for receiving commands from one or more records management software applications. This network attached storage system, itself includes a content repository and a firewall. For example, one particular content repository may be a FileNet content engine. The content repository, or content engine, is configured to access a stored data item having assigned thereto a mandatory minimum retention period. Furthermore, the content engine is further configured to prevent alteration of the stored data item during the mandatory minimum retention period. This system also includes one or more storage devices configured to store the stored data item and information about the mandatory minimum retention period.

Another aspect of the present invention relates to a computer-based method for records management. In accordance with this method, an event-based minimum retention period for a stored data item is assigned to that item and an indication is made whether the event-based minimum retention period is unalterable. If unalterable then this method prevents alteration of the stored data item during the event-based minimum retention period by a user irrespective of data access privileges granted the user.

Yet another aspect of the present invention relates to a records management system that includes a content repository configured to access a stored data item having assigned thereto a mandatory minimum retention period. This content repository is further configured to prevent alteration of the stored data item during the mandatory minimum retention period.

It is understood that other embodiments of the present disclosure will become readily apparent to those skilled in the art from the following detailed description, wherein it is shown and described only exemplary embodiments of the disclosure by way of illustration.

BRIEF DESCRIPTION OF DRAWINGS

Aspects of the present disclosure are illustrated by way of example, and not by way of limitation, in the accompanying drawings wherein:

FIG. 1 illustrates an exemplary architecture for a computer-based content management system.

FIG. 2 illustrates a data model that can be used for a file plan in accordance with one embodiment of the present disclosure.

FIG. 3A illustrates a block diagram of a content management system that implements mandatory minimum retention policies.

FIG. 3B depicts an exemplary algorithm for creating disposition schedules having mandatory minimum retention periods.

FIG. 4 illustrates an exemplary database record representing a disposition schedule having the capability of incorporating mandatory minimum retention periods.

FIG. 5 illustrates a block diagram of another content management system that implements mandatory minimum retention policies.

DETAILED DESCRIPTION OF THE PRESENT DISCLOSURE

The present disclosure provides systems, methods and computer programs for automated records management that enforces a mandatory minimum retention period for certain documents and records. A currently pending Application of the same Assignee of the current Application is application Ser. No. 10/964,694 (Attorney Docket No. 69341-016) entitled AUTOMATED RECORDS MANAGEMENT BASED ON BUSINESS PROCESS MANAGEMENT, the disclosure of which is incorporated herein, by reference, in its entirety. In that Application, a computer system and software application are described that provide records management capability within an overall content management system. A detailed description of all aspects of a records management system, that can be found in the incorporated application, is avoided in the present application so as not to obscure the aspects of the present invention. However, some redundancy of disclosure is necessary to provide a descriptive context for describing the present invention.

Application Architecture for a Content Management System

Reviewing the general architecture for a Content Management System and referring now to FIG. 1, illustrated is a block diagram 100 representation of an architecture of a content management system, including an application tier 110, a business services tier 115, and a data tier 120. A single architecture may be provided thereby for content management 125, records management 135, web content management 140, collaboration 130 and digital asset management 155 at the application tier, while a content engine 145 and a process engine 150 are used to manage the content and process, respectively for all the separate functions indicated as content management 125, records management 135, web content management 140, collaboration 130 and digital asset management 155. One of ordinary skill will recognize that this architecture is exemplary in nature and its logical functions may be re-arranged without departing from the scope of the present invention.

Using this architecture, system events can trigger actions in any part of the system. When content is added to the system, for example, that event may trigger publishing the content to the web, declaring it as a record, or other actions

The records management system 135, the process management engine system 150 and the data tier 120 shown in FIG. 1 may be configured to monitor the value(s) of one or more events or actions associated with one or more of the data objects associated with records or the file plan. In response to this monitoring and based on one or more pre-defined rules and/or conditions, the records management system 135 may be configured to automatically initiate one or more processes in the process engine system 150. For example, after user declaration of an asset as a record, the system may automatically classify one or more of the records or store information associated with one or more of these records in the records management system. One or more of these processes may in addition or instead apply one or more pre-defined retention periods or disposition rules to one or more of the records.

Alternatively, one or more of the various management systems may be separate, stand-alone systems that have been brought together and integrated merely for the purpose of creating the records management system. The records management application may be accessed by a user, whether a regular end user, records administrator, records manager or reviewer (privileged user) over an Application Programming Interface (API) that indicates the pertinent records management operation that the user can perform. These operations may include a declaration API, a record management API, a disposition API and a file plan management API. The API may be implemented through any of a variety of high-level languages (e.g., Java) and may incorporate XML technology for ease of use, as well as ease of import and export of information in the records management system.

The records management system described herein may be used to declare, classify and manage records of different types, secure repositories that contain records, create retention and disposition rules for records, control access to records, retrieve records based on search criteria, destroy records that are no longer used, review vital records, and add records with minimal user intervention.

The architecture of FIG. 1 may be implemented on a variety of programmable computer platforms. Such a computer processing system or platform may include a single computer or multiple computers and/or processors. When using multiple computers and/or processors, the multiple computers and/or processors may be at a single location or at several locations. When using multiple computers and/or processors, the multiple computers and/or processors may be interconnected by a network system, such as a local area network, a wide area network, and/or the Internet. Within such computer platforms are typically memory systems that may include any type of memory system, including one or more hard disk drives, magnetic tape drives and/or RAMs. The memory system may consist of a single device or multiple devices. When multiple devices are used, they may all be located in close proximity to each other, or at different locations. When multiple devices are used, appropriate hardware and/or software may be used to facilitate their intercommunication.

The large variety of different configurations and variations of the content engine, process engine, applications layer, records manager, and data storage systems are described in more detail in the previously mentioned Applications incorporated by reference and may be used within the context of the present invention as well.

File Plans and Disposition Schedules

The records management systems, methods and computer readable media of the present disclosure are designed to manage records of various types, including but not limited to, electronic documents and e-mails, physical records or artifacts, vital records and permanent records. A record can be any asset that an organization desires to maintain and manage in a reliable manner.

Record declaration may be performed when a potential record is added to the system. In the case of electronic content, declaration may occur when a document is created or published, or upon the creation of a new document version, or when an e-mail is transmitted. For electronic documents as well as other types of records, the records may be automatically declared. In the case of a physical artifact, declaration may occur, for example, when the physical artifact is received by a company. Records may also be generated in a variety of other uses and applications, e.g., part of a transaction, or during the course of a process. Process-centric records may be created as part of a company's line of business.

Advantageously, the records are organized according to some hierarchy often referred to as a file plan that contains an organized arrangement of data containers used to store documents and records. Typically, a disposition schedule is associated with the different data containers that defines the retention policy related to records stored in that particular data container. A single person, such as a records administrator, may be charged with responsibilities for designing a classification scheme, defining a new file plan, configuring naming patterns and phases, as well as defining and modifying disposition schedules. Major categories of the file plan may be category hierarchy and disposition schedules.

Referring now to FIG. 2, illustrated is one embodiment of a data model 200 that can be used for a file plan in accordance with the present disclosure. In this illustration, the file plan is used to manage records across object stores and repositories. As illustrated, the file plan uses a file plan object store 210 which manages classification schemes, retention schedules and record folders. The file plan object store 210 contains pointers to records stored in other systems or in physical locations. This file plan object store also incorporates a category hierarchy which may be the primary classification for records, and may include categories, as well as various types of folders and corresponding volumes. More particularly, the file plan may incorporate a classification scheme, record category, record folder, record part or record type that can be used to manage the record.

The category hierarchy may also include a tree structure defining how records are organized, and the category hierarchy may also propagate security and support disposition schedules. The category hierarchy may include a flexible hierarchical structure that is designed to fit the unique needs of an organization. The category hierarchy may determine the scheme for classifying records so that the records may be automatically classified by a records management system, without user intervention.

The category hierarchy may be determined by business function. For example, a category hierarchy may be organized according to a function/activity/transaction model wherein the first level determines functional groupings, the second level determines activities within the function, and the lowest level represents a transaction. The hierarchy may also be designed to facilitate access. In this manner, security may be more easily controlled, user access in terms of browsing may provide better performance and the hierarchy may facilitate aggregation for purposes of disposition.

Alternatively to file plan design based on business function, a file plan may be designed so that each folder in the category is a client file that contains that particular client's records, and once the client folder is closed, cutoff may be triggered so that active use of the record ends and it begins its retention period.

As yet another alternative to file plan design based on business function, a file plan may be designed so that different types of records are filed into different folders. As yet another alternative, the file plan may be designed so that each sub-category represents a project, and each project may have a collection of folders to manage different records related to the project. An external event related to a project milestone may be used to trigger cutoff so that active use of the record ends and the retention period begins.

The record category may be added to the root of the file plan. The record category may also be added to an existing category to establish a hierarchy. The required properties of a category may be the category name which may be descriptive of the category, the category identifier which may be a more cryptic string identifier often containing a numeric code, and a reviewer which may default to the user who is adding the category.

A record folder may be added to a category. Conceptually, the record folder may be the most common level for managing records. The required properties for a folder may include the folder class such as a content engine object class defining the type of folder. The folder class may be defined by the data model. The folder properties may also include a name, identifier and reviewer much like the record category.

Generally, a record folder may not contain sub-folders, but may contain volumes. The first volume may be automatically added when the record folder is created, and a name may be automatically generated based on the folder name. When a new volume is added, the previous volume may be automatically closed. Volumes may be used to partition groups of records, whether similar or not. For example, a record folder may contain all invoices while volumes may be used to partition by month. A volume may be required to include a reviewer, which may default to the user requesting the volume.

As shown in FIG. 2, the data objects and physical repositories 220, 230, 240, 250, 260 may be configured in conformance with the classic model of a software object that has been developed in object-oriented programming to include one or more attributes and one or more methods.

A broad variety of characteristics may be assigned as attributes to the file plan object 210, object stores, or logical repositories, 220, 230 and other objects. For example, these objects may incorporate attributes that are related to the records that are embodied in the software object such as a name for the record, a description of the record, the type of record, an identification of the holders of the record. Audit information may also be contained as an attribute relating to the record such as who accesses an object, when it is modified, who authorizes the modification, who generates documentation related to the object or repository, and when these events take place. Electronic signatures that may have been procured in connection with an object store such as object stores 210, 220, 230 may be contained as an attribute. Notifications that should be issued upon a change in an aspect of a data object, security information relating to a data object, status information that is associated with the record (such as lost item), relevant dates (e.g., creation date, expiry date, and/or key timelines, including multiple, periodic or cyclical information), and relationships between the record software object and other components may be contained as attributes.

Although each of these characteristics may be illustrated as an attribute of the object, each of these may also or instead be stored as separate components or objects in the record management system.

The data model 200 includes pointers from the file plan object store 210 to records stored in other systems or locations. One such pointer is to object stores related to documents 220, 230 which are the main record types and thus use more space. The data model also includes pointers to an imaging system 240, a cabinet repository for physical documents 250 that may be located in cabinets, as well as a box repository for physical documents 260 that may be located in boxes. This design provides for a file plan that incorporates an intuitive scheme that can be readily used by the records administrator to generate a file plan. Based on this user-friendly structure, a records administrator may customize the file plan to fit the company's needs.

Methods may be related to the records, including methods that include or relate to retention and disposition rules, timed events, notifications, reports and trends and forecasts. Each of these methods may constitute software subroutines that initiate, alter or interrupt one or more processes. As with the attributes, the methods may be stored separately from the file plan object store or data object in another object or component.

A disposition schedule may be assigned to a category or folder in the file plan. Where disposition schedules have already been configured, they may be added while adding a new container. If the hierarchy is also constructed, the disposition schedule may be added to the appropriate level after hierarchy construction. A disposition schedule may be automatically inherited by lower level entities. A disposition may also be designed to be overridden.

A disposition schedule may be associated with a record category or folder or other element of a file plan. The disposition schedule may include several elements. For example, a disposition schedule may include an event trigger that triggers cutoff. Cutoff may be the beginning of the retention period which signals the end of active use. Upon a cutoff action, a workflow may be automatically launched for approval of the cutoff. An event offset may optionally be provided as part of a disposition schedule, and may delay time between an event trigger and a cutoff. Disposition phases may be defined to control the retention of records, and each phase of disposition may have an action associated with a workflow.

The event triggers used in a file plan may be internal events, such as those related to the property of a particular category, folder, volume or record. The event trigger may also be an external event that represents an action that occurs outside the system. For example, in a doctor's office, a patient may decide to terminate his relationship and see another doctor. Such a decision may trigger a cutoff so that the patient records begin their disposition phase. A recurring event may include a start date and frequency. A recurring event may be a date for review of vital records. The event may also be a predefined date. For example, all records for a certain calendar year may be cutoff at the end of a particular year.

Disposition phases may be defined within the file plan such that they include actions. Each action may have a type and an associated workflow that is launched to carry out the action. In this manner, workflows may be configured for use in a disposition schedule. Workflows may also be duplicated and modified to implement multiple actions of the same type. For example, if a business commonly transfers records on an interim basis to a particular locale, the disposition schedule may include actions related to that transfer. Disposition phase action types may include review actions, export actions, interim transfer actions, transfer actions and destroy actions. A review action may indicate that a record should be reviewed to determine if its disposition should be changed. An export action may be used to copy records to an external system without removing them. A transfer action may be used to export records to an external system so that they may be removed afterwards. A destroy action may be used to remove records so they cannot be recovered. There may be an option used to retain metadata.

A disposition schedule may be pre-configured to trigger events and phase actions. In adding a new disposition schedule, a user may be required to provide a name for a schedule, select a trigger for the schedule, define a disposition event offset, select cutoff action (option) and set disposition phases. One or more disposition phases may be added to a disposition schedule in a file plan. Phases should be in logical order. For example, a disposition schedule should be defined so that nothing follows a destruction or transfer phase. A retention period should be included for each phase. For example, a record may be reviewed one year after its cutoff, and destroyed five years after its cutoff.

A disposition schedule may be inherited by folders in a category or the folders may have their own disposition schedules, whether according to record types or otherwise.

The block diagram of FIG. 3A illustrates an alternative block-level view of the three-tier logical architecture of FIG. 1. In FIG. 3A, a number of similar components are depicted but additional aspects of those components are explicitly depicted to aid in the discussion of the present system.

A number of applications 302 are provided that a user can use to add and retrieve content from the data storage components 314, 316, 318. One application is a records manager 304 that presents to the user a user interface 306 (typically through a web browser or some other client application). Using this interface 306, a user may manipulate data that is stored in the system and control the disposition of the data.

The system of FIG. 3A includes a content repository, or content engine, 310 and a process engine 312. The process engine 312 is an optional component in the system depicted in FIG. 3A and may be omitted in particular embodiments of the present invention. These two components are described in detail in the incorporated parent application of the present application. In general, these two components control the way the data is added to, retrieved from, and managed within the content system. The content engine 310 may be implemented as a software application that includes an applications program interface (API) 308. Through this API, the records manager 304 can call different objects or procedures within the content engine 310 to affect how data is manipulated within the content system.

The content system may include a number of storage sub-systems such as a database server 314, a file store 316, or a separate hardware storage solution 318. As recognized by one of ordinary skill, the data within the content management system of FIG. 3A may be distributed among these sub-systems 314, 316, 318 in a variety of different ways. The term database server 314 is used generally to refer to both the server itself as well as the tables maintained by the server.

For example, each object stored within the content management system may have the data itself stored at a specified location within the file store 316 while all the meta-data associated with the stored object is stored within the database server 314. In such an arrangement, the database server 314 includes a table having one or more records associated with a stored object. In operation, the content engine 310 and process engine 312 utilize that meta-data when manipulating the stored data object. Alternatively, the database server 314 and the file store 316 can be a part of a single storage system or as shown be distributed among one or more storage devices.

Another alternative is the inclusion of a hardware storage solution 318. As described previously, such a solution 318 typically includes a firewall and physical storage devices. Using an interface at the front-end of the firewall, the content engine can direct the hardware storage solution 318 to add, modify, or delete objects. In such a configuration, the file store 316 would likely not be necessary but the database server 314 would continue to serve its same function as described above. Also, if the hardware solution 318 had its own storage retention policies, these could be disabled or unused because the content engine would enforce the disposition schedules without aid of such hardware techniques.

Within the system of FIG. 3A, a user uses the user interface 306 to create a disposition schedule that eventually becomes meta-data associated with a data object stored on the file store 316. The disposition schedule is stored as a table entry in the database server 314. Because a storage object may be logically stored in different locations and be associated with different constraints, a storage object may have more than one associated disposition schedule.

FIG. 3B depicts a flowchart of an exemplary algorithm for creating a disposition schedule having a mandatory minimum retention period. Unlike creation of the disposition schedule that is described in the earlier incorporated patent application, the user interface 306 includes options that allow a user to indicate that a) the data container associated with this disposition schedule has a minimum retention period and b) that this minimum retention period is mandatory or unalterable. During definition of a data container, in step 352, the user interface 306 provides an option for the user to indicate, in step 354, that the disposition schedule involves a minimum retention period. This indication may be as complex as the wide variety of ways that data can be inter-related. For example, the definition of the minimum retention period will advantageously include a time period (e.g., 3 months, 5 years, etc.) and a trigger event (e.g., creation of the document, closing of the file, payment of the invoice, completing of a transaction, etc.).

Next, the user interface 306 provides a opportunity for the user to indicate, in step 356, that the minimum retention period is mandatory or unalterable. The specific characteristics of a particular minimum retention period may be a good business decision or be a general corporate policy and still not be mandatory. However, when systems want to be in compliance with external rules and regulations that require enforcement of certain retention policies, this flag provides a way to show that the minimum retention period is enforced and cannot be changed or removed. It is always possible to lengthen a mandatory minimum retention period by defining a second disposition schedule that includes a length longer than the first. In determining whether or not to delete or modify a stored data object, the content engine will ensure that all disposition schedules are satisfied before allowing such a command to proceed.

In this way, a storage object managed by the content management system will be unable to be deleted or modified before its associated mandatory minimum retention period expires. This prevention of deletion or modification is enforced regardless of the level of privilege of a user and independent of other events that may be defined to automatically delete or modify a storage object.

FIG. 4 depicts an exemplary row 400 of a database table that may be maintained by the database server 314. This row represents the meta-data about a stored data object that involves a disposition schedule. For example, a field 402 may be used to indicate that this row represents a disposition schedule rather than, for example, a document's author. The field 404 identifies the stored data object associated with this meta-data. A flag 406, or bit, may be included to indicate that a minimum retention period is involved and whether it is mandatory or not. Also, the details of the retention period are stored in the field 408. In operation, the content engine 310 and process engine 312 can access this row 400 to determine what operations are or are not to be performed with respect to a stored data object.

To accomplish the enforcement of the minimum retention period, three different levels of security are provided. First, the user interface 306 and the records manager 304 are designed to recognize that a disposition schedule includes a mandatory minimum retention period. Thus, when the records manager 304 is used to access any of the meta-data of a previously defined data container, the meta-data related to the mandatory minimum retention period is unable to be changed. This functionality is similar to many graphical user interfaces that present selections as “grayed-out” to indicate that that selection cannot be changed or modified. Similarly, the records manager 304 will not provide a drop-down menu or other selection method that includes an option to delete or modify a record that is still within its mandatory minimum retention period.

However, the records manager 304 is merely one way to make calls to functions and objects within the API 308. Thus, the API 308 may also include techniques that prevent modifying data that must remain in compliance with some externally applied rules. As one of ordinary skill will recognize, the existing APIs of the content manager 310 may be modified to include condition checking related to mandatory retention periods. If a prohibited command is attempted then the API returns an error instead of performing the command.

Even with the security provided by proper design of the user interface 306 and the API 308, the database table at the database server 314 is still vulnerable. For example, someone with enough skill could locate the row 400 depicted in FIG. 4 and modify a retention policy by modifying the field 408.

Thus, in the system of FIG. 4, the data in the “Details” field 408 is encrypted or digitally signed. Encrypting or digitally signing the data will remove the vulnerability of direct database modification without having access to a private secret or key. One of ordinary skill will recognize that there are many different ways to encrypt this information without departing from the scope of the present invention. There are additional methods such as creating a checksum or hash of the data that will increase the complexity of database modification. The additional methods do not remove the database vulnerability but significantly lessen the risk of the vulnerability.

One exemplary method would use a seed that is stored in the database server 314 and an encryption engine 311 in the content engine. The encryption engine would use the seed to generate an encryption/decryption key. Thus, even if someone knew where the seed was located, that would not provide the key needed to decrypt the data.

In operation, the content engine would save the disposition schedule as shown by the row 400 in FIG. 4. If the mandatory flag 406 is set, then the content engine knows to encrypt the information in the field 408 when generating that row of the database table. The reverse is true as well. When a stored data object is accessed in such a way that its associated disposition schedule 400 is retrieved as well, then the data in the field 408 must be decrypted. This also holds true for operations in which just the meta-data of the disposition schedule is retrieved that does not actually involve retrieval of the associated data object.

One alternative to the seed being stored in the database server 314 is to include the seed as a dongle or some other type of device connected to the computer platform running the content engine 310. The encryption/decryption algorithm 311 will use this seed when generating the key for encrypting and decrypting data.

These three levels of protection (the UI 306, the API 308, and the encryption 311) all work together to ensure compliance with external rules and regulations that mandate minimum retention periods for certain managed objects. One of ordinary skill will recognize that all three of the techniques do not necessarily have to be used but that omitting one or two will reduce the level of assurance that a minimum retention period cannot be modified or overridden.

The encryption techniques described above are useful because the database server may be accessed via a network connection or via a console. If the security of the database server 314 can be maintained, then the encryption step may be omitted.

In the parent patent application that is incorporated by reference, an enterprise content management system is described that incorporates the content engine within a network attached storage device. The hardware and software components that comprise such an enterprise content management system are described in great detail in that patent application. However, a high level block diagram of such a system 502 is depicted in FIG. 5.

In this system, the network attached system 502 includes a firewall 504 that only allows predetermined commands to pass through. Accordingly, access to the data storage 508 is much more limited than in the system of FIG. 3A. The firewall 504 may be more than merely a typical hardware firewall device and, instead, be a logical construct of software and hardware that limits any user or administrator from changing content located behind the firewall.

In particular, the firewall 504 would be configured to pass through only certain API calls to the content engine 506. Then the content engine would operate in a similar manner as that previously described. In particular, if the data storage 508 included a database 314 and the file system 316, then the content engine would interact with these sub-systems in the manner previously described. However, because of the added security for the database 314, there would be no need to encrypt and decrypt the disposition schedules as previously described.

The previous description of the disclosed embodiments is provided to enable one skilled in the art to make or use the present disclosure. Various modifications to these embodiments will be readily apparent to those skilled in the art. The principles set forth herein may be applied to other embodiments without departing from the spirit or scope of the disclosure. Thus, the present disclosure is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A computer-based method for content management comprising the steps of:

assigning an event-based minimum retention period for a stored data item;

indicating whether the event-based minimum retention period is mandatory; and

preventing alteration of the stored data item during the event-based minimum retention period, if mandatory, by a user irrespective of data access privileges granted the user.

2. The method of claim 1, further comprising the step of:

preventing alteration of the event-based minimum retention period by the user irrespective of data access privileges granted the user.

3. The method of claim 2, wherein alteration of the event-based minimum retention period includes shortening the event-based minimum retention period.

4. The method of claim 2, wherein alteration of the event-based minimum retention period includes lengthening the event-based minimum retention period.

5. The method of claim 2, wherein lengthening of the event-based minimum retention period is permitted.

6. The method of claim 2, wherein alteration of the event-based minimum retention period includes deleting the event-based minimum retention period.

7. The method of claim 1, wherein alteration of the stored data item includes deleting the stored data item.

8. The method of claim 1, wherein alteration of the stored data item includes modifying the stored data item.

9. The method of claim 1, wherein the step of assigning includes the steps of:

defining a disposition schedule for a segment of a file plan, the disposition schedule including the event-based minimum retention period; and

identifying the event-based minimum retention period for any stored data items filed into the segment.

10. The method of claim 1, wherein the step of indicating further includes the step of:

receiving input determining whether the event-based minimum retention period is mandatory.

11. The method of claim 1 further comprising the steps of:

indicating that the event-based minimum retention period is non-mandatory; and

allowing alteration of the stored data item during the non-mandatory event-based minimum retention period by the user.

12. The method of claim 11, wherein the step of allowing alteration is dependent on the data access privileges granted to the user.

13. The method of claim 11 further comprising the step of:

allowing alteration of the non-mandatory event-based minimum retention period by the user.

14. The method of claim 13, wherein the step of allowing alteration of the non-mandatory event-based minimum retention period is dependent on the data access privileges granted to the user.

15. The method of claim 1, wherein the step of preventing further includes the steps of:

presenting, via a user interface, selectable operations to be performed on the stored data item; and

preventing selection of any of the selectable operations that result in alteration of the stored data item.

16. The method of claim 15, wherein the step of preventing selection further includes the step of preventing presentation of any of the selectable operations that result in alteration of the stored data item.

17. The method of claim 2, wherein the step of preventing alteration of the event-based minimum retention period further includes the steps of:

presenting, via a user interface, selectable operations to be performed on the event-based minimum retention period; and

preventing selection of any of the selectable operations that result in alteration of the event-based minimum retention period.

18. The method of claim 17, wherein the step of preventing selection of any of the selectable operations that result in alteration of the event-based minimum retention period further includes the step of:

preventing presentation of any of the selectable operations that result in alteration of the event-based minimum retention period

19. The method of claim 1, wherein the step of preventing alteration further includes the steps of:

providing a plurality of application programming interface (API) calls that manipulate the stored data item; and

preventing completion of an API call that would result in alteration of the stored data item.

20. The method of claim 2, wherein the step of preventing alteration of the event-based minimum retention period further includes the steps of:

providing a plurality of application programming interface (API) calls that manipulate the event-based minimum retention period; and

preventing completion of an API call that would result in alteration of the event-based minimum retention period.

21. The method of claim 2, wherein the step of preventing alteration of the event-based minimum retention period further includes the steps of:

storing the event-based minimum retention period as meta-data associated with the stored data item; and

encrypting at least a portion of the meta-data.

22. The method of claim 21, further comprising the step of:

encrypting at least a portion of the stored data item.

23. The method of claim 21, wherein encrypting comprises digitally signing the at least a portion of the meta-data.

24. The method of claim 2, wherein the step of preventing alteration of the event-based minimum retention period further includes the steps of:

storing the event-based minimum retention period as meta-data in a database table; and

restricting allowable commands that may be received by a system hosting the database table.

25. Computer-readable media containing programming instructions for managing content that upon execution thereof, causes one or more processors to perform the steps of:

assigning an event-based minimum retention period for a stored data item;

indicating whether the event-based minimum retention period is mandatory; and

preventing alteration of the stored data item during the event-based minimum retention period, if mandatory, by a user irrespective of data access privileges granted the user.

26. The computer readable media of claim 25, wherein the instructions are further configured upon execution to perform the additional step of:

preventing alteration of the event-based minimum retention period by the user irrespective of data access privileges granted the user.

27. The computer readable media of claim 25, wherein the instructions are further configured upon execution to perform the additional step of:

indicating that the event-based minimum retention period is non-mandatory; and

allowing alteration of the stored data item during the non-mandatory event-based minimum retention period by the user based on the data access privileges granted to the user.

28. The computer readable media of claim 25 wherein the instructions are further configured upon execution to perform the additional step of:

allowing alteration of the non-mandatory event-based minimum retention period by the user based on the data access privileges granted to the user.

29. The computer readable media of claim 25, wherein the instructions are further configured upon execution to perform the additional step of:

presenting, via a user interface, selectable operations to be performed on the stored data item; and

preventing selection of any of the selectable operations that result in alteration of the stored data item.

30. The computer readable media of claim 26, wherein the instructions are further configured upon execution to perform the additional step of:

presenting, via a user interface, selectable operations to be performed on the event-based minimum retention period; and

preventing selection of any of the selectable operations that result in alteration of the event-based minimum retention period.

31. The computer readable media of claim 25, wherein the instructions are further configured upon execution to perform the additional step of:

providing a plurality of application programming interface (API) calls that manipulate the stored data item; and

preventing completion of an API call that would result in alteration of the stored data item.

32. The computer readable media of claim 26, wherein the instructions are further configured upon execution to perform the additional step of:

providing a plurality of application programming interface (API) calls that manipulate the event-based minimum retention period; and

preventing completion of an API call that would result in alteration of the event-based minimum retention period.

33. The computer readable media of claim 26, wherein the instructions are further configured upon execution to perform the additional step of:

storing the event-based minimum retention period as meta-data associated with the stored data item; and

encrypting at least a portion of the meta-data.

34. A content management system comprising:

a software-based content repository configured to access a stored data item having assigned thereto a mandatory minimum retention period;

the software-based content repository further configured to prevent alteration of the stored data item, during the mandatory minimum retention period, by a user irrespective of data access privileges granted the user.

35. The system of claim 34 further comprising:

a data storage system configured to store the stored data item and information about the mandatory minimum retention period.

36. The system of claim 35, wherein the content repository is further configured to prevent alteration of the information about the mandatory minimum retention period by the user irrespective of data access privileges granted the user.

37. The system of claim 34, further comprising:

a records manager software application configured to receive input from a user regarding the mandatory minimum retention period for the stored data item and provide the input to the software based content repository.

38. The system of claim 37, wherein the records manager software application includes a user interface that prevents selection of operations that would result in alteration of the stored data item.

39. The system of claim 37, wherein the records manager software application includes a user interface that prevents selection of operations that would result in alteration of the mandatory minimum retention period.

40. The system of claim 34, wherein the content repository includes a plurality of API calls for accessing the stored data items and is configured to prevent operation of an API call that would result in alteration of the stored data item.

41. The system of claim 34, wherein the content repository includes a plurality of API calls for accessing the mandatory minimum retention period and is configured to prevent operation of an API call that would result in alteration of the mandatory minimum retention period.

42. The system of claim 35 wherein the content repository is configured to encrypt the information when storing the information to the data storage system and decrypting the information when retrieving the information from the data storage system.

43. A records management system comprising:

a network attached data storage system coupled to a network for receiving commands from one or more records management software applications, further comprising: a content repository configured to access a stored data item having assigned thereto a mandatory minimum retention period; a firewall located between the records management software applications and the content repository, and configured to restrict traffic reaching the content repository to an allowable set of commands; the content repository further configured to prevent alteration of the stored data item during the mandatory minimum retention period; and one or more storage devices configured to store the stored data item and information about the mandatory minimum retention period.