US 6,185,576 B2Grant
Defining a uniform subject classification system incorporating document management/records retention functions
Issue Date:2001-02-06
•10 Claims
•42 Drawing Sheets
Abstract
An interlingual mechanism to achieve uniformity when classifying anything by subject. Using generic terminology in an especially oriented hierarchical structure, it directs the user to a single classification. The system captures acronyms, vernacular and industry-specific, as well as foreign terms, into a thesaurus that can be modified and appended as classification needs change. The system “learns” as synonyms are added to “family groups”, capturing differences in individual perception. Searching for an entity is quickly successful by reversing the process. To ask the system for the location of any item, a descriptive term is entered that the individual believes best describes the object in question. If this entry results in a “hit”, all information pertaining to the item is then available to query. If the entry term does not find a match in the generic structure, the system will search the synonym data base for a match. By arranging “generic terms” in a classified format, the system provides a single location for each record series and enables linking all relevant administrative document management functions and legal retention requirements. Selective and timely purging of documents is thus made possible, greatly facilitating the management of information for both current and prospective use.
Metadata
Inventor
- Lowrie McIntosh
Application Information
Application Number:US 09/176,394
Filing Date:1998-10-21
Priority Date:1996-09-23
Art Unit:7
Classifications
IPC:
G06F 1730
Field of Search:
707200707206705 2705 3
Patent Drawings (42 sheets)
Description
[0002] This application is a continuation of U.S. application Ser. No. 08/717,897, filed Sep. 23, 1996, now abandoned.
Background of the Invention
[0003] The exponential growth of information within an enterprise which is stored in individual document form has created a need for a reliable mechanism to purge individual documents when no longer legally or otherwise required, as well as locate them in an efficient manner.
[0004] In an age when the growth of information contained within documents has been exponential, a missing element is the ability to determine the proper life cycle for a document, and thus, make it possible for the document to be purged on a scheduled basis. However, to safely accomplish this purging process, a document management system typically requires that a significant amount of detail be stored with the document.
[0005] Since all retention scheduling is based on the subject matter of a document, it is essential that the system identify the subject matter of all documents in a consistent manner. Additionally, the terms used to identify the subject matter must conform to the terms used in legislation to identify documents as well as the terminology in current use within the enterprise.
[0006] The present invention provides a reliable mechanism to accomplish this task.
[0007] In systems having this capability, the “type” of document must also be determined. Different types of documents within the same subject matter area may have different retention requirements. The system must be able to determine the type of document at the outset. This “type” information specifies whether a particular document is “official” or “informational” and whether it is also “vital” or “sensitive.” The type of document determines the level of protection afforded and has a direct impact on determining the life-cycle of the document. Additionally, document type impacts the decision as to the media selected to store it, whether electronic, paper or film.
[0008] Official documents are those documents identified in a retention schedule as having either administrative or legislative retention requirements. Properly, only official documents are subject to archiving.
[0009] Informational documents (largely copies) have their own destruction schedule based on need. They are not archived and their life cycle must not exceed official documents of the same subject. They are destroyed at the office level when their usefulness is over. Normally, informational documents have a substantially shorter life-cycle than official documents pertaining to the same subject.
[0010] Vital documents are those that are absolutely essential to the conduct of the enterprise and whose loss would be hugely expensive or would irrefutably damage continued operations.
[0011] Sensitive documents contain, for example:
[0012] 1. Personnel information which provides confidential data.
[0013] 2. Information that in the hands of a competitor could be used to embarrass or cast a bad image on the enterprise with its customers or the public.
[0014] 3. Marketing, product development or corporate changes that could sabotage effectiveness.
Summary of the Invention
[0015] A system is disclosed for providing a true interlingual mechanism to achieve uniformity when classifying documents by subject to assist in the management, complying with retention requirements and long term storage of documents of an organization. In this connection, as used herein, the term document includes, without limitation, the hard copy and digitally stored version of the output of a computer program such as a wordprocessor, microfilm or microfiche, correspondence of all types and office folders which themselves may contain documents. Although not a document by this definition, objects such as furniture and the like may also be classified by creating a label (in this case, the document) which contains all of the relevant classification information for the object. Using generic terminology in a hierarchical structure, use of the system directs a user of the system to a single classification for any document. The system captures acronyms, vernacular and industry specific terms, as well as foreign terms, into a thesaurus that can be modified and appended as classification needs change. The system learns as synonyms are added to the hierarchical structure capturing differences in individual perception.
[0016] Legislative terminology describes document retention requirements by subject. In this connection, two major issues exist:
[0017] 1. Documents whose retention is covered by legislative requirements must be retained a prescribed period of time, after a certain event takes place, e.g., after an audit is completed, when the document is superseded, when its purpose has been completed (such as a contract) and for certain corporate documents).
[0018] 2. Legal penalties exist, including fines, where purging of documents occurs before their legal requirements have been met. On the other hand, retaining documents longer than their legal requirement can have both a “sword and a shield” effect where litigation is concerned.
[0019] With billions of documents being filed every day, the volume of documents subject to legislative retention offer additional justification for a system that makes retrieval inexpensive and predictable. Current practices involving the classification of documents make it difficult to identify documents by subject. However, retention legislation identifies documents by subject.
[0020] Accordingly, all documents must be identified by subject and ultimately destroyed consistently with the enterprise's official retention schedule.
[0021] In most cases legislation is silent as to the specific media to be used to “house” a document, This means that legislative retention requirements apply to all media. For example, if the paper document is destroyed and it continues to exist on magnetic media, the retention schedule is not effective and is not being enforced. This invention provides a reliable structure to accomplish compliance with all legislative retention requirements.
[0022] In addition to classifying documents to ensure compliance with legislatively or other required retention schedules, as a bi-product, the invention includes the capability of searching for the location of a particular document. To use the system for the location of any particular document, a descriptive term is entered at a query prompt that the user believes best describes the subject matter of the document in question. If this entry results in a hit, all information pertaining to the document is then available to query. An example of a screen display in which such a query may be made is shown in FIG. 3. For example, entry of a descriptive term produces a particular subject classification (i.e., a class code as described below).
[0023] For a typical user, there is just a small set of documents within his or her responsibility. Thus, once within this relatively small set of documents, if only those assigned a particular class code are deemed to be “hits,” the user is able to easily select the correct document from the set of hits. For users whose responsibility includes a large set of documents such that it would not be feasible to select a desired document from a list of documents assigned a particular class code hit list, a full range of attribute filters would be available to narrow the hits. Examples of such attribute filters include location (physical location such as file cabinet or work station), acronym (class codes, alpha and/or numeric references, i.e., form numbers, department IDs), organizational unit (cost center number, department number), subject description (i.e., class code), label description (e.g., three line description for a particular tangible asset as shown in FIG. 1. If the entry term does not find a match in the hierarchical structure, the system will search a synonym database for a match. If the search of the synonym database also does not yield the desired document, it must be concluded that the desired document has not been classified.
[0024] By arranging terms from the general to the specific in a consistent classification format, the system is able to specify a physical location for a hard copy of a document by office, box, draw and folder, or of a document on magnetic or similar media by diskette location, hard disk drive location (i.e., computer) or network drive location (i.e., server) and file name. In this manner, for each document within a set of records, linking all relevant administrative document management functions and legal retention requirements for each document classified in the system is possible.
[0025] Selective and timely purging of documents is thus made possible, greatly facilitating the management of information for both current and prospective use.
Brief Description of the Drawings
[0026] FIG. 1 is a screen display showing a query screen for performing a search.
[0027] FIG. 2 is a screen display showing a list of synonyms.
[0028] FIG. 3 is a screen display showing a query screen for performing a search.
[0029] FIG. 4 is a screen display showing the results of a query of the type shown in FIG. 3.
[0030] FIG. 5 is a screen display showing a query screen for performing a search.
[0031] FIG. 6 is a screen display showing the results of a query of the type shown in FIG. 5.
[0032] FIG. 7 is a screen display showing the results of a query of the type shown in FIG. 5.
[0033] FIG. 8 is a block diagram showing a high level view of the functions performed by the invented system.
[0034] FIG. 9 is a block diagram showing the store documents function.
[0035] FIG. 10 is a block diagram showing the maintain inventory function.
[0036] FIG. 11 is a block diagram showing the maintain system function.
[0037] FIG. 12 shows the layout for the entity relationship diagram shown in FIGS. 12A-12F.
[0038] FIGS. 12A-12C show the first row of Figures forming the entity relationship diagram.
[0039] FIGS. 12D-12F show the second row of Figures forming the entity relationship diagram.
[0040] FIG. 13 shows the layout for the logical database model shown in FIGS. 13A-13L.
[0041] FIGS. 13A-13D show the first row of Figures forming the logical database model.
[0042] FIGS. 13E-13H show the second row of Figures forming the logical database model.
[0043] FIGS. 13I-13L show the third row of Figures forming the logical database model.
[0044] FIG. 14 shows the layout for the physical database model shown in FIGS. 14A-14L.
[0045] FIGS. 14A-14D show the first row of Figures forming the physical database model.
[0046] FIGS. 14E-14H show the second row of Figures forming the physical database model.
[0047] FIGS. 14I-14L show the third row of Figures forming the physical database model.
Detailed Description of the Invention
[0048] This invention is a computer based system which provides a reliable structure to properly identify and track documents used by an enterprise throughout their life cycle to provide an efficient and easy to use mechanism to ensure that document retention requirements are complied with while enabling the orderly destruction of documents once their retention requirements have been satisfied.
[0049] In order to meet all the requirements of a document management system, it is necessary to develop a technique for classifying documents by subject. For this reason, the requirements of a document management system are more disciplined than any other component of an information resource management environment. One particular component is a detail tracking mechanism that must be in place to know where each document is and how many copies exist so that they all may be destroyed according to schedule.
[0050] Schedules must be rigorously followed. If the documents in question have to do with a litigation, the court in which the litigation is pending will test to determine if a true schedule exists and if records are destroyed in accordance with the schedule. If a true retention schedule does not exist, the company can be sanctioned for destroying records related to the case. The source of protection, and limiting exposure, lies within a disciplined document management program and enforcement of document retention policies covering all media.
[0051] Classification is performed when the document is created. There are a number of reasons for developing software that makes retrieval easier and control and tracking a bi-product of the processing which of necessity is already being performed. One factor which leads to performing document classification at document creation is placing the responsibility for classifying the document on the individual creating the document. The individual creating the document is in the best position to provide its proper classification. The time it takes to learn proper classifications for the subject areas involved for the normal user is relatively short, typically a matter of hours. This small investment in time substantially reduces the time required for searches to locate documents for retention schedule compliance and for retrieval. Learning to classify at the time a document is “saved” enables the use of the same procedure when a search needs to be performed.
[0052] Almost all search engines in use today rely on various mechanical techniques and sophisticated algorithms to find documents that have been saved by an author using “on-the-fly” techniques for classifying. This invention provides a mechanism for the author/creator of the document to classify the document properly, and, in such a form that anyone searching for the document would, following the same sequence, find the document with ease. This makes investing a small amount of time on the “save” side important because it makes the search time much more productive and far quicker than prior art approaches.
[0053] The selection of terms and what are referred to as classes used in a hierarchical structure to classify documents must be of the most generic form possible. Terms used in each class, i.e., Major, Primary, Secondary, Tertiary and Quaternary, requires that each word has a relative relationship and the same value level as any other word in that grouping. In order to simplify the subject description, where possible, the first two letters of the word used in each level of hierarchy is selected as its acronym.
[0054] In a very short period of time, the acronyms become easily translatable as the individual users have an opportunity to work with the system. This ease of learning is more easily understood since the range of subjects in use by a predominance of users is limited to a very small number, usually between 10 and 15 classes. Rarely does anyone using a typical work station require global searches, i.e., searches extending through multiple organizational units. Such searches would require special security clearance and a substantial knowledge of system navigation.
[0055] The invention also employs the intelligent use of synonyms, i.e., a synonym database, as pointers. Synonyms are used to direct the user to the “official” term for the appropriate classification. To populate the synonym database, a document inventory is taken to collect the local terms being used to describe documents. It should be noted that a detailed inventory of document descriptions currently existing (i.e., prior to implementation of the invention) is not needed. However, when a system implementing the invention is initially used, it is preferable that there be some inventory of terms (synonyms) in use be available to the new users of the system to improve acceptance of the system and productivity. This inventory or synonym database can be created manually, i.e., by manual entry as part of the Browse Synonym function shown in FIG. 9. The synonym database contains all or a subset of terms in use by the organization to refer to a particular document instead of the “official” term used to classify that document. A screen display used for this purpose is shown in FIG. 2.
[0056] Synonyms are assigned to each level of the hierarchy. This enables anyone to use a term that they perceive is related to the subject matter and be directed to a unique official classification.
[0057] There should be only one location in the hierarchy for any document. If it appears that there is more than one location, it generally means that the selected classification is not as precise as it should be, and it is likely that an additional classification should be added.
[0058] One of the most important strengths of using a synonym database to link the elements of the hierarchy is that it makes possible the use of local vernacular. Changes to the hierarchy are rare, leaving its structure stable. Almost all changes can be easily accomplished through changes in synonyms.
[0059] Because of the global scope of this invention, such as its use on the Internet, the use of foreign language terms in the synonym database makes it possible for the system to uniformly classify documents (as well as any other item) using any language throughout the world. With this range of flexibility, a unique classification tool exists for any multi-national information system.
[0060] One of the important aspects of this invention relates to its record retention components which create a records retention linkage. This includes tracking and providing a direct linkage to the terminology used in the U.S. Code of Federal Regulations and to similar legislative retention requirements of any other country. In addition to identifying the media, it also catalogs the type of record.
[0061] The document type determines the essential security requirements for these documents.
[0062] Use of the invention provides a system that ensures uniformity by all users when classifying documents by subject, i.e., a uniform subject classification system. This invention provides a hierarchically structured, subject oriented database, populated with terms in current use by the enterprise (i.e., chart of accounts and organizational chart) and by legislative references which pertain to the retention of documents. A typical set of class codes names with class code acronyms in a uniform subject classification is shown in Table II.
[0063] When a document is “saved,” as on a magnetic media, or simply classified manually as in hardcopy documents, the system provides classification tools that enable the process to “find” the single proper classification in the hierarchy.
[0064] The “search” process is the reverse, where the search word (subject description) is entered into the system and the classification tools lead the user to the proper classification and then to the document being sought.
[0065] Supplemental databases containing synonyms are available for each line of the classification scheme. These databases can be added to by the user and in this way translate acronyms, local vernacular, abbreviations and foreign terms that reveal the user's perception of the subject being sought.
[0066] Associated with all documents belonging to the same subject (referred to as a “File Series”) are a body of particular attributes set forth by legislative or informational requirements.
[0067] The invention provides a tracking mechanism to enable protecting, finding and retrieving a document, or group of documents (file series) when needed and to ultimately locate and destroy them when their life-cycle has been completed, as specified by an official retention schedule.
[0068] Using The Uniform Subject Classification System
[0069] I. Build A Classification Structure:
[0070] Select terms from legislative, business government and other industry sources. Adapt terms used in the Code of Federal Regulations, state statutes and terms that are industry specific. Organize selected terms into hierarchical order, i.e., primary class and sub-classes (i.e., secondary, tertiary, etc.).
[0071] II. Apply Synonyms To The Classification Structure
[0072] Assemble synonyms into a thesaurus and connect the synonyms with a particular file series (i.e., a line in the class hierarchy).
[0073] Build a database of local vernacular, acronyms, technical terms, etc.
[0074] Organize the database into the classification structure built in step I, appending to the synonym database, as appropriate.
[0075] Modify major classes, primary classes, secondary classes, etc. as required to fit the working environment.
[0076] III. Classify Documents
[0077] Determine major classes, e.g.,: Accounting, Administration, Finance, Marketing, Corporate, Legal, Engineering, etc. Major classes should be by functional class, not organizational names.
[0078] Using the first two characters in the class description, assign functional descriptions from the general to the specific, under the selected major class, then do the same thing for the selected primary class, secondary class, etc., until no further delineation is needed to classify all documents of interest. In most cases, no more than tertiary or quaternary classes are needed. For example, a document containing “Employee Expense Accounts” would be classified as follows:
[0079] AC Accounting (MAJOR)
[0080] PA Payables (PRIMARY)
[0081] EM Employee (SECONDARY)
[0082] which results in the Uniform Subject Classification Code:
[0083] ACPAEM ACCOUNTING, PAYABLES, EMPLOYEE
[0084] Depending on need, class levels can be adjusted to fit local conditions.
[0085] With the above class levels, the following are examples of acronyms which could be employed:
[0086] ADFAOF Administration, Facilities, Offices
[0087] ADFAOFFU Administration, Facilities, Offices, Furnishings
[0088] ADFUDE Administration, Furnishings, Desk
[0089] ADFUAR Administration, Furnishings, Art
[0090] The particular acronym which would be employed in any given situation would depend on how many levels are needed to identify particular items of interest so that they can be efficiently retrieved. For example, in some situations just two or three levels are sufficient because the number of items which are classified at that level of detail is sufficiently small such that a user can see on a single screen display all potential hits from which the desired item may be selected. In other situations, more levels may be needed where there are numerous items that satisfy a particular class code.
[0091] In these examples, the document would be a label affixed to the artwork or the desk. Such labels may also be affixed to a document or folder or box containing documents and/or folders. Additional data appearing on the label, referred to as “label lines,” providing specific descriptions beyond the class itself. Label line descriptions are extensions of the class code and are searchable using well known automated search techniques. Labels are a part of the record when attached with the same retention value as the record which normally is then case when the label is associated with a particular folder. It should be noted that labels do not have a retention value when attached to an asset such as a desk.
[0092] IV: Finding Documents using the Uniform Subject Classification System
[0093] To illustrate this step, assume that it is desired to find job descriptions for an employee's new assignment as Budget Analyst, a newly created position.
[0094] To determine what may be available to aid in the creation of a new job description, enter the term “job description” in an inventory label search field to determine the location for all Job Descriptions. In this connection, the label search field is part of a query screen display, an example of which is shown in FIG. 1.
[0095] A typical response to the query provides the acronym of “HRJD”, or “Human Resources, Job Descriptions” as shown in the screen display of FIG. 3.
[0096] Next, assuming that any job description for an Analyst would help in creating the new job description, a search on the word “Analyst” within the “HRJD” segment of the hierarchy displays “HRJDSA” for job descriptions related to a range of Systems Analysts positions as shown in the screen display of FIG. 4 and “HRJDMA” for job description of a Marketing Analyst also shown in the screen display of FIG. 4.
[0097] Next, search for job descriptions that are involved with the budgeting process to identify the terms used in describing the tasks and skills required:
[0098] Enter the word “budget” as shown in the screen display of FIG. 5.
[0099] With full security clearance, the system would return:
[0100] “FIBU” or Finance, Budgets.
[0101] as shown in the screen display of FIG. 6.
[0102] From the synonym table, the display would show the contents of the class table for the item located by the search as containing:
[0103] “HRD” or “Human Resources, Job Description”
[0104] as shown in the screen display of FIG. 4.
[0105] From the synonym table, a display would show the “folder” contents as containing a job description for “Manager, Budget Planning ” as shown in the screen display of FIG. 7.
[0106] By inspection, the searcher would select the analyst job descriptions as well as the one for “Manager” that might help in preparing the new description.
[0107] V. Associate The Class Acronym With Retention Data
[0108] Once steps I-III have been performed, it is possible to generate a report for each classification with the information shown in Table I. The information in the Med Typ, Rec Typ, Start After, Off Ret and RC Ret columns is initialized for each new document added to the system based on the class code. That is, for each class code, this information is stored in a class table and is predetermined based on business and government regulations. The information in the RCopy CC4 column is obtained from a location table and is preset with a location code based on the workstation from which the data for the record was entered. By changed the data in the class table or location table, all documents associated with that class code or location would be changed as well. However, all of this information can be changed for individual documents, and once changed for a particular document, changes at the class table or location table level are not reflected in the records for such documents.
[0109] In Table I, each row corresponds to a file series.
[0110] The column labeled “No.” contains a unique computer generated numbers used to represent each file series.
[0111] The column labeled “Class Acronym ” contains the classification acronyms.
[0112] The column labeled “Class Code Name” contains the official terms to describe documents.
[0113] The column labeled “Med Typ” represents media type, i.e., paper, magnetic, microfiche, etc. Each media type in the example is represented by a number, for example, 0 for paper, 1 for magnetic, 2 for microfilm, 3 for microfiche, 4 for CD-ROM.
[0114] The column labeled “Rec Typ” represents record type, i.e., Vital (V), Informational (I), Official (O), Sensitive (S).
[0115] The column labeled Start After contains the date starting the retention, e.g., annual review (AR), completed (CT), superseded (SU), current year (CY) and final audit (FA). The retention start date marks the beginning of the “clock” as related to “upon the completion of the audit” when the record is superseded, or beginning when the contract has been completed, or when a license has expired. As a result, the creation date has little relevance to the legislative requirement for retention.
[0116] The column labeled “Off Ret” represents office retention in months.
[0117] The column labeled “RC Ret” represents records center retention in months.
[0118] The column labeled “RCopy CC#” represents record responsibility copy cost center number. This is the cost center number as identified in the Chart-of-Accounts for the organization. This cost center is the only cost center which can send documents in this file series to a long term storage facility (for archival). All other holders of copies of such documents (i.e., informational copies) would have been instructed to destroy such copies at the office level according to a predefined schedule for destruction of such documents, which as previously noted, would predate scheduled destruction of the official copy of the document. An expanded example of a retention schedule appears in Table II.
[0119] VI. Purge Documents Selectively And Within Legal And Administratively Defined Requirements
[0120] Using predetermined life-cycles (retention schedules) for each file series, the system identifies documents subject to purging.
[0121] The system automatically identifies the “owner” of the document and the location of all copies, both Official and Informational. Such ownership is determined by virtue of the ownership of the file series of the document which in turn is determined by the functional responsibility of the cost center in the Chart-of-Accounts (organizationally). As noted above, the system captures the location and the cost center when the user “saves” a created (or modified) document based on information in the class table and location table.
[0122] By use of the system a report may be produced identifying the selected document's key attributes allowing the “owner” to review the document and authorize the purge process, or any other access to or modification of a file series and records in the file series.
[0123] The above described system may be implemented entirely in software as described below.
[0124] Design Details
[0125] The following is a description of an implementation of an Electronic Records System (ERS) according to the present invention as a computer program designed to assist in the management and long term storage of an organization's documents.
[0126] Overview
[0127] ERS is a client/server application to assist in the management of valuable corporate information.
[0128] ERS maintains a record retention schedule detailing how information ought to be stored, where, and for how long.
[0129] The application helps the user classify documents into groups of similar information.
[0130] ERS provides document security. It can prevent unauthorized reading of or writing to official corporate information.
[0131] ERS provides a means to search for documents pertaining to a specific subject, date range, author, etc.
[0132] The system acts as a pointer to direct users to where information is stored.
[0133] Definition of User Community
[0134] The ERS application has four categories of user. Each group of users and their responsibilities are described below.
[0135] Records Manager
[0136] The Records Manager is responsible for the overall performance of the system. The manager has the greatest amount of authority and access. The responsibilities of the Records Manager are the following:
[0137] Sets policy for record storage. This policy includes what media to use for long term storage.
[0138] Creates new classes and maintains the retention schedule.
[0139] Monitors the performance of the entire application.
[0140] Re-classifies documents that have been mis-classified.
[0141] Information Services
[0142] The Data Processing, Management Information Systems, or the Information Services organization plays a role in the management of documents. Their responsibilities are defined below:
[0143] Under the direction of the Records Manager, move documents from one media to another. For example, Information Services will be responsible for moving documents from disk to tape or microfiche.
[0144] Also Information Services will be responsible for moving documents from one location to another. Movement of records will apply to only those media they deal with (Tapes, microfiche, etc.).
[0145] Information Services will be responsible for maintaining the technical environment. This includes setting up databases, insuring that all users and servers are configured properly, etc.
[0146] Department Coordinator
[0147] The Department Coordinator is sometimes referred to as a ‘Super User’. They have more authority and system access than a normal user, but less than the Records Manager. The responsibilities of the Department Coordinator are the following:
[0148] Provide training and technical support to users within the department.
[0149] Monitors the performance of the system regarding departmental records.
[0150] Creates and sets up new users.
[0151] Enforces record retention policy for official records created by the department.
[0152] Manages the logistics of moving records to and from a storage facility.
[0153] User
[0154] The majority of individuals accessing the system will be categorized as users. Their responsibilities are listed below:
[0155] Properly classifies records they create.
[0156] Enforces record retention policy for informational records created by them.
[0157] Policies
[0158] There are a number of office policies and procedure that need to be followed in order for ERS to be a successful application. Some of these policies are documented below.
[0159] Users and Class Assignments
[0160] Any user can assign any class to a document. They will not be prevented by the ERS application from assigning classes outside their area of the organization. However, audit reports will be made available to the Departmental Coordinators and Records Manager to help insure that classes are being used properly.
[0161] No Class Attribute Overrides
[0162] Each class has attributes. There attributes are retention period, record type (official, informational), sensitivity, and vital flag, etc. Users can not override these values with their own when storing a document. If they need different attribute values than what is associated with a given class, then they should contact the Record Manager. The Record Manager may then create a sub class having the attribute values desired by the user.
[0163] Classification Owner
[0164] There will be one cost center that owns each classification. A classification will no be the responsibility of two or more cost centers. The cost center the owns a classification is responsible for all the documents that have been assigned to that classification. The cost center must insure that the inventory of documents is correct and properly maintained.
[0165] Location and Class Assignment
[0166] If a document is assigned a classification at the major level, then it can not be located in any archive facility. For example, if a document is classified as ‘AC’ for accounting, then it can not be stored at a off site storage facility. If the same document was classified as ‘ACAP’ for accounting, accounts payable, then it could be stored at a warehouse.
[0167] One Production Database Per User
[0168] A user can have access to several ERS databases. One for production work and one database for training, for example. However, no user will have write access to two production databases. There will be no support for across production database searches.
[0169] System Functions
[0170] All the capabilities of the system can be described as functions. Functions fall into five types. They are reports, updates, inquires, interfaces, utilities. These functions are described below by the group of user who will access them.
[0171] User Functions
[0172] All individuals who have access to the system will be able to operate the functions defined as follows:
[0173] Application Package File Open Function
[0174] From a word processing, spreadsheet, or presentation software package, a user will be able to pull down the package's File menu and activate the Open menu item. This will access ERS, automatically. The features of this function are described below.
[0175] Search and Retrieve Feature
[0176] The user will have the ability to retrieve and open a document by searching for its classification, synonym, or other attributes such as author, title, and/or date. If multiple documents are found that satisfy the users search criteria, a list of these documents will be displayed for the user to pick from. The documents being searched may be found on the users hard drive, shared network drive, or archive facility (Mezzanine).
[0177] Application Package File Save Function
[0178] From a word processing, spreadsheet, or presentation software package, a user will be able to pull down the package's File menu and activate the Save or Save As menu items. This will access ERS, automatically. The features of this function are described below.
[0179] Document Storage Feature
[0180] The users will have the ability to store at document on their hard drives, shared network drives, or archive facility (Mezzanine). Regardless of where the user stores the document, they will have the ability to manage their documents with ERS classifications and synonyms.
[0181] Classification Assignment Feature
[0182] Users will be able to assign any classification directly to the document. Or, users can select a corporate synonym (official term or keyword) to be applied to the document. Behind the scenes, ERS will assign the classification associated with the corporate synonym to the document. Also, the user may wish to assign one of their own synonyms to the document. ERS will automatically translate from the user's synonym to the appropriate corporate synonym and assign the classification to the document.
[0183] Synonym Maintenance Feature
[0184] Users will have the ability to add, change, or delete their own synonyms. They may create synonyms different than the corporate synonyms. However, user created synonyms must be related to corporate synonyms. User synonyms will be children of a corporate synonym.
[0185] Attribute Maintenance Feature
[0186] When saving a document, a user will have the ability to store other attributes about the document. These attributes are title, subject, author, date created, etc.
[0187] Stand Alone ERS User Functions
[0188] Not all the functions the user needs can be accessed via an application package such as Microsoft Word. There will need to be a stand alone ERS application (.EXE) the user can run. The functions contained within this facility are described below.
[0189] Update Functions
[0190] Inquiry Functions
[0191] Reporting Functions
[0192] Department Coordinator Functions
[0193] The Department Coordinator would have access to the same functions as the normal user. However, in their stand alone ERS application they would access to these additional functions.
[0194] Update Functions
[0195] Reporting Functions
[0196] Information Services Functions
[0197] The Information Services organization needs some of the same functions of the Department Coordinator, but not all. Information Services needs to be able to maintain inventory locations and media. They will also need the same inventory reports and media life reports available to the Department Coordinator. In addition, the following functions would be available to only Information Services users.
[0198] Update Functions
[0199] There are several update functions that only Information Services personnel would use. These functions are described below.
[0200] Batch Functions
[0201] The following functions are intended to run once a day in the evening hours. The overall purpose of these functions is to keep the various ERS servers in sync with one another and healthy.
[0202] Records Manager Functions
[0203] The Records Manager would have access to all the functions available to the normal user and the Department Coordinator. However, the Records Manager would have access to the following additional functions in their stand alone ERS application.
[0204] Update Functions
[0205] Reporting Functions
[0206] Catalog of Functions
[0207] The purpose of the catalog of functions is to display a summarized list of all the update and reporting capabilities of the system by type, subject, name, and description.
[0208] Generic Description of All Function and Features
[0209] The purpose of this section of the document is to describe, in a generic fashion, what the system will be able to do. This section defines the functions and features of the application.
[0210] Any system is made up of functions. Functions are software that produce menus, reports, updates, interfaces, and utility activities. Features are the capabilities of each function. For example, reporting functions have the capability to output their information to the screen, the printer, or to an extract file for easy entry into a spread sheet. These output routing capabilities are all features of a reporting function.
[0211] Menu Functions
[0212] The purpose of menus is to provide access to all other functions of the system. Pull down menus are placed at the top of each window. The features of all menus are described below:
[0213] Function Access All menus will provide access to the various functions of the system. An example of the pull down menus and their options would be the following:
[0214] Reporting Functions
[0215] Reports are functions used to output information. Reporting functions can produce output in tabular listings, graphs, or spread sheets formats. This output can be sent to the screen, a printer, or a file directory. The features of reporting functions are the following:
[0216] Update Functions
[0217] Update functions provide the ability to add, change, or delete records in the database. The features of update functions are the following:
[0218] Process Model
[0219] The purpose of a business process model is to show the relationship between people, systems, data, office policy and procedures, and documents.
[0220] Node Tree Diagrams
[0221] A component of a business process model is a node tree diagram. FIG. 8 shows the major activities associated with an application. FIGS. 9 through 11 show the node tree diagrams for ERS.
[0222] Database Design
[0223] The application will store its information in a set of relational tables. The total size of the database is expected to be approximately 500 Megs of disk space for a 300,000 inventory items. There will be roughly 1,200 total users, about 300 will be activity at any point in time.
[0224] Entity Definitions
[0225] The nature of each table in the database is described in the following entity definitions.
[0226] Entity Relationship Diagram
[0227] FIG. 12 is the entity relationship diagram. Its purpose is to provide a high level view of the database and its structure. The diagram shows each table in the system and how it relates to other tables. The solid lines between entities denotes identifying relationships. The dotted lines denotes non-identifying relationships.
[0228] Attribute Definitions
[0229] Following are the attribute definitions. Attributes are the columns that can be found in each entity or table within the database. The definitions are sorted by entity name and attribute name.
[0230] Logical View
[0231] FIG. 13 is a logical view of the database. It shows all the entities or tables and their attributes or columns. The purpose of this diagram is to provide a more detailed picture of the database and its contents.
[0232] Standard Abbreviations
[0233] The following lists the standard abbreviations for database object and column names. Several of these abbreviations will be merged together to derive a name. For example, the user tables will be named ‘tbl_usr’. The user's last name column will be called ‘lst_nme’.
[0234] Triggers
[0235] Triggers are business rules embedded in the database. These rules are activated every time a row is added, changed, or delete for a table. They can be used insure referential integrity, enforce security, and/or calculate values for columns. The triggers defined for this system are described below by table. Note, that referential integrity triggers are not listed. They are too numerous to display, but will be part of the application.
[0236] Class Table
[0237] Insert Trigger—Two rows should be added to the synonym table. The values for the synonym table are as follows:
[0238] When inserting a row into the class table, add two rows to the class synonym table. The values for the class synonym table should be the following:
[0239] Update Trigger—See if the class code is being changed. If it is, then update the synonym name in the synonym table and the synonym name in the class synonym table.
[0240] When updating a row in the class table, see if the class title is being changed. If it is, then update the synonym name in the synonym table and the synonym name in the class synonym table.
[0241] When updating a row in the class table, see if the parent classification identification is being changed. If it is, then update the parent synonym name in the synonym table.
[0242] Delete Trigger—Delete the corresponding rows in the synonym table and the class synonym table where the following is true:
[0243] Synonym name equals class code and user identification equals ‘SA’ or
[0244] Synonym name equals classification title and user identification equal ‘SA’
[0245] Function Table
[0246] Delete Trigger—Create a cascading delete that will remove the function form all other tables.
[0247] Update Trigger—If the function type is changed for ‘REPORT’ to something else, a search for the function column and function sort tables should be performed. If there are any rows in these tables, then they ought to be deleted.
[0248] Function Column Table
[0249] Insert Trigger—The function type column in the function table must be set to ‘REPORT’. If the function is not a report, then it should not have rows in the function column or sort table.
[0250] The relationship code can only have values of ‘EQUAL’, ‘LIKE’ or ‘BOTH’.
[0251] Also the column type values can only be ‘CHAR’, ‘INT’, ‘DATE’, and ‘FLOAT’.
[0252] Update Trigger—The relationship code can only have values of ‘EQUAL’, ‘LIKE’ or ‘BOTH’. Also the column type values can only be ‘CHAR’, ‘INT’, ‘DATE’, and ‘FLOAT’.
[0253] Function Sort Table
[0254] Insert Trigger—There can only be one row having a default sort flag value of ‘Y’ for yes for each function.
[0255] Update Trigger—There can only be one row having a default sort flag value of ‘Y’ for yes for each function.
[0256] Function Usage Table
[0257] Insert Trigger—The usage start date must be less than the usage end date.
[0258] Update Trigger—The usage start date must be less than the usage end date.
[0259] Location Table
[0260] Insert Trigger—If the level number for the location type is one, then the parent location identification equals the location identification. If the level number of the location type is not equal to one, then the parent location identification can not be equal to the location identification.
[0261] If the level number is not equal to one, then the level number must be equal to one minus the level number for the parent location.
[0262] Object Table
[0263] Insert Trigger—The object purpose can not be null if the object type code is ‘V’ for view.
[0264] Insert Trigger—The object purpose can not be null if the object type code is ‘V’ for view.
[0265] Object Identification Table
[0266] Insert Trigger—Insure that the object type column value in the object table is set to ‘U’ for user table.
[0267] Update Trigger—Insure that the object type column value in the object table is set to ‘U’ for user table.
[0268] Organization Table
[0269] Insert Trigger—If the level number for the organization type is one, then the parent organization identification equals the organization identification. If the level number of the organization type is not equal to one, then the parent organization identification can not be equal to the organization identification. If the level number is not equal to one, then the level number must be equal to one minus the level number for the parent organization.
[0270] Update Trigger—If the level number for the organization type is one, then the parent organization identification equals the organization identification. If the level number of the organization type is not equal to one, then the parent organization identification can not be equal to the organization identification. If the level number is not equal to one, then the level number must be equal to one minus the level number for the parent organization.
[0271] User Table
[0272] Insert Trigger—When inserting a new user, create rows for the user class table. Copy the user class rows for the person doing the inserting and place them into the user class table for the new user. The processing steps are:
[0273] Retrieve the user ID of the individual inserting a new row into the user table.
[0274] Take the user ID found in the previous step and read the user class table for the person doing the inserting. Retrieve their set of classifications and access codes.
[0275] Insert the classifications and access codes found in the previous step under the ID of the new user.
[0276] Ignore the processing describe above if the user doing the inserting is SA.
[0277] Delete Trigger—Create a cascading delete that will remove the user for all other tables.
[0278] User Class Table
[0279] Insert Table—There can only be one row having a default class flag value of ‘Y’ for yes for each user.
[0280] If an individual is inserting a new row into the user class table, then that individual must have read or write access to that same class. The new row can not have write access to the class if the individual doing the inserting only has read access. Ignore this logic if the person doing the inserting is SA.
[0281] Update Table—There can only be one row having a default class flag value of ‘Y’ for yes for each user.
[0282] If the access code is being changed from R=read to W=write then the individual making the change must have write access to that same class. Ignore this logic if the person doing the changing is SA.
[0283] User Database Table
[0284] Insert Trigger—There can only be one row having a default database flag value of ‘Y’ for yes for each user.
[0285] Update Trigger—There can only be one row having a default database flag value of ‘Y’ for yes for each user.
[0286] User Defined Datatypes
[0287] User defined datatypes are common formats that will be applied to columns. The attributes for each datatype in this system are listed below.
[0288] udt_integer
[0289] integer System generated identification numbers.
[0290] udt_ndt
[0291] varchar(40) Names, descriptions and titles 40 chars or less.
[0292] udt_name
[0293] char(20) First, Last Names, other names 20 chars or less.
[0294] udt_label
[0295] char(25) Labels.
[0296] udt_text
[0297] varchar(255) Long descriptions, text, explanations, summaries etc.
[0298] udt_identifier
[0299] char(20) Any type of database object identifier.
[0300] udt_yesno
[0301] char(1)Any yes/no column.
[0302] udt_phone
[0303] char(13) Full length phone number—Do not store dashes.
[0304] udt_code_a
[0305] char(1) Codes and other data of various lengths.
[0306] udt_code_b
[0307] char(2)
[0308] udt_code_c
[0309] char(6)
[0310] udt_code_d
[0311] char(8)
[0312] udt_code_e
[0313] char(10)
[0314] udt_code_f
[0315] char(12)
[0316] udt_code_g
[0317] char(15)
[0318] Physical Database Model
[0319] The physical database model displays all the SQL attributes about each column in the application. It is the combination of the logical view, abbreviations, triggers, and user defined datatypes. The physical database model is presented in FIG. 14.
[0320] Physical Attributes
[0321] The following table displays the SQL attributes (column name, datatype, null option, etc.) for each column being stored.
[0322] System Requirements
[0323] The purpose of this section of the document is to define the minimum hardware and software needed to run and maintain the application. This section is divided into three parts; Client Workstation, Developers Workstation, and Server. The requirements defined below assume that there are no other applications running on this equipment at the same time.
[0324] Client Workstation
[0325] The client workstation is the personal computer run by the average user. Its purpose is to create word processing documents, spreadsheets, presentations, and to run the ERS application.
[0326] Application Packages Microsoft Office containing Word, Excel, and PowerPoint.
[0327] Developer Workstation
[0328] The developer workstation is used to construct and maintain the application. It contains all the tools needed to modify the source code for the system.
[0329] Server
[0330] The server supports the user community and developers. It acts as the centralized storage point for the system's database and archived documents. The server should support two modems for remote access trouble shooting, demonstrations, and training sessions. The amount of disk space requested should be enough to support two versions of the database.
[0331] The production implementation of ERS will require one server. ERS will have 1,200 total users in one geographic location. 300 of the users will be active at any one point in time ERS is planned to be a 500 Meg database containing 300,000 inventory items.
[0332] Clarifications
[0333] The purpose of this section of the design document is to clearly state limitations of the system. The items listed below are not planned to be implemented in ERS at the present time. However, there is nothing preventing these functions or capabilities from being added to the application at a later date.
[0334] Ad Hoc Reporting
[0335] The menus within the ERS application will not provide access to any ad hoc reporting tools such as InfoMaker by PowerSoft or Microsoft Access.
[0336] Ad hoc reporting tools will not have access the ERS database. User passwords will be encrypted to prevent ad hoc tools from gaining access to the database.
[0337] ERS could be modified to bring up an ad hoc reporting tool from its menu some time in the future, if desired.
[0338] Multiple Databases
[0339] ERS will use only one database.
[0340] Only one database is needed. Based upon the size to the database (500 Megs.), the quantity of users(300 active users), and the location of the users (one building) can be supported on one server. For this reason, multiple databases will not be provided, nor will any across database functions be built.
[0341] As the application grows in quantity of users or locations, additional databases can be considered at a later date.
[0342] Archive Facility Management
[0343] ERS will track what documents are available and where.
[0344] ERS acts as the pointer to archive facilities. Some these documents will be stored in archive facilities such as off site warehouses or in Mezzanine.
[0345] ERS will not manage the operation of these archive facilities. It will not perform document check in and check out functions, or deliver the document to the user's workstation, for example. These functions will be the responsibility of the archive facility.
[0346] In this fashion there will be a division of labor. ERS can do what it is designed to best and the archive facilities can continue to perform what they do best.
[0347] Total Control Over All Corporate Information
[0348] ERS will not provide a fully automated means to enroll all of a corporation's information into a records management database. All information implies every eMail message, all application database transactions, telephone conversation, as well as electronic and hard copy documents.
[0349] ERS will not provide an interface into off site storage facility's information system. If the volume of information flowing between an office and a off site storage facility warrants it, an interface could be added later.
[0350] ERS will not provide an interface into eMail systems. The policies on the control and management of eMail messages needs to be established, first, before an interface can be considered.
[0351] ERS will provide a means to easily input hard copy documents, Microsoft Word documents, and Excel spreadsheets into a inventory and to classify these documents.
Claims
What is claimed is:
1. A computer implemented method for enabling individuals in an enterprise to uniformly classify documents comprising the steps of:
a) assigning to a document to be classified a class code selected from a set of predetermined class codes from a class database, each of said class codes representing a class, said class database arranged in a hierarchy of classes from general to specific utilizing a hierarchically structured methodology using terms in current use by the enterprise wherein at least one of said class codes has at least one associated synonym stored in a synonym database;
b) assigning a document type to said document;
c) assigning a retention period to each of said classes and each of said document types, said retention period being associated with its corresponding class and corresponding document type in said class database and determined by governmental requirements;
d) storing the class code and document type as part of a record in a document database.
2. The method defined by claim 1 wherein each of said class codes is selected from terms used in business and government.
3. The method defined by claim 1 wherein said document type is one of official, informational, vital and sensitive.
4. The method defined by claim 1 further comprising the steps of:
a) assigning to said document a media type and location;
b) storing the media type and location assigned to said document as part of said record in said document database.
5. The method defined by claim 1 further comprising the steps of:
a) searching said document database by class code and
b) generating a display showing matching records.
6. The method defined by claim 1 further comprising the steps of:
a) receiving a term as a search parameter; and
b) searching said document database using said search parameter by class code and generating a display showing records in said document database where said search parameter matches the class code, and if no matching records are found, searching said synonym database and generating a display showing records in said document database having a class code associated with a synonym which matches said search parameter.
7. The method defined by claim 1 wherein said synonym database is customizable at a user workstation for use by a user at said user workstation.
8. The method defined by claim 1 further comprising the step of:
assigning to a user a user access code based on said user's position within at least one of a chart of accounts and an organization chart.
9. The method defined by claim 8 further comprising the steps of:
a) assigning an organization name to said document;
b) comparing the class code and the organization name assigned to the document to the user's access code;
c) permitting the user access to said document if the class code and the organization name match the user's access code and preventing said user from accessing said document if the class code and the organization name do not match the user's access code.
10. The method defined by claim 1 wherein said document type serves as a modifier to the assigned class code.
Patent Citations (41)
| Patent | Date | Inventor | Cited By |
|---|---|---|---|
| US4276597 | 1981-06-01 | Dissly et al. | Applicant |
| US4542477 | 1985-09-01 | Noyori et al. | Applicant |
| US4674066 | 1987-06-01 | Kucera | Applicant |
| US4862408 | 1989-08-01 | Zamora | Applicant |
| US4879648 | 1989-11-01 | Cochran et al. | Applicant |
| US4899299 | 1990-02-01 | MacPhail | Applicant |
| US5018060 | 1991-05-01 | Gelb et al. | Applicant |
| US5051891 | 1991-09-01 | MacPhail | Applicant |
| US5056021 | 1991-10-01 | Auborn | Applicant |
| US5107419 | 1992-04-01 | MacPhail | Applicant |
| US5168565 | 1992-12-01 | Morita | Applicant |
| US5197005 | 1993-03-01 | Shwartz et al. | Applicant |
| US5201047 | 1993-04-01 | Maki et al. | Applicant |
| US5201048 | 1993-04-01 | Coulter et al. | Applicant |
| US5204812 | 1993-04-01 | Kasiraj et al. | Applicant |
| US5206949 | 1993-04-01 | Cochran et al. | Applicant |
| US5218696 | 1993-06-01 | Baird et al. | Applicant |
| US5229936 | 1993-07-01 | Decker et al. | Applicant |
| US5261103 | 1993-11-01 | Takeuchi et al. | Applicant |
| US5265065 | 1993-11-01 | Turtle | Applicant |
| US5274806 | 1993-12-01 | Hill | Applicant |
| US5297039 | 1994-03-01 | Kanaegami et al. | Applicant |
| US5299123 | 1994-03-01 | Wang et al. | Applicant |
| US5307266 | 1994-04-01 | Hayashi et al. | Applicant |
| US5369763 | 1994-11-01 | Biles | Applicant |
| US5404514 | 1995-04-01 | Kageneck et al. | Applicant |
| US5418946 | 1995-05-01 | Mori | Applicant |
| US5418948 | 1995-05-01 | Turtle | Applicant |
| US5418951 | 1995-05-01 | Damashek | Applicant |
| US5423034 | 1995-06-01 | Cohen-Levy et al. | Applicant |
| US5428778 | 1995-06-01 | Brookes | Applicant |
| US5454101 | 1995-09-01 | Mackay et al. | Applicant |
| US5463773 | 1995-10-01 | Sakakibara et al. | Applicant |
| US5469355 | 1995-11-01 | Tsuzuki | Applicant |
| US5530848 | 1996-06-01 | Gilbert et al. | Applicant |
| US5630125 | 1997-05-01 | Zellweger | Applicant |
| US5634051 | 1997-05-01 | Thomson | Applicant |
| US5634130 | 1997-05-01 | Lee | Applicant |
| US5649196 | 1997-07-01 | Woodhill et al. | Applicant |
| US5655130 | 1997-08-01 | Dodge et al. | Applicant |
| US5689699 | 1997-11-01 | Howell et al. | Applicant |
Non-Patent Literature (2)
- Skupsky, D.S., “Legal Requirements & Legal Considerations—the Basis for the Legal Records Retention Period,” Records Management Quarterly, v24, n2, Apr. 1990, pp. 32-36.Examiner
- Skupsky, D.S., “The Functional Records Retention Schedule—an Alternative that Works!,” Records Management Quarterly, v23, n4, Oct. 1989, pp. 37-43.Examiner