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

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