throbber
UNITED STATES PATENT AND TRADEMARK OFFICE
`
`____________
`
`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

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket