`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`______________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`______________________
`
`
`INTEL CORPORATION
`Petitioner
`
`v.
`
`ALACRITECH, INC.
`Patent Owner
`
`________________________
`
`Case IPR. No. Unassigned
`U.S. Patent No. 7,673,072
`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,673,072
`
`
`
`
`
`
`
`
`Mail Stop “PATENT BOARD”
`Patent Trial and Appeal Board
`U.S. Patent and Trademark Office
`P.O. Box 1450
`Alexandria, VA 22313-1450
`
`
`
`

`

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

`

`Petition for Inter Partes Review of 7,673,072
`Ex. 1003 (“Horst Decl.”)
`
`F.
`
`E.
`
`OSI Protocol Offload ............................................................... 30
`1.
`TCP/IP Protocol Offload .......................................................... 30
`2.
`VMTP and XTP Protocol Offload ........................................... 30
`3.
`4. Multi-Protocol Offload ............................................................ 31
`Portions of the Protocol Offloaded ..................................................... 31
`1.
`Checksum Offload ................................................................... 32
`2.
`Full Offload .............................................................................. 32
`3. Multi-Level Offload ................................................................. 33
`4.
`Header Prediction ..................................................................... 33
`a)
`Partial Offload with Header Prediction ......................... 35
`Offload Implementation ..................................................................... 35
`1. Multiprocessor Offload ............................................................ 36
`2.
`Offload Adapters based on Microprocessors ........................... 37
`3.
`Offload Adapters based on Custom Processors or Custom
`Logic ........................................................................................ 39
`Protocol Offload Summary ................................................................ 42
`G.
`H. Additional Background Technology .................................................. 42
`1.
`DMA ........................................................................................ 43
`2.
`Virtual and Physical Memory Addresses ................................. 45
`VI. OVERVIEW OF 072 PATENT ................................................................... 47
`VII. 072 PATENT PROSECUTION HISTORY ................................................. 51
`VIII. CLAIM CONSTRUCTIONS ....................................................................... 52
`A.
`Legal Standard .................................................................................... 52
`B.
`“context” ............................................................................................. 52
`C.
`“prepend” ........................................................................................... 53
`IX. THE PRIOR ART ......................................................................................... 53
`A. U.S. Patent No. 5,937,169 (“Connery”) ............................................. 53
`X. GROUNDS OF INVALIDITY .................................................................... 58
`XI. DECLARATION .......................................................................................... 58
`
`ii
`
`

`

`Petition for Inter Partes Review of 7,673,072
`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
`
`Intel Corporation (“Intel”) to provide this Declaration concerning technical subject
`
`matter relevant to the petition for inter partes review (“Petition”) concerning U.S.
`
`Patent No. 7,673,072 (Ex.1001, the “072 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.
`
`
`
`

`

`Petition for Inter Partes Review of 7,673,072
`Ex. 1003 (“Horst Decl.”)
`
`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.
`
`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
`
`

`

`Petition for Inter Partes Review of 7,673,072
`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,673,072 (Ex.1001), I also
`
`reviewed and considered the prosecution history of the 072 Patent (Ex.1002). I
`
`
`
`3
`
`

`

`Petition for Inter Partes Review of 7,673,072
`Ex. 1003 (“Horst Decl.”)
`
`also reviewed U.S. Pat. No. 5,937,169 to Connery (Ex.1043). 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
`
`

`

`Petition for Inter Partes Review of 7,673,072
`Ex. 1003 (“Horst Decl.”)
`
`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-21 of the 072 Patent. Accordingly my analysis of the prior art
`
`for the claims of the 072 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;
`
`
`
`5
`
`

`

`Petition for Inter Partes Review of 7,673,072
`Ex. 1003 (“Horst Decl.”)
`
`(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
`
`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 072 Patent is directed to an apparatus and
`
`methods for network protocol offload. In my experience, systems such as those
`
`6
`
`

`

`Petition for Inter Partes Review of 7,673,072
`Ex. 1003 (“Horst Decl.”)
`
`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.
`
`A. Layered Network Protocols
`22. The primary goal of computer networking is to provide fast, reliable
`
`data communications between computer systems. Interoperability has been
`
`
`
`7
`
`

`

`Petition for Inter Partes Review of 7,673,072
`Ex. 1003 (“Horst Decl.”)
`
`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),
`
`transport (e.g. TCP, UDP, VMTP, XTP), and Application (e.g. FTP, SMTP,
`
`
`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 Tanenebaum96
`
`(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).
`
`
`
`8
`
`

`

`Petition for Inter Partes Review of 7,673,072
`Ex. 1003 (“Horst Decl.”)
`
`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
`
`connection (that is, actually transmitting the data onto the physical wires) from
`
`layers above the physical, data link, and network layers above. Likewise, the
`
`
`2 It appears that this diagram was made in 2012. It is being used for illustrative
`
`purposes only.
`
`
`
`9
`
`

`

`Petition for Inter Partes Review of 7,673,072
`Ex. 1003 (“Horst Decl.”)
`
`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.
`
`1.
`Encapsulation
`27. Network layering corresponds to the encapsulation of higher levels by
`
`lower levels. The following figure shows an example with application data
`
`
`3 These books were well known resources to a POSA. Consistent with that,
`
`Alacritech patents cite editions of the Tanenbaum and Stevens books.
`
`
`
`10
`
`

`

`Petition for Inter Partes Review of 7,673,072
`Ex. 1003 (“Horst Decl.”)
`
`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
`
`

`

`Petition for Inter Partes Review of 7,673,072
`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.
`
`Ex.1013, Stevens2 at .125.
`
`
`
`12
`
`
`
`

`

`Petition for Inter Partes Review of 7,673,072
`Ex. 1003 (“Horst Decl.”)
`
`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.
`
`3.
`
`IP Header
`
`
`
`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.
`
`
`
`13
`
`

`

`Petition for Inter Partes Review of 7,673,072
`Ex. 1003 (“Horst Decl.”)
`
`4.
`
`TCP header
`
`
`
`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
`
`more
`
`
`information on TCP, see Stevens1 (Ex.1008) Chapter 17, “TCP:
`14
`
`

`

`Petition for Inter Partes Review of 7,673,072
`Ex. 1003 (“Horst Decl.”)
`
`Transmission Control Protocol,” .247-.252. 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 with 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-
`derived programming interface (Section 1.15). It is the socket pair (the
`
`
`
`15
`
`

`

`Petition for Inter Partes Review of 7,673,072
`Ex. 1003 (“Horst Decl.”)
`
`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.” Tanenabaum96
`
`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
`the address used does not matter to the server. The CONNECT
`16
`
`
`
`

`

`Petition for Inter Partes Review of 7,673,072
`Ex. 1003 (“Horst Decl.”)
`
`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.
`
`
`
`17
`
`

`

`Petition for Inter Partes Review of 7,673,072
`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.
`
`
`
`18
`
`
`
`

`

`Petition for Inter Partes Review of 7,673,072
`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
`
`
`
`19
`
`

`

`Petition for Inter Partes Review of 7,673,072
`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. TCB’s maintain the state at each end of a TCP connection:
`
`Protocol control blocks (PCBs) are used at the protocol layer to hold
`the various pieces of information required for each UDP or TCP
`socket. The Internet protocols maintain Internet protocol control
`blocks and TCP control blocks.
`
`Ex.1013, Stevens2 at .739.
`
`41. RFC 2140 shows a list of the information contained in a TCB:
`
`The TCP Control Block (TCB)
`
`A TCB is associated with each connection, i.e., with each association
`of a pair of applications across the network. The TCB can be
`summarized as containing [9]:
`
`Local process state
`
`
`
`20
`
`

`

`Petition for Inter Partes Review of 7,673,072
`Ex. 1003 (“Horst Decl.”)
`
`pointers to send and receive buffers
`
`pointers to retransmission queue and current segment
`
`pointers to Internet Protocol (IP) PCB
`
`Per-connection shared state
`
`macro-state
`
`connection state
`
`timers
`
`flags
`
`local and remote host numbers and ports
`
`micro-state
`
`send and receive window state (size*, current number)
`
`round-trip time and variance
`
`cong. window size*
`
`cong. window size threshold*
`
`max windows seen*
`
`MSS#
`
`round-trip time and variance#
`
`Ex.1014, RFC2140 at .002.
`
`As part of the TCP layer, the sequence number must be kept. For example,
`
`when sending subsequent packets, the TCP layer must increment the
`
`sequence variable, placing this new number into the next packet. Ex.1006,
`
`
`
`21
`
`

`

`Petition for Inter Partes Review of 7,673,072
`Ex. 1003 (“Horst Decl.”)
`
`Tanenbaum96 at .584. As will be shown below, either the host can pe