IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`
`In the Inter Partes Review of:
`
`
`
`U.S. Patent No. 8,612,536
`
`Filed: June 30, 2011
`
`Issued: December 17, 2013
`
`Named Inventor(s): Steven L. Pope,
`David J. Riddoch
`
`Recorded Assignee: Solarflare
`Communications, Inc.
`
`Title: User-Level Stack
`
`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
`
`

`
`
`
`TABLE OF CONTENTS
`
`I.
`
`Introduction .................................................................................................... 1
`
`II. Mandatory Notices......................................................................................... 1
`
`A.
`
`Real Party-in-Interest (37 C.F.R. § 42.8(b)(1)) ..................................... 1
`
`B.
`
`C.
`
`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)) .................................... 3
`
`VI. Relevant Background on the ’536 Patent .................................................... 5
`
`A.
`
`Level of Ordinary Skill ......................................................................... 5
`
`B.
`
`Description of the Alleged Invention of the ’536 Patent ...................... 5
`
`VII. Claim Construction .....................................................................................12
`
`VIII. Reasonable Likelihood that Claims 1–17 are Unpatentable ...................14
`
`A. GROUND 1: Claims 1–3, 5–6, 10–11, and 13–14 are obvious
`in view of the combination of Druschel & Andjelic ...........................14
`
`1.
`
`2.
`
`3.
`
`4.
`
`5.
`
`6.
`
`7.
`
`Background of Druschel ...........................................................14
`
`Background of Andjelic ............................................................17
`
`Claim 1 is obvious.....................................................................19
`
`Claim 2 is obvious.....................................................................29
`
`Claim 3 is obvious.....................................................................30
`
`Claim 5 is obvious.....................................................................31
`
`Claim 6 is obvious.....................................................................32
`
`i
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. 8,612,536
`
`
`8.
`
`9.
`
`Claim 10 is obvious ..................................................................33
`
`Claims 11 and 13–14 are obvious .............................................40
`
`B.
`
`GROUND 2: Claims 4 and 7–9 are obvious in view of the
`combination of Druschel, Andjelic, and Chesson ...............................40
`
`1.
`
`2.
`
`3.
`
`4.
`
`5.
`
`Background on Chesson ...........................................................40
`
`Claims 4 is obvious ...................................................................44
`
`Claim 7 is obvious.....................................................................49
`
`Claim 8 is obvious.....................................................................51
`
`Claim 9 is obvious.....................................................................51
`
`C.
`
`GROUND 3: Claims 12 and 15–17 are obvious in view of the
`combination of Druschel, Andjelic, and Maquelin .............................52
`
`1.
`
`2.
`
`3.
`
`4.
`
`5.
`
`Background on Maquelin ..........................................................52
`
`Claim 12 is obvious ..................................................................53
`
`Claim 15 is obvious ..................................................................57
`
`Claim 16 is obvious ..................................................................59
`
`Claim 17 is obvious ..................................................................60
`
`IX. Secondary Considerations Do Not Support The Non-Obviousness
`of the ’536 Patent Claims ............................................................................60
`
`X. Conclusion ....................................................................................................60
`
`ii
`
`
`
`
`
`

`
`
`
`
`I.
`
`INTRODUCTION
`
`Exablaze Pty. Ltd. (“Petitioner”) requests inter partes review of Claims 1–
`
`17 of U.S. Patent No. 8,612,536 (“the ’536 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 ’536 Patent
`
`against Petitioner in: Solarflare Comms. v. Exablaze Pty. Ltd., Case No. 16-cv-
`
`01891 (D. NJ). Solarflare amended its complaint on July 14, 2016, to allege, for
`
`the first time, infringement of the ’536 Patent.
`
`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
`
`Backup 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
`
`
`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
`
`1
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. 8,612,536
`
`
`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.
`
`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
`
`seventeen (17) claims is requested and an excess claim fee is submitted. 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 ’536 Patent. Petitioner certifies: (1)
`
`Petitioner is not the owner of the ’536 Patent; (2) Petitioner (or any real party-
`
`in-interest) has not filed a civil action challenging the validity of any claim of
`
`the ’536 Patent; (3) Petitioner files this Petition within one year of the date it
`
`was served with a complaint asserting infringement of the ’536 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 ’536 Patent was granted.
`
`
`
`2
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. 8,612,536
`
`
`V.
`
`IDENTIFICATION OF CHALLENGE (37 C.F.R. § 42.104(B))
`
`Petitioners request institution of an IPR and cancellation of Claims 1–17
`
`of the ’536 Patent based on the following:
`
`Druschel. “Operating System Support for High-Speed Communication”
`
`by Peter Druschel. (Ex. 1003.) Druschel: (1) was published in September,
`
`1996 in Communications of the ACM, Vol. 39, Issue No. 9; (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.
`
`Andjelic. U.S. Patent No. 7,451,456 to Mario Andjelic. (Ex. 1004.)
`
`Andjelic: (1) is a U.S. Patent issuing from an international application that was
`
`filed on June 19, 2002 and published as a WIPO publication in English (Ex.
`
`1011); (2) is prior art under at least 35 U.S.C. § 102(e); and (3) was not
`
`submitted to, or considered by, the PTO in prosecution.
`
`Chesson. U.S. Patent No. 6,594,787 to Gregory L. Chesson. (Ex. 1005.)
`
`Chesson: (1) was filed September 17, 1999, and issued July 15, 2003; (2) is
`
`prior art under at least 35 U.S.C. §§ 102(a) and 102(e); and (3) was not
`
`submitted to, or considered by, the PTO in prosecution.
`
`Maquelin. “Polling Watchdog: Combining Polling and Interrupts for
`
`Efficient Message Handling” by Olivier Maquelin. (Ex. 1007.) Maquelin: (1)
`
`
`1
`Cites to 35 U.S.C. §§ 102 and 103 are to the pre-AIA versions.
`
`
`
`3
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. 8,612,536
`
`
`was published in 1996 in the Proceedings of the 23rd Annual International
`
`Symposium on Computer Architecture; (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–3, 5–6, 10–11, and 13–14 are rendered obvious by
`
`Druschel in view of Andjelic under § 103(a);
`
`Ground 2: Claims 4 and 7–9 are rendered obvious by Druschel in view
`
`of Andjelic and Chesson under § 103(a); and
`
`Ground 3: Claims 12 and 15–17 are rendered obvious by Druschel, in
`
`view of the Andjelic and Maquelin under § 103(a).
`
`Petitioner sets forth the relevant background on the ’536 Patent (Section
`
`VI), how the contested Claims are to be construed (Section VII), and how
`
`construed Claims are unpatentable under the statutory grounds (Section VIII).
`
`Attached is an Appendix of Exhibits. The relevance of the evidence,
`
`including identifying the specific portions of the evidence 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.)
`
`
`
`4
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. 8,612,536
`
`
`VI.
`
`RELEVANT BACKGROUND ON THE ’536 PATENT
`
`A. Level of Ordinary Skill
`
`Person’s having ordinary skill in the art (“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., ¶ 25.)
`
`B. Description of the Alleged Invention of the ’536 Patent
`
`The ’536 Patent purports to describe and claim a data processing system
`
`that transmits or receives data using “non-operating system” functionality. (Ex.
`
`1002, ’536 Patent, at Abstract; col. 6, l. 58–col. 7, l. 6.) In particular, the ’536
`
`Patent describes providing a “transport library” that performs processing
`
`necessary for communication over a network. (Id. at col. 6, ll. 17–20; col. 9, ll.
`
`29–31.) PHOSITA would have understood the term “library” to refer to a
`
`collection of functions. (Ex. 1001, Jeffay Decl., ¶ 45.) The processing
`
`performed by the transport library includes network protocol processing. (Ex.
`
`1002, ’536 Patent, at col. 9, ll. 29–31.)
`
`A network protocol is the set of rules defining the formatting and
`
`processing of messages over a network. (Ex. 1001, Jeffay Decl., ¶ 33.)
`
`
`
`5
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. 8,612,536
`
`
`Protocol processing involves forming data into a required format for
`
`transmission or parsing received messages in order to extract data for use by the
`
`system. (Id. at ¶¶ 33, 36.) The ’536 Patent mentions protocols such as TCP,
`
`RDMA, and iSCSCI. (Ex. 1002, ’536 Patent, at col. 1, ll. 34–38.) The set of
`
`software modules that enable an application to send and receive data using a
`
`network protocol is often referred to as a “protocol stack.” (Ex. 1001, Jeffay
`
`Decl., ¶ 33.)
`
`The ’536 Patent system provides protocol processing functionality in
`
`both the user-level transport library and the operating system kernel. (Ex. 1002,
`
`’536 Patent at col. 9, ll. 29–31.) However, the user-level transport library can
`
`bypass the kernel when interacting with the network interface. (Id. at col. 6, ll.
`
`12–16.)
`
`Providing protocol processing in both the kernel and at the user-level is
`
`contrasted with conventional systems in which a user level process that “desires
`
`to communicate” with the network “can do so only through calls to the
`
`operating system.” (Id. at col. 3, ll. 4–6.) For example, in conventional prior
`
`art systems, an application “wishing to transmit data” using the TCP/IP protocol
`
`may issue a “send() call” that invokes “kernel routines to copy the data into a
`
`kernel data buffer and perform TCP send processing.” (Id. at col. 3, ll. 8–13.)
`
`
`
`6
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. 8,612,536
`
`
`A preferred embodiment for the ’536 Patent is illustrated in Figure 5
`
`below, annotated to identify the network interface card (“NIC”) (yellow), an
`
`application, (purple), non-operating system functionality (i.e., a user-level
`
`protocol stack) (green), and an operating system (blue):
`
`
`
`(Id. at Fig. 5 (annotated).)
`
`The ’536 Patent alleges that an advantage is gained by implementing
`
`network functionality at the user level rather than in the operating system. In
`
`particular, “network transmit and receive operations” in conventional systems
`
`where protocol processing is limited to the kernel “can involve excessive
`
`context switching.” (Id. at col. 3, ll. 28–30.) This is because each time an
`
`application calls the kernel, control of the processor must be handed over from
`
`the running application to the kernel. (See id. at col. 3, ll. 8–26; Ex. 1001,
`
`
`
`7
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. 8,612,536
`
`
`Jeffay Decl., ¶ 40.) User-level network processing allegedly avoids this
`
`“significant overhead” by enabling “data transfers using standard protocols to
`
`be made without requiring data to traverse the kernel stack.” (Ex. 1002, ’536
`
`Patent, col. 3, ll. 28–39.)
`
`The ’536 Patent acknowledges that user level protocol stacks is a
`
`“solution that has been attempted in the past.” (Id. at col. 3, ll. 35–39.) Instead,
`
`the ’536 Patent purports to solve problems with systems that implement user-
`
`level protocol stacks. (Id. at col. 3, ll. 60–61.) In particular, the ’536 Patent
`
`focuses on what happens when an application becomes nonresponsive during a
`
`send or receive operation. (Id. at col. 5, ll. 46–56.) For example, the ’536
`
`Patent states that a traditional kernel implementing the TCP protocol is capable
`
`of delivering “sent, but unacknowledged data and gracefully close a connection
`
`when a sending application exits or crashes.” (Id. at col. 5, ll. 46–49.) But, this
`
`is an “issue for a transport library which will disappear (possibly ungracefully)”
`
`in the same circumstances. (Id. at col. 5, ll. 49–54.)
`
`To resolve this issue, the ’536 Patent proposes two steps. First, the ’536
`
`Patent suggests a mechanism to determine if a transmitting or receiving
`
`application is unresponsive. (Id. at col. 10, ll. 22–27, ll. 42–48.) Second, if the
`
`application is determined to be unresponsive, the operating system is signaled
`
`“to handle the data for the application.” (Id. at col. 10, ll. 27–37.) The
`
`
`
`8
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. 8,612,536
`
`
`operating system handles both transmission (id.) and reception (id. at col. 10, ll.
`
`50–58) in such circumstances.
`
`In order to detect that an application is unresponsive, the system uses a
`
`timer. (Id. at col. 10, ll. 42–45.) For receive operations, a timer is set each time
`
`a packet is received for an application. (Id.) If the timer expires without the
`
`application having retrieved the packet, the application is deemed unresponsive.
`
`(Id. at col. 10, ll. 45–48.) If an application is deemed unresponsive, the NIC
`
`will notify the operating system. (Id. at col. 10, ll. 50–52.) The operating
`
`system will then handle the processing of the received packet instead of the
`
`application. (Id. at col. 10, ll. 50–58.) This can include, for example, protocol
`
`processing and removal of data from a buffer for use. (Id. at col. 10, ll. 52–58.)
`
`Similarly, for transmit operations, a timer is set each time an
`
`acknowledgement or timeout message is received. (Id. at col. 10, ll. 22–25.)
`
`An acknowledgement message is a message from a remote node that tells the
`
`transmitting node that it has received its last transmission. (Ex. 1001, Jeffay
`
`Decl., ¶ 39.) A timeout message, on the other hand, signals to the transmitting
`
`device that an acknowledgement has not been received and that it should
`
`instead retransmit the corresponding data. (Id.) If a transmit timer expires prior
`
`to the transmitting application retrieving the acknowledgement or timeout
`
`message, the application is deemed unresponsive. (Ex. 1002, ’536 Patent, at
`
`
`
`9
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. 8,612,536
`
`
`col. 10, ll. 26–31.) The operating system will then handle the processing of the
`
`received acknowledgement or timeout message instead of the application. (Id.)
`
`Claim 1 pertains to data transmission and recites:
`
`[A] A data processing system for transmitting data,
`
`comprising:
`
`[B] a processor subsystem having access to a memory
`
`and a network interface device capable of supporting
`
`a communication link over a network with another
`
`network interface device;
`
`[C] an application configured to, while executing on
`
`the processor subsystem, form data to be transmitted,
`
`cause it to be written to a data buffer and request a
`
`non-operating-system
`
`functionality of
`
`the data
`
`processing system to send the data to be transmitted
`
`over the network;
`
`[D] a non-operating system functionality configured
`
`to cause the network interface device to access the
`
`data buffer and begin a transmission operation of at
`
`least some of the data over the network; and
`
`[E] an operating system configured
`
`to, while
`
`executing on the processor subsystem and in response
`
`to
`
`the
`
`application being determined
`
`to be
`
`unresponsive, access
`
`the data buffer and
`
`its
`
`corresponding connection state and continue the
`
`
`
`10
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. 8,612,536
`
`
`transmission operation by means of the network
`
`interface device.
`
`(Ex. 1002, ’536 Patent, Claim 1 (bold element letters added).)
`
`Claim 10 is very similar, but instead pertains to data reception:
`
`[A] A data processing system for receiving data
`
`comprising:
`
`[B] an operating system;
`
`[C] an application;
`
`[D]
`
`a non-operating-system
`
`functionality
`
`for
`
`performing receive processing;
`
`[E] a network interface device capable of supporting a
`
`communication link over a network with another
`
`network interface device; and
`
`[F] a processor subsystem having access to a memory
`
`and the network interface device; wherein:
`
`[G] the network interface device is configured to
`
`write data received over a receive channel for the
`
`application to a data buffer associated with that
`
`receive channel;
`
`[H] the application is configured to, while executing
`
`on the processor subsystem, read received data from
`
`the data buffer in a data reception operation by means
`
`of the non-operating-system functionality; and
`
`
`
`11
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. 8,612,536
`
`
`[I] the operating system is configured to, while
`
`executing on the processor subsystem and in response
`
`to
`
`the
`
`application being determined
`
`to be
`
`unresponsive, access
`
`the data buffer and
`
`its
`
`corresponding connection state and continue the data
`
`reception operation.
`
`(Ex. 1002, ’536 Patent, Claim 10 (bold element letters added).)
`
`Both the alleged problem and the purported solution claimed by the ’536
`
`Patent are disclosed by the prior art. (Ex. 1001, Jeffay Decl., ¶¶ 85, 117.)
`
`VII.
`
`CLAIM CONSTRUCTION
`
`Petitioner submits, for purposes of this IPR only, that the plain and
`
`ordinary meaning be applied to all claim terms. In addition, several claims in
`
`the ’536 Patent recite the word “means.” Petitioner further submits, for
`
`purposes of this IPR only, that these terms should not be construed under 35
`
`U.S.C. § 112, ¶ 6 as means-plus-function terms. In particular, Claims 1, 2, and
`
`10 use the phrase “by means of”:
`
` “continue the transmission by means of the network interface
`
`device” (Claim 1);
`
` “access the data buffer by means of communication between the
`
`non-operating-system functionality and the network interface
`
`device that bypasses the operating system” (Claim 2);
`
`
`
`12
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. 8,612,536
`
`
` “read received data from the data buffer in a data reception
`
`operation by means of the non-operating-system functionality.”
`
`(Claim 10).
`
`It is presumed that a claim term invokes § 112, ¶ 6 when it “uses the
`
`word ‘means’ as a noun in the claim: ‘means’ for doing something.” The
`
`Federal Circuit, however, has specifically rejected applying
`
`the same
`
`presumption for the phrase “by means of.” Robert Bosch, LLC v. Snap-On Inc.,
`
`769 F.3d 1094, 1098–1099 (Fed. Cir. 2014). Therefore, the phrase “by means
`
`of” in the Claims of the ’536 Patent do not automatically invoke § 112, ¶ 6.
`
`In determining whether a limitation is a means-plus-function, the
`
`question is “whether the words of the claim are understood by persons of
`
`ordinary skill in the art to have a sufficiently definite meaning as the name for
`
`structure.” Williamson v. Citrix Online, LLC, 792 F.3d 1339, 1349 (Fed. Cir.
`
`2015). In other words, the question is whether the term “recite[s] sufficiently
`
`definite structure”—which does not invoke means-plus-function—or instead
`
`recites “function without reciting sufficient structure for performing that
`
`function.” (Id.) Here, the limitations at issue recite both functions and
`
`structures for performing those functions.
`
`With respect to Claim 1, the function of continuing transmission is
`
`performed using the “network interface device” (e.g., a network interface card),
`
`
`
`13
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. 8,612,536
`
`
`a defined structure. With respect to Claim 2, the function of accessing the data
`
`buffer is performed using “communication between the non-operating system
`
`functionality and the network interface device that bypasses the operating
`
`system” (e.g., the direct data path that exists between the non-operating system
`
`functionality and the network interface device), a defined structure. With
`
`respect to Claim 10, the function of receiving data from the buffer in a data
`
`reception operation is performed using the “non-operating system functionality”
`
`(e.g., the titular user-level stack), a defined structure.
`
`For the above reasons, the terms reciting the phrase “by means of” in the
`
`claims of the ’536 Patent do not invoke § 112, ¶ 6, and therefore should not be
`
`construed as mean-plus-function terms.
`
`VIII.
`
`REASONABLE LIKELIHOOD THAT CLAIMS 1–17 ARE
`UNPATENTABLE
`
`Below is a detailed discussion of why Claims 1–17 are unpatentable.
`
`A. GROUND 1: Claims 1–3, 5–6, 10–11, and 13–14 are obvious in
`view of the combination of Druschel & Andjelic
`
`1.
`
`Background of Druschel
`
`Druschel aims to solve issues of “OS software latencies” which “can easily
`
`dominate the end-to-end communication delays experienced by applications” over
`
`a network. (Ex. 1003, Druschel, at 10.) For example, “communication-intensive”
`
`applications can “suffer from added communication latencies caused by the lack of
`
`direct access to the network hardware.” (Id.)
`
`
`
`14
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. 8,612,536
`
`
`To that end, Druschel discloses a system that “allows applications to bypass
`
`the operating system kernel during network send and receive operations.” (Id.) In
`
`order to accomplish this, Druschel teaches, like the ’536 Patent, first implementing
`
`a user-level protocol stack:
`
`[I]nstead of centralizing the network communication
`
`software inside the operating system, a copy of this
`
`software is placed into each user domain as part of the
`
`standard library that is linked with application programs.
`
`This user-level network software supports the standard
`
`application programming interface. . . [T]he user-level
`
`network software is granted direct access to a
`
`restricted set of functions provided by the network
`
`adaptor. This set of functions is sufficient to support
`
`common network send and receive operations without
`
`involving the OS kernel. As a result, the OS kernel is
`
`removed from the critical network send/receive path.
`
`(Id. (emphasis added).)
`
`
`
`Second, in order to facilitate communication between the user-level and the
`
`network interface, Druschel discloses:
`
`An application process communicates with the network
`
`adaptor through an application device channel, which
`
`consists of a set of data structures that is shared between
`
`network adaptor and the user-level network software.
`
`
`
`15
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. 8,612,536
`
`
`These data structures include queues of buffer descriptors
`
`for the transmission and reception of network messages.
`
`(Id. (emphasis added).)
`
`The arrangement of the system, with an application, a user-level network
`
`software (“protocol library”), and an application device channel (“ADC”), all of
`
`which facilitate bypassing the operating system (“OS”), is depicted in Figure 3:
`
`(Id. at Fig. 3 (protocol library coloring added to indicate non-operating system
`
`
`
`functionality).)
`
`Druschel further discloses
`
`that
`
`the user-level networking software
`
`implements TCP/IP protocols, but that “[a] complete implementation of the
`
`network software remains in the kernel.” (Id. at 11.) This arrangement is depicted
`
`in Figure 3, above, which shows that “Network Protocols” remain in the OS.
`
`While the “OS is normally only involved in the establishment and termination of
`
`network connections” (id. at 10), “[t]he in-kernel [network] software handles
`
`exceptional cases and tasks that require centralized control,” (id. at 11).
`
`
`
`16
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. 8,612,536
`
`
`2.
`
`Background of Andjelic
`
`Andjelic, like Druschel and the ’536 Patent, discloses a data processing
`
`system implementing network software at the user-level. In particular, Andjelic is
`
`directed to systems that include “network device drivers that support NIC access
`
`directly from user space, avoiding message copying between user space and kernel
`
`space.” (Ex. 1004, Andjelic, at col. 2, ll. 9–12.) Andjelic explains that a problem
`
`with such systems in the prior art is that they require “special. . . NIC controllers.”
`
`(Id. at col. 2, ll. 45–48.) They require multiple NICs—a specialized one for user-
`
`level access, and an ordinary NIC for kernel-level access. (Id. at col. 2, ll. 48–52.)
`
`To address this issue, Andjelic discloses a “network device driver
`
`architecture” that includes both “kernel-space access and user-space access to the
`
`NIC, preferably over the same NIC port.” (Id. at col. 2. ll. 11–14.) The driver
`
`comprises both “kernel-space device driver” as well as a “user-space device driver
`
`functionality.” (Id. at col. 3, ll. 19–21.) This architecture is depicted in Figure 1:
`
`
`
`17
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. 8,612,536
`
`
`
`
`(Id. at Fig. 1 (colors added).)
`
`The user-space device driver functionality “is adapted for enabling direct
`
`access between user space and said NIC via a user-space-NIC interface.” (Id. at
`
`col. 3, ll. 24–26.) It also provides access between the kernel-space device driver
`
`and the NIC. (Id. at col. 3, ll. 26–30.)
`
`The kernel-space device driver has two modes of accessing the NIC:
`
`In the first mode, the kernel-space device driver is
`
`operable for directly accessing the NIC via a kernel-
`
`space-NIC interface. In the second mode, also referred to
`
`as user-space tunneled access mode, the kernel-space
`
`device driver is operable for accessing the NIC via the
`
`user-space device driver functionality.
`
`
`
`18
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. 8,612,536
`
`
`(Id. at col. 3, ll. 34–39.) However, because the kernel-space device driver is reliant
`
`on the user-space device driver functionality when in the “tunneled access mode,”
`
`an issue can arise if the user application associated with the user-space device
`
`driver crashes. (Id. at col. 3, ll. 43–46.) To that end, the kernel-space driver must
`
`be able to detect an unresponsive application and alter its behavior. To accomplish
`
`this, Andjelic teaches that the kernel-space device driver is “provided with a
`
`watchdog that switches back to the first operational mode [(with direct access to
`
`the NIC rather than access through the user-space device driver)] if there has been
`
`no call from the user-space device driver functionality for a predetermined period
`
`of time.” (Id. at col. 3, ll. 46–51.)
`
`3.
`
`Claim 1 is obvious
`
`(a) Preamble: Druschel discloses [A] “[a] data processing
`system for transmitting data”
`
`Druschel discloses: “data processing system for
`
`transmitting data”
`
`(Druschel’s workstation).
`
`Druschel
`
`teaches
`
`implementing an operating system for high-speed
`
`communication that is run on, for example, a “DEC 3000/600” workstation. (Ex.
`
`1003, Druschel, at 4, 13; Ex. 1001, Jeffay Decl., ¶ 74.).
`
`
`
`19
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. 8,612,536
`
`
`(b) Druschel discloses [B] the data processing system
`comprising “a processor subsystem having access to a
`memory and a network interface device capable of
`supporting a communication link over a network with
`another network interface device”
`
`Druschel discloses: “a processor subsystem” (Druschel’s CPU) “having
`
`access to a memory” (Druschel’s CPU having access to main memory) “and a
`
`network interface device capable of supporting a communication link over a
`
`network with another network interface device” (Druschel’s CPU having access to
`
`a network adaptor).
`
`
`
`Druschel teaches that the operating system making use of “OS facilit[ies],”
`
`(Ex. 1003, Druschel, at 5), is aimed at improving the speed of operation for
`
`systems employing a “central processing unit (CPU)” interacting with “main
`
`memory.” (Id. at 4–5; Ex. 1001, Jeffay Decl., ¶ 76.)
`
`
`
`Druschel discloses that the CPU has access to “network adaptor” (also
`
`referred to as a “network interface” or “NI”). (Ex. 1003, Druschel, at 10, 12; Ex.
`
`1001, Jeffay Decl., ¶ 77.) For example, Druschel teaches use of an “OSIRIS ATM
`
`network adaptor.” (Ex. 1003, Druschel, at 12.) The network adaptor supports a
`
`communication link over a network, such as between two workstations, each with
`
`an OSIRIS board, “linked back-to-back.” (Id. at 13.)
`
`
`
`20
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. 8,612,536
`
`
`(c) Druschel discloses [C] “an application configured to,
`while executing on the processor subsystem, form
`data to be transmitted, cause it to be written to a data
`buffer and request a non-operating-system
`functionality of the data processing system to send the
`data to be transmitted over the network”
`
`Druschel discloses: “an application” (Druschel’s application) “configured to,
`
`while executing on the processor subsystem, form data to be transmitted”
`
`(Druschel’s application that forms a data stream), “cause it to be written to a data
`
`buffer” (Druschel’s application stores data into a buffer) “and request a non-
`
`operating-system functionality of the data processing system” (Druschel’s protocol
`
`library) “to send the data to be transmitted over the network” (Druschel’s protocol
`
`library that sends data to be transmitted over the network).
`
`Druschel discloses a system
`
`that supports “data streams between
`
`applications.” (Id. at 4; Ex. 1001, Jeffay Decl., ¶ 79.) Such applications “generate
`
`output data.” (Ex. 1003, Druschel, at 8; Ex. 1001, Jeffay Decl., ¶ 79.)
`
`Applications communicate with a “with the network adaptor through an
`
`application device channel.” (Ex. 1003, Druschel, at 10.) The ADCs “include
`
`queues of buffer descriptors for the transmission and reception of network
`
`messages.” (Id.) In other words, the ADCs contain