`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`______________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`______________________
`
`
`WISTRON CORPORATION
`Petitioner
`
`v.
`
`ALACRITECH, INC.
`Patent Owner
`
`________________________
`
`Case IPR. No. IPR2018-00327
`U.S. Patent No. 7,237,036
`Title: FAST-PATH APPARATUS FOR RECEIVING DATA CORRESPONDING
`A TCP CONNECTION
`________________________
`
`
`Declaration of Robert Horst, Ph.D. in Support of
`Petition for Inter Partes Review
`of U.S. Patent No. 7,237,036
`
`
`
`WISTRON CORP. EXHIBIT 1003.001
`
`

`

`Petition for Inter Partes Review of 7,237,036
`Ex. 1003 (“Horst Decl.”)
`
`TABLE OF CONTENTS
`
`
`
`Page
`
`
`
`I.
`II.
`III.
`
`IV.
`V.
`
`A.
`B.
`
`INTRODUCTION AND QUALIFICATIONS .......................................... 1
`MATERIALS RELIED ON IN FORMING MY OPINION ..................... 3
`UNDERSTANDING OF THE GOVERNING LAW ................................ 4
`Invalidity by Anticipation ..................................................................... 4
`Invalidity by Obviousness ..................................................................... 5
`LEVEL OF ORDINARY SKILL IN THE ART ........................................ 6
`STATE OF THE ART AND OVERVIEW OF TECHNOLOGY
`AT ISSUE ................................................................................................... 7
`Layered Network Protocols ................................................................... 8
`1.
`OSI Layers .................................................................................. 8
`2.
`TCP/IP Layers ............................................................................. 8
`TCP/IP ................................................................................................. 10
`1.
`Encapsulation ............................................................................ 11
`2.
`Ethernet Header ......................................................................... 12
`3.
`IP Header ................................................................................... 14
`4.
`TCP header ................................................................................ 15
`5.
`RFC 793 – TCP Specification................................................... 16
`6.
`Prepending Headers .................................................................. 19
`7.
`TCP Control Block (TCB) ........................................................ 20
`8.
`Segmentation ............................................................................. 23
`9.
`Advertising a Receive Window ................................................ 24
`Protocol Offload .................................................................................. 25
`1.
`RFC 647 – Front-Ending .......................................................... 25
`2.
`RFC 929 – Outboard Processing .............................................. 26
`3. Mediation Levels ....................................................................... 28
`D. Offloaded Protocols ............................................................................. 31
`1.
`OSI Protocol Offload ................................................................ 31
`
`A.
`
`B.
`
`C.
`
`
`
`ii
`
`WISTRON CORP. EXHIBIT 1003.002
`
`

`

`Petition for Inter Partes Review of 7,237,036
`Ex. 1003 (“Horst Decl.”)
`
`TCP/IP Protocol Offload ........................................................... 31
`2.
`VMTP and XTP Protocol Offload ............................................ 31
`3.
`4. Multi-Protocol Offload ............................................................. 31
`Portions of the Protocol Offloaded ..................................................... 32
`1.
`Checksum Offload .................................................................... 32
`2.
`Full Offload ............................................................................... 33
`3. Multi-Level Offload .................................................................. 34
`4.
`Header Prediction ...................................................................... 34
`Offload Implementation ...................................................................... 37
`1. Multiprocessor Offload ............................................................. 37
`2.
`Offload Adapters based on Microprocessors ............................ 39
`3.
`Offload Adapters based on Custom Processors or Custom
`Logic ......................................................................................... 40
`Protocol Offload Summary ................................................................. 43
`G.
`H. Additional Background Technology ................................................... 44
`1.
`DMA ......................................................................................... 44
`2.
`Virtual and Physical Memory Addresses .................................. 46
`OVERVIEW OF 036 PATENT ............................................................... 47
`036 PATENT PROSECUTION HISTORY ............................................. 50
`CLAIM CONSTRUCTIONS ................................................................... 52
`Legal Standard ..................................................................................... 52
`“context” .............................................................................................. 52
`“prepend” ............................................................................................. 53
`THE PRIOR ART ..................................................................................... 54
`Tanenbaum96: A. Tanenbaum, Computer Networks,
`3rd ed. (1996) ...................................................................................... 54
`U.S. Patent No. 5,768,618 (“Erickson”) ............................................. 61
`Obviousness Combinations – Motivations To Combine ......................... 73
`Erickson in Combination with Tanenbaum96 .................................... 73
`GROUNDS OF INVALIDITY ................................................................ 80
`
`A.
`
`ii
`
`E.
`
`F.
`
`A.
`B.
`C.
`
`A.
`
`B.
`
`VI.
`VII.
`VIII.
`
`IX.
`
`X.
`
`XI.
`
`
`
`WISTRON CORP. EXHIBIT 1003.003
`
`

`

`
`I, Robert Horst, hereby declare as follows:
`
`Petition for Inter Partes Review of 7,237,036
`Ex. 1003 (“Horst Decl.”)
`
`I.
`
`INTRODUCTION AND QUALIFICATIONS
`1. My name is Robert Horst. I have been retained on behalf of Petitioner
`
`Wistron Corporation (“Wistron”) to provide this Declaration concerning technical
`
`subject matter relevant to the petition for inter partes review (“Petition”)
`
`concerning U.S. Patent No. 7,237,036 (Ex.1001, the “036 Patent”). 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
`
`as an expert witness and consultant in patent and intellectual property litigation as
`
`well as inter partes reviews and re-examination proceedings.
`
`
`
`1
`
`WISTRON CORP. EXHIBIT 1003.004
`
`

`

`Petition for Inter Partes Review of 7,237,036
`Ex. 1003 (“Horst Decl.”)
`
`I earned my M.S. (1978) in electrical engineering and Ph.D. (1991) in
`
`6.
`
`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.
`
`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
`
`
`
`2
`
`WISTRON CORP. EXHIBIT 1003.005
`
`

`

`Petition for Inter Partes Review of 7,237,036
`Ex. 1003 (“Horst Decl.”)
`
`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).
`
`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,237,036 (Ex.1001), I also
`
`reviewed and considered the prosecution history of the 036 Patent (Ex.1002). I
`
`
`
`3
`
`WISTRON CORP. EXHIBIT 1003.006
`
`

`

`Petition for Inter Partes Review of 7,237,036
`Ex. 1003 (“Horst Decl.”)
`
`also reviewed U.S. Pat. No. 5,768,618, to Erickson (Ex.1005), and A. Tanenbaum,
`
`3rd ed. (1996) (Ex.1006). 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
`
`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.
`
`
`
`4
`
`WISTRON CORP. EXHIBIT 1003.007
`
`

`

`Petition for Inter Partes Review of 7,237,036
`Ex. 1003 (“Horst Decl.”)
`
`
`Invalidity by Obviousness
`
`I have been informed that a patent claim is invalid as obvious under
`
`B.
`16.
`
`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-7 of the 036 Patent. Accordingly, my analysis of the prior art for
`
`the claims of the 036 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;
`
`
`
`5
`
`WISTRON CORP. EXHIBIT 1003.008
`
`

`

`Petition for Inter Partes Review of 7,237,036
`Ex. 1003 (“Horst Decl.”)
`
`(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;
`
`(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
`
`
`
`6
`
`WISTRON CORP. EXHIBIT 1003.009
`
`

`

`Petition for Inter Partes Review of 7,237,036
`Ex. 1003 (“Horst Decl.”)
`
`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 036 Patent is directed to an apparatus and
`
`methods for 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
`
`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.
`
`
`
`7
`
`WISTRON CORP. EXHIBIT 1003.010
`
`

`

`Petition for Inter Partes Review of 7,237,036
`Ex. 1003 (“Horst Decl.”)
`
`
`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.
`
`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),
`
`
`1 References on TCP/IP use different terminology to describe the layer under IP.
`
`The data link layer is also called the “host-to-network layer” in Tanenbaum96 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
`
`
`
`
`
`8
`
`WISTRON CORP. EXHIBIT 1003.011
`
`

`

`Petition for Inter Partes Review of 7,237,036
`Ex. 1003 (“Horst Decl.”)
`
`transport (e.g. TCP, UDP, VMTP, XTP), and Application (e.g. FTP, SMTP,
`
`Telnet, HTTP). The following figure shows the relationship between the OSI and
`
`TCP/IP layering.
`
`
`Available at http://mitigationlog.com/how-tcpip-and-reference-osi-model-works/.2
`
`
`
`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
`
`art references use many of these terms and also sometimes use the name of a
`
`specific implementation (e.g. Ethernet, ATM).
`
`2 It appears that this diagram was made in 2012. It is being used for illustrative
`
`purposes only.
`
`
`
`9
`
`WISTRON CORP. EXHIBIT 1003.012
`
`

`

`Petition for Inter Partes Review of 7,237,036
`Ex. 1003 (“Horst Decl.”)
`
`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 how the user data has been partitioned into
`
`individual packets.
`
`B. TCP/IP
`26. 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. By that time, detailed descriptions of the protocols and open-source
`
`implementations were widely available from books, technical papers, and code
`
`repositories. 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. A few of the key
`
`RFCs are quoted below to establish when certain concepts were proposed and
`
`documented. TCP/IP consists of two parts: (1) Transmission Control Protocol
`
`(TCP), which provides virtual bi-directional connections between programs
`
`
`3 These books were well known resources to a POSA. Consistent with that,
`
`Alacritech patents cite editions of the Tanenbaum and Stevens books.
`
`
`
`10
`
`WISTRON CORP. EXHIBIT 1003.013
`
`

`

`Petition for Inter Partes Review of 7,237,036
`Ex. 1003 (“Horst Decl.”)
`
`running on different computers over the internet, and provides guaranteed error-
`
`free delivery of arbitrary amounts of data; and (2) Internet Protocol (IP), which
`
`provides delivery of datagrams (packets) to any routable internet address, without
`
`any reliability guarantees. TCP/IP can be transmitted over a variety of physical
`
`media (e.g. Ethernet).
`
`1.
`Encapsulation
`27. Network layering corresponds to the encapsulation of higher levels by
`
`lower levels. The following figure shows an example with application data
`
`accompanied by an application header. 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
`
`then encapsulates that with a TCP header, etc. The processing occurs sequentially,
`
`from top to bottom, as shown below.
`
`
`
`11
`
`WISTRON CORP. EXHIBIT 1003.014
`
`

`

`Petition for Inter Partes Review of 7,237,036
`Ex. 1003 (“Horst Decl.”)
`
`
`
`
`Ex.1008, Stevens1 at .034.
`2.
`Ethernet Header
`28. The 14-byte Ethernet header includes 48-bit (6-byte) source and
`
`destination MAC (media access control) addresses for uniquely identifying the
`
`network adapters at each end of the link.
`
`
`
`12
`
`WISTRON CORP. EXHIBIT 1003.015
`
`

`

`Petition for Inter Partes Review of 7,237,036
`Ex. 1003 (“Horst Decl.”)
`
`
`
`
`Ex.1013, Stevens2 at .125.
`29.
`
` 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.
`
`
`
`13
`
`WISTRON CORP. EXHIBIT 1003.016
`
`

`

`3.
`
`IP Header
`
`Petition for Inter Partes Review of 7,237,036
`Ex. 1003 (“Horst Decl.”)
`
`
`
`
`
`
`Ex.1008, Stevens1 at .058.
`30. 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
`
`of the connection. 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.
`
`
`
`14
`
`WISTRON CORP. EXHIBIT 1003.017
`
`

`

`4.
`
`TCP header
`
`Petition for Inter Partes Review of 7,237,036
`Ex. 1003 (“Horst Decl.”)
`
`
`
`
`
`
` Ex.1008, Stevens1 at .249.
`31. 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. 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). The TCP
`
`layer performs several important functions such as ensuring that the segments are
`
`assembled in the proper order. As shown above, a “sequence number” is included
`
`for several reasons such as identifying segments and performing reassembly. For
`
`
`
`15
`
`WISTRON CORP. EXHIBIT 1003.018
`
`

`

`Petition for Inter Partes Review of 7,237,036
`Ex. 1003 (“Horst Decl.”)
`
`information on TCP, see Stevens1 (Ex.1008) Chapter 17, “TCP:
`
`more
`
`Transmission Control Protocol,” pp. 223-228. A sender or receiver maintains the
`
`“sequence number” as a variable for these purposes. Accordingly, routing packets
`
`between source and destination processes over Ethernet is based on the MAC
`
`addresses, IP addresses and TCP ports.
`
`5.
`RFC 793 – TCP Specification
`32. 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.
`
`a)
`Sockets
`33. The combination of an IP address and a port number is sometimes
`
`called a “socket.” A TCP connection is formed by a pair of sockets which includes
`
`a source IP address and TCP port number and a destination IP address and TCP
`
`port number. IP addresses and TCP ports can be specified by the application. For
`
`instance, a browser accessing Google.com may open a socket to IP address
`
`216.58.216.46 and port 80:
`
`The combination of an IP address and a port number is sometimes
`called a socket. This term appeared in the original TCP specification
`(RFC 793), and later it also became used as the name of the Berkeley-
`
`
`
`16
`
`WISTRON CORP. EXHIBIT 1003.019
`
`

`

`Petition for Inter Partes Review of 7,237,036
`Ex. 1003 (“Horst Decl.”)
`
`
`derived programming interface (Section 1.15). It is the socket pair (the
`4-tuple consisting of the client IP address, client port number, server
`IP address, and server port number) that specifies the two end points
`that uniquely identifies each TCP connection in an internet.
`
`Ex.1008, Stevens1 at .250.
`34. Much of the software for network communications leverages standard
`
`application programming interfaces (APIs) and libraries. An early standard is
`
`Berkeley Sockets, also known as BSD Sockets or just “sockets.” Tanenbaum96
`
`offers this overview of sockets:
`
`Let us now briefly inspect another set of transport primitives, the
`socket primitives used in Berkeley UNIX for TCP. They are listed in
`Fig. 6-6. Roughly speaking, they follow the model of our first
`example but offer more features and flexibility. We will not look at
`the corresponding TPDUs here. That discussion will have to wait until
`we study TCP later in this chapter.
`
`The first four primitives in the list [SOCKET, BIND, LISTEN,
`ACCEPT] are executed in that order by servers. The SOCKET
`primitive creates a new end point and allocates table space for it
`within the transport entity. The parameters of the call specify the
`addressing format to be used, the type of service desired (e.g., reliable
`byte stream), and the protocol.
`
`Ex.1006, Tanenbaum96 at .504-.505.
`
`Now let us look at the client side. Here, too, a socket must first be
`created using the SOCKET primitive, but BIND is not required since
`
`
`
`17
`
`WISTRON CORP. EXHIBIT 1003.020
`
`

`

`Petition for Inter Partes Review of 7,237,036
`Ex. 1003 (“Horst Decl.”)
`
`
`the address used does not matter to the server. The CONNECT
`primitive blocks the caller and actively starts the connection process.
`When it completes (i.e., when the appropriate TPDU is received from
`the server), the client process is unblocked and the connection is
`established. Both sides can now use SEND and RECEIVE to transmit
`and receive data over the full-duplex connection.
`
`Id. at .505.
`35. Establishing a connection over TCP is sometimes called “opening a
`
`socket.” As described above, after the server has executed its sequence of
`
`primitives SOCKET, BIND, LISTEN, ACCEPT, the client executes the SOCKET
`
`and CONNECT primitives, then both sides can communicate using SEND and
`
`RECEIVE. These primitives involve control packet transmissions (versus simply
`
`sending a data packet that includes application data). Opening a socket
`
`(establishing a connection) thus requires both the sender and receiver exchanging a
`
`series of control messages, interpreting the messages, and in response to certain
`
`control messages, responding with the appropriate message. Accordingly, it is a
`
`more complex process to open a connection (and enter an ESTABLISHED state)
`
`than simply one side sending a single data packet transmission. As described
`
`below, this is why it was known in the art for the host to open the connection (the
`
`more complex aspect of communication) and to offload only the sending and
`
`receiving of data packets to a separate device.
`
`
`
`18
`
`WISTRON CORP. EXHIBIT 1003.021
`
`

`

`Petition for Inter Partes Review of 7,237,036
`Ex. 1003 (“Horst Decl.”)
`
`
`6.
`Prepending Headers
`36. When a socket is opened and after the connection is established,
`
`application data is sent and received by constructing packets that encapsulate the
`
`data. Standard UDP/IP and TCP/IP implementations, such as BSD 4.4-Lite, copy
`
`headers and data into linked list structures called mbufs. Stevens2 describes how
`
`headers are prepended to the data in the mbuf chain:
`
`Ex.1013, Stevens2 at .043.
`
`
`
`19
`
`
`
`WISTRON CORP. EXHIBIT 1003.022
`
`

`

`Petition for Inter Partes Review of 7,237,036
`Ex. 1003 (“Horst Decl.”)
`
`37. Figure 1.8 above shows an Mbuf chain for UDP, but Stevens2 later
`
`broadens the discussion to include TCP and shows diagrams of TCP and UDP
`
`mbuf chains.
`
`Figure 2.2 shows an example of two packets on a queue. It is a
`modification of Figure 1.8. We have placed the UDP datagram onto
`the interface output queue (showing that the 14-byte Ethernet header
`has-been prepended to the IP header in the first mbuf on the chain)
`and have added a second packet to the queue: a TCP segment
`containing 1460 bytes of user data. The TCP data is contained in a
`cluster and an mbuf has been prepended to contain its Ethernet, IP,
`and TCP headers.
`
`Ex.1013, Stevens2 at .060.
`38. Note that the outgoing frames include all three headers – MAC (e.g.
`
`Ethernet), IP and TCP. The first hop MAC address is determined based on the
`
`route to the destination. Once the destination MAC address is determined, it is
`
`stored and accessed when constructing the outgoing frames. Accordingly, the
`
`construction of packets, whether on the host or network interface card (see
`
`offloading discussion below), requires adding the TCP, IP, and MAC headers.
`
`7.
`TCP Control Block (TCB)
`39. Established connections need to maintain certain state information.
`
`For example, the state of a TCP connection is used to track acknowledgements
`
`(ACKs) with the connection that requested the data in order to later retransmit the
`
`
`
`20
`
`WISTRON CORP. EXHIBIT 1003.023
`
`

`

`Petition for Inter Partes Review of 7,237,036
`Ex. 1003 (“Horst Decl.”)
`
`segment if required. The TCP state is held in a structure called the TCB (TCP or
`
`transmission control block).
`
`The maintenance of a TCP connection requires the remembering of
`several variables. We conceive of these variables being stored in a
`connection record called a Transmission Control Block or TCB.
`Among the variables stored in the TCB are the local and remote
`socket numbers, the security and precedence of the connection,
`pointers to the user’s send and receive buffers, pointers to the
`retransmit queue and to the current segment. In addition several
`variables relating to the send and receive sequence numbers are stored
`in the TCB.
`
`
`Ex.1007, RFC 793 at .024.
`
`40. TCBs maintain the state at each end of a TCP connection:
`
`Protocol control blocks (PCBs) are used at the protocol layer to hold
`the va