Note: Descriptions are shown in the official language in which they were submitted.
215~g2~
CO~Y~ ;~ BASED RECORDS MANAGEMENT
~Y~l~;M AND METHOD
FIELD OF THE INVENTION
The present invention relates to records management. In particular, the
invention concerns computer based systems and methods for, inter alia, capturing,
ret~ining, retrieving, tracking and/or disposing of documents within a business
org~ni7~ion.
BACKGROllND OF THE INVENTION
Br~sines~ Problem - Records Management
Most organi7ations have a need to create and retain records which
document their business transactions and related processes. Eventually, after legal,
regulatory and other requirements have been met, many of these records can be
destroyed. In those org~ni7~tions having a form~li7ed program of records
retention and destruction, documents are most often stored as paper in filing
cabinets on-site and may also be microfilmed or microfiched. The film or fiche
is typically retained on-site with an archival copy stored in an off-site archival
location. Paper records of completed transactions are often boxed and sent off-site
to be warehoused in an archival facility.
As required in the course of business, warehoused boxes are recalled from
the archival facility as access to the paper originals is required for litigation or
other reasons. Management of these film and paper records is generally h~n~11ed
through a stand-alone manual or co~ er system, developed for the purpose,
which tracks the location and retention period of these records. Periodically,
retained records are reviewed and destroyed by the organi_ation or archival
21S492~
facility. Destruction dates and frequency is determined by a combination of
external requirements and organi7~tional policy.
Management of computer-generated output from business applications has
been handled in various ways, with a view toward system backup required for
normal system restoration/recovery in the event of a system malfunction or as part
of an organi7~tional disaster recovery program. Records generated from col.,puler
application systems, which are considered to be part of a corporate program of
records retention and destruction, are either saved as hard-copy output or on
magnetic media and sent to an off-site archival facility with a retention period and
destruction (or scratch) date.
Scanned images of documents stored on optical media through computer
application systems are beginning to replace microfilming and/or microfiche in
some org~ni7~tions as an archival method, as is computer output to laser disk
(COLD) technology for computer system-generated output. These systems manage
the archival of documents or colllpuler output from a retention viewpoint only.
Records destruction is still handled through stand-alone systems which track
volume and location information for COLD data. Paper, where not destroyed after
im~ging, is also tracked through a stand-alone mechanism. This duplication of
records may cause confusion. In the event of litigation, for example, issues mayarise as to which source of such records should be the basis for a docum~nt
production. Clearing up this confusion involves expensive use of time and
resources to track and report potentially relevant, duplicated records.
Currently available imaging systems allow for scanning, indexing, filing,
saving and retrieving of images but do not provide an integrated ability to track
file retention and initiate complete file destruction on a regular, schedl-led basis.
Typically, items deleted from such systems are handled on a case basis, with only
datahace pointers (not filed images) being marked for deletion. Images are almost
always written to a single medium, e.g., permanent write once read many
(WORM) optical platters, from which they cannot be purged. Audit logging
capabilities in such systems vary by product, from none to partial logging of
system activity.
-3- 215~92~
Available imaging systems do not provide for the integration of records
management functions which automate the handling of records retention and
destruction. They also do not consider automation of those areas required to assist
with legal admi~ihility of stored records in courts of law. Procedures surrounding
A-lmi~sihility questions are, therefore, left to manual handling, which is time-consuming and subject to error and omission.
Further, the available imaging systems do not track duplicate copies of
stored records which may have been retained on paper or in other form within an
organi7Ation that inadvertently may not have been destroyed when other copies ofthe file were purged.
Br~siness Problem - Disaster Recovery
Current system back-up and record archival processes provide, in an
aggregated fashion, back-up for an orgAni7~tion's records in the event of a
disaster. When an imaging application has been implemented, some or all of an
organi7ation's paper-based records may also be recoverable. However, because
of the disparate nature of the hardware/software platforms which create back-up
records, the lack of coordination between those platforms and the media on whichthe back-up records are archived, full recovery from a disaster could take an
orgAni7Ation weeks or months, depending upon the types and number of records
stored.
Each individual platform must be se~al~tely restored from previously saved
backups and paper files without backup must be re-created, as far as possible,
from externally mAintAine~l records (often from outside the orgAni7Ation).
Synchroni~ation of cross-platform data and records when restored then becomes
(by default) a matter of how close in time each of the individual backups (beingused to restore) was ~~ ,ed.
Obviously, any delays in the time required for a business or agency which
has suffered a disaster (e.g., major destruction from a fire, earthquake or windstorm) to become fully operational again r~resell~ tremendous cost to the
orgAni7Ation. This cost reflects the expenses of coming back on-line, coupled with
the lost business opportunities experienced while the system was not operational.
In addition, each back-up and recovery process undertaken in the normal course
-4 - 215 4~ 25
of business generates additional expense associated with the potential inefficiencies
of non-synchronized back-up and the off-site storage of records.
These inefficiencies may waste time and money even for recovery efforts
less far-reaching than a major disaster (e.g., where a single location goes downand multiple types of records and potentially multiple systems are involved). This
is because whenever an organi7~tion~s record-keeping efforts are not synchronized,
reconstructing to a point in time is difficult and generally also will be costly in
terms of both time and money.
B!~si~ess Problem - Discoverability of
Electronically-M~i~tt~ ed Bl~si~ess Records
Back-ups made for purposes of disaster recovery, which are not currently
tied to any form~li7ed program of records retention and destruction, may exist for
long (even indefinite) periods of time beyond their regularly intended destruction
dates. Such back-ups may be admissihle evidence in the event of litigation. The
proliferation of electronic mail, sent within and without an org~ni7~tion and saved,
as well as the contents of unm~naged personal computer hard-drives can, thus,
present a substantial unrecognized potential exposure to organi7~tions. Typically,
even those or~ni7ations that are meticulous about maintaining reten[ion of paperrecords have not yet dealt with the complex issues of managing electronic records
in the same fashion, due to the unavailability of tools to do so.
Related Art - General
Currently, a few org~ni7ations are looking to systems integrators to assist
with the marriage of off-the-shelf stand-alone records management systems with
archival imaging applications. These application integration efforts, if suc~s~ful,
may solve that portion of the overall business problem which deals with the timely
disposal of archived imaged records. The records management of current
conl~uter generated data, which generally remains a process apart from normal
records management methods and procedures, will not be touched by those efforts,and the synchroni_ation of archived files to provide an enterprise-wide capability
to recover swiftly after a disaster will not be addressed.
In addition, rapid changes in technology are continuing to impact
organi_ations with new ways of communicating (e.g., inter- and intra-
-5- 21S~92~
organi7~ional electronic mail, systems which allow the direct generation and/or
receipt of f~çsimile information, electronic data interchange (EDI) of data, andinteractive voice response systems), all of which are records of information that
should be incorporated into an o~g~ni~alion's records management system, and be
subject to destruction according to an established records retention schedule.
Rec~use they are new, these communication methods remain largely
unm~n~ged and are outside the scope of current records retention and destructionprogra~ms and vehicles. As electronic ~i~n~tllres, widespread use of EDI and inter-
company systems become a general reality, the use of paper as a meAillm to record
the business of an or~ni7~tinn will decrease. Each org~ni7~tional entity must find
new methods and vehicles of archiving, reviewing and ensuring the appl~p~iate
destruction of its records in accordance with policy and externally generated
re~uirements.
Prior Art - The Wye Oak System
An im~ging archival system developed within the past few years, but not
widely used, the Wye Oak system, had three main `functions: Scan, Retrieve and
Systems Atlmini~tration.
The Scan function allowed users to scan images into the system and to
place (or file) the images into predefined case, folder and document categories.The Retrieval function allowed users to access images at their workstations,
annotate the images, add case journal notes and print images to a desi~.n~ted
printer. The System A~mini~tration function allowed for the setting of user
passwords, controlled access to system features and to stored information (images),
and also allowed the System ~Amini~trator to turn on or off a print audit log of all
items printed through the application. Other audit logging was p~rol",ed for theScan function, but not for any other functions within the Wye Oak system.
The Wye Oak system was a Microsoft Windows-based application written
in Visual Basic and C language, and provided users with a graphic user interface(GUI) im~ing system. The Wye Oak system also included the concept of a case
journal. The case journal could be ~tt~rhed to a Wye Oak file by an authorized
user and made either public or private, but the journal could not be deleted from
the system once entered. The Wye Oak system had no built-in features for records
-6- 21S4925
management (file retention and destruction) and could not handle non-imaged files.
The system also did not contemplate use for disaster recovery purposes or for
support in litigation document production.
SUMMARY OF THE INVENTION
In view of the foregoing, it is a principal object of the present invention to
provide a "cradle to grave" system and method for m~n~ging the records of an
org~ni7~tion, whether retained as hard copy paper documents, microform or in
electronic data formats, and whether text, recorded voice or other signals.
It is a further object of the present invention to provide an integration of
im~ging, electronic document management and records management principles.
It is another object of the present invention to provide for specified record
types filtering and verification/certification me~h~nicmc which will allow for
deletion of transient, non-archival type information prior to saving required
records.
It is yet another object of the invention to provide, for records stored and
archived under the system, me~h~nicmc to alter retention information, to purge
records on an individual or global basis at predefined intervals, and to generate
audit records of all system activity, whether system-generated or resulting frommanual intervention, so as to support legal ~tlmiccihility of stored records.
Still another object of the invention is to provide a mech~nicm for cross-
referencing related records across multiple record formats, types and media, andacross different hardware/software platforms, for purposes of record retrieval,
tracking, retention and destruction.
Yet another object of the invention is to provide an organi_ation with a
central audit point for all electronic business conducted within the enterprise, thus
ensuring that all records are captured and a~lulliately processed, and that
external communications (such as acknowledgm~nts) are also processed as
necessary.
A further object of the invention is to provide a system that, in the event
of a disaster, will allow an ol~ni,~lion to restore its records without the delays
caused by uncoûrdinaled efforts at back-up between various hardware and soflwar~prûcessi,lg platforms.
-7- 2154925
These and other objects are achieved with the present invention. In one
aspect, the invention is embodied in a computer based records management system
and method according to the present invention. The computer based records
management system according to the present invention comprises input devices forreceiving record data units that may or may not be retained in the system and
storing the record data units for possible retention. These record units may
comprise sc~nned documents inçlufling or excluding marginalia, old microfilm
records, information cont~ining audio and video media, various computer
generated media such as floppy discs, hard drive stored data and the like or
practically any and all media and data forms that may come to mind that a user
may wish to store.
One especially illlpOl ~t element of the present invention is a unit
verification and certification process whereby a record data unit is carefully
examined for retention in the system in accoldance with preset criteria. Once the
unit is found to meet the preset critPri~, the unit is stored in storage media along
with record unit disposal schedules determined for that unit. Of course, as the
disposal schedule requires, record units are automatically destroyed in accordance
with the present invention. Practically all paper record keeping may be
e~imin~t~d from an enterprise. Moreover, all paper or other records reduced to
digital form are destroyed autom~ti~lly in accor~al-ce with predetermined disposal
schedules. Also, via unit tracking, even paper records stored off-site are idçntifi~d
and any record thereof not immediately purged from the system until the disposalis verified by a records manager.
Another especi~lly illlpOl~t element of the present invention is an
information filtering process which occurs prior to verification/certifi~tion.
During information filt~ring, incomplete or redun-l~nt units are i~entifiçd and such
units, for example, may be acknowledged or forwarded for special h~n-lling or the
like. Information filte ing may serve to route input record data units to dç~ign~ted
destin~tions. Preferably, data units passed on for verific~ti-~n/certifil~ti~n are
tagged to enable tracking of units through the system, for example, for subsequent
al--liting.
-8- 21S492~
According to a method for m~n~ging records in a computer based system,
the method comprises the afore-mentioned steps of receiving record units for
possible retention, filtering the units according to preset criteria, and forwarding
the units for verification/certification or other operations, wherein said forwarded
units are tagged for enabling tracking of units through the system. Once the units
are verified and certified for retention, the units may be retrieved for use by
anyone having access to the system, but, according to predetermined se~ulily
levels, only those users meeting those security levels may manipulate or destroythe retained data units.
These and other objects, features and advantages of the present invention
will be readily apparent and fully understood from the following detailed
description of the prefelled embo~limtont~.
DETAILED DESCRIPrION OF THE DRAWINGS
Figure 1 is a logical schematic overview of a preferred implementation of
the present computer-based system, including its various data sources, functionsand stages.
Figure 2 is a schematic view showing in greater detail various possible data
input sources.
Figure 3 is a logical schematic view illustrating in greater detail a retrieval
function of the present system.
Figure 4 is a logical schematic view illustMting in greater detail the
verification/certification function shown in Figure 1.
Figure S is a logical schem~tic view illustMting in greate~l detail the record
disposal function shown in Figure 1.
Figure 6 is a logical schPm~tic view illustrating a further impl~ment~tinn
of the present invention in an automated records archival facility providing on-line
access (local or remote) to, and retrieval of, archived records (both on-line and
off-line).
Figure 7 is a schem~tic view illustrating the ha~dw~re, software and
network connectivity associated with an implemt~nt~tion of the present system ina large enterprise having numerous branch locations conn~;~ed via a wide area
9- 2154925
network (WAN), with a centralized storage of information at the corporate
headquarters.
Figure 8 illustrates a record filing (indexing) hierarchy in accordance with
the present invention.
DETAILED DESCRIPrION OF THE PREFERRED EMBODIMENIS
The present invention, as depicted in Figure 1, provides an information
location management (ILM) system and process by which an org~ni7~tion may
control the receipt, acknowledgmPnt, validation, org~ni7~tion, destin~tion, storage,
retention and destruction of multi-format m~hine readable (both on-line and off-line) and hard-copy records used by the org~ni7~tion in conducting, documenting
and reporting its activities for internal and/or external purposes.
In accordance with the present invention, unorg~ni7~d (raw) data enters the
process only after it has been assembled by automated or manual means into usable
information with a definable and autom~ti-~lly recogni_able format. Temporary
(transient) information enters the process only for the purpose of ~c~uring that such
information is located on applupfiate media, that unnecessary backups are not
taken and that all copies of such information are destroyed in a timely fashion.Version management is used to control/reduce multiple iterations of electronic data
which may be resident within an org~ni7~tion, across applicable hardware and
software platforms and physical and geographic locations, both for primary use
auld copies maintained for backup purposes. Copies of electronic information
which are maintained (e.g. backup copies maintained on-site or off-site for disaster
recovery purposes) within an organi_ation, either stand-alone or embedded withinother information, are tracked by format and location to ensure simultaneous andtimely destruction of all copies maintained by the org~ni7~tion at the end of the
scheduled retention period(s). Embedded information (e.g. images, spre~ heetc
embedded into larger documents) ~umes the life span of any file into which it has
been embedded. If the retention period for embedded information is longer than
that of a larger file, prior to being embedded in that file, the retention schednlP for
either the file or the embe~ded information is modified.
Except as ne~ç~ry for recovery or other such purpose, multi-resident data
(i.e. data ~ in~in~d in multiple versions or locations) is norm~li7~d to the most
-lo- 215~9~5
recent (i.e. valid) version, maintained in a single location and made accessible to
all applications which require it. Version and location norm~li7~tion occurs across
~t~h~ces for processed information and accounts for the distribution of localized
databases in multiple sites. This ensures the simultaneous update and eventual
simultaneous destruction of all file versions.
The present system and process may be implemented within a single or
multi-org~ni7~tional unit or may include trading partners of the org~ni7~tion where
two-way electronic communication is the prefelled form of business transaction
handling. In the latter case, all partners should agree to abide by similar
information management principles and adhere to specified standards for data
formatting, processing and communication.
Non-electronic records, e.g., hard-copy documents and off-linedata storage
media, are managed by electronically tracking the printing and distribution
information associated with those records, and coor ~in~ting the external control
procedures and information with a centralized ILM d~t~h~ce.
The purpose of ILM is not strictly to provide a "Big Brother" audit
oversight of org~ni7~tional information, but rather to provide numerous other
beneficial functions, one of which is to help ensure that the smallest subset ofvalidated records is m~int~in~ by the or~ni7~tion at any one time. ~ h~ g
a deliberately minimi7~ t~hacP~ of docum~nts and (related or unrelated) coded
information benefits the org~ ion by helping to minimi7~ for org~ni7~tion
members the "noise" of information overload and confusion caused by multiple,
perhaps lic.cimil~r, versions of files. In accordance with the invention, nece~.y
replicated versions of d~t~b~c~s fvr distributed architPctllres, and generations of
files retained for backup or similar purposes, are clearly defined with version and
time stamp information, and all replicated versions are synchrvnized across the
entel~lise.
A minimi7~d d~t~h~e also helps to m~int~in system pelr ~l---ance over the
entire en~ ,lise infrastructure by minimi7ing the size of the index ~l~t~h~oe which
must be searched in response to queries or requests for information. It also
reduces the amount of information which must be sent over the network in
11- 21S~25
response to such requests, thereby speeding access to information throughout theenterprise.
ILM facilitates direct inter-olg~ni ,~ional information access by tracking the
location of required information and se~-ring that information against unauthorized
access. The system also tracks the intended destin~tion of outbound information
(e.g., f~scimil~s, electronic mail, EDI data streams) for audit and troubleshooting
purposes.
In addition, ILM minimi7es the ongoing potential liability associated with
ret~ining information beyond established retention sched~ s by providing an
automated method for ensuring compliance with those retention schedules across
the organi7~tion.
ILM provides a centralized audit point for troubleshooting when system
failures or other problems require back-tracking to determine a chain of events.Also, where a~ropliate backups are taken, ILM can facilitate recovery after a
disaster by providing a single enterprise view of the status and location of allstored information at a point in time imme li~tely before the disaster.
Preferred features of a ILM-compliant system include: (1) open (non-
proprietary) architectural hardware, software, network and communications
components which comply with industry standards for communications protocols
and data formatting; (2) a mech~nism to maintain control over system resources
(e.g. system catalogues) on multiple platforms and in multiple geographic
locations; (3) norm~li7~tion and tracking of stored documPnts, formatted data and
m.osc~ging across d~t~h~es (this requires the creation and/or recognition of a
unique identifying tag, e.g., cont~ining document/file name, creation source anddate, file location, priority and certification data, for each record processed by the
system); (4) the ability to recognize the destination and source of information, to
route in-coming information and to respond in real-time to electronic information
entering the enterprise from external entitie~s; (S) adherence to scheduled ret~ntion
parameters for all stored information across platform ~t~b~es; (6) security against
unauthorized access to and/or modification of stored information, including suchsecurity vehicles as encryption of access and stored information; (7) recognition
of and control over electronically maintained versions and iterations of files and
-12- 2154~2~
-
documents within the enterprise infrastructure; and (8) creation and maintenanceof a centralized audit point for all information created, stored and/or sent outside
of the enterprise.
Referring now to the drawings, Figure 1 is a logical schematic overview
of the present system including various data sources, functions and steps. As
shown in the Figure, information in electronic or other record formats may enterthe system, from multiple sources, including external sources 1 or internal sources
2.
The external in-coming information comprises information which enters the
enterprise from outside sources (e.g., external trading partners, clients, other third
parties, etc.). This information may take many forms, including: (1) formatted
electronic information intended for entry into computerized processing systems,
such as EDI data streams, etc.; (2) formatted electronic information intended for
direct receipt by individuals within the enterprise, such as direct digital input of
computer aided tomography (CAT scans), m~gnetic resonance imaging (MRIs),
etc; (3) unformatted electronic information intended for direct receipt by
individuals within the enterprise, such as electronic mail and fat~simile documPnt~,
text files, etc.; and (4) hard copy (non-electronic) information intended for direct
receipt by individuals within the enterprise, which must be sc~nned (.ligiti7~3)prior to entry into the system, such as paper-based colles~ndence, photographs,
blueprints.
The internal in-coming information enters the system from within the
enter~lise (e.g., internally generated documents, spreadsheets, text files, output
from computer processing systems, etc.). This information may also take many
forms, including: (1) formatted electronic information created by co",puler
application systems and intended for further p~ces~ g and/or backup for recoverypurposes or intended to be sent outside the enterprise (e.g. EDI data streams
intended for trading partners, customers or other third parties); (2) fol,.,alled
electronic information created by individuals or systems within the entel~lise and
intended to be sent outside of the enterprise, such as direct digital input of
computer aided tomography (CAT scans), m~gnetic resonance im~ging (MRIs),
etc; (3) unformatted electronic information created by individuals within the
-13- 215492~
org~ni7~tion and intended for either direct receipt by individuals within the
enterprise or by individuals outside of the enterprise, such as electronic mail and
facsimile documents, text files, etc.; and (4) hard copy (non-electronic)
information intended for direct receipt by other individuals within the ente~lise
or by individuals outside the entcl~lise, which must be sc~nned (-ligiti7~) prior
to entry into the system, such as paper-based collc~lon~ence~ photographs,
blueprints, microfilm or microfiche to be converted to digital form, etc.
Units of information which enter the system from external sources 1 or
internal sources 2 are termed "record data units". Record data units are definedas discrete, physical units of data, whether in single or continuous form, which are
characteri_ed by one or more of: an identifiable beginning and ending; a common
creation date and time; a common source and destin~tion; a single type and format;
and a common use or purpose.
Figure 2 shows in more detail the various possible data input sources. As
shown in Figure 2, external in-coming data record units include (1) in-coming
formatted data lA, e.g., EDI data streams, spre~dsheet files; (2) in-coming
unformatted data lB, e.g., electronic mail messages, f~<similes; (3) sc~nn~l
(~igiti7ed hard copy) input lC, e.g., sc~nned paper records, microfilm or fiche
which has been ~igiti7~d, photographs; (4) voice information iD, e.g., interactive
voice/keypad ordering input, which is converted to digital form; (S) direct digital
input lE, e.g., digital camera input, video or information such as video which has
been converted to digital form; and (6) textual information lF, e.g., word
procescinp files or text files intended for use in text search applications.
Figure 2 shows internal incoming information in the form of (1)
applications systems output 2A, e.g., record data unit files produced by personal
co"~puler, minico",puler or mainframe business applications; (2) sc~nn~d (fligiti7~
hard copy) input 2B, e.g., scanned paper records, microfilm or fiche which has
been ~1igiti7~d, photographs; (3) formatted data record units 2C, e.g., CAT scans,
MRIs, etc.; (4) unformatted data record units 2D, e.g., f~rcimil~, eléctronic mail
messages; (S) direct digital input 2E, e.g., digital camera input, video, which is
converted to digital form; and (6) textual infcl,llation 2F, e.g., word ~ s~ g
files, text files intended for use in text search applications.
-14- 215~92~
Referring again to Figure 1, record data units which enter the system from
external sources 1 or internal sources 2 are either captured directly by the system
or may be received by the system after first being created and org~ni7P~ by an
individual or automated process. In those instances, such records may then be
org~ni7P~ by those processes into the logical file formats in which they will
~lltim~tely be archived and retrieved. (A pler~lled record filing structure is shown
in Figure 8 and described below.)
If incoming records (e.g., direct digital input) are to be retained by the
system, these records are org~ni7~d for archival by the system upon receipt within
the enterprise. In most cases, retention periods and conditions (e.g. upon receipt,
after completion etc.) will be controlled by the org~ni7~tion's established schedule
of records retention and destruction, maintained within the system d~t~h~e.
InformaIion Filler:
Still referring to Figure 1, the system preferably initially processes records
presented for possible retention through an information filter 3. This information
filter acts as a "black box" between the creation and receipt of record data units
within the enterprise and all further processing, backup, receipt and logging of this
information. The filter, thus, handles the prelimin~ry validation, routing,
acknowledgement, priority verification, buffering and similar functions and
provides any neces~ry translation, parameter passing, etc., by means of intern~lly
m~int~ined tables. For multi-national org~ni7~tioils or those who engage in
international communication or commerce, the filter may, in certain
implementations, recogni_e the language used on in-bound comm~lni~tion~ and
incorporate either translation or tagging information as required by the down-
stream applications or recipients.
The purpose of the filter is to ensure that record data units received, either
from external sources or internally created, are a~ro~liate for further proce-~ing
or handling within the olg~ni,~tion~ inc.l~(1ing verification/certification for archival.
The specific functions ~lr~,l,l,ed by the filter at any given time will generally
depend on the particular format, type and destin~tion of the record data units being
h~ntlled However, certain functions are pel~l,lled on all incoming information
regardless of format, type and destin~tion.
-lS- 215~925
-
Information format means the verifiable structure of the in-coming
information, such as a formatted EDI data stream. Information type is determinedby the source (technology) of the in-coming record data units, such as voice,
video, pre-processed data, etc. Information destin~tion means the co,-lpu
platform and application or other direct intended recipient of the information.
In the preferred embodiment, filter 3 captures incoming external
information, as well as record data units of information created within the
enterprise, and parses the information for further procec~ing. The filter, thus,detellllines whether required header or index data exists (e.g. location, date/time
data, etc.) and also whether ap~rop.iate filing and index criteria has been created.
Where necessary filing (indexing) data does not exist, the record or file is
transmitted to a hold area 4 and held for input of the indexing information by the
Records Manager or other design~ted individual in connection with the
verification/certification process described below.
Filter 3 also checks incoming information for redundancy with currently
archived records (e.g., whether a record with the same index criteria and date/time
stamp data has already been archived) and determines whether poter,lially
redundant information is identified as repl~cemPnt data intended to overlay the
eYi~ting file. ~edund~ncy (and potential for information resent from the source)is det~t~ by accessing the central ILM d~t~h~e 13 and system audit file 9.
Where redundancy is detected, the record (e.g., file) is deleted from the processing
stream and sent to hold area 4. The deletion and the potential redundancy is then
reported to the Records Manager or other central facility for resolution and foraudit purposes.
Filter 3 further verifies whether information has previously been processed
by the enterprise applications or is still to be processed or received by the
destin~tion address. Where the information has yet to be processed or received,
the filter first verifies the information integrily and then returns any n~ry
acknow]P~gmenL~ to the source, logs the receipt of the information and routes the
information to the proper destin~tion, e.g., business applications 5 or user work
station 7. The filter also reviews the priority ~c~i~n~d to the incoming records(from an int~rn~lly m~int~ined table or by reading a priority indicator received
-16- 215492S
with the incoming data) to ensure timely processing of priority information.
Priority records which require processing are forwarded with the appropliate
priority processing indicator or flag.
In the preferred implementation, the filter determines which coded
information is maintained for validation, processing, retention, retrieval,
information collection and ~ semin~tion and ultimate disposal for a single or
multiple org~ni7~tion unit. The filter ~tt~hes to incoming records a tag (i.e.,
envelope, pointer or reference entry prior to application proces~ing) which can be
associated with a d~t~h~ce in order to track the source, destin~tion, version,
storage location(s) and retention data associated with the record. Where
information does not enter the filter, e.g., scanned input, app~fiate tag (or
tracking) information is added during the verification/certification process. For
internally-created information, created either at the individual wolk~lion or bybusiness applications, information considered to be important for saving may be
sent to the filter for tagging, prior to being released either internally for further
handling, or externally to trading partners, etc. Where no further handling other
than verification/certification is required, such information may be routed directly
to the verification/certification module for operator h~ndling. In either case,
incomplete information is trapped and sent to hold area 4 and held for input of the
n~sc~,y proces~ing information by the Records Manager or other dç~ign~ted
individual.
As described above, the specific functions of the filter depend, at least in
part, on the format of the particular information being h~ntll~od. Thus, in the case
of formatted electronic information, the filtering process will further determine
whether the record is in a recognizable format that may be opened, read and
closed by applications requiring access to the record, and whether the information
is complete (e.g. has an a~,l)r~liate end-of-file marker or valid close parameter).
The filter also will determine whether acknowledgmPnt of receipt, in~ ding
electronic si~n~tllre validation, is required by the sçn-ling entity (and ensure that
a~)r~liate acknowledgment is sent), and whether the destin~tion of the record isclear and in accor~ance with o~ ;on~l pararneters (e.g., whether the record
must be processed further before storage).
- 17- 215492~
In addition, using in-coming header data and/or internally maintained
tables, the filter will determine whether there is a need for special handling of the
information (e.g., translation) prior to routing the information to the defined
destin~tion. Where special handling is required, the filter tags or routes the
information to Special Handling module 22. For formatted information inten~ed
for direct receipt by individual(s), the filter determines the number of recipients
and the a~r~ iate destin~tions (e.g. workstation(s), network storage), based upon
the requirements (e.g. size, type) of the in-coming information.
In the case of unformatted electronic information, the filter verifies
~estin~tion and priority information and, in the case of information intended for
direct receipt by individual(s), determines the number of recipients and the
appropliate destin~tion (e.g. workstation(s), network storage), based upon the
requirements (e.g. size, type) of the incoming information. Also, using data on
incoming record data units and/or internally maintained tables, the filter verifies
the need for special handling of the information (e.g., optical character recognition
processing) prior to routing to the defined destin~tion, and where special h~n-lling
is required, tags or routes the information to Special Handling module 22.
For digiti7~ hard-copy information, the filter verifies that the destin~tion
(e.g., file structure and file index information) information is clear.
Aside from format-driven functions, the filter performs certain functions
for all incoming information, regardless of format or type. For example, the filter
generates necessary information tags for all units of information processed through
the filter. These tags contain the following information - inforrnation unit
identifi-or, information source, destin~tion, versio~ or date, and, where applicable,
retention and storage location data.
The filter also ~tt~ches priority and other pertinent information to the
information units (e.g., "do not save" flag for items not to be backed up) and
places incomplete, re~llln-i~nt (not itlentified as approyliately re-sent) or otherwise
ayyarenlly inaccurate information on "Hold" in hold area 4. This information is
~pol~ed to the Records Manager message queue or other ayplopliate location for
further action (see arrow 5A).
-18- 21S~925
-
The filter further sends tagged, complete information to the destin~tion
recipient i.e., user workstation 7 or business applications 5, for further processing,
and receives information returneA from Special Handling module 22 and routes
that information to the dessin~tion recipient or application. The original file sent
for special handling is m~int~in~A at Special Handling module 22 in temporary
storage with a limited retention period, e.g., 90 days, until processing of the
information is complete. Where information intended for direct receipt cannot bedelivered, the filter sends acknowledgement and, as appropliate, stores the
incoming information in data buffer 6 for later delivery. The filter further logs,
to audit file 9, all appropliate information (multiple recipients, acknowledgements,
non-delivery, items held, special handling,etc.) The audit file can be useA by the
Records Manager or other authorized persons to provide system reporting on audit-
related matters.
Infortna~ion Processing
Electronic information which leaves information filter 3 after being parsed
(or information which has received special handling and is now being routed to its
destin~tion) is routeA to business applications 5, user workstations 7 or the Records
Manager hold area 4.
Items of information intended for individual receipt, such as f~similes,
electronic mail messages, electronic forms and files, etc. are routed to the
identified user workstations. Where storage r~4uirements prohibit routing to thewolk~lation, the data is stored on the network (described hereinafter with respect
to Figure 7) and a workstation notification message with applo~liate access
information is sent to the recipient, who will then access the stored information on
the network.
Data streams intended for processing by colllpulel applications are routed
to a hold queue and a message is sent to the console controlling that application.
Record items which are intended for real-time receipt (e.g. video and/or
audio tr~n~mi~cions) are routed immediately to the receiving address. If this
routing cannot be completed, a message is returned to the sender and the routingattempt is logged for audit purposes. Where possible, the incoming record is
buffered in data buffer 6 for delayed routing as resources become available.
-l9- 215492~
-
Record data which is intended to overlay another version of that data at the
same storage location is updated after an audit record of "before" and "after" data
is sent to the central ILM d~t~ e 13.
Scanned (digitized hard copy) information which leaves the user
wolk~tion is sent directly to verification/certification module 10, for proc~s~ing
by an operator, i.e., the Records Manager or other de~ign~ted person with
authority over the retention of records within the organization. The
verification/certification module receives information from multiple sources, and
is described below.
Record data units of information received at the destin~tion are processed
by business applications 5 or otherwise handled at user workstations 7. Where the
processed information is to remain internal to the enterprise, a~propliate b~r~lps
will be taken by backup module 8 subsequent to processing for recovery purposes.Ap~lupliate backups will also be taken by backup module 8 of information
at the workstation (or information saved on network drives), including a specialbackup of identified text files which may later be utili_ed for text search
applications of text d~t~h~e 12.
In the present system, information is processed by an organi7~tion~s
systems and personnel outside of the actual ILM system itself. The ILM system
will, however, continue to interface with those systems and wolk~tions to track
tagged information through its many stages within the org~ni7~tion~ from receiptand initial parsing through processing, backup and eventual disposal. This
tracking is made possible by the information tagging done by the filter, which
uniquely identifies every unit of information which is considered important for the
enterprise to retain (i.e., not every piece of information created within the
org~ni7~tion will be tracked for retention). Information which will generally beconsidered important for retention includes (1) information which is part of an
org~ni7~tion's official records retention schedule; (2) information required to be
backed up as part of a potential recovery process in the event of a disaster or
computer failure, including external incoming information intended for input into
business applications which will result in that backup process; (3) incoming
information, preidentified to the filter by source, type and format, which is
-20- 21~A92~
intended for input into business applications or to be routed directly to recipient(s);
and (4) information created within the org~ni7~tion which is routed to the filter for
tagging by an individual or process prior to any subsequent handling based upon
a determination that such information is important to a business transaction or
other affairs of the enterprise.
Information not considered to be important for retention may either enter
the filter (e.g., external incoming electronic mail messages which are not to bes~ved by the organi7~tion and which would receive a "do not save" flag from the
filter or deleted, redund~nt data) or may not enter the filter (e.g., created and
saved on the user's workstation hard drive and not considered necessary to be
saved by the workstation user). Such decisions are made both at the filter leveland by individual system users, including the Records Manager.
ILM Capture and Update
Previously processed or otherwise handled (e.g., viewed at user
workstation) information which is to be archived within the olg~ on is
captured, in the preferred implem~nt~tion, prior to being processed for verification
and certification. This capture is performed to ensure that the current location and
version information, subsequent to processing and system backups, is captured for
all information processed via business applications across multiple platforms,
including such information for all replicated ~lat~h~ces. It also ensures that the
information sent to user workstations (and any subsequent backups taken), which
is to be subsequently archived, is complete and organized for subsequent filing by
the verification and certification function; that all necessary preprocescing of text
files to be archived is done to ensure app,~fiate handling by subsequent text
searches; and that information which should not be backed up (e g, flagged as "do
Not Save") has not been backed up after processing or viewing. For all captu,~d
information, a prçlimin~ry update of location and version data to the central ILM
d~t~h~ce is done prior to pr~ by the verification/certification function.
To explain further, location and version information concerning uncertified
or pre-certified records is captured by ILM capture module 11 for update to ILM
d~t~h~ce 13 prior to any p,ocessed information entering verification/certification
module 10. This update is done for recovery purposes, in the event of system
-21- 21~92~
failure during proces~ing. Location and version information is captured for all
outbound information, i.e., information created for sending to destin~tions outside
of the enterprise, by either business applications 5 or user workstations 7; for all
processed information int~nded to remain internal to the enterprise; and for all text
files identified for later use by text search applications.
Outbound information or record data units may consist of processed data
files, such as EDI data streams produced by business applications 5. It may alsoconsist of infor,l,~tion produced at a specific user workstation 7 (e.g., text files,
images faxed, etc.), which is considered by the org~ni7~tion or user to be
important to the business of the enterprise and therefore, important to be tracked.
At the user workstation level, the decision to track outbound information is made
by the individual user.
Most processed information files are created, backed up and sent to the
a~propliate external dçstin~tion or regular internal stoMge location. For these
files, version and location information is captured for the purpose of m~n~ging
retention and eventual disposal only.
Information coming directly from the user workstation (including sc~nned
documents) will not normally enter the ILM capture module but will do so if the
information requires further internal processing (other than
verification/certification) and has been sent to the filter for tagging and routing or
the information is being sent outside of the enterprise and is considered i"~po~be to be tracked by the workstation user. Such information will also enter the
ILM capture module if the information is textual in nature and will be utilized
further by the org~ni7~tion for text retrieval applications.
The p.l,~ose of capture is to ensure that the location of all inforrnation
intçnded for retention by the org~ni7~tion is maintained. This is done to create a
complete and norm~li7~ l~t~h~ of information critical to the enterprise; the state
of the information within the enterprise is m~int~ined at all times in the event that
audit or recovery from failure or disaster is required.
Verificalion/Certification (Figures I and 4)
Records (image or non-image) are not accepted for archival within the
present system or viewing through the Retrieval function unless the documents are
-22- 21S~25
first "certified." Certification ensures that documents and files are placed within
the correct filing structure and associated with the proper documentation. It also
ensures that the documents or files have been properly captured (through SC~nnin~
or import) and have the applopliate retention information attached.
Sub-document pages (image or non-image) may be viewed and certified,
deleted or placed on hold status if questions arise which must be answered priorto certification. Certification involves viewing the images or electronic records
Att~h~d to the sub-document for clarity and correctness and proper filing withina case. Default retention information may be changed during this process and thereason for such change entered for audit logging.
The act of certification moves the sub-document within the system from the
telnl)ol~y network storage location to a permanent filing location (cabinet), which
may reside on disk or on permanent or erasable optical media. Certification
provides the quality control assurance often needed in legal proceedings to address
the ~mi~ihility question concerning the knowledge and skill of the individual(s)who created the record in the normal course of business. Certification replaces,in the on-line records management world, the act of verifying microfilmed imagesin the miclugldphics arena.
For processed information, a system verification/certification module 10
determines the ~lopliate security level and vehicle for retrieval of the archived
information and provides additional edits to verify the accuracy of header/indexinformation (e.g. that a normal end of file on EDI data stream exists). For textual
information where text search and retrieval may be needed, the location and header
information of the text file will be saved for re~erencing when text searches are
pe,rol-..ed.
The verification/certification process is pelroln~ed in either of two ways,
i.e., by an operator viewing the records to be certified or automatically without
operator inteNention. In cases of operator inteNention, the operator may query
audit file 9 for information concerning the status of information under review.
O~lator inteNention, which l~ S access to security module 20 for
verification of operator authority, is required in circum~t~nces where resolution is
required for incomplete, redundant or other potentially inaccurate information
-23- 2154925
which has been placed in hold area 4 by information filter 3. Operator
intervention is also required where digitized (e.g., scanned) hard copy
documentation is reviewed for completeness of indexing information, filing
placement and appropliate retention information, including storage media.
In addition, operator intervention is required where error conditions are
detected during the filter, audit, special handling, data buffering, ILM capture or
database update operations which require manual intervention. Errors occurring
outside system boundaries (e.g., within business applications, user workstations or
backup processes) should be monitored and corrected within those processes, but
may be detected by the ILM capture module.
Operator intervention is further required where information enters the
system, either through information filter 3 or from a user workstation 7, for which
no pre-defined retention information is available; and where manual tracking
information 23 for manually held records must be manually keyed into the system
for later use by the disposal module 14.
Operator intervention is not required for processed application data files,
which are automatically certified and sent directly to permanent storage media 19,
where the media and retention parameters are pre-defined within the system.
Storage media 19 may be directly controlled by multiple hardware/software
platforms. In cases of automatic verification/certification proces~ing, the system
will access the audit file 9 during the verification process.
Also, where large, processed co---puler files are received by the system for
COLD (Co..-puler Output to Laser Disk) storage (e.g., co..~puler report runs), the
verification/certification plocess will receive these runs and route them to final
storage location(s) as pre-certified records. In all cases, certification information
and "permanent" storage location is updated to the central ILM database 13, which
is the vehicle for most system reporting functions (block 15).
When the record is certified and certification information is written, pre-
certification information (written by the ILM capture process to a d~t~b~e file) is
deleted from the system. A record of all certification activity is also written to
audit file 9, and audit reporting (block 15) can be done utili7ing audit file
information.
-24- 21S~92S
-
For processed information not automatically handled by the
verific~tion/certification function, a Records Manager 25 (Figure 4) performs a
Quality Assurance review, as part of the verification/certification process, which
checks the appr~l;~tPnes~ of the record for archival and determines the r~colJing
media, and volume, where applicable, for storage. The goal is to provide storageof records with similar retention periods on the same volume and thereby expedite
the destruction process. Certain large record types (such as direct digital input)
may be specifically stored on media (such as Write Once Read Many, or WORM,
platters) and volumes retained for those records.
The Records Manager has the option to commit the record or file for
archival in ILM d~t~h~e 13, to delete the record or file from the system as
ina~ro~liale or erroneous or to place the record or file on "Hold" in hold area 4
for a specified period to resolve questions, after which the record will be deleted
or commit~ed. Committed records will enter the archival process and be stored toallow retrieval until the selected or system-calculated destruction date.
The Records Manager will utilize the method and system to ensure the
retention of all record formats and appropliate destruction of all logically related
records and record versions. The system will provide the Records Manager with
a catalogue of records scheduled for destruction, (see Figure 5, block 49), withfile/case/folder/dataset name, logical and physical location(s), destruction date,
record format and type and related information. The system will also check the
scheduled record type and retention period for those records against the cul~enlly
authorized retention schedule and report discrepancies which the system has not
previously detected.
The Records Manager will determine whether to modify retention
information or to destroy scheduled records. (see Figure 5, block 26, 27 and 28).
During the destruction process, the system will produce a destruction verifil~tion
log for certification of record erasure and reindexing of volumes whe,e not all
records were erased/destroyed due to extended retention periods.
System links to all involved proce~ing platforms will ensure that all new
backups are taken and system dataset catalogues remain synchlonized after
destruction. (see Figures l and 5, block 16). The best, but not the only method
-2s- 2154~25
of implementing the invention, ensures that, as required, JCL or other app~opliale
commands will be issued by the system to synchronize all affected system
catalogues. Where micr~for,l, or paper records are destroyed, the Records
Manager will oversee the process and enter destruct certification into the system.
(see Figures 1 and 5, block 18).
The system will retain the link between stored versions of unprocessed
information received from external entities and processed versions of that same
information so that both files or data streams, if saved, will receive the same
handling for retention and destruction. The system will store the location of all
on-site and off-site versions of electronic information, including backups and
replicated ~hh~ces.
Records managed by the present system and method may be m~int~ined on
multiple media types and in multiple physical and logical locations. (see Figure 3,
blocks l9A through l9F and Figure 6, blocks l9C through 31). The system will
track the record type, record format, location, dataset name, volume identifier, as
well as specific index information, security level and retention/destruction data.
The system will allow the automated ,--aintenance of approved records
retention schedules, including the ability for the System A~mini~trator to make
global modifications to retention data to all records for record types where policy
or external reasons cause a modification to retention criteria (see Figure 4, block
13). This includes the ability to suspend and resume sch~AIlled retention for
specific information in response to legal, regulatory or other needs or
requirements.
Records to be managed under this method and system result from
transactions ini~i~trd and completed through various electronic vehicles generating
industry standard record fol.,-at~, which may include some of the following: (1)scanned input, including scanned documents, photographs, blueprints, X-rays, etc.
filed and retained as images or microfilm/microfiche records converted to image
format; (2) electronic mail, inrll--ling incoming, internal and outgoing messages
filed and retained as part of an o~n;,~lion's transactions; (3) facsimiles,
including electronic f~simile information; (4) voice, including voice messages
captured as incoming telephone traffic, voice annotation related to srerific
-26- 21~92~
org~ni7~tional transactions obtained through audio capture or speech recognition,
interactive voice input (e.g. interactive telephone ordering systems) containing both
voice and pulse input; (S) video, including data captured as .li~iti7~d video images;
(6) text, including text files relating to completed transactions and resulting from
word processing files, optical character recognition output, document recognition
system output, conversion from voice input captured through speech recognition,
or col~-puler business application output; (7) electronic data interchange (EDI),
including EDI data streams retained as trading partner transaction records; (8)
output from col-lpu~er application systems, including records of completed
transactions (e.g. closed claims), periodic financial reports, employee records, etc.
generated from hardware/software platforms including personal computer/local (orwide) area network (conventional wire, fiber optic or wireless), mid-range
computing platforms, mainframe computing platforms; and (9) direct digital input,
including computer aided tomography (CAT scans), magnetic resonance im~ging
(MRIs), computer-generated holograms, digital packet data received through
cellular tr~nsmi~ion, etc.
The system can also be used to track the location, record type, destruction
date and case-specific information for non-electronic records and manage the
retention, retrieval and destruction of these records, including
microfilm/microfiche (not converted to image format) and paper records, whether
stored on-site or in of~:site archive f~cilities.
Figure 4 illustrates the verification/certification function in detail. As
shown in the figure, Records Manager 25 receives input for verification and
certification from multiple sources, which includes messages coming from
information filter 3, and record data units such as held records which have beenplaced in hold area 4 by the info~lllation filter or previously by Records Manager
25. Records Manager 25 also receives manual tracking data 23 for information
not controlled directly by the system which must be entered and tracked for
eventual disposal of the off-system information (from off-site electronic storage 17
and paper records 18 shown in Figure 1). In addition, the Records Manager
receives data processing exceptions 24 from business applications 5.
-27- 215~92~
-
Records Manager 25 also utiliæs information from audit file 9 and
retention and related data stored on ILM d~b~ce 13 during the process. System
reports are created from data on both audit file 9 and ILM ~l~ph~ce 13. During
this process, Records Manager 25 may enter required information about the data
record units being certified or about data record units outside the direct control of
the system (i.e., in storage areas 17 and 18), commit or certify the record dataunits, place the records on hold status in hold area 4 or delete records from the
system due to error conditions.
Data record units processed by business applications 5, and backups taken
by backup module 8 of these files, are stored on storage media 19. Location and
version information concerning these data record units is captured by ILM capture
module 11 and updated to ILM (l~t~h~ce 13 during the automatic certification of
the previously stored information. Where copies of the information created by the
business applications S have been sent outside of the enterprise, this information
will also be updated to the ILM database during the automatic certification
process. Processed information for which no exception conditions are noted need
not be handled by the Records Manager 25 during this process.
System Access/lnformation Retrieval (Figure 3)
Information stored within, and controlled by, the present system may be
requested for retrieval, viewing or other proceccing by authorized users of the
system. All such requests will be processed by the system to determine the levelof security access authority of the requesting user, in addition to deter~ ing aviable vehicle for viewing or using the information (e.g., sending copies of therequested information to the user workstation, to network storage, to an application
program, etc.).
The purpose of the retrieval function is to provide access to stored
information to system users within the ente,~lise in a manner consistent with the
requirements imposed by the type, format and size of the requested information,
as well as the information access needs and procedures of the ente,~,ise.
All individuals with access to the system will have security level access
information in their individual profiles, (see Figure 3, block 20) which will extend
or limit access to, and duplication of, the various records and record types
-28- 21~492S
managed by the system. Where paper hard copy records and!or microfilm or
microfiche are also managed through this process, the system will track the on-site
location or warehouse where the records are stored, as well as the warehouse
location or on-site file drawer, for ease of retrieval from any location.
The ILM ~t~ha~e includes information concerning logically related
records, their locations and retention data for retrieval and reconciliation of
retention periods and other information, to ensure simultaneous destruction of all
record versions.
Individuals with sufficient system access may view the archive catalogue
25 (Figure 3) and request retrieval of archived data. The system will verify access
authority to requested information prior to retrieval.
Routing of archived information will be managed by the system depending
upon the record format requested. Audio, video, image, textual or f~simile
information will be routed to the workstation 7 of an authorized requester and
placed in a queue for local access. Large application data files, EDI data streams,
etc. will be routed to the appropliate location/CPU (see Figure 3, blocks 5A
through 5E) with header information concerning the request (requester, date, time)
for processing by the business application, data file seal~;hing, etc.
All retrieval requests will be logged, and requests without necesc~ry
authority will be routed to a system user with authority for system ~lmini~tration
for exception handling. The System A-lmini~trator 26 (Figure 3) has the choice
of approving or denying the request for information and routing the information
to an a~ropliate receiving agency.
Figure 3 shows the information retrieval process in more detail. In the
figure, retrieval requests for record data units of information are sent from anauthorized user workstation 7 of the records management system. These
information requests are passed to the system security module 20 which determines
the user's access rights to the information. Authorized users may request
information after viewing the archive catalog 25, which is part of the central ILM
d~t~h~e 13. Requests which pass security validation are routed to ILM d~t~h~e
13 for location information. The system then routes the retrieval request to thea~r~pliate storage media l9A through l9E to obtain a copy of the requested
-29- 21~92a
-
record data unit(s). Access information is updated on the ILM d~t~h~e access log41, and the system determines the applol,liate routing for the information (block
24), i.e., sending the data to a user workstation 7, business application SA through
SD or to an ~rcescihle location on network storage SE. All information
concerning access to record data units controlled by the ILM system is availablefrom the system reporting function (block 15).
Retrieval is the most used function and allows system users to select and
recall case files or selected contents using any of the defined case level and sub-
document level index criteria, quick search characters (e.g., the first letter of a
word) or "wild cards" (special characters used to represent character strings), with
numerous defined search types (any part matching, all parts must match, etc.).
This function allows all users to obtain instant access to the same file or
documents without searching for hard copy files or creating unnecessary duplicates
of records. Retrieved images or electronic files are copied to the workstation for
local decompression (images) and viewing, annotation (images), printing (images)or making a working copy (electronic files). Such copies are resident on the
workstation fixed disk only until closed within the session or until the end of the
session, when the copies are deleted from the workstation. System users in
sepal~te geographic locations may view and annotate the same file, requiring only
a screen refresh to view one another's annotation information.
Retrieval also allows authorized users access to related in~ir~tors and
information in the form of annotations (line drawing, highlighting, electronic
"sticky notes" or margin comments), any icon "bullet" status indicators which have
been attached to cases or individual images with a descriptive message and any
case "journal" entries which have been created by individuals and attached to case
files. These journal entries may be either public to authorized system users or
private to the author and may have diary "tickler" dates attached which generatereminder messages to the author in their workstation message queue at the
a~lopliate date. Case journals are useful for maintaining on-line diaries of case-
related information. Journal entries may be edited or deleted only by the authoror the Records Manager.
215 192~
- 30 -
Persons wishing to review imaged (or other electronic) information are
allowed to select a portion of a case or folder (specific documents or sub-
documents) that they wish to view before images or files are retrieved for localviewing at the workstation. This lessens image traffic on the network and
improves overall system performance.
In one implementation of the present invention, retrieval features are
~ccec~e~ through "point and click" on the ToolBox and ToolBar command utilities
or by using speed keys or pull-down menus. Images or non-image files may be
viewed in single-page (one page at a time) mode or in dual-page (two pages side
by side) mode. Non-image files are viewed by using scroll bars to navigate
through the document. Options to assist a user in scrolling through documents
once retrieved to the workstation include: (1) clicking on sub-documents and pages
within sub-documents from a navigational box on the Toolbox; (2) the use of speed
keys such as the up and down arrow keys, pageup and pagedown keys, end key,
etc.; and (3) utili7ing a "case scan" function which, at a user-selectable speed,
allows the scrolling through of images and files in either single or dual-page mode
and a stop button to cease the scan when the desired page or file is reached.
Multiple cases may be open on the workstation at any one time. Pages from
multiple cases retrieved to the workstation can be viewed in a "side by side" mode
for comparison of contents.
Case journals may be acc~cse~ by authorized users from within the retrieval
function or from the menu. Case-level index criteria may be edited from within
the retrieval function.
Options available to m~nipulate imaged information once retrieved to the
workstation include: (1) Zoom (sizable window showing selected portion of image
or user-defined variable window showing document over entire viewing screen);
(2) Rotate (reposition image at 90 or 180 degree intervals; all annotations cullelllly
saved with the image are also repositioned accordingly); (3) Landscape (display
image in landscape format and save landscape position for further viewing by allsystem users after session is completed; when images are placed in lanllcc~pe, any
annotations attached in portrait mode will be repositioned accordingly); (4)
Annotations (overlay, edit and delete highli~ht or drawn line annotations;
-31- 21~92S
-
electronic "sticky notes", which are text entries that close to an icon which may
be positioned anywhere on the displayed image; margin comments, which are text
entries within an open window, which may be positioned anywhere on the
displayed image; and "bullets", icons which attach to an image and which may
have the bullet name overlaid as text on the image when displayed (e.g.,
"canceled")); (5) Case Scan (allows the user to page through retrieved images orelectronic files at a selectable speed and stop when the desired page or file ispresented for viewing); and (6) Image Tagging (allows electronic "paper clipping"
of a subset of retrieved images to create a dynamic file for working at the
workstation. This paper clipping, or tagging, feature allows navigation through
all retrieved information or only tagged information). These features do not
impact upon the integrity of stored information.
The following system utilities may be called from within the retrieval
function: (1) Send a Message (which allows a user to send a message to the
specific user workstation or to a general message queue for workgroup access); (2)
Save a File (allows the authorized user to make a "working copy" of a saved
electronic or image file and export it from the system; (3) Send Fax (allows theuser to fax imaged information directly to an external f~csimile modem or
machine); (4) Print (allows the printing of selected cases, folders, documents or
sub-documents to a defined locai or network printer); (5) View Message (allows
the user to review their individual message queue at any time); and (6) Search
(allows a report to be generated of cases which meet one or two search criteria-either within a case type or across all case types).
Where so configured, the retrieval function is under the control of a
specific user message queue when the user logs on to the system and selects the
retrieval function. The system will present the message queue only if out~t~ndin~
messages are present. Messages, once read, are deleted from the system to help
ensure that unnece~c~ry, transient information is not saved. Messages may have
the case identifier of stored case files ~tt~.h~, in which case the user may click
on the identifi~r and go directly into a case contents dialog for that case, which
allows the user to select that portion(s) of the case (or the case itself) that he wants
to retrieve for viewing. When a message is sent, the sender may set a priority (1
-32- 215~92~
to 99) for the message, which will determine the display order of the message inthe message queue (messages with the same priority level will be displayed within
priority in the order received). The system will poll for user messages on a user-
selected basis (e.g., every minute to an hour). When the system identifies a newly
received message, a user message is sent and the user may elect whether or not
to view the message immyli~tely.
The retrieval module accecces the ILM d~t~h~ce., which contains pointers
to the physical storage location of the image(s) or electronic files to be retrieved.
Image copies are retrieved from the image server and sent in complessed form
over the network and then deco~ essed by the software portion of the im~in~
engine for display at the requesting workstation. Electronic (non-image) files are
not compressed for storage. The images or files are optionally encrypted for
enhanced security.
Disposal of Records
Certified information, maintained within the system, is held for periods of
time (or other retention parameters, which may include retention by source, by
destination, by data usage, etc.), based upon the approved retention schedules and
other criteria (e.g., system backup schedules) of the enterprise.
For some records, retention information may be incoming with the record
or re~.ention may be ~ccigned to the record (e.g., information created at a system
user workstation) when it is sent for verification/certification.
At the end of the retention period (or version cycle, etc.), except in those
cases where information is so flagged or where retention has been suspended due
to legal action, regulatory proceeding, etc., the system will electronically purge
the retained information from all nececc~ry storage locations across all affected
hardware and software platforms. The purpose of the disposal function is to
maintain the smallest possible subset of v~lid~ted information required to manage
the business of the enterprise.
The present system provides an automated method of tracking the retention
of stored records and a purge feature which provides for the complete disposal of
records at the end of the retention period. While other systems dispose of d~t~h~ce
information and stored pointers, the present system completely purges the file and
33 21S~92~
all associated records and images, even those stored in cabinets or residing on
permanent (Write Once Read Many, or WORM) media.
During disposal of stored records, the system will purge records from
storage media 19, directly controlled by the system, and send a purge request for
electronic or paper records stored off-site (at off-site electronic storage 17 or in
paper records 18) or not within the direct control of the system, including backup
copies stored for recovery purposes. Such requests will cause data concerning the
record data unit of information to be retained within the system until the Records
Manager or authorized individual certifies that the records have been destroyed.Also, during the disposal process, the system will log all purge activity to
ILM d~t~b~ce 13 and audit file 9; delete all active pointers and other related
information from ILM ~t~h~ce 13 and other affected d~t~h~ces; and where
required, initiate a new backup process via backup module 8 to create files without
purged records. The system also will send a~ropflate commands aCL, etc.) to
affected platform system catalogues 16 to synchronize dataset versions. Reports
of all results of the disposal functions are obtained from the system reporting
function (block 15) or from information contained in ILM d~t~h~ce 13. Reports
containing related audit information (block 15) may also be obtained from audit
file 9.
Once disposal is completed, recovery of purged items which were deleted
in error is oniy available from a saved backup of the system. All files and
documents which are purged using this function are logged, providing proof that
destruction was done in the "normal course of business" according to establishedprocedures.
Disposal of images and files is facilitated by allowing authorized
individual(s) to select a file type (or all types) and to build a list of all documents
within the system whose disposal date is equal or prior to the current date. When
the list is built, all documents (except those carrying a "Do Not Delete" flag,
which prevents purging from the system until the flag is removed) are
autom~tic~lly selected for disposal.
-34- 215~925
The authorized user may de-select a document or file and remove it from
the normal disposal process, if this is desired. When this is done, the documentwill not be purged during the disposal process.
The system allows an authorized user to modify retention information for
items not purged in the disposal process or to retain the original disposal date.
Where the retention information for those items is subsequently modified throughthe "recertification" process, a reason for the change must be entered into the
d~t~h~ce by the Records Ma~ager. When the disposal date is not modified for
items not purged, these items will present them~-lves in all subsequent disposals
(for that case type) until the items are purged.
Figure S illustrates the disposal function in detail. Referring to the figure,
disposal of records is initi~tçd by Records Manager 25 at defined intervals.
Records Manager 25 may choose to destroy a set of record data units, to exempt
the records from disposal and/or to modify the retention information. Where
retention is modified, the record data units are fed to a reindexing function 29where retention data is updated. The new retention data is updated to the ILM
~t~h~ce 13 and the reindexing activity is also reflected in audit file 9.
Where the decision made is that records are to be purged (block 28), the
system (block 30) purges the record data units from storage media 19 controlled
by the system and removes all related data from ILM database 13. The system
also records the purge activity to the ILM c~t~b~ce and logs the activity to audit
file 9.
Purge requects are initiated for records 17 stored off-site and for paper-
based records 18. When n-)tification is received that off-site and paper recordshave been destroyed, the Records Manager will update ILM ~t~h~ce 13 and the
activity will be logged to the audit file 9. After a purge is completed, the system
will initiate a new backup process (via backup module 8) and affected system
catalogues 16 will be synchronized to reflect the new version information.
When disposal occurs for records which are stored on permanent media
(e.g., WORM platters), special handling is required to remove the stored sub-
documents from the system. In accordance with this process, sub-documents
stored on permanent media are removed by first creating a temporary ~t~h~ce
2154g25
table for all permanent (WORM) volumes which have sub-documents to be
disposed, and verifying the path to that volume. Sub-documents to be removed
from the permanent media are grouped on temporary d~t~h~e tables by platter
(e.g., WORM01, WORM02, etc.). A check is then made to determine whether
any of the sub-documents to be disposed is logically ~tt~ched to another document
or folder with a longer retention. If so, the document cannot be purged from thesystem.
Next, the contents of each affected platter are dumped to rewritable media
(after the system has determined that sufficient storage capacity exists on the
rewritable media). The records to be destroyed are then purged from the
rewritable media (e.g. platter). After each affected permanent platter's contents
are dumped to rewritable media, a system message is sent to the System
Admini~trator to dismount and destroy the permanent platter. After each
dismount, a system message is sent to the System A-lmini~trator to mount a new
platter, which has been initialized with the same volume name and to which
rem~ining platter contents are written after the system checks to verify that the
volume name equals the volume identifier of the destroyed platter. If there are no
rem~ining records to be written to the new volume, the mount message for the newvolume will not be sent and the next platter to be purged will be mounted.
After all records are deleted from each rewritable medium, all associated
database records related to that sub-document are purged from the d~t~h~. In
instances where all sub-documents (or all rem~ining sub-documents) in a case arebeing destroyed during the disposal process, all case-related information is purged
from the d~t~h~ce tables. The exception to this is where outstanding informationexists conc~-rning off-system sub-documPnt versions which must be destroyed as
part of the disposition process. When information is deleted from the d~t~b~ce,
as the transaction is committed, the table is overwritten.
This process continues until all affected permanent media has been
lewlillen with records not yet due for disposal. After the permanent media
disposal is completed, the system deletes all selected images or electronic records
and ~soci~t~d d~t~h~e information stored on rewritable media, making the space
available for storage of other information. Deletion of images or electronic files
-36- 215~925
and SQL database information for those files is done on a one-for-one basis for
images and electronic records stored on rewritable media. All records purged
from the system are logged for audit purposes as the files are deleted from the
temporary media and reports concerning disposition are available from the system.
Another method of purging records stored on permanent media involves
building the te~ ry ~t~h~e table for all WORM platters with contents to be
disposed and verifying the path to the volume. Sub-docl-m~nt~ to be removed
from each platter are then grouped by platter and a check is made to determine
whether any of the documents to be disposed are logically ~tt~ched to a document,
folder or case with a longer retention. If so, the sub-document cannot be disposed
of during the process.
After the contents of each permanent platter have been checked, the records
to be saved are written to temporary storage and a check is made to ensure that
only records to be retained have been written. A message is then sent to the
operator to remove and destroy the platter and to mount a new WORM platter in
its place. The contents of each WORM platter which are to be retained after the
disposal process are then rewritten to a new WORM platter.
Centralized A~tomnted Records Archival
Another implementation of the present invention involves an automated
"warehouse" facility for paper and electronic records. Such a facility can be
~ces~ed on-line from eYtPrn~l or~ni7~tions and provides for the automated
transfer of requested information stored on behalf of the external entities.
From time to time, org~ni7~tions audit records stored off-site in warehouse
facilities, such as facilities managed by Pierce Archives. Although the number of
"lost" paper records may not be significant in relation to the number of recordsstored at the facility, some number of boxes of records are generally lost or
misfiled due to the manual nature of the storage procedures used in most such
facilities. Also, many current archival f~iliti~s which are well-org~ni7~d, clean
and climate-controlled for proper storage conditions are mainly for "dead" storage.
Such facilities cannot handle a significant volume of recall/drop-off/delivery
requests, such as those generated by large org~ni7~tions or entities. Other
37 215~92~
facilities which are less org~ni7~d and controlled for proper archival of records are
better staffed to handle volume drop-off/recall requests.
Using the ILM system according to the present invention, an automated
archival facility for paper and electronic records is the "next generation~ of
archival storage and provides for storage of retained paper documents and
microfilm/microfiche as well as records stored in electronic formats. The present
invention can be utili_ed by org~ni7~tions whose records archival needs are moreactive than Hdead" (i.e., record recall requests will be frequent enough to warrant
on-line access to the archival facility).
A facility according to the present invention will handle an org~ni7~tion's
total requirements for records management (active and dead storage). The facility
is accessible through an on-line system, which will validate and process requests
for archived information and forward requested data electronically or by other
physical means to the requesting org~ni7~tion.
Due to the sensitive nature of information stored in this facility, on-line
requests can be made, through a system terminal in the requester's own facility,only after a smart card or other access key is properly placed into the terminalreceptor. This access key for example, will perform the following functions: (1)turn on the terminal and ~tt~rllp~d microco~upuLel, (2) validate that the request for
archived information is within the bearer's archival access authority (contained on
the card); (3) update the card ~l~t~h~e with the information access request; (4)establish a telecommunications link with the archival facility; and (5) send
information concerning the information access request to the archival facility.
If the request for information is rejected during the card/tell,linal operation,the access card holder will receive a "Not Authorized" message, and the invalid
access attempt will be upd~t-PA on the access card database. If a sufficiPnt number
of invalid access attempts are made using any single card, the card will also beinv~lid~tPA for access until a revalidation routine is pelrol--,ed on the card by an
authori_ed agency.
When a previously validated access request is received in the archival
facility, a system tellninal at the facility will display the identity of the requester,
the requesting org~ni7~tion~ the records requested, media and location, as well as
-38- 21~ 925
-
the desired mechanism for forwarding the information (on-line tr~ncmi~ci-)n,
courier, etc.) to the requester. Data tr~ncmitted by the facility to client sites may
be encrypted as part of the tr~ncmiccion process. One or more encryption keys
will be made available to clients for data decryption prior to reading or pr~scing
at the client location. The decryption process will be undertaken by an authorized
individual at the client site.
An archival facility ~t~h~ce will track requesters and data requests, along
with archived records, media and locations. This information will periodically be
fed through a neural network system which will assist in the management of record
archival media and location for ease of access and forwarding.
As requested by its clients, the facility will arrange with an outside
vendor(s) to do conversion of paper records or microfilm or fiche to optically-
stored images. In addition, records retention information for those images may be
added at the facility upon request.
Pierce Archives, for example, offers, as part of its service to customers,
an on-line system to allow a customer to review records archived, box locations,make record retrieval and destruction requests and allow ordering of record
cartons. This service, accessible from a stand-alone microprocessor or pelsollalcomputer, supplements monthly activity reports sent by Pierce to warehouse
clients. The automated facility according to the present invention provides the
following additional services: (1) added security through remote access key
validation prior to contact with the archival facility; (2) management of electronic
information across all fol"-als and media, in addition to storage and managementof paper and microform records; (3) capability of providing a total records
management solution, not just archival warehousing of records; (4) capability ofproviding, through business relationships, document/ microform conversion and
index and records management information entry; (S) multiple retrieval options,
including electronic transfer of information to a requesting customer; and (6)
active, continuous, physical archival management, utili7ing technology (e.g.,
neural network monitoring of datatpaper access frequency) to optimize record
locations (e.g., change jukebox platter locations or move physical records to more
accessible locations) and facilitate retrieval.
39 - 21~9925
The archival facility, according to the present invention, will also provide
a solution to the following problems experienced with current records archival
comr~nies: (1) inaccurate inventory of archived record cartons; (2) time-
cons~lming and costly research process required to locate old records due to lack
of itemized knowledge of carton contents; (3) lack of follow-up tracking or
information available on records recalled from archival, including up-to-date
retention and destruction schedule data; (4) time delays in rec~lling archived
information from the off-site facility; and (5) inability to manage all businessrecords through a single system.
Although these issues are less important for organi7~tions whose archived
records are "dead" (i.e. seldom if ever recalled), previous Records Management
studies have shown that at least 25% of inactive paper records, for example, arerecalled on a regular basis.
ILM System Remote Opera~ion with Sma~tCards
Referring to Figure 6, an alternative method of implementing the ILM
system will now be described.
In this figure, the ILM system is used to run a remote information archival
application, which houses information belonging to multiple organi7~tions and is~ccessed by authorized l~leselltatives of those org~ni7~tions through a retrieval
station 7 conlaining a smart card reader. Authorized individuals wishing to reques~
access to stored information from the archival facility place their sl,la,~card access
key 36 in the reader in their organization. The card turns on the terminal 7,
validates the card bearer's access authority from the card access database 20,
updates the information retrieval request on the card ~l~t~h~e 38; establishes acommunications link with the archival facility; and sends data concerning the
information request to the archival facility.
Information requests not within the card bearer's authority will receive a
"not authorized" message and the invalid access attempt will be updated (block 39)
to card tl~t~b~e 38.
Valid retrieval requests will be routed to the terminal 7 at the archival
facility and will display the requester, requesting org~ni7~tion, requested records,
215492S
media and location, as well as forwarding information (on-line tr~nsmi~cion,
courier, etc.).
Retrieval request information will be written to an access/retrieval .l~t~h~
41. The system will query ILM d~t~h~ce 13, which will route the retrieval request
to the applopliate storage media (18, 31, 19). Periodically, request and location
~l~t~h~e information will be fed through a neutral network system 36, which willdetermine the most viable location for information and media storage (-hased upon
frequency of access, etc.) for ease of retrieval and update the consolidation
,t~h~e 37 accordingly.
Data to be tr~nsmitted to the requester is, preferably, first encrypted and
an encryption key 34 is attached to allow for decryption at the receiving location.
The information is then forwarded to the requestor's waiting business applications
(SA, SB, SE), to a stand-alone retrieval (viewing) station (7), faxed to a specified
number (32) or sent by courier (33), if requested.
Sample System Configuratwn Showing an Enterprise
Implementntion with Branch and Central Corporate Locations
Referring to Figure 7, there is shown another exemplary system
configuration. In this sample implementation, documents are sc~nned into the
system by a scan wo~ lion in a branch location and sent (see arrow 1) to
temporary storage where the documents are saved. The information is passed,
through a router 2 located at the branch location, to the Wide Area Network 3.
The information is received at a router 4 in the corporate office and stored
temporarily on a file server, which may be a Novell file server. At the col~lateoffice the records are recalled from the file server 8 by a management workstation
6 connected to a local area network ring 7 and routed via routers 10 and 4 to the
management wolk~k~tion for certification.
Certified records may then be requested by a second branch location
retrieval workstation 13. In response to the request, images are routed from file
server 8 to a router 9 and into the Wide Area Network 3. The images are
received via a router 11 at the branch location and routed to the Local Area
Network 12 for passing to retrieval wolk~tation 13 for viewing.
215~925
- 41 -
Sample Filing Structure for Paper-Based InformaAon
Figure 8 represents a samplè filing structure which may be used for filing,
storage and retrieval of paper-based (sc-qnned images) docum~-ntc or electronic
documents (e.g., spre-q.-lcheetc, word pr~ing files, etc.) which are generally
handled for filing and retrieval in the same manner as paper-based files are
handled.
The elements of this structure include a cabinet 42, which lepl~senls a
physical storage location; a case type 43, which represents a type of file, such as
a claim or a contract; cases 44, which lcpre3ent spe~ fic instances of the case type,
such as specific claims or contract files; folders 45, which replcscnt logical filing
units within the cases; documents 46, which rcpresent individual docum~ntc (or
groups of records) stored within the folders; and sub-documents 47, a further
definition and breakdown of information stored within documents. The last unit
of case-based files is the page 48, which represents a specific scanned image orelectronic record. This unit has been defined, for example, as a record data unit.
The sample file structure mimics a paper file stored within a separate folder.
Other System Features
The ILM system of the present invention is an integrated tool which
combines the features of an electronic document management system with true
Records Management c~pability and sensitivity to and support for the issues of the
legal ta~lmi~sihility and discoverability of records and electronic records-related
regulatory compliance issues through built-in system features. These and other
unique rea~ures of the present application which distinguish the system from other
available products are now explained in some detail.
Automated Support for Legal Admissibility of Stored Records
System Integrity
The system of the present invention is a self-checking system. When a user
signs on to any of the main system functions from the Main Menu (Scan, Retrieve,Management Services or System Services), a system integrity test is run, ch~in~
the status of that user's wo,~l~lion ~hard drive, CPU, network connection), as
well as the network plinlels, system servers, optical storage devices and dq-~-qbq~e
integrity. A status dialog box on the screen shows the progress of the system self-
-42 - 2 1~ 4 ~2~j
,
check to the workstation user. Results of this test are returned and logged to atable on the 11~t~h~e This built-in diagnostic provides the answer to the
customary admissibility question, "How do you know that the system which
produced these records was working properly?"
The System Integrity function can also be run by authorized system users
from the Main Menu at any time. This function provides a printed record of the
integrity check results.
Audit Logging
All significant functionc performed on the present system are logged for
audit purposes to tables on the ~t~h~e, with such information as the login ID and
workstation of the user pe~ ning the function and the date and time the functionwas performed. In addition, no record deletions or modifications to the retention
data of stored records may be ~lrol"led without first indicating the reason for the
deletion or change. The reasons are also written to the audit log file.
All records printed by the system are logged, with the ID and wol~lation
ID of the individual who printed the record and the date and time the print was
done. This extensive logging is useful for troubleshooting and activity verification.
More importantly, the logging may also be valuable in the event it becomes
necessary to prove to a court of law or regulatory body that some activity did not
occur (records may be used to prove the negative as ~ell as the positive). In
addition, back-up support for any deletion of records "outside the normal courseof business" (which may r~use a flag if discovered during litigation or pre-trial
discovery) is noted within the system itself.
System Audit Function
The System Services portion of the present invention contains a feature
which allows an external individual(s) to audit stored files (image and non-image
records) by building a list of files in one or all case types and selecting individual
files, folders, documents, sub-documton~ and pages to view in the Audit functionviewing window. In addition to the images or electronic files, the auditor may
view all index and retention period information and del~ ine whether annotationshave been added to the individual sub-doc-lm~nt page(s).
-43- 21S492~
After viewing, the auditor may place a Pass or Fail flag on the sub-
document, which will cause a Last Audited date field to be filled by the system.This date is used to verify that an audit has occurred and also to select cases and
sub-documents for the next audit pass. Closer scrutiny of s~le~ted cases may be
done by noting the select~d files and viewing them using the retrieval function
prior to setting the audit flag indi~tor. Cases for audit may be selected through
a reference to the Last Audited date field (e.g., select all cases not audited
since. ..).
This feature provides the org~ni7~tion with an automated manner in which
to periodically inspect its electronic records and provides an answer to the
a~miccibility question: "How often is the system which produced these records
audited?" since it can be shown that business records are consistently che~d foraccuracy and that established procedures are consistently followed by system users.
The system reports function provides several pre-defined audit reports for use by
the system auditor. Specific audit criteria for each org~ni7~tion are developed
within that organization to conform to internal policies and procedures.
Elec~ronic Document lmport/E~cport
Electronic documents, other than scanned images (e.g., electronic mail
messages, facsimil.os, word pl~cec~;ng doc~lm~ntc), may be imported into the
present system, from a user wG,k~tion using the Import Utility and saved as partof an official business record within a system file. Although these documents
remain in modifiable format and can be copied for export out of the system, theymay not be modified from within the application and none of the ori~in~ting
applications (e.g., Excel) can be launched by the present system. This helps
ensure the ir.l~lily of saved file contenls. The ability to make working copies of
saved electronic files is limited to specific system users through system security.
Version, Media and Duplicate Management
The present system provides for the tracking of sub-docum~ontc which have
off-system duplicates or for which off-system duplicates have been created through
printing of imaged documents or the export copying of electronic files stored
within the system. In the last two inct~nces, the location is recorded autom~ ally
by the system to a Media Locations table. When stored system records are backed
-44- 2154925
up for recovery purposes, information concerning the backup is written to a
Backup Log.
For other copies or duplicates of the sub-document not created through the
system, the Records Manager may enter the information into the Media Locations
table for tracking. The system tracks both the media on which the sub-documPnt
is stored and the physical location of that record. This is done to f~ilit~te the
simultaneous (manual) destruction of all out~t~nding copies of the sub-docum~Pntat the end of the retention period.
When the disposal process is performed, it is ne~es~ry to run a new full
backup of both the ~t~h~e and stored image and electronic files and to dispose
of prior backups to ensure continuing integrity of scheduled retention information.
After the disposal process, the prior backup is m~int~inPd only until it can be
verified that no records were purged in error.
The electronic record export facility allows an authorized system user to
create a copy of the stored file and import it into an application for mo~ifir~tion.
The present system will not launch that application (to prevent ~t~cident~l
overwriting of previously certified information) and requires that any other
"versions" of the electronic records be separately saved and certified into the
system. This allows the reuse of electronic documents or records without
co.l-pru--.ising information stored within the system.
The present invention may be implemented in accordance with any suitable
progr~mming language and run on any operating system. The operating
environment for controlling the storage of images and electronic files may be
Novell Netware (Token Ring or Ethernet), or Windows NT. For a current
Microsoft Windows NT implement~tion, an interf~e ("thunking") layer h~nflle~
the 16 bit to 32 bit conversion of calls and parameters. Other implem~nt~tions can
include OS/2 and Unix.
Four or more main irunctions and a number of utilities are ~ ihle
through a Main Menu. The Main Menu conl~ins icons for all functions and
utilities available and "bubble help" for each icon to assist the user in navigating
beyond the menu. Functions and utilities not ac cessihle to a specific system user
-45- 215492S
.
are disabled at the Menu screen when the user signs on to the system. The main
functions are further described as follows:
Scan and Index
This is a restricted access function which allows a user to enter information
into the system through a number of industry-standard scanner devices, which
interface to the scan function through the Kofax im~ging engine.
A Kofax board (and software) is inct~llP~ in any workstation utili7ing the
scan function. This board provides connectivity with the scanner device and
handles image co~ ssion and deco-nplession. Kofax is considered an industry
standard im~ging vendor. The present system incorporates, insofar as possible,
industry standard hardware and software components coupled with its own
proprietary application.
For case files to be stored within the system, the user may attach
approp~iate index information (search criteria) to imaged cases and sub-documPntc,
organize documents for formal filing and retrieval and save the images to a
pOl~y network storage device.
These images may be placed into a newly-created local filing unit (i.e.,
case) or appended to exicting information within the system. Images are
co~.lp~ssed by the im~ging engine prior to saving on network storage to minimi
impact on network traffic and file seNer storage. The system may be placed for
sc~nning in automatic system mode, which creates or retrieves case information
and scans documents into the created or retrieved case, or in step by step mode,which requires the sc~nnict to scan first and then process case information in astrictly controlled sequence of events.
Through this function, the sc~nnict may toggle to an "in-bound queueH,
allowing the sc~nnict to index and place (file) uncertified electronic documPnt~ or
files that have not been scanned but are incoming by means of being placed into
.he Import Utility by authorized individuals. Such "documents" include, among
others, f~csimilPs, electronic mail messages, spre~dcheetc, word procPscing files
and other ASCII files. These documentc may be viewed by means of a generic
viewing utility, org~ni7e~ and filed together with imaged documents in a~r~pliate
case files.
-46- 2154925
Documents may be scanned in black and white or in color into the system
on a case basis or batched with separator sheets for high-speed sc~nning and
h~n~ling of batches. The system allows saving of b~t~he~ pages on network
storage to allow for separation of sc~nning and indexing functions. All functions
of the selected scanner, including resolution setting and halting the scan process
if nece~ry, are controlled through the application itself and do not re~uire
physical manipulation of the scanner device.
Documents inco,leclly sc~nnt-d (e.g., folded or bent) or illlpropelly
(unneces~rily) scanned may be deleted prior to the save process. For indexed
files (not saved batches), entered search criteria will be updated to the d~t~h~e
when the case is saved to temporary network storage. For batches, only batch
information will be saved to the datab~ce during saving to network storage.
Landscape documents which have been scanned into the system as portrait
documents may be flagged as lantlcc~re for ease of later viewing without the
necessity of rotating the image(s). The scan function has access to mes~ging as
well as the bullet annotation feature of the system. Scan may be minimi7ed to
allow for simultaneous running of other applications.
Imaged documents are co.,.l"cssed as they are sc~nned into the fixed disk
of the scan workstation by the hardware portion of the im~ging engine. Saved
(imaged) documents are preferably sent in co,.ll)lessed form over the network and
stored in temporary storage as co---~lessed images.
System Services
This function allows the System A~mini~trator to configure system options,
to handle security, set the l~t~h~e backup schedule and to access the pre-defined
reports menu. System Services is the day-to-day ~ministrative function handler
for users and contains the system audit function. System Services functions
include:
Security:
The security function allows the System ~rlministrator to define user
security profiles, which include functional access rights and stored informationaccess levels. The user may be given access to any or all of the four main system
functions and the system utilities Retrieve, Management Services and System
47 21~4925
Services are broken down and access to these sub-functions is also given within
Security.
At any time the System Admini~trator may determine what functional
access has been granted to a specific user by clicking on the Quick Rights button,
which produces a listing of all system features to which the user has access. The
access rights for each system user are set up within the Security function, as asecurity access range (for example, 0 to 999) which conforms to security levels
given to cases, folders, documents and sub-documents which are set up within thesystem. The user is ~igned a low range and a high range and is allowed, for
example, up to ten range exceptions (security classes outside the main access range
to which the user has access). Case information, cases, folders, documents and
sub-documents which are not included within either the access range or the rangeexceptions may not be retrieved by the specific system user. Associated with each
user is location information, which defines the portion of the org~ni7~tion to which
that user belongs. This feature allows the system to be used by the enterprise,
whether or not the enlel~rise is defined as a single or multi-company org~ni7~ti-~n.
Passwords are set up within the user profile by the System Admini~rator
and must be modified at sign-on by all system users on a pre-defined basis (e.g.,
every 30, 60, 90, etc. days). Passwords are encrypted within the system and are
not viewable at any time (encryption may be based on a DES algorithm or other
algorithm known in the art such as PGE, RSA, NIST or the like; for example, the
password is encrypted twice and the results of that encryption are converted to a
numeric string). The Login ID is set up within the system to equal the network
(e.g., Novell) Login ID and is never entered by the user during the login process
to the present system. The system checks the User Table to determine that the
Login ID which corresponds to the entered password equals the Novell Login ID.
Where a dir~elence is detected, login access to the present system will be denied.
Repeat use of passwords by users of the present system is discouraged, as
the system tracks the current password and the three prior passwords used and will
not allow any of these pas~lvofds to be entered during the password change dialog.
The use of trivial passwords (e.g., "AAAAAA") may also be prohibited.
-48- 21S~S25
Options:
Options is divided into the System Audit function (previously described)
and Configuration Options. Configuration Options include the set-up of a GeneralQueue for workgroup mes~ging and the set-up of outbound faxing for sçlectçd
users with the proper equipment installed at the workstation.
Set Backup Frequency:
The system allows authorized users to set the date, time and frequency of
~t~h~e backup. Where no settings are made, the system defaults to a backup at
24:00:00 daily.
Reports:
The System Admini~trator is allowed access to a full, pre-defined menu of
reports. Reports fall into three categories: Management Reports, which contain
information required for the Records Manager to handle the Management Services
function; Audit Reports, which contain reports used by the external or internal
audit individual who uses the System Audit function; and System Reports, which
include system activity logs and other reports required by the System
Admini~trator. Reports are point and click (report runs immerli~t~ly after clicking
on the icon next to the desired report name) and some reports allow the entry ofa date range to limit report output. When the report is run, an on-screen formatted
report is immediately created; printing the report, if desired, is an option. Several
navigation icons allow the report re~uester to navigate through the pages of the on-
screen report. Ad hoc reports may also be created using a report utility program.
ManagemenI Services
The Management Services function allows authorized individuals to handle
all system set-up and processing functions associated with the Records
Management portion of the system, inclu-ling Records Admini~tration (which
includes the certification process previously described); Disposal; Types (set-up
of the case-related filing structure including cases, folders, clocumçnt~ and sub-
documents, with ~ ted retention and security class information); Cabinets
(dçfining storage locations and the path information for that location); and Bullets
(which allows the Records Manager to define what icon status indicators may be
-49- 21S492S
associated with cases stored in the system). Management Services contains many
unique features of the present invention.
Records Admini~tration:
The main function of Records Admini~tration is the certification of sub-
document information to be stored within the system and made available for
retrieval by authorized users. Certification is performed in one of the available
system modes of Records ~dminictration, i.e., uncertified mode. While the
images or electronic files are uncertified, they are stored in te,l,~l~y networkstorage and are unavailable for retrieval at the, wolk~tion. During certification,
stored records are moved by the system from te"ll)ol~ y storage and placed in their
pre-defined permanent location. Also, during certification, the system uses the
retention period (for example, in months) and the certification date to calculate the
disposal date for sub-docl-ments having date-driven retention. Certification is a
quality control process pe-r~"",ed on most case-related information. Large
numbers of computer-generated records being filed within the application at one
time may be sent through as pre-certified records.
After certification, the Records Manager may still work with the case file
contents by ~rces~ing certified mode. In certified mode, the Records Manager
may view index information, attached bullets, media locations and retention
information and has the following available options: (1) delete page or sub-
document (a reason must be entered for audit purposes); (2) transfer page or sub-
document (move from one case, folder or sub-document to another, including
movement between storage cabinets); (3) copy page or sub-document (logically
attaches a stored page or sub-document to more than one sub-document or
document, across cases and folders, so that when any of these cases, folders or
documents are retrieved, the copied page or sub-document will also be retrieved);
(4) add/delete media locations (add or delete references to copies of sub-doc. ~"~,Lc
which are stored on media and in locations outside of direct control of the system
to help ensure complete file disposition of all copies at destruction time); and (5)
modify retention period (change the default retention information set for the sub-
document at the time of certification; a reason must be entered for audit purposes).
-50- 21~4g25
-
The Records Manager also has the opportunity to rotate images as they are
displayed. Electronic (non-image) files cannot be rotated but may be viewed by
using scroll bars.
Prior to being certified, data streams, sub-documents or uncertified sub-
document pages may be placed by the Records Manager into Hold status until
problems or questions can be resolved and certification or deletion can be done.The Records Manager may access the hold mode to review and certify sub-
docum~nts which have been previously placed on hold. Data, sub-documents or
pages in hold mode may also be deleted or left in hold mode upon exit.
Sub-documents which, for intPrn~l, legal or regulatory reasons, are
excepted from the normal disposal cycle when they present themselves for
destruction, may be recertified if the Records Manager wishes to modify retention
information and so indicates during the disposal dialog. All such sub-docum~n~
are then flagged for recertification and will autom~tic~lly present themselves when
the Records Manager ~cces~es the l~cellirled mode of Records Admini~tration.
The Records Manager may then alter the retention information and certify the sub-
document(s), after entering a reason for the change for audit purposes. The
system will recalculate the disposal date based on the newly entered retention
information. Whenever the retention information is modified, the system l,lesellls
the Records Manager with the default retention information and the last entered
retention for comparison purposes.
When the only information concerning a case in the system is information
concerning off-system Media Locations or when the Records Manager wishes to
add or delete Media Locations information without the performance overhead of
retrieving and displaying images or files, the Records Manager may access the
"media only" mode of Records Administration. The same functionality is
presented in this mode as in certified mode, except that images or electronic files
will not be displayed. When all images or electronic files have been purged fromthe system and all Media Location information deleted by the Records Manager,
all ~l~t~h~e information will be purged from the system after the deletion is logged
for audit purposes.
-51- 21~ 1~25
The following utilities are accessible from within the Records
Administration function: (1) Send Fax; (2) Send A Message; (3) View Message;
and (4) Print.
Disposal:
This function (described above) may only be accessed by authorized
individuals. In brief, its main functions are to: (1) build and finalize disposal lists;
(2) verify copied pages/files; (3) write temporary ~l~t~h~ tables; (4) purge andrewrite permanent (WORM) media and ~soci~ted d~t~b~ce data; (5) purge erasable
(DASD or rewritable optical) media and associated ~at~h~e data; and (6) write,
for audit purposes, a disposal log for all sub-documents, etc. deleted from the
system.
After this process has been completed, it is necessary to manually
determine that no records have been purged in error and then to complete a new
full system backup, destroying any prior backups. This will preserve the integrity
of the disposal process. Sub-documents marked "Do Not Delete" may not be
purged during the disposal function. The Records Manager may, however, view
any descriptive text entered when the marking was attached to the sub-document.
When the Records Manager exits the disposal function and has excepted
records from the purge, he will be asked whether the records are to be recertified.
A "yes" answer will place the excepted sub-docum~nt~ in the queue for
lc;ce, lification.
Tvpes:
This set-up function allows the Records Manager to create within the
d~t~h~ the filing structure for the storage of case-related information within the
system. Types to be defined include Cases, Folders, Documents and Sub-
Docl-m~nts. Any associated index information is defined for cases and sub-
docum~onts when they are defined to the system and sub-document retention is setwhen the sub-document type is defined under the appl~liate document type.
Retention types include (1) date-driven retention (a period in months is
assigned at certification (or a default is used) and the sub-document is destroyed
at the end of the period); (2) event-driven retention (retention will not begin until
a specific event, e.g., tel-nination of an employee or cancell~tion of a contract or
-52- 215~92~
-
policy, has occurred; the entry of the event date will trigger the beginning of the
designated retention period); or (3) replacement retention (a document or file will
remain within the system until a replacement of the same type is filed, at whichpoint the first document on file will become available for disposal).
No Case, Folder, Document or Sub-Document type may be deleted from
the system if images or electronic files stored in the system are associated with that
type until all images and electronic files have been deleted or transferred.
Cabinets:
This set-up function allows the Records Manager to define locations
controlled by the system where images and other electronic records and files areto be stored, both on a tem~l~ry basis (prior to certification) and a permanent
basis (after certification).
Information created during the set-up of cabinets includes the purpose; DOS
path used by the system to locate stored information; and the amount of storage
rem~ining before the system issues a warning message that the cabinet is nearly
full. A cabinet in which information has been stored may not be deleted from thesystem until all stored information has been transferred or purged.
Bullets:
Bullets are set up for case types within this function. A group of icons is
available to the Records Manager, who assigns bullet icon status flags to specific
case types and assigns a name to the bullet annotation. Other propellies of the
bullet (e.g., the bullet may be assigned at case level or image level, bullet name
may be displayed over images to which the bullet is attached, etc.) are defined at
this time also. A bullet icon may not be attached to an image or case within a
specific case type unless it has been previously set up by the Records Manager.
System Utilities
In addition to the main four functions, a number of utilities are available
in the present system, either from within some functions or from the Main Menu.
These include:
~53~ 21S~92~
Send A Message
The mess~ging utility is available to be run from the Main Menu. Send a
message can be used to send messages to an individual user queue or to the
general queue for workgroup h~ndlin~.
System Integrity
This function is the same as that run automatically when users sign on to
any of the four main functions. System integrity is checked and logged, except
that results are printed as well as logged for audit purposes.
Run System Backup
Access to this function is restricted. When this function is acces~ed, the
system prepares to run the ILM backup at the pre-selected date, time and
frequency.
Run System Restore
Access to this function is restricted. When this function is executed, it
begins an immediate rebuild of the ILM dat~h~ce, into which data is restored from
a defined, prior d~t~b~ce backup. This function is used to resolve d~t~b~e
problems and purges all existing d~t~b~se information.
General Oueue
This function allows a user to access the general message queue. Messages
sent to this queue may be ~-cçssed by authorized users, who may "assign" a
message to their own queue for handling. This queue may be used for ~signmlont
of case work within a group performing the same work tasks.
Search Utility
The facility, which may also be ~cces~ed from within the retrieval function,
allows a user to enter one of two search criteria fields and search the ILM
.1~t~b~e, either within a case type or across all case types within the system. The
resulting list is displayed and may be printed, if necçs~ry.
Import Utility
This utility allows a user to select electronic files to which he has access
and to send the files to the scan application for importation and filing.
-54- 215192~
-
There has been disclosed a system which meets the objectives first
described. Other variations and embodiments may come to mind from a careful
reading and study of the system description and drawings. The present invention
should only be considered to be limited in scope by the claims which follow.
