Dierist
`
`Implementation Reference IVI aiiua
`
`Carl Lagoze
`
`Erin Shaw
`
`James
`
`Davis
`
`Dean
`
`Krafft
`
`May
`
`1995
`
`Abstract
`
`infrastructure
`
`for
`
`We describe the architecture and implementation of Dienst
`protocol and server
`that pro
`the World Wide Web Dienst
`document
`vides distributed document
`is based on
`libraries over
`model
`incorporates unique document names multiple document
`formats and multiple
`that
`document decompositions
`Interoperability among Dienst servers provides the user with
`sin
`gle logical document collection even though the actual collection is distributed across multiple
`servers The Dienst protocol uses HTTP the protocol of the World Wide Web as
`transport
`layer making Dienst servers accessible from any WWW client Dienst
`is currently used as the
`number of U.S
`distributed computer science technical
`library by
`report
`universities This document
`guide for Dienst site administrators and implemen
`is intended as
`the architecture of an individual server and
`library systems It describes
`tors of other digital
`network of Dienst servers and includes the server
`installation instructions Appendices describe
`issues and retrospective conversion of the Cornell
`report collection
`
`copyright
`
`technical
`
`Computer Science Department Cornell University Ithaca NY 14853 lagozecs.cornell cdii
`tComputer Science Department Cornell University Ithaca NY 14853 shawcs.cornell cdii
`Institute Cornell University Ithaca NY 14853 davisdri.cornell.edu
`tXerox Corporation Design Research
`Computer Science Department Cornell Univeristy Ithaca NY 14853 deancs.cornell cdii
`
`Petitioner IBM – Ex. 1014, p. 1
`
`

`
`Contents
`
`Overview of Dienst
`
`Organization of this document
`
`Dienst document model
`names ...............................
`Unique document
`3.1
`...............................
`3.2 Multiple document
`formats
`3.3 Document decompositions ................................
`
`4.1
`
`Dienst server architecture
`Components of Dienst server .............................
`Interaction among Dienst servers ............................
`
`4.2
`
`Dienst user interface features
`
`Installing
`
`basic Dienst system
`Considering copyright
`issues
`IDs for your site
`Obtaining publisher
`Creating your document
`database
`directory structure
`6.3.1
`Set up
`6.3.2 Make the bibliography files
`Downloading the Dienst server
`Configuring your server
`
`6.5.1 Modifying config_constants.pl
`6.5.2 Writing code in custom.pl
`Declaring storage formats in custom.pl
`6.5.3
`Checking the configuration and database
`Indexing your document
`database
`Starting your server
`
`6.1
`
`6.2
`
`6.3
`
`6.4
`
`6.5
`
`6.6
`
`6.7
`
`6.8
`
`6.9
`
`Testing your server
`6.10 Registering your site
`6.11 Downloading Web server
`6.12 Configuring your Web server
`to work with Dienst
`6.12.1 Creating the home page
`6.12.2 Configure NCSA httpd
`6.12.3 Configure CERN httpd
`6.13 Testing your Web server with Dienst
`
`Adding additional document
`7.1 Overview of document
`types
`7.2 Adding new types to custom.pl
`7.3 Adding new file formats to documents
`
`in your database
`
`types to your Dienst server
`
`11
`
`12
`
`21
`
`21
`
`21
`
`21
`
`22
`
`22
`
`24
`
`25
`
`26
`
`26
`
`28
`
`29
`
`29
`
`29
`
`30
`
`30
`
`31
`
`31
`
`31
`
`32
`
`32
`
`33
`
`33
`
`33
`
`33
`
`35
`
`Petitioner IBM – Ex. 1014, p. 2
`
`

`
`Installing Dienst Optional Features
`Installing the Dienst Full-Text Search Package
`8.1
`Overview of full-text
`search
`
`8.1.1
`
`8.1.2
`
`8.1.3
`
`8.1.4
`
`Prerequisites for this installation
`Overview of this installation
`
`Detailed installation instructions
`
`8.2
`
`Additional
`information
`8.1.5
`Installing the Dienst Page-Level Zoom Package
`Overview of zoom
`8.2.1
`
`8.2.2
`
`8.2.3
`
`Prerequisites for this installation
`Overview of this installation
`
`8.2.4
`
`Detailed installation instructions
`
`8.3
`
`Installing the Dienst Foreign Servers Package
`Overview of foreign servers
`
`8.3.1
`
`8.3.2
`
`8.3.3
`
`8.3.4
`
`Prerequisites for this installation
`Overview of this installation
`
`Detailed installation instructions
`
`8.4
`
`Installing the Dienst Printing Package
`Overview of printing and downloading
`
`8.4.1
`
`8.4.2
`
`8.4.3
`
`8.4.4
`
`Prerequisites for this installation
`Overview of this installation
`
`Detailed installation instructions
`
`8.5 Maintaining your Dienst server
`Adding new documents
`8.5.1
`8.5.2 Monitoring log files
`8.5.3 Maintaining the integrity of your database
`
`to your database
`
`9.2
`
`The Dienst Library Management Package
`overview
`Submission package
`9.1
`Format generator utility
`tools overview
`Library management
`9.3
`9.4 Notes on directory structure and permissions
`Prerequisites for this installation
`Configuring the submission package
`9.6
`9.7 Configuring your Web server
`to enable Submissions
`
`9.5
`
`10 Advanced server customization
`the Dienst built-in search engine
`10.1 Replacing
`10.2 Using other bibliography formats
`
`Dienst protocol
`A.1 Repository requests
`A.1.1
`Requests about
`A.1.2 Requests about an individual
`A.2 Indexer requests
`A.3 User
`interface requests
`A.4 Miscellaneous Requests
`
`the entire collection
`document
`
`35
`
`35
`
`35
`
`36
`
`36
`
`36
`
`38
`
`38
`
`39
`
`39
`
`39
`
`39
`
`41
`
`41
`
`41
`
`41
`
`42
`
`42
`
`42
`
`42
`
`43
`
`43
`
`44
`
`44
`
`45
`
`45
`
`47
`
`48
`
`49
`
`49
`
`51
`
`51
`
`52
`
`52
`
`53
`
`53
`
`55
`
`57
`
`57
`
`57
`
`58
`
`58
`
`60
`
`61
`
`Petitioner IBM – Ex. 1014, p. 3
`
`

`
`Copyright considerations
`Copyright handling at Cornell
`.1.1 Cornell copyright agreement form........................
`B.2 Copyright handling at Stanford
`Stanford single report copyright permission form ...............
`.2.2 Stanford blanket copyright permission form ..................
`
`B.2.1
`
`Building the Cornell collection
`
`62
`
`62
`
`63
`
`64
`
`64
`
`65
`
`67
`
`Petitioner IBM – Ex. 1014, p. 4
`
`

`
`Overview of Dienst
`
`is
`
`Internet
`
`access
`
`to
`
`to
`
`it
`
`server
`
`library
`
`as part of
`
`to
`
`Information Infrastructure NIT promises unprecedented
`The rapid development
`National
`of
`information resources The current
`incarnation of the NIT the Internet provides
`access to global
`preview of future accessibility to information Every day millions of people use the Internet
`to
`access data and documents
`few years ago were only available at some distant
`that just
`or by waiting for them to be sent via the mail
`Although the Internet provides access to an enormous amount of information the current state-
`falls far short of what
`is commonly viewed as
`that
`of-the-art
`library service
`is relatively easy
`The notion of
`set of documents
`navigation of and access
`that are part of
`collection
`the set of documents was not selected haphazardly
`in that
`implies that
`collection is important
`but by some trusted intermediary Current users of
`the Internet confront an information space
`where the quality of documents
`is far from reliable facilities
`for locating documents
`are primitive
`and access to
`specific document
`Tower of Babel of architecture
`frequently means wading through
`dependencies and file formats
`protocol and server
`Dienst
`distributed decentralized
`that provides
`multi-format document
`From the standpoint of
`Dienst user the collection consists
`collection
`unified space of uniquely identified documents each of which may be available
`of
`in
`variety
`of formats Using publicly available World Wide Web clients users may search the collection
`browse and read individual
`documents
`formats and download
`in any of their available
`or print
`The Dienst system also provides
`site administrators with tools for managing their
`
`document
`document
`collections
`Dienst was developed by researchers at Xerox Corporation and Cornell University
`the Computer Science Technical Report CS-TR project an ARPA-sponsored effort
`to create
`reports from the nations top university computer
`an on-line digital
`science
`library of technical
`The architecture has three components
`for searching browsing and
`departments
`protocol
`implements this protocol and interoperates with other
`that
`viewing on-line documents
`Dienst servers and
`digital collection and maintaining
`for managing
`set of ancillary utilities
`number of computer science departments in the
`server Dienst servers are currently running at
`reports The technology
`United States providing access to thousands of computer science technical
`report domain and thus
`that underlies Dienst
`is not specific to the computer science
`technical
`collections We should note however
`can be applied to many other document
`that
`the current
`architecture does not address issues unique to copyrighted materials such as limiting access
`authorized individuals
`in the context of other generally available tech
`Dienst can be best understood by viewing it
`nologies for document
`transfer over the Internet The traditional baseline technology for document
`is anonymous FTP While the ubiquity of FTP makes it an attractive
`the Internet
`as medium for
`number of flaws that
`technology it has
`limit
`its usefulness
`digital
`library
`service There are no standards for organization of FTP directories file names give little or no
`information about the contents of files file formats can only be intuited from suffixes in file names
`rapid browsing of files is impossible and utilities
`for searching among multiple sites have limited
`usefulness
`beyond FTP Both allow
`Gopher and the World Wide Web represent significant advancements
`unified information space rather than one of separate addresses or sites Both
`the user to view
`permit related information to be linked and automatically
`traversed by the user Whereas
`the
`only meta information for anonymous FTP documents
`terse file name Gopher allows more
`titles WWW goes one step further by placing links to
`expressive document
`document within the
`
`transfer over
`
`is
`
`Petitioner IBM – Ex. 1014, p. 5
`
`

`
`context of another hypertext document Finally both Gopher and WWW incorporate the notion
`types e.g text graphics etc and the ability to automatically
`of document
`document
`an appropriate helper application
`The Dienst architecture represents
`layer of functionality above that provided
`an additional
`by the WWW This layer provides
`number of important abstractions
`defined collections
`unique document
`searchable and viewable documents
`identifiers that provide access to multiple
`representations of documents and document decompositions that provide access to individual pages
`The Dienst protocol uses HTTP the protocol used over
`the Web
`or logical parts of documents
`the features of the Web
`transport layer This allows the Dienst user
`interface to exploit all
`as
`the World Wide Web as Mosaic Cello and
`such as accessibility from such popular browsers of
`
`to
`
`of
`
`route
`
`as if
`
`in
`
`Netscape
`the docid One can
`Each document
`Dienst collection is addressed by its unique identifier
`in
`think of this docid as analogous to the ISSN and ISBN of the print publishing world All client
`are made using the docid as
`document
`key translation from the
`requests to Dienst server for
`server site and file system location is hidden from the user Geographic distribution of
`docid to
`is able to map from docid to repository
`the collection is handled by the fact
`that each Dienst server
`location The client accesses each document
`it were resident on the server
`to which the request
`was made
`The Dienst protocol provides extensible facilities
`the
`for resource discovery Clearly users of
`library wont always know the docid of
`particular document
`and must use some type of
`digital
`search engine to find the resource The current Dienst
`implementation includes
`simple search
`standard bibliographic format RFC 1357 and allows clients
`engine that indexes documents using
`to submit queries based on the bibliographic fields e.g author matches Gries
`search request
`is connected
`The client may choose
`is not
`to which the client
`limited to the server
`to submit
`to multiple Dienst servers and view the combined results Search results are
`the search in parallel
`the distributed documents
`hypertext document allowing the user
`to access
`presented as
`simple point and click manner The protocol
`is extensible to more advanced search engines as they
`become available
`Dienst makes use of the HTTP protocol
`types for documents eliminating
`to provide explicit
`the need to guess the format By providing file format meta-information Dienst allows the Web
`to automatically use the correct viewer HTML Postscript TIFF GIF etc to display the
`client
`document
`regardless of format The ability to handle multiple document
`formats is important for
`number of reasons in particular
`collection that
`retrospective conversion of
`is mixture of digital
`and paper forms
`Dienst builds upon HTTP by incorporating the notion of document
`The cur
`decompositions
`addresses physical partitions pages but
`the protocol also supports logical
`implementation
`rent
`partitions e.g chapters tables etc. For example
`user may choose
`to view
`specific page of
`the document
`is available One particularly useful
`specific format if
`facility in the current
`in
`images of document
`pages as means of
`to view reduced thumbnail
`features in the document e.g tables figures references Clicking
`searching for significant visual
`on
`image allows the user
`page rectangle within the thumbnail
`to view the selected page in full
`library and information retrieval
`Since Dienst was developed as
`platform for digital
`research
`both protocol and server are designed to be flexible and extensible
`The protocol
`is specifically
`interaction with systems such as software agents text analyzers and search
`designed to support
`engines and some of these are currently being developed
`
`implementation
`
`allows
`
`client
`
`it
`
`Petitioner IBM – Ex. 1014, p. 6
`
`

`
`Organization of this document
`
`The remainder of this document
`
`is organized as follows
`
`Section
`
`describes the document model on which the architecture is based
`
`Section
`
`describes the components of Dienst server and the manner in which
`Dienst servers interoperate
`
`network of
`
`Section
`
`describes notable features of the Dienst user interface
`
`Sections
`
`and 10 are the installation instructions for the Dienst software.1
`
`Appendix
`
`describes the protocol
`
`for requesting services from Dienst servers
`
`Appendix
`
`describes how Cornell and Stanford deal with copyright
`
`issues regarding on-line
`
`technical
`
`reports
`
`Appendix
`
`report collection to digital
`
`describes the procedures we followed to convert
`form
`
`the existing Cornell
`
`technical
`
`Dienst document model
`
`central component
`systems based on it
`
`limit
`
`document model FTP and
`to the Dienst architecture is the concept of
`like WATERS are bound by limitations of the file system abstraction File
`their usefulness for object identification Most file systems have
`names have restrictions that
`no provision for associating meta-data with files e.g
`description of the object Directories are
`the only method for grouping multiple files
`The Dienst document model provides three important abstractions
`multiple document
`formats and document
`decompositions
`model Appendix
`describes the use of this document model
`
`unique document
`names
`the document
`illustrates
`
`Figure
`in the Dienst protocol
`
`3.1 Unique document names
`
`Every document
`Dienst collection is identified by
`in
`the docid The docid has two parts
`
`identifier
`
`location-independent
`
`unique document
`
`is unique within the total Dienst name space Currently Rebecca Lasher at
`publisher that
`Stanford2 acts as the naming authority who verifies the uniqueness of publisher names
`
`is unique within the name space for the publisher The format of this string is
`name that
`to the publisher
`
`left
`
`As described in section 4.2 mapping from docid to an indexing and repository location is done via
`is downloaded
`by each server This mapping is transparent
`central server registration table that
`to the user and from his/her point of view the collection is
`flat set of documents
`
`1These
`the
`sections
`of
`on-line
`installation
`copy
`are
`http //cstr cs cornell edu/dienstJnstall/installation html
`2rlasherMorsythe stanford edu
`
`instructions
`
`available
`
`at
`
`Petitioner IBM – Ex. 1014, p. 7
`
`

`
`multiple
`
`fo
`
`multiple
`
`decompositio
`
`Physical
`
`Logical
`
`The Dienst document model
`Figure
`and multiple decompositions
`
`incorporates notions of unique naming multiple formats
`
`chapters
`
`sections
`
`Petitioner IBM – Ex. 1014, p. 8
`
`

`
`3.2 Multiple document
`
`formats
`
`document While from the users
`
`The docid provides
`means of grouping multiple fixations of
`point of view it would probably be ideal
`if multiple document
`formats did not exist there are
`several good reasons for supporting this notion First documents
`For
`have multiple origins
`example most of the early documents
`in the Cornell
`report collection existed only in
`technical
`paper form Retrospective conversion to digital
`form was done via scanning the paper documents
`to 600dpi TIFF images On the other hand new documents
`are uniformly added in PostScript
`the collection from systems with varying display technologies One
`format Second users access
`non-bitmapped display that only view can ASCII text
`user may be accessing the system through
`another may have
`high-resolution display on machine with high bandwidth network connections
`library are best served by multiple display formats
`Finally the different
`functions of
`digital
`Medium resolution bitmapped GIF images are best
`for online viewing on Web browser high-
`resolution TIFF images are best for archival storage the output of an OCR program acts as the
`for logical structure discovery programs and ASCII
`the input
`input
`text provides
`search indexing
`document
`The docid allows the user of Dienst
`to view the multiple formats in which
`single entity even though these formats are actually represented
`The user
`this is described in
`in multiple directories
`interface presentation of
`
`represented as sub-components of
`
`by multiple files
`section
`
`for full-text
`
`is
`
`3.3 Document decompositions
`
`Another
`
`PostScript
`
`is the notion of physical and logical decompo
`important abstraction provided by Dienst
`document Physical decomposition corresponds
`document Generally
`sitions of
`to pages of
`files One
`is addressable in separate pages is stored on disk as separate physical
`format that
`example is scanned TIFF images of pages However
`this file-to-page mapping is not required
`and the page breakdown may be done programmatically3 e.g separating
`file via the
`document structuring conventions
`via structural elements for exam
`document
`Logical decomposition allows the user to address
`in the document
`ple chapters and sections This structure can be explicit
`via some type of markup
`e.g SGML or implicit and discovered via heuristics that use whitespace and other layout char
`guide4
`
`acteristics as
`
`Dienst server architecture
`
`4.1 Components of Dienst server
`
`document
`database the server
`Dienst server consists of four components
`Wide Web server and the Dienst CGI stub The relationship of these components
`
`itself
`
`the World
`
`is illustrated in
`
`figure
`
`document database
`This is the set of documents
`provided by an individual Dienst server
`Documents are stored as files within the Unix file system Each document may be stored
`in multiple formats At the minimum each document must be represented by an RFC 1357
`bibliography file
`
`3The current Dienst
`implementation only supports physical decomposition for formats that are stored on disk as
`separate files for each page
`4This work has recently been completed and will described fully in
`
`future document
`
`Petitioner IBM – Ex. 1014, p. 9
`
`

`
`Figure
`
`through Web server via the Common Gateway Interface
`Each Dierist server
`CGI Each Dienst server interoperates with other Dienst servers and maps requests for documents
`to files in the document database
`
`is accessed
`
`10
`
`Petitioner IBM – Ex. 1014, p. 10
`
`

`
`rules for mapping from tuple consisting of
`The server software contains
`docid format
`and optional decomposition e.g page number to the actual
`file in the document database
`file organization we allow each site to provide
`Rather
`than imposing
`installation time
`
`customized version
`
`of this mapping at
`
`standalone multi-threaded
`
`Dienst server
`
`is
`
`process written in Pen
`Dienst server
`The
`on
`listens for connections
`port defined in the server configuration file Valid requests
`server
`to the server are defined by the Dienst protocol All responses from Dienst are formatted
`in the same fashion as HTTP responses These responses are sent
`to the requesting client
`interpretation by the Web server or CGI stub program As part of fulfilling
`without
`request
`an individual Dienst server may make requests to and interpret responses from other Dienst
`servers Interoperation among servers is described in section 4.2
`
`Each Dienst server provides three services
`
`current Dienst
`
`repository service
`
`provides
`
`in the document
`to documents
`access
`repository may contain documents
`implementation
`lishers The documents
`from given publisher must all be stored in
`
`database
`In the
`from several pub
`single repository
`
`indexing service
`current Dienst
`
`for full-text
`
`in the document
`permits searching of documents
`server can only index documents
`implementation
`Indexes for the search engine are constructed offline with
`the repository at that server
`reads the RFC 1357 bib files for each document
`in the database At startup
`utility that
`reads into memory the data from the index files The search engine allows
`the server
`fielded boolean searches over the indexed bibliographic data The server also has facilities
`search using either the Smart or WAIS search engine This is described in
`
`database
`
`In the
`
`that are stored in
`
`section 8.1
`
`user interface service
`itory services
`
`provides
`
`user friendly HTML front-end to the index and repos
`
`World Wide Web server
`Web
`The system is designed for access from Web clients through
`that supports the Common Gateway
`server Dienst may be accessed through any Web server
`Interface CGI The current version of Dienst has been tested with the two most popular
`servers CERN and NCSA
`Dienst requests are packaged within the path portion of the HTTP request
`to the Web server
`Web server
`front-end for Dienst must be configured
`that serves as
`to invoke the Dienst
`CGI stub program when the HTTP request
`request Setting up Web
`Dienst
`contains
`gateway to
`Dienst server
`is described in section
`
`server as
`
`Dienst CGI stub
`
`request
`
`As described above the CGI stub is invoked each time the gateway Web
`Dienst request The stub is
`small simple executable that strips the Dienst
`server receives
`from the HTTP request packages
`few important environment variables that contain
`identity the MIME types the client
`the request e.g the remote host
`information about
`willing to accept etc and sends them via socket
`I/O to the Dienst server
`
`is
`
`4.2
`
`Interaction among Dienst servers
`
`single logical collection even though the collection is distributed
`user of Dienst server perceives
`by interaction between
`set of Dienst servers at three
`over multiple servers This is accomplished
`functional
`
`levels
`
`11
`
`Petitioner IBM – Ex. 1014, p. 11
`
`

`
`server registration
`
`collection consists of
`
`document
`
`in
`
`Dienst
`
`in
`
`As described earlier each docid that
`identifies
`name Each server
`publisher identifier and
`set of interoperating
`Dienst servers indexes and acts as
`repository for documents
`from one or more publishers
`the documents
`publisher must be indexed and reside on the
`In the current version all
`same server
`Each server
`is able to locate the indexing and repository site for
`specific
`the meta server and
`publisher using tables that are maintained by
`distinguished server
`periodically downloaded by the individual server This allows every server
`to provide the next
`two functions
`
`for
`
`Each Dienst user interface server provides
`front-end for searching the
`distributed searching
`inter-operating Dienst servers The user specifies in the search form
`collection provided by all
`The respective
`which publishers should be searched
`then dispatches
`user
`interface server
`to the Dienst
`search requests in parallel
`index servers that
`to the publisher
`correspond
`selections The user interface server
`then parses and combines the results from the requested
`coordinated hit list
`to the user
`servers to present
`
`distributed document access
`
`Each server in
`set of interoperating Dienst servers is capable
`The respective
`for any document
`in the distributed collection
`of responding to
`request
`and the mapping tables
`in the docid of the requested document
`server uses the publisher
`to route the document
`downloaded
`from the meta server
`to the server
`that acts as
`request
`to the user
`the repository for the publisher This routing is transparent
`
`Dienst user interface features
`
`Each Dienst server allows the user to search browse and view the collection using any Web client
`Several of the features of the user interface are described in this section Not all Dienst servers
`the features described in this section nor are the features available for all documents
`
`provide all
`
`number of features are optional e.g full-text
`respective server
`
`searching and may not be installed at
`
`the
`
`on the formats in which the respective document
`number of features are dependent
`is
`the document
`is stored in GIF
`available For example in-line page viewing is only available if
`format
`
`An HTML form allows
`Forms-based distributed searching
`user
`to specify criteria for
`search These criteria are publisher names at least one must be selected document name
`and bibliographic keywords title author abstract The search form allows the user to specify
`arid or or boolean operators between the bibliographic keyword fields In addition the user
`may user boolean operators and precedence symbols parentheses within bibliographic fields
`An example search form is shown in figure
`
`Unified hypertext hit
`servers are presented to the user as
`docid Each hit is link to the document
`
`The results of
`
`list
`
`search that may have been dispatched
`to several
`combined list of hyperlinks sorted by publisher and
`summary page for the respective document
`If any
`search as specified in the publisher
`in the search form are
`the top of the results form An example hit
`not available this information is printed at
`is shown in figure
`
`of the servers needed for
`
`list
`
`list
`
`12
`
`Petitioner IBM – Ex. 1014, p. 12
`
`

`
`Search the Collection
`
`Select one or more publishers
`
`from this list
`
`Princeton CS
`
`Stanford
`Maoland College Park CS
`
`or
`
`search all publishers
`
`Document
`
`Identifier
`
`Bibliographic keywords
`
`AND keyword fields
`
`OR keyword field
`
`Author
`
`subrasanian or saltz or wet
`
`Title
`
`Abstract
`
`parallel algorithrri
`
`..J
`
`submit search to other technical
`
`report indexes
`
`start searchi
`
`clear fleldsi
`
`The Dieust search form allows users to euter search criteria for bibliographic
`Figure
`Booleau expressious may be used withiu aud/or betweeu fields
`
`fields
`
`13
`
`Petitioner IBM – Ex. 1014, p. 13
`
`

`
`Your search was for
`
`publishers selected
`
`Cornell
`
`Stanford
`Maryland College ParkCS
`
`Bibliographic keywords anded together
`
`author
`
`subramanian
`
`or as/tx or wei
`
`abstract
`
`parallel algorithm
`
`Search results
`
`opLtELLcTp
`212 44 mjth Cc
`tjormoOnFrom i/c
`So
`uior
`\veiLi
`and KeshavPingali
`CORNELLCSTR94-14F9 COMFIUNO FOR NUMA PARALLEL
`MACH AiES WeiLi
`3T\NCSTR891L75Anewopproochto
`Subramanian
`STANt2-TR89l2Th The complexity of circuit s.c/in on/netwo
`Mayr and Ashok Subrarnanian
`Ernst
`UMCPCSD LSTR--o425 Poro//el Monte Curio Simu/otto
`ow over
`Nance
`ThseeDunesssiono/
`P/ot Plo/c
`Robert
`is.hard Wilmoth Bongki Moon and Joel Jaltc
`UMCPflSO CSTR2A47 Joterprocetht
`ol Compi/otion of /rregu/or
`irthoted Men
`and Jot
`for Di
`
`toNcmctchi
`
`oh/etc Ashok
`
`s/oddity
`
`of
`
`Hassan
`
`4pp/tcotions
`aJtz
`
`ties hit
`
`Cagan Agraczai
`
`Figure
`Each hit is
`
`Dieust search results are displayed iu
`hypertext
`list
`liuk to the summary page for the respective documeut
`
`sorted by publisher aud docid
`
`14
`
`Petitioner IBM – Ex. 1014, p. 14
`
`

`
`Document summary page
`summary page serves two purposes First it dis
`The document
`plays the metadata associated with an individual
`document e.g author
`title publication
`document
`date abstract
`included abstract words the appropriate
`the search criteria for
`abstract words are highlighted in the document
`summary page Second
`it presents to the
`user the formats in which the document
`is available These are divided into four groups
`
`If
`
`page thumbnails for browsing
`
`structural overview of the document
`
`formats for which physical page decompositions are available the user may choose
`appropriate page to display
`
`the
`
`formats for which decompositions are not available selection of one of these formats will
`download of the entire document
`in the respective format
`
`effect
`
`link to the printing and downloading form
`
`for the specific document will be shown on that documents
`Only those formats available
`summary page An example document
`summary form is shown in figure
`
`Sitigular op Iransforniatioti
`Based on NonSingular Matrices
`
`ramework
`
`CORNELLCS TR92--1294
`
`-iri- ne
`triIi11_i1p4J
`
`fli
`
`li
`
`1111
`
`nrip
`
`I1 III
`
`L1II1aiIori11ILrL
`ii
`
`inpII_
`
`UI
`
`pIItI
`
`lit
`
`1111
`
`In Th1
`1Lt1 LnuLI
`1_U.LI
`-1It-
`
`1iIIL
`
`ltfln
`
`I1U IliI
`I-rnL
`
`lii
`
`_rirntIir
`
`In
`
`How to view Ihis docLinlent
`
`I_
`
`II
`
`_______
`IcoI joi
`
`r_ntLn Lh 11InIrt
`-r iIC
`
`The document
`
`summary page displays the metadata associated with the respective
`Figure
`and the formats in which the document
`is available The user can use the links on this
`document
`format
`page to display the document
`
`in the chosen
`
`Structural overview
`
`of
`
`document
`shown in figure
`
`structural overview allows the user to view the major structural features
`such as chapters sections and the like An example structural overview is
`
`15
`
`Petitioner IBM – Ex. 1014, p. 15
`
`

`
`Tools for Monitoring and Controlling Distributed Applications
`
`and J.l
`
`irri
`
`1991
`
`rr
`
`.14
`
`..Ti
`
`..t
`
`cn 1nt.l uwn
`__
`
`i.n
`
`Fur
`___
`..4 i3U1t
`
`...fI
`
`.J
`
`i_
`
`rtflo
`
`ir.i
`
`J..k
`
`tii
`
`i....n
`
`.1
`
`ci
`
`Ci
`
`13
`14
`
`The structural overview allows the user to see the hierarchical structure of the docurneut
`Figure
`revealiug features such as chapters aud sectious Each structural item is
`liuk to the page ou which
`the item begius
`
`16
`
`Petitioner IBM – Ex. 1014, p. 16
`
`

`
`Page browsing via thumbnail
`images
`Page thumbnails allow users to quickly browse the
`document
`and discover and locate structural objects such as tables graphs and
`body of
`HTML irnagernap allowing the user to
`the like Each thumbnail page is implemented using
`URL to view that specific page in readable form An example
`page and dispatch
`select on
`thumbnail page is shown in figure
`
`Singular Loop Transformation Framework Based
`on NonSingular Matrices
`
`1i wihn
`
`ag
`
`di
`
`II
`
`pg
`
`for formatting features e.g
`document
`Page thumbnails are
`tool for quick browsing of
`Figure
`tables The thumbnails are implemented using the HTML irnagernap mechanism which allows
`page and view that page in full
`user to select
`
`resolution sufficient for on-screen read
`Inline page image
`Inline page images are displayed in
`ing of the document At Cornell we have found that 72 dpi four-bit deep GIFs have the
`proper combination of resolution and size for most monitors The page image display also
`includes several other user interface objects
`
`hyperlinks that allow the user to go the next or previous page of the document or to
`summary page
`the document
`
`is performed when the user selects
`two radio buttons that control
`the operation that
`point within the document
`page The two operations are zoom and full-text
`both of which are described below
`
`search
`
`An example page-image page is shown in figure
`
`Page level zooming
`page image by selecting the zoom
`The user can zoom in on
`section of
`the document
`radio button and clicking within the page image in the page-image display If
`
`17
`
`Petitioner IBM – Ex. 1014, p. 17
`
`

`
`Click with the mouae
`
`Full-text search on aporagraph
`
`to select aperagraph or section of
`..- Zoomin on
`
`the page
`
`section
`
`aix
`
`Af4j-s1aa
`
`ij/J
`
`1wTheod-1
`
`rIo o10Io itesaIoe spao
`
`sai
`
`xs
`
`1041
`
`loop Trarzormatious
`
`.1 ...i
`
`c.c....-
`t.i.p
`
`...
`
`format with 4-bit deep gray scaling for maximum screen
`Pages are displayed in 72d pi
`Figure
`and
`links to move back and forth through the document
`readability The page display includes
`controls for the zoom and click-to-search full-text
`search feature
`
`II
`
`18
`
`Petitioner IBM – Ex. 1014, p. 18
`
`

`
`high-resolution format e.g scanned TIFF zoomed section of this format
`is available in
`will be displayed to the user An example zoom page is shown in figure
`
`Left Lip Down Zoom Out
`
`for
`
`for
`
`10 step
`3maz1
`Smin8
`
`F1
`L3J
`
`step
`
`vi
`
`v/6
`
`The targe1 code
`
`Left TJp Down Zoom Out
`
`Figure
`
`Page level zooming allows the user to see fine detail on
`
`document page
`
`Click-to-search full-text
`
`search
`
`The user can perform full-text
`search based on text in the
`document
`radio button the default and clicking within the page
`by selecting the full-text
`The server will use the contents of the paragraph in the
`image in the page-image display
`as the source for the search Mapping from the selection
`the user selection
`proximity of
`text is done by an analysis of the OCR output using paragraph delin
`to the ASCII
`point
`eation heuristics based on line spacing
`full description of the implementation of full-text
`search returns two sets of results document
`searching is in section 8.1
`full-text
`ranked order and paragraph level
`in ranked order The results are pres