IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`In the Inter Partes Review of:
`
`
`
`U.S. Patent No. 8,645,558
`
`Filed: June 15, 2006 (PCT filing date)
`
`Issued: February 4, 2014
`
`Named Inventor(s): Steven Leslie Pope,
`Derek Edward Roberts, David James
`Riddoch, Greg Law, Steve Grantham,
`Matthew Slattery
`
`Recorded Assignee: Solarflare
`Communications, Inc.
`
`Title: Reception According To A Data
`Transfer Protocol Of Data Directed To
`Any Of A Plurality Of Destination
`Entities For Data Extraction
`
`Mail Stop Inter Partes Review
`Commissions for Patents
`P.O. Box 1450
`Alexandria, VA 22313-1450
`
`
`
`
`
`PETITION FOR INTER PARTES REVIEW
`UNDER 35 U.S.C. § 311 AND 37 C.F.R. § 42.100
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. 8,645,558
`
`
`TABLE OF CONTENTS
`
`I.
`
`Introduction .................................................................................................... 1
`
`II. Mandatory Notices......................................................................................... 1
`
`A.
`
`B.
`
`C.
`
`Real Party-in-Interest (37 C.F.R. § 42.8(b)(1)) ..................................... 1
`
`Related Matters (37 C.F.R. § 42.8(b)(2)) .............................................. 1
`
`Designation of Lead and Backup Counsel and Service
`Information (37 C.F.R. §§ 42.8(b)(3)-(4)) ............................................ 1
`
`III. Fee for Inter Partes Review (37 C.F.R. § 42.103) ........................................ 2
`IV. Grounds for Standing (37 C.F.R. § 42.104(a)) ............................................ 2
`
`V.
`
`Identification of Challenge (37 C.F.R. § 42.104(b)) .................................... 2
`
`VI. Relevant Background on the ’558 Patent .................................................... 4
`
`A.
`
`B.
`
`Level of Ordinary Skill ......................................................................... 4
`
`Description of the Alleged Invention of the ’558 Patent ...................... 4
`
`VII. Claim Construction ....................................................................................... 9
`
`A.
`
`“in response to signaling from a thread of the application”
`(Claim 1) ..............................................................................................10
`
`VIII. Reasonable Likelihood that Claims 1–12 are Unpatentable ...................14
`
`A. GROUND 1: Claims 1–5, 7, and 10–12 are anticipated by
`Mansley under § 102 ...........................................................................14
`
`1.
`
`2.
`
`3.
`
`4.
`
`5.
`
`Background of Mansley ............................................................14
`
`Claim 1 is anticipated by Mansley ............................................19
`
`Claim 2 is anticipated by Mansley ............................................30
`
`Claim 3 is anticipated by Mansley ............................................31
`
`Claim 4 is anticipated by Mansley ............................................32
`
`
`
`i
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. 8,645,558
`
`
`6.
`
`7.
`
`8.
`
`9.
`
`Claim 5 is anticipated by Mansley ............................................32
`
`Claim 7 is anticipated by Mansley ............................................33
`
`Claim 10 is anticipated by Mansley ..........................................34
`
`Claim 11 is anticipated by Mansley ..........................................35
`
`10. Claim 12 is anticipated by Mansley ..........................................35
`
`B.
`
`GROUND 2: Claim 6 is obvious in view of the combination of
`Mansley and Riddoch under § 103 ......................................................36
`
`1.
`
`2.
`
`Background on Riddoch ...........................................................36
`
`Claim 6 is rendered obvious .....................................................37
`
`C.
`
`GROUND 3: Claims 8 and 9 are obvious in view of the
`combination of Mansley and the Knowledge of PHOSITA
`under § 103 ..........................................................................................41
`
`1.
`
`2.
`
`Knowledge of PHOSITA ..........................................................41
`
`Claims 8 and 9 are obvious in view of the combination of
`Mansley and the Knowledge of PHOSITA ..............................42
`
`IX. Secondary Considerations Do Not Support The Non-Obviousness
`of the ’558 Patent Claims ............................................................................44
`
`X. Conclusion ....................................................................................................44
`
`
`
`ii
`
`
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. 8,645,558
`
`I.
`
`INTRODUCTION
`Exablaze Pty. Ltd. (“Petitioner”) requests inter partes review of Claim 1–12
`
`of U.S. Patent No. 8,645,558 (“the ’558 Patent”). (Ex. 1002.)
`
`II.
`
`MANDATORY NOTICES
`A. Real Party-in-Interest (37 C.F.R. § 42.8(b)(1))
`Exablaze Pty Ltd. and Zomojo Pty. Ltd. are the real parties-in-interest for
`
`Petitioner.
`
`B. Related Matters (37 C.F.R. § 42.8(b)(2))
`Solarflare Communications, Inc. (“Solarflare”) has asserted the ’558 Patent
`
`against Petitioner in: Solarflare Comms. v. Exablaze Pty. Ltd., Case No. 16-cv-
`
`01891 (D. NJ). The case was filed on April 5, 2016.
`
`This case may affect, or be affected by, decisions in this proceeding.
`
`C. Designation of Lead and Backup Counsel and Service
`Information (37 C.F.R. §§ 42.8(b)(3)-(4))
`
`Lead Counsel
`Russell Levine (Reg. No. 32,153)
`russell.levine@kirkland.com
`Postal and Hand-Delivery Address:
`KIRKLAND & ELLIS LLP
`300 North LaSalle Street
`Chicago, Illinois 60654
`Telephone: (312) 862-2000
`Fax: (312) 862-2200
`
`
`Backup Lead Counsel
`Eugene Goryunov (Reg. No. 61,579)
`egoryunov@kirkland.com
`Postal and Hand-Delivery Address:
`KIRKLAND & ELLIS LLP
`300 North LaSalle Street
`Chicago, Illinois 60654
`Telephone: (312) 862-2000
`Fax: (312) 862-2200
`
`Petitioner concurrently submits a Power of Attorney, 37 C.F.R. § 42.10(b),
`
`and consents to service by email at Exablaze_IPR_Service@kirkland.com.
`
`
`
`1
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. 8,645,558
`
`III.
`
`FEE FOR INTER PARTES REVIEW (37 C.F.R. § 42.103)
`The undersigned authorizes the PTO to charge the fee set forth in 37 C.F.R.
`
`§ 42.15(a) for this Petition to Deposit Account No. 506092. Review of twelve (12)
`
`claims is requested, and thus no excess claim fees are required. The undersigned
`
`further authorizes payment for any additional fees that may be due in connection
`
`with this Petition to be charged to the above-referenced Deposit Account.
`
`IV.
`
`GROUNDS FOR STANDING (37 C.F.R. § 42.104(A))
`
`Petitioner certifies that they have standing to request, and are not barred or
`
`estopped from requesting, an IPR of the ’558 Patent. Petitioner certifies: (1)
`
`Petitioner is not the owner of the ’558 Patent; (2) Petitioner (or any real party-in-
`
`interest) has not filed a civil action challenging the validity of any claim of the
`
`’558 Patent; (3) Petitioner files this Petition within one year of the date it was
`
`served with a complaint asserting infringement of the ’558 Patent; (4) the estoppel
`
`provisions of 35 U.S.C. § 315(e)(1) do not prohibit this IPR; and (5) this Petition is
`
`filed after the ’558 Patent was granted.
`
`V.
`
`IDENTIFICATION OF CHALLENGE (37 C.F.R. § 42.104(B))
`
`Petitioners request institution of an IPR and cancellation of Claims 1–12 of
`
`the ’558 Patent based on the following:
`
`Mansley. “Engineering a User-Level TCP for the CLAN Network” by
`
`Kieran Mansley. (Ex. 1003.) Mansley (1) was published in 2003 in the
`
`Proceedings of
`
`the ACM SIGCOMM 2003 Workshop on Network I/O
`
`
`
`2
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. 8,645,558
`
`Convergence: Experience, Lessons, Implications; (2) is prior art under 35 U.S.C.
`
`§ 102(b);1 and (3) was not submitted to, or considered by, the PTO in prosecution.
`
`Riddoch. “Distributed Computing with the CLAN Network” by David
`
`Riddoch, Kieran Mansley, and Steve Pope. (Ex. 1005.) Riddoch (1) was
`
`published in 2002 in the Proceedings of the 27th Annual IEEE Conference on
`
`Local Computer Networks; (2) is prior art under 35 U.S.C. § 102(b); and (3) was
`
`not submitted to, or considered by, the PTO in prosecution.
`
`The statutory grounds on which Petitioner’s challenge is based are:
`
`Ground 1: Claims 1–5, 7, and 10–12 are anticipated by Mansley under
`
`§ 102(b);
`
`Ground 2: Claim 6 is obvious in view of the combination of Mansley and
`
`Riddoch under § 103(a);
`
`Ground 3: Claims 8–9 are obvious in view of the combination of Mansley
`
`and the Knowledge of Persons Having Ordinary Skill In The Art (“PHOSITA”)
`
`under § 103(a).
`
`Petitioner sets forth the relevant background on the ’558 Patent (Section VI),
`
`how the contested Claims are to be construed (Section VII), and how the construed
`
`Claims are unpatentable under the statutory grounds (Section VIII).
`
`
`1
`Cites to 35 U.S.C. §§ 102 and 103 are to the pre-AIA version.
`
`
`
`3
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. 8,645,558
`
`
`Attached is an Appendix of Exhibits. The relevance of the evidence,
`
`including the specific portions that support the challenge, is set forth in Section
`
`VIII. Petitioner submits a declaration by Dr. Kevin Jeffay in support of this
`
`Petition. 37 C.F.R. § 1.68. (Ex. 1001.)
`
`VI.
`
`RELEVANT BACKGROUND ON THE ’558 PATENT
`A. Level of Ordinary Skill
`PHOSITA would have a B.S. degree, or its equivalent, in Computer Science,
`
`Computer Engineering, Electrical Engineering, or a related field, as well as a
`
`Master of Science degree, or equivalent, in one of those fields or approximately 2–
`
`3 years of academic or industry experience in the design of software for network
`
`protocol processing. More work experience could compensate for a lack of post-
`
`graduate degree. (Ex. 1001, Jeffay Decl., ¶ 26.)
`
`B. Description of the Alleged Invention of the ’558 Patent
`The ’558 Patent purports to describe and claim a data processing system that
`
`processes network traffic. (Ex. 1002, ’558 Patent, at col. 42, ll. 51–52.) In
`
`particular, the claimed data processing system includes a protocol processing entity
`
`that performs protocol processing on data received over the network. (Id. at col.
`
`44, ll. 19–29.) A protocol for communication on a network “conventionally
`
`includes a specification of how traffic data is to be carried, and also how control
`
`functions are to be implemented.” (Id. at col. 43, ll. 15–18; see also id. at col. 43,
`
`ll. 18–21 (stating that control functions typically include “error checking,
`
`
`
`4
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. 8,645,558
`
`retransmission requests and responses, flow control and basic network messages
`
`such as those for identifying whether a host is active or reachable.”).) The
`
`specification discloses several protocol examples: Transmission Control Protocol
`
`(TCP), User Datagram Protocol (UDP), Internet Control Message Protocol
`
`(ICMP), and Real-Time Transport Protocol (RTP). (Id. at col. 3, ll. 26–32.) The
`
`’558 Patent discloses that protocol processing is “the processing of data in
`
`accordance with the protocol for transmission or reception.” (Id. at col. 43, ll. 34–
`
`36.) Protocol processing is performed in order to extract traffic data. (Id. at col.
`
`44, ll. 19–29; cl. 1.) After extracting the traffic data, the system provides it to the
`
`application for which the data was intended, such as a database application. (Id. at
`
`col. 43, ll. 53–56; col. 48, ll. 58–63.)
`
`Although protocol processing is traditionally implemented by the operating
`
`system,
`
`in
`
`the preferred embodiment,
`
`the protocol processing entity
`
`is
`
`implemented at a higher level than the operating system, i.e., at the user-level. (Id.
`
`at col. 44, ll. 30–33.)
`
`The claimed protocol processing entity provides an application
`
`programming interface (API). (Id. at col. 44, ll. 36–37.) An API is a mechanism
`
`through which applications can access a bundle of functions or resources. (Ex.
`
`1001, Jeffay Decl., ¶ 38; see also Ex. 1006, Peterson & Davie, at 5–6 (stating that,
`
`with respect to a network API, “Each protocol provides a certain set of services,
`
`
`
`5
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. 8,645,558
`
`and the API provides the syntax by which those services can be invoked.”).) The
`
`API described in the ’558 Patent is the well-known sockets API. (Ex. 1002, ’558
`
`Patent, at col. 3, ll. 16–21; Ex. 1001, Jeffay Decl., ¶¶ 40, 46.) A socket is a
`
`software abstraction provided by the sockets API that “connects the application to
`
`remote entities by means of a network protocol.” (Ex. 1002, ’558 Patent, col. 2, ll.
`
`14–18; Ex. 1001, Jeffay Decl., ¶ 40.) The sockets API enables an application to,
`
`for example, “send and receive TCP/IP messages by opening a socket and reading
`
`and writing data to and from the socket.” (Ex. 1002, ’558 Patent, at col. 2, ll. 18–
`
`22; see also Ex. 1006, Peterson & Davie, at 5–6 (stating that the sockets API
`
`“defines operations for creating a socket, attaching the socket to the network,
`
`sending/receiving messages through the socket, and closing the socket.”).)
`
`The alleged point of novelty of the ’558 Patent is that the protocol
`
`processing entity performs protocol processing on data received over the network
`
`in response to signaling from an application. (Ex. 1002, ’558 Patent, at col. 44, ll.
`
`46–50; Ex. 1001, Jeffay Decl., ¶¶ 48–49.) In particular, the signaling comes from
`
`a thread of an application that inquires whether data is available for processing.
`
`(Ex. 1002, ’558 Patent, at col. 44, ll. 46–50; col. 44, ll. 55–58.) Signaling,
`
`according to the applicants, distinguished the alleged invention from prior art
`
`systems where protocol processing was driven by the mere receipt of data. (Ex.
`
`1002, ’558 Patent at col. 43, ll. 41–67; Ex. 1001, Jeffay Decl., ¶¶ 43, 49.) The
`
`
`
`6
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. 8,645,558
`
`purported benefit of using signaling to trigger protocol processing, as opposed to
`
`mere data receipt, is a performance improvement derived from the system not
`
`interrupting running processes (or threads) every time data is received over the
`
`network. (Ex. 1002, ’558 Patent at col. 46, l. 50–col. 47, l. 4; Ex. 1001, Jeffay
`
`Decl., ¶ 49.)
`
`The ’558 Patent specifies that an application may issue a “a select() and/or a
`
`poll() call” in order to signal a request for available data. (Id. at col. 44, ll. 49–50;
`
`see also Ex. 1001, Jeffay Decl., ¶ 42 (explanation of select() call known in the
`
`prior art).) These calls are resolved “by means of a static linkage,” or alternatively,
`
`by means of a “dynamic linkage.” (Id. at col. 44, ll. 52–54.) Although the
`
`specification does not further describe “static linkage,” statically linked libraries
`
`are a well known concept in which the applications are combined with the library
`
`functions they use prior to execution of the application. (Ex. 1001, Jeffay Decl.,
`
`¶ 49.) A dynamically linked library, on the other hand, is combined with an
`
`application when the application is executed, at “runtime.” (Ex. 1002, ’558 Patent,
`
`at col. 47, ll. 33–34; Ex. 1001, Jeffay Decl., ¶¶ 39, 50.)
`
`In one embodiment, the ’558 Patent suggests its protocol processing avoids
`
`costly interrupts through use of an “event buffer.” (Ex. 1002, ’558 Patent, at col.
`
`45, ll. 26–28; col. 47, ll. 1–4 (referring to “event queue”).) The event buffer “acts
`
`to provide a queue of events that can be actioned by the library when required.”
`
`
`
`7
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. 8,645,558
`
`(Id. at col. 45, ll. 53–54.) The specification further discloses that the “event buffers
`
`are used by the NIC to signal to the library [(e.g., the protocol processing entity)]
`
`that events such as the receipt of data have occurred.” (Id. at col. 45, ll. 26–28.)
`
`An “event” is described as a “data unit of a predefined format that indicates to the
`
`library that data has been received.” (Id. at col. 45, ll. 48–49.) “The event may
`
`include information such as time when the data was received and the buffer it has
`
`been written to.” (Id. at col. 45, ll. 51–53.)
`
`Claim 1 recites:
`
`[A] 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:
`
`[B] a memory;
`
`[C] a network interface for receiving the data from the
`network and storing the data in the memory;
`
`[D] an operating system for supporting one or more
`applications;
`
`[E] an application supported by the operating system;
`and
`
`[F] 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 therefrom, the protocol processing
`
`
`
`8
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. 8,645,558
`
`
`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.
`
`(Ex. 1002, ’558 Patent, Claim 1.) (bold element letters added)
`
`Both the alleged problem and the purported solution claimed by the ’558
`
`Patent are disclosed by the prior art.
`
`VII.
`
`CLAIM CONSTRUCTION
`
`Petitioner submits, for purposes of this IPR only, that certain terms of the
`
`’558 Patent should be construed. A claim in IPR is given the broadest reasonable
`
`interpretation (“BRI”) in light of the specification to a PHOSITA. 37 C.F.R.
`
`§ 42.100(b). “In addition, the applicant may act as a lexicographer by setting out a
`
`definition in some manner within the patent disclosure.” In re Scroggie, 442 Fed.
`
`App’x 547, 549 (Fed. Cir. 2011). BRI must take “into account any definitions
`
`presented in the specification.” In re Bass, 314 F.3d 575, 577 (Fed. Cir. 2002).
`
`The prosecution history should also be considered as part of the BRI analysis. See
`
`Microsoft Corp. v. Proxyconn, Inc., 789 F.3d 1292, 1298 (Fed. Cir. 2015) (“The
`
`PTO should also consult the patent’s prosecution history in proceedings in which
`
`the patent has been brought back to the agency for a second review.”).
`
`
`
`9
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. 8,645,558
`
`
`A.
`
`“in response to signaling from a thread of the application”
`(Claim 1)
`
`The BRI of the phrase “in response to signaling from the application” is “in
`
`response to signaling from a process or part of a process of the application, not in
`
`response to receiving the data from the network.”
`
`The applicants made a “clear and unmistakable” disclaimer during
`
`prosecution of the ’558 Patent. Omega Eng’g, Inc, v. Raytek Corp., 334 F.3d
`
`1314, 1325–26 (Fed. Cir. 2003). The applicants repeatedly and unequivocally
`
`contrasted a well-known prior art mechanism of performing protocol processing
`
`“in response to receiving data from the network” with the claim language of
`
`protocol processing “in response to signaling from the thread of the application.”
`
`The applicants first disclaimed processing in response to receiving data from the
`
`network on December 13, 2012, when they attempted to distinguish art cited by the
`
`Examiner in an office action. Specifically, the applicants argued that U.S. Patent
`
`No. 5,951,645 to Goto (“Goto”) did not disclose the claimed invention:
`
`Moreover, in col. 4, lns 37-44, Goto describes that the
`communication control section receives data from the
`network, and performs data processing upon reception of
`data from the network . . . As such, Goto is understood to
`describe a technique that includes a communication
`control section that performs protocol processing of data
`received from the network, in response to receiving the
`
`
`
`10
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. 8,645,558
`
`
`data from the network, and not in response to signaling
`from the application.
`
`(Ex. 1008, 12/13/2012 Response to OA at 35 (emphasis in original).)
`
`The applicants repeated this argument on July 30, 2012, again arguing that
`
`“Goto describes performing data processing upon reception of data from the
`
`network, rather than in response to signaling from a thread of an application.” (Ex.
`
`1010, 7/30/2013 RCE at 31 (emphasis in original).) The applicants’ arguments
`
`leave no room for ambiguity: performing protocol processing in response to
`
`receiving data from the network is not within the scope of the claims.
`
`The specification confirms this conclusion. In particular, the specification
`
`distinguishes performing protocol processing “in response” to signaling from an
`
`application from doing so “in response to receiving data from the network.” For
`
`example, the specification discloses that “protocol processing (typically TCP/IP
`
`and UDP/IP protocol processing) of raw received data… is performed in response
`
`to requests from applications rather than in response to the receipt of data.” (Ex.
`
`1002, ’558 Patent at col. 46, ll. 50–54) (emphasis added). Elsewhere, the
`
`specification discloses:
`
`library does not
`the
`During normal operation
`automatically process received data in response to its
`being written to a buffer or in response to an event being
`added to the event queue. The received data therefore
`
`
`
`11
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. 8,645,558
`
`
`sits in the data buffer without protocol processing being
`performed on it. However, when an application wishes
`to receive data it signals the library … Thus, for received
`data the protocol processing is carried out by the library
`14, at user level, in response to a request or command
`received from an application. It is not driven by the
`receipt of data.
`
`(Id. at col. 45, l. 55–col. 46, l. 8.) (emphasis added)
`
`The specification further describes the various alleged disadvantages to
`
`performing protocol processing “in response to receiving the data from the
`
`network,” further distinguishing that technique from the claimed invention. For
`
`example, the specification discloses:
`
`One significant disadvantage is the need for context
`switching whenever data is received from the NIC.
`When the data is received the processor 5 may be
`executing a program thread. That thread must be
`temporarily suspended and a new thread executed in
`order to allow the operating system to process the
`received data. Then the original thread is resumed. This
`switching of
`threads
`significantly
`reduces
`the
`performance of the data processing system. Another
`issue is that the use of interrupts and system calls for
`signalling [sic] the operating system uses up system
`resources.
`
`
`
`12
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. 8,645,558
`
`(Id. at col. 43, ll. 57–67.) In contrast, the specification discloses several alleged
`
`advantages to instead performing protocol processing in response to requests from
`
`applications:
`
`This can reduce the need for context switching both
`between user and kernel context or between threads in a
`user-level library. Multiple blocks of raw data can be
`received and stored in the data buffers, but protocol
`processing need not be performed after each one arrives.
`Instead, protocol processing can be performed for all
`those blocks together, when initiated by an application's
`request for data. This agglomeration of the protocol
`processing operations also results in a reduction in the
`number of transfers of data between the cache of the
`processor 5 and the data buffers. The system can provide
`these advantages whilst applying the same network
`protocols, packet formats and control plane protocols as
`would be required to communicate with the NIC in a
`prior art system.
`
`(Id. at col. 46, ll. 54–67.)
`
`The applicants consistently distinguished the claimed invention from the
`
`prior art technique of performing protocol processing in response to receiving data
`
`from the network is pervasive. The BRI of the term “in response to signaling from
`
`a thread of the application” accordingly excludes performing protocol processing
`
`“in response to receiving the data from the network.”
`
`
`
`13
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. 8,645,558
`
`VIII.
`
`REASONABLE LIKELIHOOD THAT CLAIMS 1–12 ARE
`UNPATENTABLE
`
`Below is a detailed discussion of why Claims 1–12 are unpatentable.
`
`A. GROUND 1: Claims 1–5, 7, and 10–12 are anticipated by
`Mansley under § 102
`1.
`Mansley discloses a technique for “user-level” protocol processing. (Ex.
`
`Background of Mansley
`
`1003, Mansley, at 8.) The focus of the technique is on the TCP protocol, one of
`
`the protocols expressly addressed by the ’558 Patent. In Mansley, the TCP
`
`protocol is implemented at the application layer, as opposed to the operating
`
`system (or kernel) layer. (Ex. 1001, Jeffay Decl., ¶ 71.) By implementing a TCP
`
`protocol stack at the user-level, Mansley aims to avoid the inefficiencies of
`
`traditional protocol processing, which typically takes place in the operating system.
`
`(Id.) When protocol processing is implemented at the operating system, several
`
`costly mechanisms are required in order to pass the data from the network
`
`interface, to the operating system, and eventually on to the application. (Ex. 1003,
`
`Mansley, at 8.) These include “copying data between buffers, demultiplexing,
`
`interrupts, system calls, and inefficient protocols.” (Id.) The various mechanisms
`
`use up CPU cycles that the system can use for performing work for the
`
`applications. (Id.) “User-level networking has the potential to address many of
`
`these problems.” (Id.) User-level networking enables an application to
`
`
`
`14
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. 8,645,558
`
`communicate the network interface card (“NIC”) directly, bypassing the operating
`
`system, improving efficiency. (Id.; Ex. 1001, Jeffay Decl., ¶ 71.)
`
`Mansley teaches performing two essential operations on each TCP/IP packet
`
`it receives over the network: (1) the packet is “processed by the relevant protocol
`
`stacks”; (2) the data extracted from this processing is “passed to the application”
`
`that it is destined for. (Ex. 1003, Mansley, at 11; Ex. 1001, Jeffay Decl., ¶ 72.) In
`
`order to facilitate interaction between applications and the TCP/IP protocol stack,
`
`Mansley teaches providing an API. (Ex. 1003, Mansley, at 8.) Specifically,
`
`Mansley teaches use of the well-known “sockets” API. (Id. at 10; Ex. 1001, Jeffay
`
`Decl., ¶¶ 40, 73.) This is the same API disclosed as a preferred embodiment in the
`
`’558 Patent. (See Ex. 1002, ’558 Patent at col. 3, ll. 16–21 (“Fig. 2 shows
`
`components implementing a TCP stack for use in accordance with embodiments of
`
`the present invention. Layers of the stack include an application 1 and a socket 2
`
`provided by the socket library. The socket library is an application program
`
`interface (API) for building software applications.”); Ex. 1001, Jeffay Decl., ¶ 46.)
`
`Mansley further teaches that a thread of the application interacts with the
`
`TCP protocol stack (e.g., via sockets API). (Ex. 1003, Mansley, at 10; Ex. 1001,
`
`Jeffay Decl., ¶ 75.) In particular, Mansley teaches that “each application thread
`
`can access the TCP/IP stack directly.” (Ex. 1003, Mansley, at 10.) As a result,
`
`Mansley teaches performing “the majority of [TCP] protocol processing in the
`
`
`
`15
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. 8,645,558
`
`same thread as the application.” (Id.) Mansley explains that “[t]his approach is
`
`becoming popular in other areas of computing where high performance is required.
`
`For example omniORB [33] avoids thread switches on the call path by performing
`
`all work in the calling thread.” (Id. at 10 n1) (emphasis added).
`
`The interaction between the application thread and the TCP stack is
`
`illustrated in Mansley’s Figure 3:
`
`
`(Id. at Figure 3 (depicting data flow from the NIC (Network Interface) through the
`
`TCP/IP stack to a thread of the Application).)
`
`Mansley further teaches performing protocol processing “lazily.” (Id. at 11.)
`
`“Lazy” processing means that protocol processing is done “when the application
`
`asks for it.” (Id.) An advantage of this approach includes “improved cache
`
`performance” because data to be extracted through protocol processing is “touched
`
`by the stack just before the application makes use of it.” (Id.) Petitioner provides
`
`the following graphics to illustrate Mansley’s mechanism.
`
`Step one (Graphic I) - packet is received over the network; protocol
`
`processing has not yet occurred:
`
`
`
`16
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. 8,645,558
`
`
`
`The Network Interface (NIC) stores the packet in a buffer in memory. (See id. at 8
`
`(“[In user-level networking] the NIC is able to deliver received data directly into
`
`the application’s buffer”); 9 (“The buffer for the circular queue physically resides
`
`in the memory of the receiver.”); Ex. 1001, Jeffay Decl., ¶¶ 71, 84.)
`
`Step two (Graphic II) - application thread signals to the TCP stack
`
`requesting available data:
`
`
`
`17
`
`
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. 8,645,558
`
`This is accomplished using the sockets API. (Ex. 1003, Mansley, at 10; Ex. 1001,
`
`Jeffay Decl., ¶¶ 73, 76.) The application signals to the protocol stack using the
`
`select() call. (Ex. 1003, Mansley, at 10.) Specifically, Mansley teaches:
`
`A common criticism of other user level network libraries
`is
`that applications cannot use select() with a
`combination of the user-level socket file descriptors and
`traditional OS file descriptors. In our case this is possible
`due to the way the asynchronous event queues that select
`responses to are implemented . . ., and is invisible to the
`application.
`
`(Id. (emphasis added).) The select() signal is similarly described as a preferred
`
`embodiment in the ’558 Patent. (Ex. 1002, ’558 Patent at col. 44, ll. 49–50.)
`
`Step three (Graphic III) - TCP Stack performs protocol processing (Ex.
`
`1003, Mansley, at 11) in response to the application thread’s signal:
`
`
`
`18
`
`
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. 8,645,558
`
`
`Step four (Graphic IV) - data extracted as a result of the protocol processing
`
`is delivered to the application (Id. at 11):
`
`
`An element-by-element analysis of how Mansley discloses all elements of
`
`Claims 1–5, 7, and 10–12, arranged as claimed, follows.
`
`2.
`
`Claim 1 is anticipated by Mansley
`(a) Preamble: Mansley discloses [A] “[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”
`
`Mansley discloses “a data processing system” (Mansley’s server) “for
`
`receiving data from a network” (Mansley’s data communicated in a server cluster
`
`network), “and processing that data in accordance with a network protocol to
`
`extract traffic data thereform” (Mansley’s processing received packets in
`
`accordance with the TCP protocol and extracting the data contained in the packet).
`
`
`
`19
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. 8,645,558
`
`
`First, Mansley teaches servers in a server cluster network implementing a
`
`suite of network protocols. (See Ex. 1003, Mansley, at 8, 14 (“We have therefore
`
`created our own testbed to allow direct comparison of different technologies. This
`
`consists of four PCs acting as the server nodes connected via the CLAN switch.”);
`
`Ex. 1001, Jeffay Decl., ¶ 82.)
`
`Second, Mansley teaches that packets received over the network are first
`
`processed by the relevant protocol stack (of the data processing system) in
`
`accordance with a network protocol, such as TCP. (See Ex. 1003, Mansley, at 8,
`
`11 (“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.”); Ex.
`
`1001, Jeffay Decl., ¶ 83.)
`
`Third, as a result of the TCP processing, data (i.e., “traffic data”) is extracted
`
`from the packet and passed to the application. (See Ex. 1003, Mansley, at 11
`
`(“Secondly, if it contains valid data, it must be passed to the application.”), 12 (“
`
`
`
`We also separate the headers from the payloads [of received packets] and
`
`transfer them into two separate queues.”); Ex. 1001, Jeffay Decl., ¶ 83.)
`
`(b) Mansley discloses [B] “a memory”
`Mansley discloses the limitation of “a memory” (Mansley’s “host me