`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`______________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`______________________
`
`
`DELL INC.
`Petitioner
`
`v.
`
`ALACRITECH, INC.
`Patent Owner
`
`________________________
`
`Case IPR. No. 2018-00374
`U.S. Patent No. 9,055,104
`Title: FREEING TRANSMIT MEMORY ON A NETWORK INTERFACE
`DEVICE PRIOR TO RECEIVING AN ACKNOWLEDGEMENT THAT
`TRANSMIT DATA HAS BEEN RECEIVED BY A REMOTE DEVICE
`________________________
`
`
`Declaration of Robert Horst, Ph.D. in Support of
`Petition for Inter Partes Review
`of U.S. Patent No. 9,055,104
`
`
`
`DELL Ex.1003.001
`
`

`

`
`
`I.
`
`II.
`
`III.
`
`IV.
`
`V.
`
`Petition for Inter Partes Review of 9,055,104
`Ex.1003 (“Horst Decl.”)
`
`TABLE OF CONTENTS
`
`
`
`Page
`
`INTRODUCTION AND QUALIFICATIONS .......................................... 1
`
`MATERIALS RELIED ON IN FORMING MY OPINION ..................... 4
`
`UNDERSTANDING OF THE GOVERNING LAW ................................ 4
`
`A.
`
`B.
`
`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
`
`A.
`
`Layered Network Protocols ................................................................... 8
`
`(1) OSI Layers .................................................................................. 8
`
`(2)
`
`TCP/IP Layers ............................................................................. 8
`
`B.
`
`TCP/IP .................................................................................................10
`
`(1)
`
`(2)
`
`(3)
`
`(4)
`
`Encapsulation ............................................................................11
`
`Ethernet Header .........................................................................13
`
`IP Header ...................................................................................14
`
`TCP header ................................................................................15
`
`(5) RFC 793 – TCP Specification...................................................16
`
`(6)
`
`Sockets ......................................................................................16
`
`(7) Windows Sockets ......................................................................19
`
`(8)
`
`(9)
`
`Prepending Headers ..................................................................22
`
`TCP Control Block (TCB) ........................................................23
`
`(10) Segmentation .............................................................................26
`
`(11) Advertising a Receive Window ................................................27
`
`C.
`
`Protocol Offload ..................................................................................28
`
`(1) RFC 647 – Front-Ending ..........................................................28
`
`(2) RFC 929 – Outboard Processing ..............................................29
`
`
`
`i
`
`DELL Ex.1003.002
`
`

`

`Petition for Inter Partes Review of 9,055,104
`Ex.1003 (“Horst Decl.”)
`
`(3) Mediation Levels.......................................................................31
`
`D.
`
`Portions of the Protocol Offloaded .....................................................33
`
`(1) Checksum Offload ....................................................................34
`
`(2)
`
`Full Offload ...............................................................................35
`
`(3) Multi-Level Offload ..................................................................35
`
`(4) Header Prediction ......................................................................35
`
`E.
`
`Interrupts .............................................................................................37
`
`VI.
`
`OVERVIEW OF 104 PATENT ...............................................................38
`
`VII.
`
`104 PATENT PROSECUTION HISTORY .............................................41
`
`VIII.
`
`CLAIM CONSTRUCTION .....................................................................44
`
`THE PRIOR ART – U.S. Patent No. 5,937,169 (“Connery”) .................44
`
`GROUNDS OF INVALIDITY ................................................................48
`
`IX.
`
`X.
`
`
`
`
`
`ii
`
`DELL Ex.1003.003
`
`

`

`Petition for Inter Partes Review of 9,055,104
`Ex.1003 (“Horst Decl.”)
`
`
`I, Robert Horst, hereby declare as follows:
`
`I.
`
`INTRODUCTION AND QUALIFICATIONS
`
`1. My name is Robert Horst. I have been retained on behalf of Petitioner
`
`Dell Inc. (“Dell”) to provide this Declaration concerning technical subject matter
`
`relevant to the petition for inter partes review (“Petition”) concerning U.S. Patent
`
`No. 9,055,104 (Ex.1001, the “104 Patent”). I previously offered a substantially
`
`identical declaration in connection with Case Nos. IPR2017-01393 (for Intel
`
`Corporation) and IPR2017-01714 (for Cavium, Inc.). Unlike prior declarations,
`
`this declaration does not address claim 22 of the 104 Patent, which I understand
`
`has already been found invalid by a district court. 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.
`
`1
`
`DELL Ex.1003.004
`
`

`

`Petition for Inter Partes Review of 9,055,104
`Ex.1003 (“Horst Decl.”)
`
`Currently, I am an independent consultant at HT Consulting where my
`
`5.
`
`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.
`
`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 9,055,104
`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 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).
`
`3
`
`DELL Ex.1003.006
`
`

`

`Petition for Inter Partes Review of 9,055,104
`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. 9,055,104 (Ex.1001), I also
`
`reviewed and considered the prosecution history of the 104 Patent (Ex.1002). I
`
`also reviewed and considered the background materials and prior art references
`
`discussed, cited, and relied on 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. Invalidity by Anticipation
`
`14.
`
`I have been informed that a patent claim is invalid as anticipated
`
`under 35 U.S.C. § 102 if each and every element of a claim, as properly construed,
`
`is found either explicitly or inherently in a single prior art reference.
`
`15.
`
`I have been informed that a claim is invalid under 35 U.S.C. § 102(a)
`
`if the claimed invention was patented or published anywhere, before the
`
`applicant’s invention. I further have been informed that a claim is invalid under 35
`
`4
`
`DELL Ex.1003.007
`
`

`

`Petition for Inter Partes Review of 9,055,104
`Ex.1003 (“Horst Decl.”)
`
`U.S.C. § 102(b) if the invention was patented or published anywhere more than
`
`one year prior to the first effective filing date of the patent application (critical
`
`date). I further have been informed that a claim is invalid under 35 U.S.C.
`
`§ 102(e) if an invention described by that claim was disclosed in a U.S. patent
`
`granted on an application for a patent by another that was filed in the U.S. before
`
`the date of invention for such a claim.
`
`B. Invalidity by Obviousness
`
`16.
`
`I have been informed that a patent claim is invalid as obvious under
`
`35 U.S.C. § 103 if it would have been obvious to a person of ordinary skill in the
`
`art, taking into account (1) the scope and content of the prior art, (2) the differences
`
`between the prior art and the claims, (3) the level of ordinary skill in the art, and
`
`(4) any so called “secondary considerations” of non-obviousness, which include:
`
`(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 April 22,
`
`2002 for claims 1, 6, 9, 12, and 15 of the 104 Patent. Accordingly, my analysis of
`
`the prior art for the claims of the 104 Patent is based on the prior art and
`
`knowledge of a person having ordinary skill in the art (“POSA”) as of that date.
`
`5
`
`DELL Ex.1003.008
`
`

`

`Petition for Inter Partes Review of 9,055,104
`Ex.1003 (“Horst Decl.”)
`
`I have been informed that a claim can be obvious in light of a single
`
`17.
`
`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;
`
`(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.
`
`6
`
`DELL Ex.1003.009
`
`

`

`Petition for Inter Partes Review of 9,055,104
`Ex.1003 (“Horst Decl.”)
`
`
`IV. LEVEL OF ORDINARY SKILL IN THE ART
`
`18.
`
`I have been informed that factors that may be considered in
`
`determining the level of ordinary skill in the art may include: (A) “type of
`
`problems encountered in the art;” (B) “prior art solutions to those problems;”
`
`(C) “rapidity with which innovations are made;” (D) “sophistication of the
`
`technology;” and (E) “educational level of active workers in the field.” I also
`
`understand that every factor may not be present for a given case, and one or more
`
`factors may predominate. In my experience, systems such as those described in the
`
`104 Patent 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.
`
`7
`
`DELL Ex.1003.010
`
`

`

`Petition for Inter Partes Review of 9,055,104
`Ex.1003 (“Horst Decl.”)
`
`20. The statements that I make in this declaration when I refer to a POSA
`
`are from the perspective of April 22, 2002.
`
`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.
`
`(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
`
`8
`
`DELL Ex.1003.011
`
`

`

`Petition for Inter Partes Review of 9,055,104
`Ex.1003 (“Horst Decl.”)
`
`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). 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.
`
`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 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 9,055,104
`Ex.1003 (“Horst Decl.”)
`
`
`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
`
`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
`
`
`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 9,055,104
`Ex.1003 (“Horst Decl.”)
`
`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.
`
`27. TCP/IP consists of two parts: (1) Transmission Control Protocol
`
`(TCP), which provides virtual bi-directional connections between programs
`
`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
`
`28. 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
`
`
`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 9,055,104
`Ex.1003 (“Horst Decl.”)
`
`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.
`
`
`
`12
`
`DELL Ex.1003.015
`
`

`

`Petition for Inter Partes Review of 9,055,104
`Ex.1003 (“Horst Decl.”)
`
`
`Ex.1008, Stevens1 at .034, Fig. 1.7.
`
`(2)
`
`Ethernet Header
`
`29. 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, Fig. 4.8.
`
`30.
`
` 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
`
`DELL Ex.1003.016
`
`

`

`Petition for Inter Partes Review of 9,055,104
`Ex.1003 (“Horst Decl.”)
`
`
`(3)
`
`IP Header
`
`
`
`Ex.1008, Stevens1 at .058, Fig. 3.1.
`
`31. 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
`
`DELL Ex.1003.017
`
`

`

`Petition for Inter Partes Review of 9,055,104
`Ex.1003 (“Horst Decl.”)
`
`
`(4)
`
`TCP header
`
`
`
` Ex.1008, Stevens1, at .249, Fig.17.2.
`
`32. 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:
`
`15
`
`DELL Ex.1003.018
`
`

`

`Petition for Inter Partes Review of 9,055,104
`Ex.1003 (“Horst Decl.”)
`
`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
`
`33. 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 in that timeframe.
`
`(6)
`
`Sockets
`
`34. 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-
`
`derived programming interface (Section 1.15). It is the socket pair (the
`
`4-tuple consisting of the client IP address, client port number, server
`
`16
`
`DELL Ex.1003.019
`
`

`

`Petition for Inter Partes Review of 9,055,104
`Ex.1003 (“Horst Decl.”)
`
`
`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.
`
`35. 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
`
`the address used does not matter to the server. The CONNECT
`
`primitive blocks the caller and actively starts the connection process.
`
`17
`
`DELL Ex.1003.020
`
`

`

`Petition for Inter Partes Review of 9,055,104
`Ex.1003 (“Horst Decl.”)
`
`
`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.
`
`36. 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
`
`DELL Ex.1003.021
`
`

`

`Petition for Inter Partes Review of 9,055,104
`Ex.1003 (“Horst Decl.”)
`
`
`(7)
`
`Windows Sockets
`
`37. The Microsoft Windows environment also supported sockets with a
`
`programming interface known as WinSock. The WinSock 2 API manual
`
`documents
`
`the application programming
`
`interface
`
`(API)
`
`for Windows
`
`environments such as Windows NT and Windows 95.
`
`Windows Sockets 2 utilizes the sockets paradigm as first popularized
`
`in BSD UNIX1 and as adapted for Microsoft Windows in the
`
`Windows Sockets 1.1 specification.
`
`Ex.1050, WinSock2 at .009.
`
`38. Following is a diagram illustrating how WinSock 1.1 and WinSock 2
`
`applications were run in a layer above TCP/IP.
`
`Ex.1050, WinSock2 at .016, Fig. 2.
`
`
`
`
`
`19
`
`DELL Ex.1003.022
`
`

`

`Petition for Inter Partes Review of 9,055,104
`Ex.1003 (“Horst Decl.”)
`
`
`
`
`39. WinSock 2 includes Berkeley-style routines (socket(), bind(), listen(),
`
`accept(), send(), rcv(),…) as well as Windows versions of those and other socket
`
`routines. Ex.1050, Winsock2 at .041-.042. To create a reliable connection-
`
`oriented socket running over TCP/IP, socket() is called with a type field set to
`
`SOCK_STREAM:
`
`Connection-oriented sockets such as SOCK_STREAM provide full-
`
`duplex connections, and must be in a connected state before any data
`
`may be sent or received on it. A connection to another socket is
`
`created with a connect() call. Once connected, data may be transferred
`
`using send() and recv() calls. When a session has been completed, a
`
`closesocket() must be performed.
`
`The communications protocols used
`
`to
`
`implement a reliable,
`
`connection-oriented socket ensure that data is not lost or duplicated. If
`
`data for which the peer protocol has buffer space cannot be
`
`successfully transmitted within a reasonable length of time, the
`
`connection is considered broken and subsequent calls will fail with the
`
`error code set to WSAETIMEDOUT.
`
`Ex.1050, Winsock2 at .092-.093.
`
`40. The reliable socket connections created in this way guaranteed that
`
`data would be reliably transmitted. If something prevented the delivery within a
`
`reasonable length of time, the higher layer software was notified and given an
`
`opportunity to retry the operation.
`
`20
`
`DELL Ex.1003.023
`
`

`

`Petition for Inter Partes Review of 9,055,104
`Ex.1003 (“Horst Decl.”)
`
`41. When a socket is closed by a Windows application, the shutdown is
`
`delayed until all data has either successfully reached the destination or has timed
`
`out with an error. In the example below, the FD_CLOSE indication from the client
`
`rec() is an indication to the application (running in a layer above TCP) that all data
`
`has been delivered. This indication shows that the close succeeds only after the
`
`last acknowledgement has been received for the final pending send operation.
`
`One technique that can be used to minimize the chance of problems
`
`occurring during connection teardown is to not rely on an implicit
`
`shutdown being initiated by closesocket(). Instead one of the two
`
`explicit shutdown functions ( shutdown() or WSASendDisconnect() )
`
`are used. This in turn will cause an FD_CLOSE indication to be
`
`received by the peer application indicating that all pending data has
`
`been received. To illustrate this, the following table shows the
`
`functions that would be invoked by the client and server components
`
`of an application, where the client is responsible for initiating a
`
`graceful shutdown.
`
`Ex.1050, WinSock2 at .038.4
`
`
`4 All emphasis herein added unless otherwise noted.
`
`21
`
`DELL Ex.1003.024
`
`

`

`Petition for Inter Partes Review of 9,055,104
`Ex.1003 (“Horst Decl.”)
`
`
`Ex.1050, WinSock2 at .039.
`
`(8)
`
`Prepending Headers
`
`
`
`42. 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, Fig. 1.8.
`
`
`
`22
`
`DELL Ex.1003.025
`
`

`

`Petition for Inter Partes Review of 9,055,104
`Ex.1003 (“Horst Decl.”)
`
`43. 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 a