UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`GUEST TEK INTERACTIVE ENTERTAINMENT LTD.,
`
`Petitioner,
`
`v.
`
`NOMADIX, INC.,
`
`Patent Owner.
`
`U.S. Patent No. 8,266,266 to Short et al.
`Issued: September 11, 2012
`Filed: January 11, 2010
`
`Title: SYSTEMS AND METHODS FOR PROVIDING DYNAMIC NETWORK
`AUTHORIZATION, AUTHENTICATION AND ACCOUNTING
`
`____________
`
`IPR2018-01668
`
`____________
`
`Declaration of Dr. Peter Dordal
`
`September 7, 2018
`
`GUEST TEK EXHIBIT 1004
`Guest Tek v. Nomadix, IPR2018-01668
`
`
`____________
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`GUEST TEK INTERACTIVE ENTERTAINMENT LTD.,
`
`Petitioner,
`
`v.
`
`NOMADIX, INC.,
`
`Patent Owner.
`
`U.S. Patent No. 8,266,266 to Short et al.
`Issued: September 11, 2012
`Filed: January 11, 2010
`
`Title: SYSTEMS AND METHODS FOR PROVIDING DYNAMIC NETWORK
`AUTHORIZATION, AUTHENTICATION AND ACCOUNTING
`
`____________
`
`IPR2018-01668
`
`____________
`
`Declaration of Dr. Peter Dordal
`
`September 7, 2018
`
`GUEST TEK EXHIBIT 1004
`Guest Tek v. Nomadix, IPR2018-01668
`
`
`
`
`
`TABLE OF CONTENTS
`
`INTRODUCTION ........................................................................................... 1
`I.
`II. QUALIFICATIONS AND PROFESSIONAL EXPERIENCE ...................... 1
`III. MATERIALS CONSIDERED IN FORMING MY OPINIONS .................... 3
`IV. SUMMARY OF OPINION ............................................................................. 4
`V. UNDERSTANDING OF LEGAL PRINCIPLES ........................................... 4
`VI. THE ‘266 PATENT ......................................................................................... 7
`VII. PRIORITY DATE FOR CLAIMS 1 AND 24 OF THE ‘266 PATENT ....... 11
`VIII. CLAIM CONSTRUCTION .......................................................................... 13
`IX. LEVEL OF ORDINARY SKILL IN THE ART ........................................... 14
`TECHNICAL BACKGROUND AND STATE OF THE ART AT TIME OF
`X.
`ALLEGED INVENTION .............................................................................. 16
`XI. OVERVIEW OF SPECIFIC PRIOR ART .................................................... 28
`A. U.S. Patent No. 6,226,677 (“Slemmer”) ............................................. 28
`B. U.S. Patent No. 6,389,462 (“Cohen”) ................................................. 31
`XII. OPINION REGARDING OBVIOUSNESS OF CLAIMS 1 AND 24 OF THE
`‘266 PATENT ................................................................................................ 36
`A.
`Slemmer and Cohen Disclose All Limitations of Claim 1.................. 36
`B.
`Slemmer and Cohen Disclose All Limitations of Claim 24 ............... 45
`C. Motivations to Combine Slemmer and Cohen to Arrive at Claimed
`Inventions ............................................................................................ 51
`
`
`
`
`
`i
`
`
`
`I.
`
`INTRODUCTION
`1.
`My name is Dr. Peter Dordal, and I have been retained as a
`
`technical expert by counsel for Petitioner Guest Tek Interactive Entertainment
`
`Ltd. to provide assistance in the above captioned inter partes review
`
`proceeding. Specifically, I have been asked by counsel to opine on the
`
`validity of claims 1 and 24 of U.S. Patent No. 8,266,266 (“the ‘266 patent”).
`
`This report contains a statement of my opinions formed in this matter and
`
`provides the bases and reasons for those opinions. I make the following
`
`statements based on my own personal knowledge and, if called as a witness,
`
`I could and would testify to the following.
`
`II. QUALIFICATIONS AND PROFESSIONAL EXPERIENCE
`2.
`I have included as Attachment A a copy of my current
`
`curriculum vitae, which provides an overview of my qualifications and
`
`professional experience in relation to this matter. To summarize, I received
`
`my undergraduate and masters’ degrees in Mathermatics in 1978 from the
`
`University of Chicago, and my Ph.D. in Mathematics from Harvard
`
`University in 1982.
`
`3.
`
`Since receiving my doctorate degree in 1982, I have been
`
`employed as a faculty member at Loyola University Chicago, first in the
`
`Mathematical Sciences Department and then, starting in 2001, in the newly
`1
`
`
`
`
`
`formed Computer Science Department. I received tenure in 1988, and was at
`
`that time promoted to Associate Professor, my current rank. For the past 36
`
`years, I have focused on teaching computer programming courses to
`
`undergraduate and graduate students, including Programming Languages,
`
`Computer Networks, and Advanced TCP/IP Networks. During part of my
`
`tenure, I was Acting Chair and Graduate Program Director for the Computer
`
`Science Department. I am also currently supervising a student thesis called
`
`Software-defined Networking and Dynamic Traffic Rerouting.
`
`4.
`
`From 1984-2003, I was
`
`the System Administrator for
`
`departmental computing facilities at Loyola University. As System
`
`Administrator, my responsibilities included managing University computers
`
`and network services, supporting University workstations, and maintaining
`
`University computer labs. Sometimes this work entailed significant software
`
`development; for example, I implemented a TCP/IP layer for the University
`
`that allowed communication between computers supporting only the 3BNET
`
`networking software and a server supporting TCP/IP. My other exemplary
`
`experiences in system management and programming through the University
`
`are set forth in Attachment A.
`
`5.
`
`Since 1982, I have also spent a significant amount of time, as part
`
`2
`
`
`
`
`
`
`
`of my everyday course preparation and teaching, conducting research on, as
`
`well as performing and demonstrating, computer programing and network
`
`device management and support.
`
`6.
`
`In addition to my professional experience, I have published a
`
`substantial number of books and articles on computer programming networks.
`
`For example, I authored the book An Introduction to Computer Networks,
`
`published by Loyola University of Chicago in 2012. I also significantly
`
`contributed to the book Computer Networks: A Systems Approach, 2nd Edition,
`
`Peterson & Davie, Morgan-Kaufmann 2000, which provides computer
`
`network and protocol exercises for students. I fill list of my publications and
`
`contributions is shown in my attached curriculum vitae.
`
`7.
`
`I am a member of the Mathematical Association of America and
`
`the Association for Symbolic Logic.
`
`III. MATERIALS CONSIDERED IN FORMING MY OPINIONS
`8.
`In preparing this declaration, I have reviewed and relied on
`
`various materials, including but not limited to the following exemplary
`
`materials: (1) certain prior art, including the prior art cited in this declaration;
`
`(2) the ‘266 patent; (3) the ‘266 patent’s prosecution history; (4) U.S.
`
`Provisional Application No. 60/111,497; and (6) all of the other materials
`
`referenced in this declaration.
`
`3
`
`
`
`
`
`IV.
`
`SUMMARY OF OPINION
`9.
`As described in more detail below, it is my opinion that claims 1
`
`and 24 of the ‘266 patent would have been obvious to a person of ordinary
`
`skill in the art as of October 22, 1999, which I understand is the earliest date
`
`of the purported invention claimed in the ‘266 patent, over U.S. Patent No.
`
`6,226,677 (“Slemmer”) in view of U.S. Patent No. 6,389,462 (“Cohen”) under
`
`35 U.S.C. § 103.
`
`V.
`
`UNDERSTANDING OF LEGAL PRINCIPLES
`10.
`I am not a legal expert and offer no legal opinions. I have been
`
`informed by counsel, however, of the various legal standards that apply to the
`
`pertinent technical issues, and I have applied those standards in arriving at the
`
`conclusions expressed in this report. I understand that determining the
`
`validity of a patent requires a two-step analysis. First, the meaning and scope
`
`of the patent claims are construed and then the construed claims are compared
`
`to the prior art.
`
`11.
`
`It is my understanding that to prove that a claim is invalid for
`
`obviousness under 35 U.S.C. § 103, the challenger of its validity must
`
`demonstrate that, for example, two or more prior art references in combination
`
`disclose, expressly or inherently, every claim limitation and also that the
`
`claim, as a whole, would have been obvious to a person of ordinary skill in
`4
`
`
`
`
`
`the art at the time the invention was made. The relevant standard for
`
`obviousness is as follows:
`
`(a) A patent may not be obtained though the invention is not
`identically disclosed or described as set forth in section 102
`of this title, if the differences between the subject matter
`sought to be patented and the prior art are such that the subject
`matter as a whole would have been obvious at the time the
`invention was made to a person having ordinary skill in the
`art to which said subject matter pertains. Patentability shall
`not be negatived by the manner in which the invention was
`made.
`35 U.S.C. §103.
`
`12.
`
`In determining whether or not a patented invention would have
`
`been obvious, the following factual inquiries must be made: (1) the scope and
`
`content of the prior art; (2) the differences between the prior art and the claims
`
`at issue; (3) the level of ordinary skill in the pertinent art at the time the
`
`invention was made; and (4) such secondary considerations as commercial
`
`success, long felt but unsolved needs, failure of others, etc.
`
`13.
`
`I understand that a patent composed of several elements is not
`
`proved obvious merely by demonstrating that each of its elements was,
`
`independently, known in the prior art. Most, if not all, inventions rely on
`
`building blocks of prior art. The challenger of the patent’s validity must prove
`
`that, at the time of the claimed invention, there was a reason that would have
`
`prompted a person having ordinary skill in the field of the invention to
`5
`
`
`
`
`
`
`
`combine the known elements in a way the claimed invention does, taking into
`
`account such factors as: (1) whether the claimed invention was merely the
`
`predictable result of using prior art elements according to their known
`
`function(s); (2) whether the claimed invention provides an obvious solution
`
`to a known problem in the relevant field; (3) whether the prior art teaches or
`
`suggests the desirability of combining elements claimed in the invention; and
`
`(4) whether the change resulted more from design incentives or other market
`
`forces. To find it rendered the invention obvious, the prior art must have
`
`provided a reasonable expectation of success.
`
`14.
`
`I further understand that it is not permissible to use hindsight in
`
`assessing whether a claimed invention is obvious. Rather, I understand that,
`
`to assess obviousness, you must place yourself in the shoes of a person having
`
`ordinary skill in the relevant field of technology at the time the invention was
`
`made who is trying to address the issues or solve the problems faced by the
`
`inventor, consider only what was known at the time of the invention and
`
`ignore the knowledge you currently now have of the inventions.
`
`15.
`
`I understand that certain objective evidence known as “secondary
`
`considerations,” such as commercial success, long-felt but unsolved needs,
`
`failure of others, and unexpected results, to the extent they exist, may be
`
`6
`
`
`
`
`
`
`
`relevant in determining whether or not an invention would have been obvious.
`
`However, I am not aware of any such secondary considerations applicable
`
`with respect to claims 1 or 24 of the ’266 patent.
`
`VI. THE ‘266 PATENT
`16. The ‘266 patent describes systems and methods for redirecting
`
`client computers to different network content. Abstract. The user is said to
`
`be associated with a source computer, or client computer, which “has
`
`transparent access to the network via a gateway device.” Id. I have pasted
`
`Figure 1 of the ‘266 patent below. That Figure provides an overview of the
`
`alleged invention, illustrating how system 10 allows user computers 14 to
`
`access online service 22 and networks 22:
`
`7
`
`
`
`
`
`
`
`Figure 1 depicts access controller 16, which connects client computers 14 to
`
`a gateway device 12. 18:35-37. When a user tries to access a destination
`
`location, e.g., a webpage, the gateway device 12 receives the request and
`
`routes the packets send from the client computer to a protocol stack on a
`
`temporary server at the gateway device. The protocol stack pretends to be the
`
`user-entered destination location, temporarily adopting, for the duration of the
`
`user's connection, the IP address of the user-entered destination location, and
`
`completes a “handshake” with the client computer.
`
`17.
`
`If the user is not permitted to access the destination location, in
`
`accordance with rules embedded within system 10, the protocol stack will
`
`initiate a request for network content at a network location different from the
`
`original destination address. When a reply packet is sent back to the user
`
`computer, the destination address may be set to that of the user computer
`
`rather than the gateway device, and the source address can be set to the
`
`original destination address. As was standard at the time, the alleged
`
`invention can be implemented using Transport Control Protocol/Internet
`
`Protocol
`
`(TCP/IP), with minor modifications
`
`to support address
`
`masquerading as described in, for example, RFC 1919, section 4.1:
`
`“Transparent proxy connection example”, or the Cohen ’462 patent, and using
`
`8
`
`
`
`HTTP servers, which were the standard servers hosting web pages on the
`
`Internet at the time of the alleged invention.
`
`18. As mentioned, I have been asked to opine on the validity of
`
`claims 1 and 24 of the ‘266 patent. Claim 1 recites a “method of redirecting
`
`a session directed to an HTTP server to a redirected destination HTTP server.”
`
`Claim 24 recites most of the same limitations of claim 1, except claim 24 is in
`
`apparatus form, directed to “A network management system, configured to
`
`cause a user device to receive alternate content different from what was
`
`requested by the user device, the user device being connected to the network
`
`management system.”
`
`19.
`
`The full language of the claims is as follows, where the
`
`individual subparagraphs have been designated (1.a)-(1.e) and (24.a)-(24.d)
`
`for convenient reference:
`
`A method of redirecting a session directed to an HTTP server to a
`redirected destination HTTP server, the method comprising the
`steps of:
`
`(1.a) receiving, at a communications port of a network system, a
`request from a user device to open a TCP connection with a server
`located external to the network system;
`
`the network system, TCP connection
`(1.b) sending, from
`handshake completion data to the user device in response to the
`request to open the TCP connection, the handshake completion data
`being configured to appear to be from the server located external to
`
`9
`
`
`
`
`
`the network system, wherein the network system need not
`communicate with the server located external to the network
`system;
`
`(1.c) receiving, at the communications port of the network system,
`an HTTP server request for access to the server located external to
`the network system, the HTTP server request originating from the
`user device; and
`
`(1.d) generating response data customized for the HTTP server
`request, the response data including alternate content different from
`content requested by the HTTP server request, wherein the
`response data is customized for the HTTP server request at least in
`part by appearing to be from the server located external to the
`network system, wherein the response data appears to be from the
`server located external to the network system at least in part by
`including, in a header of the response data, a source address
`corresponding to the server located external to the network system;
`and
`
`(1.e) sending, from the network system, a response to the HTTP
`server request, the response configured to cause the user device to
`receive the alternate content, the response comprising the generated
`response data customized for the HTTP server request.
`
`24. A network management system, configured to cause a user device
`to receive alternate content different from what was requested by the
`user device, the user device being connected to the network
`management system, the system comprising:
`
`
`(24.a) a communications port configured to receive incoming data
`from the user device relating to accessing a first network location
`external to the network management system; and
`
`(24.b) a processor configured to complete a connection handshake
`with the user device while appearing to be the first network
`location, the connection handshake being completed in response to
`
`10
`
`
`
`
`
`
`
`the incoming data and without the need to communicate with the
`first network location;
`
`(24.c) the processor further configured to generate response data
`customized for the user device, the response data including
`alternate content different from content to be accessed at the first
`network location, wherein the response data is customized for the
`user device at least in part by appearing to be from the first network
`location, wherein the response data appears to be from the first
`network location at least in part by including a source address
`corresponding to the first network location in a header of the
`response data;
`
`(24.d) the processor further configured to send to the user device
`the generated response data including the alternate content.
`
`VII. PRIORITY DATE FOR CLAIMS 1 AND 24 OF THE ‘266
`PATENT
`20.
`I have been told and understand that, in order for the claims of a
`
`later-filed application to be entitled to the filing date of an earlier-filed
`
`application, the claims must have written description and enablement support
`
`in the earlier-filed application. My understanding is that 35 U.S.C. § 112 sets
`
`forth the written description and enablement requirements. As to written
`
`description, “[t]he specification shall contain a written description of the
`
`invention.” 35 U.S.C. § 112. I understand that the written description
`
`requirement is satisfied if a skilled artisan, reading the specification, would
`
`conclude that the inventor(s) had possession of the claimed invention. As to
`
`enablement, the specification must must describe “the manner and process of
`
`11
`
`
`
`
`
`
`
`making and using [the invention], in such full, clear, concise and exact terms
`
`as to enable any person skilled in the art to which it pertains, or with which it
`
`is most nearly connected, to make and use the same . . . .” Id. In other words,
`
`the specification must contain sufficient disclosure such that a skilled artisan
`
`could make and use the claimed invention without having to conduct undue
`
`experimentation.
`
`21.
`
`I have reviewed U.S. Provisional Application No. 60/111,497,
`
`which I’ll refer to as the ’497 provisional. That provisional application was
`
`filed December 8, 1998 and, as I understand, is the earliest application related
`
`to the ‘266 patent.
`
`22.
`
`In my opinion, claims 1 and 24 of the ‘266 patent are not entitled
`
`to the priority date of the ’497 provisional because the provisional does not
`
`contain written description and enablement support for the claims. For
`
`example, a skilled artisan like myself would not have believed that the
`
`purported inventors of the ‘266 patent had possession of the claimed invention
`
`as of the filing of the ’497 provisional. Although the provisional describes
`
`the functions of a router at a high-level, it does not disclose or suggest various
`
`limitations of claims 1 and 24, including completing a “connection
`
`handshake” with the user device while appearing to be the first network
`
`12
`
`
`
`
`
`
`
`location and response data that “appears to be from the first network location
`
`by at least including a source address” corresponding to the first network
`
`location in a header of the response data. There is no suggestion in the
`
`provisional application of any form of IP address modification, or any form
`
`of IP address masquerade, or any attempt by the gateway system to appear to
`
`the user computer to be the destination system. The provisional application
`
`does disclose that “the first time a subscriber accesses his residential network,
`
`the Nomadix solution has the ability to redirect that user to a sign-in page on
`
`his browser.” [pages 2-3]. However, the provisional application does not
`
`disclose a mechanism for this redirection. There is no suggestion whatsoever
`
`or requirement that this redirection involves any form of IP address
`
`masquerading.
`
`VIII. CLAIM CONSTRUCTION
`23.
`I understand that the terms of the unexpired ‘266 patent claims
`
`are to be given their broadest reasonable interpretation as understood by one
`
`of ordinary skill in the art at the time of the alleged invention in view of the
`
`‘266 patent’s specification. As such, in this declaration, I have opined on the
`
`validity of claims 1 and 24 using their broadest reasonable interpretation.
`
`24. The term “connection handshake” in claims 1 and 24, for
`
`instance, means an exchange of data whereby a communication session is
`13
`
`
`
`
`
`initiated as a result of a first device sending data to a second device, and the
`
`second device responding to the first device. This is consistent with the claim
`
`language and specification of the ‘266 patent. For example, claim 24 refers
`
`to “a connection handshake with the user device while appearing to be the
`
`first network location, the connection handshake being completed in response
`
`to the incoming data.” Claim 1 and the specification also refer to conducting
`
`handshakes in connection with TCP connections (e.g., col. 33, line 56-60). As
`
`was well known at the time of the alleged invention (see, for example, RFC
`
`793), a TCP connection is established between a client and server by the client
`
`sending a SYN packet to the server, the server responding with a SYN + ACK
`
`packet, and then the client sending an ACK packet. (I explain these TCP-
`
`related terms in more detail below.) Particularly with respect to the “TCP”
`
`connection handshake recited in claim 1, the handshake in the claims would
`
`be understood as the TCP three-way handshake described in RFC 793, which
`
`I discuss below in paragraphs 39, 56, 95 and other places.
`
`IX. LEVEL OF ORDINARY SKILL IN THE ART
`25.
`I understand there is a concept in patent law known as the
`
`“person having ordinary skill in the art.” I understand that this concept refers
`
`to a person who is trained in the relevant technical field of a patent without
`
`possessing extraordinary or otherwise exceptional skill. I further understand
`14
`
`
`
`
`
`that factors such as the educational level of those working in the field, the
`
`sophistication of the technology, the types of problems encountered in the art,
`
`prior art solutions to those problems, and the speed at which innovations are
`
`made may help establish the level of skill in the art.
`
`26.
`
`In my opinion, the field of the ‘266 patent is systems and
`
`methods for providing computer access to a network using a gateway device.
`
`Based on the factors mentioned above, a person of ordinary skill in the art of
`
`the ‘266 patent as of October 22, 1999 would have had (1) either a formal
`
`degree in computer science or a related subject, or commensurate informal
`
`education in computer programming and designing computer networks, and
`
`(2) at least 2 years of experience in designing or programmng computer
`
`networks.
`
`27. Based at least on my educational and work experience referenced
`
`above and in my attached curriculum vitae, it is my opinion that I qualify as
`
`a person of ordinary skill in the art now, and would have qualified as one at
`
`least as of October 22, 1999. Again, I have advanced degrees in mathematics,
`
`a subject directly related to computer programming. In fact, many practicing
`
`computer scientists in the 1990s had mathematics degrees (rather than
`
`computer science degrees), as the algorithms and problem solving processes
`
`15
`
`
`
`
`
`
`
`used in computer programming originated in mathematics. (Many computer
`
`scientists in the 1990s did not have any formal degrees at all, and were self
`
`taught through informal study and research.) In addition, I have informal
`
`education commensurate to a formal computer science degee from over 35
`
`years of studying and teaching computer programming and designing
`
`computer networks, with well over 25 years of cumulative hands-on
`
`experience designing and programming computer networks through my
`
`research and work at Loyola University.
`
`X. TECHNICAL BACKGROUND AND STATE OF THE ART AT
`TIME OF ALLEGED INVENTION
`28. As mentioned, the ‘266 patent involves transmitting requests for
`
`Internet data, such as webpages, in the form of data packets from client
`
`computers that are intercepted by transparent proxies. I will give an overview
`
`of these concepts as known as of October 22, 1999.
`
`Basics of Network Communications and Protocols
`
`29. Computers on a network communicate by sending what is
`
`referred to as data “packets” to each other. A packet is a string of data
`
`transmitted over a network, such as an Intranet or Internet. Packets are
`
`composed of headers, which include control information, and bodies, which
`
`contain the payload or actual content of the transmission (such as a request for
`
`16
`
`
`
`
`
`
`
`Internet data or the requested data sent in response).
`
`30. The information contained in a packet depends on the protocol
`
`used. The set of protocols used for sending information over the Internet and
`
`related networks is referred to as the Internet Protocol suite. It involves four
`
`main layers: the application layer, transport layer, Internet layer, and link
`
`layer. The link layer contains the networking scope of the local network
`
`connection that the host computer is attached to. The Internet layer defines
`
`the addressing and routing sructures of the packets. All devices operating on
`
`the Internet use Internet Protocol (IP) as the standard application layer
`
`protocol.
`
`31. The
`
`transport
`
`layer
`
`is
`
`the
`
`layer used
`
`for providing
`
`communication channels for client and server computers to exchange data
`
`over a network. Message transmission at the transport layer can be
`
`categorized as either connection-oriented, implemented in Transmission
`
`Control Protocol (TCP), or connectionless, implemented in User Datagram
`
`Protocol (UDP). The primary benefit of using TCP, whereby connections are
`
`established between client and server computers, is reliability. Unlike UDP,
`
`which is connectionless, TCP provides packet flow control and reliable data
`
`transmission.
`
`
`
`17
`
`
`
`
`
`32. The application
`
`layer comprises
`
`the protocols used for
`
`exchanging application data over the network. Examples include the
`
`Hypertext Transfer Protocol (HTTP) typically used for Internet data and File
`
`Transfer Protocol (FTP). Application layer protocols are often associated
`
`with particular well-known port numbers reserved by the Internet Assigned
`
`Numbers Authority (IANA). The HyperText Transfer Protocol, for example,
`
`uses a server’s Port 80. See IANA, Service Name and Transport Protocol Port
`
`Number Registry, at https://www.iana.org/assignments/service-names-port-
`
`numbers/service-names-port-numbers.xhtml?&page=2; see also RFC 1340
`
`(1992), which can be found at https://tools.ietf.org/html/rfc1340.
`
`33. An example of the control information in a header of a TCP
`
`packet arriving at a destination computer on the Internet is shown in the
`
`following table (which I adapted from U.S. Patent No. 6,389,462, Table 1):
`
`Arriving packet
`
`beginning of packet header dump <---
`--->
`IP header: version=4 hdr_len=5 TOS=0 pkt_len=346 id=60276
`--->
` frag_off=4000H TTL=64 protocol=6 cksum=1792H
` saddr=135.104.25.243 daddr=204.71.200.244
`TCP header: sport=1273 dport=80 seq=2189084427 ack_seq=3266449517
`--->
`tcp_hdr_len=5 flags=ACK PSH res1=0H
`
`res2=0H window=31856 cksum=162H urgent=0
`
`
`
`As shown, the IP headers include information such as the source (saddr) and
`
`destination (daddr) addresses of the client and server computers on the
`
`18
`
`
`
`
`
`network that are sending and intended to receive the packets. Those addresses
`
`are used by the receiving computers and routers to make sure the packets are
`
`being sent to and from the correct network locations. The TCP header of the
`
`same exemplary packet includes an “ACK” flag, acknowledging receipt of a
`
`prior packet.
`
`HyperText Transfer Protocol
`
`34. As mentioned, HyperText Transfer Protocol (HTTP) is a
`
`standard protocol used in the application layer of the IP suite. It is basically
`
`the foundational protocol for requesting and receiving data for the World
`
`Wide Web. HTTP defines how messages are formatted and transmitted, and
`
`what actions Internet servers and browsers should take in response to various
`
`commands.
`
`35. HTTP development was initiated in the late 1980s, and has been
`
`described in specifications published by the Internet Engineering Task Force
`
`(IETF). The IETF is an open standards organization that develops and
`
`promotes voluntary Internet standards, including the standards that comprise
`
`the Internet Protocol suite (TCP/IP). RFC 1945, which was published in May
`
`1996, is one of the IETF standards that defined HTTP. Exhibit 1011, which I
`
`understand is being submitted in connection with the present request for inter
`
`19
`
`
`
`
`
`partes review, is a copy of RFC 1945 that I retrieved from IETF’s website
`
`(https://tools.ietf.org/html/rfc1945), which stores and indexes copies of its
`
`standards.
`
`36.
`
`In terms of HTTP terminology, messages sent from browsers on
`
`client computers for content from websites are referred to as “requests,” and
`
`the messages containing the content sent in response to the requests from the
`
`web server hosting the site are referred to as “responses.” The format and
`
`commands used in HTTP requests and responses are described in sections 5
`
`and 6 of RFC 1945. Section 8 describes the different commands, or
`
`“methods,” that may be included in standard requests. One of those methods
`
`is the ‘GET’ method. That method is (and was in the 1990s) the basic method
`
`used to request content from a webpage. As explained in section 8 of RFC
`
`1945, when a ‘GET’ method is specified in the HTTP request, the request will
`
`retrieve the webpage or whatever other information is identified by the
`
`request.
`
`37. As of the mid-1990s (and today), the standard and default TCP
`
`port used to transmit HTTP messages was port 80. See, e.g., RFC 1945 at 8
`
`(“On the Internet, HTTP communication generally takes place over TCP/IP
`
`connections. The default port is TCP 80.”); RFC 1340. As RFC 1945
`
`20
`
`
`
`
`
`
`
`explains:
`
`The most common form of Request-URI is that used to identify
`a resource on an origin server or gateway. In this case, only the
`absolute path of the URI is transmitted . . . . For example, a client
`wishing to retrieve the resource above directly from the origin
`server would create a TCP connection to port 80 of the host
`"www.w3.org"
`and
`send
`the
`line:
`GET
`/pub/WWW/TheProject.html HTTP/1.0.
`
`RFC 1945 at 24-25.
`
`TCP Protocol and Establishing Connections
`
`38. Most major Internet-based applications, such as the World Wide
`
`Web, rely on TCP as the standard protocol for exchanging data. TCP was first
`
`developed in the 1970s. RFC 793, which was published in September 1981,
`
`is the IETF standard that defines TCP. Exhibit 1006, which I understand is
`
`being submitted in connection with the present request for inter partes review,
`
`is a copy of RFC 793
`
`that
`
`I
`
`retrieved
`
`from
`
`IETF’s website
`
`(https://tools.ietf.org/html/rfc793), which stores and indexes copies of its
`
`standards.
`
`39.
`
`In contrast to UDP, use of TCP has always required establishing
`
`a connection between two computers on the network before the computers can
`
`exchange data. The process for establishing a connection for devices using
`
`TCP is set forth in the TCP standard. Specifically, section 2.7 of RFC 793
`
`21
`
`
`
`
`
`
`
`explains that, with respect to TCP, the “procedures to establish connections
`
`utilize the synchronize (SYN) control flag and involves an exchange of three
`
`messages. This exchange has been termed a three-way hand shake.” It
`
`explains and illustrates the handshake using the following diagram, where A
`
`and B represent the two devices establishing a TCP connection:
`
`1) A --> B SYN my sequence number is X
`2) A <-- B ACK your sequence number is X
`3) A <-- B SYN my sequence number is Y
`4) A --> B ACK your sequence number is Y
`
`RFC 793 at 27-28. As explained in RFC 793, “[b]ecause steps 2 and 3 can be
`
`combined in a single message this is called the three way (or three message)
`
`handshake.” Id. at 28. The three messages include a first packet sent from
`
`client A with a SYN flag in the TCP header, a second packet from server B
`
`with ACK and SYN flags responding to that first packet, and a
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
