Filed on behalf of Microsoft Corporation
`
`By: John D. Vandenberg (Reg. No. 31,312)
`
`john.vandenberg@klarquist.com
`Stephen J. Joncus (Reg. No. 44,809)
`stephen.joncus@klarquist.com
`Klarquist Sparkman, LLP
`One World Trade Center, Suite 1600
`121 S.W. Salmon Street
`Portland, Oregon 97204
`Telephone: (503) 595-5300
`Facsimile: (503) 595-5301
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`MICROSOFT CORPORATION
`Petitioner
`
`v.
`
`PROXYCONN, INC.
`Patent Owner
`
`____________
`
`Case IPR2012-00026 (TLG)
`Case IPR2013-00109 (TLG)
`Patent 6,757,717 B1
`
`____________
`
`3rd Declaration of Professor Darrell D. E. Long
`Regarding U.S. Patent No. 6,757,717
`
`
`
`
`
`
`
`By: John D. Vandenberg (Reg. No. 31,312)
`
`john.vandenberg@klarquist.com
`Stephen J. Joncus (Reg. No. 44,809)
`stephen.joncus@klarquist.com
`Klarquist Sparkman, LLP
`One World Trade Center, Suite 1600
`121 S.W. Salmon Street
`Portland, Oregon 97204
`Telephone: (503) 595-5300
`Facsimile: (503) 595-5301
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`MICROSOFT CORPORATION
`Petitioner
`
`v.
`
`PROXYCONN, INC.
`Patent Owner
`
`____________
`
`Case IPR2012-00026 (TLG)
`Case IPR2013-00109 (TLG)
`Patent 6,757,717 B1
`
`____________
`
`3rd Declaration of Professor Darrell D. E. Long
`Regarding U.S. Patent No. 6,757,717
`
`
`
`
`
`
`
`
`
`
`
`QUALIFICATIONS
`
`I incorporate my qualifications as described in my two prior declarations
`
`I.
`II. COMPENSATION
`
`
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`(Ex. 1007 (1st IPR) and Ex. 1013 (2nd IPR) submitted in this matter.
`
`
`
`Counsel for Microsoft is compensating me at my standard compensation
`
`rate of $500/hour for consulting and $600/hour for testimony in deposition or trial,
`
`plus reimbursement for reasonably incurred expenses. I have no interest in the
`
`outcome of the related litigation or of this proceeding.
`
`III. SUMMARY OF MY STUDY AND CONCLUSIONS
`
`10
`
`
`
`I have reviewed the entire transcript of testimony of Dr. Alon Konchitsky in
`
`11
`
`12
`
`13
`
`14
`
`this matter, dated July 2, 2013. I have considered in particular pages 22–24, 28–
`
`30, 96–97, 109–11, and 141–55 of this transcript. I also have reviewed two
`
`versions of Dr. Konchitsky’s CV, one identified as Ex. 2003 (4 pages) and the
`
`other identified as Ex. 1022 (6 pages).
`
`15
`
`
`
`Based on these materials, I am of the opinion that Dr. Konchitsky is not an
`
`16
`
`17
`
`18
`
`19
`
`20
`
`expert in any field of endeavor material to the ’717 patent or the prior art
`
`references I have discussed in this matter. I am of the opinion that Dr. Konchitsky
`
`does not even qualify as having ordinary skill or knowledge in this field. More
`
`specifically, Dr. Konchitsky’s testimony demonstrates that he does not know what
`
`is common knowledge to experts in this field, about HTTP, caching, file systems,
`
`2
`
`
`
`
`
`
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`11
`
`12
`
`13
`
`14
`
`15
`
`16
`
`17
`
`18
`
`19
`
`20
`
`etc. He has not written about matters that experts in this field typically would have
`
`written about, has not worked in this field, and does not belong to the
`
`organizations to which experts in this field would typically belong.
`
`IV. FIELD OF THE INVENTION
`
`{For ease of reference, the below description is copied from my second
`
`declaration submitted in this matter.}
`
`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
`
`distributed data storage systems and networking, coding theory including error
`
`detection and 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
`
`{For ease of reference, the below description is copied from my second
`
`declaration submitted in this matter.}
`
`A person of ordinary skill in this art in 1998–99 would hold a B.S. degree in
`
`computer science and would have as part of his 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 require the student to
`
`3
`
`
`
`
`
`
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`11
`
`12
`
`13
`
`14
`
`15
`
`16
`
`17
`
`18
`
`19
`
`20
`
`examine actual source code. In addition he would have several years of practical
`
`experience working in operating systems, in particular the data storage subsystem.
`
`As a result, actual experience in working with this operating system
`
`subsystem would normally occur after several years of experience working for a
`
`company with a focus on systems software.
`
`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 his or her thesis
`
`in an area related to data storage and/or computer security.
`
`A person of ordinary skill in the art would understand network protocols.
`
`This was normally part of undergraduate programs in computer science 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.
`
`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.
`
`4
`
`
`
`
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`11
`
`12
`
`13
`
`14
`
`15
`
`16
`
`17
`
`18
`
`19
`
`20
`
`
`
`VI. DR. KONCHITSKY IS NOT AN EXPERT IN THIS FIELD
`
`He is Not Familiar with Technologies that Any Expert Would Know:
`
`HTTP GET: The HTTP protocols (e.g., HTTP/1.0 and HTTP/1.1) have
`
`been the application-level data communication protocol for the World Wide Web
`
`for more than 20 years. Any expert in this art would understand HTTP well. For
`
`example, many of the references under discussion refer to HTTP: the HTTP/1.1
`
`protocol is cited in DRP (Ex. 1003 (2nd IPR), p. 10), Mattis (Ex. 1004 (2nd IPR),
`
`14:4–5) and is cited prior art to the ’717 patent.
`
`Dr. Konchitsky testified that he was not comfortable testifying about the
`
`basic GET request in the HTTP protocol, and did not know whether a GET request
`
`identified the data it requests by its Uniform Resource Locator (URL).
`
`(Konchitsky TR 22:5–24:6). This lack of knowledge demonstrates a lack of even
`
`ordinary skill in the art. Persons of ordinary skill in the art in 1998–99, and today,
`
`would have no trouble describing an HTTP GET request. The HTTP/1.0 protocol
`
`defines only three methods: GET, HEAD and POST. A HTTP/1.0 GET request
`
`has only three elements: “GET” followed by the URL (e.g., /TheProject.html)
`
`followed by the protocol (e.g., “HTTP/1.0.”) The same is true of the HTTP/1.1
`
`GET method. (See, e.g., DRP, p. 7 (“GET /Example/home.html HTTP/1.1”). Any
`
`expert in this art would know without hesitation that an HTTP GET request
`
`identifies the desired resource by its URL.
`
`5
`
`
`
`
`
`
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`11
`
`12
`
`13
`
`14
`
`15
`
`16
`
`17
`
`18
`
`19
`
`20
`
`Caching Servers: Caching servers are a fundamental part of distributed data
`
`storage systems, networking and the World Wide Web. Yet, Dr. Konchitsky’s
`
`testimony shows he is utterly unfamiliar with the state of the art in caching servers
`
`in 1998.
`
`He testified that caching servers stored their caches in RAM, that he could
`
`not recall caching servers storing their caches on disk, and that he had no opinion
`
`as to whether any caching servers in 1998 stored their cache in nonvolatile
`
`memory. (Konchitsky TR 109:24–111:12). This testimony is akin to someone
`
`professing to be an expert on baseball history and having no opinion whether the
`
`Yankees ever won a World Series.
`
`Experts and even persons of ordinary skill in the art know that in the late
`
`1990s Web (and Internet) caching servers nearly universally used non-volatile
`
`(typically disk) storage for cache when used to cache Web pages or other files
`
`transmitted over the Internet. For example, Inktomi’s 1999 “Caching Guide” (Ex.
`
`1010 (2nd IPR)) explains the use of disks with web proxy caches. (E.g., id. at pp.
`
`18 (of 45) (“The size of the cache being managed is another consideration for
`
`scalability. The physical disks and their seek-times do not represent a measurable
`
`bottleneck, but the cache server software must be able to manage large amounts of
`
`data effectively.”), 30 (“Determining how large a cache to maintain is a trade-off
`
`between the cache hit rate and the cost of configuring disk storage. Cache capacity
`
`6
`
`
`
`
`
`
`
`can range from single cache servers to clusters of servers to distributed cache
`
`hierarchies.”), 36 (“Inktomi’s Object Store is a custom-designed and optimized
`
`Web-object database. It uses raw disk I/O to provide optimal storage and retrieval
`
`of content objects.”). So do Inktomi’s Mattis patents (Exs. 1015 (1st IPR) and
`
`1004 (2nd IPR).) Someone not knowing this lacks even ordinary skill in the art.
`
`Well-Known Technologies: In his examination, Dr. Konchitsky was asked
`
`a series of questions to test his knowledge of well-known technologies and systems
`
`and research in this field. He failed the test. In my opinion, no expert in this field
`
`could possibly be unfamiliar with more than perhaps one or two of the following:
`
`Harvest, Squid, LBFS (Low-Bandwidth File System), NFS, AFS (Andrew File
`
`System), Sprite, Rsync, xdelta, and Venti. Yet, Dr. Konchitsky was not familiar
`
`with any of them, not even the ones he said that he knew about.
`
`Harvest and Squid: Dr. Konchitsky testified that he was not familiar with
`
`Harvest or Squid. (Konchitsky TR 150:15–20, 153:11–12). Anyone who has
`
`studied distributed storage systems understands web proxy caches and knows of
`
`the seminal Harvest web cache and its derivative open-source Squid web cache.
`
`Each is directed to the same goal at issue here, reducing network bandwidth
`
`consumption. I raised the Harvest cache in my testimony. (Long TR, 51–53, 69).
`
`The following is an excerpt from a 2004 Ph. D. Thesis by my colleague Ethan
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`11
`
`12
`
`13
`
`14
`
`15
`
`16
`
`17
`
`18
`
`19
`
`20
`
`7
`
`
`
`
`
`
`
`Miller’s Ph. D. student (I sat on his dissertation committee), Ismail Ari, about
`
`Harvest and Squid:
`
`Web proxy caches [66] have successfully been used over the last
`decade to improve response times for web clients. These caches
`have also reduced network bandwidth consumption and server
`CPU utilization, thus contributing to scalable growth of the
`Internet. Web caches allow sharing of web objects among a
`community of web clients, thus they exploit web access patterns
`[36] to save Internet resources. The following is a description of
`three different architectures used for web content caching and
`dissemination.
`
`2.1.3.1 Hierarchical Web Caches
`
`Harvest Squid [66, 21] web caches have a hierarchical structure.
`They are widely–adopted around the world [16] today. They define
`parent–child relationships between levels of a cache hierarchy,
`thus forming a tree topology from the bottom (i.e. edges of the
`Internet) to the top levels. These caches establish and maintain
`connections between themselves and clients during web document
`transfers. The upper–level caches in a cache hierarchy serve misses
`of the lower–level caches.
`
`Santos (Ex. 1004 (1st IPR) cites to Squid. (Santos, p. 13). So does
`
`Inktomi’s Network Caching Guide (Ex. 1010 (2nd IPR), p. 33) (“Inktomi Traffic
`
`Server competes with the public domain Squid cache server.”) (Inktomi is the
`
`assignee on the Mattis patents and its Traffic Server web proxy caching server
`
`used an alias-free object cache (Ex. 1010 (2nd IPR), p. 37), which is what the
`
`Mattis patents describe.)
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`11
`
`12
`
`13
`
`14
`
`15
`
`16
`
`17
`
`18
`
`19
`
`20
`
`8
`
`
`
`
`
`
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`11
`
`12
`
`13
`
`14
`
`15
`
`16
`
`17
`
`18
`
`19
`
`20
`
`NFS (Network File System) and LBFS (Low Bandwidth File System): Dr.
`
`Konchitsky testified that he was familiar with NFS and LBFS (Konchitsky TR
`
`150:21–151:12, 151:23–152:5), but his testimony does not demonstrate that he was
`
`familiar with either. Any expert in data storage systems existing in the late 1990s
`
`understands the leading distributed file systems and knows that “NFS” is not a
`
`generic term for just any network file system but rather that Sun Microsystems
`
`developed the NFS protocol and file system. Similarly, LBFS is recognized by
`
`experts in the art not as a generic term for a file system designed for low-
`
`bandwidth networks, as Dr. Konchitsky seemed to have guessed, but rather as the
`
`specific LBFS network file system described in the paper “A Low-bandwidth
`
`Network File System” and developed at MIT. LBFS breaks data into chunks and
`
`sends hashes of those chunks between clients and servers to avoid unnecessarily
`
`consuming network bandwidth by transmitting data already present in the client’s
`
`cache. An expert in this field, asked to describe LBFS, would have referenced that
`
`feature or at least noted that LBFS was developed at MIT. Dr. Konchitsky did
`
`neither and could not say what “LBFS” meant. (Konchitsky TR 150:21–151:12).
`
`AFS (Andrew File System): Dr. Konchitsky testified that he did not know
`
`what the Andrew File System is. (Konchitsky TR 151:13–18). In this field, AFS
`
`is well known and is considered seminal. It is required reading in graduate courses
`
`in distributed systems and data storage, and has been for more than 20 years. It is
`
`9
`
`
`
`
`
`
`
`a distributed network file system developed at Carnegie Mellon. Each AFS client
`
`caches files on its file system.
`
`Sprite: Dr. Konchitsky testified that he did not know what Sprite is.
`
`(Konchitsky TR 151:19–22). Although less well known than AFS and NFS, an
`
`expert in this field would have heard of Sprite—a distributed operating system
`
`developed at UC Berkeley. It contributed important concepts including caching
`
`techniques, especially for locating files via a prefix cache.
`
`Rsync: Dr. Konchitsky purported to describe Rsync (Konchitsky TR 152:6–
`
`25), but his testimony demonstrates that he does not understand Rsync and was
`
`instead confusing it with rsh, a remote login shell that was distributed as part of the
`
`rlogin package in 4.2BSD (Berkeley UNIX). Rysnc is a protocol using chunk-
`
`based encoding to synchronize files over a network while reducing the
`
`consumption of network bandwidth. It was developed by Andrew Tridgell as part
`
`of his 1996 Ph.D. thesis. Contrary to Dr. Konchitsky’s testimony, it was not
`
`mainly for remote logging in over dial-up links with 30 kb/s bandwidth.
`
`Xdelta: This is a compression utility using delta encoding. It is an open
`
`source utility for computing the differences between files, originally based on the
`
`same algorithm as Rsync. Dr. Konchitsky was unable to identify it. (Konchitsky
`
`TR 153:1–4).
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`11
`
`12
`
`13
`
`14
`
`15
`
`16
`
`17
`
`18
`
`19
`
`20
`
`10
`
`
`
`
`
`
`
`Venti: Venti is a single instance network storage system developed at Bell
`
`Labs that uses hashes of data blocks as the address of the data. Dr. Konchitsky
`
`said he had heard of Venti but then misdescribed it as a “virtual network.”
`
`(Konchitsky TR 153:7–10).
`
`Ross Williams: Ross Williams is an Australian computer scientist with a
`
`seminal patent in data deduplication and compression. Most experts in this field
`
`would know of Ross Williams and the focus of his work. Dr. Konchitsky testified
`
`that he knew of Ross Williams but his testimony shows that he did not, as he mis-
`
`described Mr. Williams work as “different type of file systems.” (Konchitsky
`
`153:23–154:12).
`
`His CV Does Not Claim Expertise in This Field: Dr. Konchitsky’s six-page
`
`CV lists the following areas as his areas of expertise. Reading this list in the
`
`context of his entire CV, none of these areas is the field in which the ’717 patent
`
`resides. He lists “distributed computing” and “client server” but without
`
`specifying which aspects of these broad categories in which he professes expertise.
`
`His listed patents, work experience and writings do not pertain to these areas.
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`11
`
`12
`
`13
`
`14
`
`15
`
`16
`
`17
`
`18
`
`19
`
`20
`
`11
`
`
`
`
`
`
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`11
`
`12
`
`13
`
`14
`
`15
`
`16
`
`17
`
`18
`
`19
`
`20
`
`His Work Experience Demonstrates No Expertise or Even Ordinary Skill in
`
`
`
`This Field: As noted, a person of ordinary skill in the art in 1998–99 would have
`
`had several years of practical experience working in operating systems, in
`
`particular the data storage subsystem (or the equivalent post-graduate academic
`
`work). There is nothing in either of Dr. Konchitsky’s two CVs to support the
`
`claim that he has any expertise in these areas.
`
`His Patents Show No Expertise in This Field: The titles of his patents listed
`
`in his CV show no expertise in this field. I searched the U.S. Patent and
`
`Trademark Office database of patents for “Konchitsky” in the “Inventor” field and
`
`any of the following words in the “Description/Specification” field, finding no
`
`hits: server, client, proxy, hash, MD5, fingerprint, digest, signature, cryptographic,
`
`encryption, cache/cached/caching, proxy, “file system,” or HTTP.
`
`He Has Not Published in This Field: A typical expert in this field would
`
`have authored peer-reviewed publications in the field. Peer review by other
`
`12
`
`
`
`
`
`
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`11
`
`12
`
`13
`
`14
`
`15
`
`16
`
`17
`
`18
`
`19
`
`20
`
`experts is the standard for correctness and quality. Yet, Dr. Konchitsky testified
`
`that he has authored no peer-reviewed publications in any field. (Konchitsky TR
`
`149:15–25).
`
`Most experts in this field would have authored some publications in this
`
`field. Dr. Konchitsky’s Ph.D. thesis (“Multimode Multiband RF Transmitter”)
`
`(Konchitsky TR 150:1–5) is not pertinent to this field. Based on their titles, none
`
`of Dr. Konchitsky’s “publications” or patents listed in the two CVs, pertain to this
`
`field. None concern distributed data storage systems and networking, coding
`
`theory including error detection and correction codes, or cryptographic hash
`
`functions commonly called message digest functions. He testified that he had
`
`published no papers discussing hashing techniques or techniques for generating
`
`message digests or web caching or forward proxy caching or reverse proxy
`
`caching. In short, his writings demonstrate no expertise or experience in the
`
`relevant fields. (Konchitsky TR 154:13–155:2).
`
`He Does Not Belong to the Organizations in This Field: The three leading
`
`professional organizations in this field are USENIX, the Association for
`
`Computing Machinery, and the Computer Society of the IEEE. In my experience,
`
`the majority of experts in this field would belong to one or more of these
`
`organizations. Dr. Konchitsky testified that he belongs to none of them.
`
`(Konchitsky TR 150:6–14).
`
`13
`
`
`
`
`
`
`
`I declare under penalty of perjury under the laws of the United States of
`
`America that the foregoing is true and correct.
`
`Executed on the ___ day of August, 2013, in San Diego, California.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Darrell D. E. Long
`
`
`
`
`
`
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`11
`
`12
`
`13
`
`14
`
`15
`
`16
`
`17
`
`18
`
`19
`
`20
`
`14
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
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.
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.
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
