U.S. patent application number 11/363946 was filed with the patent office on 2006-07-06 for automated records management with enforcement of a mandatory minimum retention record.
This patent application is currently assigned to FileNet Corporation. Invention is credited to Albert C. Brown, Tod DeBie.
Application Number | 20060149735 11/363946 |
Document ID | / |
Family ID | 35188302 |
Filed Date | 2006-07-06 |
United States Patent
Application |
20060149735 |
Kind Code |
A1 |
DeBie; Tod ; et al. |
July 6, 2006 |
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.
Inventors: |
DeBie; Tod; (Costa Mesa,
CA) ; Brown; Albert C.; (Huntington Beach,
CA) |
Correspondence
Address: |
MCDERMOTT WILL & EMERY LLP
18191 VON KARMAN AVE.
SUITE 500
IRVINE
CA
92612-7108
US
|
Assignee: |
FileNet Corporation
|
Family ID: |
35188302 |
Appl. No.: |
11/363946 |
Filed: |
March 1, 2006 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
10834100 |
Apr 29, 2004 |
|
|
|
11363946 |
Mar 1, 2006 |
|
|
|
Current U.S.
Class: |
1/1 ;
707/999.008; 714/E11.12; 714/E11.125 |
Current CPC
Class: |
G06F 16/289 20190101;
Y10S 707/99933 20130101; Y10S 707/959 20130101; G06F 11/1474
20130101; G06F 11/1456 20130101; Y10S 707/99953 20130101; G06F
11/1464 20130101 |
Class at
Publication: |
707/008 |
International
Class: |
G06F 17/30 20060101
G06F017/30 |
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.
Description
RELATED APPLICATIONS
[0001] 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
[0002] 1. Field
[0003] The present disclosure relates generally to records
management and, more particularly, to automated records management
in compliance with external rules.
[0004] 2. Related Art
[0005] 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.
[0006] 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
[0007] 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.
[0008] 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.
[0009] 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.
[0010] 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.
[0011] 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.
[0012] 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.
[0013] 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.
[0014] 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.
[0015] 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
[0016] 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.
[0017] 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.
[0018] 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.
[0019] 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
[0020] Aspects of the present disclosure are illustrated by way of
example, and not by way of limitation, in the accompanying drawings
wherein:
[0021] FIG. 1 illustrates an exemplary architecture for a
computer-based content management system.
[0022] FIG. 2 illustrates a data model that can be used for a file
plan in accordance with one embodiment of the present
disclosure.
[0023] FIG. 3A illustrates a block diagram of a content management
system that implements mandatory minimum retention policies.
[0024] FIG. 3B depicts an exemplary algorithm for creating
disposition schedules having mandatory minimum retention
periods.
[0025] FIG. 4 illustrates an exemplary database record representing
a disposition schedule having the capability of incorporating
mandatory minimum retention periods.
[0026] FIG. 5 illustrates a block diagram of another content
management system that implements mandatory minimum retention
policies.
DETAILED DESCRIPTION OF THE PRESENT DISCLOSURE
[0027] 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
[0028] 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.
[0029] 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
[0030] 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.
[0031] 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.
[0032] 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.
[0033] 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.
[0034] 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
[0035] 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.
[0036] 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.
[0037] 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.
[0038] 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.
[0039] 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.
[0040] 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.
[0041] 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.
[0042] 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.
[0043] 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.
[0044] 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.
[0045] 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.
[0046] 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.
[0047] 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.
[0048] 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.
[0049] 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.
[0050] 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.
[0051] 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.
[0052] 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.
[0053] 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.
[0054] 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.
[0055] 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.
[0056] 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.
[0057] 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.
[0058] 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.
[0059] 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.
[0060] 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.
[0061] 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.
[0062] 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.
[0063] 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.
[0064] 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.).
[0065] 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.
[0066] 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.
[0067] 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.
[0068] 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.
[0069] 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.
[0070] 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.
[0071] 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.
[0072] 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.
[0073] 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.
[0074] 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.
[0075] 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.
[0076] 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.
[0077] 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.
[0078] 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.
[0079] 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.
[0080] 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.
* * * * *