Paper 11
`Trials@uspto.gov
`571-272-7822 Entered: November 30, 2017
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`INTEL CORPORATION,
`Petitioner,
`
`v.
`
`ALACRITECH, INC.,
`Patent Owner.
`____________
`
`Case IPR2017-01392
`Patent 7,337,241 B2
`____________
`
`
`
`Before STEPHEN C. SIU, DANIEL N. FISHMAN, and
`WILLIAM M. FINK, Administrative Patent Judges.
`
`FISHMAN, 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
`all claims (1–24) of U.S. Patent No. 7,337,241 B2 (“the ’241 patent,” Ex.
`
`
`Trials@uspto.gov
`571-272-7822 Entered: November 30, 2017
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`INTEL CORPORATION,
`Petitioner,
`
`v.
`
`ALACRITECH, INC.,
`Patent Owner.
`____________
`
`Case IPR2017-01392
`Patent 7,337,241 B2
`____________
`
`
`
`Before STEPHEN C. SIU, DANIEL N. FISHMAN, and
`WILLIAM M. FINK, Administrative Patent Judges.
`
`FISHMAN, 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
`all claims (1–24) of U.S. Patent No. 7,337,241 B2 (“the ’241 patent,” Ex.
`
`
`
`IPR2017-01392
`Patent 7,337,241 B2
`
`1001) pursuant to 35 U.S.C. §§ 311 et seq. Paper 4 (Corrected Petition
`“Pet.”). Alacritech, Inc. (“Patent Owner”) filed a preliminary response.
`Paper 10 (“Prelim. Resp.”). Institution 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 all claims 1–24 of the
`’241 patent.
`
`A. Related Matters
`We are informed that the ’241 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; Paper 6, 1.
`
`B. The ’241 Patent
`The ’241 patent describes a system and method for accelerating data
`transfer between a network and storage unit. Ex. 1001, Abstract. In
`particular, the claimed invention of the ’241 patent relates to a fast-path
`processing in which processing for headers of a layered network protocol
`(e.g., TCP/IP or UDP/IP) is offloaded from the host computer to an
`intelligent network interface. See id. at 5:18–38, Fig. 24. Specifically, the
`intelligent network interface includes accelerated processing features, “[t]he
`accelerated processing includes employing representative control
`
`2
`
`
`
`IPR2017-01392
`Patent 7,337,241 B2
`
`instructions for a given message that allow data from the message to be
`processed via a fast-path which accesses message data directly at its source
`[in the host computer] or delivers it directly to its intended destination [in the
`host computer].” Id. at 5:18–22.
`
`C. Illustrative Claim
`Claims 1, 9, and 17 are the independent claims of the ’241 patent.
`Claims 1 and 9, reproduced below, are illustrative of the claimed subject
`matter:
`
`1. A method for network communication, the method
`comprising:
`receiving a plurality of packets from the network, each of
`the packets including a media access control layer header, a
`network layer header and a transport layer header;
`processing the packets by a first mechanism, so that for
`each packet the network layer header and the transport layer
`header are validated without an interrupt dividing the processing
`of the network layer header and the transport layer header;
`sorting the packets, dependent upon the processing, into
`first and second types of packets, so that the packets of the first
`type each contain data;
`sending, by the first mechanism, the data from each packet
`of the first type to a destination in memory allocated to an
`application without sending any of the media access control layer
`headers, network layer headers or transport layer headers to the
`destination.
`Id. at 98:32–49.
`
`9. A method for communicating information over a
`network, the method comprising:
`obtaining data from a source in memory allocated by a first
`processor;
`dividing the data into multiple segments;
`
`3
`
`
`
`IPR2017-01392
`Patent 7,337,241 B2
`
`prepending a packet header to each of the segments by a
`second processor, thereby forming a packet corresponding to
`each segment, each packet header containing a media access
`control layer header, a network layer header and a transport layer
`header, wherein the network layer header is Internet Protocol
`(IP), the transport layer header is Transmission Control Protocol
`(TCP) and the media access control layer header, the network
`layer header and the transport layer header are prepended at one
`time as a sequence of bits during the prepending of each packet
`header; and
`transmitting the packets to the network.
`Id. at 99:19–35.
`
`D. Asserted Grounds of Unpatentability
`Petitioner asserts that claims 1–24 are unpatentable based on the
`following grounds (Pet. 14–15):
`
`Reference(s)
`Erickson,1 Tanenbaum,2
`and Alteon3
`Erickson and Tanenbaum
`Erickson, Tanenbaum, and
`Alteon
`
`
`
`
`Basis
`§ 103
`
`§ 103
`§ 103
`
`§ 112, 2nd
`paragraph4
`
`Claims challenged
`1–8
`
`9–17, 19–21, and 24
`18, 22, and 23
`
`1–5, 7, 8, 17, 20, and 23
`
`
`1 U.S. Patent No. 5,768,618. (“Erickson,” Ex. 1005).
`2 Andrew S. Tanenbaum, Computer Networks, Third Edition, 1996
`(“Tanenbaum96,” Ex. 1006).
`3 Alteon Networks Inc., Gigabit Ethernet Technical Brief: Achieving End-to-
`End Performance, 1996. (“Alteon,” Ex. 1033).
`4 Under 37 C.F.R. § 42.104(b)(2), we are not authorized to address
`patentability issues under 35 U.S.C. § 112, second paragraph.
`4
`
`
`
`IPR2017-01392
`Patent 7,337,241 B2
`
`Petitioner relies on the testimony of Dr. Robert Horst (Ex. 1003) in
`support of its assertions. Patent Owner relies on the testimony of Dr. Paul
`Prucnal (Ex. 2001) in support of its assertions.
`
`II. DISCUSSION
`
`A. 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).
`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). Only terms that are in controversy need to be construed and only to
`the extent necessary to resolve the controversy. See Wellman, Inc. v.
`Eastman Chem. Co., 642 F.3d 1355, 1361 (Fed. Cir. 2011); Vivid Techs.,
`Inc. v. Am. Sci. & Eng’g, Inc., 200 F.3d 795, 803 (Fed. Cir. 1999).
`At this stage of the proceeding, we determine that it is not necessary
`to provide an express interpretation of any claim terms.
`
`B. Cited Prior Art References
`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:
`
`5
`
`
`
`IPR2017-01392
`Patent 7,337,241 B2
`
`
`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.
`In particular, Erickson discloses that I/O device adapter 314 and a user
`process on a host computer share access to a portion of the user’s virtual
`memory space on the host computer. Id. at 1:67–2:7. When applied in the
`context of network communications, I/O adapter 314 (i.e., a “network
`interface device”) and the user process pre-negotiate certain fields that will
`be common to all data transfers to be made—i.e., fields in the various
`headers used in layered network protocols such as TCP/IP or UDP/IP over
`an Ethernet medium. Id. at 6:42–7:4. To transmit a datagram, the user
`process programs registers of the I/O adapter to identify the data to be
`
`6
`
`
`
`IPR2017-01392
`Patent 7,337,241 B2
`
`transmitted, the registers and the identified data accessible through the
`shared virtual memory. Id. at 7:5–32. The I/O adapter then combines the
`identified data with the pre-negotiated fields of the various headers needed
`for network transmission, adjusts fields in the pre-negotiated header that
`vary for each datagram, and transmits the completed packet including the
`completed headers and the user-supplied data. Id. at 7:38–8:26.
`
`2. Overview of Tanenbaum
`Tanenbaum describes general principles of data transmission in
`computer networks including TCP/IP and UDP/IP protocols. See generally
`Ex. 1006.
`
`3. Alteon Reference (Ex. 1033)
`a. Printed Publication
`An inter partes review may only request review under 35 U.S.C.
`§§ 102 and 103 and only based on “prior art consisting of patents or printed
`publications.” 35 U.S.C. § 311(b); 37 C.F.R. § 42.104(b)(2). Before
`reaching the merits of Petitioner’s obviousness contentions regarding
`unpatentability, some of which are based, in part, on Alteon, we must
`determine as a threshold issue whether Alteon is a prior art printed
`publication under 35 U.S.C. § 311(b). It is Petitioner’s burden to prove that
`it is, as Petitioner bears the burden of proving unpatentability by a
`preponderance of the evidence. See 35 U.S.C. § 316(e).
`
`7
`
`
`
`IPR2017-01392
`Patent 7,337,241 B2
`
`Petitioner argues “Alteon was published on or before January 26,
`1997 and is therefore at least § 102(a) prior art.” Pet. 40 (citing Ex. 1087
`(the “Butler Declaration”).5
`Patent Owner argues Petitioner has failed to meet its burden to show
`Alteon is available as a prior art printed publication in this preliminary
`proceeding. Prelim. Resp. 40–43. Specifically, Patent Owner argues the
`Petition fails to explain how a “crawler,” referenced in Mr. Butler’s
`Declaration, automatically stored a copy of the Alteon technical brief
`document. Id. at 41. Patent Owner further argues the Petition fails to
`explain how an interested person of ordinary skill would have located the
`Alteon document. Id. Patent Owner contends,
`Without a link from the main Alteon webpage, “it is unclear how
`a person of ordinary skill in the art would be able to access the
`URL from which the technical brief was allegedly accessed by
`the crawler without knowledge of the full URL path (which
`appears to be http://www.alteon.com/techbrief.ps).”
`Id. at 42.
`At this preliminary stage of the proceeding, Petitioner has shown
`sufficiently that Alteon qualifies as a prior art printed publication. However,
`we note Petitioner does not assert that Exhibit 1033 (the Alteon reference
`relied upon by Petitioner) is identical to “Exhibit A” of the Butler
`Declaration (a version of the Alteon reference authenticated by Mr. Butler.
`For purposes of this Decision, we presume Exhibit 1033 is identical to the
`
`
`5 Patent Owner correctly observes that Petitioner erroneously states Alteon
`was published “on or before January 26, 1997.” Prelim. Resp. 40 n.12
`(citing Pet. 40). This is in error because Mr. Butler’s Declaration identifies
`the archival date in www.archive.org as January 13, 1997. See Ex. 1087
`.001 (¶ 5), .004.
`
`8
`
`
`
`IPR2017-01392
`Patent 7,337,241 B2
`
`document Mr. Butler attests to as “Exhibit A” in his Declaration.
`Furthermore, Patent Owner correctly observes that Petitioner does not
`explain how an ordinarily skilled artisan would locate the URL
`(www.alteon.com/techbrief.ps) without locating the underlying home page
`(www.alteon.com). Prelim. Resp. 42. However, Patent Owner provides, in
`Exhibit 2006, a copy of an archived web page corresponding to the URL
`www.alteon.com. Although Mr. Butler’s Declaration does not address
`Patent Owner’s Exhibit 2006, it appears that both Exhibit 2006 (an archive
`printout of the www.alteon.com home page) and “Exhibit A” of the Butler
`Declaration (an archive printout of www.alteon.com/techbrief.ps) were
`archived on the same day (January 13, 1997). Although Petitioner does not
`identify a link from the archived home page to the techbrief.ps web page, on
`the record before us we find it is sufficiently shown for purposes of this
`Decision that the two pages, archived on the same date, are linked in such a
`manner that the interested ordinarily skilled artisan would have been able to
`locate and access the techbrief.ps document.
`For the reasons above, on the record before us and for purposes of this
`Preliminary Decision, we determine Alteon (Exhibit 1033) qualifies as a
`prior art printed publication in this proceeding. We note this panel has not
`yet made a final determination as to the printed publication status of Alteon
`based on the preponderance of the evidence standard required for a final
`written decision.
`
`b. Overview of Alteon
`Alteon describes general principles of operation of a high-speed
`Ethernet I/O adapter. See Ex. 1033, .005–.007. In particular, Alteon
`discloses a problem of prior Ethernet I/O adapters that required multiple
`
`9
`
`
`
`IPR2017-01392
`Patent 7,337,241 B2
`
`interrupts in the processing for each packet, thus, consuming resources of the
`host computer. See id. at .020. Alteon purports to address this problem
`using an intelligent network I/O adapter that “allows a single interrupt to be
`issued for multiple data packets.” Id. at .022.
`
`C. Alleged Indefiniteness
`Claims 1–8 and 17–24 recite a “first mechanism” and/or a “second
`mechanism.” Petitioner argues “mechanism” is a nonce word that fails to
`convey sufficient structure and, thus, these terms should be construed under
`35 U.S.C. § 112(6) as means plus function elements. Pet. 26. Petitioner
`further argues the ’241 patent Specification fails to disclose any
`corresponding structure for the functions of these elements and, thus, these
`claims are invalid as indefinite under 35 U.S.C. § 112(2).6 Id. at 26–33.
`Indefiniteness, however, is not an issue for an IPR.
`Patent Owner argues all the claims of the ’241 patent are method
`claims such that the recited mechanisms are merely the locations at which
`the recited steps are performed and, therefore, the claims do not use the term
`“mechanism” as a nonce word that would be construed under 35 U.S.C.
`§ 112(6). Prelim. Resp. 25–26. In other words, the novelty of the claimed
`invention lies in the performance of the steps to exchange information
`
`
`6 Petitioner specifically identifies only claims 1–5, 7, 8, 17, 20, and 23 as
`indefinite under this reasoning. Pet. 26. However, claims 1 and 17 are
`independent claims from which all of claims 2–8 and 18–24 depend (directly
`or indirectly). The dependent claims incorporate all limitations of the claims
`from which they depend. Because Petitioner has not presented argument or
`evidence that claims 6, 18, 19, 21, 22, and 24 recite any additional structure
`to exclude them from its argument of indefiniteness, Petitioner’s argument
`regarding indefiniteness applies to all of claims 1–8 and 17–24.
`10
`
`
`
`IPR2017-01392
`Patent 7,337,241 B2
`
`between two structures—i.e., between any two “mechanisms” capable of
`performing the recited steps.
`We agree with Patent Owner. All claims of the ’241 patent are
`method claims and the method steps are agnostic regarding the particular
`type of mechanism involved in each step. Instead, the term “mechanism”
`bears weight in the claim only to the extent that certain recited processing of
`the method steps involve one or the other recited mechanism or involve both
`mechanisms. Therefore, particular structural features/limitations of each
`mechanism are not relevant to the scope of the claims. On this record and
`for purposes of this preliminary Decision, we are not persuaded claims 1–8
`and 17–24 should be interpreted in accordance with 35 U.S.C. § 112(6).
`
`D. Obviousness over Erickson and Tanenbaum (and Alteon)
`1. Petitioner’s Position
`Petitioner contends claims 1–8, 18, 22, and 23 are unpatentable under
`35 U.S.C. § 103(a) as obvious over the combination of Erickson,
`Tanenbaum, and Alteon and that claims 9–17, 19–21, and 24 are
`unpatentable under 35 U.S.C. § 103(a) as obvious over the combination of
`Erickson and Tanenbaum. See Pet. 49–92.
`At this preliminary stage of the proceeding and on the record before
`us, Petitioner has accounted sufficiently for the limitations of at least one of
`the claims challenged in the Petition. For example, regarding claim 1,
`Petitioner argues Erickson discloses the step of “receiving a plurality of
`packets . . .” as receiving Ethernet packets having a physical (“MAC”) layer
`header, a network (“IP”) layer header, and a transport (“UDP” or “TCP”)
`layer header. Pet. 50–51 (citing Ex. 1005, Fig. 6, 6:48–56; Ex. 1003
`Appendix A-2). Petitioner notes that, although Erickson’s Figure 6 is
`
`11
`
`
`
`IPR2017-01392
`Patent 7,337,241 B2
`
`specific to the UDP transport protocol, Erickson expressly discloses its
`invention is equally applicable to other protocols including the TCP
`transport protocol. Id. at 52 (Ex. 1005, 5:47–51).
`Petitioner argues the step of “processing the packets . . . [so] the
`network layer header and transport layer header are validated without an
`interrupt dividing the processing of [the headers]” is disclosed by Erickson’s
`I/O adapter executing scripts that validate the network and transport layer
`headers by computing checksums for each such header. Id. at 53–54 (citing
`Ex. 1005, 4:18–23, 7:50–64, 8:10–25; Ex. 1003 Appendix A-5). Petitioner
`acknowledges Erickson does not disclose the “without an interrupt”
`limitation of claim 1 but asserts Alteon in the proposed combination
`discloses this limitation by teaching a single interrupt of a host system is
`generated by an intelligent network interface for the processing of multiple
`packets. Id. at 54–55 (citing Ex. 1033, .015, .022, .023).
`Petitioner argues Erickson and Alteon are both concerned with
`reducing intervention processing by a host computer for each I/O operation
`and, therefore, contends the ordinarily skilled artisan would have been
`motivated to combine Alteon with Erickson because Alteon’s “single
`interrupt processing reduces the need for the host computer to insert itself
`into the process. “ Id. at 48.
`The Petition next argues Erickson in combination with Tanenbaum96
`discloses the step of “sorting the packets . . . into first and second types of
`packets, so that the packets of the first type each contain data.” Id. at 55–56
`(citing Ex. 1006, .584–.585). Specifically, the Petition asserts Tanenbaum96
`discloses checking if packets meet certain criteria for fast-path processing
`and, thus, sorts packets according to claim 1. Id.
`
`12
`
`
`
`IPR2017-01392
`Patent 7,337,241 B2
`
`Petitioner argues Erickson incorporates an earlier version of
`Tanenbaum and, thus, provides express motivation to combine Erickson
`with the teachings of Tanenbaum. Id. at 44 (citing Ex. 1005, 4:34–43).
`Petitioner then argues the ordinarily skilled artisan would have been
`motivated to seek out the then current version of Tanenbaum (e.g.,
`Tanenbaum96) at the time of the ’241 patent priority. Id. Petitioner
`contends Tanenbaum96 and Erickson both relate to fast-path processing of
`packets and, although Erickson discloses its applicability to the TCP
`(transport) protocol (Ex. 1005, 5:47–51), Tanenbaum96 expressly discloses
`fast-path processing for TCP protocol. Id. at 45–47.
`Petitioner contends the proposed combination also discloses the step
`of “sending . . . the data from each packet of the first type to a destination
`memory . . . without sending any of the . . . headers to the destination.” Id.
`at 56–58. Specifically, Petitioner argues Erickson discloses sending data to
`an application by writing the data directly to a memory space of the
`application. Id. at 56–57 (citing Ex. 1005, Figs. 3 and 4, 4:53–5:14, 6:1–41,
`8:17–37; Ex. 1003 § V.H.1). Petitioner further argues Alteon’s step 2 of
`table 4 expressly discloses that the packet is moved to the application
`memory without the headers. Id. at 57–58 (citing Ex. 1033, .021; Ex. 1003
`Appendix A13–A14).
`
`2. Patent Owner’s Preliminary Response
`Patent Owner argues the references, alone or in the proposed
`combination, fail to teach or suggest that the network and transport layer
`headers are validated “without an interrupt dividing the processing” of the
`two headers as required by claim 1. Prelim. Resp. 43–45. Specifically,
`regarding Alteon’s interrupt timer that the Petition relies on for this feature,
`
`13
`
`
`
`IPR2017-01392
`Patent 7,337,241 B2
`
`Patent Owner argues Alteon’s interrupt timer simply refers to copying data
`from multiple packets to the application memory space but “does not
`implicate validating the network layer header or a [sic] validating a transport
`layer header because these headers would be validated after each packet is
`copied into the operating system buffer space and the TCP stack processed
`the packets.” Id. at 44 (citing Ex. 2001 ¶ 101).
`
`3. Analysis Regarding Alleged Obviousness of Claims 1–8
`We are persuaded by Petitioner’s arguments. Patent Owner’s
`argument regarding claim 1 is not persuasive because it is not responsive to
`the Petitioner’s assertions and, instead, attacks the references individually.
`See, e.g., In re Keller, 642 F.2d 413 (CCPA 1981); In re Merck, 800 F.2d
`1091 (Fed. Cir. 1986). The Petition relies on Erickson, not Alteon, in the
`proposed combination for teaching processing (validating) of headers by an
`intelligent network interface rather than by the host computer. Pet. 53–54
`(“The script validates the network and transport layer headers by performing
`checksum on each header.”) (citing Ex. 1005, 8:10–25). Petitioner asserts
`that Erickson discloses validating the headers but does not specifically
`disclose that such validation on the intelligent network interface is without
`interruption. Id. Therefore, Petitioner relies on Alteon, in combination with
`Erickson, for disclosing the absence of interrupts (of the host system) when
`receiving packets from the network because “[i]f there was an interrupt after
`validation of every network layer header, it would not be possible to have
`only one interrupt for multiple data packets.” Id. at 54 (citing Ex. 1003
`Appendix A-5). Thus, Erickson is relied on for disclosing the processing
`(validation) of received packet headers and Alteon is relied on in the
`
`14
`
`
`
`IPR2017-01392
`Patent 7,337,241 B2
`
`proposed combination for its teaching of reducing the number of interrupts
`of the host system for the processing of packets.
`On this record and for purposes of this Decision, we are persuaded the
`combination of Erickson, Tanenbaum96, and Alteon disclose or suggest the
`step of “processing the packets . . . [so] the network layer header and
`transport layer header are validated without an interrupt dividing the
`processing of [the headers].”
`Patent Owner’s Preliminary Response does not raise other issues
`regarding Petitioner’s arguments for unpatentability of claim 1 or any of
`claims 2–8 dependent from claim 1. See Prelim. Resp. 39–45.
`For the above reasons, on the record before us and for purposes of this
`preliminary Decision, we are persuaded there is a reasonable likelihood that
`Petitioner would prevail in showing claims 1–8 are unpatentable over the
`combined teachings of Erickson, Tanenbaum96, and Alteon.
`
`4. Asserted Obviousness of Claims 9–17, 19–21, and 24
`Petitioner asserts claims 9–17, 19–21, and 24 are unpatentable over
`the combination of Erickson and Tanenbaum96. Petitioner identifies the
`features of each of these claims in the combined teachings of Erickson and
`Tanenbaum96. Pet. 71–88.
`
`a. Claims 9–16
`Claim 1, discussed supra, recites, in essence, steps for processing
`packets received from a network and processed (validating headers) in a first
`mechanism before sending the data of the packets to a second mechanism—
`i.e., receiving and processing packets from the network. By contrast, claim
`9 recites method steps for transmitting packets to a network. In general,
`claim 9 recites obtaining data from a first mechanism (a first processor),
`
`15
`
`
`
`IPR2017-01392
`Patent 7,337,241 B2
`
`dividing the data into multiple segments, and prepending headers to each
`segment to form a packet to be transmitted to the network. In pertinent part,
`independent claim 9 recites prepending network (IP) and transport (TCP)
`packet headers to each segment such that the headers are “prepended at one
`time as a sequence of bits during the prepending of each packet header.”
`Regarding this portion of claim 9, Petitioner refers to its argument for
`a similar limitation in claim 7. Id. at 74. The related recitation in claim 7
`(which depends from claim 1) recites that the headers “are prepended at one
`time as a packet header,” i.e., no limitation that the headers are prepended
`“as a sequence of bits.” In the argument regarding this similar recitation of
`claim 7, Petitioner asserts Erickson discloses: a header template is stored in
`the network interface device’s memory, the header template includes both a
`network (IP) header and a transport (UDP) header; the data to be transmitted
`to the network is first transferred to the network interface device’s memory;
`the header template is used to create a header that corresponds to the data to
`be sent; and the packet datagram (header combined with data) is then
`transmitted to the network. Pet. 67–68. Petitioner further argues there are
`two well-known, obvious ways the header and data can be combined—i.e.,
`either the completed header is prepended to the data to be sent or the data to
`be sent is appended to the completed header. Petitioner then contends it
`would have been obvious to the ordinarily skilled artisan to select one of
`these two options—namely prepend the completed header to the data to be
`transmitted. Id. at 69 (citing Ex. 1005, 7:38–47, 8:2–9; Ex. 1003 Appendix
`A-28, § V.B.8).
`Patent Owner asserts Petitioner’s application of the arguments for
`claim 7 to the similar recitation of claim 9 is deficient because “Erickson
`
`16
`
`
`
`IPR2017-01392
`Patent 7,337,241 B2
`
`appears to ‘build the network layer and transport layer in a traditional serial
`fashion,’ rather than ‘at one time’ as required by claim 9.” Prelim. Resp. 47
`(citing Ex. 2001 ¶¶ 104–108).
`We are persuaded by Petitioner’s arguments and we find Patent
`Owner’s argument unpersuasive. Although Erickson may compute the
`various checksum and length fields of the generated header in some fashion
`as Patent Owner suggests, claim 9 does not limit the manner in which the
`headers are built but, instead, requires only that the headers be prepended at
`one time. In general, the header and data portions of a packet are both stored
`in the memory of Erickson’s network interface device and then transmitted
`to the network. More specifically, Erickson builds the updated header from
`a template in the memory of its network interface device and stores the
`corresponding data portion in the same memory. Ex. 1005, 7:38–47.
`Erickson discloses the host system programs the address and length of the
`user data to be sent and then “spanks” a GO register to cause the network
`interface to execute a script using the programmed parameters identifying
`the user data. Id. The exemplary script in Erickson for sending a UDP
`packet computes appropriate checksum values and fills in a template header
`with the computed checksums and the relevant lengths to generate a
`completed header based on the corresponding data. Id. at 7:65–8:27. The
`completed header and the corresponding user data, previously stored in the
`memory of the network interface, are then transmitted as a completed
`packet. Id. at 7:46–47; see also id. at 6:48–56. We agree with Petitioner
`that the header and data to be transmitted, both stored in the memory of the
`network interface device, would be combined in one of two obvious
`manners—either the header is prepended to the data or the data is appended
`
`17
`
`
`
`IPR2017-01392
`Patent 7,337,241 B2
`
`to the header. Given the small number of known solutions to combining the
`header and data, it would have been obvious to try prepending the header to
`the data to transmit the packet. KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398,
`421 (2007) (noting that if there are a finite number of identified, predictable
`solutions to solve a problem, a person of ordinary skill in the art has good
`reason to pursue the known options within his or her technical grasp). Thus,
`Erickson would have, at least, suggested to the ordinarily skilled artisan that
`the header for a packet is built in the memory of the network interface
`device and the completed header (with properly adjusted checksum and
`length fields) is prepended “at one time” to the user data previously stored in
`the network interface memory prior to the completed packet being
`transmitted.
`Patent Owner’s Preliminary Response does not raise other issues
`regarding Petitioner’s arguments for unpatentability of claim 9 or any of
`claims 10–16 dependent from claim 9. See Prelim. Resp. 45–49.
`For the above reasons, on the record before us and for purposes of this
`preliminary Decision, we are persuaded there is a reasonable likelihood that
`Petitioner would prevail in showing claims 9–16 are unpatentable over the
`combined teachings of Erickson and Tanenbaum96.
`
`b. Claims 17, 19–21, and 24
`Independent claim 17, similar to claim 9, is directed to the
`transmission of user data to the network and adds a limitation that the
`prepending of various layered headers to a packet occurs without
`interruption. Petitioner identifies the features of claims 17, 19–21, and 24 in
`the combined disclosures of Erickson and Tanenbaum. Pet. 84–88.
`Regarding claim 17’s recitation of prepending headers without an interrupt,
`
`18
`
`
`
`IPR2017-01392
`Patent 7,337,241 B2
`
`Petitioner refers to the same arguments as for claims 7 and 9 as discussed
`supra and contends, “[a]ccordingly, the headers are appended without an
`interrupt dividing the prepending of the headers.” Id. at 87.
`Patent Owner argues the Petition fails to show that Erickson prepends
`all the layers of headers “at one time” as claimed and, even if they are
`prepended “at one time” in Erickson, the petition fails to show that it is
`“without interrupt” as claimed. Prelim. Resp. 48–49.
`We are persuaded by Petitioner’s arguments and we find Patent
`Owner’s argument unpersuasive. As discussed supra, Erickson would have,
`at least, suggested to the ordinarily skilled artisan that the header for a
`packet is built in the memory of the network interface device and the
`completed header (with properly adjusted checksum and length fields) is
`prepended “at one time” to the user data previously stored in the network
`interface memory prior to the completed packet being transmitted.
`Regarding the “without interrupt” requirement of claim 17, all
`processing to generate headers for packets to be sent from the network
`interface device of Erickson is performed by the processing capability of
`Erickson’s network interface device with no reason to interrupt the
`processing of the host computer requesting the transmission.
`Patent Owner’s Preliminary Response does not raise other issues
`regarding Petitioner’s arguments for unpatentability of claim 17 or any of
`claims 19–21 and 24 dependent from claim 17. See Prelim. Resp. 45–49.
`For the above reasons, on the record before us and for purposes of this
`preliminary Decision, we are persuaded there is a reasonable likelihood that
`Petitioner would prevail in showing claims 17, 19–21, and 24 are
`unpatentable over the combined teachings of Erickson and Tanenbaum96.
`
`19
`
`
`
`IPR2017-01392
`Patent 7,337,241 B2
`
`5. Asserted Obviousness of Claims 18, 22, and 23
`Claims 18, 22, and 23 depend from claim 17 adding further
`limitations similar to those of claim 1 relating to reception of packets from
`the network rather than transmission of packets to the network as recited in
`their base claim 17. Petitioner asserts
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
