`
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`____________
`
`MICROSOFT CORPORATION
`Petitioner
`
`
`v.
`
`
`
`PROXYCONN, INC.
`Patent Owner
`
`____________
`
`U.S. Patent No. 6,757,717 B1
`Issued: June 29, 2004
`Application No. 09/398,007
`Filed: September 16, 1999
`Title: SYSTEM AND METHOD FOR DATA ACCESS
`
`____________
`
`DECLARATION OF PROFESSOR
`DARRELL D. E. LONG IN SUPPORT OF PETITION FOR
`INTER PARTES REVIEW OF U.S. PATENT NO. 6,757,717
`
`
`Page 1
`
`
`
`
`
`I.
`
`QUALIFICATIONS
`
`1.
`
`I am a Professor of Computer Science and Computer Engineering and
`
`have served as Associate Dean for Research and Graduate Studies in the Jack
`
`Baskin School of Engineering at the University of California at Santa Cruz. I hold
`
`the Kumar Malavalli Endowed Chair of Storage Systems Research and I am the
`
`Director of the Storage Systems Research Center, an internationally recognized
`
`center of excellence in data storage. I am also the Director of the Working-group
`
`on Applied Security and Privacy (WASP), the laboratory at the University of
`
`California at Santa Cruz that studies computer security. I teach graduate and
`
`undergraduate courses in computer security, operating systems, and data storage
`
`and have taught courses in networking and distributed systems. I received my B.S.
`
`degree in Computer Science from San Diego State University, and my M.S. and
`
`Ph.D. from the University of California, San Diego. I am a Fellow of the Institute
`
`of Electrical and Electronics Engineers (IEEE) and of the American Association
`
`for the Advancement of Science (AAAS). My research interests include data
`
`storage systems, operating systems, computer security, distributed systems and
`
`networking. My qualifications are further described in my appended Curriculum
`
`Vitae.
`
`2.
`
`I have published numerous papers including in the ACM Transactions
`
`on Storage, and various other journals, including those of IEEE, ACM, and
`
`Declaration of Professor Darrell D. E. Long
`
`
`
`Page 2
`
`
`
`
`
`USENIX. I am the co-author of two books. I have published more than 200 peer-
`
`reviewed articles, including 140 peer-reviewed conference papers. These
`
`publications are listed in Exhibit A. I am the founder of the premier conference in
`
`the data storage field known as the Symposium on File Storage Technologies
`
`(FAST). For the past six years, I served as Editor-in-Chief of ACM Transactions
`
`on Storage. I have participated in organizing numerous academic conferences in
`
`this field.
`
`3.
`
`I have also consulted for industry in the area of storage systems
`
`including for Hewlett-Packard Laboratories and IBM. I have also been a consultant
`
`to numerous agencies of the Federal government.
`
`II. COMPENSATION
`
`4.
`
`I am being compensated by counsel for Microsoft at my compensation
`
`rate of $650/hour for consulting and for testimony in deposition or trial, plus
`
`reimbursement for reasonably incurred expenses. I have no personal or financial
`
`interest in the outcome of the related litigation or this proceeding.
`
`III. SUMMARY OF MY STUDY AND CONCLUSIONS
`
`5.
`
`I have read U.S. Patent No. 6,757,717, filed September 16, 1999. The
`
`patent concerns technology within my areas of expertise. I have considered the
`
`patent’s disclosures from the perspective of a person of ordinary skill in the art in
`
`1998–99.
`
`Declaration of Professor Darrell D. E. Long
`
`
`
`Page 3
`
`
`
`
`
`6.
`
`I have studied the following references and considered them from the
`
`perspective of the person of ordinary skill in the art in 1998–99.
`
`7. Williams (Ex. 1002): Ross Williams, “Method for Partitioning a
`
`Block of Data into Subblocks and for Storing and Communicating Such
`
`Subblocks,” PCT WO 96/25801, published August 22, 1996 (“Williams”).
`
`8.
`
`DRP (Ex. 1003): Arthur van Hoff, John Giannandrea, Mark Hapner,
`
`Steve Carter, and Milo Medin, “The HTTP Distribution and Replication Protocol,”
`
`W3C Note, http://www.w3.org/TR/NOTE-drp-19970825.html, Aug. 1997
`
`(“DRP”).
`
`9. Mattis (Ex. 1004): Peter Mattis et al., U.S. Patent No. 6,292,880,
`
`“Alias-Free Content-Indexed Object Cache,” issued Sept. 18, 2001 on application
`
`filed Apr. 15, 1998 (“’880” or “Mattis”).
`
`10.
`
`I have compared these references to claims 15, 16, 17, 19, 20, 21, 25,
`
`26, and 27 of the ’717 patent. I have considered the perspective of the person of
`
`ordinary skill in the art in 1998–99 (defined below) who was designing a system in
`
`which data is sent over a network from some source and is stored by a receiver
`
`computer for possible later reuse, and having a design goal of reducing the
`
`transmission of redundant data over the network. I have considered such a person
`
`having read DRP with an eye toward using and possibly expanding on its
`
`teachings.
`
`Declaration of Professor Darrell D. E. Long
`
`
`
`Page 4
`
`
`
`
`
`11. These ’717 patent claims recite nothing innovative compared to these
`
`references. DRP discloses to the person of ordinary skill in the art in 1998–99
`
`everything required by these claims, with the possible exception of certain
`
`implementation details that would have been common knowledge to such skilled
`
`workers in the field. Skilled workers would have combined DRP with their own
`
`knowledge of the field to arrive at the claimed combinations of steps in these nine
`
`claims. That knowledge is found throughout the art, including in Mattis and
`
`Williams, as explained below. In other words, the person of skill in the art would
`
`have already possessed the claimed subject matter upon reading DRP, combined
`
`with their knowledge of the technology in the field (represented by Mattis and
`
`Williams), as explained below.
`
`12. Also, the patent is internally inconsistent and unclear on the meaning
`
`of “digital digest.” For purposes of my comparison of the claims to the prior art
`
`references, however, I have assumed that this term includes a fixed-size digital
`
`fingerprint (e.g., hash, message digest, signature or identifier), of 128 bits,
`
`calculated using an MD5 and/or CRC algorithm and calculated on arbitrary-size
`
`data, such that it represents and depends only on the content of that data.
`
`IV. FIELD OF THE INVENTION
`
`13. The ’717 patent defines its “field of the invention” as accessing data
`
`in communication networks. (’717, 1:10–15). The field also includes the areas of
`
`Declaration of Professor Darrell D. E. Long
`
`
`
`Page 5
`
`
`
`
`
`distributed data storage systems and networking, coding theory including error
`
`detection, error correction codes, erasure correction codes, and cryptographic hash
`
`functions commonly called message digest functions. These were all mature fields
`
`for many years prior to 1998–99.
`
`V. LEVEL OF SKILL IN THE ART IN 1998–99
`
`14. A person of ordinary skill in this art in 1998–99 would hold a B.S.
`
`degree in computer science or computer engineering and would have as part of
`
`their study courses in operating systems, networking, data compression and
`
`computer security. These studies would include the storage subsystem of computer
`
`operating systems which is covered briefly in most undergraduate operating
`
`systems courses, but few courses require the student to examine actual source
`
`code. In addition, they would have several years of practical experience working in
`
`operating systems, in particular the data storage subsystem.
`
`15. As a result, actual experience in working with this part of the
`
`operating system would normally occur after several years of experience working
`
`for a company with a focus on systems software.
`
`16. Alternatively, a person would develop the level of ordinary skill in the
`
`art in 1998–99 by obtaining an M.S. in computer science and by writing their
`
`thesis in an area related to data storage or applied computer security.
`
`Declaration of Professor Darrell D. E. Long
`
`
`
`Page 6
`
`
`
`
`
`17. A person of ordinary skill in the art would understand network
`
`protocols. This was normally part of undergraduate programs in computer science
`
`and computer engineering in 1998–99. A person of ordinary skill in the art would
`
`also understand coding theory; in particular error detection and correction codes, as
`
`well as cryptographic hash functions and message digest functions. Introduction to
`
`basic hash functions is a normal part of most undergraduate curricula, but coding
`
`theory is normally part of specialized courses (although it is commonly part of
`
`electrical engineering programs), and cryptographic hash functions would normally
`
`be taught only in courses in computer security.
`
`18.
`
`I have first-hand experience teaching and working with such persons
`
`of ordinary skill in the art. For example, I have taught students having about that
`
`level of skill in this art since at least as early as 1990.
`
`VI. REDUNDANT DATA TRANSFER
`
`19. Redundant data transfer became a significant issue in the mid-late
`
`1990s, during the massive growth of Internet traffic. I discussed aspects of this
`
`then-growing issue in an article co-authored with Randal Burns titled, “Efficient
`
`Distributed Backup With Delta Compression,” published November 1997 in the
`
`Proceedings of the Fifth Workshop On I/O In Parallel and Distributed Systems.
`
`(See also Mogul et al., Potential benefits of delta encoding and data compression
`
`for HTTP, Research Report 97/4a, Digital Western Research Laboratory (Dec.
`
`Declaration of Professor Darrell D. E. Long
`
`
`
`Page 7
`
`
`
`
`
`1997). By 1998–99, those in the field had recognized at least three scenarios that
`
`regularly lead to redundant data transfers that needlessly increased Internet traffic.
`
`In the same content / different name scenario, clients would request a file by using
`
`the file name, without realizing that they already held an exact copy of the file
`
`under a different name. (E.g., Williams at 57:2–4.) This scenario arose, e.g.,
`
`because different computers stored the same file with different names. In the same
`
`name / different content scenario, clients already possessing a file, but wanting to
`
`ensure that they had the latest version of that file, would request that file (again
`
`using the file name). This would result in the entire file being sent again, regardless
`
`of whether any changes had actually been made to the file. If no changes had been
`
`made, the data transfer would be redundant. The overlapping content scenario
`
`often involved a client requesting entire file directories even though the client
`
`already possessed some files in the directory – the transfer of those already-
`
`possessed files would be redundant.
`
`VII. SEARCH TECHNIQUES
`
`20. One approach to resolving these redundant data transfer scenarios
`
`involved use of data fingerprints to easily identify existing copies of data (or
`
`portions thereof). Instead of inefficiently transferring the entirety of the data, a data
`
`source could transfer over the network only the data fingerprint(s) of the requested
`
`data. Using these data fingerprints, the data requestor / receiver could use the
`
`Declaration of Professor Darrell D. E. Long
`
`
`
`Page 8
`
`
`
`
`
`fingerprints to determine which data it already had and then only request that data
`
`or data portions not in its possession, thereby avoiding redundant data transfers.
`
`DRP, Mattis, and Williams each describes this data fingerprint approach.
`
`21. During the relevant time period, persons of ordinary skill in the art
`
`would have turned to several known algorithms for these data fingerprint
`
`calculations. By this time period, the idea of data fingerprints was old, dating to at
`
`least the early 1980s. (See, e.g., Rabin, M. O. 1981. Fingerprinting by random
`
`polynomials. Tech. rep. TR-15-81, Center for Research in Computing Technology,
`
`Harvard University.) By the mid-late 1990s, known and commonly-used
`
`algorithms included MD5 and CRC-128, both of which calculated data fingerprints
`
`that were highly unlikely to produce the same fingerprint for different pieces of
`
`data (CRC only where only random collisions are of concern, not malicious
`
`collisions). (E.g., DRP at 3:4–7; Williams at 34:30–35:17 and 35:24–30.) I discuss
`
`both MD5 and the CRC class of algorithms in more detail below.
`
`22. Williams discloses details on ways to use data fingerprints to search
`
`for matching data in a storage area. Williams discloses using hash tables and
`
`multiple other data structures for storing the data and data fingerprints to facilitate
`
`such searching, i.e., to “determine quickly whether incoming subblocks are
`
`identical to any of those already held.” (Williams at 45:20–22; see also id. 44:27–
`
`46:20 (section titled “Comparing Subblocks”), Fig. 24, 10:16–21 (aspect no. 14),
`
`Declaration of Professor Darrell D. E. Long
`
`
`
`Page 9
`
`
`
`
`
`39:3–6, 65:5–11 (claim 14).) Mattis also refers to “hashing search techniques.”
`
`(Mattis at col. 9:23–24.) Below, I briefly describe what a hash table is, and how
`
`such searching using a hash table works, and why one implementing DRP likely
`
`would have used such hash-table searching techniques. Below I describe only what
`
`would have been well known to persons of ordinary skill in the art in 1998-99.
`
`23. A hash table is a table of data that is accessed using a function called a
`
`hash function. A hash function, h: d → r, is a function that maps a domain (such as
`
`the domain of text strings) onto a codomain of integers. If the mapping is one-to-
`
`one (injective) then it is deemed a perfect hash. In most cases, the domain is much
`
`larger than the codomain and so there will be multiple elements of the domain that
`
`map to the same element of the codomain. This is called a hash collision. It is a
`
`goal of cryptographic hash functions to make it extremely difficult to purposely
`
`create a collision, that is, to find two elements x and y such that h(x) = h(y).
`
`Essential to the design of a good hash function is that the change of a single bit in
`
`the domain results in the change of many bits in the codomain. Given a domain 1,
`
`…, n the range h(1), …, h(n) should appear to be statistically random, that is there
`
`should be no discernible relationship between h(k) and h(k + 1). Further, given a
`
`value h(x), it should be computationally infeasible to find y such that h(y) = h(x).
`
`Finally, it should be impossible to invert h, that is to find x given the value h(x).
`
`Declaration of Professor Darrell D. E. Long
`
`
`
`Page 10
`
`
`
`
`
`24. Given a text string s, locating the associated element is done by
`
`examining the hash table at location h(s). If there are multiple entries there, then
`
`they are examined to find the one with its access key equal to s. The search of
`
`these multiple entries does not have to be sequential, or even to examine every
`
`value, but can use data structure techniques that are known to every undergraduate
`
`in computer science.
`
`VIII. DRP TEACHES THE CLAIMED SUBJECT MATTER
`
`25. DRP taught a person of ordinary skill in the art each of the methods
`
`described in the nine patent claims under consideration. I describe some examples
`
`of these teachings below.
`
`26. Create MD5 Digital Digest of Data: DRP’s clients and servers each
`
`calculate MD5 (or other fingerprints) digests of each data file from the content of
`
`the file; it refers to these digests as “content identifiers.” (DRP at 3:12–31; 5:30–
`
`32; 6:9–20; 7:17–45; 11:3–7.)
`
`27. Create CRC Digital Digest of Data: Although DRP does not mention
`
`“CRC” specifically, it does say “typically a checksum algorithm is used.” (DRP at
`
`3:25.) This would immediately bring to mind the CRC class of algorithms, which
`
`are checksum algorithms. CRC stands for “cyclic redundancy check,” indicative of
`
`the fact that it is a checksum algorithm. Under its most common usage, a
`
`“checksum algorithm” is similar to but distinct from a hash function; both take a
`
`Declaration of Professor Darrell D. E. Long
`
`
`
`Page 11
`
`
`
`
`
`potentially large number of bits and map them to a smaller number of bits, but the
`
`goals are quite different. The most common use of a checksum algorithm, such as
`
`CRC (cyclic redundancy check), is for error detection: it takes a potentially large
`
`number of bits and creates a summary that is a smaller number of bits: 16, 32, 128,
`
`such that if one or more bits of the original string of bits changes then so will the
`
`checksum. The simplest checksum algorithm is called parity, and is 0 if the number
`
`of 1 bits is even, and 1 if the number of 1 bits is odd. It can detect a single bit error,
`
`but two bit errors can go undetected. The CRC family of codes were designed to be
`
`easy to implement, efficient to execute, and well-suited to detect “burst errors” that
`
`are commonly found in communication systems. “Burst errors” are bit errors that
`
`occur together in a burst, rather than randomly in the bit string. The larger the
`
`number of bits in the CRC, the larger the number of bit errors that can be detected.
`
`28. DRP uses the term “checksum algorithm” more broadly than its
`
`common usage to also encompass hash algorithms, e.g., when it refers “to a well
`
`known checksum algorithm such as MD5 or SHA.” (DRP 4:11–13.) (Other
`
`common names for such checksums are cryptographic checksum and
`
`cryptographic digest.) It also states “it is possible to verify the integrity of the
`
`content” which is exactly the primary purpose of the CRC family of algorithms.
`
`Given this broader usage, and an implicit teaching towards content verification, a
`
`person of ordinary skill would understand DRP to encompass at least CRC-128
`
`Declaration of Professor Darrell D. E. Long
`
`
`
`Page 12
`
`
`
`
`
`within its meaning of “checksum algorithms.” In other words, if “checksum
`
`algorithm” is used to include MD5, which is not commonly thought of as a
`
`checksum algorithm, then a skilled artisan would know that it also encompasses
`
`CRC-128, which is commonly considered a checksum algorithm.
`
`29. Sender Sending Digests To Receiver: DRP’s server sends an “index
`
`file” to the client with separate digest values for each data file, and discloses doing
`
`that for some or for all of the files on the server. (DRP at 4:37–5:33.)
`
`30. Sender Sending “Principal” And “Auxiliary” Digests: DRP’s server
`
`stores multiple versions of the same file, which is how it is able to calculate and
`
`send the differences between two versions of the same file. (DRP at 8:1–37.)
`
`DRP’s server also optionally sends the client, in a single index file for the entire
`
`contents of the server site, separate MD5 identifiers for each file. (Id. at 4:36–5:32,
`
`10:45–11:2.) DRP teaches including a separate MD5 identifier for each server-
`
`stored version of the same file (5:30–32; 7:17–19; 11:5–6), although it allows for
`
`omitting content identifiers in certain circumstances (7:10–12).
`
`31. Receiver Searching For Data With Same Digest As Received Digest:
`
`For each file that is new or changed, DRP’s client searches its disk cache indexed
`
`by MD5 content identifiers for data with the same MD5 digest. (DRP at 5:30–32;
`
`6:40–7:8) This allows the client to determine whether it already has data with the
`
`“principal” digest (in which case it uses that data) (DRP at 7:3–5) or, if not, already
`
`Declaration of Professor Darrell D. E. Long
`
`
`
`Page 13
`
`
`
`
`
`has data with the “auxiliary digest” (in which case it issues a partial indication
`
`signal (“differential GET”)) (id. at 8:11–13).
`
`32. Receiver Sending Negative Indication to Sender: If the search fails to
`
`find the desired data, DRP’s client may send a GET request specifying the separate
`
`file name and MD5 identifier of each file it wants. (DRP at 6:40–44; 7:20–31.)
`
`33. Receiver Sending Partial Indication to Sender: When DRP’s client
`
`finds the auxiliary digest in its cache, it sends a differential GET request specifying
`
`the separate file name and the MD5 identifier of the version it has and the MD5
`
`identifier of the version it wants, requesting the differences between those versions.
`
`(DRP at 8:1–27.)
`
`34. Sender Sending Requested Data To Receiver: DRP’s server sends the
`
`client the data file requested in a GET request (DRP at 7:30–35, 9:3–19) or the
`
`version differences (e.g., between “principal” and “auxiliary” versions) requested
`
`in a differential GET request (id. at 8:14–34, 9:3–19).
`
`35. Packet-Switched Network: DRP’s server is a sender/computer and
`
`DRP’s client is a receiver/computer. The DRP server and client carry out their data
`
`transfers in a packet-switched network, i.e., the Internet, using the HTTP protocol,
`
`which is transmitted over TCP/IP, the ubiquitous packet-switched protocol suite.
`
`For example, DRP states that “[t]his document provides a specification of a
`
`protocol for the efficient replication of data over HTTP.” (DRP at 1:29.) In the
`
`Declaration of Professor Darrell D. E. Long
`
`
`
`Page 14
`
`
`
`
`
`1998–99 time-frame, the HTTP protocol was well-known for its use in transferring
`
`data over the World Wide Web (“Web”). The Web, in turn, was simply one way of
`
`accessing data over the Internet, a network known to use packet-switching for data
`
`transfers.
`
`36. Sender/Computer and Receiver/Computer: A person of ordinary skill
`
`in the art would have understood DRP to extend to any client device that utilized
`
`the HTTP protocol. In 1998–99, that necessarily included commonly-found
`
`computers such as PCs and Sun workstations. Each of these computers relied on
`
`standard hardware and software, including non-volatile or permanent memory
`
`(such as flash memory or a hard disk drive), volatile memory (such as RAM), and
`
`processors running operating systems (e.g., Windows on PCs and UNIX on Sun
`
`machines). The same is true of the DRP server—a person of ordinary skill would
`
`understand it to extend to standard Web servers. Such Web servers also necessarily
`
`included at least the same hardware and software as the client (and often included
`
`more memory, more computing power, and special server software such as Apache
`
`Web server software). Not only was this hardware and software standard on client
`
`and server machines, but it would have been necessary for carrying out the
`
`processes described in DRP. For example, calculation of DRP’s content identifiers
`
`would have involved use of the processor and volatile memory, while storage of
`
`the actual data, e.g., would involve use of non-volatile memory.
`
`Declaration of Professor Darrell D. E. Long
`
`
`
`Page 15
`
`
`
`
`
`37. Network Cache: DRP describes how “a client can use a disk cache for
`
`data files, which is accessed using content identifiers” and that “[t]his means that if
`
`multiple indexes refer to a file with the same content identifier, the client can
`
`automatically detect that the file is already in the cache, and thus avoid
`
`downloading the file a second time.” (DRP at 7:2–8.) A person of ordinary skill in
`
`the art would have understood this client “disk cache” to store data files
`
`downloaded from the network in memory on the client computer. Most typically,
`
`the cache would be stored on non-volatile memory (such as a hard disk) but
`
`portions of the cache would necessarily be in volatile memory so that they could be
`
`used for computational purposes.
`
`IX. SKILLED ARTISANS WOULD HAVE USED CRC-128 INSTEAD
`OF MD5 IN SOME APPLICATIONS OF DRP’S TEACHINGS
`
`38. As mentioned previously, computation of the CRC family of functions
`
`was designed to be simple and highly efficient. In the case where there is no
`
`adversary, that is, it is not a situation where collision resistance must be enforced
`
`(such as in cryptography), a CRC provides a quick and easy way to implement a
`
`digital digest of a large number of bits. As discussed above in paragraphs 24–25, a
`
`skilled artisan reading DRP’s instruction to use “a well known checksum” would
`
`think of the CRC algorithms, including CRC-128, which were well known for use
`
`in creating checksums. As CRC-128 is less much less complex and more efficient
`
`to compute than MD5, a skilled artisan would be motivated to use it instead of
`
`Declaration of Professor Darrell D. E. Long
`
`
`
`Page 16
`
`
`
`
`
`MD5 in certain applications of DRP where only random collisions are of concern,
`
`not malicious collisions.
`
`X.
`
`SKILLED ARTISANS WOULD HAVE USED TEACHINGS IN
`MATTIS IN SOME APPLICATIONS OF DRP’S TEACHINGS
`
`39.
`
`I have been asked to consider the question whether a person of
`
`ordinary skill in the art considering the redundant-data transmission problem
`
`addressed by these patent claims, and aware of relevant prior art references (but
`
`not aware of the ’717 patent’s disclosure), would have had an apparent and natural
`
`reason to combine the teachings of these two references (DRP and Mattis) in the
`
`manner claimed in these patent claims. In other words, would such a person
`
`starting with DRP and applying ordinary skill and common sense, have combined
`
`its teachings with teachings from Mattis to reach the same combination claimed in
`
`these claims. For example, would such a person have seen a benefit of
`
`implementing the DRP protocol in clients, web proxy cache server, and other
`
`HTTP servers of the type described in Mattis. The answer is yes. For multiple
`
`reasons, a person having ordinary skill in the art looking to expand upon Mattis
`
`would have looked to DRP and, conversely, one looking to implement DRP would
`
`have looked to Mattis. As explained below, some of these reasons are that these
`
`two references address the same problem, present the same algorithmic solution to
`
`that problem, and apply that shared solution to the same type of application.
`
`Further, nothing in these two references teaches away from their combination.
`
`Declaration of Professor Darrell D. E. Long
`
`
`
`Page 17
`
`
`
`
`
`40.
`
` Same Problem: First, each reference addresses the same problem as
`
`the ’717 patent: the desire to reduce redundancy in network data transmissions
`
`where certain data has been received over a network and is stored by a proxy cache
`
`(or client cache) for possible later reuse. The ’717 patent identifies the following
`
`objects among others: “It is therefore a broad object of the present invention to
`
`provide a method, system and apparatus for increasing the speed of data access in a
`
`packet-switched network. Another object of the present invention is to decrease
`
`data traffic throughout the network. Still another object of the present invention is
`
`to decrease the required cache size.” (’717, 1:61–67).
`
`These were well-known goals in the mid-1990s for designers of network
`
`caching systems. It was known that redundant network transmissions and
`
`redundant cache storage could arise, for instance, when downloaded data is subject
`
`to change at its original source and/or the same downloaded data content exists on
`
`the network under two or more different names. (E.g., DRP at 2:11–30, 3:2–4.)
`
`When the data is subject to change at the source, a proxy cache might wastefully
`
`download that same data from the original source each time it is requested by a
`
`client, for fear that the proxy cached version is out of date. When the data exists
`
`and is requested by clients under various names, the proxy cache might wastefully
`
`download the same data in response to those requests, and cache duplicate copies
`
`of that data. (E.g., DRP at 7:2–8 (discussing how to overcome such redundant
`
`Declaration of Professor Darrell D. E. Long
`
`
`
`Page 18
`
`
`
`
`
`caching).) Each of DRP and Mattis addresses how to avoid such redundant
`
`downloads and storage of redundant copies. “[D]ifferent sites often refer to the
`
`same standard libraries or images, and because their content identifiers match,
`
`multiple redundant downloads can be avoided.” (DRP at 7:5–6; see also id. at 7:2–
`
`8). “The technology described herein provides for a cache object store for a high-
`
`performance, high-load application having the following general characteristics: …
`
`Alias free, so that multiple objects or object variants, with different names, but
`
`with the same content identical object content, will have the object content cached
`
`only once, shared among the different names.” (Mattis at 4:48–52, 4:64–68).
`
`This shared problem would have motivated a person having ordinary skill in
`
`the art to consider these references together.
`
`41. Same Solution: Second, each reference proposes the same
`
`algorithmic solution to this problem. Each uses MD5 digest fingerprints. (E.g.,
`
`DRP at 6:35, 7:43–45, 9:29–32, 10:45–11:6; Mattis at 5:43–46, Figs. 3A and 11,
`
`Abstract, 5:27–6:4, 8:18–9:6, 9:36–63, 20:13–18.) Each calculates an MD5 digest
`
`from the content in question to represent that content. (E.g., DRP at 6:35, 7:43–45,
`
`9:29–32, 10:45–11:6; Mattis at 8:18–36.) Each transmits MD5 digest fingerprints
`
`over the network. (E.g., DRP at 4:41–5:32; Mattis at Fig. 1-2 and 11, 1:14–2:14,
`
`9:65–10:10, 27:50–28:2, 37:26–31, 37:42–45.) Each receiver of those MD5 digests
`
`compares that network-transmitted MD5 digest to its own cached MD5 digest
`
`Declaration of Professor Darrell D. E. Long
`
`
`
`Page 19
`
`
`
`
`
`fingerprint values. (E.g., DRP at 5:30–32; Mattis at Fig. 9A, 27:49–28:55, 8:18–36,
`
`12:7–12.) Each relies on a match between two MD5 digital digest values to avoid
`
`an otherwise redundant transmission or storage of duplicate copies of the same
`
`data content. (E.g., DRP at 2:29–30, 7:3–5, 9:43–45; Mattis at Figs. 2-6, 9, 11,
`
`Abstract, 1:53–2:28, 5:40–55, 7:58–62, 8:18–9:6, 9:50–63, 10:23–39, 11:3–20,
`
`11:43–56, 12:42–50, 13:15–17, 13:34–38, 14:6–27, 16:49–62, 17:27–55, 20:13–
`
`18, 21:1–2, 24:24–47, 27:49–28:55, 35:43–52, 36:23–28, 36:38–50, 37:53-38–24.)
`
`This common algorithmic solution would have motivated a person having ordinary
`
`skill in the art to consider these references together.
`
`42. Same Application: Third, each reference teaches that its techniques
`
`can be used to distribute the same type of content over the same type of
`
`distribution system, namely web server files and content over the existing HTTP
`
`web architecture, including the Internet (with its routers, switches, ISPs, proxies,
`
`etc.) and web proxy caches. HTTP DRP “provides a specification of a protocol for
`
`the efficient replication of data over HTTP network routers” (DRP at 1:29) and
`
`describes “functionality that can be deployed anywhere where HTTP is available
`
`today” (id. at 2:22). With Mattis, “a client may be able to access replicas from a
`
`topologically proximate cache faster than possible from the original web server,
`
`while at the same time reducing Internet server traffic.” (Mattis at 1:62–65).
`
`Declaration of Professor Darrell D. E. Long
`
`
`
`Page 20
`
`
`
`
`
`43. Mattis Contemplates HTTP-DRP Type Requests: Fourth, Mattis
`
`expressly acknowledges that clients may request a particular object by identifying
`
`the object’s MD5 digest, but that clients typically instead request an object by its
`
`object name, such as a URL or file system name. (Mattis at 9:65–10:4). Therefore,
`
`as shown in Fig. 9A, step 904, the Mattis system includes the capability of
`
`converting an object name included in such a request to that object’s MD5 digest
`
`value (object key value). After that conversion step, the rest of Fig. 9A uses the
`
`MD5 digest of the object. However Mattis obtains the MD5 digest from the
`
`request, whether directly from the object request (e.g., an HTTP DRP request) or
`
`indirectly by converting the object’s name to its MD5 digest, the operation
`
`thereafter using that MD5 digest is the same. Therefore, Mattis and HTTP DRP
`
`fully operate together without changing either.
`
`44. No Teaching Away: Finally, nothing in either reference or outside
`
`either reference teaches away from their combination. No essential feature in
`
`Mattis conflicts with an essential feature of HTTP DRP. Nothing stated in Mattis
`
`would lead a person having ordinary skill in the art away from using it to
`
`implement HTTP DRP and nothing stated in HTTP DRP would lead a person
`
`having ordinary skill in the art away from implementing it using Mattis.
`
`
`
`Declaration of Professor Darrell D. E. Long
`
`
`
`Page 21
`
`
`
`I declare under penalty of perjury under the laws of the united states of
`
`America that the foregoing is true and correct.
`
`2016, in Paris, France
`
`DarrellD"Wong
`
`Declaration of Professor Darrell D. E. Long
`
`Page22