`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`________________
`
`INTEL CORP. and CAVIUM, INC.,
`Petitioners,
`
`v.
`
`ALACRITECH, INC.,
`Patent Owner
`________________
`
`Case IPR2017-013911
`U.S. Patent No. 7,237,036
`________________
`
`
`
`
`
`PATENT OWNER’S RESPONSE
`PURSUANT TO 35 U.S.C. § 313 AND 37 C.F.R. § 42.107
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`1 Cavium, Inc., filed a Petition in Case IPR2017-01718, and has been
`
`joined as a petitioner in this proceeding.
`
`
`
`
`
`
`
`I.
`
`II.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
` Case No. IPR2017-01391
`U.S. Patent No. 7,237,036
`
`TABLE OF CONTENTS
`
`Page
`
`INTRODUCTION ........................................................................................... 1
`
`BACKGROUND OF THE RELEVANT TECHNOLOGY ........................... 2
`
`III. OVERVIEW OF THE ’036 PATENT ............................................................ 8
`
`A.
`
`B.
`
`The ’036 Patent Specification ............................................................... 8
`
`The ’036 Patent Claims ....................................................................... 14
`
`IV. OVERVIEW OF THE ASSERTED PRIOR ART ........................................ 16
`
`A. U.S. Patent No. 5,768,618 to Erickson et al. (“Erickson”) ................. 16
`
`B.
`
`Andrew S. Tanenbaum, Computer Networks, 3rd ed.
`(1996) (“Tanenbaum”) ........................................................................ 18
`
`V.
`
`CLAIM CONSTRUCTION .......................................................................... 21
`
`A.
`
`“context for communication” .............................................................. 21
`
`VI. LEVEL OF ORDINARY SKILL IN THE ART ........................................... 22
`
`VII. ERICKSON AND TANENBAUM DO NOT RENDER CLAIMS
`1-8 OBVIOUS ............................................................................................... 23
`
`A.
`
`There Is No Motivation to Combine Erickson and
`Tanenbaum .......................................................................................... 23
`
`1.
`
`2.
`
`3.
`
`4.
`
`5.
`
`6.
`
`Tanenbaum Expressly Teaches Away From a
`Combination Using Erickson .................................................... 23
`
`A POSITA Would Not Have Combined
`Tanenbaum With Erickson Because the Two
`References are Incompatible ..................................................... 27
`
`Tanenbaum Does Not Include an Express
`Motivation to Combine ............................................................. 30
`
`A POSITA Would Not Have Had an Expectation
`of Success in Combining Tanenbaum with
`Erickson .................................................................................... 31
`
`Petitioner Mischaracterizes Erickson as Being
`Similar to Tanenbaum ............................................................... 32
`
`The Complexity of the Subject Matter of Erickson
`and Tanenbaum Weighs Against Combining Them ................ 33
`
`
`
`ii
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
` Case No. IPR2017-01391
`U.S. Patent No. 7,237,036
`
`7.
`
`8.
`
`Petitioner’s Expert Agreed That Marketplace
`Demands Discouraged Offload ................................................. 36
`
`Contrary to Petitioner’s Assertions, Combining
`Erickson with Tanenbaum Would Have Increased
`Complexity, Rather Than Reduced It ....................................... 39
`
`(a) Complexity added by the window size,
`acknowledgement, and re-transmission
`inherent in TCP ............................................................... 40
`
`(b) Combining Erickson with Tanenbaum
`Would Result in Increased I/O Bus Access,
`Which is Contrary to the Goals of Erickson,
`and the Need For Additional Logic ................................ 42
`
`B.
`
`C.
`
`D.
`
`E.
`
`The Prior Art Fails to Disclose [1.2] “said
`communication processing mechanism containing a
`second processor” ................................................................................ 43
`
`The Prior Art Fails to Disclose [1.3] “[second processor]
`running instructions to process a message packet such
`that the context is employed to transfer data contained in
`said packet to the first apparatus memory” ......................................... 45
`
`The Prior Art Fails to Disclose [1.4] “the TCP State
`Information Is Updated by Said Second Processor” ........................... 46
`
`The Prior Art Fails to Disclose the Challenged
`Dependent Claims ............................................................................... 48
`
`1.
`
`“Receive Sequencer” ................................................................ 48
`
`VIII. THE STRONG EVIDENCE OF SECONDARY
`CONSIDERATIONS WEIGHS AGAINST OBVIOUSNESS .................... 49
`
`1.
`
`2.
`
`3.
`
`The Claimed Invention Addresses a Long-felt, Yet
`Unresolved Need in the Art for Accelerated
`Network Communications ........................................................ 49
`
`The Claimed Inventions Were Commercially
`Successful ................................................................................. 51
`
`The Claimed Invention Received Praise in the
`Industry ..................................................................................... 53
`
`
`
`iii
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
` Case No. IPR2017-01391
`U.S. Patent No. 7,237,036
`
`4. Many Others Tried and Failed to Develop the
`Claimed Technology ................................................................. 54
`
`5.
`
`Experts Were Skeptical of the Claimed Invention
`and Taught Away From It ......................................................... 54
`
`IX. THE BOARD SHOULD DENY THE PETITION BECAUSE
`IT FAILS TO DISCLOSE ALL REAL PARTIES IN
`INTEREST .................................................................................................... 56
`
`X. ALACRITECH RESERVES ITS RIGHTS UNDER THE
`PENDING OIL STATES CASE AT THE UNITED STATES
`SUPREME COURT ...................................................................................... 58
`
`XI. CONCLUSION ............................................................................................. 59
`
`
`
`
`
`iv
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
` Case No. IPR2017-01391
`U.S. Patent No. 7,237,036
`
`TABLE OF AUTHORITIES
`
`Page
`
`
`
`
`CasesCasesCases Cases
`Belden Inc. v. Berk–Tek LLC,
` 805 F.3d 1064 (Fed. Cir. 2015) ............................................................... 27
`CCS Fitness, Inc. v. Brunswick Corp.
`288, F.3d 1359 (Fed. Cir. 2002) ............................................................... 21
`Genetics Institute, LLC v. Novartis Vaccines and Diagnostics, Inc.,
` 655 F.3d 1291 (2011)............................................................................... 37
`KSR Int’l Co. v. Teleflex Inc.,
` 550 U.S. 398 (2007) ................................................................................. 32
`Personal Web Technologies, LLC v. Apple, Inc.,
` 848 F.3d 987 (Fed. Cir. 2017) ................................................................. 27
`United States v. Adams,
` 383 U.S. 39 (1966) ................................................................................... 31
`
`Statutory Authorities
`35 U.S.C. § 312(a)(2) .................................................................................... 56
`
`Rules and Regulations
`37 C.F.R. § 42.6(e) ....................................................................................... 62
`37 C.F.R. § 42.8(b)(1) .................................................................................. 56
`37 C.F.R. § 42.24 .......................................................................................... 61
`37 C.F.R. § 42.24(b) ..................................................................................... 61
`37 C.F.R. § 42.100(b) ................................................................................... 21
`
`
`
`
`
`
`
`
`
`
`v
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
` Case No. IPR2017-01391
`U.S. Patent No. 7,237,036
`
`
`
`
`
`PATENT OWNER’S LIST OF EXHIBITS
`
`Ex. 2001
`
`Not Used
`
`Ex. 2002
`
`Ex. 2003
`
`Ex. 2004
`
`Ex. 2005
`
`Intel Corporation’s Motion to Intervene, Case No. 2:16-
`cv-00693-JRG-RSP, Dkt. 71 (E.D. Tex., Oct. 31, 2016)
`
`Declaration of Christopher Kyriacou, Case No. 2:16-cv-
`00693-JRG-RSP, Dkt. 71-5 (E.D. Tex., Oct. 31, 2016)
`
`Jonathan Corbet; Alessandro Rubini; Greg Kroah-
`Hartman (2005), Linux Device Drivers, 3rd edition,
`Chapter 10, “Interrupt Handling”
`
`Defendant Dell Inc.’s First Supplemental Responses to
`Plaintiff’s Second Set of Common Interrogatories to
`Defendants and Intervenors (No. 11)
`
`Ex. 2006
`
`Not Used
`
`Ex. 2007
`
`Ex. 2008
`
`Declaration of Garland Stephens, Case No. 2:16-cv-
`00693-JRG-RSP, Dkt. 71-2 (E.D. Tex., Oct. 31, 2016)
`
`Excerpts of Declaration of Mr. Mark R. Lanning
`Regarding Claim Construction, Case No. 2:16-cv-00693-
`JRG-RSP, Dkt. 303-5 (E.D. Tex. Jul. 6, 2017)
`
`Ex. 2009
`
`Cavium’s Motion to Intervene, Case No. 2:16-cv-00693-
`JRG-RSP, Dkt. 109 (E.D. Tex., Jan. 13. 2017)
`
`Ex. 2010
`
`Not Used
`
`Ex. 2026
`
`Declaration of Kevin Almeroth, Ph.D. in Support of
`Patent Owner’s Response to the Petition
`
`Ex. 2027
`
`Curriculum Vitae of Kevin Almeroth, Ph.D.
`
`Ex. 2028
`
`Transcript from the Deposition of Robert Horst, Ph.D.
`dated January 25, 2018
`
`
`
`vi
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
` Case No. IPR2017-01391
`U.S. Patent No. 7,237,036
`
`Ex. 2029
`
`Ex. 2030
`
`Transcript from the Deposition of Robert Horst, Ph.D.
`dated January 26, 2018
`
`Memorandum Order and Opinion on Claim
`Construction, Case No. 2:16-cv-00693-RWS-RSP,
`Docket 362 (Filed September 21, 2017)
`
`Ex. 2031
`
`The Architecture of a Gb/s Multimedia Protocol Adapter
`
`Ex. 2032
`
`A Fast Track Architecture for UDP/IP and TCP/IP
`
`Ex. 2033
`
`A Communication Architecture for High-speed
`Networking
`
`Ex. 2034
`
`Server Network Scalability and TCP Offload
`
`Ex. 2035
`
`Alacritech and NetXen Join Forces to Deliver Solutions
`for Microsoft TCP Chimney Offload Technology
`
`Ex. 2036
`
`QLogic Licenses Alacritech
`
`Ex. 2037
`
`Neterion Licenses Alacritech’s Patents
`
`Ex. 2038
`
`Alacritech Licenses
`
`Ex. 2039
`
`Ex. 2040
`
`An Evaluation of an Attempt at Offloading TCP/IP
`Protocol Processing onto an i960RN-based iNIC
`
`Alacritech, Pioneer In Network Acceleration, Unveils
`Appliance To Alleviate Enterprise Storage Woes
`
`Ex. 2041
`
`TCP offload is a dumb idea whose time has come
`
`Ex. 2042
`
`TCP/IP Headers (https://nmap.org/book/tcpip-ref.html)
`
`Ex. 2043
`
`TCP/IP message processing
`(http://www.thegeekstuff.com/2011/11/tcp-ip-
`fundamentals/)
`
`Ex. 2300
`
`Horst Paper
`
`
`
`vii
`
`
`
`Case No. IPR2017-01391
`U.S. Patent No. 7,237,036
`
`
`
`I.
`
`INTRODUCTION
`
`Patent Owner Alacritech Inc. respectfully submits this Patent Owner
`
`Response. Petitioner Intel Corporation filed the Petition for Inter Partes Review of
`
`claims 1-7 of U.S. Patent No. 7,237,036, and the Board instituted proceedings on
`
`Ground 1 of the Petition.
`
`The Petition, however, fails to demonstrate that the challenged claims are
`
`unpatentable. First, one of ordinary skill in the art would never have combined the
`
`two cited references, Tanenbaum and Erickson. Tanenbaum expressly teaches
`
`away from the combination, a position echoed by Petitioner’s own expert in one of
`
`his publications. Other factors, including significant differences between the
`
`protocols (Tanenbaum uses TCP/IP while Erickson uses UDP) further weigh
`
`against this combination.
`
`Secondary considerations likewise weigh against Petitioner’s combination.
`
`Indeed, the claimed invention achieved significant commercial success, achieved
`
`praise in the industry, and was subject to high levels of skepticism and failure of
`
`others.
`
`Last, neither of the references on which Petitioner relies teaches key
`
`limitations of the challenged claims. None of the references, alone or in
`
`combination, discloses the claimed “second processor,” processing a message
`
`
`
`1
`
`
`
`Case No. IPR2017-01391
`U.S. Patent No. 7,237,036
`
`packet such that “the context is employed to transfer data,” or updating TCP
`
`information by the second processor.
`
`II. BACKGROUND OF THE RELEVANT TECHNOLOGY
`
`Both in 1997 and today, sending and receiving information over the Internet
`
`involves the use of many different protocols that set out the rules for how devices
`
`on the Internet can communicate with one another. (Ex. 2026, ¶ 59.) Multiple
`
`conceptual models exist for characterizing the interactions between these protocols
`
`in the context of the Internet and other telecommunication or computing systems.
`
`The Open Systems Interconnection model (or “OSI model”) is one well known
`
`example, describing a seven layer stack where a particular layer serves the layer
`
`above it and is served by the layers below it. Id. The seven layers of the OSI
`
`model are:
`
`Layer 7: Application Layer
`
`Layer 6: Presentation Layer
`
`Layer 5: Session Layer
`
`Layer 4: Transport Layer
`
`Layer 3: Network Layer
`
`Layer 2: Data Link Layer
`
`Layer 1: Physical Layer
`
`with layer 1 (the Physical Layer) being the lowest layer in the model. Id.
`
`
`
`2
`
`
`
`Case No. IPR2017-01391
`U.S. Patent No. 7,237,036
`
`
`
`The Internet Protocol (or “IP”) is an example of a well-known network
`
`(layer 3) protocol. (Id., ¶ 61.) IPv4 was published as RFC 760 in January 1980
`
`while its successor IPv6 was published as RFC 2460 in December 1998. Id. The
`
`IP protocol describes a set of rules for dividing a message into multiple parts
`
`(called “IP packets”) and then transmitting those packets from an IP sender to an
`
`IP destination across multiple routers or other links in a computer network. Each
`
`packet of information includes an IP address for its destination, analogous to
`
`sending a letter through the mail by placing the letter inside an envelope that has
`
`the recipient’s postal address printed on it. Id. The format of an IP header is
`
`depicted below:
`
`
`
`3
`
`
`
`Case No. IPR2017-01391
`U.S. Patent No. 7,237,036
`
`
`
`(Id.; Ex. 2042)2
`
`
`
`The Transmission Control Protocol, referred to as “TCP,” is one of the main
`
`protocols used to send and receive information over the Internet. (Ex. 2026, ¶ 62.)
`
`TCP is well known in the computer networking industry—one early TCP rule set
`
`was published as a Request for Comment (or “RFC”) by the Internet Engineering
`
`Task Force (“IETF”) in September 1981 (RFC 793). That rule set was based on an
`
`
`
`2 This figure accurately depicts an IP header as of October 1997, as supported by
`
`the testimony of Dr. Almeroth. (Ex. 2026 at ¶ 61.)
`
`
`
`4
`
`
`
`Case No. IPR2017-01391
`U.S. Patent No. 7,237,036
`
`even earlier rule set published in December 1974 as RFC 675. TCP is an example
`
`of a transport (layer 4) protocol in the OSI model. Id. TCP is responsible for
`
`adding reliability and ordering to the stream of network information—for example,
`
`the packets of information sent using IP as the network-layer protocol may not
`
`arrive at the destination in the same order intended by the sender of the message.
`
`Id. TCP sets rules for breaking up and transmitting the message so that the
`
`recipient is able to reliably receive and reassemble the message. Another common
`
`analogy from the physical world is the example of sending a multi-page letter
`
`through the mail by separately numbering each page and mailing it in its own
`
`envelope. IP, like the postal service, will route the envelope-like packets to the
`
`destination, but TCP (like the numbering of the individual pages) sets the rules to
`
`allow the recipient to verify that all of the pages have been received and to
`
`reassemble the pages in the right order. Id.
`
`
`
`TCP describes, for example, how two devices on the Internet may establish a
`
`connection over which TCP data packets may be communicated between them.
`
`(Ex. 2026, ¶ 63.) By way of a negotiation process known as a three-way
`
`handshake, such a connection can be established between two nodes, and once that
`
`connection establishment phase completes, data transfer can begin. Typically, a
`
`TCP connection is managed by a device operating system so that applications such
`
`as a web browser or a web server like a CDN caching server can pass data to the
`
`
`
`5
`
`
`
`Case No. IPR2017-01391
`U.S. Patent No. 7,237,036
`
`operating system’s TCP protocol “stack,” and the operating system will manage
`
`transmission of that data to the receiver and will pass received data from the other
`
`device up to the application layer. Id. The format of a TCP header is depicted
`
`below:
`
`(Id.; Ex. 2042.3)
`
`
`
`
`
`3 This figure accurately depicts an TCP header as of October 1997, as supported
`
`by the testimony of Dr. Almeroth. (Ex. 2026 at ¶ 63.)
`
`
`
`6
`
`
`
`Case No. IPR2017-01391
`U.S. Patent No. 7,237,036
`
`
`
`Transmitting a message requires processing each of the layers in that
`
`protocol stack sequentially so that the message can then be transmitted over the
`
`data medium. The receiving computer is also required to process those same
`
`layers in reverse until the message is handed off to the appropriate program (e.g., a
`
`web server). (Ex. 2026, ¶ 64.) One example of processing a message using
`
`TCP/IP is depicted below:
`
`
`
`
`
`7
`
`
`
`Case No. IPR2017-01391
`U.S. Patent No. 7,237,036
`
`(Id.; Ex. 2043.4)
`
`
`
`
`
`Much of this processing is typically handled by the CPU. (Ex. 2026, ¶
`
`65.) Thus, sending and receiving data over a network can negatively impact the
`
`CPU’s ability to perform other functions, particularly as the volume of data sent or
`
`received increases. Id. For the purposes of this case, the manner by which the
`
`CPU handles the required protocol processing—i.e., the specific software steps it
`
`takes to perform the needed TCP and IP processing—is immaterial. Id. At most, it
`
`is sufficient that the CPU does perform or is capable of performing that processing,
`
`whether through software included as part of the operating system or through some
`
`other means. Id.
`
`III. OVERVIEW OF THE ’036 PATENT
`
`A. The ’036 Patent Specification
`
`The ’036 Patent,
`
`titled “Fast-Path Apparatus for Receiving Data
`
`Corresponding to a TCP Connection,” describes a novel system for accelerating
`
`network processing. An intelligent network interface card (INIC) communicates
`
`with a host computer. The INIC provides “a fast-path that avoids protocol
`
`
`
`4 This figure accurately depicts an example of processing a message using TCP/IP
`
`as of October 1997, as supported by the testimony of Dr. Almeroth. (Ex. 2026 at ¶
`
`64.)
`
`
`
`8
`
`
`
`Case No. IPR2017-01391
`U.S. Patent No. 7,237,036
`
`processing for most large multi-packet messages, greatly accelerating data
`
`communication.” (Ex. 1001 at Abstract.) In some embodiments, the INIC
`
`“contains specialized hardware circuits that are much faster at their specific tasks
`
`than a general purpose CPU.” (Id.; Ex. 2026 at ¶ 66.)
`
`As explained in the background of the ’036 Patent, when a conventional
`
`network interface card prepares to send data from a first host to a second host,
`
`“some control data is added at each layer of the first host regarding the protocol of
`
`that layer, the control data being indistinguishable from the original (payload) data
`
`for all lower layers of that host.” (Id. at 4:15-18.) For example, an application
`
`layer attaches an application layer header to the payload data and sends the
`
`combined data to the presentation layer of the sending host, which receives the
`
`combined data, operates on it and adds a presentation layer header to the data,
`
`resulting in another combined data packet. The data resulting from combining the
`
`payload data, application layer header, and presentation layer header is then passed
`
`to the session layer, which performs required operations including attaching a
`
`session layer header to the data and presenting the resulting combination of data to
`
`the transport layer. This process continues as the information moves to lower
`
`layers, with a transport layer header, network layer header, and data link layer
`
`header and trailer attached to the data at each of those layers, with each step
`
`
`
`9
`
`
`
`Case No. IPR2017-01391
`U.S. Patent No. 7,237,036
`
`typically including data moving and copying, before sending the data as bit packets
`
`over the network to the second host. (Id. at 4:28-33.) (Ex. 2026 at ¶ 67.)
`
`This process of adding a layer header to the data from the preceding layer is
`
`sometimes referred to as “encapsulation” because the data and layer header is
`
`treated as the data for the immediately following layer, which, in turn, adds its own
`
`layer header to the data from the preceding layer. Each layer is generally not
`
`aware of which portion of the data from the preceding layer constitutes the layer
`
`header or the user data; as such, each layer treats the data it receives from the
`
`preceding layer as some generic payload.
`
`(Ex. 1008, Stevens at 1008.034, Figure 1.4 (adapted from Petition at 18).) (Ex.
`
`
`
`2026 at ¶ 68.)
`
`
`
`10
`
`
`
`Case No. IPR2017-01391
`U.S. Patent No. 7,237,036
`
`On the receiving side, the receiving host generally performs the reverse of
`
`the sending process, beginning with receiving the bits from the network. Headers
`
`are removed, one at a time, and the received data is processed, in order, from the
`
`lowest (physical) layer to the highest (application) layer before transmission to a
`
`destination within the receiving host (e.g., to the operating system space where the
`
`received data may be used by an application running on the receiving host). (Ex.
`
`1001 at 4:34-39.) Each layer of the receiving host recognizes and manipulates
`
`only the headers associated with that layer, since to that layer the higher layer
`
`header data is included with and indistinguishable from the payload data.
`
`“Multiple interrupts, valuable central processing unit (CPU) processing time and
`
`repeated data copies may also be necessary for the receiving host to place the data
`
`in an appropriate form at its intended destination.” (Id. at 4:43-46.) (Ex. 2026 at ¶
`
`69)
`
`Because the processing of each layer typically involves a copy and data
`
`manipulation operation (for example a checksum generation or validation
`
`operation), the host CPU must be “interrupted” at least one time per layer in order
`
`to process the data and construct (transmit side) or deconstruct (receive side) the
`
`packet. An interrupt is a signal to the processor emitted by hardware or software
`
`indicating an event that needs immediate attention. (Ex. 2026 at ¶ 70.) An
`
`interrupt alerts the processor to a high-priority condition requiring the interruption
`
`
`
`11
`
`
`
`Case No. IPR2017-01391
`U.S. Patent No. 7,237,036
`
`of the current code the processor is executing. (Id.) This process associated with
`
`traditional network interface cards results in “repeated copying and interrupts to
`
`the CPU” of the host computer. (Ex. 1001 at 5:39-40.) When the host CPU is
`
`interrupted, it generally must stop all other tasks it is currently working on,
`
`including tasks completely unrelated to the network processing. (Ex. 2026 at ¶
`
`70.) Frequent interrupts to the host CPU can be very disruptive to the host system
`
`generally and cause system instability and degraded system performance. (Id.)
`
`The invention of the ’036 Patent includes a “fast-path” where the host CPU
`
`is relieved of certain TCP/IP processing, which is instead performed by the INIC.
`
`In other words, the invention “allow[s] data from the message to be processed via a
`
`fast-path which accesses message data directly at its source or delivers it directly to
`
`its intended destination.” (Ex. 1001 at 5:31-34.) The fast-path “bypasses
`
`conventional protocol processing of headers that accompany the data” and
`
`“employs a specialized microprocessor designed for processing network
`
`communication, avoiding the delays and pitfalls of conventional software layer
`
`processing, such as repeated copying and interrupts to the CPU.” (Id. at 5:34-40;
`
`Ex. 2026, ¶ 71.)
`
`The fast-path is shown in Figure 24 of the ’036 Patent, which is reproduced
`
`below. In this embodiment, the INIC performs at least the IP and TCP layer
`
`processing, freeing up the CPU on the host (“client”) computer to do other tasks.
`
`
`
`12
`
`
`
`Case No. IPR2017-01391
`U.S. Patent No. 7,237,036
`
`The fast-path also reduces or eliminates the number of interrupts sent to the CPU
`
`on the host/client. The more traditional “slow-path” is also shown, where the
`
`host/client is responsible for the IP and TCP layer processing. In the slow-path,
`
`the CPU on the host/client is interrupted at least one time at each layer of
`
`processing. (Ex. 2026 at ¶ 72.)
`
`
`
`(Ex. 1001.026 at Fig. 24.)
`
`The results of the claimed invention include more efficient network
`
`processing and “a huge reduction in interrupts.” (Id. at 11:47-53.) For fast-path
`
`communications, only one interrupt occurs at the beginning and end of an entire
`
`upper-layer message transaction, and “there are no interrupts for the sending or
`
`receiving of each lower layer portion or packet of that transaction.” (Id. at 11:53-
`
`57.) (Ex. 2026 at ¶ 73.)
`
`
`
`13
`
`
`
`Case No. IPR2017-01391
`U.S. Patent No. 7,237,036
`
`As stated above, the claimed arrangement allows for enhanced network and
`
`system performance, a stark reduction or elimination of interrupts seen by the host
`
`CPU, faster data throughput, increased system stability, and an overall better user
`
`experience. (Ex. 2026 at ¶ 74.)
`
`B.
`
`The ’036 Patent Claims
`
`The ’036 Patent includes 22 claims. Claims 1-7 are challenged in the
`
`Petition and are reproduced below:
`
`Claim 1 of the ’036 Patent
`
`Label
`
`Limitation
`
`1pa
`
`1pb
`
`1pc
`
`1.1
`
`1.2
`
`1.3
`
`1.4
`
`2
`
`
`
`A device for use with a first apparatus that is connectable to a second
`apparatus,
`the first apparatus containing a memory and a first processor
`operating a stack of protocol processing layers that create a context
`for communication,
`the context including a media access control (MAC) layer address, an
`Internet Protocol (IP) address and Transmission Control Protocol
`(TCP) state information, the device comprising:
`a communication processing mechanism connected to the first
`processor,
`said communication processing mechanism containing a second
`processor
`running instructions to process a message packet such that the context
`is employed to transfer data contained in said packet to the first
`apparatus memory and
`the TCP state information is updated by said second processor
`
`Claim 2 of the ’036 Patent
`
`The device of claim 1, wherein said communication processing
`mechanism includes a receive sequencer with directions to classify
`
`14
`
`
`
`Case No. IPR2017-01391
`U.S. Patent No. 7,237,036
`
`said packet, wherein said packet contains control information
`corresponding to the stack of protocol layers.
`Claim 3 of the ’036 Patent
`
`3. The device of claim 1, wherein said communication processing
`mechanism includes a receive sequencer with directions to generate a
`summary of a second message packet received from the network, said
`second packet containing control information corresponding to the
`stack of protocol layers, and said instructions including an instruction
`to compare said summary with said context.
`Claim 4 of the ’036 Patent
`
`4. The device of claim 1, wherein said instructions include a first
`instruction to create a header corresponding to said context and
`having control information corresponding to several of the protocol
`processing layers, and said instructions include a second instruction to
`prepend said header to second data for transmission of a second
`packet.
`
`Claim 5 of the ’036 Patent
`
`5. The device of claim 1, wherein said communication processing
`mechanism has a direct memory access unit to send, based upon said
`context, said data from said communication processing mechanism to
`the first apparatus memory, without a header accompanying said data.
`Claim 6 of the ’036 Patent
`
`6. The device of claim 1, wherein said context includes a receive
`window of space in the memory that is available to store application
`data, and said communication processing mechanism advertises said
`receive window.
`Claim 7 of the ’036 Patent
`
`7. The device of claim 1, wherein said context includes TCP ports of
`said first and said second apparatuses.
`
`15
`
`3
`
`4
`
`5
`
`6
`
`7
`
`
`
`
`
`
`
`Case No. IPR2017-01391
`U.S. Patent No. 7,237,036
`
`IV. OVERVIEW OF THE ASSERTED PRIOR ART
`
`Petitioner relies on the Erickson and Tanenbaum references. Erickson and
`
`Tanenbaum, however, lack any disclosure of limitations 1.2, 1.3 and 1.4,
`
`specifically, a communication processing mechanism containing a second
`
`processor that runs instructions to process a message packet such that the context
`
`(including a media access control (MAC) layer address, an Internet Protocol (IP)
`
`address and Transmission Control Protocol (TCP) state information) is employed
`
`to transfer data contained in said packet to the first apparatus memory. The
`
`following sections summarize these references and underscore their respective
`
`shortcomings.
`
`A. U.S. Patent No. 5,768,618 to Erickson et al. (“Erickson”)
`
`Erickson discloses an input/output (I/O) device connected to a computer to
`
`facilitate fast I/O data transfers. (Ex. 1005 at Abstract.) An address space for the
`
`I/O device is created in the virtual memory of the computer, wherein the address
`
`space comprises virtual registers that are used to directly control the I/O device.
`
`Control registers and/or memory of the I/O device are mapped into the virtual
`
`address space, and the virtual address space is backed by control registers and/or
`
`memory on the I/O device. When the I/O device detects writes to the address
`
`space, a pre-defined sequence of actions can be triggered in the I/O device by
`
`programming specified values into the data written into the mapped virtual address
`
`
`
`16
`
`
`
`Case No. IPR2017-01391
`U.S. Patent No. 7,237,036
`
`space. (Id.) Notably, Petitioner states that Erickson describes a “fast path for
`
`network connections.” (Petition at 39) The phrase “fast path,” however, is not
`
`used once in Erickson. (Ex. 2026 at ¶ 81.)
`
`82. Figure 7 of Erickson shows a UDP datagram header “template” that
`
`resides in the I/O adapter’s memory. (Id. at 7:39-46.) A user provides the starting
`
`address and length for the user data in its virtual address space, and then “spanks”
`
`a GO register to trigger execution of a predetermined script. (Id.) The script
`
`causes a UDP datagram to be created by accessing the user data, computing a
`
`counter value for the datagram, computing a UDP checksum over both the UDP
`
`header and user data, and computing an IP checksum. (Id. at 8:10-26.) The
`
`completed UDP datagram is then transmitted over the network. (Id. at 7:45-47.)
`
`Erickson does not address or suggest segmenting or dividing a block of user data
`
`from source memory into a number of transmittable segments because the network
`
`adapter only possesses “a very limited knowledge of the user process’ virtual
`
`address space, probably only knowing how to map virtual-to-physical for a very
`
`limited range, maybe as small as a single page.” (Id. at 8:16-20.) Consequently,
`
`Erickson is also silent as to the network adapter then prepending packet headers to
`
`each of these divided segments. (Ex. 2026 at ¶ 82.)
`
`In addition, while TCP/IP is mentioned in passing (“[t]ypes of protocols
`
`include, but are not limited to, TCP/IP, UDP/IP, BYNET lightweight datagrams,
`
`
`
`17
`
`
`
`Case No. IPR2017-01391
`U.S. Patent No. 7,237,036
`
`deliberate shared memory, active message handler, SCSI, and File Channel”), all
`
`the described examples and embodiments in Erickson use UDP, not TCP. (Id. at
`
`5:47-51.) There is no discussion or explanation within Erickson of how to
`
`implement any of the processes described in Erickson with TCP. (Ex. 2026 at ¶
`
`83.)
`
`B. Andrew S. Tanenbaum, Computer Networks, 3rd ed. (1996)
`(“Tanenbaum”)
`
`Tanenbaum appears on the face of the ’036 patent under “References Cited.”
`
`Ex. 1001.003. Tanenbaum is the third edition of a textbook relating to “Computer
`
`Networks.” (Ex. 2026 at ¶ 84.)
`
`Petitioner cites only a few pages from Tanenbaum—i.e., the portion of
`
`Tanenbaum that discusses “fast path” host CPU processing of the TCP protocol.
`
`Ex. 1006 at 584. Specifically, Tanenbaum describes “fast” TPDU (Transport
`
`Protocol Data Unit) processing. (Ex. 1006 at 583-86.) On the sending side,
`
`Tanenbaum notes that “[i]n the normal case, the headers of consecutive data
`
`