`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`______________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`______________________
`
`
`DELL INC.
`Petitioner
`
`v.
`
`ALACRITECH, INC.
`Patent Owner
`
`________________________
`
`
`Inter Partes Review No. IPR2018-00336
`U.S. Patent No. 7,124,205
`Title: NETWORK INTERFACE DEVICE THAT FAST-PATH PROCESSES
`SOLICITED SESSION LAYER READ COMMANDS
`
`________________________
`
`DECLARATION OF BILL LIN IN SUPPORT OF PETITION
`FOR INTER PARTES REVIEW OF
`U.S. PATENT NO. 7,124,205
`UNDER 37 C.F.R. § 1.68
`
`
`
`
`Mail Stop “PATENT BOARD”
`Patent Trial and Appeal Board
`U.S. Patent and Trademark Office
`P.O. Box 1450
`Alexandria, VA 22313-1450
`
`
`
`DELL Ex.1003.001
`
`
`
`Petition for Inter Partes Review of 7,124,205
`Ex. 1003 (“Lin Decl.”)
`
`TABLE OF CONTENTS
`
`
`
`Page
`
`INTRODUCTION AND QUALIFICATIONS ............................................... 1
`
`
`
`I.
`
`II. MATERIALS RELIED ON IN FORMING MY OPINION........................... 3
`
`III. UNDERSTANDING OF THE GOVERNING LAW ..................................... 3
`
`A. Anticipation ........................................................................................... 3
`
`B.
`
`Invalidity by Obviousness ..................................................................... 4
`
`IV. LEVEL OF ORDINARY SKILL IN THE ART ............................................. 6
`
`V. OVERVIEW OF THE TECHNOLOGY ......................................................... 7
`
`A.
`
`B.
`
`Layered Network Protocols ................................................................... 8
`
`Offloading Protocol Processing ..........................................................11
`
`1.
`
`2.
`
`3.
`
`4.
`
`5.
`
`Offloaded Protocols ..................................................................14
`
`Portions of the Protocol Offloaded ...........................................15
`
`Partial Offload and Fast Paths...................................................16
`
`Offload Implementation ............................................................19
`
`Protocol Offload Summary .......................................................22
`
`C.
`
`Additional Background Technologies for Protocol
`Offloading ...........................................................................................22
`
`1.
`
`2.
`
`DMA .........................................................................................22
`
`Interrupts ...................................................................................24
`
`D.
`
`Block-Level Storage Area Networks ..................................................25
`
`VI. OVERVIEW OF THE 205 PATENT ............................................................28
`
`VII. 205 PATENT PROSECUTION HISTORY ..................................................33
`
`VIII. CLAIM CONSTRUCTIONS ........................................................................34
`
`A.
`
`Legal Standard .....................................................................................34
`
`IX. THE PRIOR ART ..........................................................................................35
`
`A.
`
`B.
`
`C.
`
`Thia ......................................................................................................35
`
`Satran ...................................................................................................40
`
`Carmichael ...........................................................................................42
`ii
`
`
`
`DELL Ex.1003.002
`
`
`
`Petition for Inter Partes Review of 7,124,205
`Ex. 1003 (“Lin Decl.”)
`
`
`X. OBVIOUSNESS COMBINATIONS – MOTIVATIONS TO
`COMBINE .....................................................................................................43
`
`A.
`
`B.
`
`Thia in Combination with Satran ........................................................43
`
`Thia in Combination with Satran and Carmichael ..............................46
`
`XI. GROUNDS OF INVALIDITY .....................................................................49
`
`
`
`
`
`
`
`ii
`
`DELL Ex.1003.003
`
`
`
`
`
`
`
`
`I, Bill Lin, hereby declare as follows:
`
`I.
`
`INTRODUCTION AND QUALIFICATIONS
`
`1. My name is Bill Lin. I have been retained on behalf of Petitioner Dell
`
`Inc. (“Dell” or “Petitioner”) to provide this Declaration concerning technical
`
`subject matter relevant to the petition for inter partes review (“Petition”)
`
`concerning U.S. Patent No. 7,124,205 (Ex.1001, “the 205 Patent”). I previously
`
`offered a substantially identical declaration in connection with Case Nos. IPR2017-
`
`01405 (by Intel Corporation) and IPR2017-01735 (by Cavium, Inc.). I reserve the
`
`right to supplement this Declaration in response to additional evidence that may
`
`come to light.
`
`2.
`
`I am over 18 years of age. I have personal knowledge of the facts
`
`stated in this Declaration and could testify competently to them if asked to do so.
`
`3. My compensation is not based on the resolution of this matter. My
`
`findings are based on my education, experience, and background in the fields
`
`discussed below.
`
`4.
`
`I am a Professor of Electrical and Computer Engineering and an
`
`Adjunct Professor of Computer Science and Engineering at the University of
`
`California, San Diego (UCSD). I have over 25 years of experience in research
`
`and development in the areas of computer networking and computer design. I
`
`
`
`
`
`DELL Ex.1003.004
`
`
`
`Petition for Inter Partes Review of 7,124,205
`Ex.1003 (“Lin Decl.”)
`
`
`
`
`have also testified as an expert witness and consultant in patent and intellectual
`
`property litigations as well as inter partes reviews.
`
`5.
`
`I received a Bachelor of Science in Electrical Engineering and
`
`Computer Sciences from University of California, Berkeley in May 1985; a
`
`Master’s of Science in Electrical Engineering and Computer Sciences from the
`
`University of California, Berkeley in May 1988; and a Ph.D. in Electrical
`
`Engineering and Computer Sciences from the University of California, Berkeley
`
`in May 1991.
`
`6.
`
`I am a named inventor on five patents in the fields of computer
`
`networking and computer design, and I have published over 170 journal articles
`
`and conference papers in top-tier venues and publications.
`
`7.
`
`I have also served or am currently serving as Associate Editor or
`
`Guest Editor for 3 ACM or IEEE journals, as General Chair on 4 ACM or IEEE
`
`conferences, on the Organizing or Steering Committees for 6 ACM or IEEE
`
`conferences, and on the Technical Program Committees of over 44 ACM or
`
`IEEE conferences.
`
`8. 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.
`
`
`
`2
`
`DELL Ex.1003.005
`
`
`
`Petition for Inter Partes Review of 7,124,205
`Ex.1003 (“Lin Decl.”)
`
`
`
`II. MATERIALS RELIED ON IN FORMING MY OPINION
`
`9.
`
`In addition to reviewing U.S. Patent No. 7,124,205, I also reviewed
`
`and considered the prosecution history of the 205 Patent (Ex.1002). I reviewed all
`
`of the references forming the grounds of these Petitions. Specifically, for the 205
`
`Patent, Thia (Ex.1015), SMB (Ex.1055), SatranI (Ex.1056), SatranII (Ex.1057),
`
`and Carmichael (Ex.1053). I also considered the background materials cited
`
`herein.
`
`III. UNDERSTANDING OF THE GOVERNING LAW
`
`10.
`
`I understand that a patent claim is invalid if it is anticipated or obvious
`
`in view of the prior art. I further understand that invalidity of a 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. Anticipation
`
`11.
`
`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.
`
`12.
`
`I have been informed that a claim is invalid under 35 U.S.C. § 102(a)
`
`if the claimed invention was known or used by others in the U.S., or 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
`3
`
`
`
`DELL Ex.1003.006
`
`
`
`Petition for Inter Partes Review of 7,124,205
`Ex.1003 (“Lin Decl.”)
`
`
`
`patented or published anywhere, or was in public use, on sale, or offered for sale in
`
`this country, more than one year prior to the 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
`
`13.
`
`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 one 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. My
`
`analysis of the prior art is made as of the time the invention was made.
`
`
`
`4
`
`DELL Ex.1003.007
`
`
`
`Petition for Inter Partes Review of 7,124,205
`Ex.1003 (“Lin Decl.”)
`
`
`
`
`14.
`
`I have been informed that a claim can be obvious in light of a single
`
`prior art reference or multiple prior art references. I further understand that
`
`exemplary rationales that may support a conclusion of obviousness include:
`
`(A) Combining prior art elements according to known methods to yield
`
`predictable results;
`
`(B) Simple substitution of one known element for another to obtain
`
`predictable results;
`
`(C) Use of known technique to improve similar devices (methods, or
`
`products) in the same way;
`
`(D) Applying a known technique to a known device (method, or product)
`
`ready for improvement to yield predictable results;
`
`(E) “Obvious to try” – choosing from a finite number of identified,
`
`predictable solutions, with a reasonable expectation of success;
`
`(F) Known work in one field of endeavor may prompt variations of it for use
`
`in either the same field or a different one based on design incentives or other
`
`market forces if the variations are predictable to one of ordinary skill in the art;
`
`(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.
`
`
`
`5
`
`DELL Ex.1003.008
`
`
`
`Petition for Inter Partes Review of 7,124,205
`Ex.1003 (“Lin Decl.”)
`
`
`
`IV. LEVEL OF ORDINARY SKILL IN THE ART
`
`15.
`
`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 205 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.
`
`16.
`
`In my opinion, a person of ordinary skill in the art at the time of the
`
`claimed inventions would be 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
`
`
`
`6
`
`DELL Ex.1003.009
`
`
`
`Petition for Inter Partes Review of 7,124,205
`Ex.1003 (“Lin Decl.”)
`
`
`
`development. An individual with an advanced degree in a relevant field, such as
`
`computer or electrical engineering, would require less experience in the
`
`development and use of memory devices and systems.
`
`17.
`
`I reserve the right to amend or supplement this declaration if the
`
`Board adopts a definition of a person of ordinary skill other than that described
`
`above, which may change my conclusion or analysis. But should the Board adopt
`
`a higher standard, it would not change my opinion that the claims are invalid.
`
`18. My opinion below explains how a person of ordinary skill in the art
`
`would have understood the technology described in the references I have identified
`
`herein around the 1997 time period, which is the approximate date when the
`
`application to which the 205 Patent claims priority was filed. I was a person of at
`
`least ordinary skill in the art in 1997.
`
`V. OVERVIEW OF THE TECHNOLOGY
`
`19. Along with the 205 Patent, Petitioner has also filed for Inter Partes
`
`Review of U.S. Patent Nos. 7,673,072, 7,237,036, 7,337,241, and 8,805,948
`
`(“Related Patents”). These patents belong to the same family as the 205 Patent
`
`and are directed to substantially the same technology. Dr. Horst has provided
`
`declarations in support of the petitions for IPR for the Related Patents, and, as
`
`part of those declarations, Dr. Horst prepared an overview of the technology. I
`
`
`
`7
`
`DELL Ex.1003.010
`
`
`
`Petition for Inter Partes Review of 7,124,205
`Ex.1003 (“Lin Decl.”)
`
`
`
`
`have reviewed this overview and I have adopted and incorporated (with his
`
`permission) language from his overview into my declaration.1
`
`A. Layered Network Protocols
`
`20. Computer networks based on layered protocol architectures have been
`
`well-known since at least the 1980s. As explained in Dr. Horst’s Declaration (see
`
`¶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.
`
`21. As explained in Dr. Horst’s Declaration (see ¶¶23-24), the two most
`
`dominant models of protocol layers are the OSI model and the TCP/IP model.2
`
`
`1 Note that I did not review any other sections of Dr. Horst’s declaration. Nor did I
`
`assist Dr. Horst with his declaration (and vice versa).
`
`2 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 and
`
`the “interface layer” in Stevens2. 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
`
`DELL Ex.1003.011
`
`
`
`Petition for Inter Partes Review of 7,124,205
`Ex.1003 (“Lin Decl.”)
`
`
`
`The OSI model defines a seven-layer protocol stack whereas the TCP/IP model
`
`defines a simpler four-layer protocol stack. The OSI model includes physical, data
`
`link, network, transport, session, presentation and application layers. The figure
`
`below shows the relationship between the OSI layering and the TCP/IP layering.
`
`
`
`Available at http://mitigationlog.com/how-tcpip-and-reference-osi-model-works/.
`
`22. As explained in Dr. Horst’s Declaration (see ¶25), at a conceptual
`
`level, each layer is responsible for 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
`
`
`
`9
`
`DELL Ex.1003.012
`
`
`
`Petition for Inter Partes Review of 7,124,205
`Ex.1003 (“Lin Decl.”)
`
`
`
`the data belongs to or how the user data has been partitioned into individual
`
`packets.
`
`23.
`
`In the figure above, the bottom “host-to-network” layer of the TCP/IP
`
`model has roughly the same functions as the “data link” and “physical” layers of
`
`the OSI reference model. The next two layers up, the “transport” and “Internet”
`
`layers have roughly the same functions as their similarly named counterparts in the
`
`OSI model (namely, the “transport” and “network” layers).
`
`24.
`
`In the TCP/IP model, the “network” (Internet) layer is called the
`
`“Internet Protocol” (IP) layer, which provides for Internet addressing and routing
`
`functions. The “transport” layer is concerned with conveying a message from one
`
`application to another over a network. The two most widely used transport
`
`protocols are TCP and UDP, either of which can be used to transport application-
`
`layer messages. Whereas TCP provides a connection-oriented service to its
`
`applications that includes guaranteed delivery and congestion control, UDP
`
`provides a simpler connectionless service that does not provide for reliability or
`
`flow control.
`
`25. Above the “transport” and “network” layers, the OSI reference model
`
`has two additional layers, the session and presentation layers. The session layer
`
`controls the connections between computers, and the presentation layer establishes
`
`
`
`10
`
`DELL Ex.1003.013
`
`
`
`Petition for Inter Partes Review of 7,124,205
`Ex.1003 (“Lin Decl.”)
`
`
`
`context between application-layer entities. These two layers are not present in the
`
`TCP/IP model.
`
`B. Offloading Protocol Processing
`
`26. The idea of offloading protocol processing from the host in order to
`
`increase performance was known at least as early as 1974, as shown by RFC 647
`
`(Ex.1019) and RFC 929 (Ex.1009). In RFC 647, front-end protocol offload was
`
`considered for standardization. RFC 647 also discusses rigid and flexible front-
`
`end (FE) alternatives.
`
` “FRONT-ENDING”
`
`In what might be thought of as the greater network community, the
`
`consensus is so broad that the front-ending is desirable that the topic
`
`needs almost no discussion here. Basically, a small machine (a PDP-
`
`11 is widely held to be most suitable) is interposed between the IMP
`
`and the host in order to shield the host from the complexities of the
`
`NCP.
`
`Ex.1019, RFC 647 at .002.
`
`27. Similarly, RFC 929 dealt with a possible standard for interfacing
`
`between an Outboard Processing Environment (OPE) and a host.
`
`There are
`
`two
`
`fundamental motivations
`
`for doing outboard
`
`processing. One is to conserve the Hosts' resources (CPU cycles and
`
`memory) in a resource sharing intercomputer network, by offloading
`
`
`
`11
`
`DELL Ex.1003.014
`
`
`
`Petition for Inter Partes Review of 7,124,205
`Ex.1003 (“Lin Decl.”)
`
`
`
`
`as much of the required networking software from the Hosts to
`
`Outboard Processing Environments (or "Network Front-Ends") as
`
`possible. The other is to facilitate procurement of implementations of
`
`the various intercomputer networking protocols for the several types
`
`of Host in play in a typical heterogeneous intercomputer network, by
`
`employing common implementations in the OPE.
`
`Ex.1009, RFC 929 at .002.
`
`The interaction between the Host and the OPE must be capable of
`
`providing a suitable
`
`interface between processes (or protocol
`
`interpreters) in the Host and the off-loaded protocol interpreters in the
`
`OPE. This interaction must not, however, burden the Host more
`
`heavily than would have resulted from supporting the protocols
`
`inboard, lest the advantage of using an OPE be overridden.
`
`Id. at .003.
`
`28. The 1984 proposal to standardize offload implementations in RFC
`
`929 is evidence that there was already much activity in offload implementations at
`
`that time.
`
`The mediation level parameter is an indication of the role the Host
`
`wishes the OPE to play in the operation of the protocol. The extreme
`
`ranges of this mediation would be the case where the Host wished to
`
`remain completely uninvolved, and the case where the Host wished to
`
`make every possible decision. The specific interpretation of this
`
`parameter is dependent upon the particular off-loaded protocol.
`
`
`
`12
`
`DELL Ex.1003.015
`
`
`
`Petition for Inter Partes Review of 7,124,205
`Ex.1003 (“Lin Decl.”)
`
`
`
`
`
`
`The concept of mediation level can best be clarified by means of
`
`example. A full inboard implementation of the Telnet protocol places
`
`several responsibilities on the Host. These responsibilities include
`
`negotiation and provision of protocol options, translation between
`
`local and network character codes and formats, and monitoring the
`
`well-known socket for incoming connection requests. The mediation
`
`level indicates whether these responsibilities are assigned to the Host
`
`or to the OPE when the Telnet implementation is outboard. If no OPE
`
`mediation is selected, the Host is involved with all negotiation of the
`
`Telnet options, and all format conversions.
`
`
`
`With full OPE mediation, all option negotiation and all format
`
`conversions are performed by the OPE. An intermediate level of
`
`mediation might have ordinary option negotiation, format conversion,
`
`and socket monitoring done in the OPE, while options not known to
`
`the OPE are handled by the Host.
`
`
`
`The parameter is represented with a single ASCII digit. The value 9
`
`represents full OPE mediation, and the value 0 represents no OPE
`
`mediation. Other values may be defined for some protocols (e.g., the
`
`intermediate mediation level discussed above for Telnet). The default
`
`value for this parameter is 9.
`
`
`Ex.1009, RFC 929 at .015-.016.
`
`
`
`
`13
`
`DELL Ex.1003.016
`
`
`
`Petition for Inter Partes Review of 7,124,205
`Ex.1003 (“Lin Decl.”)
`
`
`
`
`29. More than a decade passed between the publication of RFC 929 and
`
`the priority date of the earliest Alacritech provisional application, and during that
`
`time, protocol offload was the subject of many papers and systems of the typed
`
`anticipated by RFC 929. As explained in Dr. Horst’s declaration (see ¶54) the
`
`implementations can be separated into three general categories: The set of
`
`protocols to be offloaded (e.g., TCP/IP, VMTP, OSI), 2) the portions of the
`
`protocol that are offloaded (e.g. full offload, partial offload, fast path offload, no
`
`offload), 3) the offload implementation (e.g., parallel processor, custom processor,
`
`standard microprocessor). The references discussed below include many different
`
`combinations of these three factors. However, all of the combinations discussed
`
`were the result of design choices from a small number of options. It would have
`
`been obvious to modify one of the three factors of the particular implementation
`
`and produce predictable results. Or to put it differently, those of skill in the art
`
`would have recognized that the extent of offloading could be changed for a given
`
`implementation.
`
`1. Offloaded Protocols
`
`30. As explained in Dr. Horst’s Declaration (see ¶¶ 55-60), protocol
`
`offload implementations for different protocol stacks were known by the mid-
`
`1990s. These included OSI protocol offload (for example, Thia (Ex.1015) and
`
`
`
`14
`
`DELL Ex.1003.017
`
`
`
`Petition for Inter Partes Review of 7,124,205
`Ex.1003 (“Lin Decl.”)
`
`
`
`Woodside (Ex.1038)), TCP/IP protocol offload (for example, Bach (Ex.1020),
`
`Erickson (Ex.1005), Morris (Ex.1021), Cooper (Ex.1022), Kung (Ex.1023),
`
`Rütsche (Ex.1017) and Chesson (Ex.1024)), VMTP and XTP Protocol Offload (for
`
`example, Kanakia (Ex.1025), Chesson (Ex.1024)), and multi-protocol offload (for
`
`example, Erickson (Ex.1005) and Kung and Cooper (Ex.1026)).
`
`2.
`
`Portions of the Protocol Offloaded
`
`31. As explained in Dr. Horst’s Declaration (see ¶61), the portion of the
`
`protocol offloaded can be between full and partial offload.
`
`32. As explained in Dr. Horst’s Declaration (see ¶¶62-63), one type of
`
`offload is checksum offload.
`
`33. A checksum offload is described, for example, in Dalton Afterburner.
`
`To support the use of the on-card memory as clusters, we have written
`
`a small number of functions. The most important is a special copy
`
`routine, functionally equivalent to the BSD function bcopy. It is
`
`optimized for moving data over the I/O bus, and also optionally uses
`
`the card’s built-in unit to calculate the IP checksum of the data it
`
`moves. Another function converts a single-copy cluster into a chain of
`
`normal clusters and mbufs; it also calculates the checksum.
`
`
`
`15
`
`DELL Ex.1003.018
`
`
`
`Petition for Inter Partes Review of 7,124,205
`Ex.1003 (“Lin Decl.”)
`
`
`
`Ex.1027, Dalton at .011.3
`
`34. As explained in Dr. Horst’s Declaration (see ¶¶64-65), other types of
`
`offloads included full offload (for example, Murphy (Ex.1028), Bach (Ex.1020),
`
`MacLean (Ex.1029), Cooper (Ex.1022), Rütsche92 (Ex.1017), Rütsche93
`
`(Ex.1018) and multi-level offload (for example, Chesson (Ex.1024)).
`
`3.
`
`Partial Offload and Fast Paths
`
`35. The performance of TCP/IP, or for that matter most communication
`
`protocols, can be improved by adapting the header prediction algorithm that was
`
`proposed in 1988 by Van Jacobson, which led to many different types of partial
`
`offloads, including a TCP/IP implementation (i.e., BSD 4.3 Reno) in which the
`
`code is partitioned into one module for the commonly executed path (the fast path)
`
`and another module to handle the more complex cases and exception handling (the
`
`slow path).
`
`36. For example the BSD 4.4-Lite distribution included code for
`
`implementing the header prediction algorithm.
`
`Most IP packets carry no options. Of the 20-byte header, 14 of the
`
`bytes will be the same for all IP packets sent by a particular TCP
`
`connection. The IP length, ID, and checksum fields (6 bytes total) will
`
`3 Emphasis added unless otherwise noted.
`
`
`
`16
`
`DELL Ex.1003.019
`
`
`
`Petition for Inter Partes Review of 7,124,205
`Ex.1003 (“Lin Decl.”)
`
`
`
`
`
`
`probably be different for each packet. Also, if a packet carries any
`
`options, all packets for that TCP connection will be likely to carry the
`
`same options.
`
`The Berkeley implementation of UNIX makes some use of this
`
`observation, associating with each connection a template of the IP and
`
`TCP headers with a few of the fixed fields filled in. To get better
`
`performance, we designed an IP layer that created a template with all
`
`the constant fields filled in. When TCP wished to send a packet on
`
`that connection, it would call IP and pass it the template and the
`
`length of the packet. Then IP would block-copy the template into the
`
`space for the IP header, fill in the length field, fill in the unique ID
`
`field, and calculate the IP header checksum.
`
`This idea can also be used with TCP, as was demonstrated in an
`
`earlier, very simple TCP implemented by some of us at MIT [6]. In
`
`that TCP, which was designed to support remote login, the entire state
`
`of the output side, including the unsent data, was stored as a
`
`preformatted output packet. This reduced the cost of sending a packet
`
`to a few lines of code.
`
`A more sophisticated example of header prediction involves applying
`
`the idea to the input side. In the most recent version of TCP for
`
`Berkeley UNIX, one of us (Jacobson) and Mike Karels have added
`
`code to precompute what values should be found in the next incoming
`
`packet header for the connection. If the packets arrive in order, a few
`
`simple comparisons suffice to complete header processing.
`
`17
`
`DELL Ex.1003.020
`
`
`
`Petition for Inter Partes Review of 7,124,205
`Ex.1003 (“Lin Decl.”)
`
`
`
`Ex.1030, Clark at .003.
`
`37. As explained in Dr. Horst’s Declaration (see ¶¶68-69), the 1995 book
`
`by Stevens (Stevens2) walks through the Jacobson BSD header prediction code
`
`including the conditions for selecting the fast or slow path.
`
`38. Stevens2 identifies six conditions for using the fast path:
`
`1. The connection must be established.
`
`2. The following four control flags must not be on: SYN, FIN, RST,
`
`or URG. The ACK flag must be on.
`
`3.-6. [Conditions to assure that the received segments are in-order]
`
`
`Ex.1013, Stevens2 at .962-.963.
`
`39. Many other works built on the Jacobson BSD header prediction code,
`
`such as Biersack (Ex.1016), which describes a TCP protocol offload with fast and
`
`slow paths, as well as Thia (Ex.1015), which built on Jacobson BSD header
`
`prediction algorithm by implementing a fast path using an OSI protocol offload.
`
`40. As explained in Dr. Horst’s Declaration (see ¶¶70-71), the Jacobson
`
`header prediction code forms the basis of what Alacritech offloads to its intelligent
`
`network interface card according to its 1997 provisional application. See also
`
`Ex.1031, Alacritech 1997 Provisional Application at .057.
`
`
`
`18
`
`DELL Ex.1003.021
`
`
`
`Petition for Inter Partes Review of 7,124,205
`Ex.1003 (“Lin Decl.”)
`
`
`
`
`4. Offload Implementation
`
`41. As explained in Dr. Horst’s Declaration (see ¶¶72-73), offload
`
`implementations include dedicating one or more processors to protocol processing.
`
`For example, Tanenbaum96 discussed offloading to an interface card.
`
`The hardware and/or software within the transport layer that does the
`
`work is called the transport entity. The transport entity can be in the
`
`operating system kernel, in a separate user process, in a library
`
`package bound into network applications, or on the network interface
`
`card.
`
`Ex.1006, Tanenbaum96 at .498.
`
`42. As explained in Dr. Horst’s Declaration (see ¶¶74-81), several groups
`
`proposed offload implementations based on multiprocessor configurations or
`
`dedicated microprocessor implementations, including the Nectar system, the
`
`parallel protocol system, and a Gb/s Multimedia Protocol Adapter, as well as
`
`offload adapters based on microprocessors, as discussed in Kanakia (Ex.1025),
`
`MacLean (Ex.1029), and Rütsche92 (Ex.1017).
`
`The Nectar communication processor together with its host can be
`
`viewed as a
`
`(heterogeneous)
`
`shared-memory multiprocessor.
`
`Dedicating one processor of a multiprocessor host to communication
`
`tasks can achieve some of the benefits of the Nectar approach, but this
`
`constrains the choice of host operating system and hardware. In
`
`
`
`19
`
`DELL Ex.1003.022
`
`
`
`Petition for Inter Partes Review of 7,124,205
`Ex.1003 (“Lin Decl.”)
`
`
`
`
`contrast, the Nectar communication processor has been used with a
`
`variety of hosts and host operating systems.
`
`Ex.1022, Cooper at .006.
`
`In this paper our goal is to demonstrate that a careful implementation
`
`of a standard transport protocol stack on a general purpose
`
`multiprocessor architecture allows efficient use of the bandwidth
`
`available in today's high-speed networks. As an example, we chose to
`
`implement the TCP/IP protocol suite on our 4-processor prototype of
`
`the PPE.
`
`Ex.1017, Rütsche92 at .009.
`
`In this paper we present a new multiprocessor communication
`
`subsystem architecture, the Multimedia Protocol Adapter (MPA),
`
`which is based on the experience with the Parallel Protocol Engine
`
`(PPE) [Kaiserswerth 92] and is designed to connect to a 622 Mb/s
`
`ATM network. The MPA architecture exploits
`
`the
`
`inherent
`
`parallelism between the transmitter and receiver parts of a protocol
`
`and provides support for the handling of new multimedia protocols.
`
`Ex.1018, Rütsche93 at .001.
`
`The prototype Network Adapter Board (NAB) has been designed
`
`using Motorola's MC68020 as the on-board processor, running at 16
`
`Mhz clock rate; it uses about 200 hundred standard MSI and LSI
`
`components. The current version is designed for connecting two VMP
`
`
`
`20
`
`DELL Ex.1003.023
`
`
`
`Petition for Inter Partes Review of 7,124,205
`Ex.1003 (“Lin Decl.”)
`
`
`
`
`multiprocessor systems with a 100 megabit/sec point-to-point
`
`connection.
`
`Ex.1025, Kanakia at .010.
`
`The internal functions and data flows of the protocol accelerator