`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`______________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`______________________
`
`
`DELL INC.
`Petitioner
`
`v.
`
`ALACRITECH, INC.
`Patent Owner
`
`________________________
`
`Case IPR. No. 2018-00372
`U.S. Patent No. 7,337,241
`Title: FAST-PATH APPARATUS FOR RECEIVING DATA CORRESPONDING
`TO A TCP CONNECTION
`________________________
`
`
`Declaration of Robert Horst, Ph.D. in Support of
`Petition for Inter Partes Review
`of U.S. Patent No. 7,337,241
`
`
`
`
`
`DELL Ex.1003.001
`
`

`

`
`
`I.
`
`II.
`
`III.
`
`IV.
`
`V.
`
`Petition for Inter Partes Review of 7,337,241
`Ex. 1003 (“Horst Decl.”)
`
`TABLE OF CONTENTS
`
`
`
`Page(s)
`
`INTRODUCTION AND QUALIFICATIONS .......................................... 4
`
`MATERIALS RELIED ON IN FORMING MY OPINION ..................... 7
`
`UNDERSTANDING OF THE GOVERNING LAW ................................ 7
`
`A.
`
`B.
`
`Invalidity by Anticipation ..................................................................... 8
`
`Invalidity by Obviousness ..................................................................... 8
`
`LEVEL OF ORDINARY SKILL IN THE ART ......................................11
`
`STATE OF THE ART AND OVERVIEW OF TECHNOLOGY
`AT ISSUE .................................................................................................12
`
`A.
`
`Layered Network Protocols .................................................................12
`
`1.
`
`2.
`
`OSI Layers ................................................................................12
`
`TCP/IP Layers ...........................................................................13
`
`B.
`
`TCP/IP .................................................................................................15
`
`1.
`
`2.
`
`3.
`
`4.
`
`5.
`
`6.
`
`7.
`
`8.
`
`9.
`
`Encapsulation ............................................................................17
`
`Ethernet Header .........................................................................19
`
`IP Header ...................................................................................20
`
`TCP Header ...............................................................................21
`
`Application Data .......................................................................26
`
`RFC 793 – TCP Specification...................................................26
`
`Sockets ......................................................................................27
`
`Prepending Headers ..................................................................29
`
`Advertising a Receive Window ................................................31
`
`10.
`
`Segmentation .............................................................................32
`
`C.
`
`Protocol Offload and Fast-Path Processing.........................................34
`
`1.
`
`2.
`
`RFC 647 – Front-Ending ..........................................................34
`
`RFC 929 – Outboard Processing ..............................................35
`
`3. Mediation Levels.......................................................................37
`
`D. Offloaded Protocols .............................................................................40
`
`
`
`
`
`DELL Ex.1003.002
`
`

`

`Petition for Inter Partes Review of 7,337,241
`Ex. 1003 (“Horst Decl.”)
`
`OSI Protocol Offload ................................................................40
`
`TCP/IP Protocol Offload ...........................................................40
`
`VMTP and XTP Protocol Offload ............................................41
`
`1.
`
`2.
`
`3.
`
`4. Multi-Protocol Offload .............................................................41
`
`E.
`
`Portions of the Protocol Offloaded .....................................................42
`
`1.
`
`2.
`
`Checksum Offload ....................................................................42
`
`Full Offload ...............................................................................43
`
`3. Multi-Level Offload ..................................................................43
`
`4.
`
`Header Prediction ......................................................................44
`
`F.
`
`Offload Implementation ......................................................................47
`
`1.
`
`2.
`
`Offload Adapters based on Microprocessors ............................48
`
`Offload Adapters based on Custom Processors or Custom
`Logic .........................................................................................50
`
`G.
`
`Protocol Offload Summary .................................................................53
`
`H. Additional Background Technology ...................................................53
`
`1.
`
`2.
`
`3.
`
`DMA .........................................................................................54
`
`Virtual and Physical Memory Addresses..................................56
`
`Sequencers ................................................................................59
`
`VI.
`
`VII.
`
`OVERVIEW OF 241 PATENT ...............................................................60
`
`241 PATENT PROSECUTION HISTORY .............................................63
`
`VIII.
`
`CLAIM CONSTRUCTIONS ...................................................................64
`
`A.
`
`B.
`
`C.
`
`Legal Standard .....................................................................................64
`
`“[first/second] mechanism” .................................................................64
`
`“without an interrupt dividing” ...........................................................67
`
`IX.
`
`THE PRIOR ART .....................................................................................68
`
`A. U.S. Patent No. 5,768,618 (“Erickson”) .............................................68
`
`B.
`
`Tanenbaum96: A. Tanenbaum, Computer Networks,
`3rd ed. (1996) ......................................................................................82
`
`
`
`ii
`
`DELL Ex.1003.003
`
`

`

`Petition for Inter Partes Review of 7,337,241
`Ex. 1003 (“Horst Decl.”)
`
`
`C.
`
`“Gigabit Ethernet Technical Brief: Achieving End-to-
`End Performance” by Alteon Networks (Ex. 1033,
`“Alteon”) .............................................................................................94
`
`X.
`
`Obviousness Combinations – Motivations To Combine .........................96
`
`A. Motivations To Combine Erickson and Tanenbaum96 ......................96
`
`B. Motivations to Combine Erickson, Tanenbaum96, and
`Alteon ................................................................................................100
`
`GROUNDS OF INVALIDITY ..............................................................103
`
`XI.
`
`
`
`
`
`iii
`
`DELL Ex.1003.004
`
`

`

`Petition for Inter Partes Review of 7,337,241
`Ex. 1003 (“Horst Decl.”)
`
`
`I, Robert Horst, hereby declare as follows:
`
`I.
`
`INTRODUCTION AND QUALIFICATIONS
`
`1. My name is Robert Horst. I have been retained on behalf of Petitioner
`
`Dell Inc. (“Dell”) to provide this Declaration concerning technical subject matter
`
`relevant to the petition for inter partes review (“Petition”) concerning U.S. Patent
`
`No. 7,337,241 (Ex.1001, the “241 Patent”). I previously offered a substantially
`
`identical declaration in connection with Case Nos. IPR2017-01392 (for Intel
`
`Corporation), IPR2017-01728 (for Cavium, Inc.), and IPR2018-00328 (for Wistron
`
`Corporation). I reserve the right to supplement this Declaration in response to
`
`additional evidence that may come to light.
`
`2.
`
`I am over 18 years of age. I have personal knowledge of the facts
`
`stated in this Declaration and could testify competently to them if asked to do so.
`
`3. My compensation is not based on the resolution of this matter. My
`
`findings are based on my education, experience, and background in the fields
`
`discussed below.
`
`4.
`
`I am an independent consultant with more than 30 years of expertise
`
`in the design and architecture of computer systems. My current curriculum vitae is
`
`submitted as Exhibit 1004 and some highlights follow.
`
`5.
`
`Currently, I am an independent consultant at HT Consulting where my
`
`work includes consulting on technology and intellectual property. I have testified
`
`4
`
`
`
`
`
`DELL Ex.1003.005
`
`

`

`Petition for Inter Partes Review of 7,337,241
`Ex. 1003 (“Horst Decl.”)
`
`
`
`
`
`as an expert witness and consultant in patent and intellectual property litigation as
`
`well as inter partes reviews and re-examination proceedings.
`
`6.
`
`I earned my M.S. (1978) in electrical engineering and Ph.D. (1991) in
`
`computer science from the University of Illinois at Urbana-Champaign after
`
`earning my B.S. (1975) in electrical engineering from Bradley University. During
`
`my master’s program, I designed, constructed and debugged a shared memory
`
`parallel microprocessor system. During my doctoral program, I designed and
`
`simulated a massively parallel, multi-threaded task flow computer.
`
`7.
`
`After receiving my bachelor’s degree and while pursuing my master’s
`
`degree, I worked for Hewlett-Packard Co. While at Hewlett-Packard, I designed
`
`the micro-sequencer and cache of the HP3000 Series 64 processor. From 1980 to
`
`1999, I worked at Tandem Computers, which was acquired by Compaq Computers
`
`in 1997. While at Tandem, I was a designer and architect of several generations of
`
`fault-tolerant computer systems and was the principal architect of the NonStop
`
`Cyclone superscalar processor. The system development work at Tandem also
`
`included development of the ServerNet System Area Network and applications of
`
`this network to fault tolerant systems and clusters of database servers.
`
`
`
`
`
`5
`
`DELL Ex.1003.006
`
`

`

`Petition for Inter Partes Review of 7,337,241
`Ex. 1003 (“Horst Decl.”)
`
`
`
`
`
`
`8.
`
`Since leaving Compaq in 1999, I have worked with several
`
`technology companies, including 3Ware, Network Appliance, Tibion, and AlterG
`
`in the areas of network-attached storage and biomedical devices. From 2012 to
`
`2015, I was Chief Technology Officer of Robotics at AlterG, Inc., where I worked
`
`on the design of anti-gravity treadmills and battery-powered orthotic devices to
`
`assist those with impaired mobility.
`
`9.
`
`In 2001, I was elected an IEEE Fellow “for contributions to the
`
`architecture and design of fault tolerant systems and networks.” I have authored
`
`over 30 publications, have worked with patent attorneys on numerous patent
`
`applications, and I am a named inventor on 80 issued U.S. patents.
`
`10. My patents include those directed to networks (e.g., U.S. Pat. No.
`
`6,157,967: Method of data communication flow control in a data processing
`
`system using busy/ready commands), storage (e.g., U.S. Pat. No. 6,549,977: Use of
`
`deferred write completion interrupts to increase the performance of disk
`
`operations), and multi-processor systems (e.g., U.S. Pat. No. 5,751,932: Fail-fast,
`
`fail-functional, fault-tolerant multiprocessor system). My publications include a
`
`conference paper that examined the performance and efficacy of protocol offload
`
`engines. (Ex.1004).
`
`
`
`
`
`6
`
`DELL Ex.1003.007
`
`

`

`Petition for Inter Partes Review of 7,337,241
`Ex. 1003 (“Horst Decl.”)
`
`
`
`
`
`
`11. My Curriculum Vitae, which is filed as a separate Exhibit (Ex.1004),
`
`contains further details on my education, experience, publications, and other
`
`qualifications to render this opinion as expert.
`
`II. MATERIALS RELIED ON IN FORMING MY OPINION
`
`12.
`
`In addition to reviewing U.S. Patent No. 7,337,241 (Ex.1001), I also
`
`reviewed and considered the prosecution history of the 241 Patent (Ex.1002). I
`
`also reviewed U.S. Pat. No. 5,768,618, to Erickson, titled “Method for Performing
`
`Sequence of Actions in Device Connected to Computer in Response to Specified
`
`Values Being Written Into Snooped Sub Portions of Address Space,” filed on Dec.
`
`21, 1995 and issued on June 16, 1998 (Ex.1005, “Erickson”), A. Tanenbaum, 3rd
`
`ed. (1996) (Ex.1006, “Tanenbaum96”), and “Gigabit Ethernet Technical Brief:
`
`Achieving End-to-End Performance” by Alteon Networks (Ex.1033, “Alteon”). I
`
`also considered the background materials cited herein.
`
`III. UNDERSTANDING OF THE GOVERNING LAW
`
`13.
`
`I understand that a patent claim is invalid if it is anticipated or
`
`rendered obvious in view of the prior art. I further understand that invalidity of a
`
`patent claim requires that the claim be anticipated or obvious from the perspective
`
`of a person of ordinary skill in the relevant art at the time the invention was made.
`
`
`
`
`
`7
`
`DELL Ex.1003.008
`
`

`

`Petition for Inter Partes Review of 7,337,241
`Ex. 1003 (“Horst Decl.”)
`
`
`
`
`
`
`A.
`
`Invalidity by Anticipation
`
`14.
`
`I have been informed that a patent claim is invalid as anticipated
`
`under 35 U.S.C. § 102 if each and every element of a claim, as properly construed,
`
`is found either explicitly or inherently in a single prior art reference.
`
`15.
`
`I have been informed that a claim is invalid under 35 U.S.C. § 102(a)
`
`if the claimed invention was patented or published anywhere, before the applicant's
`
`invention. I further have been informed that a claim is invalid under 35 U.S.C. §
`
`102(b) if the invention was patented or published anywhere more than one year
`
`prior to the first effective filing date of the patent application (critical date). I
`
`further have been informed that a claim is invalid under 35 U.S.C. § 102(e) if an
`
`invention described by that claim was disclosed in a U.S. patent granted on an
`
`application for a patent by another that was filed in the U.S. before the date of
`
`invention for such a claim.
`
`B.
`
`Invalidity by Obviousness
`
`16.
`
`I have been informed that a patent claim is invalid as obvious under
`
`35 U.S.C. § 103 if it would have been obvious to a person of ordinary skill in the
`
`art, taking into account (1) the scope and content of the prior art, (2) the differences
`
`between the prior art and the claims, (3) the level of ordinary skill in the art, and
`
`(4) any so called “secondary considerations” of non-obviousness, which include:
`8
`
`
`
`
`
`DELL Ex.1003.009
`
`

`

`Petition for Inter Partes Review of 7,337,241
`Ex. 1003 (“Horst Decl.”)
`
`
`
`
`
`(i) “long felt need” for the claimed invention, (ii) commercial success attributable
`
`to the claimed invention, (iii) unexpected results of the claimed invention, and (iv)
`
`“copying” of the claimed invention by others. I further understand that it is
`
`improper to rely on hindsight in making the obviousness determination. I have
`
`been informed that Alacritech claims a filing priority date no later than October 14,
`
`1997 for all claims of the 241 Patent. Accordingly, my analysis of the prior art for
`
`the claims of the 241 Patent is based on the prior art and knowledge of a person
`
`having ordinary skill in the art (“POSA”) as of October 14, 1997.
`
`17.
`
`I have been informed that a claim can be obvious in light of a single
`
`prior art reference or multiple prior art references. I further understand that
`
`exemplary rationales that may support a conclusion of obviousness include:
`
`(A) Combining prior art elements according to known
`
`methods to yield predictable results;
`
`(B) Simple substitution of one known element for
`
`another to obtain predictable results;
`
`(C) Use of known technique to improve similar devices
`
`(methods, or products) in the same way;
`
`
`
`
`
`9
`
`DELL Ex.1003.010
`
`

`

`Petition for Inter Partes Review of 7,337,241
`Ex. 1003 (“Horst Decl.”)
`
`
`(D) Applying a known technique to a known device
`
`(method, or product) ready for improvement to yield
`
`predictable results;
`
`(E) “Obvious to try” - choosing from a finite number of
`
`identified, predictable solutions, with a reasonable
`
`expectation of success;
`
`(F) Known work in one field of endeavor may prompt
`
`variations of it for use in either the same field or a
`
`different one based on design incentives or other market
`
`forces if the variations are predictable to one of ordinary
`
`skill in the art;
`
`(G) Some teaching, suggestion, or motivation in the prior
`
`art that would have led one of ordinary skill to modify
`
`the prior art reference or to combine prior art reference
`
`teachings to arrive at the claimed invention.
`
`10
`
`
`
`
`
`
`
`
`
`DELL Ex.1003.011
`
`

`

`Petition for Inter Partes Review of 7,337,241
`Ex. 1003 (“Horst Decl.”)
`
`
`
`
`
`IV. LEVEL OF ORDINARY SKILL IN THE ART
`
`18.
`
`I have been informed that factors that may be considered in
`
`determining the level of ordinary skill in the art may include: (A) “type of
`
`problems encountered in the art;” (B) “prior art solutions to those problems;” (C)
`
`“rapidity with which
`
`innovations are made;” (D) “sophistication of
`
`the
`
`technology;” and (E) “educational level of active workers in the field.” I also
`
`understand that, every factor may not be present for a given case, and one or more
`
`factors may predominate. Here, the 241 Patent is directed to an apparatus and
`
`methods for send and receive side network protocol offload. In my experience,
`
`systems such as those capable of protocol offload are not designed by a single
`
`person but instead require a design team with wide ranging skills and experience
`
`including computer architecture, network design, software development and
`
`hardware development. Moreover, the design team typically would have
`
`comprised individuals with advanced degrees and some industry experience, or
`
`significant industry experience.
`
`19. Accordingly, and while it would be rare to find all of these skills in a
`
`single individual, it is my opinion that a person of ordinary skill in the art
`
`(“POSA”) is a person with at least the equivalent of a B.S. degree in computer
`
`11
`
`
`
`
`
`DELL Ex.1003.012
`
`

`

`Petition for Inter Partes Review of 7,337,241
`Ex. 1003 (“Horst Decl.”)
`
`
`
`
`
`science, computer engineering or electrical engineering with at least five years of
`
`industry experience including experience in computer architecture, network design,
`
`network protocols, software development, and hardware development.
`
`20. The statements that I make in this declaration when I refer to a POSA
`
`are from the perspective of October 14, 1997.
`
`V.
`
`STATE OF THE ART AND OVERVIEW OF TECHNOLOGY AT
`ISSUE
`
`21.
`
`In this section, I provide an overview of the technology at issue and
`
`illustrate the state of the art.
`
`A. Layered Network Protocols
`
`22. The primary goal of computer networking is to provide fast, reliable
`
`data communications between computer systems. Interoperability has been
`
`accomplished through adherence to standards, and performance has steadily
`
`increased through new technology and optimizations of hardware and software.
`
`1. OSI Layers
`
`23. Computer networking standards provide inter-system communications
`
`across a wide range of hardware and software implementations. The seven-layer
`
`OSI model describes a logical layering including physical, data link, network,
`
`transport, session, presentation and application as illustrated below.
`
`
`
`
`
`12
`
`DELL Ex.1003.013
`
`

`

`Petition for Inter Partes Review of 7,337,241
`Ex. 1003 (“Horst Decl.”)
`
`
`
`
`
`
`2.
`
`TCP/IP Layers
`
`24. The TCP/IP layering is slightly different and corresponds more
`
`closely to the way the networking code is typically partitioned in some popular
`
`Unix variants. TCP/IP layers include physical (e.g. 100baseT, 1000baseT), data
`
`link1 (e.g. IEEE 802 Ethernet, ATM, Token Ring), Internet (e.g. IPv4, IPv6),
`
`transport (e.g. TCP, UDP, VMTP, XTP), and Application (e.g. FTP, SMTP,
`
`Telnet, HTTP). A network interface connected to a TCP/IP network receives
`
`TCP/IP packets that comply with the TCP/IP protocol. The following figure shows
`
`the relationship between the OSI and TCP/IP layering.
`
`
`1 References on TCP/IP use different terminology to describe the layer under IP
`
`layer. The data link layer is also called the “host-to-network layer” in
`
`Tanenbaum96 (Ex.1006) and the “interface layer” in Stevens2 (Ex.1013) (see
`
`below for description of these references). Some Alacritech patents use “data link
`
`layer,” “link layer” and “MAC layer.” Prior art references use many of these terms
`
`and also sometimes use the name of a specific implementation (e.g. Ethernet,
`
`ATM).
`
`
`
`
`
`13
`
`DELL Ex.1003.014
`
`

`

`Petition for Inter Partes Review of 7,337,241
`Ex. 1003 (“Horst Decl.”)
`
`
`
`
`
`
`
`
`Available at http://mitigationlog.com/how-tcpip-and-reference-osi-model-works/2
`
`25. An application layer is above the transport layer in both protocols.
`
`26. At a conceptual level, each layer is responsible only for its respective
`
`functions. This enables, for example, hiding the complexity of the physical data
`
`connection (that is, actually transmitting the data onto the physical wires) from
`
`layers above the physical, data link, and network layers above. Likewise, the
`
`lower layers must transmit the data on the physical wires, but need not worry about
`
`
`2 It appears that this diagram was made in 2012. It is being used for illustrative
`
`purposes only.
`
`
`
`
`
`14
`
`DELL Ex.1003.015
`
`

`

`Petition for Inter Partes Review of 7,337,241
`Ex. 1003 (“Horst Decl.”)
`
`
`
`
`
`what application the data belongs to or even whether it is receiving packets in the
`
`correct order.
`
`B.
`
`TCP/IP
`
`27. By the mid 1990s, TCP/IP was a firmly entrenched standard and was
`
`a widespread networking protocol to, for example, access the Internet and World
`
`Wide Web, overtaking the OSI protocols. See Ex.1006, Tanenbaum96 at .016
`
`(“The OSI protocols have quietly vanished, and the TCP/IP protocol suite has
`
`become dominant.”) By that time, detailed descriptions of the protocols and open-
`
`source implementations were widely available from books, technical papers, and
`
`code repositories. Free implementations of TCP/IP, such as Free BSD, were
`
`widely available and widely used. Standard reference books on TCP/IP included
`
`Stevens1 (Ex.1008), Stevens2 (Ex.1013), and Tanenbaum96 (Ex.1006), all of
`
`which were widely cited and relied upon.3 A series of technical memos called
`
`RFCs (request for comments) document the progression of design concepts of the
`
`Internet. TCP/IP was standardized in a series of publically available Request for
`
`
`3 These books were well known resources to a POSA. Consistent with that,
`
`Alacritech patents cite editions of the Tanenbaum and Stevens books.
`
`
`
`
`
`15
`
`DELL Ex.1003.016
`
`

`

`Petition for Inter Partes Review of 7,337,241
`Ex. 1003 (“Horst Decl.”)
`
`
`
`
`
`Comments (RFCs) published by the Internet Engineering Task Force, including
`
`RFC 793, entitled “Transmission Control Protocol” and RFC 791, entitled
`
`“Internet Protocol.” Ex.1007, RFC 793; Ex.1036, RFC 791. A few of the key
`
`RFCs are quoted below to establish when certain concepts were proposed and
`
`documented.
`
`28. TCP/IP consists of two parts: (1) Transmission Control Protocol
`
`(TCP), which provides virtual bi-directional connections that are guaranteed in-
`
`order, error-free delivery of arbitrary amounts of data between programs running
`
`on different computers over the Internet; and (2) Internet Protocol (IP), which
`
`provides delivery of datagrams (IP packets) to any routable Internet address,
`
`without any reliability or ordering guarantees. IP also provides for fragmentation
`
`during transmission and reassembly when received. Fragmentation occurs when an
`
`IP packet must be divided (“fragmented”) into smaller packets when a packet
`
`travels over an intermediate network with a small packet size. TCP network
`
`interface includes the ability to receive multiple TCP packets for the same
`
`connection. TCP/IP can be transmitted over a variety of physical media (e.g.
`
`Ethernet).
`
`
`
`
`
`16
`
`DELL Ex.1003.017
`
`

`

`Petition for Inter Partes Review of 7,337,241
`Ex. 1003 (“Horst Decl.”)
`
`
`
`
`
`
`1.
`
`Encapsulation
`
`29. Network layering corresponds to the encapsulation of higher levels by
`
`lower levels. TCP runs on “top” of IP by first dividing application data to be
`
`transmitted into segments that become the data payloads of TCP packets and
`
`concatenating each payload with a TCP header to form a TCP packet, a process
`
`called TCP segmentation. TCP/IP then places the resulting TCP packet (TCP
`
`header + payload) into the data payload of an IP packet by concatenating the TCP
`
`packet (IP data payload) with an IP header. The TCP packet is thus “encapsulated”
`
`in an IP packet.
`
`30. The following figure shows an example with application data
`
`accompanied by an application header. As shown in the figure below, in typical
`
`TCP/IP processing, the packet is built from the top down, i.e., each layer
`
`encapsulates what it receives from the above layer by concatenating an additional
`
`header associated with that layer. The application header-data combination
`
`becomes the application data of a TCP segment. The TCP segment containing the
`
`application header-data combination along with the IP header forms an IP
`
`datagram. The IP datagram along with an appropriate MAC (media access control)
`
`layer header forms the frame that is sent over the physical interconnect. The
`
`
`
`
`
`17
`
`DELL Ex.1003.018
`
`

`

`Petition for Inter Partes Review of 7,337,241
`Ex. 1003 (“Horst Decl.”)
`
`
`
`
`
`diagram below shows an example of such encapsulation where the MAC layer is
`
`Ethernet. Some software implementations implement the layers separately with
`
`data, or pointers to data, passed between the software modules for each layer. In
`
`this case, one module creates the user data and application header, another module
`
`then encapsulates that with a TCP header, etc. The processing occurs sequentially,
`
`from top to bottom, as shown below.
`
`
`Ex.1008, Stevens1 at .034, Fig. 1.7. When receiving a packet from the network,
`
`the layers work in reverse, with each layer stripping its header and providing the
`
`
`
`
`
`18
`
`DELL Ex.1003.019
`
`

`

`Petition for Inter Partes Review of 7,337,241
`Ex. 1003 (“Horst Decl.”)
`
`
`
`
`
`resulting packet to the above layer. The user data without headers is eventually
`
`delivered to the relevant application.
`
`2.
`
`Ethernet Header
`
`31. The lowest layer, the MAC (media access control) layer handles the
`
`actual transmission on the physical media. A 14-byte Ethernet header, for
`
`example, includes 48-bit (6 byte) source and destination MAC addresses for
`
`uniquely identifying the network interface (e.g., on a computer or router) on a local
`
`area network at each end of the link.
`
`Ex.1013, Stevens2 at .125, Fig. 4.8.
`
`
`
`32.
`
` The MAC address can be determined by a routing table in the
`
`protocol stack. In an Ethernet-based network, the 48-bit MAC address corresponds
`
`to a physical interface, such as a network interface card (NIC) or WiFi modem in a
`
`server or router. The MAC address field of the destination in the Ethernet header
`
`determines the next hop along the route to the destination. At each router along the
`
`
`
`
`
`19
`
`DELL Ex.1003.020
`
`

`

`Petition for Inter Partes Review of 7,337,241
`Ex. 1003 (“Horst Decl.”)
`
`
`
`
`
`path, the MAC address field is changed to the MAC address of the next router. The
`
`final router changes the MAC address field to the MAC address of the destination.
`
`3.
`
`IP Header
`
`Ex.1008, Stevens1 at .058, Fig. 3.1.
`
`
`
`33. Above the MAC layer is the Internet protocol layer (IP layer). An IP
`
`header is illustrated by the figure above from Stevens1. The IP header includes
`
`source and destination IP addresses for identifying the end points (e.g., computer)
`
`of the connection. The IP header also has a flag that indicates whether the packet
`
`has been fragmented. The 32-bit IPv4 addresses are usually expressed in dotted
`
`decimal notion. For example, an IP address of Google.com is 216.58.216.46.
`
`
`
`
`
`20
`
`DELL Ex.1003.021
`
`

`

`Petition for Inter Partes Review of 7,337,241
`Ex. 1003 (“Horst Decl.”)
`
`
`
`
`
`
`4.
`
`TCP Header
`
` Ex.1008, Stevens1 at .249, Fig. 17.2.
`
`
`
`34. Above the IP layer is the TCP (Transport) layer. A TCP header is
`
`illustrated by the figure above from Stevens1. The TCP header includes 16-bit
`
`source and destination port numbers for identifying the processes that are
`
`communicating. These port numbers identify the end points (e.g., client or server
`
`programs) sending and receiving data on each end of the connection. TCP is used
`
`to establish connections between processes at IP addresses across the network and
`
`the TCP port numbers identify which processes are communicating. For instance,
`
`Email may use SMTP (simple mail transfer protocol) on port 25 (SMTP’s well-
`
`
`
`
`
`21
`
`DELL Ex.1003.022
`
`

`

`Petition for Inter Partes Review of 7,337,241
`Ex. 1003 (“Horst Decl.”)
`
`
`
`
`
`known port number) while a web server is using HTTP on port 80 (HTTP’s well-
`
`known port number).
`
`35. The TCP layer performs several important functions such as tracking
`
`the sequence of packets to ensure that the TCP packets are assembled in the proper
`
`order. As shown above, a “sequence number” is included in the TCP header for
`
`several reasons such as identifying TCP packets and performing reassembly of
`
`these packets. The TCP layer tracks and acknowledges the sequence of packets to
`
`allow the TCP layer to identify and re-send lost (and therefore unacknowledged)
`
`data so that the application does not have to manage this process. The TCP layer
`
`assembles the data from packet payloads in the proper order by using sequence
`
`numbers in the TCP packet headers.
`
`36. TCP maintains the status of each connection with a finite state
`
`machine. The TCP finite state machine and associated messages are described in
`
`detail in RFC 793. RFC 793 describes the data structure for storing the
`
`information needed to maintain a TCP connection as a Transmission Control Block
`
`(TCB). Ex.1007, RFC 793 at .016. The finite state machine is also illustrated in
`
`Tanenbaum96 below.
`
`
`
`
`
`22
`
`DELL Ex.1003.023
`
`

`

`Petition for Inter Partes Review of 7,337,241
`Ex. 1003 (“Horst Decl.”)
`
`
`
`
`
`
`Ex.1006, Tanenbaum96 at .550, Fig. 6-28.
`
`23
`
`
`
`
`
`
`
`DELL Ex.1003.024
`
`

`

`Petition for Inter Partes Review of 7,337,241
`Ex. 1003 (“Horst Decl.”)
`
`
`
`
`
`
`37. Connections begin in a CLOSED state. Different control flags in the
`
`TCP header of packets sent between client and server affect the state of the
`
`connection. These control flags are URG, ACK, PSH, RST, SYN, and FIN as
`
`illustrated below.
`
`
`
`
`
`24
`
`DELL Ex.1003.025
`
`

`

`Petition for Inter Partes Review of 7,337,241
`Ex. 1003 (“Horst Decl.”)
`
`
`
`
`
`
`
` Ex.1008, Stevens1 at .249, Fig. 17.2. Certain control flags indicate that the
`
`connection is not yet established or will be closed. A server can move from
`
`CLOSED into a LISTEN state, where it will wait until a request to initialize a
`
`connection is received in a packet with the SYN flag set. A server is not in the
`
`ESTABLISHED state until the server acknowledges the SYN packet. In the
`
`ESTABLISHED state, data is transferred over the connection. Either side can
`
`close the connection by sending a packet with the FIN flag set. The connection
`
`can also be closed by a packet with the RST (reset) flag set. When the connection
`
`is closed, it is no longer in the ESTABLISHED state.
`
`38. Accordingly, routing packets between source and destination
`
`processes over a TCP/IP connection using Ethernet requires TCP source and
`
`
`
`
`
`25
`
`DELL Ex.1003.026
`
`

`

`Petition for Inter Partes Review of 7,337,241
`Ex. 1003 (“Horst Decl.”)
`
`
`
`
`
`destination port numbers, source and destination IP addresses, and source and
`
`destination MAC addresses. For more information on TCP, see Stevens1 (Ex.1008)
`
`Chapter 17, “TCP: Transmission Control Protocol,” at .247-.252.
`
`5.
`
`Application Data
`
`39. Each user application typically has at least one range of addresses in
`
`the user space region of host memory where it places data for transmission and
`
`receives data from the network. For transmission, the protocol stack can retrieve
`
`data from this area in host memory, encapsulate it in packets as described above,
`
`and then transmit it over the network. For receipt of data, the protocol stack puts
`
`data in the assigned host memory after it has processed and stripped off the MAC,
`
`IP, and TCP headers from the packet.
`
`6.
`
`RFC 793 – TCP Specification
`
`40. The original TCP specification was published in RFC 793 (Ex.1007)
`
`in September 1981. RFC 793 is a full specification for TCP and shows, among
`
`many other things, that identifying a TCP connection by its source and destination
`
`IP addresses and TCP ports were known more than 15 years before