**Image File Wrapper (IFW)**

**Electronic Records Management (ERM)**

**Compliance Paper**

![](media/image1.png)

VERSION 13

Last updated on 7-01-03

(This page intentionally left blank.)

# Executive Summary {#executive-summary .unnumbered}

The USPTO's Image File Wrapper (IFW) Electronic Records Management (ERM)
Compliance Paper (Compliance Paper) is based on the Technical Standards
and Guidelines for Electronic Records Management (TSG-ERM), which was
duly adopted by the United States Patent and Trademark Office (USPTO;
also referred to as Office) as the standard to properly maintain
electronic records.

This document indicates the manner in which we have satisfied all the
requirements of the TSG-ERM for the data that is maintained by IFW. IFW
is a system that maintains electronic images of most documents that are
involved in the prosecution of patent applications.

The USPTO is in a position to convert all of its application files that
are currently in paper into an electronic format. The initiative to
convert paper files into electronic records is squarely within the
framework of the Government Paperwork Elimination Act and will lead to
improved efficiency within the USPTO. The USPTO can achieve this
initiative by using advanced scanning equipment and software that were
acquired from its European counterpart, the European Patent Office.

The advantages of having compact electronic records that are established
and maintained in standard industry formats are manifold: applications
can be viewed by multiple people at various locations, backup and
recovery of lost files can be assured, and parallel processing of
applications by USPTO employees in different locations at the same time
will speed up prosecution, to name a few.

To be truly effective, the records stored in IFW must be relied upon as
the official records. By the time a patent application document is
consulted during or after the prosecution of that application, the
originally submitted papers that were scanned into IFW will have been
long gone. They will have been packed in labeled boxes, organized only
by the date of receipt, and shipped off to off-site storage areas.
Perhaps, if paper documents had been scheduled for destruction, they
will not even be available in the off-site storage areas. Electronic
records are intended to be authoritative documents to be used and
accepted as the official records of the USPTO. The Office shall not be
put in a position where, in the normal course of business, those paper
submissions need to be consulted.

Pursuant to federal patent laws, the Office has the right to establish
procedures to process patent applications electronically. See 35 U.S.C.
2(b)(2)(C). The recent USPTO financial authorizing legislation at
Section 13103 requires "the Director to develop a user-friendly
electronic system for the filing and processing patent and trademark
applications. This electronic system must also allow examiners and
applicants to send all communications electronically, and should allow
the PTO to process, maintain, and search electronically the contents and
history of each application." (Public Law 107-273 (Nov. 2, 2002)).
Further, the Office is encouraged to move to electronic records by the
Government Paperwork Elimination Act (P.L. 195-277, Title XVII, Sec.
1707) and Executive Order A-130.

The Compliance Paper evaluates the electronic records in accordance with
the TSG-ERM with the intention that the electronic records of the
application files will be the official files of the Office.

**Table of Contents**

[**Executive Summary 3**](#executive-summary)

[1 INTRODUCTION 6](#introduction)

[1.1 General 6](#general)

[1.2 Goals 6](#goals)

[1.3 General Capabilities of IFW 6](#general-capabilities-of-ifw)

[1.3.1 Primary Functions 6](#primary-functions)

[1.3.2 File Storage and Handling Functions
7](#file-storage-and-handling-functions)

[1.4 IFW Prototype Assumptions
7](#ifw-prototype-and-production-starting-assumptions)

[1.5 Overview of the Record-keeping Systems
8](#overview-of-the-record-keeping-systems)

[2 Electronic Records Management Requirements
10](#electronic-records-management-requirements)

[2.1 Records Acquisition 10](#records-acquisition)

[2.1.1 Capture of Complete Electronic Records
10](#capture-of-complete-electronic-records)

[2.1.2 Capture Links to Notes and Annotations
12](#capture-links-to-notes-and-annotations)

[2.1.3 Capture Hyperlinks 13](#capture-hyperlinks)

[2.1.4 Working Files 13](#working-files)

[2.1.5 Conversion of Paper Records to Electronic Form
14](#conversion-of-paper-records-to-electronic-form)

[2.1.6 Quality Assurance and Quality Control
14](#quality-assurance-and-quality-control)

[2.1.6.1 Quality Control 15](#quality-control)

[2.1.6.2 Quality Assurance 18](#quality-assurance)

[2.1.7 Record Capture Audits 20](#record-capture-audits)

[2.2 Record Metadata 21](#record-metadata)

[2.2.1 Metadata Management 21](#metadata-management)

[2.2.1.1 Metadata Retention 21](#metadata-retention)

[2.2.1.2 Metadata Profiles 23](#metadata-profiles)

[2.2.1.3 Electronic Record Encapsulation
24](#electronic-record-encapsulation)

[2.2.2 Electronic Record Retrieval Profile Metadata
25](#electronic-record-retrieval-profile-metadata)

[2.3 File Management 30](#file-management)

[2.4 Preservation of Integrity 30](#preservation-of-integrity)

[2.4.1 Protect Against Alteration 31](#protect-against-alteration)

[2.4.2 Validate Integrity 32](#validate-integrity)

[2.5 Protection of Confidentiality 32](#protection-of-confidentiality)

[2.6 Access Controls and Authentication
34](#access-controls-and-authentication)

[2.7 Search, Retrieval, and Reproduction
38](#search-retrieval-and-reproduction)

[2.7.1 Search and Retrieval 38](#search-and-retrieval)

[2.7.2 Store Search Results 39](#store-search-results)

[2.7.3 Display/Print Record, Index, and Annotations
39](#displayprint-record-index-and-annotations)

[2.7.4 Applicant Access 41](#applicant-access)

[2.8 Audit Trail 44](#audit-trail)

[2.8.1 Use History Profile 44](#use-history-profile)

[2.8.2 Use History Profile Creation and Update
44](#use-history-profile-creation-and-update)

[2.8.3 Link to Other Information System Tracking or Event Logging
45](#link-to-other-information-system-tracking-or-event-logging)

[2.9 Vital Record Backup and Recovery
45](#vital-record-backup-and-recovery)

[2.10 Records Retention 46](#records-retention)

[2.10.1 Case File Retention 47](#case-file-retention)

[2.10.2 Retention Period 47](#retention-period)

[2.10.3 USPTO Case File Retention Schedules
47](#uspto-case-file-retention-schedules)

[2.10.4 Determine Retention Period 48](#determine-retention-period)

[2.10.5 Records to be Retained 49](#records-to-be-retained)

[2.10.6 Disposal 50](#disposal)

[2.10.7 Disposal of Working Files 54](#disposal-of-working-files)

[2.11 Migration 55](#migration)

[2.11.1 Copy, Reformat, and Transfer 55](#copy-reformat-and-transfer)

[2.11.2 Media Management 56](#media-management)

[2.12 Transfer to Archival Storage 56](#transfer-to-archival-storage)

[2.13 Records Hold 57](#records-hold)

[3 Glossary 59](#glossary)

[APPENDIX 1 - DRAFT MODEL OF QUALITY ASSURANCE AND QUALITY CONTROL
PROGRAM
60](#appendix-1---draft-model-of-quality-assurance-and-quality-control-program)

[APPENDIX 2 -- VERA DOCUMENT 61](#appendix-2-vera-document)

# INTRODUCTION

## General

As expressed in the executive summary, the Compliance Paper is based on
the USPTO Technical Standards and Guidelines for Electronic Records
Management (TSG-ERM). The purpose of the TSG-ERM is to define and
describe requirements and tasks to be completed for electronic records
management over the complete life cycle of an electronic record. The
resulting product required from the TSG-ERM is a checklist that
describes tasks to be done to support each of the electronic records
management requirement categories. These requirements are fulfilled in
various Automated Information System (AIS) life cycle phases, from the
concept phase through the operations phase.

Electronic records management involves all users of USPTO AISs. The
intended audience for the TSG-ERM is System Development Managers, System
Maintenance Managers, Project Managers, System Managers, Business Area
Record Stewards, Operational Record Stewards, and Technical Record
Stewards who are responsible for developing, testing, redesigning, or
enhancing a production AIS or infrastructure system to support the
electronic records management throughout the complete life cycle of an
electronic record.

The TSG-ERM was used to outline and detail electronic records management
requirements for IFW. This compliance paper also identifies areas that
IFW or another system will address in the future.

The appendix describes, at a high level, architecture for managing
archived electronic records.

## Goals

The goal of this document is to compare, section by section, the
requirements of the TSG-ERM with the design of IFW and conform to the
TSG-ERM.

IFW is being deployed in two major parts, a Prototype and Production.
Production should commence after procedures have been established for
activities that take place in the various parts of the Prototype. The
IFW Prototype began in November 2002 in two Technology Centers (2800 and
1600) and will involve three Group Art Units, (2824, 2827, and 1634).

As of June 30, 2003 the Office started the Production phase of the
project.

## General Capabilities of IFW 

### Primary Functions

**Central Scanning and Printing**

A central scanning facility will be established to handle scanning
requirements. Central Scanning and Printing will scan all application
image files and follow-on papers for both OIPE and the examining corps.
A central printing facility will be established to print outgoing
correspondence (from OIPE and the TCs) and working folders (for the
TCs). Central Scanning and Printing may be located in more than one
physical location; it is described as a "central" location because the
procedures for using the facility are the same for all and management is
envisioned under a single authority.

**Messaging**

IFW provides a messaging system that alerts users when an application
image file is available for processing by an individual or group.
Transfer of the processing responsibility for application image files is
accomplished by "releasing" the case file, which results in a
corresponding message to a new individual or group.

**Viewing**

The view capability provided in IFW is in an 8.5 x 11 format. However,
A4, letter-size, and legal-size paper will be accepted for scanning.

### File Storage and Handling Functions

**Application files**

Scanning contractors will maintain a separate storage area to store IFW
files. During the prototype, after scanning processes are completed,
original IFW application submissions and follow-on submissions will be
placed in paper file wrappers and maintained in a file room as the
official application file. In production, the post scanned source papers
are being boxed and stored in warehouses. The IFW images are the
official files. Header data in the IFW images allows the source paper to
be retrieved if a scanning issue is discovered. After a certain amount
of time, the source papers will be scheduled to be destroyed.

**Artifacts**

Artifacts will be stored in appropriate containers in a separate storage
area. Artifacts will be identified in IFW by scanned artifact sheets
that are created at the time artifacts are received at the USPTO.

**Working Folder**

A working folder is a paper copy of all or specified parts of IFW
application submissions. As and when requested by examiners, Central
Scanning and Printing will create one copy of each application, place
that copy in an appropriately marked folder (the working folder), and
forward that copy to the appropriate GAU. Examiners will store working
folders in their offices until a case is issued and they will be
responsible for destroying the working folder at appropriate times. (See
Section 3.18 in this document, Destruction of Working Folder.)

**Action Folder**

The assigned examiner or Legal Instrument Examiner (LIE) will create an
action folder at the same time they create an Office Action. The action
folder will be an appropriately marked folder that is used to transfer
file papers (other than application submissions) within the Office.
Documents that would be placed in an action folder are search results
and Office Actions that are to be signed, scanned, printed, or added to
the official paper file.

## IFW Prototype and Production Starting Assumptions

Assumptions will be modified as our experience with the system grows.

1.  National applications and international applications in the national
    stage are included in the IFW Prototype. Patent Law Treaty (PLT)
    applications and reexamination proceedings are excluded.

2.  IFW offers more than one level of access. OIPE, SPEs, examiners, and
    LIEs need access to all IFW capabilities during the IFW Prototype.

3.  Electronic File Wrapper (EFW or eDAN) development is expected to
    continue simultaneously with the IFW Prototype, leaving open the
    possibility that the EFW Graphical User Interface (GUI) and IFW may
    integrate in subsequent versions.

4.  High-speed printers (approximately 25) must be available for all
    examiners who are involved in the IFW Prototype.

5.  It is desirable for participating customers to "voluntarily comply"
    with new amendment and eIDS procedures during the IFW Prototype.

6.  IFW application submissions and all incoming and outgoing documents
    will be scanned and incorporated into the IFW image file.

7.  Only incoming non-patent literature (NPL) or Foreign Patents that
    are submitted with Information Disclosure Statements (IDSs) will be
    scanned.

8.  Artifact sheets will be prepared for items such as computer
    diskettes, videotapes, and models that cannot be scanned, in order
    to facilitate with the identification of these items. Artifact
    sheets will be scanned and incorporated into the IFW image file.
    Paper artifact sheets will be inserted into the official paper
    application file with the artifact and stored in a separate file
    room that is designated for IFW records only. Contractor staff will
    generate a message in IFW and send it to the assigned examiner or
    the assigned GAU with regards to each artifact.

9.  Priority documents (PDs) will be treated as artifacts and placed in
    the official paper application file in the file room that is
    designated for IFW records only. An artifact sheet will be completed
    and scanned for each priority document. Examiner access to PDs will
    be accomplished in the same manner as other artifacts, namely, by
    making specific requests.

10. Photographs will be treated as artifacts until the time that they
    can be properly scanned in color.

11. During the IFW Prototype, the paper file maintained by OIPE in the
    separate storage area is the official application file.

## Overview of the Record-keeping Systems

IFW image processing is not intended to be the ultimate record system
for the USPTO. Instead, it should be viewed as a waypoint in which paper
records are replaced with electronic images, with advantages as noted
above. Ultimately, the USPTO still intends to institute tagged character
coded records (i.e. XML), as required for submitting applications in the
Electronic Filing System (EFS). This waypoint, however, offers
attractive opportunities for the Office to establish electronic records
by using the simpler TIFF encoded images of the documents and gaining
experience in the issues surrounding these records.

IFW will provide a direct electronic analogy to the paper application
files of the Office. All records, as defined by 44 U.S.C. 3301, that are
created, received or used in the prosecution of patent applications that
are currently placed in the paper file wrapper, the USPTO's official
record, will be placed in the electronic analog, which is the IFW.

Thus, IFW is intended to house the complete set of
[original]{.underline} records that the Office currently stores.
Derivative information or indirect records, such as the status
information on the USPTO's PALM system, or most financial information
stored on the Office's RAM system, will not be in IFW. Derivative
information can be regenerated at any time from official IFW records,
since they currently can be derived from the paper records.

IFW will maintain the electronic images throughout the prosecution of
the applications, and unless otherwise decided, throughout the whole
period in which the USPTO is responsible for the records. Some of this
"maintenance" time will take place in the USPTO as an active file, and
then, in the USPTO file repository as an issued or abandoned application
file. After 40 years, the responsibility for the records shifts to the
National Archives and Records Administration (NARA), which requires that
the records be encapsulated and placed in a government facility that is
acceptable.

The USPTO is currently working with NARA to keep the electronic records
scheduled in a manner that is acceptable to them and suitable for
eventual transfer to their facility. However, the Office will defer the
planning of the encapsulation, packaging and transfer of the records
until 40 years has passed.

VERA is a proof-of-concept system that provides for the maintenance of
electronic records that has been presented to various organizations
within the USPTO. It is likely that VERA will be deployed sometime in
the near future. Currently, IFW will perform the ERM tasks of the
electronic records under its control.

It is suggested that by the time the Office changes its format in which
electronic records are maintained (from TIFF images to XML), along with
the components of each record in various formats and stored in different
systems, the Office will have to implement VERA, or another similar
system, to control and properly maintain its records in that
environment.

A description of VERA appears in Appendix 2 of this document.

# Electronic Records Management Requirements

This paper defines and describes the requirements and establishes more
detailed checklists on how to manage electronic records over their
complete life cycle. When creating the electronic records management
checklist for an AIS, the SDM should coordinate with the Office of Data
Management to ensure that the checklist addresses all electronic records
management requirements for all LCM phases of the system.

The checklist should identify where in each LCM stage each requirement
area and its aggregate requirements will be identified, implemented, and
confirmed. This will allow for assurance of accurate, reliable, and
authentic electronic records creation, maintenance and use, and
disposition. While patent and trademark case files are used as cited
examples for many of these profiles, abstraction of requisite metadata
should be done for other yet to be defined electronic records.

The following categories of requirements are addressed in this paper.

+-----------------------------------+----------------------------------+
| -   Records Acquisition           | -   Audit Trail                  |
+-----------------------------------+----------------------------------+
| -   Record Metadata               | -   Vital Record Backup and      |
|                                   |     Recovery                     |
+-----------------------------------+----------------------------------+
| -   File Management               | -   Records Retention            |
+-----------------------------------+----------------------------------+
| -   Preservation of Integrity     | -   Migration                    |
+-----------------------------------+----------------------------------+
| -   Protection of Confidentiality | -   Transfer to Archival Storage |
+-----------------------------------+----------------------------------+
| -   Access Controls and           | -   Records Hold                 |
|     Authentication                |                                  |
+-----------------------------------+----------------------------------+
| -   Search, Retrieval and         | ##  {#section .unnumbered}       |
|     Reproduction                  |                                  |
+-----------------------------------+----------------------------------+

It is important to note that all of the categories detailed in this
section may not apply to every AIS.

## Records Acquisition

The capture of electronic records by USPTO information systems applies
to all documentary materials that meet the tests for an official record
copy, including records received or created electronically and those
received and converted from paper or microfilm to electronic form. The
preciseness and reliability of the acquisition process is critical to
obtaining an accurate and complete electronic record---a record that
preserves the content, structure and context of the information.

### Capture of Complete Electronic Records

It is important to acquire a complete electronic record in order to
ensure a) an accurate copy of all elements of the record is captured;
and b) long-term accessibility and transferability. Electronic records
can contain other electronic records. An example is the USPTO Case
Files. The case file itself is an electronic record that contains
associated metadata. It also contains electronic records (e.g.,
correspondence with an applicant) - Case File Records that include
captured metadata.

In order to capture a complete record, certain requirements must be met.
The requirements will be fulfilled as follows:

1.  The system shall capture the act of "committing" documentary
    intellectual property material as a record copy to a case file. The
    commitment action should be an event that is distinct, conscious and
    verifiable through an audit.

The[^1] audit trail will verify the indexing and scanning of each
document. The date of indexing and scanning will be captured and made
available.

2.  The system shall provide for the capture of all received and created
    electronic records that meet the tests of a record copy. Such
    records might include the following.

    a.  Records received from an applicant

    b.  Office actions created by an examiner

    c.  Communications between the examiner and the applicant, including
        e-mail

    d.  Working files that meet the retention criteria

    e.  Other documentary materials that are *appropriate for
        preservation*

The complete list of types of documents stored in IFW is maintained in
the document code list. All documents that are currently in use or
envisioned in U.S. patent application files are also subject to capture.
A list of the documents or other information that is part of the
official record and are stored in other systems, such as RAM, is
maintained in the Data Location Document.

3.  The system shall capture the content, structure and context of each
    record.

TIFF images of all documents in the application file, except for U.S.
patents, are put into aggregate records in USPTO files. TIFF records
also contain bibliographic data in a related Oracle database that
contains the structure, content, and context of the records. This is
known as the Dossier Management System.

The content of each TIFF record is evident from its face. It is an image
of the document that was received or transmitted. As an image, its
structure is self-evident.

The context of the document is derived from the document code that is
assigned to the record on indexing and scanning and the information in
the table of contents regarding that document (Amendment A, etc.).
Additionally, the bibliographic data stored in the Oracle database, the
metadata of the record, adds to the context with historical data about
the indexing and scanning of the document.

4.  The system shall capture attachments and addenda as separate records
    so that they do not alter the record to which they are linked.

Each section of each paper document will be stored as a separate IFW
document, not as attachments.

5.  The system shall logically link the attachment or addenda to the
    associated record copy.

N/A.

6.  The system shall capture metadata associated with the electronic
    record that allows for search, retrieval, routing, confidentiality,
    status, migration, and retention management. (See Section 2.2,
    Record Metadata).

Most metadata is captured in the Dossier Management System. Other ERM
data on retention is entered into the proposed VERA system. VERA is
scheduled for construction before the migration of the data takes place.

7.  The system shall establish file format standards for receiving,
    creating and storing records that can be processed and transferred
    for the full retention life of the record.

Images will be stored as TIFF images compressed to CCITT Group 4. Data
elements and TIFF images are stored in Oracle tables.

8.  The system shall maintain the same content, structure and context,
    if multiple renditions (same content but different file format, such
    as an MS Word and a XML rendition of the same document) of the same
    record are captured.

EFS submissions are in XML. They will be rendered as TIFF images and
both the XML and TIFF image will be stored in IFW.

### Capture Links to Notes and Annotations

Certain requirements must be met. The requirements will be fulfilled as
follows:

1.  Capture notes and annotations as "logical" additions to the record
    and ensure that they do not alter the content or structure of the
    record.

Overlays on documents are stored as new versions of documents. The
original document without overlays is closed and not altered.
Annotations are stored separately from the document and logically
linked.

2.  Allow users to position notes and annotations on the document in a
    meaningful location. Retain the location of the annotation, like a
    bookmark.

Annotations are not positioned on the document but stored and displayed
in the table of contents. The user positions overlays on the document.
The document image is stored as a new copy.

3.  Reproduce and make viewable the electronic record at any time
    without the notes or annotations.

The pre-modified or modified records containing overlays will be able to
be viewed. Annotations are viewed separately from the document and are
printed on the cover sheet of the document.

### Capture Hyperlinks

Certain requirements must be met. The requirements will be fulfilled as
follows:

1.  Capture hyperlinks within an electronic record that refer to another
    part of the same record.

The IFW system does not contain hyperlinks, so this section is not
applicable.

2.  Capture hyperlinks within an electronic record that refer to other
    electronic records within the same case file.

3.  Hyperlinks to electronic records outside of the electronic case file
    will not be allowed, unless a method is provided to update the
    hyperlinks whenever the record location or the record or hyperlink
    changes.

### Working Files

Capture working files when they meet the requirements for preservation
as a record copy. Working files, such as preliminary drafts, rough
notes, and other similar materials, will be maintained for purposes of
adequate and proper documentation if:

1.  They were circulated or made available to USPTO employees, other
    than the creator, for official purposes such as approval, comment,
    action recommendation, follow-up, or to communicate with USPTO staff
    about USPTO business.

The destruction of the paper working files will take place as scheduled.
The paper working files contain record information, but are not records
as such. All records are maintained in the IFW system.

2.  They contain unique information, such as substantive annotations or
    comments that adds to a proper understanding of the USPTO's
    formulation and execution of basic policies, decisions, actions or
    responsibilities.

N/A.

Electronic working files are managed outside of the case file until it
is determined that they are to become a record copy; afterwards, they
are committed to and managed as part of the case file.

N/A.

1.  Establish a process for committing a working file as a record copy.

Any document that is added to the official record is scanned.

2.  Use version control to capture and track the creation history of
    working files and link successor records to the predecessor records.

### Conversion of Paper Records to Electronic Form

When it is required that documentary materials in paper form be
converted to electronic form, specific guidelines will be followed in
order to ensure that accurate and complete records are captured and that
the process is consistent and reliable.

1.  Ensure that the scanning resolution for image capture is
    sufficiently high to capture a readable, usable and reproducible
    copy of the original.

Procedures of the scanning process are described in the Business
Procedures Manual. The resolution must be 300dpi.

2.  If the document to be scanned has intrinsic value in its originating
    media, consult the agency Records Officer prior to scanning.

Artifacts are stored as such.

### Quality Assurance and Quality Control

Quality control (QC) is a process that is performed during the actual
image indexing and scanning process by the scanning contractor prior to
the images and index data being loaded into IFW quality assurance (QA)
is a step that is performed by the PTO after the images have been loaded
into IFW. Image errors encountered during QA or QC will require a rescan
of the application or batch, depending on the extent of the errors.\
\
A quality control step is an integral part of the record capture
process, independent of whether the documentary materials are being
scanned from paper or are being automatically acquired from
electronically received or created sources (e.g. the USPTO's electronic
filing system (EFS)).. The sampling level for electronically received or
created documents can generally be lower than that used for quality
control of scanned images, unless the observed quality level of the
captured records warrants an increased sample size. A quality assurance
sampling process will be conducted by the Business Area Records Steward
to ensure that all records are accurately and reliably captured.

#### Quality Control

1.  Conduct quality control to ensure accurate, complete and readable
    information is acquired for records captured from the original paper
    document.

Quality control will include a random visual scan by the scanning
operator to verify image quality, and the automatic checking of proper
page feed, page count, and indexing as detected by the scanner. Quality
control will also include the selective extraction of images using a
random function set up by the scanner dependent on the volume of images
being scanned and consistent with accepted ISO standards. The rate of
sampling will be higher for image-scanned paper and lower for documents
acquired from electronic sources. Sampling rates will be adjusted to
reflect the level of errors determined during the sampling process.

These randomly selected images are checked for image quality and
accuracy of indexing. The sampling technique will be sequential sampling
with record keeping including a cumulative count of nonconformities in
image quality and indexing with respect to a given batch. If the
cumulative number of nonconformities reaches an agreed upon number in a
given batch, the inspection is curtailed and the entire batch has to
inspected. During the quality control step, the date of scanning will
also be the date of inspection.

An additional quality control step is carried out with respect to batch
quality. With this step, randomly selected documents within a package of
documents are checked to verify that the document has the appropriate
number of pages and the proper sequence of those pages. A comparison is
made between the images and the paper to determine completeness. During
this step, the date of inspection will be recorded.

A record will be kept of the date of the inspections, the scanner used,
the operator of the scanner, a description of the inspection process,
and the results of the inspection.

Quality control methods will be consistent with the sequential quality
sampling method presented in ANSI/AIIM, Sampling Procedures for
Inspection by Attributes of Images in Electronic Image Management and
Micrographic Systems (ANSI/AIIM TR34-1996).

2.  Conduct quality control on a sample of the captured electronic
    records, whether scanned from paper or acquired from electronically
    received or created sources. The sampling level required will depend
    on the quality level of: a) the source materials, higher for
    image-scanned paper and lower for documents acquired from electronic
    sources, and b) the error levels encountered during the quality
    review process. Sampling rates will be adjusted to reflect the level
    of errors per sample determined during the quality control process.

Quality control will include two procedures.

\(1\) Quality control is ensured by a combination of (a) page counting
for quantity accuracy, with technological checking for misfeeds, (b)
periodic calibration of the scanner before each shift for quality
compliance, and (c) a scientific sampling of the scanning batches to
review image quality and accuracy. The sampling rates are based on
accepted ISO standards with record keeping including a cumulative count
of nonconformities in image quality and indexing.

With regards to documents acquired from electronic sources, such as soft
scanning word processing documents, the rate of sampling would be half
of that needed for paper sources. These percentages would vary based on
the error rate discovered.

\(2\) A follow-up quality assurance step described in more detail in the
next section.

3.  Provide a means to rescan documents that quality control has shown
    to be of insufficient quality, or mark the documents prior to
    scanning as "best copy."

For purposes of providing a means to rescan documents that Quality
Control has shown to be of insufficient quality, the source materials
will be stored onsite for a period of at least 2 months or until the
users in the normal course of business will usually view the material.
The source material will be traceable to a location of storage and will
note the scanner, the indexer, the scanner operator and when the source
material was scanned. All storage information will be loaded into a
database so that an IFW user can view storage location of the scanned
documents. Location information must be updated when scanned documents
are moved.

4.  Track the batch number for both the imaged and paper documents as a
    means of accessing any documents determined to be of insufficient
    quality.

All source materials and scanned records will be assigned a batch number
that identifies when and where the source materials were scanned, which
scanner was used, the operator of the scanning apparatus, and the
indexer of the document. The scanning apparatus records will uniquely
identify the batches so that the source material and the scanned
material can be associated at a later date.

5.  Test the scanners periodically to ensure that they are operating
    according to manufacturers' specifications and are producing the
    desired quality level for the documents being scanned.

The scanners will be cleaned and calibrated at the beginning of every
shift. Calibration will include scanning a scanner test page to check
for image quality.

6.  Conduct meticulous quality control of the converted text when
    Optical Character Recognition is used to convert scanned image
    documents to computer readable format.

No OCR functions are currently part of IFW.

#### Quality Assurance

1.  Conduct a final quality assurance independent validation and
    verification (IV&V) sample. If a third party contractor is
    performing the record capture and/or quality control then it is
    preferable that the USPTO perform this final IV&V step.

The party who performs the initial scanning step and associated quality
control at that stage will be different from the party who performs the
quality assurance step. The USPTO Business Area will perform the quality
assurance step.

2.  Conduct a final quality assurance independent validation and
    verification (IV&V) sample. If a third party contractor is
    performing the record capture and/or quality control then it is
    preferable that the USPTO perform this final IV&V step.

The party who performs the initial scanning step and associated quality
control at that stage will be different from the party who performs the
quality assurance step. The USPTO Business Area will perform the quality
assurance step.

Where nonconformities are found, the scanner, the indexer and the
scanner operator will be noted in an effort to correct the source of the
nonconformity. If the problem is found to be in the scanner, all of the
output for that particular scanner for a given period of time might have
to be checked.

To determine if that level of nonconformities has been reached, a
cumulative count of nonconformities in image quality with respect to a
given scanner for an agreed upon period of time will be kept. If the
cumulative number of nonconformities reaches an agreed upon number for
that scanner, the inspection is curtailed and the entire output for that
scanner for a given period of time will have to be inspected. If the
problem were found to be the operator or the indexer, other appropriate
steps would be taken.

As with the quality control step, a record will be kept of the date of
the inspections, the description of the inspection process, and the
results of the inspection.

Quality assurance methods will be selected from the sequential quality
sampling methods presented in ANSI/AIIM, *Sampling Procedures for
Inspection by Attributes of Images in Electronic Image Management and
Micrographic Systems* (ANSI/AIIM TR34-1996).

3.  Regularly conduct a final quality assurance process as the means of
    being certain that all records and associated metadata are being
    accurately and reliably captured.

Quality assurance will include having the recipients of the documents
(the users) inspect every document they view on the screen for the
purpose of detecting nonconformities in image quality, indexing, or
completeness. This step is conducted during the normal course of
processing. Quality assurance focuses on the first user; however, it
will also include any nonconformities found by any other user of the
documents. When problems are detected, the user reports these
nonconformities to an image problem box using an easy and convenient way
to report defects.

These nonconformities are channeled back to the scanning team for
correction and for analysis of any systemic problems, such as a bad
scanner or inattentive operator. During the quality assurance step, the
date of the user report will also be the date of inspection. For
purposes of this step, every user will have a standard list of defects
from the appropriate Electronic Image Management (EIM) standards as
defined in Table 1 of page 5 of ANSI/AIIM TR34-1996 so as to use the
measurable nonconformities in image quality as defined by the EIM
standards.

Where nonconformities are found, the scanner, the indexer and the
scanner operator will be noted in an effort to correct the source of the
nonconformity. If the problem is found to be in the scanner, all of the
output for that particular scanner for a given period of time might have
to be checked.

To determine if that level of nonconformities has been reached, a
cumulative count of nonconformities in image quality with respect to a
given scanner for an agreed upon period of time will be kept. If the
cumulative number of nonconformities reaches an agreed upon number for
that scanner, the inspection is curtailed and the entire output for that
scanner for a given period of time will have to be inspected. If the
problem were found to be the operator or the indexer, other appropriate
steps would be taken.

As with the quality control step, a record will be kept of the date of
the inspections, the description of the inspection process, and the
results of the inspection.

Quality assurance methods will be selected from the sequential quality
sampling methods presented in ANSI/AIIM, Sampling Procedures for
Inspection by Attributes of Images in Electronic Image Management and
Micrographic Systems (ANSI/AIIM TR34-1996).

4.  Conduct a final quality assurance independent validation and
    verification (IV&V) sample. If a third party contractor is
    performing the record capture and/or quality control then it is
    preferable that the USPTO perform this final IV&V step.

The party who performs the initial scanning step and associated quality
control at that stage will be different from the party who performs the
quality assurance step. The USPTO Business Area will perform the quality
assurance step.

### Record Capture Audits

The system shall conduct periodic audits of the document capture
process. This will ensure that all procedures and guidelines are being
followed and that accurate and reliable records with associated metadata
are being acquired. Adjust scanning, quality control and assurance
procedures and levels accordingly.

## Record Metadata

### Metadata Management

The records for intellectual property applications are managed in case
files, whether paper or electronic. The metadata required to provide
accessibility, auditability, and transferability of the electronic
records must also be managed in conjunction with the electronic record.
The metadata shall be integrated or encapsulated in the electronic
record.

The system shall maintain the accuracy and completeness of all case file
and record-related metadata through media renewals, through transfers to
new hardware or software or new application information systems, and
transfers to archival storage. This is one of the fundamental
requirements for long-term access and retention of electronic records
and record metadata - metadata must be retained for the same period of
time as the electronic case files and records.

The USPTO will follow a migration strategy to manage software and
hardware dependencies for patent electronic records. Metadata to support
this strategy will be stored in IFW (e.g. TIFF image software
dependency) and in an electronic record archiving system (to be
developed at a later date).

Processes and procedures will be deferred until future enhancements are
made, and developed and integrated with IFW to support this strategy.

#### Metadata Retention

The retention management requirements for the electronic records must
also be applied to the related metadata.

For each document that is stored in IFW, the following metadata elements
will be captured:

+---------------------+------------------------------------------------+
| **IFW**             | **Description of field name**                  |
|                     |                                                |
| **field name**      |                                                |
+---------------------+------------------------------------------------+
| Code                | Document code                                  |
+---------------------+------------------------------------------------+
| Description         | Document description; language of the document |
+---------------------+------------------------------------------------+
| Date                | Legal date; the filing date                    |
+---------------------+------------------------------------------------+
| Source              | e.g. scan, copy, CASEX, EPASYS                 |
+---------------------+------------------------------------------------+
| Pages               | Number of pages of a document                  |
+---------------------+------------------------------------------------+
| First user          | Userid of the user who viewed the document the |
|                     | first time                                     |
+---------------------+------------------------------------------------+
| Index officer       | Person who indexed the document                |
+---------------------+------------------------------------------------+
| Annotation          | Document annotation                            |
+---------------------+------------------------------------------------+
| Procedure           | The name of the procedure used to process an   |
|                     | application (e.g. Search/Exam)                 |
+---------------------+------------------------------------------------+
| Participant         | Full name of the participant                   |
+---------------------+------------------------------------------------+
| Status              | This is the status of the document (e.g.,      |
|                     | whether the document is indexed, scanned,      |
|                     | loaded, etc.)                                  |
+---------------------+------------------------------------------------+
| Scanned             | Indicates whether a document has been scanned  |
+---------------------+------------------------------------------------+
| Closed              | Indicates whether a document is logically      |
|                     | deleted                                        |
+---------------------+------------------------------------------------+
| Public              | Indicates whether a document belongs to the    |
|                     | public part of dossier                         |
+---------------------+------------------------------------------------+
| Handled             | Indicates whether a document is handled        |
+---------------------+------------------------------------------------+
| Model               | Model filed                                    |
+---------------------+------------------------------------------------+
| Number              | Number of model                                |
+---------------------+------------------------------------------------+
| Box                 | Box number of model                            |
+---------------------+------------------------------------------------+
| Room                | Where model is stored                          |
+---------------------+------------------------------------------------+
| A-Publication       | For publication, republication, or correction  |
|                     | by the USPTO                                   |
+---------------------+------------------------------------------------+
| Date                | Date sent to the printer                       |
+---------------------+------------------------------------------------+
| Annotation          | Note for the printer                           |
+---------------------+------------------------------------------------+
| B-Publication       | For publication, republication, or correction  |
|                     | by the USPTO                                   |
+---------------------+------------------------------------------------+
| Date                | Date sent to the printer                       |
+---------------------+------------------------------------------------+
| Annotation          | Note for the printer                           |
+---------------------+------------------------------------------------+
| PXI document        | Package number and type of document            |
+---------------------+------------------------------------------------+
| Offset              | Offset of document from beginning of package   |
+---------------------+------------------------------------------------+
| Original dossier    | Original dossier number                        |
+---------------------+------------------------------------------------+
| Logical package     | Package number in dossier                      |
+---------------------+------------------------------------------------+
| Sequence            | Sequence number of a document within its       |
|                     | logical package                                |
| number              |                                                |
+---------------------+------------------------------------------------+
| Batch number        | Includes date indexed                          |
+---------------------+------------------------------------------------+
| CDR number          | Includes date put to CDR                       |
+---------------------+------------------------------------------------+
| Box number          | Where the paper document is stored             |
+---------------------+------------------------------------------------+
| Location            | 2-character abbreviation of the current        |
|                     | location of the box                            |
+---------------------+------------------------------------------------+
| Room                | Room where the box is kept                     |
+---------------------+------------------------------------------------+
| Time                | Timestamp when the status change took place    |
+---------------------+------------------------------------------------+
| Original status     | Original status of the package                 |
+---------------------+------------------------------------------------+
| New status          | New status of the package                      |
+---------------------+------------------------------------------------+
| User                | Userid of the person who changes the status    |
+---------------------+------------------------------------------------+

#### Metadata Profiles

The following metadata record profiles shall be implemented and the
metadata elements should be defined, acquired and retained for the
following areas:

1.  **Case file and Case file Records profiles**: These profiles contain
    metadata for storage, search and retrieval, confidentiality and
    tracking accesses. Examples of these profiles and some of the
    metadata they will capture can be found in Section 3.

Metadata for records in the case files includes for each document at
least the following: date of indexing, index code, date of scanning,
quality assurance, size of document, encoding format (TIFF),
compression, (checksum or message digest), scanner used, size of
document, and the box number where the original is stored.

2.  **Use History (see Section 2.8 Audit Trail)**: This profile
    documents an audit trail of events and actions in order to provide a
    basis for: a) establishing the reliability and general
    trustworthiness of the electronic record, b) use in meeting the test
    of authenticity for admissibility, and c) for tracking or
    researching events related to proving that integrity has been
    preserved or that confidentiality has been protected. An example of
    this profile and some of the metadata it will need to capture can
    also be found in Section 3.

Use history is stored in an audit trail; it contains the names of all
persons who have accessed the file's records and had the opportunity to
view or alter them. Actual viewing or alteration is not necessary to be
included in this metadata. Any changes that were made or might have been
made are not recorded in this metadata.

However, the documents themselves bear witness to the changes in the
specification and claims and also provide the reason for the changes.
The metadata of use history is used to help locate unauthorized accesses
and also to anecdotally check the workflow of particular applications.

3.  **Copy, Reformat and Transfer Profiles**: These profiles document
    the copy or reformat of electronic records in the event of media
    renewal; the transfer to a new hardware and software system or
    information system; or the transfer to archival storage. Examples of
    these profiles and some of the metadata they will need to capture
    can also be found in Section 3.

The Metadata Profiles above do not identify *how* each metadata element
will be captured. This is also not necessarily an all-inclusive list of
profiles and metadata that may be needed. Nonetheless, it assumes that
many metadata elements, such as those for the Case file Profile and Case
file Record Profile could be automatically acquired from the USPTO
information systems. Many of the other metadata elements, such as access
dates, may be supplied automatically by the information system or, as a
last resort, via manual data entry.

#### Electronic Record Encapsulation

For ease of migration and for audit purposes, all metadata information
shall be encapsulated within the electronic record. Encapsulation of all
metadata as part of the electronic record provides a "single digital
object" that contains the elements necessary for accessing and for
tracking activity related to the electronic record. Encapsulation also
makes it easier to identify all information that needs to be migrated in
the event of media renewal or the transfer of electronic records.
Encapsulation can be done using either a logical or physical approach.

1.  Logical encapsulation: "Links" all of the records, annotations and
    notes, and metadata profiles that comprise a case file as a
    "logical" single digital object. However, the records and metadata
    related to a case file may reside on different storage servers and
    different media volumes. While logical encapsulation may represent
    the most flexible method for storage, it creates a potentially
    complex management environment and, as such, a higher risk of loss
    or corruption when performing media renewal or transfer of case
    files.

2.  Physical encapsulation: This means that all of the information
    associated with a specific electronic intellectual property case
    file, such as the records, related annotations and notes, metadata,
    and intra-or inter-case file or record linkages, exists as a single
    physical object or entity residing on the same volume of media.
    Physical encapsulation may provide the most straightforward
    environment for media renewal and transfers of case files, however,
    it could pose issues related to the resources and time required to
    keep the case file physically encapsulated.

The USPTO will implement both logical and physical encapsulation
strategies in order to ease migration and support auditability. IFW will
serve as the repository for the official electronic file wrapper and
will store images of information that constitutes the complete
electronic file wrapper.

Other related electronic record information (a.k.a. audit trail and
associated records) will be stored and managed in appropriate supporting
systems, i.e. RAM and a future electronic record archiving system. These
distributed repositories will be logically linked together through a
metadata database. All electronic record information will then be
physically aggregated together and encapsulated for long-term retention
and disposition in the Electronic Record Archive according to the
approved records disposition schedule.

### Electronic Record Retrieval Profile Metadata

One of the primary purposes of metadata is to provide an easy and
efficient means for retrieval of the electronic records by authorized
personnel. One type of metadata is defined as "profile data." The Case
file and Case file Record profiles are designed to include information
such as: a unique identifier for the case file and each record in the
case file, the subject or title of the case file or record, the creator
or origin of the record; why, when, and how the record came into
existence; accuracy of the source data; source granularity; processing
status; use history; and the quality and extent or scope of the
resource.

The following guidelines are provided for capturing and managing
metadata for purposes of retrieving electronic records.

1.  Differentiate each electronic case file and each record in an
    electronic case file with at least one unique metadata identifier.

The unique metadata identifier for the application (case file) is the
dosOriNumber. The unique metadata identifier for an individual document
(record) within an application is the docPckKey and the docPckSeqNumber.
These two fields uniquely identify a document.

2.  Encapsulate Case File and Case File Record profile metadata in the
    related electronic case file for effective retention and migration
    management.

The metadata for the Case File and Case File Record is stored in the
jDMS and the jPXI. The jDMS is the Dossier Management System which
provides data on every application, the details of every document, its
history, and a link to its location in the archive (jPXI). jDMS also
stores data on users and teams and on the system itself. The electronic
documents themselves are stored in the Document Archive (jPXI) which is
designed to store large files.

3.  Identify USPTO information systems to provide the primary source of
    metadata for the Case File and Case File Record profiles.

IFW jDMS and jPXI are the primary source for metadata about the case
file and the case file record profiles. Additional metadata that relates
to fee processing is stored in RAM. PALM contains metadata concerning
filing date, assignment, and classification.

4.  Identify USPTO information systems for search and retrieval of
    electronic case files and records.

IFW provides the ability to select an application by entering the
application number and viewing the table of contents (TOC). Viewing the
TOC allows a user to view available documents that are contained in the
application. Search abilities are not available at this time in IFW.

5.  Provide a link from USPTO information system databases to the
    electronic case files.

N/A

6.  Define specific document-type designations that allow for retrieval
    of only specific records within an electronic case file.

Retrieval - to simplify navigation through large numbers of documents,
jDMS creates a Table of Contents (ToC) for every application within it.
The user is able to retrieve documents by selecting an item on the list.
Any new documents for action are retrieved automatically.

7.  Provide for the identification of hard copy records and other
    non-electronic materials, where relevant, as Case File Record
    Profiles so that retrievals are kept simple, e.g., one search to
    identify all records available, regardless of media type or physical
    location.

When an artifact is received with an original submission or a follow-on
submission, an artifact sheet will be completed, forwarded to Central
Scanning and Printing for scanning, and added to the image-file
application image file.

The artifact sheet will identify the artifact, the associated
application number, the date of receipt of the artifact and the storage
location of the artifact.

8.  Use the Case File Metadata profile to indicate the status of
    confidential records, e.g., identify confidential, privileged and
    private records so they can be secured from unauthorized users.

IFW allows all USPTO internal users to see any application and the
associated data.

Application information that is electronically submitted is protected by
an Entrust security architecture in PAIR that provides:

\(a\) **Authentication** - the process of validating that the document
was sent by the entity indicated as being the sender;

\(b\) **Integrity** -- the ability to verify that data is unchanged from
its source and has not been accidentally or maliciously modified,
altered, or destroyed;

\(c\) **Non-repudiation** -- the ability to ensure that the sender
cannot repudiate either the contents or the authenticity of the
document. The identity of the sender and an indication of integrity are
sent to the recipient in a manner that is sufficient to prevent him from
successfully denying having possessed and sent the data.

\(d\) **Confidentiality** -- this ensures that information can be read
only by authorized entities.

USPTO client software and Entrust/Direct provide data encryption and
security to reduce the risk of unauthorized disclosure of confidential
customers who want to access confidential PAIR data by requiring
interested persons to submit by U.S. mail a request to access this data.
The USPTO will provide, by return mail, an Entrust/Direct certificate
and assign it to the same customer number that requests such access. The
PAIR system independently verified Entrust/Direct certificates by
checking the customer numbers.

PAIR uses the USPTO\'s PKI infrastructure to comply with USPTO security
policies and establish a secure communication channel for data that is
transmitted over the Internet. PAIR also uses digital certificates
issued by the PKI infrastructure to establish secure communication
channels to transmit messages between the Entrust/Direct client and the
PAIR server.

The PKI infrastructure provides the services necessary to issue, use,
and revoke digital certificates that are needed for secure electronic
communication between the USPTO and its customers.

Each time a customer makes an online request for access, the
user-supplied Entrust/Direct certificate is matched with the one stored
on PAIR. Data can only be viewed after PAIR validates the customer
number. PKI certificates are stored in PAIR database tables and indexed
by customer numbers that the USPTO assigns.

PAIR 4.0 contained enhancements to support implementation of the upgrade
that contained the Examination and Post-Examination (EXPO) database.
Specific software performance problems were fixed in releases 4.1
(reviewed for Section 508 compliance) and PAIR 4.2 (which included the
addition of the Patent Term Extension \[PTE\] page). PAIR 4.3, a pilot
project, was initiated to support distribution of Patent Proof Copies
(PPCs) to USPTO customers prior to final publication.

PAIR was modified to allow customers with active digital certificates
and the Entrust/Direct client installed on their computers to download
PPCs from the PAIR server via the main USPTO website (uspto.gov).

The production system in PAIR 4.4 was enhanced for private customers to
upload commented PPC images for review by USPTO prior to their
publication. The production system in PAIR 4.5 is being enhanced for
private customers to review electronic file wrapper contents that reside
on the USPTO's IFW server.

When IFW is in production in June 2003, the applicant is the only one
who will have access to his applications. No additional public access
will be granted.

9.  Where possible, automatically index all records received or created
    in accordance with an USPTO-wide filing scheme for electronic case
    files that is to be developed using the metadata profiles defined
    for Case Files and Case File Records.

Refer to the IFW Doc Code list and Business Process Description for more
information on the index process.

10. For ease of mass retrievals, allow for designation of common
    predetermined metadata fields, e.g., application number, subject,
    date, originator, record type or form number, and disposition code.

Not applicable.

11. Do not allow altering of metadata associated with (or encapsulated
    with) an electronic case file, unless it is determined that the
    metadata contains errors that must be corrected.

The following fields can be modified for a document stored in IFW:

\- DocCode

\- Related procedure (folder)

\- Status settings:

\- Public document (\'P\' or space)

\- To be sent to Publisher (\'Y\', \'N\' or \'R\')

\- Related group

-   DocCode description

-   Document annotation

12. Limit and control access of modification programs or tools for
    correcting metadata to authorized personnel, should corrections to
    metadata be required (such as due to errors induced during automatic
    or manual data capture). Audit trail information about any changes
    will be added to the Use History metadata profile.

Role privileges define what actions a user can take.

**History** - At the moment an application is opened, the system updates
the history with the user ID, date, time, and type of access (either
ad-hoc or the docCode of the message). The history is viewable for an
application by selecting the History Tab in the application.

**Action Log** -The action log records system-generated actions such as
the request, printing, and receipt of a paper file. It is possible to
record actions manually by using the "add action" feature.

## File Management

The file management system must protect the physical and referential
integrity of electronic records and associated metadata over the full
life cycle. The file management system must protect and not allow an
electronic record and associated metadata to be overwritten or
inadvertently deleted. It will also provide the means to enable access
to electronic records and metadata for the full retention period,
independent of the storage media---digital, paper or microfilm.

1.  Use access controls to ensure that the disposal of electronic
    records and associated metadata will be restricted to specific
    personnel who are authorized by the USPTO Records Officer or
    equivalent/designate to destroy or transfer electronic records and
    associated metadata.

Only "super users" will be authorized to destroy or transfer electronic
records. The Records Officer will provide procedures for the "super
users" to follow.

2.  Create and maintain a unique link or pointer between the USPTO's
    records retrieval and tracking information systems, the file
    management directory and/or the metadata, and the physical location
    of the electronic records. This will enable access throughout the
    records life cycle.

A directory of where the documents are maintained will be created and
maintained. The vast majority of records will be maintained in IFW and
will not be distributed among systems.

3.  Provide a link or pointer between the USPTO's records retrieval and
    tracking information systems, the file management directory and/or
    the metadata profiles, and the physical location of the electronic
    records and related metadata in order to facilitate the vital
    records backup of electronic records and related metadata.

4.  Capture metadata to locate any records that are maintained only in
    physical form or on physical media (such as CD-ROM).

Metadata of the location of artifacts will be stored in PALM. (It will
also be stored in IFW.)

For management of physical storage media, see Section 1.11.2 Media
Management in the TSG-ERM.

## Preservation of Integrity

Integrity means ensuring consistency of data, in particular, preventing
(including detecting) unauthorized alteration or destruction of data.
Maintaining the integrity of electronic records is essential for
ensuring the protection of intellectual property rights and the value of
the inventor's business assets. For these reasons, checks and balances
must be in place to assure the preservation of the integrity,
authenticity and trustworthiness of the USPTO's records over time.
Managing and protecting the electronic records from any loss,
alteration, removal, or premature destruction will accomplish this.
Since evidence of record tampering may not be as readily identifiable
with electronic records, as it might be with paper records, it is even
more important that the controls are in place to adequately protect and
preserve the electronic record.

### Protect Against Alteration

1.  Apply access controls to electronic records on a "least privilege"
    basis, with access limits based on the role or function of an
    individual.

Access controls are provided to all users of a class who must process
the application file. As the processing of the patent application
progresses through prosecution, the authorized users may change. For
example, when an application is being petitioned, the authority of an
examiner to access and process the file is suspended.

2.  Preserve the content, structure and context of a record committed to
    an electronic case file. No alteration will be allowed. The
    integrity of each record must be preserved for the full retention
    period of the case file.

Each document is a scanned TIFF image. No alteration of the actual
record is permitted once it is created. Access controls, re-scanning of
processed documents (e.g. with and without a stamp mark) and the
preservation of the original paper serve as backups and guarantors of
the preservation.

3.  Protect any annotations and addenda related to an electronic case
    file or record from alteration or loss. Annotations and addenda will
    be maintained as data that is separate from, but logically linked,
    to the record. This activity is needed so that the electronic record
    can be viewed or reproduced in the original manner, content and
    structure, in which it was presented.

Annotations and addenda are treated as either new documents when marked
on an original document, or as associated metadata when stored in data
form. When annotations are applied to the original document and the
document as annotated is scanned, the annotation becomes part of the
document and is protected from alteration just as the original document
is.

4.  Correct metadata associated with (or encapsulated with) an
    electronic case file or record only if it is determined that the
    metadata contains errors that must be corrected.

Metadata is under access controls. Authority files indicate the class of
worker that may make a certain annotation.

5.  Limit and control corrections of metadata (such as due to errors
    induced during automatic or manual data acquisition) to specifically
    authorized personnel. An audit trail of any modification activity
    will be tracked in the Use History metadata profile.

Only USPTO workers who are authorized to make the indicated corrections
may correct metadata.

6.  Use version controls (such as check-out/check-in procedures) to
    ensure that the original electronic record remains unaltered. If new
    electronic records are to be created using an existing electronic
    record as the basis, the new electronic version must be committed to
    the electronic case file as a new record with new case file record
    profile metadata.

The use of scanned images means that versions of the documents appear as
whole new documents. The versions are under the full control of the
access systems.

7.  Limit access to programs or functions used for destroying electronic
    case files and records at the end of the authorized retention period
    (including associated attachments and annotations, and the metadata)
    to persons or system functions specifically authorized by the
    Information Systems Security Officer or equivalent/designate.

Ordinary users cannot destroy the electronic files. The function is
needed in the event that security order cases are found to be in IFW.
The actual destruction of files can be done by a limited number of
trained and trusted employees.

### Validate Integrity

1.  Use some feature, such as a cyclical redundancy check (CRC) or a
    digital signature hash that allows the integrity of the record to be
    validated at the time of each receipt/creation and at the time of
    each access. The validation mechanism should allow for detection of
    any attempt at or alteration of the record.

Currently, no mechanical system such as CRC or digital signature hashes
are being used to validate integrity at the time of creation of the
electronic document or when accessed within USPTO systems. The digital
signature is used when the documents are transmitted to other offices
over the Internet. (The addition of this safeguard within the USPTO is a
future development.)

2.  Record each validation of integrity in the use history metadata
    profile.

If and when the integrity is checked by hash, CRC, or message digest,
the event will be recorded in the use history.

## Protection of Confidentiality

Confidentiality is defined as ensuring that information is not disclosed
or revealed to unauthorized persons. Confidentiality does not apply to
all electronic records. Confidentiality applies to pending and abandoned
electronic patent records and associated metadata, except when the
abandoned patent is referenced by an issued patent. Maintaining the
confidentiality of pending or abandoned patent case file and record
content is crucial because the information is confidential and highly
valuable intellectual property of the owner.

1.  Protect confidential electronic records and associated metadata from
    unauthorized viewing during transmission, using a level of
    encryption appropriate for the type of record.

Role privileges define what actions a user can take. Linking privileges
to access controls will be provided by user password use.

2.  Protect confidential electronic records during the review,
    pre-examination, examination, and publication steps, and during
    maintenance of abandoned patents, and ensure that they are not
    disclosed or revealed to unauthorized persons.

Role privileges define what actions a user can take. Linking privileges
to access controls will be provided by user password use.

3.  Provide a metadata field that indicates when the status of an
    electronic case file is confidential.

Access will be provided to the entire record and to the application as
filed based on the public's right to the information. Thus, only
unpublished applications that are not referenced in another open
application will be kept in a completely confidential state.

4.  Access controls to confidential records will include the ability to
    restrict access on a "least privilege" basis within one or more
    specified functions or roles for an individual.

Role privileges define what actions a user can take. Linking privileges
to access controls will be provided by user password use.

5.  Physically secure off-line media that contain confidential records
    from unauthorized access.

Access to artifacts will continue to be provided only when based on a
determination by Office staff that access is permitted.

## Access Controls and Authentication

Providing access controls (identification) and authentication
(validation of identity) is critical for protecting the confidentiality
and preserving the integrity of electronic records. It is required to
prevent unauthorized viewing, modification, destruction and, generally,
the unauthorized issuing of commands. Access controls will be based on
"least privilege," granting users access only to those electronic
records, and to associated annotations and metadata, that are minimally
required to perform their roles or functions. Controls may selectively
limit access to electronic records, to any action or event related to
electronic records, and to specific computing resources related to
migration or purging. Record access control, authentication, and other
security requirements are discussed in the respective AIS Security Plan.
For further information consult Security Plan TSG.

1.  Provide access controls and authentication, such as public/private
    key pair, to authenticate the identity of the sender, creator, and
    user of the record.

Public access is through PAIR. PAIR is integrated with Entrust and PKI
infrastructure to provide user authentication and secured sessions.
Entrust provides user authentication, data encryption, and secured
session links between users and PAIR via the Internet.

To ensure internal access, it is envisioned that the Single Sign On
(SSO) product will be used to grant access to IFW. The SSO adheres to
all USPTO and departmental rules and regulations for password
protection. IFW will authenticate the user by checking the UserID and
password that is stored for the SSO.

2.  Identify and authenticate each user at the time of log-on to all
    USPTO information systems that: receive, create, process, maintain
    or otherwise manage electronic records.

IFW will authenticate the internal user by checking the UserID that is
stored for the SSO. SSO provides the authentication of the user at the
time he logs on to PTONet.

As per section 2.3.1 (Use of PAIR System) of the PAIR DDD, dated July
12, 2002, access to documents is set forth as follows.

**Access To Pending and Abandoned Applications:**

In order to get access to pending or abandoned applications, the
application must have a customer number and its related correspondence
address.

The following describes the process to obtain customer numbers. A
customer can apply for a customer number by completing the appropriate
form and mailing it to the Office of Initial Patent Examiner (OIPE).
OIPE assigns a customer number and forwards it to the customer.

Afterwards, the customer files a change of address form to change the
mailing address to the customer number in all the applications that are
pending or abandoned which they may want to access via PAIR. A filing
that includes a change of address is necessary to assign a new customer
number to the application.

If accessing the PAIR system via Internet, the customer must apply for a
UserID and Password. All applications for UserID and Password should be
addressed to:

U. S. Patent and Trademark Office\
Office of Security**\
**Attn.: UserID/Password Application\
Washington, DC 20231

The customer must possess a valid Entrust certificate. In the
certificate, a digital distinguished name (DN) is established. The PURM
Administrator runs the PURM software to insert the DN and customer
number into the PALM Examination and Post-Examination (PALM-EXPO) Oracle
database.

To access confidential information from PAIR, such as pending or
abandoned patent application data, the customer must provide his or her
UserID and Password using Entrust Client software to become
Entrust-enabled.

The PAIR uniform resource locator (URL) must be entered using either
Microsoft Internet Explorer or the Netscape web browsers. The
PAIR/Private system is then accessible. PAIR prompts the user to enter
an application number, a patent number, or a customer number. If the
customer has multiple customer numbers, a wild card option can be
selected for requesting data.

In order to access the data, users must fill out an online request. In
this request, the user-specific DN obtained from the PAIR application
via the Entrust application programming interface (API) must match the
one stored in the PALM-EXPO database. After a successful login, the user
is allowed to see his confidential PALM data. In the event of ten
consecutive unsuccessful tries to access unauthorized PAIR confidential
data, the user\'s access is revoked.

The user must then contact the USPTO Security Office to reinstate the
access privilege. If the access privilege is revoked, the customer
number, the user's Internet Protocol (IP) address, and the time of day
are recorded in a log file for the purposes of status reporting.

All cases under 'Security Review' are inaccessible, even to the
applicant's attorney. In these cases, a warning message, 'Case is not
accessible pending Security Review' displays to the user.

The USPTO PAIR web server software interfaces with Entrust software and
provides data encryption and security to reduce the risk of unauthorized
disclosure of confidential data.

**Access to Issued Patents**

Information on issued patents is accessible (and searchable) by all
Internet users by application number, publication number, or patent
number. Customer numbers and UserIDs with passwords are not required.

**Access to USPTO Employee Information**

Users are able to access a USPTO employee's office name and telephone
numbers.

**Access to a List of Applications and Patents by Customer Number**

Customers with Entrust Certification are able to enter the customer
number for searching all pending applications and issued patents that
are assigned to that customer number. The search returns application
number, patent number, filing date, issue date, earliest publication
number, earliest publication date, and attorney docket number for each
record found.

**Access to Pre-Grant Publication Status**

Application status for published patents is electronically accessible by
all public users by application number, patent number, or publication
number after the first publication date. Customer numbers and UserIDs
with passwords are not required.

**Access to Pre-Publication Status by Publication Number**

Customers with Entrust certificates are able to enter the publication
number for searching all pending applications and issued patents that
are assigned to their customer number. Search results return:
application number, patent number, filing date, issue date, earliest
publication number, earliest publication date, and attorney docket
number, for each record found.

**Attorney/Applicant Access to Bibliographic Data**

Customers **with** Entrust certificates are able to search all front
page bibliographic data for the applications.

3.  Use access controls and profiles that include the ability to
    restrict access by an individual on a "least privilege" basis to one
    or more specific functions or roles as well as to selected computing
    resources based on the process status of the electronic record.

Users who need access to the system have a user-id record. Each user is
assigned to one or more teams with a certain set of **privileges**. The
privileges are configurable within IFW and are established by the Patent
Business Area.

4.  Use access controls and profiles that strictly limit access to any
    information system or other computing functions or resources that
    provide for the modification of metadata, creating new versions of
    documents, and the scheduled purging (deleting) of electronic
    records and associated metadata.

Authorization will be developed based on establishing roles that have
privileges and assigning individuals to the appropriate roles. A role
can have more than one person assigned and a person can be assigned to
**more** than one role. The assignment of roles to a person will be
based on the user's UserID. Limited authorization will be implemented
for maintaining role privileges and assigning individuals to roles.

5.  Use an audit trail to track all events related to access of the
    record, including the detection of unauthorized access attempts.

**History** - At the moment an application is opened, the system updates
the history with the UserID, date, time and type of access (either ad
hoc or the document code of the message). The history is viewable for an
application by selecting the History Tab in the application.

**Action Log** - The Action log records system-generated actions such as
the request and the printing and receipt of a paper file. It is possible
to record actions manually by using the "add action" feature.

Detection of unauthorized access is through the SSO and not directly
through IFW. Therefore, there is no audit trail of unauthorized access
attempts in IFW.

## Search, Retrieval, and Reproduction

The ability for records managers and stewards to search and retrieve
specific record related data and metadata is vital to supporting the
authenticity and integrity of the records and the recordkeeping system.

### Search and Retrieval

1.  Search for all electronic records relevant to an authorized request,
    whether they are stored in online, near-line, or off-line media.

In IFW, searches are provided by viewing records by patent application
number.

2.  Search options for electronic Case Files will include:

    a.  Searching the metadata for a specific "case file."

    b.  Searching a case file for a specific record.

In IFW, searches are provided by viewing records by patent application
number.

3.  Allow for a variety of types of searches, for example word matching
    and Boolean.

(These statements apply to statements 1, 2, and 3 above.) Searching of
the images that are in the application files is not to be performed in
the "word search" sense. Documents are to be accessed in the same manner
as used in paper applications: by application number and by document
number with the application, as indicated in the application's table of
contents. Document codes applied during indexing and scanning indicate
the nature of the document.

Applications are not normally word searched until publication, and even
then, only the published application's specification, claims and
abstract are word searchable. Other systems are responsible for the word
search function of published applications and patents, based on
character coding that is applied during the publication process.

Retrieval of the applications and documents is performed by IFW and is
based on the application number.

### Store Search Results

1.  Allow users to store the search results as a record, e.g., a list of
    all intellectual property documents that were reviewed during a
    search process of an intellectual property application examination.

2.  Allow users to temporarily store and then retrieve search results
    until a business task or event is complete.

### Display/Print Record, Index, and Annotations

1.  Ensure that a human--readable copy (screen display and hard-copy) of
    the complete record can be generated over the life of the record.

The image is stored in a TIFF format in Oracle as blobs. The image can
be rendered through IFW into various image types. Currently, the USPTO
is only using TIFF. Printing and viewing of the image is available in
IFW. The data about the application is stored in Oracle tables in the
format that is most suitable to the data. This information is
retrievable through IFW for viewing and printing as well.

2.  Display/print options will include any combination of the following:

    a.  Display/print of the record.

Records can be displayed and printed via the IFW GUI.

b.  Display/print of the annotations.

**Application Annotations**

At the bottom of the cover panel, there is a specific area to make
dossier annotations. The system always shows all current (valid)
annotations in chronological order with the following fields: date,
UserID, and text. If some of the annotations or text is not visible,
users can scroll by clicking with the mouse in the scroll bars at the
bottom and right of the screen.

Users can print annotations by selecting the print option and marking
the appropriate box.

**Document Annotations**

Document Annotations are viewable in the table of contents viewer.

Users can print document annotations on the banner sheet by selecting
the print option and marking the appropriate box.

c.  Display/print of Electronic Record metadata.

Application information and the images are viewable through the IFW GUI
and printable through the IFW print program.

3.  Distinguish notes and annotations from the record.

Annotations for both the application and a document within the
application are stored and displayed in separate areas. Application
annotations are viewable at the bottom of the cover panel. Annotations
for documents are viewable in the table of contents that corresponds the
document.

4.  Permit printing and display with annotations on the record,
    annotations following the print of the record, or no annotations.

**Application Annotations**

At the bottom of the cover panel, there is a specific area to make
dossier annotations. The system always shows all current (valid)
annotations in chronological order with the following fields: date,
UserID and text. If some of the annotations or text is not visible,
users can scroll by clicking with the mouse in the scroll bars at the
bottom and right of the screen.

Users can print annotations by selecting the print option and marking
the appropriate box.

**Document Annotations**

Document Annotations are viewable in the table of contents viewer.

Users can print document annotations on the banner sheet by selecting
the print option and marking the appropriate box.

5.  Provide for zooming in and out to easily distinguish hard-to-read
    text and graphics.

**Zoom In**

Users can enlarge the image or part of it by zooming.

To zoom in, users must:

\- Press the \< + \> key

\- Select Zoom In in the viewer menu (position the cursor in the
viewer and press the right mouse button)

\- Select the section of the image that is to be enlarged by dragging
with the left mouse button horizontally and vertically to form a
rectangle, and by releasing the mouse.

**Optimum/Full Page**

By selecting \"Zoom Full Page\" in the viewer menu, the image returns to
its normal size. By selecting \"Zoom Optimum\" in the viewer menu (or by
pressing the \< / \> key), the image fills the whole viewer (this can be
useful if there are black lines around the image or the image opens in
\"zoom\" mode).

To do this, users must:

\- Press the \< / \> key

\- Select Zoom Optimum in the viewer menu

\- Select the section of the image to be enlarged by dragging with the
left mouse button horizontally and vertically to form a rectangle, and
by releasing the mouse.

**Magnifier**

For parts of an image that are very difficult to read, a magnifier is
available. In order to access the magnifier, users must open the viewer
menu (right mouse button in the viewer) and select "magnifier" to
activate. A pop-up will open with a portion of the image magnified. Move
the mouse cursor to select the image portion that is to be magnified.
Select "magnifier" in the menu again to deactivate. The pop-up can be
resized in order to change the magnification.

### Applicant Access

Where access to electronic case file, records and/or metadata
information is provided, measures must be taken to restrict access only
to the records and metadata that an applicant is authorized to view. The
integrity of the electronic case file records and metadata must be
preserved, and the confidentiality of pending patent application
information must be assured.

1.  Provide a means of restricting access to only those case files,
    records and/or metadata that the applicant is authorized to access
    and view.

Application information is protected by an Entrust security architecture
in PAIR that provides:

\(a\) **Authentication** - the process of validating an identity claimed
by or for an entity;

\(b\) **Integrity** -- the ability to verify that data is unchanged from
its source and has not been accidentally or maliciously modified,
altered, or destroyed;

\(c\) **Non-repudiation** -- this ensures that strong and substantial
evidence is available to the sender that the data has been delivered
(with the cooperation of the recipient). The identity of the sender is
sent to the recipient in a manner that is sufficient to prevent either
from successfully denying having possessed the data. This includes the
ability of a third party to verify the integrity and origin of the data;

\(d\) **Confidentiality** -- this ensures that information can be read
only by authorized entities.

USPTO client software and Entrust/Direct provide data encryption and
security to reduce the risk of unauthorized disclosure of confidential
customers who want to access confidential PAIR data by requiring
interested persons to submit by U.S. mail a request to access this data.
The USPTO will provide, by return mail, an Entrust/Direct certificate
and assign it to the same customer number that requests such access. The
PAIR system independently verified Entrust/Direct certificates by
checking the customer numbers.

PAIR uses the USPTO\'s PKI infrastructure to comply with USPTO security
policies and establish a secure communication channel for data that is
transmitted over the Internet. PAIR also uses digital certificates
issued by the PKI infrastructure to establish secure communication
channels to transmit messages between the Entrust/Direct client and the
PAIR server. The PKI infrastructure provides the services necessary to
issue, use, and revoke digital certificates that are needed for secure
electronic communication between the USPTO and its customers.

Each time a customer makes an online request for access, the
user-supplied Entrust/Direct certificate is matched with the one stored
on PAIR. Data can only be viewed after PAIR validates the customer
number. PKI certificates are stored in PAIR database tables and indexed
by customer numbers that the USPTO assigns.

PAIR 4.0 contained enhancements to support implementation of the upgrade
that contained the Examination and Post-Examination (EXPO) database.
Specific software performance problems were fixed in releases 4.1
(reviewed for Section 508 compliance) and PAIR 4.2 (which included the
addition of the Patent Term Extension \[PTE\] page). PAIR 4.3, a pilot
project, was initiated to support distribution of Patent Proof Copies
(PPCs) to USPTO customers prior to final publication.

PAIR was modified to allow customers with active digital certificates
and the Entrust/Direct client installed on their computers to download
PPCs from the PAIR server via the main USPTO website (uspto.gov).

The production system in PAIR 4.4 was enhanced for private customers to
upload commented PPC images for review by USPTO prior to their
publication. The production system in PAIR 4.5 is being enhanced for
private customers to review electronic file wrapper contents that reside
on the USPTO's IFW server.

When IFW is in production in June 2003, the applicant is the only one
who will have access to his applications. No additional public access
will be granted.

2.  Provide a means of identifying and authenticating the applicant,
    preferably through digital certificates and Public Key
    Infrastructure technology.

Public access is through PAIR. PAIR is integrated with Entrust and PKI
infrastructure to provide user authentication and secured sessions.
Entrust provides user authentication, data encryption, and secured
session links between users and PAIR via the Internet.

3.  Log all accesses by applicants in the Use History Metadata Profile
    as an audit trail of these events.

**History**

At the moment an application is opened, the system updates the history
with the UserID, date, time and type of access (either ad hoc or the
document code of the message). The history is viewable for an
application by selecting the History Tab in the application.

**Action Log**

The Action log records system-generated actions such as the request and
the printing and receipt of a paper file. It is possible to record
actions manually by using the "add action" feature.

## Audit Trail

An audit trail, also known as an event log, is the "chain of custody"
that records the "who, what, and when" for each action or event,
including creation or receipt, processing, access, distribution,
dissemination, migration, transfer and disposal of an electronic record.
As such, an audit trail essentially captures specific metadata that
documents the intent and result of activities related to electronic
records. The audit trail can provide an independent
(computer-controlled, not human-controlled) element of proof that
policies and procedures were followed and that the integrity and
confidentiality of the information was not compromised. From a legal
perspective, an audit trail can be used as "management data" to help
prove the authenticity of a record for admissibility in evidence in an
interference or appeal proceeding. The audit trail information for
accesses and events related to intellectual property case files should
be documented using the metadata in the Use History Profile.

### Use History Profile

As set forth in Section 2.1.1.2 Metadata Profiles, it is recommended
that a Use History metadata profile be created for each electronic
record, and encapsulated in the electronic record, to serve as the audit
trail of accesses and events related to the electronic record. The Use
History metadata profile logs accesses and events (such as migrations of
electronic records). These provide a basis for: a) establishing the
reliability and general trustworthiness of electronic records, b)
meeting the test of authenticity in admissibility, including appeals,
and c) tracking or researching events related to proving that integrity
has been preserved, that confidentiality has been protected, that system
procedures have been followed and that the management of electronic
records has been conducted in a trustworthy manner.

### Use History Profile Creation and Update

1.  Create a Use History Profile at the time the electronic record is
    created and log the "creating" event in the Use History Profile.

2.  Log each access to an electronic record in the Use History profile.

3.  Log to the Use History Profile each event that receives, creates,
    updates, disposes of or is otherwise material to the use and
    maintenance of the electronic record.

4.  Log each copy, reformat and transfer event in the Use History
    Profile

5.  Log the disposition action and date to the Use History File when
    retention schedules are applied and electronic records are disposed.

6.  Log the types of electronic records transferred, the electronic
    record count transferred and the date transferred when electronic
    records are transferred to archival storage.

As mentioned in section 2.2 of the Compliance Paper, IFW supports the
monitoring of record access and usage by means of an audit trail.
Processes and procedures, to be deferred for future enhancements, will
be developed and integrated with IFW to support reformatting, migration,
disposition and archival storage for long-term retention and disposition
of electronic records.

### Link to Other Information System Tracking or Event Logging

The system shall link to USPTO workflow or process tracking information
systems to extract or capture information related to maintenance events,
such as reassignments of a patent from one party to another.

Processes and procedures, to be deferred for future enhancements, will
be developed and integrated with IFW and other business area AISs to
support identification, extraction, encapsulation, and long-term
retention of relevant electronic record information.

## Vital Record Backup and Recovery

Intellectual property case files are considered vital records, that is,
they must be available for purposes of reconstructing the business of
USPTO should a disaster occur that damages the primary electronic case
files. To ensure that this vital information is backed up and available,
specific policies must be defined and specific procedures implemented
and practiced. A vital records backup copy of all electronic records and
associated metadata must be made and available for disaster recovery
purposes. A backup copy of all information systems and operating
software used to manage the electronic records will also be available
for disaster recovery.

Complete backup for IFW will be available to resume processing after a
breakdown or degradation of IFW.

The IFW database will be copied every production day (Sunday-Saturday).
On Saturdays, the back-up job will copy all IFW file directories except
the operating system directory. There will also be a back-up job that
copies the database and can be manually started whenever needed.

Off-site back-up tape storage procedures will follow established UPSTO
practice.

1.  Develop automated backup policies and procedures for electronic
    records, metadata and associated information systems and operating
    software.

2.  Assure that record material and non-record material are not
    intermingled on the same media.

3.  Assure that records of the same disposition and retention period are
    stored on the same media.

4.  Create a vital records backup copy of all electronic records and
    related metadata.

5.  Create a backup copy of all operating software and information
    systems that process and maintain electronic records and related
    metadata software.

6.  Store all vital records backup copies in a geographically separate
    location from the primary media.

7.  Provide electronic and physical (where appropriate) labeling that
    allow ready identification of the location of and access means to
    the backup media.

8.  Develop procedures and implement automated and manual capabilities,
    as needed, that allow for full recovery of electronic records and
    related metadata in the event of a disaster.

9.  Maintain metadata and/or file directory that allow access to both
    the primary and backup media for each electronic record, as well as
    for any associated hard copy records.

10. Apply retention management, including disposal of electronic records
    and related metadata, consistently for the backup media and the
    primary media.

11. Secure the vital records backup media and protect it from
    environmental and other potential harms, including:

    a.  ordinary hazards, such as fire, water, mildew, rodents, and
        insects;

    b.  human-made hazards, such as theft, accidental loss, sabotage,
        and commercial espionage;

    c.  disasters, such as fire, flood, earthquake, wind, and explosion;
        and

    d.  unauthorized use, disclosure, and destruction.

## Records Retention

The USPTO will ensure that electronic records are retained for as long
as defined in the USPTO Comprehensive Records Schedule. Record
retentions follow established, approved schedules and cannot be altered
without review by the agency Records Officer. The Business Area Records
Steward and the USPTO Records Officer initiate the Records Scheduling
activity. Retention procedures will include provisions for scheduling
the disposition of all electronic records and their related
documentation and indices.

The information in electronic records systems will be scheduled as soon
as possible but no later than one year after system implementation.
Provision will be made for transferring a copy of the electronic records
and related documentation and indices to archival storage. It is also
important to establish procedures for regular recopying and reformatting
and the performance of other necessary maintenance to ensure the
retention and usability of electronic records throughout their life
cycle.

Maintaining the integrity of intellectual property records is essential
for ensuring the protection of the intellectual property rights and the
value of the inventor's business assets. For these reasons, checks and
balances must be in place to assure the preservation of the integrity,
authenticity and trustworthiness of the USPTO's records over time. This
may be accomplished by managing and protecting the electronic records
from any loss, alteration, removal, or premature destruction. Since
evidence of record tampering may not be as readily identifiable with
electronic records, as it might be with paper records, it is even more
important that the controls are in place to adequately protect and
preserve the record.

The migration to electronic record storage will not alter the need and
timelines to retain patent case file records. Storage needs will be
based on whether the case is pending, patented or published, abandoned
but referenced in a published or patented file, or abandoned but not
referenced in a published or patented file.

### Case File Retention

For the scheduling of case file retention, the complete electronic
intellectual property case file is considered to be a single entity,
and, as such, the complete case file will be managed and preserved using
a single retention period.

The VERA system will permit complete case files to be encapsulated for
retention. Following encapsulation, the file will be managed and
preserved using a single retention period.

### Retention Period

Retention periods vary based on the status of the case file, i.e.,
whether the patent is issued or abandoned, and also based on the period
of time during which the application was filed. The determination of
retention period for any given record is a matter of business need,
legal requirement, or historical value. In other words, is the record
needed to conduct business? If yes, it will be retained so long as that
need exists. Legal requirements and historical value are two factors
that determine the retention period of a record.

Case files should be retained in situation where they are pending, after
abandoned by the applicant for a period of 23 years, and after grant or
publication as a published application (or mention of the case file in a
granted or published case) for the life of the Republic.

### USPTO Case File Retention Schedules

Retention periods for intellectual property case files and records,
whether electronic or paper-based, can be described as "event driven."
For example, a retention period does not start until the prosecution of
a pending patent application is completed---when a patent has been
granted or abandoned. The duration of the retention period is also
dependent on whether the patent was granted or abandoned. The Program
Office that maintains control of the records must consult with the Data
Administration Division in establishing retention periods.

Suggested retention periods are provided below.

For patent case files showing the prosecution of applications for, and
the granting of, a patent:

1.  Files include the original application, the patent drawing, and all
    materials relating to the prosecution of the application and
    subsequent actions by the USPTO. Includes patent files for reissues.

IFW will maintain an electronic image record of all papers, currently
stored in paper files, submitted by the applicant or created by the
USPTO.

2.  Closed (granted) patent case files selected by the USPTO Director
    are permanent and transferred to archival storage after 40 years.

The transfer of e-records will follow the current archival storage
timelines.

3.  All other closed (granted) patent case files are destroyed 40 years
    after closure.

Destruction of closed patent case files will follow the current
timelines.

For abandoned patent applications that do not result in the grant of a
patent:

1.  Abandonment occurs when the applicant; fails to pay fees or submit
    documentation requested by the examiner within the allowed time;
    when claims made for the invention are not patentable or were
    previously patented; or when another applicant has filed an
    application for the same invention and can demonstrate an earlier
    date for the conception of the invention.

2.  Applications retained because they are referred to in another
    application that was granted are disposed of with the patent case
    file in which it is cited.

3.  Abandoned applications are destroyed 23 years after closure.

### Determine Retention Period

The information system that captures the event that triggers the start
of a retention period, such as the granting of a patent, will populate
the appropriate Disposition metadata fields in the appropriate
Electronic Record Profile.

1.  Capture an event that triggers the beginning of a retention period
    and automatically determine the values for and populate the
    Disposition attributes "Instruction Code" and "Action Date" in the
    appropriate Electronic Record Profile with the appropriate retention
    information.

Trigger events are that the case has been published or patented; they
indicate that the file needs to be retained and that the entire file is
publicly accessible. Mention of the case in another published or
patented file or attachment of a retention label to the file indicates
that the file needs to be maintained based on the referenced file.

a.  Instruction Code relates to an action, such as "disposal,"
    "transfer" or "hold."

PALM will include the information concerning the status of the case
file.

b.  Action Date is the date that the "instruction" is to occur.

PALM, the Office "tickler" system, needs to include the date of disposal
or transfer.

2.  Allow modifications to disposition attributes. Modifications will be
    restricted to personnel that are authorized (e.g., a Supervisory
    Patent Examiner or the Managing Attorney for a Law Office) by the
    USPTO Records Officer or equivalent/designate, and will be tracked
    as part of the Use History Profile metadata for each electronic
    record.

Role privileges define what actions a user can take. Linking privileges
to access controls will be provided by user password use.

3.  Provide for the capability to perform selective, authorized mass
    updates to the Disposition attributes, such as when retention
    schedules are modified. For example, if the transfer period to
    permanent archival storage for granted patents was changed from 40
    years to 30 years, allow for the mass change of the transfer "Action
    Date" to permanent archival storage for all affected electronic
    records.

### Records to be Retained

All documentary record materials received or created by the USPTO and
working files that require preservation will be stored and the integrity
preserved for the full retention period.

1.  Ensure that the official, legal record copy of each electronic
    record, including related metadata, plus a vital records disaster
    recovery backup copy, will be retained.

VERA will encapsulate records stored outside of IFW.

2.  Ensure that the content and structure of the record is preserved so
    that a human readable display or print of the data can be
    reconstructed over the life of the record.

Image file format in IFW is viewable with a viewer. Support or other
systems (PALM Pre-Exam) will need to be maintained in order to provide
long-term access.

3.  Preserve the context (the circumstances under which the record was
    generated and stored) over the full retention period.

IFW stores the context of the record.

4.  Ensure that the chosen record format(s) will provide for record
    availability for the full retention life of the record, such as an
    industry standard or widely supported defacto standard file format.

The storage format for IFW images is the industry standard (TIFF)
format.

### Disposal

The requirements for disposal of electronic records and associated
metadata and backup copies are summarized below. Disposing will include
complete physical destruction to include overwriting data or destroying
physical media with a technique that meets or exceeds the DOD5220.22-M,
National Industrial Security Program Operating Manual standard, of all
electronic record information, not just logical deletion of metadata and
pointers to the electronic record. Further detailed information on the
National Industrial Security Program can be found at
http://www.dss.mil/isec/nispom.htm. Note: If an electronic record is
hyperlinked to another electronic record, the record will be deleted
only when it is eligible for deletion by the referencing electronic
record. The Business Area Records Steward will preserve permanent
records and promptly dispose of or retire temporary (non-permanent)
records.

1.  Provide for access to and screening of the disposition action for
    electronic records by authorized personnel using the Disposition
    Action metadata in the appropriate electronic record Profile.

2.  Periodically produce electronic or hard copy lists for approval of
    electronic records, whose action codes and dates indicate a pending
    disposal, produced either automatically based on predetermined
    criteria or upon manual initiation by authorized personnel.

3.  Provide for electronic approval of disposal actions, either using
    disposal lists or via manual entry by personnel authorized by the
    USPTO Records Officer or equivalent/designate.

4.  Provide for a "confirmation" action prior to actually beginning the
    disposal of electronic records.

5.  Provide for the electronic initiation of the disposal process for a
    specified list of electronic records, either using an information
    system or employing a separate utility specifically designed for
    disposal actions.

6.  Extract and save, for a to-be-specified period of time, a subset of
    the Use History Profile metadata documenting the disposal action
    taken for each electronic record (disposal audit trail).

7.  Sample (audit) disposed of electronic records. Attempts to access
    disposed of electronic records will be conducted in order to assure
    that the disposal action has been accurately and completely carried
    out.

8.  Disposal of a case file will include the complete contents of the
    case file, all metadata associated with the case file, and the vital
    records backup of the case file.

9.  Delete a case file or record that is hyperlinked to another case
    file only when it is eligible for deletion by the referencing case
    file. For example, an issued patent references an abandoned patent
    case file; the abandoned case file will be deleted only when it is
    eligible for deletion by the referencing case file.

Ordinarily, records are not disposed of during their life at the USPTO.
Electronic records are maintained in an active state during prosecution,
and in a suspended state thereafter in the USPTO records center. In that
later state, very few changes are made in the records, perhaps the
addition of a maintenance fee paper or notice of litigation.

Eventually, the documents are transferred to NARA, after 40 years, in a
format that they will accept. Since NARA is still developing its
electronic record policies, any decisions dealing with formats for that
transfer are deferred for now.

The exception to the lack of disposal occurs when a document that was
placed on the system should, by law, be removed. The most telling
occurrences of this type are when a patent application has been scanned
into the IFW system, and then after a few months, a security agency has
recommended that it be placed under a secrecy order by the Director of
the USPTO. Secrecy Order (SO) applications are treated the same as
national security applications, except that the latter are known to be
secret from the start, and thus are never placed on an electronic
database system on a network.

The SO applications are "discovered" to be secret, as it were, after
being placed on the IFW system and partially processed. Thereafter, they
must be removed from the system once the SO is put into effect. These
documents must be removed from the system through obliteration methods
that are spelled out in the technical directions. The metadata must also
be removed, except for a small notation that the case is no longer
pending.

Years later, when the SO is removed, the application will be rescanned
into whatever processing system is in place at the time.

The following steps 1 through 9 of this section are to be followed when
the disposal of SO applications takes place.

**Expungement Items**: A special class of submissions consists of items
that are presented in 37 C.F.R. 1.59 and must be expunged from the
record. These documents, which may not include any parts of the
application as filed, are specially treated, since it is known that they
will be expunged from the application. Therefore, they are not scanned
into the electronic systems and are treated as artifacts from the
beginning. The issue of disposal of the items from the electronic
systems should not arise.

Deletion, disposal, and/or expunging of an electronic record will be
done according to the security level assigned to the respective data.
Metadata and audit trails will be used to support that the appropriate
actions have taken place.

Disposal or expungement will include complete physical destruction of
data including overwriting of data or destruction of physical media with
techniques that meet or exceed section DOD 5220.22-M of the National
Industrial Security Program Operating Manual of the Department of
Defense.

Steps 1 through 9 of this section will be followed when an electronic
record is to be removed from the IFW repository.

Processes and procedures, to be deferred for future enhancements, will
be developed and integrated with IFW and other business area AISs to
support disposal of temporary and non-record electronic records.

**USPTO Security**

According to USPTO security, the following procedures need to be done
under the following scenario: "Clearing NSI data from within the Oracle
RDBMS."

The process of clearing NSI data from the IFW Oracle RDBMS is fairly
straightforward and if coded properly, should require no additional
software depending upon the chosen implementation of the project team
for persistent storage of patent data (potential NSI data). Typical
methods of data storage are as follows.

**Alternative 1:** Patent data is stored entirely within the Oracle
RDBMS.

**Alternative 2:** Only a reference or a point for patent information is
stored in the RDBMS and the actual patent information is stored
physically on a disk storage device (presumably a magnetic disk).

In the case of Alternative 1, the Oracle RDBMS has been designed around
the several core security principles, one of which is referred to as
*Object Reuse.* During Oracle's common criteria (CC) evaluation, Oracle
demonstrated enforcement of the CC Object Reuse requirements. These
requirements specifically ensure that residual information protection
(RIP) mechanisms are implemented; ensuring that a block level recovery
of deleted information is not possible.

Common criteria defines residual information protection (RIP) as:
"...the need to ensure that deleted information is no longer accessible,
and that newly created objects do not contain information that should
not be accessible. This family requires protection for information that
has been logically deleted or released, but may still be present within
the TOE."

This enforcement of RIP capability is implemented by default in Oracle
and requires no additional configuration or software to be applied to
the server.

In order to successfully implement a standardized Oracle deletion
method, it is recommended that IFW develop a centralized secrecy
enforcement procedure. This would be implemented as a reusable Oracle
stored-procedure that performs a delete of the NSI data from all related
tables. Implementing this delete functionality in a
configuration-managed stored procedure ensures that NSI data will be
removed from the Oracle server consistently every time this operation is
required. It is recommended that the following steps be implemented as a
best practice:

**Step 1:** Create an Oracle stored-procedure using PL/SQL

**Step 2:** This procedure should delete all records from the RDBMS that
may contain NIS data associated with a unique idea that is passed to the
stored procedure.

**Step 3:** Include a commit command in the stored-procedure to complete
the deletion transactions and clear NIS targeted data from the rollback
segment.

The delete functionality is part of the Oracle ANSI/1992 SQL command
set. This functionality can be implemented with either SQL or PL/SQL
(for modular design and consistency, PL/SQL is recommended). Below is an
example. Please note that this example is illustrative and cannot be
taken literally because the code is dependent on the table structure in
IFW.

**Example**:

SYNTAX: Delete from {*tablename*} where {*condition*}; commit;

EXAMPLE: Delete from *patents* where *patent_id = 123;* commit;

Although this example is relatively simple, the actual SQL statement
will likely be more complicated depending on the IFW data model. If
necessary, the Booz Allen Hamilton (BAH) Enterprise Security Engineering
team can assist in writing the procedure with the IFW EPO/USPTO team.
However, the BAH team must first become familiar with the IFW data
model.

Oracle's security evaluation documentation asserts that this is all that
is required and that additional measures such as "triple overwrite" or
using the crypto package to overwrite the record with an encrypted
string is not necessary and will not deliver any additional protections.

### Disposal of Working Files

Working files are managed outside of the electronic record. However,
they should be disposed of at the earliest opportunity. Working files
shall be deleted when the prosecution of the intellectual property
application is completed (issuance, registration or abandonment), or
earlier when they have no expected reference value and are not subject
to a hold order. Deletion will include complete physical destruction
(overwrite or disposal of a unit of media) of all electronic record
information, not just logical deletion of pointers to the electronic
record. Note: Do not track the disposal activity of working files in the
Use History Profile audit trail.

The system shall provide a method for authorized users to dispose of
working files that are not required for preservation as records.

The working files are paper files that are part of the IFW system; they
are not subject to disposal by electronic means. The system will give a
reminder to the examiner when it is time to dispose of the working
files, after the application has been abandoned, issued or otherwise
finishes prosecution. The examiner will be responsible for taking the
paper working file and passing it on for shredding or other destruction.

## Migration

Electronic records must remain accessible and transferable despite
changes in information technology. The content, structure and context of
the electronic records must be able to be displayed, printed or
otherwise reproduced, as they originally were captured, for the complete
life cycle of the record.

Please see the life cycle discussion in the Introduction. Processes and
procedures, to be deferred for future enhancements, will be developed
and integrated with IFW and other business area AISs to support
migration of electronic records. These will include copying,
reformatting, and/or transfer procedures for electronic records to
ensure that they do not become inaccessible over time because of
software and/or hardware obsolescence and deterioration.

### Copy, Reformat, and Transfer

Technology is certain to change and advance with a frequency that will
require multiple migrations of electronic records over most retention
periods. This will include the copying and reformatting of the
electronic records to new media and/or the transfer to new information
systems or new hardware and software.

1.  Preserve the content, structure and context of the electronic
    records and the related metadata accurately through copy, reformat
    and transfer migrations.

2.  Copy and reformat, if required, electronic records at the time they
    are moved from one information system or one software and or
    hardware system environment to another.

3.  Reformat electronic records, as required, when new storage devices
    or media are utilized.

4.  Read a statistical sample, when using magnetic tape for either the
    primary or vital records backup, annually of all reels of magnetic
    tape to identify any loss of data and to discover and correct causes
    of data loss.

5.  Recopy vital electronic records, when using magnetic tape for either
    the primary or backup of the vital record,

    a.  Every ten years, or;

    b.  When the annual readability sample of the respective magnetic
        tape discloses ten or more temporary or read errors.

6.  Transfer electronic records when the current software is upgraded or
    a new or upgraded electronic records file management system is
    installed.

7.  Ensure the reliability and integrity of reformatted, copied, and
    transferred electronic records by employing a strict quality control
    procedure that may include bit/byte comparisons and comparisons of a
    NIST-approved hash digest algorithm.

8.  Document fully all actions taken when reformatting, copying and
    transferring electronic records and include this information in the
    Use History Profile metadata associated with each electronic record.

9.  Provide for vital electronic records backup and disaster recovery by
    creating two copies (primary and backup) of electronic records at
    the time of reformatting, copying, or transfer and storing one copy
    at a separate accepted USPTO off-campus location.

### Media Management

The manufacturer's specifications for both the *"pre-written"* media
life and the *"post-written"* archival life must be followed. For
further detailed information see 36 C.F.R. 1234.

1.  Determine and follow the media manufacturer's specifications for
    pre-written and post-written life. The *pre-written* media life is
    the time period from the date of manufacture until the date after
    which the *initial* writing of information to the media is not
    recommended. The *post-written* archival life is the period from the
    date of manufacture until the media will be copied to a new unit of
    media.

2.  Store the physical media in accordance with the manufacturer's
    environmental requirements for temperature and humidity controls.

3.  Check the media periodically for read-errors and read-error
    correction rates, even if the manufacturer's specifications for
    temperature and humidity controls are followed.

4.  Copy the digital data to "fresh" media, when read-error correction
    rates meet or exceed the tolerance level or when the post-written
    archive life is imminent. This practice of copying the records
    before the media expires is an effective preservation technique only
    as long as the existing media is readable.

## Transfer to Archival Storage

The USPTO has established policies and procedures to ensure that all
records and their documentation are retained as long as needed. These
policies and procedures will be expanded as needed to incorporate
electronic records. Procedures for electronic records will be
periodically reviewed and will be based upon best practice reviews and
state of the art archival storage capabilities.

1.  Transfer only the "selected" electronic records and associated
    metadata to permanent archival storage, as designated by the
    Instruction Code and Action Code in the Electronic Record Profile.

2.  Generate all required forms to transfer records.

3.  Provide for the transfer of electronic records into the file formats
    and media types appropriate for permanent archival retention.

4.  Verify the quality of the records and associated metadata being
    transferred.

5.  Update the Transfer Profile metadata as a means of keeping a
    detailed audit trail of records transferred to permanent archival
    storage.

Processes and procedures, to be deferred for future enhancements, will
be developed and integrated with IFW and other business area AISs to
support the transfer of permanent electronic records to archival storage
for long-term retention and disposition. These procedures will be based
upon best practices and archival media storage requirements.

## Records Hold

Records will be held (not deleted) when litigation, audit or
investigation is imminent or would be foreseen by an average person.
Only the USPTO Records Officer or equivalent/designate will authorize
selected personnel to create, change, or release a hold order.

Occasionally, a government agency (or other organization) is subject to
a "hold" order from a court in the event that litigation affecting the
Offices records is pending or imminent or where an average person would
foresee it. The records present are to be maintained unchanged until the
"hold" is lifted.

The Office is obliged to honor that hold order. Since the Office does
not modify or delete the image records, there is merely a matter of
making note that they are to be subject to the order. The metadata,
however, is modifiable. Copies of metadata records that are subject to
the hold order will be made, authenticated, and "frozen", while the work
of the Office continues on other copies.

1.  Identify which records are subject to the hold.

2.  Mark the metadata for the records as requiring a hold; identify the
    specific hold(s) that affect the record; and automate the release of
    the record, once the hold order is lifted (one record may be subject
    to multiple hold orders.)

# Glossary

**Electronic Record** -- The term "records" is defined below. As per 44
U.S.C. 3301, "records" also encompasses records that are in an
electronic format. IFW stores records as TIFF images in an electronic
format. Other image formats, such as XML, may be used in the future.

**Electronic Record Maintenance** -- The Technical Standards and
Guidelines for Electronic Records Management (TSG-ERM) states that
electronic records must be maintained in a proscribed, acceptable manner
in order to retain their admissibility as a record of the agency.

**Evidentiary Copy** -- For legal purposes, the creation and maintenance
of evidentiary copies of records are essential for the effective pursuit
of legal remedies in a court of law. The evidentiary copy of a record is
a copy that is not the official copy, but because of its position in the
chain of custody, it has, or may have, information pertinent to the
information on the record copy.

**Official Record Copy** - The official record copy is that copy which
the USPTO designates as the one to be used during the prosecution of
patent applications and it is to be relied upon as the true copy of the
record.

**Indirect records -** The term "records" is defined below. Derivative
information or indirect records are secondary sources and are not the
original record. They are documents that contain information that was
originally provided on the record.

**Records** - The term \"records\" includes all books, papers, maps,
photographs, machine-readable materials, or other documentary materials,
regardless of physical form or characteristics, that are made or
received by an agency of the United States government under federal law
or in connection with the transaction of public business and are
preserved or appropriate for preservation by that agency or its
legitimate successor as evidence of the organization, functions,
policies, decisions, procedures, operations, or other activities of the
government or because of the informational value of the data in them.
Records also include library and museum materials made or acquired and
preserved solely for reference or exhibition purposes. Extra copies of
documents are preserved only for the convenience of reference, and
stocks of publications and of processed documents are not included. See
44 U.S.C. 3301 for more information.

**Records Management** - The term \"records management\" includes the
planning, controlling, directing, organizing, training, promoting, and
other managerial activities involved with respect to records creation,
records maintenance and use, and records disposition, in order to
achieve adequate and proper documentation of the policies and
transactions of the federal government and effective and economical
management of agency operations. See 44 U.S.C. 3301 for more
information.

# APPENDIX 1 - DRAFT MODEL OF QUALITY ASSURANCE AND QUALITY CONTROL PROGRAM {#appendix-1---draft-model-of-quality-assurance-and-quality-control-program .unnumbered}

Please refer to section 2.1.6 in this paper for more information on a
draft model of a quality assurance and quality control program proposed
to be implemented at the USPTO upon the completion of the IFW Prototype
and the beginning of IFW Production.

# APPENDIX 2 -- VERA DOCUMENT {#appendix-2-vera-document .unnumbered}

![](media/image2.png)

**Electronic Records Management**

***"From Soup to Nuts***

***Or***

***From Digital Birth to***

***Digital Denouement"***

**Concept Paper**

Purpose

The purpose of this document is to describe an architecture for USPTO
Electronic Records Management (ERM) and electronic record keeping
functions that supports managing the electronic records life cycle.
Electronic Records Management is the broadest term that refers to
electronically managing records on varied formats. Electronic Record
Keeping focuses on electronically managing electronic records and is
considered a subset of Electronic Records Management. The USPTO records
management requirements are defined at a business area level and
therefore cross Automated Information Systems (AIS). The Technical
Standards and Guidelines for Electronic Records Management (TSG-ERM)
describes specific requirement areas in detail. These business area
requirements need to be addressed by each AIS in order to ensure that
all elements of Electronic Records Management are being met for that
particular business area.

Challenge (a.k.a. Opportunity)

To achieve the USPTO\'s vision of the future electronic workplace, where
most internal and external transactions are performed electronically,
proper and thorough electronic records management becomes absolutely
essential.  The USPTO is engaged in numerous projects that produce
electronic records, including the successful deployment of electronic
filing systems for Trademark and Patent applications where the original
documents are submitted in an electronic format.  These records, that
are "born digital," must be managed properly.  Requirements for
maintaining the integrity of all intellectual property information;
protecting confidentiality; meeting Federal laws and regulations for
records management; and attaining legal admissibility and customer trust
must all be achieved through automated systems that are developed to
support the USPTO\'s business operations.  To effectively implement
electronic commerce, the USPTO must carefully define highly structured,
policies, procedures, and practices for managing electronic records. 
Records management standards existing today generally only address
paper-based processes and must be refined to support the future
electronic workplace.  The USPTO will actively participate in the
research and development of standards to support long term electronic
records management and access strategies.

ERM Requirements: A Business Area Solution

Commensurate with current business practice, business areas will
continue to be the proper owners or stewards of their records. Long term
storage and migration of electronic records from one source to another
are electronic records management requirements. An archival solution for
official electronic records should be defined at the broader, business
area level and not within each AIS that stores official records. An
economy of scale as well as risk mitigation can be defined using this
approach and stovepipe solutions are avoided. Addressing the electronic
records management archival storage at the business area level supports
the creation, maintenance, use, and disposition stages of the records
life cycle. The USPTO will implement a DOD 5015.2, Design Criteria
Standard for Electronic Records Management Software Applications -
compliant Commercial Off The Shelf (COTS) tool to support the USPTO
Electronic Records Management functions, to further mitigate risk. By
using existing certified COTS technology, the USPTO is able to avoid
building electronic records management processes that have already been
developed and tested. This also makes the adaptive software maintenance
activity on existing AISs easier once the business area records steward
identifies the elements that comprise an electronic record.

Records Management Stewards and Custodians

**Business Area Record Steward**: Designated from within business areas,
the Business Area Record Steward is ultimately accountable for the
business records. Business areas that exercise programmatic control over
records have record stewardship responsibilities. The Business Area
Records Steward assigns the Operational Record Stewards for all business
functions within their organization.

**Operational Record Steward**: The individual/organization responsible
for the content and business rules surrounding the management of
electronic records. As a subject matter expert, the record steward
identifies records from a business perspective, actively participates in
records administration including initiating archival processes, and
facilitates record sharing outside the stewards organization. Stewards
supply descriptions, definitions, domain and security requirements for
their subject records.

**Technical Record Steward:** The individual/organization responsible
for the on-line, near-line, and off-line storage and processing of
electronic records. The Technical Record Steward is accountable for
where and how to access the subject electronic records for the full life
cycle of those records. They are responsible for the following items:

-   Maintaining custody or control of the records, software, and other
    components used to store, process, communicate, and present records;

-   Ensuring the physical integrity of the records;

-   Safeguarding the storage media;

-   Carrying out media sampling and media problem resolution; and

-   Acting as Records Management contact.

The functions carried out by the Technical Record Stewards include many
of those traditionally performed by Automated Data Processing
organizations such as System Development and Maintenance Managers, Data
Base Administrators, and Data Maintenance Branch/Operations staff. These
functions would include coordinating the annual sample of the universe
of media and planning media and software dependency migrations.

Vital Electronic Records Archive

The Vital Electronic Records Archive (VERA) supports the USPTO
Electronic Records Management architecture through the use of a
*federated* and *distributed* set of Business Area Records Repositories
that store metadata about electronic records. It includes active records
being processed by the USPTO business areas as well as records that have
been "retired" (no longer active) and taken off-line or near-line. In
accordance with the Code of Federal Regulations, for records that have
been taken off-line, at least two copies, a master and a backup copy,
will be stored at physically separate, environmentally controlled, and
distant locations. Random audits, annual sampling of the entire
collection (collection meaning the universe of off-line and near-line
media that holds archived records), and other administrative
requirements for reporting and management of electronic records are
performed in these repositories. The repository will serve as a data
base of pointers for records physically stored in AISs or archived. The
repository will be kept and maintained permanently for tracking official
records.

**Virtual "Shared" Staging Area:** This is storage space created as
needed for a business area to physically aggregate all case file related
records and metadata. The virtual shared area will serve as a temporary
stage to facilitate copying of the complete record onto offline media to
satisfy long term retention requirements. It works in concert with the
Electronic Records Management/VERA metadata data base. The virtual stage
can be shared across business areas because it supports common
requirements for Electronic Records Management. Any software
dependencies that are not germane to the sense of "recordness" could be
eliminated and/or reduced at this time. The need to maintain and
preserve records in their native format as well as all subsequent
migration formats is reduced or eliminated. The staging area will also
be used to retrieve archived records and to facilitate migrations of
records.

Proposed Solution

The USPTO plans to implement a passive electronic record keeping system
to capture its Patent and Trademark electronic records. By passive
record keeping, the USPTO intends to have the least intrusive,
agent-based capture of the electronic records and related metadata as
can be implemented. Only mandatory metadata of the records will be
prompted for user's input if that information is not already captured in
other systems. As the USPTO moves towards a paperless office it will not
be replacing current workflow systems but rather building the front-end
interfaces into current systems (e.g., the Office Action Correspondence
System) to capture required electronic record information.

The USPTO AIS users expect to continue to interact with our current
systems in the manner that they have become accustomed. The AISs will be
integrated with the electronic record keeping system through the use of
Application Program Interface's (APIs) from a COTS product. The AIS
development team will be responsible for "putting" information
(pointers, metadata, etc.) into the electronic record keeping metadata
data base via the API. The "fetching" of this information and the record
information being pointed to would be performed when the archive copy of
the official electronic record is created.

Archiving of complete, official, electronic records becomes a critical
stage in the life cycle. Archiving can be easily achieved during the
post-prosecution phase (whether granted or abandoned) of a Patent or
Trademark case file. At this phase, the complete record is distributed
across multiple related AISs.

By aggregating the electronic records into a "staging area" we enable
the official record to be archived and to overcome many technical
challenges, including synchronized disaster recovery backup of active
records. We also enable the continued business use of the information
stored in the respective AIS while preservation and maintenance of the
official record can be managed at a business area level and not
redundantly implemented across all AISs. This archival approach also
enables records with the same retention and series to be stored in the
same physical media. It follows recommended records management best
practices of not intermingling record with non-record information. This
practice makes disposition (denouement) of the records easier.

During the transition period (from paper to electronic record keeping),
the USPTO will be keeping duplicate records in both paper and electronic
form, although only one is designated as the official record. Some
records will require a mixed media mode of records management. Some
parts of the complete record will be in paper and some parts in
electronic form.

Summary

Utilize a DOD 5015.2 certified COTS product to serve as the metadata
data base repository to store pointers to electronic records physically
stored in USPTO AIS workflow systems

Integrate the metadata database with USPTO AISs through APIs

Integrate a post-prosecution archival approach, Vital Electronic Records
Archive (VERA), to support the requirements for long-term retention and
intellectual control of electronic records

Taken together, requirements for the complete life cycle of an
electronic record can be supported and managed while mitigating many of
the risk factors. This approach minimizes the impact on the business
area users of the AISs supporting the workflow for prosecution of
applications. This approach also minimizes the impact (cost and time) of
redundant processes having to be built and maintained in each AIS to
support the complete life cycle of a record.

This solution also supports the USPTO strategic programmatic goals of an
end-to-end electronic pipeline and paperless office, enabling
e-Government, and providing world class operations for data recovery and
remote archiving.

Attachment 1 is a pictorial representation of this concept.

**For further information contact Walter Bohorfoush, USPTO Electronic
Records Management Team Leader, Data Administration Division, Office of
Data Management, Deputy CIO for Systems Modernization, Office of the
Chief Information Officer, at (703) 308-7388.**

**[Attachment 1]{.underline}**

![](media/image3.wmf){width="6.429166666666666in"
height="5.538888888888889in"}

[^1]: The IFW system or procedure that is used to satisfy the
    requirement of the TSG-ERM is indicated in Arial font, is indented,
    and appears beneath the statement of the requirement.