Trials@uspto.gov
`571-272-7822
`
`Paper 77
`Entered: November 14, 2018
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`INTEL CORPORATION, CAVIUM, LLC, and DELL, INC,
`Petitioner,
`
`V.
`
`ALACRITECH, INC.,
`Patent Owner.
`
`Case IPR2017-01410
`
`Patent 8,131,880 B21
`
`Before STEPHEN C. SIU, DANIEL N. FISHMAN, and
`CHARLES J. BOUDREAU, Administrative Patent Judges.
`
`SIU, Administrative Patent Judge.
`
`FINAL WRITTEN DECISION
`
`35 US. C. § 318(a)
`
`1 Cavium, Inc., which filed a Petition in Case IPR2017—01737, and Dell,
`Inc., which filed a Petition in Case IPR2018-OO339, were joined as
`petitioners in this proceeding; According to updated mandatory notices filed
`in this proceeding, Cavium, Inc. has now been converted to Cavium, LLC.
`Paper 72.
`
`

`

`IPR2017-01410
`
`Patent 8,131,880 B2
`
`1. INTRODUCTION
`
`Responsive to the filed Petition (Paper 1, “Pet.”), we instituted an
`
`inter partes review of all challenged claims (claims 32, 34, 35, 37—39, and
`
`41—43) ofU.S. Patent No. 8,131,880 B2 (“the ’880 patent,” Ex. 1001).
`
`Paper 8. Alacritech, Inc. (“Patent Owner”) filed a Corrected Patent Owner’s
`
`Response (Paper 32, “PO Resp”) and Intel Corporation filed a Petitioner
`
`Reply (Paper 42, “Pet. Reply”). Responsive to petitions and requests for
`
`joinder filed in IPR2017-01737 and IPR2018-00339, we joined Cavium, Inc.
`
`(now Cavium, LLC) and Dell, Inc., respectively, as petitioners in this
`
`proceeding. Paper 8 in IPR2017-01737; Paper 9 in IPR2018-003 39.
`
`According to updated mandatory notices filed in this proceeding, Cavium,
`
`Inc. has now been converted to Cavium, LLC. Paper 72. Petitioners Intel
`
`Corporation, Cavium, Inc, and Dell, Inc. are identified herein collectively as
`
`“Petitioner.”
`
`Patent Owner filed a Contingent Motion to Amend (Paper 20),
`
`Petitioner filed an Opposition to Patent Owner’s Contingent Motion to
`
`Amend (Paper 38), Patent Owner filed a Reply to Petitioner’s Opposition
`
`(Paper 43), and, pursuant to our having granted leave, Petitioner filed a Sur-
`
`Reply (Paper 50).
`
`Petitioner filed a Motion to Exclude (Paper 54), Patent Owner filed an
`
`Opposition (Paper 58), and Petitioner filed a Reply to Patent Owner’s
`Opposition (Paper 60).
`3
`
`Patent Owner filed a Motion to Exclude (Paper 55), Petitioner filed an
`
`Opposition (Paper 57), and Patent Owner filed a Reply to Patent Owner’s
`
`Opposition (Paper 61).
`
`'
`
`Patent Owner filed a Motion to Seal (Paper 30).
`
`

`

`IPR2017-01410
`
`Patent 8,131,880 B2
`
`A transcript of an oral hearing held on September 13, 2018 (Paper 73)
`
`has been entered into the record.
`
`We have jurisdiction under 35 U.S.C. § 6. This Final Written
`
`Decision is issued pursuant to 35 U.S.C. § 318(a). We base our decision on
`
`the preponderance ofthe evidence. 35 U.S.C. § 316(c); 37 CPR. § 42.1(d).
`
`Having reviewed the arguments of the parties and the supporting
`
`evidence, we conclude that Petitioner has demonstrated by a preponderance
`
`of the evidence that the challenged claims are unpatentable. We also deny
`
`Petitioner’s Motion to Exclude, Dismiss Patent Owner’s Motion to Exclude,
`
`grant Patent Owner’s Motion to Seal, and deny Patent Owner’s Contingent
`
`Motion to Amend.
`
`THE ’880 PATENT (EXHIBIT 1001)
`
`The ’880 patent describes a system and method for performing
`
`network processing tasks on a network interface card. Ex. 1001, 3:45—47.
`
`ILLUSTRATIVE CLAIM
`
`Claim 32, reproduced below, is illustrative of the claimed subject
`
`matter:
`
`A method of transferring a packet received at a
`32.
`network interface from a network to a host computer system,
`
`comprising:
`receiving a packet from a network at a network interface of
`a host computer system;
`parsing a header portion of said packet to extract an
`identifier of a source entity and an identifier of a destination
`entity;
`‘
`generating a flow key from said source identifier and said
`destination identifier to identify a communication flow
`comprising said packet, wherein said flow key includes a TCP
`
`3
`
`

`

`IPR2017-01410
`
`Patent 8,131,880 B2
`
`connection for the communication flow and a first hop medium
`access control (MAC) layer address;
`determining whether a header in said header portion
`conforms to a pre—selected protocol;
`storing said flow key in a database;
`associating an operation code with said packet, wherein
`said operation code identifies a status of said packet;
`storing said packet in a packet memory;
`if said header conforms to the TCP protocol:
`storing a data portion of said packet in a re-asSembly
`buffer;
`storing said header portion in a header buffer; and
`processing, by the network interface, said packet according
`to the TCP connection.
`
`Id. at 93:3~29.
`
`GROUNDS OF INSTITUTION
`
`We instituted trial on claims 32, 34, 35, 39, and 41—43 as unpatentable
`
`under 35 U.S.C. § 103 over Thia2 and Tanenbaum3 and claims 37 and 38 as
`
`unpatentable under 35 U.S.C. § 103 over Thia, Tanenbaum, and Nahum,4
`
`which are all proposed challenges to patentability. Pet. 19.
`
`ANALYSIS
`
`Petitioner argues that the combination of Thia and Tanenbaum
`
`discloses receiving a packet at a network interface of a host computer system
`
`2 Y.H. Thia and CM. Woodside, “A Reduced Operation Protocol Engine
`(ROPE) for a Multiple-Layer Bypass Architecture,” 1995 (“Thia,” Ex.
`1015)
`3 Andrew S Tanenbaum, Computer Networks, Third Edition, 1996
`(“Tanenbaum, ” Ex. 1006).
`4 Erich M Nahum, et a1., Performance Issuesin Parallelized Network
`' Protocols,” Proceedings of the First Symposium on Operating Systems
`Design and Implementation, November 1994 (“Nahum,” Ex. 1079).
`
`4
`
`

`

`IPR2017-01410
`
`Patent 8,131,880 B2
`
`and parsing a header portion of the packet to extract an identifier of a source
`
`entity and an identifier of a destination entity as recited in claim 32. For
`
`example, Petitioner argues that Tanenbaum discloses that one of skill in the
`
`art would have understood that “conventional processing of an incoming
`
`data packet” includes receiving an “incoming TCP/IP packet [that]
`
`comprises both an IP header and a TCP header,” that “[t]he IP and TCP
`
`headers include source and destination IP addresses and TCP ports,” and that
`“the source and destination addresses and ports are identifiers of source and
`
`‘
`
`destination entities.” Pet. 44—46 (citing Ex. 1006, .431, .434, .524, .541,
`
`.544, Figs. 5-45, 6-23, 6-24).
`
`Petitioner argues that the combination of Thia and Tanenbaum
`
`discloses generating a flow key that includes a TCP connection for a
`communication flow and a first hop medium access control (MAC) layer
`
`address, as recited in claim 32. Pet. 47—49. For example, as Petitioner
`
`explains, Tanenbaum discloses a “connection record” or flow key that “is
`generated from ‘some simple function of the data .
`.
`. i.e., the two IP
`
`address and two port numbers” that “identif[ies] a TCP connection for the
`
`communication flow.” Pet. 48 (citing Ex. 1006, .541, 585; Ex. 1001, 7:19—
`
`22). Petitioner also explains that “it would have been obvious to have a flow
`
`key additionally include a next-hop MAC layer address” “in order to verify
`
`the flow key against the information relevant to the connection during
`
`lookup.” Pet. 49 (citing Ex. 1003 111] 30—31, A-14; Ex. 1006, .585). We also
`
`credit Petitioner’s expert’s uncontested testimony that “[a] next-hop MAC
`
`layer address indicates the physical location a packet is first routed on its
`
`way to its final destination for the connection and is therefore information
`
`relevant to the connection.” Pet. 49 (citing Ex. 1003, 30—31, A-14).
`
`

`

`IPR2017-01410
`
`Patent 8,131,880 B2
`
`Patent Owner argues that Petitioner fails to “identify any disclosure in
`
`the prior art of a flow key that includes a first hop MAC,” provide “anything
`
`more than an unadomed conclusion,” provide a “stated rationale in the prior
`
`art for adding additional information, let alone a next-hop MAC address
`
`specifically,” or “explain why a flow key that includes a first hop MAC
`
`address would have been obvious.” PO Resp. 27—29. We are not persuaded
`
`by Patent Owner’s argument at least because Patent Owner does not assert
`
`or demonstrate specific flaws in the rationale provided by Petitioner.
`
`For example, as Petitioner and Petitioner’s expert explain, when
`
`“Ethernet is used,” one of skill in the art would have known that “source and
`
`destination MAC (media access control) addresses” “determine[] the next
`’9 “
`
`hop along the route to the destination
`
`such as a network interface card
`
`(NIC).” See, e. g., Ex. 1003 1111 28, 30, 31. Hence, Petitioner’s evidence
`
`demonstrates that one of skill in the art would have known that transmission
`
`of data in a network to a destination, such as to a network interface card, is
`
`accomplished by a known “MAC address” that identifies a destination of the
`
`data. We agree with Petitioner that it would have been obvious to one of
`
`ordinary skill in the art, when attempting to transmit data in a network to a
`
`destination, to include a known parameter (i.e., a MAC address) that
`
`indicates the destination of the transmitted data. Otherwise, the data would
`
`not be transmitted to the desired destination, the desired destination not
`
`having been identified by the (known) MAC address.
`
`Claim 32 recites an “operation code.” Petitioner argues that the
`
`combination of Thia and Tanenbaum discloses this feature. Pet. 52—55. For
`
`example, Petitioner argues that Thia discloses “checking the header portion
`
`of an incoming packet to see if it matches what is expected or predicted,”
`
`

`

`IPR2017-01410
`
`Patent 8,131,880 B2
`
`subsequently making a “fast-path determination,” then “rout[ing] the packet
`
`.
`
`.
`
`. for fast-path/bypass processing.” Pet. 52—53 (citing Ex. 1015, .003,
`
`.006, .007, .013, .014, Table 1, Fig. 2; Ex. 1006, .585). Petitioner also
`
`explains that it would have been obvious to one of ordinary skill in the art to
`
`“us[e] an operation code .
`
`.
`
`. instructing whether to process the packet on
`
`the” bypass interface by, in one example, “checking the header portion of an
`
`incoming packet to see if it matches,” or, in another example, “a flag .
`
`.
`
`.
`
`signifying that a packet can be fast-pathed.” Pet. 52—55 (citing Ex. 1015,
`
`.004, .009, A-22—A-24).
`
`Patent Owner argues that “Petitioners tacitly admit there is no explicit
`
`disclosure in Thia or Tanenbaum of the claimed ‘operation code’,” that
`
`“Thia does not use an ‘operation code’ for the routing of PDUs,” “does not
`
`need to also associate the PDU with an operation code,” and only discloses a
`
`“PDU header” that supposedly does not include “a component .
`
`.
`
`. to
`
`determine whether it is bypassable.” PO Resp. 30, 32, 39—40. To the extent
`
`that Patent Owner argues that Thia fails to refer to matching a header to
`
`indicate whether the packet is a candidate for avoiding processing by the
`
`host computer (i.e., fast-path processing) as an “operation code,” we are not
`
`persuaded by Patent Owner’s argument at least because this is not an
`
`“ipsissimis verbis” test. In re Bond, 910 F.2d 831, 832 (Fed. Cir. 1990).
`Patent Owner does not explain a sufficient difference between matching a
`
`header to determine if a packet is a candidate for avoiding processing by the
`
`host computer (i.e., fast-path processing) of Thia and the claimed “operation
`
`code,” that is also for determining if a packet is a candidate for avoiding
`
`processing by the host computer.
`
`

`

`IPR2017-01410
`
`Patent 8,131,880 B2
`
`To the extent that Patent Owner argues that an “operation code” is
`
`“associated” with a data packet by indicating a status of the packet, as
`
`recited in claim 32, for example, we agree with Petitioner that Thia discloses
`
`this feature for at least the previously discussed reasons. For example, Thia
`
`discloses indicating that a packet is bypassable by “match[ing] the incoming
`
`PDU headers with a template that identifies the predicted bypassable
`
`headers.” Ex. 1015, .003. One of skill in the art would have understood that
`
`the matching of the header of the packet to a template would have been
`
`“associated” with the packet itself. Otherwise, the header of the packet
`
`would not have been matched with the template, the packet itself having no
`
`“association” with the matching.
`
`Also, as Petitioner points out, Thia discloses,
`
`The “no—in-transit PDU” test can often be avoided. At the
`beginning of data transfer on a new connection,
`it
`is
`automatically satisfied.
`It holds as long as no packet fails a
`bypass test, and it is sufficient to maintain a flag to indicate this.
`Once a packet fails, and goes to the SPS, then a full “no—in-transit
`PDU” test must be performed for each packet until the test
`succeeds, after which control can go back to the flag.
`
`Ex. 1015, .003. Thus, Thia’s flag is used to indicate whether any packet
`
`“fails a bypass test.” Once one packet fails the bypass test, requiring
`
`processing by the host protocol stack (SPS), a more complete test (full no-in-
`
`transit PDU) must be performed on each packet until a next packet passes
`
`the full test and the quicker bypass test can be resumed. Therefore, ’l‘hia’s
`
`flag indicates that the long “no-in-transit PDU” test may be avoided for
`
`packets, in favor of the quicker bypass test, until a packet fails the quick
`
`bypass test. The ordinarily skilled artisan would have understood Thia’s
`
`flag is associated with a packet. More precisely, Thia’s flag appears to be a
`
`

`

`IPR2017-01410
`
`Patent 8,131,880 B2
`
`global flag associated with the processing of all received packets rather than
`
`a unique flag associated only with a single corresponding received packet.
`
`However, the claims don’t preclude such a global association with all
`
`received packets.
`
`Patent Owner argues that Thia fails to provide a.“disclosure or
`
`suggestion of using an operation code to call the BYPASS_START
`
`procedure” and that doing so “would have been superfluous and unnecessary
`
`in View of Thia’s architecture.” PO Resp. 38. Even assuming Patent
`
`Owner’s contention to be correct that Thia fails to disclose using an
`
`operation code to call a “BYPASS_START procedure,” we are still not
`
`persuaded by Patent Owner’s implied argument that Thia therefore somehow
`
`also fails to disclose indicating, with an operation code, whether a packet is a
`candidate for avoiding processing by the host computer (i.e., fast-path
`
`processing). As previously discussed, Thia discloses this feature.
`
`Petitioner argues that the combination of Thia and Tanenbaum
`
`discloses storing the header portion of the packet in a header buffer if the
`
`header conforms to the TCP protocol, as recited in claim 32. Pet. 58—60.
`
`For example, Petitioner argues that one of skill in the art would have
`
`understood “that a buffer is a portion of memory” and that “a packet .
`
`.
`
`.
`
`includes header and data portions” and would have been “placed into a
`
`packet memory.” Pet. 58—59 (citing Ex. 1003 A-30; Ex. 1015 Fig. 4).
`
`Patent Owner argues that the combination of 'l‘hia and Tanenbaum
`
`fails to disclose storing a header portion of a packet in a header buffer
`
`because, according to Patent Owner, Thia discloses (in Fig. 4 of Thia)
`
`storing a packet header in a “Protocol Header” portion of memory but that
`
`the portion of memory (i.e., “Protocol Header”) that stores the header
`
`

`

`IPR2017-01410
`
`Patent 8,131,880 B2
`
`portion of a packet “are not the claimed separate ‘header buffer.” PO Resp.
`
`41; Ex. 1015 Fig. 4. We are not persuaded by Patent Owner’s arguments at
`
`least because Patent Owner does not point out sufficient differences between
`
`the portion of memory that stores a header portion of a packet of Thia and
`
`the “header buffer,” as recited in claim 32, for example. In both cases, a
`
`header portion of a packet is stored in a specified portion of memory.
`
`Patent Owner also argues that Thia fails to disclose storing the header
`
`portion of the packet “if said header conforms to the TCP protocol.” PO
`
`Resp. 42. However, we are persuaded by Petitioner and Petitioner’s expert
`
`that one of ordinary skill in the art, having ordinary creativity and not being
`
`an automaton, would have understood that, when performing a process of
`
`“fast—path” processing for TCP, the header would conform to the TCP
`
`protocol. Otherwise, one of skill in the art would have understood that the
`
`process would not operate as desired, the header not conforming to the
`
`protocol in use in the system.
`
`Petitioner argues that the combination of Thia and Tanenbaum
`
`discloses a “flow re-assembler” that re-assembles a data portion of a packet
`
`with a data portion of another packet, as recited in claims 41 and 42, for
`
`example, that Tanenbaum “suggests that the re-assembler is provided on a
`
`network interface,” and that Thia “provides an express disclosure.” Pet.
`
`77—78 (citing Ex. 1006, .498). In particular, Petitioner argues that
`Tanenbaum “discloses that the TCP protocol processes packets and re-
`
`assembles the data portions” and that “packets conforming to the TCP
`
`protocol are processed and the data portions .
`
`.
`
`. are re-assembled in the
`
`correct order together into a buffer.” Pet. 57—5 8, 77.
`
`10
`
`

`

`IPR2017-01410
`
`Patent 8,131,880 B2
`
`Patent Owner argues that “Petitioners admit Tanenbaum does not
`
`disclose a flow re—assembler,” as recited in claim 41, but fails to demonstrate
`
`that Petitioner, in fact, “admitted” that Tanenbaum fails to disclose the
`
`disputed claim limitation or how the re-assembly of data portions of packets
`
`of Tanenbaum (relied upon by Petitioner) differs from the reassembly of
`data portions of packets, as recited in claim 41. In both cases, data portions
`
`of packets are reassembled. PO ReSp. 43.
`
`Petitioner argues that the combination of Thia and Tanenbaum
`
`discloses a processor that maintains a TCP connection that is stored as a
`
`control block on the network interface, as recited in claims 41 and 42. Pet.
`
`78—8 1. For example, Petitioner argues that “[t]his limitation reflects
`
`standard TCP protocol operation .
`
`.
`
`. on a network interface” in which “a
`
`packet is received [and] classified .
`
`.
`
`. [and] processed” including “updating
`
`the TCP connection for the communication flow.” Pet. 78. In addition,
`Petitioner argues that Thia discloses “control blocks to store information” by
`
`“sending information .
`
`.
`
`. to the bypass chip” that are “stored in a process
`
`control block.” Pet. 79 (citing Ex. 1015, .009).
`
`Patent Owner argues that Thia and Tanenbaum fail to disclose a
`
`“processor.” PO Resp. 45, 50. In the absence of sufficient evidence to
`
`demonstrate persuasively that one of skill in the art, given the level of skill
`
`in the art at the time of the invention, would not have understood that a
`
`“processor” is used to process data, we agree with the Petitioner that one of
`
`skill in the art being of ordinary creativity and not being an automaton would
`
`have understood that a “processor” would have been utilized in a system that
`
`“processes” packets (as disclosed by the combination of Thia and
`
`Tanenbaum).
`
`11
`
`

`

`IPR2017-01410
`
`Patent 8,131,880 B2
`
`Patent Owner does not provide additional argument with respect to the
`
`other challenged claims.
`
`Combinabilig
`Petitioner argues that it would have been obvious to one of ordinary
`
`skill in the art to have combined the teachings of Thia and Tanenbaum. Pet.
`
`30—32. In particular, Petitioner argues that Thia discloses that one of
`
`ordinary skill in the art would have known and understood “offloading
`
`network protocol processing,” “would have recognized that 081 and TCP/1P
`
`share many similarities,” and that the “architecture of [the] bypass
`
`implementation” is used for “any standard protocol.” Pet. 31—32; Ex. 1015,
`.003; Ex. 1003 1] 110; Ex. 1006, 056—057.
`V
`
`Petitioner also argues that Tanenbaum discloses a similar system for
`
`“expedited network protocol processing similar to Thia” including “the
`
`concept of Header Prediction” and that “many TCP implementations use it.”
`
`Pet. 33 (citing Ex. 1006, 584—585). Hence, as Petitioner points out, it
`
`would have been obvious to one of ordinary skill in the art to have combined
`
`the known process of “header prediction” in “fast-path processing” with
`
`“protocol processing of layered protocols” using “any standard protocol’
`
`(i.e., Thia) with the known system of “header prediction” in “fast-path
`
`processing” (i.e., Thia or Tanenbaum) using “TCP implementations” (i.e.,
`
`Tanenbaum) as a known “standard protocol” (i.e., Thia and Tanenbaum) to
`
`achieve the predictable and expected result of a system for “fast-path
`
`processing” using “any standard protocol” such as “TCP implementations.”
`
`We are persuaded by Petitioner’s arguments. “The combination of familiar
`
`elements according to known methods is likely to be obvious when it does
`
`12
`
`

`

`IPR2017-01410
`
`Patent 8,131,880 B2
`
`no more than yield predictable results.” KSR Int ’1 Co. v. Teleflex, Inc., 550
`
`US. 398, 416 (2007).
`
`Patent Owner argues that it would not have been obvious to one of
`
`ordinary skill in the art to have combined the cited references because
`
`“Tanenbaum teaches away from performing protocol processing using
`
`anything’other than the host CPU.” PO Resp. 54 (citing Ex. 1006, .588—
`
`.589). However, the cited portion of Tanenbaum discloses that if an effort is
`
`made to “avoid having the network coprocessor be as expensive as the main
`
`CPU, it is often a slower chip,” which results in the “(fast) CPU [being] idle
`
`waiting for the second (slow) CPU to do the critical work.” Ex. 1006, .588—
`
`.589. Hence, Tanenbaum actually discloses that the system may not be
`
`optimal if a less “expensive” CPU is selected and the “slow CPU” “do[es]
`
`the critical work,” which is directed to the cost of the CPU used and not
`
`whether a “host CPU” is used or not. We are not persuaded by Patent
`
`Owner’s argument.
`
`Patent Owner argues that it would not have been obvious to one of
`
`ordinary skill in the art to have combined the cited references because
`
`“Tanenbaum explains the lack of interest in OSI.” PO Resp. 55. However,
`
`as previously discussed, Petitioner relies on Tanenbaum for disclosing
`
`TCP/IP and not OSI. Even assuming Patent Owner’s contention to be
`
`correct that Tanenbaum supposedly discloses a “lack of interest in OSI,”
`
`Patent Owner does not assert or demonstrate persuasively that this alleged
`
`disclosure regarding an supposed “lack of interest in OSI” sufficiently
`
`refutes Petitioner’s prima facie showing of obviousness of the disputed
`
`claims over the combination of Thia and Tanenbaum.
`
`13
`
`

`

`IPR2017—01410
`
`Patent 8,131,880 B2
`
`Patent Owner argues that it would not have been obvious to one of
`
`ordinary skill in the art to have combined the cited references because Thia
`
`discloses that “bypass could be used ‘for any standard protocol’ .
`
`.
`
`. [but
`
`actually means] any standard OSI protocol.” PO Resp. 55. We are not
`
`persuaded by Patent Owner’s argument at least because Patent Owner does
`
`not provide sufficient evidence supporting Patent Owner’s allegation that
`
`one of skill in the art would have understood that Thia intended to disclose
`
`“any OSI protocol” but inadvertently discloses “any standard protocol.” We
`
`agree with Petitioner (Pet. 31—36 (citing Ex. 1003)) that one of ordinary skill
`
`in the art, when confronted with the phrase “any standard protocol,” would
`
`have understood the phrase to mean “any standard protocol” and would have
`
`not instead understood the phrase to mean something else — namely, “any
`
`OSI protocol.” Even assuming Thia discloses “any standard OSI protocol”
`
`(Thia does not disclose this limitation, however), Patent Owner does not
`
`sufficiently demonstrate that one of skill in the art would have understood
`
`“any standard OSI protocol” to also mean “but not the TCP/IP protocol.”
`
`Patent Owner argues that it would not have been obvious to one of
`
`ordinary skill in the art to have combined the cited references because Thia
`
`discloses “modify[ing] existing OSI stack software” but fails to disclose “a
`
`TCP/IP protocol stack.” PO Resp. 57. We note that Thia discloses a system
`
`that is “based on .
`
`.
`
`. a generalization of Jacobson's "Header Prediction"
`
`algorithm .
`
`.
`
`. for TCP/IP.” Ex. 1015, .002. Patent Owner does not explain
`
`how Thia’s system that is based on “TCP/IP” actually does not use a
`
`“TCP/IP protocol stack.” In any event, even assuming Patent Owner’s
`
`contention to be correct that Thia supposedly fails to disclose TCP/IP, Patent
`
`Owner does not assert or demonstrate persuasively that the combination of
`
`14
`
`

`

`1PR2017-01410
`
`Patent 8,131,880 B2
`
`Thia and Tanenbaum also fails to disclose TCP/IP. As previously discussed,
`
`the combination of Thia and Tanenbaum discloses this feature.
`
`Secondagy Considerations
`
`Patent Owner also argues that it would not have been obvious to one
`
`of ordinary skill in the art to have combined the teachings of Thia and
`
`Tanenbaum because there was a “long-felt but unsolved need” “to enhance
`
`the efficiency of network protocol processing and network traffic
`
`management” and that “[t]he nexus between the long-felt need and the
`
`claimed invention” is to “solve[]” “bottlenecks.” PO Resp. 58—59. We are
`
`not persuaded by Patent Owner’s argument for at least the reasons set forth
`
`by Petitioner. Pet. Reply 20—21. We agree with Petitioner that Patent
`
`Owner has not persuasively established any connection between resolution
`
`of those bottlenecks and the patented invention. To be accorded substantial
`
`weight, there must be a nexus between the claimed invention and the
`
`evidence of secondary considerations. In re GPAC Inc, 57 F.3d 1573, 1580
`
`(Fed. Cir. 1995). Nexus is a legally and factually sufficient connection
`
`between the objective evidence and the claimed invention, such that the
`
`objective evidence should be considered in determining nonobviousness.
`
`Demaco Corp. v. F. von LangsdorflLicensing Ltd., 851 F.2d 1387, 1392
`(Fed. Cir. 1988). The burden of showing that there is a nexus lies with the
`
`Patent Owner. See Paulsen, 30 F.3d at 1482. In the absence of an
`
`established nexus with the claimed invention, secondary consideration
`
`factors are not entitled to much, if any, weight and generally have no bearing
`
`on the legal issue of obviousness. See In re Vamco Mach. & Tool, Inc, 752
`
`F.2d 1564, 1577 (Fed. Cir. 1985). Moreover, to the extent that Patent Owner
`
`argues that there was a “long-felt need” to solve “bottlenecks,” Patent
`
`15
`
`

`

`IPR2017-01410
`
`Patent 8,131,880 B2
`
`Owner does not assert or demonstrate persuasively that any of the disputed
`
`claims recites “solving bottlenecks.” To the extent that Patent Owner argues
`
`that some unspecified limitation recited in claim 32 constitutes the required
`
`“nexus” to the alleged “long-felt need,” we note that Thia previously
`
`satisfied this need. The “long-felt need” must not have been satisfied by
`
`another before the patentee. Newell Co. v. Kenney Mfg. Co., 864 F.2d 757,
`
`768 (Fed. Cir. 1988).
`
`Patent Owner argues that it would not have been obvious to one of
`
`ordinary skill in the art to haVe combined the teachings of the cited
`
`references because “the challenged claims .
`
`.
`
`. enjoyed great commercial
`
`success” by “the offloading .
`
`.
`
`. technology described in the challenged
`
`claims.” PO Resp. 60. We are not persuaded by Patent Owner’s argument
`
`for at least the reasons set forth by Petitioner. Pet. Reply 21—22. Patent
`
`Owner does not provide sufficient information or evidence to establish that
`
`the claimed invention, in fact, experienced “commercial success.” In fact, as
`
`Petitioner argues, evidence of record indicates that the claimed invention
`
`“never went anywhere” and was ultimately “deprecated.” Pet. Reply 22
`
`(citing Exs. 1224, 1227, 1228, 1230). In any event, even assuming that the
`
`claimed invention experienced “commercial success,” as Patent Owner
`
`alleges, the feature Patent Owner alleges to have resulted in the presumed
`
`“commercial success” was previously disclosed by Thia. See discussion
`
`above. Under these circumstances, any alleged commercial success stems
`
`from what was known in the prior art so that there can be no nexus. Tokaz'
`
`Corp. v. Easton Enters, Inc., 632 F.3d 1358, 1369 (Fed. Cir. 2011).
`
`Patent Owner argues that it would not have been obvious to one of
`
`ordinary skill in the art to have combined the teachings of the cited
`
`16
`
`

`

`IPR2017-Ol410
`
`Patent 8,131,880 B2
`
`references because “Alacritech’s patent portfolio covering network
`
`acceleration techniques was the subject of several successful commercial
`
`licenses.” PO Resp. 60. We are not persuaded by Patent Owner’s
`
`arguments for at leaSt the reasons set forth by Petitioner. Pet. Reply 22—23.
`
`For example, as Petitioner explains, Patent Owner does not demonstrate
`sufficiently that the alleged licenses were the result of the claimed invention
`
`and, therefore, fails to establish a nexus between the claimed invention and
`
`the alleged licenses. See, e. g., Pet. Reply 22—23. Rather, as Petitioner points
`
`out, the licenses were the result of reasons not related to the claimed
`
`invention (e.g., as a result of an infringement lawsuit). Pet. Reply 23 (citing
`
`Ex. 2038). In any event, even assuming that there were “successful
`
`commercial licenses,” as Patent Owner contends, and the alleged “successful
`
`commercial licenses” were the result of some unspecified feature recited in
`
`claim 32, for example, as previously discussed, Thia discloses these features.
`
`There can be no nexus if the feature relied upon was previously known in
`
`the prior art. Tokaz' Corp, 632 F.3d at 1369.
`
`Patent Owner argues that it would not have been obvious to one of
`
`ordinary skill in the art to have combined the teachings of the cited
`
`references because the claimed invention was alleged to be the subject of
`
`industry “praise.” PO Resp. 61—62. We are not persuaded by Patent
`
`Owner’s argument for at least the reasons set forth by Petitioner. Pet. Reply
`
`23. For example, Patent Owner argues that various sources stated that
`
`Patent Owner’s network interface card “is able to sustain network
`
`bandwidth,” “achiev[es] lower processor utilization,” and “is an
`
`evolutionary advancement of [Patent Owner’s] .
`
`.
`
`. protocol acceleration”
`
`(PO Resp. 61—62 (citing Ex. 2039 11 4; Ex. 2026 11 189; Ex. 2026 11 190)), but
`
`17
`
`

`

`IPR2017-01410
`
`Patent 8,131,880 B2
`
`Patent Owner does not demonstrate sufficiently that any of these alleged
`
`statements, assuming that any of these statements would have been
`
`considered to be “praise” at all, pertain to the claimed invention and in what
`
`way. Hence, Patent Owner fails to establish sufficient nexus between the
`
`alleged “praise” and the claimed invention.
`
`Patent Owner argues that it would not have been obvious to one of
`
`ordinary skill in the art to have combined the teachings of the cited
`
`references because “prior attempts at ‘TCP offload [have] repeatedly
`
`failed.’” PO Resp. 62 (citing Ex. 2041, 001—013). We are not persuaded by
`
`Patent Owner’s argument for at least the reasons set forth by Petitioner. Pet.
`
`Reply 24. Even if TCP offload is a form of network processing offload, the
`
`Patent Owner provides no evidence linking the failure of others to any
`
`limitations of the challenged claims. Also, as Petitioner points out, Thia
`
`itself discloses a “generalization of the ‘Header Prediction’ algorithm for
`
`TCP/1P” and that “its teachings are compatible with ‘any standard
`
`protocol.”’ Pet. Reply 2—3. Patent Owner states that “TCP offload”
`
`supposedly “repeatedly failed” but does not explain sufficiently how a
`
`system (of Thia) that is based upon an “algorithm for TCP/1P” and -
`
`applicable to “any standard protocol” (which one of skill in the art would
`
`have understood to include TCP because, at least, the Thia system is a
`
`generalization of such a system) would have failed. We note that Thia does
`
`not disclose that its generalized “TCP/1P” offload system fails.
`
`Patent Owner argues that it would not have been obvious to one of
`
`ordinary skill in the art to have combined the teachings of the cited
`
`references because “experts and industry were skeptical of offloading
`
`processing of complex protocols.” PO Resp. 63. We are not persuaded by
`
`18
`
`

`

`IPR2017-01410
`Patent 8,131,880 B2
`
`Patent Owner’s argument for at least the reasons set forth by Petitioner. Pet.
`
`Reply 24. For example, as previously discussed, Thia, for example,
`
`discloses “offloading processing of complex protocols.” There can be no
`
`nexus if the feature relied upon was previously known in the prior art. Tokaz'
`
`Corp, 632 F.3d at 1369. Nor would one of ordinary skill in the art have
`
`been “skeptical” of procedures (e.g., offloading) already disclosed in the
`
`prior art (e. g., Thia).
`
`Real Parties in Interest
`
`Intel Corporation identifies itself as a real party in interest in these
`
`proceedings and represents that “[n]o other parties exercised or could have
`
`exercised control over this Petition; no other parties funded or directed this
`
`Petition.” Pet. 2. Patent Owner argues that “Dell is both Intel’s and
`
`Cavium’s customer and indemnitee,” that “Del

Accessing this document will incur an additional charge of $.

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

Accept $ Charge

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.

We are unable to display this document.

PTO Denying Access

Refresh this Document
Go to the Docket