Paper: 10
`Trials@uspto.gov
`571-272-7822 Entered: November 28, 2017
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`INTEL CORPORATION,
`Petitioner,
`
`v.
`
`ALACRITECH, INC.,
`Patent Owner.
`____________
`
`Case IPR2017-01406
`Patent 7,673,072 B2
`____________
`
`
`
`Before STEPHEN C. SIU, DANIEL N. FISHMAN, and
`WILLIAM M. FINK, Administrative Patent Judges.
`
`FINK, Administrative Patent Judge.
`
`
`
`
`DECISION
`Institution of Inter Partes Review
`37 C.F.R. § 42.108
`
`
`
`I. INTRODUCTION
`Intel Corporation (“Petitioner”) requests inter partes review of claims
`1–21 of U.S. Patent No. 7,673,072 B2 (“the ’072 patent,” Ex. 1001) pursuant
`to 35 U.S.C. §§ 311 et seq. Paper 1 (“Pet.”). Alacritech, Inc. (“Patent
`Owner”) filed a preliminary response. Paper 9 (“Prelim. Resp.”). Institution
`
`
`Trials@uspto.gov
`571-272-7822 Entered: November 28, 2017
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`INTEL CORPORATION,
`Petitioner,
`
`v.
`
`ALACRITECH, INC.,
`Patent Owner.
`____________
`
`Case IPR2017-01406
`Patent 7,673,072 B2
`____________
`
`
`
`Before STEPHEN C. SIU, DANIEL N. FISHMAN, and
`WILLIAM M. FINK, Administrative Patent Judges.
`
`FINK, Administrative Patent Judge.
`
`
`
`
`DECISION
`Institution of Inter Partes Review
`37 C.F.R. § 42.108
`
`
`
`I. INTRODUCTION
`Intel Corporation (“Petitioner”) requests inter partes review of claims
`1–21 of U.S. Patent No. 7,673,072 B2 (“the ’072 patent,” Ex. 1001) pursuant
`to 35 U.S.C. §§ 311 et seq. Paper 1 (“Pet.”). Alacritech, Inc. (“Patent
`Owner”) filed a preliminary response. Paper 9 (“Prelim. Resp.”). Institution
`
`
`
`IPR2017-01406
`Patent 7,673,072 B2
`
`of an inter partes review is authorized by statute when “the information
`presented in the petition . . . and any response . . . shows that there is a
`reasonable likelihood that the petitioner would prevail with respect to at least
`1 of the claims challenged in the petition.” 35 U.S.C. § 314(a); see
`37 C.F.R. § 42.108. Upon consideration of the Petition and Preliminary
`Response, we conclude the information presented shows there is a
`reasonable likelihood that Petitioner would prevail in establishing the
`unpatentability of at least one of claims 1–21 of the ’072 patent.
`
`A. Related Matters
`We are informed that the ’072 patent is presently related to the
`following: Alacritech, Inc. v. CenturyLink, Inc., Case No. 2:16-cv-00693-
`JRG-RSP (E.D. Tex.); Alacritech, Inc. v. Wistron Corp., Case No. 2:16-cv-
`00692-JRG-RSP (E.D. Tex.); and Alacritech, Inc. v. Dell Inc., Case No.
`2:16-cv-00695-RWS-RSP (E.D. Tex.). Pet. 3.
`
`B. The ’072 Patent (Ex. 1001)
`The ’072 patent describes a system and method “that greatly increases
`the speed of [processing network communication] and the efficiency of
`transferring data being communicated.” Ex. 1001, 5:24–27.
`
`C. Illustrative Claim
`Independent claim 1, reproduced below, is illustrative of the claimed
`subject matter:
`1. A method comprising:
`establishing, at a host computer, a transport layer
`connection, including creating a context that includes protocol
`header information for the connection;
`transferring the protocol header information to an interface
`
`2
`
`
`
`IPR2017-01406
`Patent 7,673,072 B2
`
`device;
`transferring data from the network host to the interface
`device, after transferring the protocol header information to the
`interface device;
`dividing, by the interface device, the data into segments;
`creating headers for the segments, by the interface device,
`from a
`template header containing
`the protocol header
`information; and
`prepending the headers to the segments to form transmit
`packets.
`Id. at 97:17–31.
`
`D. Asserted Grounds of Unpatentability
`Petitioner asserts that claims 1–21 are unpatentable on the following
`grounds (Pet. 14–15):
`
`Basis
`Reference(s)
`Erickson1 and Tanenbaum2 § 103
`
`Claims challenged
`1–21
`
`II. DISCUSSION
`A. Real Party 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 [P]etition; no other parties funded or directed this
`Petition.” Pet. 2. Patent Owner argues that “the Petition . . . fails to identify
`at least Dell Inc. (‘Dell’) and Cavium Inc. (‘Cavium’)” as real parties-in-
`interest and that “[t]he Board should deny institution . . . because the Petition
`
`1 U.S. Patent No. 5,768,618, issued June 16, 1998 (“Erickson,” Ex. 1005).
`2 Andrew S. Tanenbaum, COMPUTER NETWORKS (3rd ed. 1996)
`(“Tanenbaum,” Ex. 1006).
`
`3
`
`
`
`IPR2017-01406
`Patent 7,673,072 B2
`
`fails to identify all real parties in interest as required by 35 U.S.C.
`§ 312(a)(2) and 37 CFR § 42.8(b)(1).” Prelim. Resp. 12–13. We disagree.
`As an initial matter, as Patent Owner points out, in determining
`whether a party is a real party-in-interest, “[a] common consideration is
`whether the non-party exercised or could have exercised control over a
`party’s participation in a proceeding.” Id. at 13–14 (citing Office Patent
`Trial Practice Guide, 77 Fed. Reg. 48756, 48759–60). Patent Owner further
`argues that “Intel has agreed to defend and partially indemnify Dell,” “Intel
`is Dell’s supplier with regard to Dell’s accused products,” “Intel admitted
`that it would have to work closely with Dell in . . . litigation,” “Intel also
`admitted that it has a close relationship to Dell financially in the district
`court case,” “Intel chose . . . to passively reimburse Dell [and also] play an
`active role to assist, protect, and defend Dell,” “Dell [was] originally
`accused of infringing the ’072 patent in the district court case, not Intel,”
`“Intel’s products were not accused in the original pleading,” “Dell desires
`review of the ’072 Patent,” “Dell and Intel have repeatedly coordinated their
`invalidity theories,” “Dell and Intel also shared a technical expert, Mr. Mark
`Lanning,” and that “Intel has effective choice of invalidity theories and
`proofs.” Id. at 14–20.
`Even accepting all of these contentions, for purposes of this Decision,
`we are not persuaded on these facts that Dell exercised or could have
`exercised control over the preparation or filing of the present Petition.
`Indeed, the alleged financial relationship with Intel as the indemnitor of Dell
`suggests that, if anything, Intel would be the one to control the preparation
`and filing of and present Petition. The other assertions relating to
`coordinating theories and sharing experts are common activities between
`
`4
`
`
`
`IPR2017-01406
`Patent 7,673,072 B2
`
`cooperating co-defendants in related litigation and are not suggestive of
`control of or ability to control this petition. See Weatherford Int’l, LLC, et
`al. v. Packers Plus Energy Services, Inc., Case IPR2016-01514, slip op. 12–
`16 (PTAB Feb. 22, 2017) (Paper 23).
`Patent Owner also argues that “Cavium is also a supplier of Dell,”
`“petitions filed by Intel and Cavium also share an identical declaration from
`the same expert, Dr. Robert Horst,” and “Cavium also filed an almost
`verbatim petition.” Prelim. Resp. 19. However, for reasons similar to those
`discussed above, we are not persuaded by Patent Owner’s argument that
`Cavium should have been identified as a real party-in-interest on these facts.
`We reject Patent Owner’s argument that we deny institution on this
`basis for an additional reason. Significantly, Patent Owner does not allege
`that inclusion of either Dell or Cavium as a real party in interest would have
`barred the Petition under 35 U.S.C. § 315. Aside from a bar defense, under
`the Board’s precedential decision in Lumentum Holdings, Inc. v. Capella
`Photonics, Inc., our jurisdiction to consider a petition does not require a
`“correct” identification of all real parties in interest in a petition. Case
`IPR2015-00739, slip op. at 6 (PTAB March 4, 2016) (Paper 38)
`(precedential); see also Blue Coat Sys., Inc. v. Finjan, Inc., Case IPR2016-
`01444, slip op. 10 (PTAB July 18, 2017) (Paper 11) (“Evidence [of failure to
`identify all real parties in interest] is, at best, suggestive of an issue that is
`not jurisdictional.”). Consequently, even if Dell and Cavium should be
`named real parties-in-interest, as Patent Owner alleges, failure to identify
`them as such at the time the Petition was filed does not require us to
`terminate the proceeding. Indeed, later PTAB decisions indicate that a
`petition may be corrected after institution of trial to add a real party in
`
`5
`
`
`
`IPR2017-01406
`Patent 7,673,072 B2
`
`interest if warranted without assigning a new filing date to the petition. E.g.,
`Axon EP, Inc., et al. v. Derrick Corp., Case IPR2016-00642, slip op. at 3
`(PTAB November 21, 2016) (Paper 17).
`We have considered Patent Owner’s argument that “[f]inding that
`Dell and Cavium are real parties in interest is . . . consistent with the express
`legislative intent concerning the need for quiet title.” Prelim. Resp. 20. For
`example, Patent Owner contends that
`If Intel were to be able to institute this IPR without adding Dell
`and Cavium as real parties in interest, Dell and Cavium would be
`able to use the same prior art relied upon here in other cases even
`if the patent is held to be valid in this IPR. This would be
`harassment through repeated litigation in violation of legislative
`intent, as Intel, Dell, and Cavium would be able to “double dip”
`and use the same invalidity theories to defend the same accused
`products twice.
`
`Id. at 21. We disagree. Notwithstanding our preliminary determination here
`that Dell and Cavium have not been shown to be real parties-in-interest, our
`decision does not preclude Patent Owner from raising a bar defense in a
`future proceeding and attempting to develop evidence sufficient to support
`such a defense.3
`
`B. Claim Construction
`In an inter partes review, we construe claim terms in an unexpired
`patent according to their broadest reasonable construction in light of the
`specification of the patent in which they appear. 37 C.F.R. § 42.100(b).
`
`
`3 Cavium has moved to join this proceeding, see Case IPR2017-01707
`(Paper 3), and Dell would appear to be time-barred, under 35 U.S.C.
`§ 315(b), regardless in any such proceeding. See Prelim. Resp. 12 n. 4
`(noting June 30, 2016 as the date of filing the complaint against Dell).
`6
`
`
`
`IPR2017-01406
`Patent 7,673,072 B2
`
`Consistent with the broadest reasonable construction, claim terms are
`presumed to have their ordinary and customary meaning as understood by a
`person of ordinary skill in the art in the context of the entire patent
`disclosure. In re Translogic Tech., Inc., 504 F.3d 1249, 1257 (Fed. Cir.
`2007).
`“context”
`Petitioner contends the term “context,” recited in independent claims
`1, 9, and 15, is indefinite, “because the specification and claims do not
`inform a [person of ordinary skill in the art] what information is necessary or
`sufficient to be a context.” Pet. 25. Nonetheless, for purposes of this
`Decision, “Petitioner submits that a ‘context’ for a connection must include
`at least data regarding a connection.” Id. Patent Owner contends that
`Petitioner’s contention that the term “context” is indefinite “should end the
`Board’s inquiry” into claims 1–21. Prelim. Resp. 10.
`We do not agree with Patent Owner that Petitioner’s contention that
`the term “context” is indefinite for purposes of a related proceeding “should
`end the Board’s inquiry.” Indeed, other than noting their positions in related
`litigation, neither party provides any analysis one way or the other in regards
`to whether the claim is indefinite. See Pet. 25; Prelim. Resp. 10–11. As to
`whether the scope of the term is discernable, we observe that claim 1 does
`not use the term “context” in isolation, but states “the context that includes
`protocol header information for the connection.” Thus, it is apparent from
`the claim itself that the term “context” at least requires protocol header
`information.
`
`7
`
`
`
`IPR2017-01406
`Patent 7,673,072 B2
`
`This is consistent with its meaning in the specification. For example,
`with regard to protocol stack 44 on host CPU 28 in Figure 2, the
`specification explains:
`The upper layer interface 42, along with the CPU 28 and any
`related controls can send or retrieve a file to or from the upper
`layer 46 or storage 35, as shown by arrow 48. A connection
`context 50 has been created, as will be explained below, the
`context summarizing various features of the connection, such as
`protocol type and source and destination addresses for each
`protocol layer.
`Ex. 1001, 7:62–8:2 (emphasis added), 30:54–58. In other words, similar to
`claim 1’s “context,” the “connection context” includes data relating to the
`connection for each relevant protocol layer.
`In view of the foregoing, and for purposes this Decision, we do not
`find that the scope of the claim requires “considerable speculation,” In re
`Steele, 305 F.2d 859, 862–63 (CCPA 1962), such that it would be improper
`for us to analyze the challenged claims under 35 U.S.C. § 103(a). Patent
`Owner argues that “context” does not otherwise require construction.
`Prelim. Resp. 13. We agree. Because neither party presents arguments in
`support of an explicit construction or, in their contentions, rely on a
`particular scope for this term beyond that which the claim itself requires
`(i.e., protocol header information), we determine that no explicit
`construction is necessary at this stage of the proceeding.
`Neither party presents arguments that turn on the construction of other
`claim terms. Accordingly, at this stage of the proceeding, we determine that
`it is not necessary to provide an express interpretation of any other claim
`terms.
`
`8
`
`
`
`IPR2017-01406
`Patent 7,673,072 B2
`
`C. Asserted Unpatentability of Claims 1–21
`over Erickson and Tanenbaum
`Petitioner contends claims 1–21 are unpatentable as directed to
`
`obvious subject matter over the combination of Erickson and Tanenbaum.
`Pet. 34–76.
`
`1. Overview of Erickson
`Erickson is directed to a “method of controlling an input/output (I/O)
`
`device connected to a computer to facilitate fast I/O data transfers.” Ex.
`1005, Abstract. Figure 3 of Erickson is reproduced below:
`
`
`Figure 3 depicts data flow in accordance with Erickson’s invention. As
`shown in Figure 3, slow application 306 uses normal stream processing 308
`and pass-through driver 310 to send information to I/O device adapter 314 to
`commodity interface 322. Id. at 4:53–61. Alternatively, fast applications
`302 and 304 send information directly to I/O adapter 314 via “VIRTUAL
`HARDWARE” 316 and 318 avoiding the overhead of the streams
`processing and pass-through driver. Id. at 4:61–5:3.
`
`9
`
`
`
`IPR2017-01406
`Patent 7,673,072 B2
`
`2. Overview of Tanenbaum
`Tanenbaum describes general principles of data transmission in
`computer networks. Ex. 1006.
`
`3. Analysis
`Petitioner contends claims 1–21 are unpatentable under 35 U.S.C.
`§ 103(a) as obvious over the combination of Erickson and Tanenbaum. Pet.
`34–76. Petitioner relies on the testimony of Dr. Robert Horst to support its
`contentions regarding how the cited references describe the claim
`limitations. Id. (citing Ex. 1003). At this stage of the proceeding, Petitioner
`has accounted sufficiently for the limitations of at least 1 of the claims
`challenged in the Petition (i.e., claim 1) and provided sufficient articulated
`reasoning with rational underpinning to support the conclusion of
`obviousness.
`“A method comprising: establishing, at a host computer, a
`transport layer connection, including creating a context that
`includes protocol header information for the connection”
`Petitioner contends Erickson discloses an I/O device adapter 314 is
`connected to a host computer and that a user process running on the host
`computer establishes a “transport layer connection.” Pet. 38 (citing Ex.
`1005, 1:65–67, 6:1–9; Ex. 1003, Appendix A, 1.1). Petitioner further
`contends the user process creates a “context” by “opening a device driver
`and specifying the protocol type (e.g., UDP or TCP).” Id. at 39–40 (citing
`Ex. 1005, 6:1–9, 8:2–9). According to Petitioner, the created context
`“includes protocol header information,” as the claim requires, because it is
`described as “including ‘almost everything’ concerning a UDP datagram
`‘except the actual user data.’” Id. at 40 (citing Ex. 1005, 6:57–7:4).
`Furthermore, Petitioner contends, the context is “for the connection,”
`
`10
`
`
`
`IPR2017-01406
`Patent 7,673,072 B2
`
`because it discloses TCP scripts which are inherently connection oriented.
`Id. at 41 (citing Ex. 1003, Appendix A, 1.1).
`“transferring the protocol header information to an interface
`device”
`Petitioner contends Erickson I/O device adapter 314 is the claimed
`“interface device.” Pet. 41. Petitioner also contends that Erickson’s
`datagram template 702 in the I/O device adapter’s memory, comprises
`protocol header information that was transferred to the I/O device adapter
`from the host computer. Id. at 41–42 (citing Ex. 1005, 7:39–41, 5:37–51,
`8:2–4).
`“transferring data from the network host to the interface device,
`after transferring the protocol header information to the
`interface device”
`Petitioner contends that in Erickson, data is transferred from the host
`to the interface device, after transferring the protocol header information to
`the interface device, because template 702 resides in the adapter’s memory
`before the script is executed to store data in the I/O device adapter’s
`memory. Id. at 42–43 (quoting Ex. 1005, 7:39–48 (“FIG. 7 is a block
`diagram illustrating a UDP datagram template 702 (without a user data area)
`residing in the I/O device adapter’s memory. . . . The I/O device adapter
`stores the user data provided by the user process in the I/O device adapter’s
`memory, and then transmits the completed UDP datagram 702 over the
`media.”).
`“dividing, by the interface device, the data into segments”
`Petitioner contends Erickson in combination with Tanenbaum
`discloses this limitation. Pet. 43. Petitioner contends that, although
`Erickson’s exemplary context is UDP, it also discloses the use of TCP/IP
`and refers readers to the 1981 edition of Tanenbaum and discloses use of
`11
`
`
`
`IPR2017-01406
`Patent 7,673,072 B2
`
`TCP/IP scripts. Pet. 34–35 (citing Ex. 1005, 4:38–43); id. at 44 (citing Ex.
`1005, 5:47–51). Petitioner provides evidence that a person of ordinary skill
`in the art would have been motivated to implement “fast path” TCP/IP on
`Erickson’s I/O device adapter in view of the 1996 version of Tanenbaum
`(i.e., Ex. 1006) with a high expectation of success to take advantage of
`TCP/IP’s popularity for Internet and World Wide Web processing. Id. at
`35–38 (citing Ex. 1003 ¶¶ 137–148).
`Petitioner further contends that Tanenbaum discloses that TCP/IP data
`is exchanged in segments. Pet. 43 (citing Ex. 1006, 525 (“The sending and
`receiving TCP entities exchange data in the form of segments.”), 522 (“A
`TCP entity accepts user data streams from local processes, breaks them up
`into pieces . . . and sends each piece as a separate IP datagram.”).4 Petitioner
`contends that the “transport entity, which does the dividing, can be on a
`network interface card (network interface device).” Id. at 43–44 (citing Ex.
`1006, 480). According to Petitioner,
`A [person of ordinary skill in the art] would know how to
`modify Erickson’s UDP script (udpscript at Ex.1005, Erickson at
`7:51-64) so that, rather than filling in the UDP Length and
`Checksum shown in Erickson, the modified script would fill in
`the TCP Sequence number, Length and Checksum. This script
`involves minimal changes from the UDP script. Ex.1003, Horst
`Decl. Appendix A limitation 1.4. The “dividing, by the interface
`device, the data into segments” limitation is met by the foregoing
`obvious TCP script for Erickson. Erickson’s senduserdatagram
`(Ex.1005, Erickson at 7:23-32) user process triggers the I/O
`device adapter to send each segment, by “spanking” the GO
`register. The adapter calculates the TCP checksum, transmits the
`packet, updates the shared state in Hardware Register 504, and
`
`4 We refer to the original page numbering in Tanenbaum, not the exhibit
`page numbers added by Petitioner.
`
`12
`
`
`
`IPR2017-01406
`Patent 7,673,072 B2
`
`waits for GO to be set again for the next segment. Repeated
`invocations of the TCP script (by repeatedly spanking the GO
`register) with pointers to data for consecutive segments result in
`the interface device dividing the user data stream into TCP
`segments.
`Pet. 44–45. Petitioner contends other TCP scripts would also have been
`obvious modifications to Erickson. Id. at 45–46 (citing Ex. 1003, Appendix
`A, 1.4).
`
`Patent Owner advances various arguments as to why the proposed
`
`combination does not teach dividing the data into segments or teaches away
`from such a combination.
`
`First, Patent Owner contends Petitioner’s cites to Tanenbaum are out
`of context and unrelated. Prelim. Resp. 25–26. Specifically, Patent Owner
`observes that the sentence before Petitioner’s quote from Tanenbaum (Pet.
`43 (quoting Ex. 1006, 522)) that a TCP entity accepts streams and breaks
`them up into pieces sent as separate IP datagrams reads, “[e]ach machine
`supporting TCP has a TCP transport entity, either a user process or part of
`the kernel that manages TCP streams and interfaces to the IP layer.” Prelim.
`Resp. 25 (citing Ex. 1006, 522). According to Patent Owner, relying on its
`declarant, “a [person of ordinary skill in the art] would understand that the
`‘TCP entity’ is software executing on the host, not the network interface
`card.” Id. (citing Ex. 2001 ¶¶ 52–53). As to Petitioner’s quote from
`Tanenbaum that a transport entity can be on the network interface card (Pet.
`43–44 (citing Ex. 1006, 480)), Patent Owner argues this is from a section 40
`pages before the discussion of the TCP entity, which is only ever described
`as being on the host or kernel. Prelim. Resp. 26.
`
`13
`
`
`
`IPR2017-01406
`Patent 7,673,072 B2
`
`As an initial matter, whether or not Tanenbaum discloses the “TCP
`entity” on “the host, and not the network interface card,” as Patent Owner
`contends, is beside the point, because Petitioner is relying on Erickson’s I/O
`device adapter as modified to use the fast path TCP processing disclosed in
`Tanenbaum. See In Keller, 642 F.2d 413, 425–26 (CCPA 1981) (“[O]ne
`cannot show non-obviousness by attacking references individually where, as
`here, the rejections are based on combinations of references.”). As
`discussed above, Petitioner relies on Tanenbaum’s disclosure that
`segmenting (i.e., “dividing . . . into segments”) is performed by the TCP
`entity and on its declarant’s testimony that a person of ordinary skill in the
`art would have understood Tanenbaum to suggest that the entity could have
`been on the network device. See Pet. 43–45. Relying on its declarant,
`Petitioner provides evidence and explanation as to how a person of ordinary
`skill in the art would have modified Erickson’s UDP scripts executing on the
`I/O device adapter into TCP scripts that would perform the claimed dividing.
`Id. Patent Owner does not point out deficiencies in this analysis, which we
`find sufficient for purposes of this Decision.
`Second, Patent Owner contends that, not only does Tanenbaum not
`disclose an interface device being able to divide data into segments, it
`actually teaches away from an interface having such a separate processor.
`Prelim. Resp. 23–24, 26–27. Specifically, Patent Owner relies on the
`following excerpt from Tanenbaum.
`
`A tempting way to go fast is to build fast network interfaces in
`hardware. The difficulty with this strategy is that unless the
`protocol is exceedingly simple, hardware just means a plug-in
`board with a second CPU and its own program. To avoid having
`the network coprocessor be as expensive as the main CPU, it is
`often a slower chip. The consequence of this design is that much
`
`14
`
`
`
`IPR2017-01406
`Patent 7,673,072 B2
`
`of the time the main (fast) CPU is idle waiting for the second
`(slow) CPU to do the critical work. It is a myth to think that the
`main CPU has other work to do while waiting. Furthermore,
`when two general-purpose CPUs communicate, race conditions
`can occur, so elaborate protocols are needed between the two
`processors to synchronize them correctly. Usually, the best
`approach is to make the protocols simple and have the main
`CPU do the work.
`Id. at 24 (quoting Ex. 1006, 588–589).
`A reference can be said to teach away “when a person of ordinary
`skill, upon reading the reference, would be discouraged from following the
`path set out in the reference, or would be led in a direction divergent from
`the path that was taken by the applicant.” Galderma Labs., L.P. v. Tolmar,
`Inc., 737 F.3d 731, 738 (Fed. Cir. 2013). However, “[a] reference that
`‘merely expresses a general preference for an alternative invention but does
`not criticize, discredit, or otherwise discourage investigation into’ the
`claimed invention does not teach away.” Meiresonne v. Google, Inc., 849
`F.3d 1379, 1382 (Fed. Cir. 2017) (quoting Galderma, 737 F.3d at 738).
`Here, for reasons discussed above, we agree with Petitioner that
`Erickson discloses a two-processor solution for performing UDP processing
`on the I/O device adapter and explicitly teaches that TCP scripts could also
`be written to do the same. See Ex. 1005, 5:36–51. Petitioner has provided
`testimony from its declarant, which we credit for purposes of this Decision,
`that a person of ordinary skill in the art would have motivated to implement
`Tanenbaum’s explicit teachings of fast path TCP processing using the two-
`processor solution of Erickson. See Ex. 1003 ¶¶ 137–148. Although
`Tanenbaum suggests that “offloading” using a two-processor solution may
`not be useful and introduces some complexities, Erickson provides
`motivation to move some protocol processing onto the I/O device adapter.
`
`15
`
`
`
`IPR2017-01406
`Patent 7,673,072 B2
`
`See Ex. 1005, 1:62–2:11. Patent Owner cites nothing in Tanenbaum to
`suggest that Erickson’s objectives would be undermined by using the fast
`path TCP processing disclosed in Tanenbaum or render Erickson inoperative
`for its intended purpose. See Meiresonne, 849 F.3d at 1383–84 (finding
`nothing to indicate the modification would detract from the goal of the
`primary reference). Accordingly, at this stage of the proceeding, we
`disagree that Tanenbaum teaches away from the proposed combination of
`Erickson and Tanenbaum.
`Third, Patent Owner contends the goal of Erickson is to reduce
`memory-to-memory copies and calls to the operating system, which
`Erickson accomplishes by mapping I/O device memory directly into the
`virtual address space of the user process. Prelim. Resp. 27–28 (citing Ex.
`1005, 2:63–66, 5:27–31, Fig. 2). Based on this characterization, Patent
`Owner concludes “[t]his suggests that the I/O adapter does not have
`processing power, but only provides working memory for the CPU.” Id. at
`28.
`
`We do not disagree with Patent Owner’s characterization of
`Erickson’s objective. However, it does not follow that the adapter only
`provides working memory and does not have its own processing power with
`which to perform the recited dividing the data into segments. As Petitioner
`points out, Erickson discloses the I/O device adapter executing a protocol
`script (e.g., udpscript). Pet. 33 (citing 7:51). For purposes of this Decision,
`we agree this supports Petitioner’s position that the I/O device adapter is
`capable of supporting a TCP-based script as Petitioner contends. See also
`Ex. 1005, 7:41–44 (“The user process provides the starting address and the
`length . . . and then ‘spanks’ a GO register to trigger the I/O device
`
`16
`
`
`
`IPR2017-01406
`Patent 7,673,072 B2
`
`adapter’s execution of a predetermined script.” (emphasis added)), 8:54–57
`(“The bus controller then transfers the data to the I/O device adapter and
`initiates the registers of the I/O device adapter to execute a predetermined
`script to process the data.”).
`Fourth, and finally, Patent Owner argues that all of the obvious scripts
`proposed by Petitioner require “a new ‘repetitive’ feature absent in the
`disclosure of Erickson itself,” that of repeating transfer of the segmented
`data until all of the data was sent. See Prelim. Resp. 29–30. Patent Owner
`argues that,
`all the scripts disclosed in Erickson are one-time scripts.
`Petitioner’s expert alleges that the script “senduserdatagram”
`disclosed at Erickson 7:23-32 will be “repeatedly spank[ed].”
`Ex. 1003, Appendix A, A-12. This allegation is technically
`wrong. Neither of the two while loops in the script includes
`anything in their braces. Ex. 2001, ¶ 54. The spanking statement
`“vhr_p->GO =1” will run at most once when the script is called.
`Id. Similarly, in the script disclosed at Erickson 7:50-64, there
`is no statement that could result in repeating execution, such as
`while loop, for statement, or if clause. Ex. 2001, ¶ 55.
`
`Petition[er]’s expert fails to provide any facts or analysis
`as to why a new repetitive feature should be added to the script
`or I/O adapter, especially when such feature is inconsistent will
`the mechanisms and embodiments disclosed in Erickson itself.
`Prelim. Resp. 30.
`We disagree with Patent Owner’s argument because it is directed at
`Erickson individually and not the proposed combination. See Keller, 642
`F.2d at 425–26. Moreover, contrary to Patent Owner’s argument,
`Petitioner’s declarant does provide facts and analysis as to why a person of
`ordinary skill in the art would have been motivated to modify Erickson’s
`scripts to add the repetitive feature. For example, Dr. Horst cites
`Tanenbaum’s teaching of breaking TCP data streams into pieces not to
`
`17
`
`
`
`IPR2017-01406
`Patent 7,673,072 B2
`
`exceed 64K (or even 1500 bytes) and sending as separate datagram and
`other evidence of TCP segmentation implemented as repeated invocations of
`a loop. See Ex. 1003, Appendix A, A-12–A-14 n. 9. Although Patent
`Owner’s declarant disputes this analysis, that testimony is based solely on
`Erickson’s disclosure and does not address the script as modified in view of
`Tanenbaum proposed by Petitioner and Dr. Horst. See Ex. 2003 ¶¶ 54–55.
`Accordingly, we credit Dr. Horst’s testimony for purposes of this Decision.
`“creating headers for the segments, by the interface device, from
`a template header containing the protocol header information”
`Petitioner contends Erickson in combination with Tanenbaum
`discloses this limitation. Pet. 47. Specifically, Petitioner relies on
`Erickson’s description of a UDP script running on the I/O device adapter
`“creating UDP/IP/MAC headers for datagrams by filling in protocol
`template header 702 shown in Fig. 7,” and its disclosure of other protocol
`scripts including TCP/IP. Id. (citing Ex. 1005, 5:47–51). Similar to its
`contentions discussed above, Petitioner contends it would have been obvious
`to a person of ordinary skill in the art to create a TCP version of the script
`described in Erickson that exchanges data in the form of segments based on
`Tanenbaum’s TCP prototype header. Id. at 47–48. Figure 6-50 of
`Tanenbaum is reproduced below:
`
`18
`
`
`
`IPR2017-01406
`Patent 7,673,072 B2
`
`
`
`Figure 6-50 of Tanenbaum depicts a TCP and IP header with
`shaded areas indicating no changes during
`one-way data transmission.
`Ex. 1006, 566. Petitioner contends that in the proposed combination, “the
`modified script would fill in the TCP Sequence number, Length and
`Checksum.” Pet. 48; Ex. 1003 ¶ 40, Appendix A, 1.4.
`“and prepending the headers to the segments to form transmit
`packets.”
`Petitioner contends Erickson in combination with Tanenbaum
`discloses this limitation. Pet. 49–50. In particular, Petitioner relies on
`Erickson’s description of UDP datagram template 702 without user data
`residing in the I/O device adapter’s memory. Id. (citing Ex. 1005, 7:39–47).
`Petitioner contends a person of ordinary skill in the art would have
`recognized that one of two obvious ways to concatenate the user data and the
`header (such as the described UDP header or TCP header in Tanenbaum)
`would have been to prepend the header to the segmented user data in the
`system of Erickson as modified by Tanenbaum. Id. at 50; Ex. 1003 ¶¶ 36–
`37, Appendix A, 1.6. For purposes of this Decision, we find that Petitioner’s
`contentions are supported sufficiently.
`For the foregoing reasons, we are persuaded that Petitioner has
`demonstrated a reasonable likelihood of prevailing on its proposed grounds
`
`19
`
`
`
`IPR2017-01406
`Patent 7,673,072 B2
`
`of obviousness for claim 1. At this stage of the proceeding, aside from the
`foregoing arguments, Patent Owner does not dispute Petitioner’s analysis
`with respect to claims 2–21.
`
`III. CONCLUSION
`For the foregoing reasons, we determine that the information
`presented establishes a reasonable likelihood that Petitioner would prevail in
`showing that at least one of claims 1–21 of the ’0
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
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.
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.
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
