Paper No. 9
`Trials@uspto.gov
`Entered: April 3, 2017
`571-272-7822
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`EXABLAZE PTY. LTD.,
`Petitioner,
`
`v.
`
`SOLARFLARE COMMUNICATIONS, INC.,
`Patent Owner.
`____________
`
`Case IPR2016-01832
`Patent 8,645,558 B2
`____________
`
`
`
`Before SALLY C. MEDLEY, DAVID C. MCKONE, and
`CHRISTA P. ZADO, Administrative Patent Judges.
`
`MEDLEY, Administrative Patent Judge.
`
`
`
`DECISION
`Denying Institution of Inter Partes Review
`37 C.F.R. § 42.108
`
`
`
`

`

`IPR2016-01832
`Patent 8,645,558 B2
`
`
`I. INTRODUCTION
`Exablaze Pty. Ltd. (“Petitioner”) filed a Petition for inter partes
`review of claims 1–12 of U.S. Patent No. 8,645,558 B2 (Ex. 1002, “the ’558
`patent”). Paper 1 (“Pet.”). Solarflare Communications, Inc. (“Patent
`Owner”) filed a Preliminary Response. Paper 8 (“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 does not show there is a
`reasonable likelihood that Petitioner would prevail in establishing the
`unpatentability of claims 1–12 of the ’558 patent.
`
`A. Related Matters
`The parties indicate that the ’558 patent has been asserted in
`Solarflare Communications v. Exablaze Pty. Ltd., Case No. 16-cv-01891
`(D. N.J.). Pet. 1; Paper 3, 1.
`
`B. The ’558 Patent
`The challenged claims of the ʼ558 patent relate to processing network
`traffic in a data processing system. Ex. 1002, 42:51–52. Figure 21 of the
`’558 patent is reproduced below.
`
`2
`
`
`
`

`

`IPR2016-01832
`Patent 8,645,558 B2
`
`
`Figure 21 depicts a data processing system
`
`
`
`Figure 21 shows a data processing system 1 for sending and receiving
`
`data over network 2. Id. at 42:53–54. The data processing system includes
`base processing section 3, and network interface device 4, also referred to as
`network interface card, or NIC. Id. at 42:54–56, 43:13–14. Network
`interface device 4 comprises processor 10 and memory 11 arranged for
`processing network traffic being transmitted or received over network 2.
`Id. at 43:3–5. Base processing section 3 comprises a central processing unit
`(CPU) 5, working memory 6, and non-volatile program store 7. Id. at
`42:57–59. Base processing section 3 supports operating system 8, one or
`more application programs 9, and library 14, which implements an
`application programming interface (API). Id. at 42:64–66, 44:36–37, 45:7.
`Library 14 provides a set of functions such as transmitting and receiving
`
`3
`
`

`

`IPR2016-01832
`Patent 8,645,558 B2
`
`data that can be called by the applications. Id. at 45:7–10. The library is not
`part of the operating system but rather runs at user level, i.e., it has user-
`level privileges allocated to it by the operating system. Id. at 45:10–12. In
`operation, protocol processing (typically TCP/IP and UDP/IP) of raw
`received data and of traffic data that is transmitted is performed in response
`to requests from applications rather than in response to receipt of data. Id. at
`46:50–54.
`
`C. Illustrative Claim
`Petitioner challenges claims 1–12 of the ’558 patent. Claim 1, the
`sole independent claim, reproduced below, is illustrative of the claimed
`subject matter:
`1. A data processing system for receiving data from a
`network, and processing that data in accordance with a network
`protocol to extract traffic data therefrom, the data processing
`system having:
`a memory;
`a network interface for receiving the data from the network
`and storing the data in the memory;
`an operating system for supporting one or more
`applications;
`an application supported by the operating system; and
`a protocol processing entity providing an application
`programming interface (API) configured to process the received
`data in accordance with a network protocol to extract traffic data
`therefore, the protocol processing entity being arranged to
`perform protocol processing of the received data in the memory
`in response to signaling from a thread of the application to
`request whether data is available for one or more endpoints of
`the data processing system.
`
`Id. at 65:15–33.
`
`4
`
`

`

`IPR2016-01832
`Patent 8,645,558 B2
`
`
`D. Asserted Grounds of Unpatentability
`Petitioner asserts that claims 1–12 are unpatentable based on the
`following grounds (Pet. 3):
`Reference(s)
`Mansley1
`Mansley and Riddoch2
`Mansley
`
`Challenged Claim(s)
`1–5, 7, and 10–12
`6
`8 and 9
`
`Basis
`§ 102(b)
`§ 103(a)
`§ 103(a)
`
`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. See 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. See In re Translogic Tech., Inc., 504 F.3d 1249, 1257 (Fed. Cir.
`2007). Although Petitioner provides a construction for the claim 1 “in
`response to signaling from a thread of the application” phrase, and Patent
`Owner weighs in on that construction, we determine that no claim term
`requires interpretation.
`
`
`1 Kieran Mansley, Engineering a User-Level TCP for the CLAN Network,
`PROCEEDINGS OF THE ACM SIGCOMM 2003 WORKSHOPS (Sept. 9, 2003)
`(Ex. 1003) (“Mansley”).
`2 David Riddoch, Distributed Computing with the CLAN Network, 27TH
`ANNUAL IEEE CONFERENCE ON LOCAL COMPUTER NETWORKS (Nov. 6–8,
`2002) (Ex. 1005) (“Riddoch”).
`
`5
`
`

`

`IPR2016-01832
`Patent 8,645,558 B2
`
`
`B. Anticipation and Obviousness of Claims over Mansley
`Petitioner contends that claims 1–5, 7, and 10–12 are anticipated by
`Mansley. Pet. 14–35. Petitioner further contends that claim 6, which
`depends from claim 1, is rendered obvious in view of Mansley and Riddoch.
`Id. at 36–41. Lastly, Petitioner contends that claims 8 and 9 are rendered
`obvious in view of Mansley. Id. at 41–44. In support of its showing,
`Petitioner relies upon a Declaration of Kevin Jeffay, Ph.D., who has been
`retained as an expert witness by Petitioner for the instant proceeding.
`Ex. 1001.
`In its Preliminary Response, Patent Owner argues that Petitioner fails
`to show that Mansley describes certain claim 1 limitations. Prelim. Resp.
`26–41. In particular, Patent Owner asserts that the following limitation is
`missing from Mansley: “a protocol processing entity providing an
`application programming interface (API) configured to process the received
`data in accordance with a network protocol to extract traffic data.” As
`explained below, we find this issue to be dispositive and agree with Patent
`Owner that Petitioner has failed to show sufficiently that Mansley describes
`the above limitation.
`
`Mansley
`Mansley, titled “Engineering a User-Level TCP for the CLAN
`Network,” describes user-level networking. Ex. 1003, 8. The CLAN
`(collapsed LAN) is a high performance user-level network targeted at the
`server room. User-level networking enables an application to communicate
`directly with the NIC, bypassing the operating system for the majority of
`operations. Id. The NIC is able to deliver received data directly into the
`
`6
`
`

`

`IPR2016-01832
`Patent 8,645,558 B2
`
`application’s buffers. Id. Mansley is “focused on TCP/IP in a server cluster
`network and bridging this to the Internet.” Id.
`Mansley describes a flow controlled messaging abstraction (a
`Distributed Message Queue (DMQ)), which conceptually is illustrated in
`Figure 1 of Mansley, reproduced below.
`
`
`
`Figure 1 of Mansley illustrates a flow controlled messaging
`abstraction (a Distributed Message Queue (DMQ)).
`
`A DMQ is similar to a circular message queue with two pointers, one
`to indicate current read position (read_i), the other to indicate current write
`position (write_i). Id. at 9. Sender and receiver keep in the shared address
`space a “lazy” copy of the pointer they are not responsible for. Id. The
`buffer physically resides in the memory of the receiver and the sender has a
`mapping of it in its own address space. Id. In this manner, the CLAN
`network is send-directed, “i.e. it is the sender that determines the final
`location (in the receiver’s memory) of the data, not the receiver. This makes
`the receiver’s role in the demultiplex simpler.” Id. at 11.
`
`7
`
`

`

`IPR2016-01832
`Patent 8,645,558 B2
`
`
`Figure 3, reproduced below, shows a CLAN network interface acting
`as a hub. Id. at 10.
`
`
`Figure 3 depicts data flow from the network interface through the
`TCP/IP stack to a thread of the application.
`In Figure 3, “[t]he TCP/IP stack, instead of being the means by which
`the application accesses the network (via the sockets API) is now a tool for
`the network interface to use, and the application accesses the CLAN network
`code directly (but still via the sockets API).” Id. The network interface
`code is a hub for all communication with the application. Id. at 11. “As a
`result the code must now provide a much richer interface and make this
`accessible to both the application (through sockets) and the protocol stack.”
`Id.
`
`Mansley describes that protocol processing is done “lazily (i.e. when
`the application asks for it).” Id. at 11. In implementation, Mansley
`describes that the model used to transport IP over CLAN is built around a
`structure similar to the DMQ, where a circular queue is shared across the
`network with the remote host writing data, and the local host reading data.
`Id. at 11. Mansley describes that for TCP/IP there are two operations that
`need to be performed on each packet: (1) it must be processed by the
`
`8
`
`

`

`IPR2016-01832
`Patent 8,645,558 B2
`
`relevant protocol stacks, and (2) if it contains valid data, it must be passed to
`the application. Id. As a result, the queue requires three pointers, rather
`than the normal two. The write pointer is the same, but “we now subdivide
`‘read’ into a protocol pointer and a delivery pointer.” Id. “We also separate
`the headers from the payloads and transfer them into two separate queues.
`In this way we prevent the payload queue becoming fragmented as headers
`are processed and discarded in advance of the application reading the
`payloads.” Id. at 12.
`Mansley further describes using a bridge (gateway) to connect the
`CLAN network to the Internet that can be used as a protocol processing
`gateway to help with TCP processing. Id. at 14. Mansley describes “having
`the gateway strip headers from incoming packets and deliver the headers and
`payloads to the servers in separate queues, in the same way as is done for
`intra-cluster communication.” Id.
`Analysis
`Claim 1 recites “a protocol processing entity providing an application
`programming interface (API) configured to process the received data in
`accordance with a network protocol to extract traffic data.” The preamble
`includes similar language in that it recites a data processing system for
`processing data in accordance with a network protocol to extract traffic data.
`Petitioner relies on the same features described in Mansley to meet the
`“extract traffic data” limitations. See, e.g., Pet. 20, 27.
`Specifically, Petitioner contends that Mansley’s TCP stack (TCP/IP
`stack) within the “data processing system” of Figure 3, meets the “protocol
`processing entity.” Pet. 25–27. Petitioner further contends that Mansley’s
`TCP stack implements sockets API, and, thus, meets the “provid[es] an
`
`9
`
`

`

`IPR2016-01832
`Patent 8,645,558 B2
`
`application programming interface (API)” limitation. Id. Petitioner further
`contends that “Mansley’s TCP stack that implements the sockets API
`performs protocol processing and extracts data for delivery to an
`application.” Id. (citing Ex. 1001 ¶¶ 83, 89). In support of its contentions
`that Mansley’s TCP/IP stack extracts data for delivery to an application,
`Petitioner and Dr. Jeffay rely on the description in Mansley that “[f]or
`TCP/IP there are essentially two operations that need to be performed on
`each packet. Firstly, it must be processed by the relevant protocol stacks.
`Secondly, if it contains valid data, it must be passed to the application.”
`Ex. 1003, 11. Petitioner and Dr. Jeffay also rely on the description in
`Mansley that “[w]e also separate the headers from the payloads and transfer
`them into two separate queues.” Id. at 12.
`Patent Owner argues that Petitioner has not shown that the TCP/IP
`stack extracts traffic data as claimed. Prelim. Resp. 28–34. Specifically,
`Patent Owner argues that
`The Petition cites to ¶83 and ¶89 of Dr. Jeffay’s declaration to
`allegedly support its assertion that Mansley’s TCP/IP stack
`extracts payload data. Petition, pp.20, 26–27. Dr. Jeffay’s
`assertion in ¶83 that Mansley’s TCP/IP stack processes the
`received data so that “the ‘payload’ (i.e., traffic data) is
`‘separate[d]’ (i.e. extracted) for access by the application” is
`supported only by citation to the same section of Mansley at p.12
`that states “[w]e also separate the headers from the payloads and
`transfer them into two separate queues.” Jeffay Decl., at ¶83.
`Nothing is cited to support the naked conclusion that it is the
`TCP/IP stack that performs the disclosed separation of the
`headers from the payloads—Dr. Jeffay does no analysis
`whatsoever to justify his hidden conclusion that the “we”
`referenced in the cited portion of Mansley refers to actions taken
`by the TCP/IP stack. Id. The other paragraph in Dr. Jeffay’s
`declaration (¶89) cited to support the assertion that Mansley’s
`
`10
`
`

`

`IPR2016-01832
`Patent 8,645,558 B2
`
`
`TCP/IP stack extracts the payload data provides no independent
`or additional analysis on this point and simply cites back to ¶83.
`
`
`Prelim. Resp. 29–30.
`We agree with Patent Owner’s arguments. In particular, Petitioner
`has not demonstrated sufficiently that Mansley’s TCP/IP stack (protocol
`processing entity) extracts data traffic. Petitioner relies on Mansley’s
`description that for “TCP/IP there are essentially two operations that need to
`be performed on each packet. Firstly, it must be processed by the relevant
`protocol stacks. Secondly, if it contains valid data, it must be passed to the
`application.” Ex. 1003, 11. That description in Mansley does not indicate
`that data is extracted or that it is the TCP/IP stack that extracts data.3
`Petitioner also relies on Mansley’s further description that “[w]e also
`separate the headers from the payloads and transfer them into two separate
`queues” to mean that it is the TCP/IP stack that separates the headers from
`the payloads. Pet. 25–26; Ex. 1001 ¶¶ 83, 89. We agree with Patent Owner,
`however, that Petitioner has not demonstrated sufficiently that the “we” in
`Mansley refers necessarily to the TCP/IP stack performing the separation of
`the headers from the payloads.
`In particular, Dr. Jeffay testifies that Mansley discloses providing a
`TCP/IP protocol stack or protocol suite, and that the protocol stack
`“performs TCP protocol processing to extract payload data from received
`network packets for delivery to the application, as discussed above with
`
`3 We find that a person having ordinary skill in the art at the time of the
`invention would have understood protocol processing to include any of
`extraction of data, sending acknowledgments, retransmission requests, and
`handling flow control data. Ex. 1002, 43:15–36, 46:36–41.
`
`11
`
`

`

`IPR2016-01832
`Patent 8,645,558 B2
`
`respect to the preamble. (Supra ¶ 83.)” Ex. 1001 ¶ 89. In paragraph 83 of
`his declaration, Dr. Jeffay testifies that “received packets are first processed
`by the relevant protocol stack and then data (i.e., ‘traffic data’) from the
`packet is passed to the application.” Id. ¶ 89. He further testifies that “[t]he
`result of this processing is that the ‘payload’ (i.e., traffic data) is
`‘separate[d]’ (i.e., extracted) for access by the application.” Id. In support of
`his testimony, Dr. Jeffay merely quotes the portion in Mansley that explains
`that “[w]e also separate the headers from the payloads and transfer them into
`two separate queues. In this way we prevent the payload queue becoming
`fragmented as headers are processed and discarded in advance of the
`application reading the payloads.” Id. (citing Ex. 1003, 12).
`Dr. Jeffay does not explain or provide a sufficient factual basis to
`support his conclusion that it is the TCP/IP stack in Mansley that
`“separate[s] the headers from the payloads” as opposed to some other
`component. As explained above, there is nothing in the quoted sections
`from Mansley that Dr. Jeffay directs attention to that indicates that it is the
`TCP/IP stack that extracts traffic data.
`Moreover, Mansley describes a bridge (gateway) connected between
`the CLAN network and Internet that can be used as a protocol processing
`gateway to help with TCP processing and that “strip[s] headers from
`incoming packets and deliver[s] the headers and payloads to the servers in
`separate queues, in the same way as is done for intra-cluster
`communication.” Id. at 14. Thus, at least in this embodiment, the payload
`
`12
`
`

`

`IPR2016-01832
`Patent 8,645,558 B2
`
`(traffic data4) is extracted by the gateway, which is outside of what
`Petitioner relies on to meet the preamble “processing data system” and the
`claimed “protocol processing entity.” Neither Petitioner, nor Dr. Jeffay,
`however, discusses or explains this or any other Mansley embodiment.
`Indeed, Dr. Jeffay only quotes the above noted passages from Mansley and
`merely concludes that the TCP/IP stack performs data extraction. Such a
`showing is conclusory and is entitled to little or no weight. See 37 CFR
`§ 42.65(a).
`For the above reasons, we determine that Petitioner has not shown that
`Mansley describes that the TCP/IP stack extracts traffic data as claimed.
`Accordingly, we are not persuaded that Petitioner has established a
`reasonable likelihood that Petitioner would prevail in its challenge to claim 1
`or claims 2–12 which depend from claim 1.
`
`III. CONCLUSION
`For the foregoing reasons, we determine that Petitioner has not shown
`a reasonable likelihood that it would prevail in showing that any one of
`claims 1–12 of the ’558 patent are unpatentable.
`
`
`
`IV. ORDER
`For the foregoing reasons, it is
`ORDERED that the Petition is denied as to all challenged claims, and
`no trial is instituted.
`
`
`
`
`
`
`4 The parties apparently agree that the “payload” referenced in Mansley is
`“traffic data.” See, e.g., Ex. 1001 ¶ 83; Prelim. Resp. 18.
`
`13
`
`

`

`IPR2016-01832
`Patent 8,645,558 B2
`
`PETITIONER:
`Russell Levine
`Eugene Goryunov
`KIRKLAND & ELLIS LLP
`russell.levine@kirkland.com
`egoryunov@kirkland.com
`
`PATENT OWNER:
`
`Richard F. Giunta
`Andrew J. Tibbetts
`WOLF, GREENFIELD & SACKS, P.C.
`rgiunta-ptab@wolfgreenfield.com
`atibbetts-ptab@wolfgreenfield.com
`
`
`14
`
`