Exhibit B-51
`
`Invalidity of U.S. Patent No. 6,415,280 over the LIFN Prior Art
`
`(cid:120)
`
`Each of the Asserted Claims is anticipated by each of:
`S. Browne et al., “Location-Independent Naming for Virtual Distributed Software Repositories,” University of Tennessee Technical
`Report CS-95-278 (Feb. 1995) (“Browne 1995”), which is available as prior art at least under 35 U.S.C. § 102(a);
`(cid:120) S. Browne et al., “Location-Independent Naming for Virtual Distributed Software Repositories,”
`http://www.netlib.org/utk/papers/lifn/main.html (Nov. 11, 1994) (“Browne 1994”), which is available as prior art at least under
`35 U.S.C. § 102(a); and
`(cid:120) K. Moore et al., “An Architecture for Bulk File Distribution,” Network Working Group Internet Draft (July 27, 1994)
`(“Moore 1994”), which is available as prior art at least under 35 U.S.C. § 102(a)
`(collectively, “the LIFN Prior Art”). All references to “the LIFN Prior Art” herein should be understood to refer to each of the
`references individually.
`(cid:120) To the extent PersonalWeb contends that the LIFN Prior Art does not meet one or more limitations of the Asserted Claims, the
`claims are obvious over the LIFN Prior Art, alone or in combination with each other, in combination with the knowledge of a
`person of ordinary skill in the art, and/or in combination with other prior art references identified in the cover pleading or
`herein, including one or more of the following:
`(cid:120) Albert Langer, “Re: dl/describe (File descriptions),” article <1991Aug7.225159.786@newshost.anu.edu.au> in Usenet
`newsgroups “alt.sources.d” and “comp.archives.admin” (August 7, 1991) (“Langer”) is available as prior art at least under 35
`U.S.C. § 102(b).
`(cid:120) U.S. Patent No. 5,649,196 to Woodhill et al. (“Woodhill”) claims priority to a U.S. patent application filed on Jul. 1, 1993, and
`therefore is available as prior art at least under 35 U.S.C. § 102(e).
`The charts below provide representative examples of where specifically each element of each asserted claim is found within the LIFN
`Prior Art and other references, at least under PersonalWeb’s apparent construction of the Asserted Claims as applied in PersonalWeb’s
`infringement contentions. The charts also identify, for each element governed by 35 U.S.C. § 112, ¶ 6, the structure(s), act(s), or
`material(s) that performs the claimed function. The charts also identify, for combinations of prior art items that make a claim obvious,
`the motivation to combine such items. The cited portions of the prior art references are only examples, and Defendants reserve the
`right to rely on any further uncited portions of the prior art references as additional evidence that the references disclose and/or render
`obvious a claim limitation.
`
`1
`PersonalWeb Technologies LLC v. EMC Corporation and VMware, Inc. (No. 6:11-cv-00660-LED) (E.D. Tex.)
`
`EMCVMW 1034
`
`

`

`The ‘280 Patent Claims
`[36a] A method of delivering a
`data file in a network comprising a
`plurality of processors, some of
`the processors being servers and
`some of the processors being
`clients, the method comprising:
`
`The LIFN Prior Art
`The LIFN Prior Art discloses a method of delivering a data file in a network comprising a
`plurality of processors, some of the processors being servers and some of the processors
`being clients. For example, the LIFN Prior Art discusses the distribution of data files over
`a network that comprises a plurality of LIFN servers, file servers (e.g., mirror sites and/or
`cache sites), and clients, all of which are processors.
`“A location-independent naming system for network resources has been designed to facilitate
`organization and description of software components accessible through a virtual distributed
`repository. . . . This paper details the design of the naming system, describes a prototype
`implementation of some of the capabilities, and describes how the system fits into the
`development of the National HPCC Software Exchange, a virtual software repository that has
`the goal of providing access to reusable software components for high-performance computing.”
`Browne 1995 at 1 (abstract).
`“Well-maintained software repositories are central to software reuse because they make high-
`quality software widely available and easily accessible. One such repository is Netlib, a
`collection of high-quality publicly available mathematical software [6, 4]. Netlib, in operation
`since 1985, currently processes over 300,000 requests a day. Netlib is serving as a prototype for
`development of the National HPCC Software Exchange (NHSE), which has the goal of
`encompassing all High Performance Computing Consortium (HPCC) software repositories and
`of promoting reuse of software components developed by Grand Challenge and other scientific
`computing researchers [5].” Browne 1995 at 1 (footnotes omitted).
`“Growth in the popularity of the Internet and the World Wide Web, as well as the wide
`availability of WWW client and server software, has accelerated the shift from centrally
`maintained software repositories to virtual, distributed repositories. For example, the GAMS
`Repository, once a central repository, is now a virtual repository that catalogs software
`maintained by other repositories [2]. Similarly, the NHSE will provide a uniform interface to a
`virtual HPCC software repository that will be built on top of a distributed set of discipline-
`oriented repositories [5], as shown in Figure 1.” Browne 1995 at 1.
`See also Browne 1995, Figure 1:
`
`2
`PersonalWeb Technologies LLC v. EMC Corporation and VMware, Inc. (No. 6:11-cv-00660-LED) (E.D. Tex.)
`
`

`

`The ‘280 Patent Claims
`
`The LIFN Prior Art
`
`“The main advantage of distributing a repository is to allow the software to be maintained by
`those in the best position to keep it up-to-date. Also, copies of popular software packages may
`be mirrored by a number of sites to increase availability (e.g., if one site is unreachable, the
`software may be retrieved from a different site) and to prevent bottlenecks.” Browne 1995 at 1–
`2.
`“The WWW mechanism of specifying a file by its Uniform Resource Locator (URL) is
`inadequate for ensuring the consistency and currency of mirrored copies, as a URL for an
`independently mirrored copy of a software package may point to an out-of-date copy and give no
`indication that it is not up-to-date. Furthermore, mirror copies of a file cannot be located from a
`URL reference, since each copy has a different URL.” Browne 1995 at 2.
`“Higher-level names allow for long-lived human-readable references, while lower-level names
`permit reliable caching and mirroring as well as permitting precise references when needed.
`Location-independent names will be the basis of transparent mirroring.” Browne 1995 at 2.
`“It has been widely recognized that a solution to the above problems is to assign location-
`independent names to files and to provide a name-to-location service that, given a name, returns
`a list of locations for that name. A resource provider who moves some files need only delete the
`3
`PersonalWeb Technologies LLC v. EMC Corporation and VMware, Inc. (No. 6:11-cv-00660-LED) (E.D. Tex.)
`
`

`

`The ‘280 Patent Claims
`
`The LIFN Prior Art
`old name-to-location bindings and register the new bindings with the name-to-location service.
`Likewise, a site that mirrors a copy of a file need only register its location with the name-to-
`location service. Then a user attempting to retrieve the file corresponding to a location-
`independent name may query the name-to-location service for a list of alternative locations to be
`tried.” Browne 1995 at 3.
`“We divide the file access system into two levels. The upper level is where publishing,
`cataloging, and searching activities take place. These upper-level activities are concerned with
`the semantic, or intellectual, contents of files. The lower level is where distribution, mirroring,
`and caching activities occur.” Browne 1995 at 3–4.
`“For a name to be useful, there must be some means of resolving a name to a location from
`which the resource can be retrieved or accessed. Thus, the publisher, as well as any other parties
`that mirror the resource, must register such locations with the appropriate name-to-location
`lookup services.” Browne 1995 at 4.
`“[T]he steps involved in resolving a URN so as to access a copy of the file it names are as
`follows, as shown in Figure 3:
`1. Use DNS to locate an appropriate URN server.
`2. Query the URN server to retrieve the URC which contains the currently associated
`LIFN.
`3. Authenticate the URC if desired.
`4. Use DNS to locate an appropriate LIFN server.
`5. Query the LIFN server to retrieve a list of locations.
`6. Choose a location from which to retrieve the file.”
`Browne 1995 at 5.
`See also Browne 1995, Figure 3:
`
`4
`PersonalWeb Technologies LLC v. EMC Corporation and VMware, Inc. (No. 6:11-cv-00660-LED) (E.D. Tex.)
`
`

`

`The ‘280 Patent Claims
`
`The LIFN Prior Art
`
`“A file server can mirror a file by acquiring a copy of it and posting an update to a LIFN server
`for the file’s naming authority.” Browne 1995 at 5.
`“One of the most important aspects of our use of LIFNs is that it assures the user of retrieving
`the most up-to-date copy of a file referenced by a URN, without the overhead of a replica control
`protocol between file servers mirroring that file, which in general will not all be under the
`control of the URN’s naming authority. This assurance is modulo the time required for the
`master-slave update protocol for the replicated URN servers, but if the user insists on contacting
`the master URN server, he is ensured of getting the most up-to-date copy.” Browne 1995 at 5.
`“[A] LIFN server returns a list of locations for a given LIFN but does not guarantee the
`correctness of those locations. A location may be incorrect if it no longer exists or if the
`contents of that location are wrong. In the former case, no file will be returned from that
`location. The latter condition may be detected by the client performing an integrity check.”
`Browne 1995 at 5.
`“The naming system is being implemented as part of the Bulk File Distribution (BFD) package.
`5
`PersonalWeb Technologies LLC v. EMC Corporation and VMware, Inc. (No. 6:11-cv-00660-LED) (E.D. Tex.)
`
`

`

`The ‘280 Patent Claims
`
`The LIFN Prior Art
`BFD is part of the implementation of the National HPCC Software Exchange (NHSE), which is
`being developed by the Center for Research in Parallel Computing (CRPC), a consortium of
`universities and national laboratories formed to make high performance and parallel computing
`accessible to engineers and scientists. BFD URN and LIFN servers will run at all the CRPC
`participating sites, as well as at other major NHSE sites, such as Oak Ridge National
`Laboratory.” Browne 1995 at 6.
`“Our naming system will help provide a uniform interface to a virtual distributed software
`repository, such as the National HPCC Software Exchange, while preserving the advantages of
`distributed maintenance of contributed software and of file mirroring.” Browne 1995 at 6.
`“As part of the BFD package, we plan to implement a replication daemon that acquires new files
`from remote servers, deletes files that are no longer wanted, and informs LIFN servers of the
`changes. These functions are similar to those provided by several existing mirror programs,
`such as the Netlib repository mirroring scheme described in [7], but with the addition of
`interacting with the LIFN database.” Browne 1995 at 6–7.
`“A location-independent naming architecture for network resources has been designed to
`facilitate organization and description of software components accessible through a virtual
`distributed repository. This naming scheme enables easy and efficient searching and retrieval,
`and it addresses many of the consistency, authenticity, and integrity issues involved with
`distributed software repositories by providing mechanisms for grouping resources and for
`authenticity and integrity checking. This paper details the design of the naming scheme, decribes
`a prototype implementation of some of the capabilities, and describes how the scheme fits into
`the development of the National Software Exchange, a virtual software repository that has the
`goal of providing access to reusable software components for high-performance computing.”
`Browne 1994, Abstract.
`“Well-maintained software repositories are central to software reuse because they make high-
`quality software widely available and easily accessible. One such repository is Netlib, a
`collection of high-quality publicly available mathematical software. Netlib, in operation since
`1985, currently processes over 300,000 requests a day. Netlib is serving as a prototype for
`development of the National Software Exchange (NSE), which has the goal of encompassing all
`High Performance Computing Consortium (HPCC) software repositories and of promoting reuse
`6
`PersonalWeb Technologies LLC v. EMC Corporation and VMware, Inc. (No. 6:11-cv-00660-LED) (E.D. Tex.)
`
`

`

`The ‘280 Patent Claims
`
`The LIFN Prior Art
`of software components developed by Grand Challenge and other scientific computing
`researchers.
`Many repositories, previously maintained centrally, have evolved into virtual repositories that
`serve as directories to distributed collections. For example, the GAMS Software Repository,
`once a central repository [1], is now a virtual repository that catalogs software maintained by
`other repositories [2]. Another distributed repository, the NASA/GSFC/ESS Software and
`Information Exchange (accessible at http://farside.gsfc.nasa.gov/ESS/), stores some of the
`catalogued software packages locally, but for packages at remote sites stores just descriptions
`with pointers. Growth in the popularity of the Internet and the World Wide Web, as well as the
`wide availability of WWW client and server software, has accelerated the shift from centrally
`maintained software repositories to virtual, distributed repositories. A provider site (either the
`maintainer or a mirror site) need only make the file available from an FTP, Gopher, or HTTP
`server for it to be accessible from a WWW client.
`The main advantage of distributing a repository is to allow the software to be maintained by
`those in the best position to keep it up-to-date. Also, copies of popular software packages may be
`mirrored by a number of sites to increase availability (e.g., if one site is unreachable, the
`software may be retrieved from a different site) and to prevent bottlenecks.
`A distributed, virtual repository should appear as a centralized, well-organized repository. An
`effective search interface for a distributed software repository allows a user to search for
`software without knowing at what site the software is located. A mirrored file should appear
`once in a list of such results, rather than once for each mirrored copy. Yet a searcher should still
`enjoy the reliability and performance benefits of mirroring - i.e., be able to try alternative
`locations to retrieve a search hit or retrieve the closest copy of the file.
`Distributed maintenance and mirroring of software introduces challenges as well as benefits.
`Maintaining the quality of software and of indexing information and presenting a uniform
`searching and browsing interface become much more difficult. Location-independent naming
`facilitates the organization, finding, and retrieval of software in a distributed repository, and can
`be used to provide consistency, authenticity, and integrity guarantees.
`The WWW mechanism of specifying a file by its Uniform Resource Locator (URL) poses
`
`7
`PersonalWeb Technologies LLC v. EMC Corporation and VMware, Inc. (No. 6:11-cv-00660-LED) (E.D. Tex.)
`
`

`

`The ‘280 Patent Claims
`
`The LIFN Prior Art
`several difficulties for a virtual software repository. URLs are inadequate for ensuring the
`consistency and currency of mirrored copies. A URL for an independently mirrored copy of a
`software package may point to an out-of-date copy and give no indication that it is not up-to-
`date. Consistency between a set of files that are meant to be used together may also become a
`problem. For example, the Netlib Software Repository provides dependency checking that
`allows the user to retrieve a top-level routine plus all routines in its dependency tree (i.e., those
`routines that are called directly or indirectly by the top-level routine). Another example is a
`graphical parallel programming environment that relies on an underlying parallel
`communications support package. The problem becomes more complex when different pieces
`might be retrieved from different physical repositories. Ideally, the user should be able to have a
`consistent set retrieved automatically without having to scan documentation to verify that
`compatible pieces have been retrieved.
`Distributing the repository also poses challenges for searching. A centrally maintained repository
`can easily run an indexing and search engine that provides a search interface to the repository
`contents. With the current WWW setup, however, the user has a choice of searching the various
`distributed repository sites individually or of using a general purpose WWW search engine such
`as WebCrawler, Lycos, or the World Wide Web Worm.” Browne 1994 at 3–4.
`“A user who contributes a resource (e.g., a software package or a document) by making it
`available via our virtual software repository is said to have published the resource.” Browne
`1994 at 5.
`“For a name to be useful, there must be some means of resolving a name to a location from
`which the resource can be retrieved or accessed. Thus, the publisher, as well as any other parties
`that mirror the resource, must register such location with the appropriate name-to-location
`lookup services. Such name-to-location services are discussed in Section 3.
`Thus, publishing a resource involves the following steps:
`1.
`creating the resource's description,
`2.
`signing the description with the publisher's private key,
`3.
`making the resource available on one or more file servers,
`
`8
`PersonalWeb Technologies LLC v. EMC Corporation and VMware, Inc. (No. 6:11-cv-00660-LED) (E.D. Tex.)
`
`

`

`The ‘280 Patent Claims
`
`The LIFN Prior Art
`listing the resource locations in the name-to-location database, and
`4.
`exporting the resource's description to search services.” Browne 1994 at 6.
`5.
`“Resources available from the virtual repository will be named by URNs and/or LIFNs, rather
`than by URLs. Thus, WWW clients will need a means of resolving a URN or LIFN to one or
`more locations, expressed in the form of a URL, to be able to access the resource. Access to files
`is provided by conventional file servers, using protocols such as HTTP, Gopher, and FTP.”
`Browne 1994 at 7.
`“For a file resource, such as a file containing a piece of software, we recommend that the list of
`locations be associated directly with the LIFN for the file, rather than with any URN assigned to
`the resource.” Browne 1994 at 7.
`“The LIFN-to-location mapping service is to be provided by a network of LIFN servers,
`collectively called the LIFN database. These servers process queries for locations of LIFNs.
`They also accept updates from file servers containing new locations for LIFNs, as well as
`requests to delete old LIFN-to-location mappings. A naming authority may run its own LIFN
`servers, or it may find another organization willing to provide the service on its behalf.” Browne
`1994 at 7.
`“A file server can mirror a file by acquiring a copy of it and posting an update to a LIFN server
`for the file's naming authority. If a file server moves or deletes a file, then it would post that
`information as well. It is not necessary to keep all LIFN servers for a particular naming authority
`perfectly synchronized. Such synchronization would entail too much overhead. Instead, location
`updates will be posted to a single LIFN server and propagated to other peer servers using a batch
`update protocol.
`Under normal conditions, all LIFN servers will be reasonably up-to-date, but if the list of
`locations provided by one server is unsufficient, the client is free to consult other LIFN servers
`for additional locations. If a listed location turns out to be incorrect - i.e., it points to a location
`that does not actually contain the file (how such an error condition may be detected by the client
`is discussed in Section 4) - the client may look for a file at the file's other listed locations.”
`Browne 1994 at 7–8.
`
`9
`PersonalWeb Technologies LLC v. EMC Corporation and VMware, Inc. (No. 6:11-cv-00660-LED) (E.D. Tex.)
`
`

`

`The ‘280 Patent Claims
`
`The LIFN Prior Art
`“[A] LIFN server returns a list of locations for a given LIFN but does not guarantee the
`correctness of those locations. A location may be incorrect if it no longer exists or if the contents
`of that location are wrong. In the former case, no file will be returned from that location. The
`latter condition may be detected by the client performing an integrity check.” Browne 1994 at 9.
`“The naming architecture is being implemented as part of the Bulk File Distribution (BFD)
`package. BFD is part of the implementation of the National Software Exchange (NSE), which is
`being developed by the Center for Research in Parallel Computing (CRPC), a consortium of
`universities and national laboratories formed to make high performance and parallel computing
`accessible to engineers and scientists. BFD LIFN and file servers will run at all the CRPC
`participating sites, as well as at other major NSE sites, such as Oak Ridge National Laboratory.”
`Browne 1994 at 11.
`“The BFD LIFN database is a simple key/data database in which the unique keys are LIFNs.
`Sending a BFD LIFN server a query containing a LIFN causes a list of URLs to be returned,
`possibly along with other information. Sending a BFD LIFN server an update containing a
`LIFN/URL pair (and possibly additional location-specific descriptive information) causes that
`pair to be added to the database.” Browne 1994 at 11.
`“When a client program requests this URL from the file server, the file server either returns a file
`that it guarantees is correct for the given LIFN, or it returns an error indicating that a file
`corresponding to that LIFN is not available. Thus, BFD file servers guarantee that the LIFN-to-
`URL mapping is correct, and no integrity checking is required on the part of the BFD client.
`Several CRPC sites are or will soon be mirroring portions of the Netlib collection and running
`such BFD file servers.” Browne 1994 at 12.
`“Our naming scheme will help provide a uniform central interface to a virtual distributed
`software repository, such as the National Software Exchange, while preserving the advantages of
`distributed maintenance of contributed software and of file mirroring.” Browne 1994 at 13.
`“As part of the BFD package, we plan to implement a replication daemon that acquires new files
`from remote servers, deletes files that are no longer wanted, and informs LIFN servers of the
`changes. These functions are similar to those provided by several existing mirror programs, such
`as the Netlib repository mirroring scheme described in [4], but with the addition of interacting
`
`10
`PersonalWeb Technologies LLC v. EMC Corporation and VMware, Inc. (No. 6:11-cv-00660-LED) (E.D. Tex.)
`
`

`

`The ‘280 Patent Claims
`
`The LIFN Prior Art
`with the LIFN database. The BFD replication daemon will be designed to perform its tasks very
`efficiently. Planned features include on-the-wire compression, checkpoint/restart, multiple file
`multiplexing (to allow for gradual transfer of very large files), integrity checking, and a protocol
`that works well over high bandwidth-delay links.” Browne 1994 at 13.
`“This memo describes a system for the automated replication of data files and their descriptions
`to various file servers across the Internet. The system maintains a distributed database which
`contains the locations of each file distributed by the system, and will provide a list of locations
`for any file upon request.” Moore 1994, abstract.
`“There are a number of problems associated with the current Internet information infrastructure,
`which result in poor service to its users. These problems include:
`+ lack of scability. Many files are available at only a single file server. Any popular file (e.g.
`Mosaic home page, weather map) will cause a file server to be swamped.
`+ lack of fault tolerance. If a file server is unavailable, there is no mechanism to find alternate
`servers for that file.
`+ inefficient use of network resources. The primary location of a file may be halfway across the
`globe, or on the other side of a lowbandwidth link. Even when alternate locations exist, there is
`currently no mechanism to find a "nearby" location of a particular file.” Moore 1994 at 1–2.
`“In order to address these problems, we propose the following architecture. It is intended to
`provide replication of files across multiple servers, scalable access to the files distributed by the
`system, and the assurance of integrity and (optionally) authenticity for each file. In addition it
`provides the ability to reliably cache such files as well as the potential to take advantage of
`network proximity for improved utiliziation.” Moore 1994 at 2.
`“The LIFN-to-location mapping service is provided by a network of "location servers"
`collectively known as the "location database". These servers accept requests for locations of
`LIFNs, as well as updates containing new locations or requests to delete old LIFN-to-location
`mappings. Such update requests require authentication; only those file servers which are
`authorized by the publisher may store locations in the database.
`Access to files themselves is provided by more-or-less conventional file servers, using any
`11
`PersonalWeb Technologies LLC v. EMC Corporation and VMware, Inc. (No. 6:11-cv-00660-LED) (E.D. Tex.)
`
`

`

`The ‘280 Patent Claims
`
`The LIFN Prior Art
`protocol which provides binary transparent file access. Such protocols would include HTTP,
`Gopher, FTP, and others, as long as certain restrictions are observed.
`Files are replicated among file servers using a "replication daemon". A copy of the replication
`daemon runs on each file server. It accepts descriptions of newly published files, and decides
`(based on site-provided criteria) which files should be acquired by the file server. It then queries
`the location database to find a location for each file desired, and retrieves the file from one of the
`locations listed. Finally, it updates the location database to inform it of the new location for that
`file.” Moore 1994 at 2.
`“A file is ‘published’ in the system by creating a description to go along with the file, signing the
`description with the publisher's private key, making the file available via one or more "master"
`file servers, and listing those locations in the location database. The description may also be sent
`(perhaps via ordinary email) to interested parties. Such parties may include slave file servers
`(which can use them to decide which new files to acquire), resource discovery servers (which
`can then provide search services based on the file descriptions and/or the files themselves), and
`ordinary users.” Moore 1994 at 3.
`“It is not necessary to keep all location servers for a publisher in sync. The location query
`service does not guarantee that it returns all instances of a given file. If the list of locations
`provided by one server is insufficient, the client is free to consult the other servers in the hope of
`finding a better one. Similarly, if one or more of the locations thus provided is "stale" (that is,
`points to a file that no longer exists), the client may also look for the file at its other listed
`locations. (Note that while a file server may delete a file whose location is listed in the location
`database, it may not re-use a filename for a different file or change that file in any way.).”
`Moore 1994 at 3.
`“A special file replication protocol is used between file servers. It provides mutual authentication
`to prevent spoofing, and pipelining to transfer large numbers of files effeciently, even over high-
`delay links. It may also accomodate compression on a per-file basis (for low-bandwidth links),
`and checkpointing to allow for recovery when transfers of large files are interrupted.” Moore
`1994 at 4.
`“The system should scale in several ways. User demand for any particular file can be distributed
`
`12
`PersonalWeb Technologies LLC v. EMC Corporation and VMware, Inc. (No. 6:11-cv-00660-LED) (E.D. Tex.)
`
`

`

`The ‘280 Patent Claims
`
`[36b] storing the data file is [sic]
`on a first server in the network and
`storing copies of the data file on a
`set of servers in the network
`distinct from the first server; and
`
`The LIFN Prior Art
`over multiple file servers. The location database is also distributed, both because each publisher
`maintains its own servers, and also because several servers can be provided for any publisher. In
`addition, the current location query protocol provides for a cacheable "redirect" response that
`allows the LIFN space for a particular publisher to be divided across several secondary servers,
`without imposing any additional structure on the LIFNs themselves. Because there is no need
`for synchronization, location updates can also be distributed across several servers, and
`effeciently transmitted among location server peers. This avoids the overhead with multi-phase
`commit protocols which would be needed to ensure consistency.” Moore 1994 at 4.
`“The system allows a client to consult a local cache or proxy server before attempting to access a
`file which may already be available locally. Since the binding between a LIFN and the file is
`fixed, if a client has a LIFN for a file, and the cache has a file which goes with it, the client has a
`reasonable assurance that the cached copy is correct (assuming it trusts the cache). If the time-to-
`live field in a location response is nonzero, LIFN-to-location bindings can also be reliably
`cached for that amount of time.” Moore 1994 at 4.
`“Finally, this system allows the potential that a client can select a "nearby" location from among
`several locations for a file, or from among several available location servers. A means by which
`this may be accomplished has been proposed and is under investigation.” Moore 1994 at 5.
`“A prototype version of this system is being constructed by the authors. A distributed location
`database and client library have been constructed and interfaced to Mosaic; the resulting client
`demonstrated the ability to (crudely) select from among multiple locations of a file, and to
`recover from the failure of both file servers and location database servers. The replication
`daemon and its associated protocols are currently under development.” Moore 1994 at 5.
`See also elements [36b] and [36c].
`The LIFN Prior Art discloses storing the data file on a first server in the network, and
`storing copies of the data file on a set of servers in the network distinct from the first
`server. For example, a data file stored on a file server (first server) is replicated onto a
`plurality of other file servers, such as mirror sites and/or cache sites (set of servers), which
`are distinct from the file server.
`“The main advantage of distributing a repository is to allow the software to be maintained by
`13
`PersonalWeb Technologies LLC v. EMC Corporation and VMware, Inc. (No. 6:11-cv-00660-LED) (E.D. Tex.)
`
`

`

`The ‘280 Patent Claims
`
`The LIFN Prior Art
`those in the best position to keep it up-to-date. Also, copies of popular software packages may
`be mirrored by a number of sites to increase availability (e.g., if one site is unreachable, the
`software may be retrieved from a different site) and to prevent bottlenecks.” Browne 1995 at 1–
`2.
`“[M]irror copies of a file cannot be located from a URL reference, since each copy has a
`different URL.” Browne 1995 at 2.
`“Higher-level names allow for long-lived human-readable references, while lower-level names
`permit reliable caching and mirroring as well as permitting precise references when needed.
`Location-independent names will be the basis of transparent mirroring.” Browne 1995 at 2.
`“It has been widely recognized that a solution to the above problems is to assign location-
`independent names to files and to provide a name-to-location service that, given a name, returns
`a list of locations for that name. A resource provider who moves some files need only delete the
`old