`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`______________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`______________________
`
`
`DELL INC.
`Petitioner
`
`v.
`
`ALACRITECH, INC.
`Patent Owner
`
`________________________
`
`Case IPR. No. IPR2018-01307
`U.S. Patent No. 8,850,948
`Title: INTELLIGENT NETWORK INTERFACE SYSTEM AND METHOD FOR
`PROTOCOL PROCESSING
`________________________
`
`
`Declaration of Robert Horst, Ph.D. in Support of
`Petition for Inter Partes Review
`of U.S. Patent No. 8,850,948
`
`
`
`DELL Ex.1003.001
`
`

`

`
`
`I.
`II.
`III.
`
`IV.
`V.
`
`Petition for Inter Partes Review of 8,850,948
`Ex. 1003 (“Horst Decl.”)
`
`TABLE OF CONTENTS
`
`
`
`Page
`
`A.
`B.
`
`A.
`
`B.
`
`B.
`
`C.
`
`INTRODUCTION AND QUALIFICATIONS ......................................... 1
`MATERIALS RELIED ON IN FORMING MY OPINION ..................... 4
`UNDERSTANDING OF THE GOVERNING LAW ............................... 4
`Invalidity by Anticipation .................................................................... 4
`Invalidity by Obviousness .................................................................... 5
`LEVEL OF ORDINARY SKILL IN THE ART ....................................... 7
`STATE OF THE ART AND OVERVIEW OF TECHNOLOGY
`AT ISSUE .................................................................................................. 8
`Layered Network Protocols .................................................................. 8
`1.
`OSI Layers ................................................................................. 8
`2.
`TCP/IP Layers ............................................................................ 9
`TCP/IP ................................................................................................ 11
`1.
`Encapsulation ........................................................................... 12
`2.
`Ethernet Header ........................................................................ 14
`3.
`IP Header .................................................................................. 16
`4.
`TCP header ............................................................................... 17
`5.
`Application Data ...................................................................... 21
`6.
`RFC 793 – TCP Specification .................................................. 21
`Protocol Offload and Fast-Path Processing ........................................ 21
`1.
`RFC 647 – Front-Ending .......................................................... 22
`2.
`RFC 929 – Outboard Processing .............................................. 23
`3. Mediation Levels ...................................................................... 24
`Offloaded Protocols ............................................................................ 27
`1.
`OSI Protocol Offload ............................................................... 27
`2.
`TCP/IP Protocol Offload .......................................................... 27
`3.
`VMTP and XTP Protocol Offload ........................................... 28
`4. Multi-Protocol Offload ............................................................ 28
`
`
`
`ii
`
`DELL Ex.1003.002
`
`

`

`D.
`
`E.
`
`Petition for Inter Partes Review of 8,850,948
`Ex. 1003 (“Horst Decl.”)
`
`Portions of the Protocol Offloaded ..................................................... 29
`1.
`Checksum Offload ................................................................... 29
`2.
`Full Offload .............................................................................. 30
`3. Multi-Level Offload ................................................................. 30
`4.
`Header Prediction ..................................................................... 30
`Offload Implementation ..................................................................... 33
`1. Multiprocessor Offload ............................................................ 34
`2.
`Offload Adapters based on Microprocessors ........................... 35
`3.
`Offload Adapters based on Custom Processors or Custom
`Logic ........................................................................................ 37
`Protocol Offload Summary ................................................................ 40
`F.
`G. Additional Background Technology .................................................. 40
`1.
`DMA ........................................................................................ 41
`2.
`Virtual and Physical Memory Addresses ................................. 43
`OVERVIEW OF 948 PATENT .............................................................. 45
`948 PATENT PROSECUTION HISTORY ............................................ 48
`CLAIM CONSTRUCTIONS .................................................................. 49
`Legal Standard .................................................................................... 49
`THE PRIOR ART .................................................................................... 50
`Thia: Thia, A Reduced Operation Protocol Engine
`(ROPE) for a mulitple-layer bypass architecture (1995) .................... 50
`Tanenbaum96: A. Tanenbaum, Computer Networks,
`3rd ed. (1996) ..................................................................................... 56
`Stevens2: Stevens, TCP-IP Illustrated, Vol. 2 ................................... 68
`Obviousness Combinations – Motivations To Combine ......................... 70
`Thia in Combination with Tanenbaum96 ........................................... 70
`Thia in Combination with Tanenbaum96 and further in
`Combination with Stevens2 ............................................................... 75
`GROUNDS OF INVALIDITY ............................................................... 77
`
`A.
`
`A.
`
`B.
`
`C.
`
`A.
`B.
`
`ii
`
`VI.
`VII.
`VIII.
`
`IX.
`
`X.
`
`XI.
`
`
`
`
`DELL Ex.1003.003
`
`

`

`
`I, Robert Horst, hereby declare as follows:
`
`Petition for Inter Partes Review of 8,850,948
`Ex. 1003 (“Horst Decl.”)
`
`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. 8,850,948 (Ex.1001, the “948 Patent”). I previously offered a substantially
`
`identical declaration in connection with Case Nos. IPR2018-00234 (by Intel
`
`Corporation) and IPR2018-00403 (by Cavium, Inc.). 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 am also
`
`1
`
`DELL Ex.1003.004
`
`

`

`currently an Adjunct Research Professor at the University of Illinois at Urbana-
`
`Petition for Inter Partes Review of 8,850,948
`Ex. 1003 (“Horst Decl.”)
`
`
`Champaign. I have testified 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.
`
`2
`
`DELL Ex.1003.005
`
`

`

`Petition for Inter Partes Review of 8,850,948
`Ex. 1003 (“Horst Decl.”)
`
`Since leaving Compaq in 1999, I have worked with several
`
`8.
`
`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 82 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.
`
`3
`
`DELL Ex.1003.006
`
`

`

`Petition for Inter Partes Review of 8,850,948
`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. 8,850,948 (Ex.1001), I also
`
`reviewed and considered the prosecution history of the 948 Patent (Ex.1002). I
`
`also reviewed Thia, A ROPE for multiple-layer bypass architecture (“Thia”)
`
`(Ex.1015), A. Tanenbaum, 3rd ed. (1996) (Ex.1006), and Stevens, TCP-IP
`
`Illustrated, Vol.2 (“Stevens2”) (Ex.1013). 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.
`
`A.
`14.
`
`Invalidity by Anticipation
`
`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
`
`4
`
`DELL Ex.1003.007
`
`

`

`Petition for Inter Partes Review of 8,850,948
`Ex. 1003 (“Horst Decl.”)
`
`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.
`16.
`
`Invalidity by Obviousness
`
`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:
`
`(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 claims 1, 3, 6-9, 11, 14-17, 19, and 21-22 of the 948 Patent. Accordingly
`
`my analysis of the prior art for the claims of the 948 Patent is based on the prior art
`
`5
`
`DELL Ex.1003.008
`
`

`

`Petition for Inter Partes Review of 8,850,948
`Ex. 1003 (“Horst Decl.”)
`
`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;
`
`(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;
`
`6
`
`DELL Ex.1003.009
`
`

`

`Petition for Inter Partes Review of 8,850,948
`Ex. 1003 (“Horst Decl.”)
`
`(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.
`
`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 948 Patent is directed to an apparatus and
`
`methods for 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
`
`7
`
`DELL Ex.1003.010
`
`

`

`Petition for Inter Partes Review of 8,850,948
`Ex. 1003 (“Horst Decl.”)
`
`(“POSA”) is a person with at least the equivalent of a B.S. degree in computer
`
`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.
`
`8
`
`DELL Ex.1003.011
`
`

`

`Petition for Inter Partes Review of 8,850,948
`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
`
`Tanenebaum96 and the “interface layer” in Stevens2 (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).
`
`9
`
`DELL Ex.1003.012
`
`

`

`Petition for Inter Partes Review of 8,850,948
`Ex. 1003 (“Horst Decl.”)
`
`
`
`
`Available at http://mitigationlog.com/how-tcpip-and-reference-osi-model-works/.2
`
`An application layer is above the transport layer in both protocols.
`
`25. 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
`
`what application the data belongs to or even whether it is receiving packets in the
`
`correct order.
`
`2 It appears that this diagram was made in 2012. It is being used for illustrative
`
`purposes only.
`
`10
`
`DELL Ex.1003.013
`
`

`

`Petition for Inter Partes Review of 8,850,948
`Ex. 1003 (“Horst Decl.”)
`
`
`B. TCP/IP
`26. The 948 Patent relates to an intelligent network interface card that
`
`provides a “fast path” that avoids host protocol processing for most packets in a
`
`large multipacket message. Ex.1001, 948 Patent at Abstract. The claims are all
`
`directed to 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.
`
`11
`
`DELL Ex.1003.014
`
`

`

`Petition for Inter Partes Review of 8,850,948
`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).
`
`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
`
`12
`
`DELL Ex.1003.015
`
`

`

`Petition for Inter Partes Review of 8,850,948
`Ex. 1003 (“Horst Decl.”)
`
`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
`
`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
`
`13
`
`DELL Ex.1003.016
`
`

`

`Petition for Inter Partes Review of 8,850,948
`Ex. 1003 (“Horst Decl.”)
`
`then encapsulates that with a TCP header, etc. The processing occurs sequentially,
`
`from top to bottom, as shown below.
`
`
`Ex.1008, Stevens1 at .034. When receiving a packet from the network, the layers
`
`work in reverse, with each layer stripping its header and providing the 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
`
`14
`
`DELL Ex.1003.017
`
`

`

`Petition for Inter Partes Review of 8,850,948
`Ex. 1003 (“Horst Decl.”)
`
`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.
`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
`
`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.
`
`15
`
`DELL Ex.1003.018
`
`

`

`3.
`
`IP Header
`
`Petition for Inter Partes Review of 8,850,948
`Ex. 1003 (“Horst Decl.”)
`
`
`
`
`
`
`Ex.1008, Stevens1 at .058.
`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.
`
`16
`
`DELL Ex.1003.019
`
`

`

`4.
`
`TCP header
`
`Petition for Inter Partes Review of 8,850,948
`Ex. 1003 (“Horst Decl.”)
`
`
`
`
`
`
` Ex.1008, Stevens1 at .249.
`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-
`
`known port number) while a web server is using HTTP on port 80 (HTTP’s well-
`
`known port number).
`
`17
`
`DELL Ex.1003.020
`
`

`

`Petition for Inter Partes Review of 8,850,948
`Ex. 1003 (“Horst Decl.”)
`
`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, so
`
`that the sending TCP layer can 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.
`
`18
`
`DELL Ex.1003.021
`
`

`

`Petition for Inter Partes Review of 8,850,948
`Ex. 1003 (“Horst Decl.”)
`
`
`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.
`
`
`
`19
`
`DELL Ex.1003.022
`
`

`

`Petition for Inter Partes Review of 8,850,948
`Ex. 1003 (“Horst Decl.”)
`
`
`
` Ex.1008, Stevens1 at .249. 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 special packet called a FIN packet. Control flags URG, and RST are
`
`also requests to close a connection, which indicates that the server is no longer in
`
`the ESTABLISHED state.
`
`37. Accordingly, routing packets between source and destination
`
`processes over a TCP/IP connection using Ethernet requires TCP source and
`
`destination port numbers, source and destination IP addresses, and source and
`
`20
`
`DELL Ex.1003.023
`
`

`

`Petition for Inter Partes Review of 8,850,948
`Ex. 1003 (“Horst Decl.”)
`
`destination MAC addresses. For more information on TCP, see Stevens1 (Ex.1008)
`
`Chapter 17, “TCP: Transmission Control Protocol,” .247-252.
`
`5.
`Application Data
`38. 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
`39. 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 the earliest
`
`priority dates of the Alacritech patents.
`
`B.
`Protocol Offload and Fast-Path Processing
`40. To increase performance and reduce demands on the host computer
`
`required for protocol processing, designers have employed different techniques
`
`such as parallel processing, improved hardware, memory copy reduction via
`
`hardware and/or software, and hardware to offload all or part of the protocol stack.
`
`21
`
`DELL Ex.1003.024
`
`

`

`Petition for Inter Partes Review of 8,850,948
`Ex. 1003 (“Horst Decl.”)
`
`
`1.
`RFC 647 – Front-Ending
`41. As early as 1974, front-end protocol offload was already being
`
`considered for standardization as described in request-for-comments RFC 647.
`
`This represents the consensus at the time that front ending (the offloading of
`
`protocol processing) was desirable. At that time, NCP (Network Control Protocol)
`
`was the protocol used in ARPANET, the predecessor to the modern Internet.
`
`“FRONT-ENDING”
`
`In what might be thought of as the greater network community, the
`consensus is so broad that the front-ending is desirable that the topic
`needs almost no discussion here. Basically, a small machine (a PDP-
`11 is widely held to be most suitable) is interposed between the IMP
`and the host in order to shield the host from the complexities of the
`NCP.
`
`Ex.1019, RFC 647 at .002.
`42. RFC 647 goes on to discuss rigid and flexible front-end (FE)
`
`alternatives and includes a high-level discussion of a protocol