throbber
UNITED STATES PATENT AND TRADEMARK OFFICE
`________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`________________
`
`INTEL CORPORATION,
`
`Petitioner,
`
`v.
`
`ALACRITECH INC.,
`
`Patent Owner
`________________
`
`Case IPR2017-01395
`U.S. Patent 8,805,948
`________________
`
`PATENT OWNER’S PRELIMINARY RESPONSE
`PURSUANT TO 35 U.S.C. § 313 AND 37 C.F.R. § 42.107
`
`

`

`Case No. IPR2017-01395
`U.S. Patent No. 8,805,948
`
`TABLE OF CONTENTS
`
`Page
`
`I.
`II.
`
`V.
`VI.
`
`IX.
`
`INTRODUCTION.................................................................................1
`OVERVIEW OF THE ’948 PATENT ..................................................4
`A.
`The ’948 Patent Specification.....................................................4
`B.
`The ’948 Patent Claims...............................................................9
`PROSECUTION HISTORY OF THE ’948 PATENT ...................... 15
`III.
`IV. OVERVIEW OF THE ASSERTED PRIOR ART............................. 16
`Thia, A Reduced Operation Protocol Engine (ROPE) for
`A.
`a Multiple-layer Bypass Architecture (1995) (“Thia”)............ 17
`Tanenbaum, Computer Networks, 3rd ed. (1996)
`(“Tanenbaum”)......................................................................... 21
`Stevens, TCP/IP Illustrated Volume 2: The
`Implementation (“Stevens”) (Ex. 1063)................................... 24
`CLAIM CONSTRUCTION ............................................................... 25
`PETITIONER HAS NOT MADE A SUFFICIENT
`THRESHOLD SHOWING THAT STEVENS IS AVAILABLE
`AS PRIOR ART IN THIS PROCEEDING........................................ 26
`VII. PETITIONER HAS NOT SUFFICIENTLY SHOWN A
`MOTIVATION TO COMBINE THIA WITH TANENBAUM
`OR STEVENS .................................................................................... 33
`VIII. PETITIONER HAS NOT SHOWN A DISCLOSURE OF
`PACKET PROCESSING FOR THE "CHECKING"
`LIMITATIONS OF THE CHALLENGED CLAIMS ....................... 35
`THE BOARD SHOULD DENY THE PETITION BECAUSE
`IT FAILS TO DISCLOSE ALL REAL PARTIES IN
`INTEREST ......................................................................................... 43
`A.
`Intel Effectively Controls Dell................................................. 44
`B.
`The Relationship Between Intel and Dell is Sufficiently
`Close......................................................................................... 46
`Dell Desires Review of the ‘948 Patent................................... 48
`
`B.
`
`C.
`
`C.
`
`i
`
`

`

`E.
`
`F.
`
`X.
`
`D.
`
`Case No. IPR2017-01395
`U.S. Patent No. 8,805,948
`
`Intel Dell Have Coordinated Interest and Action in
`Challenging the ‘948 Patent..................................................... 48
`Intel Has Effective Choice as to the Legal Theories and
`Proofs of Dell and Cavium....................................................... 50
`Finding Dell and Cavium Are Real Parties in Interest Is
`Consistent with Legislative Intent............................................ 51
`ALACRITECH RESERVES ITS RIGHTS UNDER THE
`PENDING OIL STATES CASE AT THE UNITED STATES
`SUPREME COURT ........................................................................... 52
`THE BOARD SHOULD DECLINE INSTITUTION UNDER
`35 U.S.C. § 325(D) BECAUSE THE PETITION RELIES ON
`PRIOR ART ALREADY CONSIDERED BY THE OFFICE .......... 53
`XII. CONCLUSION .................................................................................. 54
`
`XI.
`
`ii
`
`

`

`Case No. IPR2017-01395
`U.S. Patent No. 8,805,948
`
`TABLE OF AUTHORITIES
`
`Cases
`Beckman Instruments v. LKB Produkter AB,
`892 F.2d 1547, 1551, 13 USPQ2d 1301, 1304 (Fed. Cir. 1989) ............. 17
`Benson & Ford, Inc. v. Wanda Petroleum Co.,
`833 F.2d 1172 (5th Cir. 1987).................................................................. 47
`Coalition for Affordable Drugs (ADROCA) LLC v. Acorda
`Therapeutics, Inc., Case IPR2015-00817,
`Paper, 12 (Aug. 24, 2015) ......................................................................... 27
`Dynamic Drinkware LLC v. Nat’l Graphics, Inc.,
`800 F.3d 1375 (Fed. Cir. 2015)................................................................ 26
`Hewlett-Packard Co. v. U.S. Philips Corp.,
`Case IPR2015-01505, Paper, 16 (Jan. 19, 2016) ................................ 26, 27
`Microsoft Corp. v. Biscotti,
`IPR2014-01457, Paper, No. 9 (Mar. 9, 2015)........................................... 27
`Oil States Energy Servs. LLC v. Greene’s Energy Group, LLC,
`Case No. 16-712, certiorari granted (U.S. Jun. 12, 2017) ...................... 53
`Symbol Techs. Inc. v. Opticon Inc.,
`935 F.2d 1569, 19 USPQ2d 1241 (Fed. Cir. 1991).................................. 17
`Teva Pharmaceuticals USA, Inc. v. Indivio UK Limited,
`Case IPR2016-00280, Paper, 23 (Jun. 10, 2016) ...................................... 27
`Statutory Authorities
`
`35 U.S.C. § 312(a)(2).................................................................................... 43
`
`<<so: 003>>35 U.S.C. § 314............................................................................................... 3
`Rules and Regulations
`
`<<so: 007>><<so: 012>>37 C.F.R. § 42.108.......................................................................................... 3
`
`Office Patent Trial Practice Guide,
`77 Fed. Reg. 48756, 48759-60 (Aug. 14, 2012) .................... 44.z46. 48. 52
`
`iii
`
`

`

`Case No. IPR2017-01395
`U.S. Patent No. 8,805,948
`
`Legislative Materials
`
`157 Cong. Rec. S1034, S1041 (Mar. 1, 2011).............................................. 51
`H.R. Rept. No. 112-98 (2011) (Judiciary Committee
`Report on H.E. 1249, June 1, 2011).......................................................... 51
`Additional Authorities
`Andrew S. Tanenbaum, Computer Networks (3rd ed. 1996) ................... 2, 40
`
`iv
`
`

`

`Case No. IPR2017-01395
`U.S. Patent No. 8,805,948
`
`PATENT OWNER’S LIST OF EXHIBITS
`
`Description
`
`Not used
`
`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)
`
`Not used
`
`Defendant Dell Inc.’s First Supplemental Response to
`Plaintiff’s Second Set of Common Interrogatories to
`Defendants and Intervenors (No. 11)
`
`Not used
`
`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
`
`Cavium’s Motion to Intervene, Case No. 2:16-cv-00693-
`JRG-RSP, Dkt. 109 (E.D. Tex., Jan. 13, 2017)
`
`Exhibit #
`
`Ex. 2001
`
`Ex. 2002
`
`Ex. 2003
`
`Ex. 2004
`
`Ex. 2005
`
`Ex. 2006
`
`Ex. 2007
`
`Ex. 2008
`
`Ex. 2009
`
`v
`
`

`

`Case No. IPR2017-01395
`U.S. Patent No. 8,805,948
`
`I.
`
`INTRODUCTION
`
`Pursuant to 35 U.S.C. § 313 and 37 C.F.R. § 42.107(a), Patent Owner
`
`Alacritech Inc. (“Alacritech”) submits this Preliminary Response to the Petition for
`
`Inter Partes Review (“the Petition”) filed in this matter. Petitioner Intel
`
`Corporation (“Intel”) seeks Inter Partes Review (“IPR”) of claims 1, 3, 6-9, 11,
`
`14-17, 19, and 21-22 of U.S. Patent No. 8,805,948 (“the ’948 patent”), as allegedly
`
`being unpatentable under 35 U.S.C. § 103(a).1
`
`The ’948 patent is directed to accelerated network processing using an
`
`intelligent network interface card (INIC). Through a series of novel improvements
`
`over conventional network interfaces, the claimed invention is able to provide a
`
`fast-path that avoids protocol processing by the host for most large multipacket
`
`messages. As explained in more detail below, by relieving the host CPU of
`
`protocol processing for such messages, the claimed invention provides enhanced
`
`network and system performance, faster data throughput, increased system
`
`
`1 The ’948 patent is assigned to Alacritech and is the subject of co-pending
`
`litigation, Alacritech, Inc. v. CenturyLink, Inc., 2:16-cv-00693-JRG-RSP (E.D.
`
`Tex.); Alacritech, Inc. v. Wistron Corp., 2:16-cv-00692-JRG-RSP (E.D. Tex.); and
`
`Alacritech, Inc. v. Dell Inc., 2:16-cv-00695-RWS-RSP (E.D. Tex.), which were all
`
`consolidated for pre-trial purposes (“the Litigations”).
`
`1
`
`

`

`Case No. IPR2017-01395
`U.S. Patent No. 8,805,948
`
`stability, and an overall better user experience.
`
`In its Petition, Intel asserts that the ’948 patent is invalid on a single
`
`ground—that claims 1, 3, 6-9, 11, 14-17, 19, and 21-22 of the ’948 patent are
`
`obvious over Y.H. Thia and C.M. Woodside, i (1995) (“Thia”) (Ex. 1015), Andrew
`
`S. Tanenbaum, Computer Networks (3rd ed. 1996) (“Tanenbaum”) (Ex. 1006), and
`
`W. Richard Stevens and Gary R. Wright, TCP/IP Illustrated Volume 2: The
`
`Implementation (“Stevens”) (Ex. 1063). As set forth below, Intel’s Petition does
`
`not establish a likelihood of success against any challenged claim.
`
`First, the Board should deny institution because the Stevens reference—
`
`relied upon by Petitioner for every challenged claim—has not been shown to be
`
`available prior art in this proceeding. Specifically, Petitioner has not carried its
`
`institution-stage burden of producing sufficient admissible evidence that Stevens
`
`was publicly accessible prior to the October 14, 1997 priority date of the ’948
`
`patent and therefore qualifies as a “printed publication” here. In fact, Petitioner's
`
`own evidence states that the Stevens reference it submitted in this proceeding was
`
`publicly available no earlier than September 2010. This affects the entirety of this
`
`Petition, and the appropriate remedy is to deny institution.
`
`Second, Petitioner has not sufficiently shown a motivation to combine Thia
`
`with Tanenbaum or Stevens. Although Petitioner refers to conditions in
`
`Tanenbaum’s discussion of header prediction and argues these conditions may be
`
`2
`
`

`

`Case No. IPR2017-01395
`U.S. Patent No. 8,805,948
`
`implemented in a hardware bypass chip disclosed in Thia, Tanenbaum teaches
`
`against hardware implementations. This deficiency infects the entire Petition, and
`
`the appropriate remedy is to deny institution.
`
`Third, the Petition identifies TPDU processing, not packet processing, in its
`
`obviousness analysis of the “check[ing]” limitations that appear in all challenged
`
`claims. The Petition offers no explanation as to why TPDUs are identified as
`
`meeting the “packet” limitations of the challenged claims, and according to
`
`Petitioner’s own references, TPDUs are not the same as packets with respect to the
`
`“check[ing]” limitations. As a result, the Petition does not adequately show that
`
`the claimed “check[ing] . . . the packets” limitations of the ‘948 patent appear in
`
`the relied-upon references. This deficiency affects all challenged claims, and
`
`should result in non-institution of the Petition in its entirety.
`
`Fourth, the Board should deny institution because Petitioner has failed to
`
`identify all real parties in interest as required by 35 U.S.C. § 312(a)(2) and 37 CFR
`
`§ 42.8(b)(1).
`
`Accordingly, the references identified by Intel do not give rise to a
`
`reasonable likelihood that it will prevail with respect to any challenged claim of the
`
`’948 patent, either alone or in combination. Therefore, the Board should not
`
`institute review on any claim of the ’948 patent. See 35 U.S.C. § 314; 37 C.F.R. §
`
`42.108.
`
`3
`
`

`

`Case No. IPR2017-01395
`U.S. Patent No. 8,805,948
`
`II. OVERVIEW OF THE ’948 PATENT
`
`A.
`
`The ’948 Patent Specification
`
`The ’948 patent 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 host protocol
`
`processing for most large multipacket messages, greatly accelerating data
`
`communication.” Ex. 1001 at Abstract. In some embodiments, the INIC “contains
`
`hardware circuits configured for protocol processing that can perform that specific
`
`task faster than a host CPU.” Id.
`
`As explained in the background of the ’948 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 2:39-42. For example,
`
`an application layer attaches an application 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 header to the data, resulting in another combined data
`packet. The data resulting from combination of payload data,
`application header, and presentation header is then passed to the
`session layer, which performs required operations including attaching
`a session header to the data and presenting the resulting combination
`
`4
`
`

`

`Case No. IPR2017-01395
`U.S. Patent No. 8,805,948
`
`of data to the transport layer. This process continues as the
`information moves to lower layers, with a transport header, network
`header, and data link header and trailer attached to the data at each of
`those layers, with each step typically including data moving and
`copying, before sending the data as bit packets over the network to the
`second host.
`
`Id. at 2:42-57.
`
`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 is the preceding layer
`
`header of user data; as such, each layer treats the data it receives from the
`
`preceding layer as some generic payload. Id.
`
`5
`
`

`

`Case No. IPR2017-01395
`U.S. Patent No. 8,805,948
`
`Ex. 1008, Stevens at .034, Figure 1.7 (adapted from Petition at 19).
`
`On the receiving side, the receiving host generally performs the reverse of
`
`the sending process, beginning with receiving the bit packets from the network. Id.
`
`at 2:58-60. 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). Id. at 2:60-63. 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. Id. at 2:63-66. “Multiple interrupts, valuable central processing unit (CPU)
`
`6
`
`

`

`Case No. IPR2017-01395
`U.S. Patent No. 8,805,948
`
`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
`
`2:66-3:3.
`
`The host CPU processes the data by constructing (transmit side) or
`
`destructing (receive side) the packet. The host CPU must be interrupted at least
`
`one time per layer and, in response, the host CPU processes each layer, which
`
`typically involves a copy and data manipulation operation (for example a
`
`checksum computation operation). An interrupt is a signal to the processor emitted
`
`by hardware or software indicating an event that needs immediate attention. An
`
`interrupt alerts the processor to a high-priority condition requiring the interruption
`
`of the current code the processor is executing. Id. This process involved with
`
`traditional network interface cards results in “repeated copying and interrupts to
`
`the CPU” of the host computer. Id. at 3:59-62. 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. 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 ’948 patent includes a “fast-path” where the host CPU
`
`is relived of certain TCP/IP processing, which is instead performed by the INIC.
`
`In other words, the invention allows “data from the message to be processed via a
`
`7
`
`

`

`Case No. IPR2017-01395
`U.S. Patent No. 8,805,948
`
`fast-path which accesses message data directly at its source or delivers it directly to
`
`its intended destination.” Id. at 3:53-57. 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 3:57-62.
`
`The fast-path is shown in Figure 6 of the ’948 patent, which is reproduced
`
`below. In this embodiment, the INIC performs at least the network and transport
`
`layer processing (e.g., IP and TCP layer processing in TCP/IP), freeing up the CPU
`
`on the host (“client”) computer to do other tasks. 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 for each layer for processing.
`
`8
`
`

`

`Case No. IPR2017-01395
`U.S. Patent No. 8,805,948
`
`Advantageously, the claimed invention allows for more efficient network
`
`processing by relieving the host CPU of per-frame processing and reducing the
`
`number of interrupts. Id. at 9:1-5. 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 9:5-10. As stated above, the
`
`claimed arrangement allows for enhanced network and system performance, faster
`
`data throughput, increased system stability, and an overall better user experience.
`
`B.
`
`The ’948 Patent Claims
`
`The ’948 patent includes three independent claims. Independent claim 1
`
`(reproduced below) recites a method for network communication. Notably, claim
`
`1 recites, inter alia, “checking, by the network interface, whether the packets have
`
`certain exception conditions, including checking whether the packets are IP
`
`9
`
`

`

`Case No. IPR2017-01395
`U.S. Patent No. 8,805,948
`
`fragmented, checking whether the packets have a FIN flag set, and checking
`
`whether the packets are out of order.” This claimed feature is not found in any of
`
`the prior art cited by Petitioner.
`
`Claim 1. A method for network communication by a host computer
`having a network interface that
`is connected to the host by an
`input/output bus, the method comprising:
`running, on the host computer, a protocol processing stack
`including an Internet Protocol (IP) layer and a Transmission Control
`Protocol (TCP) layer, with an application layer running above the
`TCP layer;
`initializing, by the host computer, a TCP connection that is
`defined by source and destination IP addresses and source and
`destination TCP ports;
`receiving, by the network interface, first and second packets,
`wherein the first packet has a first TCP header and contains first
`payload data for the application, and the second packet has a second
`TCP header and contains second payload data for the application;
`checking, by the network interface, whether the packets have
`certain exception conditions, including checking whether the packets
`are IP fragmented, checking whether the packets have a FIN flag set,
`and checking whether the packets are out of order;
`if the first packet has any of the exception conditions, then
`protocol processing the first TCP header by the protocol processing
`stack;
`
`10
`
`

`

`Case No. IPR2017-01395
`U.S. Patent No. 8,805,948
`
`if the second packet has any of the exception conditions, then
`protocol processing the second TCP header by the protocol
`processing stack;
`if the packets do not have any of the exception conditions, then
`bypassing host protocol processing of the TCP headers and storing
`the first payload data and the second payload data together in a
`buffer of the host computer, such that the payload data is stored in the
`buffer in order and without any TCP header stored between the first
`payload data and the second payload data.
`Id. at 19:43-20:7.
`
`Claim 3 depends from claim 1 and additionally requires that a direct
`
`memory access (DMA) unit of the network interface performs the storing of the
`
`first payload data and the second payload data together in the buffer of the host
`
`computer. Id. at 20:8-10. Claim 6 also depends from claim 1 and adds the
`
`limitation that the network interface compares IP addresses and TCP ports of the
`
`packets with the source and destination IP addresses and source and destination
`
`TCP ports that define the TCP connection. Id. at 20:27-31. Claim 7 depends from
`
`claim 1 and recites that the checking of whether the packets have certain exception
`
`conditions includes checking whether the packets have a RST flag set. Id. at
`
`20:32-34. Claim 8 depends from claim 1 and recites that the checking of whether
`
`the packets have certain exception conditions includes checking whether the
`
`packets have a SYN flag set. Id. at 20:35-37.
`
`11
`
`

`

`Case No. IPR2017-01395
`U.S. Patent No. 8,805,948
`
`Independent claim 9 (reproduced below) recites a method for
`
`communicating information over a network. Notably, claim 9 recites, inter alia,
`
`“checking, by the network interface, whether the second and third packets have
`
`certain exception conditions, including checking whether the packets are IP
`
`fragmented, checking whether the packets have a FIN flag set, and checking
`
`whether the packets are out of order.” This claimed feature is not found in any of
`
`the prior art cited by Petitioner.
`
`Claim 9. A method for network communication by a host computer
`having a network interface that
`is connected to the host by an
`input/output bus, the method comprising:
`receiving, by the network interface, a first packet having a
`header including source and destination Internet Protocol (IP)
`addresses and source and destination Transmission Control Protocol
`(TCP) ports;
`protocol processing, by the host computer, the first packet,
`thereby initializing a TCP connection that is defined by the source
`and destination IP addresses and source and destination TCP ports;
`receiving, by the network interface, a second packet having a
`second header and payload data, wherein the second header has IP
`addresses and TCP ports that match the IP addresses and TCP ports
`of the TCP connection;
`
`receiving, by the network interface, a third packet having a third
`header and additional payload data, wherein the third header has IP
`
`12
`
`

`

`Case No. IPR2017-01395
`U.S. Patent No. 8,805,948
`
`addresses and TCP ports that match the IP addresses and TCP ports
`of the TCP connection;
`checking, by the network interface, whether the second and
`third packets have certain exception conditions, including checking
`whether the packets are IP fragmented, checking whether the packets
`have a FIN flag set, and checking whether the packets are out of
`order;
`
`if the second packet has any of the exception conditions, then
`protocol processing the second packet by the host computer;
`if the third packet has any of the exception conditions, then
`protocol processing
`the
`third packet by
`the host computer;
`if the second and third packets do not have any of the exception
`conditions, then storing the payload data of the second and third
`packets together in a buffer of the host computer, such that the
`payload data is stored in the buffer in order and without any TCP
`header stored between the payload data of the second and third
`packets.
`
`Id. at 20:38-21:7.
`
`Claim 11 depends from claim 9 and additionally requires that a direct
`
`memory access (DMA) unit of the network interface performs the storing of the
`
`payload data of the second and third packets together in the buffer of the host
`
`computer. Id. at 21:12-15. Claim 14 also depends from claim 9 and adds the
`
`limitation that the network interface compares IP addresses and TCP ports of the
`
`second and third packets with the source and destination IP addresses and source
`
`13
`
`

`

`Case No. IPR2017-01395
`U.S. Patent No. 8,805,948
`
`and destination TCP ports that define the TCP connection. Id. at 21:31-35. Claim
`
`15 depends from claim 9 and recites that the checking of whether the second and
`
`third packets have certain exception conditions includes checking whether the
`
`packets have a RST flag set. Id. at 21:36-38. Claim 16 depends from claim 9 and
`
`recites that the checking of whether the second and third packets have certain
`
`exception conditions includes checking whether the packets have a SYN flag set.
`
`Id. at 21:39-41.
`
`Independent claim 17 (reproduced below) recites an apparatus for network
`
`communication. Notably, claim 17 recites, inter alia, “check whether the packets
`
`have certain exception conditions, including whether the packets are IP
`
`fragmented, have a FIN flag set, or are out of order.” This claimed feature is not
`
`found in any of the prior art cited by Petitioner.
`
`Claim 17. An apparatus for network communication, the apparatus
`comprising:
`a host computer running a protocol stack including an Internet
`Protocol (IP) layer and a Transmission Control Protocol (TCP) layer,
`the protocol stack adapted to establish a TCP connection for an
`application layer running above the TCP layer, the TCP connection
`being defined by source and destination IP addresses and source and
`destination TCP ports;
`a network interface that is connected to the host computer by an
`input/output bus, the network interface adapted to parse the headers
`
`14
`
`

`

`Case No. IPR2017-01395
`U.S. Patent No. 8,805,948
`
`of received packets to determine whether the headers have the IP
`addresses and TCP ports that define the TCP connection and to check
`whether the packets have certain exception conditions, including
`whether the packets are IP fragmented, have a FIN flag set, or are out
`of order, the network interface having logic that directs any of the
`received packets that have the exception conditions to the protocol
`stack for processing, and directs the received packets that do not have
`any of the exception conditions to have their headers removed and
`their payload data stored together in a buffer of the host computer,
`such that the payload data is stored in the buffer in order and without
`any TCP header stored between the payload data that came from
`different packets of the received packets.
`
`Id. at 22:1-25. Claim 19 depends from claim 17 and recites that the network
`
`interface includes a direct memory access (DMA) unit adapted to store the payload
`
`data in the buffer of the host computer. Id. at 22:28-30. Claim 21 also depends
`
`from claim 17 and recites that the exception conditions include having a RST flag
`
`set. Id. at 22:36-37. Claim 22 depends from claim 17 and recites that the
`
`exception conditions include having a SYN flag set. Id. at 22:38-39.
`
`III. PROSECUTION HISTORY OF THE ’948 PATENT
`
`The ’948 patent issued on August 12, 2014. It was filed on September 26,
`
`2013 as Application No. 14/038,297, which was a continuation of Application No.
`
`09/692,561, filed October 18, 2000, which was a continuation of Application No.
`
`15
`
`

`

`Case No. IPR2017-01395
`U.S. Patent No. 8,805,948
`
`09/067,544, filed April 27, 1998, which claims the benefit of Provisional
`
`Application No. 60/061,809, filed on October 14, 1997.
`
`The ’948 patent was subject to a thorough examination by Examiner
`
`Moustafa M. Meky, who allowed the application on June 20, 2014 after
`
`considering references (including Thia and Tanenbaum) disclosed in by the
`
`Applicant and conducting the Examiner’s own prior art search on June 16, 2014.
`
`Ex. 1002 at .111-.149. In connection with the allowed claims, the Examiner stated:
`
`None of the prior art of record taken singularly or in combination
`teaches or suggests a network interface of a host computer for
`checking whether received packets have a certain exception
`conditions, including whether the packets are IP fragmented, have a
`FIN flag set, or out of order; processing any of the received packet
`that have the exception conditions, and storing payload data of the
`received packets that do not have any of the exception conditions in
`a buffer of the host computer and without any TCP header stored
`between the payload data of the received packets.
`Ex. 1002 at .117 (emphasis added). An Issue Notification was mailed on July 23,
`
`2014.
`
`IV. OVERVIEW OF THE ASSERTED PRIOR ART
`
`As described above, Intel relies on Thia, Tanenbaum, and Stevens. These
`
`references, each alone or in combination, fail to teach or suggest all the limitations
`
`recited in the claims of the ’948 patent. Moreover, at least the Stevens reference
`
`16
`
`

`

`Case No. IPR2017-01395
`U.S. Patent No. 8,805,948
`
`has not been established as prior art. For example, the references are completely
`
`silent as to bypass exception conditions that involve checking whether the packets
`
`are IP fragmented. The following sections summarize these references and
`
`underscore their respective shortcomings.
`
`A.
`
`Thia, A Reduced Operation Protocol Engine (ROPE) for a Multiple-
`layer Bypass Architecture (1995) (“Thia”)
`Thia appears on the face of the ’948 patent under “References Cited” and
`
`was initialed by the Examiner in an Information Disclosure Statement (IDS) dated
`
`June 15, 2014. Ex. 1002 at .120-.144. Thia was therefore already considered by
`
`the Examiner during the prosecution of the ’948 patent, which was found to be
`
`allowable over Thia.
`
`As an initial matter, Thia presents a “feasibility study for a new approach to
`
`hardware assistance” and the “final step of generating a chip layout for fabrication
`
`and fault analysis was not performed.” Ex. 1015 at .002 and .008. Since Thia at
`
`best discloses an inoperative device, it is a non-enabling reference. A non-
`
`enabling reference is prior art under 35 U.S.C. § 103 “for all that it teaches.”
`
`Beckman Instruments v.LKB Produkter AB, 892 F.2d 1547, 1551, 13 USPQ2d
`
`1301, 1304 (Fed. Cir. 1989); see Symbol Techs. Inc. v. Opticon Inc., 935 F.2d
`
`1569, 1578, 19 USPQ2d 1241, 1247 (Fed. Cir. 1991). The feasibility study
`
`discloses at a high level the idea of offloading session and transport layer
`
`17
`
`

`

`Case No. IPR2017-01395
`U.S. Patent No. 8,805,948
`
`processing to a Reduced Operation Protocol Engine (“ROPE”) chip, but does not
`
`teach many of the implementation details.
`
`Thia describes a bypass stack such as the ROPE chip that provides a
`
`hardware “fast path” for bulk data transfer. Id. at .002-.003.
`
`Id. at .003, Fig. 1 (adapted from Petition at 35). Regarding the receive bypass test,
`
`Thia merely discloses a test that matches headers of incoming data packets with a
`
`template using header prediction:
`
`18
`
`

`

`Case No. IPR2017-01395
`U.S. Patent No. 8,805,948
`
`Id. at .003 (adapted from Petition at 34). Thia does not address exception
`
`conditions relating to the bypass test.
`
`Table 1 of Thia “identifies procedures which are strong candidates for
`
`implementation in the bypass chip, and those which are better handled by the host,
`
`during the data transfer phase.” Id. at .006.
`
`19
`
`

`

`Case No. IPR2017-01395
`U.S. Patent No. 8,805,948
`
`Id. As shown in the table, Thia identifies bypassable functions in the presentation
`
`layer, the session layer, the transport layer, and all three of those layers. Thia does
`
`not address the bypass test or bypassable functions in relation to the network layer,
`
`which is where fragmentation/segmentation occurs. Indeed, Thia assumes that any
`
`packets that have been fragmented have been reassembled at the receiver before
`
`being passed to the Transport layer. Id. at .013-.014 (stating: “In an ATM system
`
`we assume that the segmentation and reassembly or SAR operation would also be
`
`in hardware, since it is done frequently”; “The Segmentation and Reassembly
`
`20
`
`

`

`Case No. IPR2017-01395
`U.S. Patent No. 8,805,948
`
`sublayer of the ATM adaption layer is a good place for [segmentation/reassembly]
`
`functions”).
`
`B.
`
`Tanenbaum, Computer Networks, 3rd ed. (1996) (“Tanenbaum”)2
`
`Tanenbaum, “Computer Networks,” is the third edition of a textbook
`
`relating to computer networks. As acknowledged by Petitioner, it too was already
`
`considered by the Examiner

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket