`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`Code200, UAB; Teso LT, UAB;
`Metacluster LT, UAB; and Oxysales,
`UAB,
`
` Petitioners,
`
` v.
`
`Luminati Networks LTD.,
`
` Patent Owner.
`
`CASE IPR2020-01266
`Patent No. 10,257,319
`
`DECLARATION OF DR. MICHAEL J. FREEDMAN
`
`I, Dr. Michael J. Freedman, declare as follows:
`
`I.
`
`BACKGROUND
`
`1.
`
`My name is Dr. Michael J. Freedman. I have been retained by Code200,
`
`UAB, UAB Teso LT, UAB Metacluster LT, and UAB Oxysales (“Petitioners”) in
`
`this IPR proceeding. This document provides certain of my opinions regarding the
`
`invalidity of U.S. Patent Nos. 10,257,319 (“’319 patent”), and specifically the
`
`following claims that I understand are at issue in this IPR proceeding: 1-2, 12, 14-
`
`15, 17-19, 21-22, 24-29 (collectively the “Challenged Claims”).
`
`2.
`
`For my work as an expert in this matter, I am being compensated for
`
`my services at my customary rate of $875 per hour, plus expenses. My compensation
`
`CODE200 ET AL, EXHIBIT 1009
`Page 1 of 194
`
`
`
`is in no way contingent or dependent upon my conclusions or the results of my
`
`analysis, or upon the outcome of this case.
`
`3.
`
`I am a trained computer scientist and engineer. I began programming
`
`online services in 1995, and received a Bachelor’s degree in 2001 and a Master’s
`
`degree in 2002 from the Massachusetts Institute of Technology, both in Computer
`
`Science and Engineering. I subsequently received a Ph.D. in Computer Science from
`
`New York University in 2007. From 2005 through 2007, I spent my doctoral studies
`
`as a research scholar at Stanford University. Since 2007, I have been a professor of
`
`computer science at Princeton University, initially as an Assistant Professor (2007-
`
`2013), then as a tenured Associate Professor (2013-2015), and since 2015 as a Full
`
`Professor. Between 2017 and 2020, I have also served as the Director of Graduate
`
`Studies for Computer Science at Princeton. I am also currently the co-founder and
`
`CTO of Timescale, a startup company building an open-source time-series database.
`
`My curriculum vitae is attached as Attachment 1. A list of the cases in which I have
`
`testified as an expert at trial or by deposition during the previous four years is at-
`
`tached as Exhibit 2.
`
`4. My research interests and experience primarily focus on Internet ser-
`
`vices, distributed systems, networking, and security. Since the year 2000, I have
`
`published over 85 peer-reviewed journal, conference, and workshop papers on these
`
`topics. According to my recent review of Google Scholar, these peer-reviewed
`
`2
`
`CODE200 ET AL, EXHIBIT 1009
`Page 2 of 194
`
`
`
`papers have been cited more than 15,000 times. A list of my publications is included
`
`in Attachment 1 to this Declaration. Of particular note here, I have published multi-
`
`ple papers concerning peer-to-peer systems (including peer-to-peer discovery, con-
`
`tent delivery, caching, and storage systems), multi-hop proxying systems, anonymity
`
`systems, web proxies, web caching, content delivery networks (CDNs), HTTP redi-
`
`rection, DNS services, server selection, distributed systems, Internet architecture,
`
`client-server protocols, and network communication.
`
`5.
`
`At Princeton, I teach graduate courses in computer systems and com-
`
`puter networking, as well as undergraduate courses in distributed systems and net-
`
`working. These courses have included materials on peer-to-peer (P2P) systems, web
`
`caching, and content delivery.
`
`6.
`
`I have been on the technical program committee for numerous confer-
`
`ences with peer-reviewed proceedings, including the main academic computer sci-
`
`ence venues for distributed systems (NSDI—Networked Systems Design and Im-
`
`plementation, OSDI—Operating Systems Design and Implementation, and SOSP—
`
`Symposium on Operating Systems Principles), networking (SIGCOMM—ACM
`
`Special Interest Group on Data Communications), and security (IEEE Security and
`
`Privacy, CCS—ACM Conference on Computer and Communications Security). I
`
`have been the technical program chair of multiple conferences, including the ACM
`
`Symposium on Cloud Computing (SOCC). I have served as a reviewer for numerous
`
`3
`
`CODE200 ET AL, EXHIBIT 1009
`Page 3 of 194
`
`
`
`leading journals, including Communications of the ACM, Transactions on Computer
`
`Systems (TOCS), Transactions on Networking (TON), and Journal of Computer Se-
`
`curity.
`
`7.
`
`I have also served as a consultant and advisor to Netflix, Cloudflare,
`
`Blockstack Labs, the Institute for Defense Analyses, Intelligent Automation, and
`
`Quova.
`
`8.
`
`I am the named inventor on six U.S. patents, including two that deal
`
`with methods to detect network middleboxes and proxies (which are applications or
`
`systems that interpose on network traffic), including through the behavior of HTTP
`
`protocols.
`
`9.
`
`I have received numerous national and international awards for my
`
`work. Of particular note, I received the 2018 ACM Grace Murray Hopper Award,
`
`given to the “outstanding young computer professional of the year, selected on the
`
`basis of a single recent major technical or service contribution”, which in my case
`
`was cited “for the design and deployment of self-organizing geo-distributed sys-
`
`tems”1 with a particular focus for my work on CoralCDN, a peer-to-peer content
`
`delivery network. I was elected as an ACM Fellow in 2019 “for contributions to
`
`robust distributed systems for the modern cloud”; the ACM Fellow is “ACM’s most
`
`prestigious member grade [which] recognizes the top 1% of ACM members for their
`
`1 Ex. 1020.
`
`
`
`4
`
`CODE200 ET AL, EXHIBIT 1009
`Page 4 of 194
`
`
`
`outstanding accomplishments in computer and information technology.” I was also
`
`awarded the Presidential Early Career Award for Scientists and Engineers (PE-
`
`CASE) in 2011, given by the White House’s Office of Science and Technology Pol-
`
`icy. In receiving this award, I was one of 20 individuals nominated by the National
`
`Science Foundation. I have also been awarded National Science Foundation's CA-
`
`REER Award, the Office of Naval Research’s Young Investigator Award, an Alfred
`
`P. Sloan Research Fellowship, membership in the Computer Science Study Group
`
`of the U.S. Department of Defense’s Defense Advanced Research Projects Agency
`
`(DARPA), the ACM SIGCOMM “Test of Time” Award for work on software-de-
`
`fined networking, the Casper Bowden Award for Outstanding Research in Privacy
`
`Enhancing Technologies, and multiple “Best Research Paper”-type awards from
`
`leading international conferences and symposia.
`
`10. My research and development has also led to deployed systems and in-
`
`dustrial impact in Web and Internet services. I designed, built, and operated an open
`
`Web content delivery system, CoralCDN, that had been publicly available between
`
`2004 and 2015, serving millions of unique users per day. DONAR solved locality-
`
`and load-aware cost optimizations for server selection, providing DNS- and HTTP-
`
`based name resolution for services on the Measurement Lab testbed from 2009-
`
`2013, including those powering the Federal Communications Commission’s Con-
`
`sumer Broadband Test. My research on IP geolocation and intelligence for Web
`
`5
`
`CODE200 ET AL, EXHIBIT 1009
`Page 5 of 194
`
`
`
`services led me to co-found Illuminics Systems, which was acquired by Quova (now
`
`part of Neustar) in 2006. My work on programmable enterprise networking helped
`
`form the basis for the OpenFlow/software-defined networking (SDN) architecture
`
`that was standardized by the Open Networking Foundation (an organization com-
`
`prised of most major telecommunications companies, networking vendors, and In-
`
`ternet and Online Service Providers).
`
`11.
`
`I am particularly familiar with topics related to peer-to-peer communi-
`
`cation system utilizing multiple intermediate hops that serve to proxy network com-
`
`munication. For example, I designed the communication layer for the Free Haven
`
`Project in 1999-2000, a system for anonymous storage, which utilized anonymous
`
`“remailers” for multi-hop privacy-preserving communication. My work on Free Ha-
`
`ven was subsequently published in 100 pages of the book “Peer-to-Peer: Harnessing
`
`the Power of Disruptive Technologies”, published by O’Reilly and Associates in
`
`2001. I subsequently designed and implemented another anonymous communication
`
`system in 2001-2002, Tarzan, that utilized “onion routing” for peer-to-peer commu-
`
`nication. My paper on Free Haven published in 2000 has been cited more than 500
`
`times, and my paper on Tarzan in 2002 has been cited almost 1000 times. My work
`
`on CoralCDN, published in 2004 and with more than 600 citations, described a peer-
`
`to-peer content delivery system involving many HTTP proxies, such that unmodified
`
`web browsers can communicate with CoralCDN proxies via HTTP, which can serve
`
`6
`
`CODE200 ET AL, EXHIBIT 1009
`Page 6 of 194
`
`
`
`web content either out of their cache, proxy requests to other CoralCDN proxies
`
`caching the content, or fetch content from origin web servers before returning it to
`
`clients. My work on FireCoral, published in April 2009, extended CoralCDN and
`
`described how client web browsers can share their caches in a peer-to-peer fashion
`
`with multi-source downloading, and thus fetch content from each other via secure
`
`HTTP range requests.
`
`12. As can be seen from the above outline of my educational background
`
`and employment history, I have extensive experience in the fields of distributed
`
`systems, HTTP and content delivery, peer-to-peer systems, Internet applications and
`
`services, and information storage and management applications. I deal frequently
`
`with the issues that are discussed in the Patents in Suit.
`
`13.
`
`If called upon to do so, I could and would testify truthfully regarding
`
`the points stated below in this declaration.
`
`II.
`
`LAW RELATING TO INVALIDITY
`
`14.
`
`I am not a lawyer. However, I have based my opinions herein on my
`
`understanding of the law relating to patentability or validity of patent claims.
`
`15.
`
`I understand that a patent claim is invalid for anticipation if a single
`
`prior art reference or system discloses every element of the patent claim. I
`
`understand that a claim is invalid for obviousness if the differences between the
`
`claimed subject matter and prior art are such that the subject matter as a whole would
`
`7
`
`CODE200 ET AL, EXHIBIT 1009
`Page 7 of 194
`
`
`
`have been obvious at the time the invention was made. I understand that the above
`
`analysis should be made from the perspective of a person of ordinary skill in the art
`
`(“POSA”). Further, for purposes of obviousness, I understand that I should consider
`
`the scope and content of the prior art, the differences between the prior art and the
`
`claimed invention, the level of ordinary skill in the art, and relevant secondary
`
`considerations. If references are to be combined as part of the analysis, I understand
`
`that another relevant consideration is whether and why a POSA would have been
`
`motivated to combine the applied references. Relevant secondary considerations
`
`may include such commercial success, long-felt but unmet need, failure of others,
`
`and unexpected results.
`
`16.
`
`I am informed that invalidity grounds beyond anticipation and
`
`obviousness, including indefiniteness, are not at issue in an inter partes review, and
`
`I therefore have not provided any opinions regarding any grounds for invalidity
`
`beyond anticipation and obviousness. Therefore, I also do not opine that any claim
`
`meets the standard for being definite.
`
`III. OVERVIEW OF ’319 PATENT
`
`17. The ’319 patent on its face indicates that it is a continuation of a patent
`
`application filed Sep. 12, 2013, which is a divisional application of a patent
`
`application filed Jul. 14, 2010 (issued as U.S. Pat. No. 8,560,604 on Oct. 15, 2013),
`
`8
`
`CODE200 ET AL, EXHIBIT 1009
`Page 8 of 194
`
`
`
`and that it also claims priority to a U.S. provisional patent application filed Oct. 8,
`
`2009. Ex. 1001, 1:7-18.
`
`18.
`
`I do not offer an opinion in this declaration as to whether any
`
`Challenged Claim of the ’319 patent is supported by the provisional patent
`
`application and/or entitled to the October 8, 2009 priority date. For purposes of my
`
`analysis, I assume that the ’319 patent is entitled to the October 8, 2009 priority date.
`
`A. Claims
`19. Claim 1 of the ’319 patent recites the following:
`
`1. A method for use with a first client device, for use with a first server
`that comprises a web server that is a Hypertext Transfer Protocol (HTTP)
`server that responds to HTTP requests, the first server stores a first content
`identified by a first content identifier, and for use with a second server, the
`method by the first client device comprising:
`
`receiving, from the second server, the first content identifier;
`
`sending, to the first server over the Internet, a Hypertext Transfer
`Protocol (HTTP) request that comprises the first content identifier;
`
`receiving, the first content from the first server over the Internet in
`response to the sending of the first content identifier; and
`
`sending, the first content by the first client device to the second server,
`in response to the receiving of the first content identifier.
`
`
`20. Claim 1 accordingly provides as follows: (i) a first client device
`
`receives from a second server a first content identifier that identifies a first content
`
`that is stored on a first server (that is a web server that responds to HTTP requests);
`
`(ii) the first client device sends an HTTP request to the first server containing the
`
`9
`
`CODE200 ET AL, EXHIBIT 1009
`Page 9 of 194
`
`
`
`first content identifier; (iii) the first client device receives the first content from the
`
`first server; and (iv) the first client device sends the first content to the second server.
`
`21. A POSA would understand that Claim 1 recites the standard use of an
`
`intermediary, where the “first client device” acts as an intermediary to retrieve from
`
`a web server (first server) content requested by a “second server,” and send the
`
`content to the second server.
`
`22. Claim 1 is the only independent claim of the ’319 patent. There are also
`
`a number of dependent Challenged Claims. As discussed further herein, the
`
`dependent ’319 Challenged Claims recite additional steps known to a POSA to be
`
`added to Claim 1. This includes that an HTTP header used in the prior art RTC 2616
`
`standard is used (Claim 15), that “TCP/IP” is used (such as in Claims 21, and 24-
`
`25), that other standard Internet protocols are used (Claim 22), or that a computer
`
`operating system is used (Claim 26).
`
`Specification
`
`B.
`23. Figure 3 of the ’319 patent depicts “peer[s],” a “client,” and an “agent”
`
`communicating, with the “agent” forming a connection to the web server:
`
`10
`
`CODE200 ET AL, EXHIBIT 1009
`Page 10 of 194
`
`
`
`
`
`Ex. 1001, Fig. 3. The patent specification states with respect to Figure 3 that “[t]he
`
`network 100 of FIG. 3 contains multiple communication devices,” that “each
`
`communication device may serve as a client, peer, or agent,” and that “a detailed
`
`description of a communication device is provided with regard to the description of
`
`FIG. 4.” Ex. 1001, 4:44-53.2
`
`24. The patent then provides a more detailed description of the
`
`“communication device” that “may serve as a client, agent, or peer”:
`
`
`
`FIG. 4 is a schematic diagram further illustrating a communication
`device 200 of
`the communication network 100, which contains general components of a
`com-
`
`
`2 All emphases in quotations have been added, unless otherwise noted.
`
`11
`
`CODE200 ET AL, EXHIBIT 1009
`Page 11 of 194
`
`
`
`puter. As previously mentioned, it should be noted that the communication
`device
`200 of FIG. 4 may serve as a client, agent, or peer.
`
`Ex. 1001, 5:52-57. The patent specification goes on to state that “[t]he
`
`communication device 200 includes a processor 202, memory 210, at least one
`
`storage device 208 . . .” Ex. 1001, 5:59-63. The specification also confirms other
`
`standard, off-the-shelf features of the “communication device,” including that its
`
`memory may include “ROM, hard drive, tape, CDROM, etc.” and that its
`
`input/output devices may include “a keyboard, mouse, scanner, micro-phone, etc.”
`
`or a printer. Ex. 1001, 6:14-24, 6:61-7:3.
`
`C. Alleged Benefit of the ’319 Patent
`25.
`I understand that Luminati and Teso are involved in a lawsuit currently
`
`pending in the U.S. District Court for the Eastern District of Texas (“Lawsuit”). I
`
`further understand that, in the Lawsuit, Luminati asserted that its patents, including
`
`the ’319 patent, allow for the benefit of “untraceability and anonymity.” Ex. 1008,
`
`p. 6. Luminati asserted that data center proxies “with a limited number of
`
`commercial IP addresses” could easily be blocked by a web server, whereas the
`
`usage of many “millions” of consumer devices as proxies provided many more IP
`
`addresses belonging to consumers, which could not easily be blocked. Ex. 1008, pp.
`
`6-7.
`
`12
`
`CODE200 ET AL, EXHIBIT 1009
`Page 12 of 194
`
`
`
`26. The usage of “consumer” IP addresses, “millions” of proxies, or
`
`anything related to “untraceability and anonymity” is not claimed in the Challenged
`
`Claims or described in the specification, and in my opinion it is therefore irrelevant
`
`to Luminati’s alleged invention. Further, the ’319 Patent as a whole, including its
`
`specification, does not mention untraceability and anonymity, neither as a goal nor
`
`specific mechanisms to achieve such. Regardless, the prior art presented in the
`
`Petition teach the alleged benefit identified by Luminati. The prior art teaches the
`
`inclusion of many ordinary computer users into a network of proxies that can send
`
`anonymous web requests on behalf of another user in order to promote anonymity,
`
`as explained further herein.
`
`D. Level of Ordinary Skill in the Art
`27. Unless otherwise stated, this declaration concerns the viewpoint of a
`
`person of ordinary skill in the art (“POSA”) with respect to the ’319 patent.
`
`28. Unless otherwise stated, when addressing the knowledge of a POSA or
`
`what would have been known or understood to a POSA, I refer to the time just prior
`
`to the earliest alleged priority date for the ’319 patent, October 8, 2009 (“Priority
`
`Date”).
`
`29. For purposes of this case, it is my opinion that a person of “ordinary
`
`skill in the art” to which the Asserted Patents pertain would have at least a bachelor’s
`
`degree in Computer Science or related field (or equivalent experience), as well as
`
`13
`
`CODE200 ET AL, EXHIBIT 1009
`Page 13 of 194
`
`
`
`two or more years of experience working with and programming networked
`
`computer systems as of the Priority Date. Such a person would be familiar with the
`
`underlying principles of Web, Internet, or network communication, data transfer,
`
`and content sharing across networks, including the ubiquitous and standard protocols
`
`of HTTP and TCP/IP. The opinions in my report are from the perspective of a POSA.
`
`IV. RELEVANT KNOWLEDGE OF A POSA
`
`30.
`
`In this section, I describe the state of the art prior to the Priority Date of
`
`the ’319 patent in 2009. This would be indicative of the working knowledge of a
`
`POSA at that time. Further, because the following discussion relates to Internet
`
`protocols, Internet communication, and proxies, this directly relates to the subject
`
`matter of the ’319 patent. Indeed, the ’319 patent specifically discusses the
`
`knowledge of a POSA in regards to HTTP, TCP/IP, IP addresses, and even the IETF
`
`RFC 2616 (the standard for the HTTP/1.1 protocol, published in 1999), as I further
`
`discuss later in this Declaration.3
`
`31. A POSA understands that the Internet may be described as having a
`
`number of stacks or layers (with this layered design more formalized in the so-called
`
`“OSI Reference Model” in the late 1970s and early 1980s), with a given layer serving
`
`the layer above it and being served by the layers below it:
`
`
`3 For example, see Claims 1, 2, 15, and 24-25 of the ’319 patent.
`
`14
`
`CODE200 ET AL, EXHIBIT 1009
`Page 14 of 194
`
`
`
`Layer 7: Application Layer
`
`Layer 6: Presentation Layer
`
`Layer 5: Session Layer
`
`Layer 4: Transport Layer
`
`Layer 3: Network Layer
`
`Layer 2: Data Link Layer
`
`Layer 1: Physical Layer
`
`32. The most common example of the Network Layer is the Internet
`
`Protocol (“IP”). Two common examples of the Transport Layer are TCP
`
`(Transmission Control Protocol) and UDP (User Datagram Protocol). Examples of
`
`the Application Layer include HTTP (Hypertext Transfer Protocol), FTP (File
`
`Transfer Protocol), and SMTP (Simple Mail Transfer Protocol, used with email).
`
`33. HTTP may be thought of as rules for carrying application-specific data
`
`between a source and a destination, for example, carrying HTTP protocol headers
`
`and world wide web data between a web browser and a webserver. HTTP is further
`
`discussed below.
`
`34. Because most Internet traffic uses TCP as a reliable, stream-based
`
`protocol, which itself typically runs on top of IP networks, Internet traffic is often
`
`described as “TCP over IP” or simply “TCP/IP.” When that traffic happens to also
`
`15
`
`CODE200 ET AL, EXHIBIT 1009
`Page 15 of 194
`
`
`
`use HTTP as the application layer protocol, it is often described as “HTTP over
`
`TCP/IP.”
`
`35.
`
`IP is an example of a well-known Network Layer protocol. IPv4 was
`
`published as an Internet Standard in RFC 791 in September 1981, while its successor
`
`IPv6 was published in RFC 2460 in December 1998. Exs. 1021, 1022. These
`
`“Request For Comments” (RFCs) serve as the informational drafts and formal
`
`standards for many Internet protocols, and are published by the Internet Engineering
`
`Task Force (IETF). The IP protocol (such as described in IPv4 and IPv6) describes
`
`a set of rules for defining a IP packet format, including a header with network source
`
`and destination address information, and a datagram body (some fixed-maximum-
`
`length message), and then transmitted those IP packets from an IP sender to an IP
`
`destination across links in a computer network. The datagram body, or message,
`
`carried within a single IP packet typically has a maximum length of around 1500
`
`bytes, which corresponds to a few paragraphs of text. The IP protocol only offers
`
`“best effort” delivery of IP packets: An IP sender can transmit an IP packet to an IP
`
`recipient (based on the IP addresses of sender and recipients that are in the packet’s
`
`headers), and the various networking routers will “attempt” to forward the packet to
`
`its proper destination, but the packet can be arbitrarily corrupted, dropped, or
`
`delayed. Because of this, when multiple IP packets belonging to the same “stream”
`
`– such as part of a web transfer between a webserver and a web browser – are sent
`
`16
`
`CODE200 ET AL, EXHIBIT 1009
`Page 16 of 194
`
`
`
`from a sender to recipient, the recipient may only receive some of the packets (others
`
`may be lost) and the packets may be received “out of order” from when sent (because
`
`some packets were delayed by the network or took a different path through the
`
`network than others). These limitations by the IP layer in providing a “reliable
`
`stream” abstraction are solved by the TCP protocol.
`
`36. The TCP protocol has also been well-known to a POSA for quite some
`
`time, having been standardized in September 1981 in the IETF RFC 793. Ex. 1023.
`
`TCP serves as a transport layer that makes the “best effort” packet delivery of the IP
`
`layer more usability by applications, such as Web browsing using HTTP. In
`
`particular, applications protocols like HTTP often want to deal with “reliable
`
`stream” abstractions: Applications can write a long “stream” of data, such as when
`
`transferring an individual webpage or an image that is embedded in the webpage.
`
`This webpage or image may be hundreds of kilobytes, many megabytes, or more.
`
`With a reliable stream, an application endpoint (such as a webserver) can open a
`
`“socket” that is associated with another application endpoint (such as a web
`
`browser), and then anything the server writes into the socket is received reliably and
`
`in the same order by the browser. This “socket” is a programming interface provided
`
`by the operating system on each endpoint. So to transfer a large file, the server just
`
`writes the content of the file, byte by byte, into its local socket, and the web browser
`
`receives the identical file by reading from its corresponding socket, byte by byte.
`
`17
`
`CODE200 ET AL, EXHIBIT 1009
`Page 17 of 194
`
`
`
`This “reliable stream abstraction” is enabled by TCP, as it builds on and adds
`
`functionality to the lower-level IP network layer: the stream of data is segmented
`
`into individual fixed-sized segments, where each segment is carried within a separate
`
`IP packet. Each segment is also associated with a sequence number, which allows a
`
`receiver to place IP packets that are received out-of-order back into the proper stream
`
`order. The sequence numbers also help receivers understand if certain segments are
`
`missing, and they subsequent can re-request missing segments from the sender, who
`
`retransmits these missing segments in order to ensure reliable delivery. TCP
`
`performs all these steps – connection management, reliable retransmission,
`
`reordering, and other features like flow and congestion control – as a component in
`
`the operating systems running on the sender and receiver, such as the web server and
`
`web browser. TCP is thus implemented on basically every common operating
`
`system, including Microsoft Windows, Apple Mac OS (including iOS running on
`
`iPhones), Linux (including Android for mobile), the BSD operating system, and
`
`every UNIX variant.
`
`37. HTTP is not the only application-level protocol that typically runs on
`
`TCP/IP. Most applicable-level protocols that rely on a reliable stream abstraction do
`
`as well. This includes application-level protocols such as FTP, SMTP, POP#, and
`
`others. FTP is the File Transfer Protocol, designed a standardized Internet protocol
`
`for easily transferring files between two hosts. FTP was standardized in RFC 959,
`
`18
`
`CODE200 ET AL, EXHIBIT 1009
`Page 18 of 194
`
`
`
`published in October 1985. Ex. 1024. SMTP is the Simple Mail Transfer Protocol,
`
`and describes a standardized Internet protocol for sending email messages reliably
`
`and efficiently. SMTP was standardized in RFC 821, published in August 1982. Ex.
`
`1025. POP is the Post Office Protocol, designed for allowing a user’s workstation or
`
`desktop to “download” its email from the user’s managed email server. The concept
`
`is that email servers should be connected to the Internet more continuously, and will
`
`run the SMTP protocol between the email servers. Then users can connect to their
`
`own mail servers to download and upload new email messages. The POP protocol
`
`was specified as POP version 1 (POP1) in RFC 918 in October 1984, version 2
`
`(POP2) in RFC 937 in February 1985, and version 3 (POP3) in RFC 1939 in May
`
`1996. Exs. 1026, 1027, 1028. Some other Internet protocols, such as DNS, make use
`
`of both UDP and TCP. DNS (Domain Name System) is a widely-deployed protocol
`
`for resolving domain names and other information on the Internet, e.g., it is how a
`
`web browser discovers the IP address associated with a URL’s domain or host name.
`
`DNS was defined in a few dozen RFCs, initially in RFC 1034 and 1035, both
`
`published in November 1987. Exs. 1029, 1030. Most DNS requests are small and
`
`can thus be sent over the User Datagram Protocol (UDP), which acts as a simple
`
`“best effort” transport protocol for applications that do not require the reliable and
`
`stream-oriented nature of TCP. Some larger DNS requests or transfers will use TCP.
`
`All of these protocols would be long known by a person of ordinary skill in the art.
`
`19
`
`CODE200 ET AL, EXHIBIT 1009
`Page 19 of 194
`
`
`
`I teach low-level details about many of them – including HTTP, TCP, UDP, IP,
`
`DNS, and others – in undergraduate networking courses, and higher-level
`
`knowledge of these protocols is exposed to undergraduate students at much earlier
`
`stages as well.
`
`38. Returning to HTTP, the notion of using an intermediary or proxy to
`
`obtain content, and particularly to obtain web content using HTTP as discussed in
`
`the ’319 patent, has been long known by a person of ordinary skill in the art. Indeed,
`
`the World Wide Web has had express support for the use of intermediates or proxies
`
`in order to obtain content from its early days. In particular, web browsers, clients,
`
`proxies, and servers all communicate via HTTP. The official specification of the
`
`HTTP protocol has appeared in various RFC drafts and standards; in particular, RFC
`
`1945 published in May 1996 defined HTTP version 1.0 (or HTTP/1.0 for short),
`
`while RFC 2616 published in June 1999 was the standard for HTTP version 1.1 (or
`
`HTTP/1.1). Exs. 1031, 1018. Both HTTP specifications described using
`
`intermediaries or proxies in detail, including express protocol-level support for
`
`proxy caching, performance acceleration, security and privacy, and more. Indeed,
`
`the HTTP specification expressly defines both transparent and non-transparent
`
`proxies and their purposes:
`
`“proxy: An intermediary program which acts as both a server
`and a client for the purpose of making requests on behalf of other
`clients. Requests are serviced internally or by passing them on,
`with possible translation, to other servers. A proxy MUST
`
`20
`
`CODE200 ET AL, EXHIBIT 1009
`Page 20 of 194
`
`
`
`implement both the client and server requirements of this speci-
`fication. A “transparent proxy” is a proxy that does not modify
`the request or response beyond what is required for proxy au-
`thentication and identification. A “non-transparent proxy” is a
`proxy that modifies the request or response in order to provide
`some added service to the user agent, such as group annotation
`services, media type transformation, protocol reduction, or ano-
`nymity filtering. Except where either transparent or non-trans-
`parent behavior is explicitly stated, the HTTP proxy require-
`ments apply to both types of proxies.”
`
`Ex. 1018, p. 9.
`
`Various deployments and configurations of such intermediaries or proxies
`
`were considered by the HTTP specification in the late 1990s and would be known
`
`to one of ordinary skill:
`
`“A more complicated situation occurs when one or more inter-
`mediaries are present in the request/response chain. There are
`three common forms of intermediary: proxy, gateway, and tun-
`nel. A proxy is a forwarding agent, receiving requests for a URI
`in its absolute form, rewriting all or part of the message, and for-
`warding the reformatted request toward the server identified by
`the URI. … The figure above shows three intermediaries (A, B,
`and C) between the user agent and origin server. A request or
`response message that travels the whole chain will pass through
`four separate connections.”
`
`Ex. 1018, p. 11.
`
`“In fact, there are a wide variety of architectures and configura-
`tions of caches and proxies currently being experimented with or
`deployed across the World Wide Web. These systems include
`national hierarchies of proxy caches to save transoceanic band-
`width, systems that broadcast or multicast cache entries, organi-
`zations that distribute subsets of cached data via CD-ROM, and
`so on. HTTP systems are used in corporate intranets over high-
`bandwidth links, and for access via PDAs with low-power radio
`links and intermittent connectivity. The goal of HTTP/1.1 is to
`
`21
`
`CODE200 ET AL, EXHIBIT 1009
`Page 21 of 194
`
`
`
`support the wide diversity of configurations already deployed
`while introducing protocol constructs that meet the needs of
`those who build web applications that require high reliability
`and, failing that, at least reliable indications of failure.”
`
`Ex. 1018, p. 12.
`
`Indeed, the word “proxy” or “proxies” appeared 38 times in the HTTP/1.0
`
`specification and 223 times in the HTTP/1.1 specification.
`
`39. The use of intermediaries or proxies in HTTP further accelerated with
`
`the emergence of commercial content delivery networks (CDNs) in the late 1990s,
`
`and such CDNs, which utilized intermediaries or proxies to obtain information from
`
`a target, would be well known to one of ordinary skill. Such CDNs in the 1990s
`
`include companies such as Akamai, Digital Island, Mirror Image, and Speedera, and
`
`new offerings continued to emerge through the 2000s including from CDN
`
`companies (e.g., Limelight, CDNetworks, Cotendo, Cloudflare) and telcos and ISPs
`
`(Level 3,