Paper No. 7
`Trials@uspto.gov
`Entered: March 2, 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-01908
`Patent 8,612,536 B2
`____________
`
`
`
`Before SALLY C. MEDLEY, DAVID C. MCKONE, and
`CHRISTA P. ZADO, Administrative Patent Judges.
`
`MCKONE, Administrative Patent Judge.
`
`
`
`DECISION
`Denying Institution of Inter Partes Review
`37 C.F.R. § 42.108
`
`
`
`
`Trials@uspto.gov
`Entered: March 2, 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-01908
`Patent 8,612,536 B2
`____________
`
`
`
`Before SALLY C. MEDLEY, DAVID C. MCKONE, and
`CHRISTA P. ZADO, Administrative Patent Judges.
`
`MCKONE, Administrative Patent Judge.
`
`
`
`DECISION
`Denying Institution of Inter Partes Review
`37 C.F.R. § 42.108
`
`
`
`
`
`IPR2016-01908
`Patent 8,612,536 B2
`
`
`I. INTRODUCTION
`
`A. Background
`Exablaze Pty. Ltd. (“Petitioner”) filed a Petition (Paper 1, “Pet.”) to
`institute an inter partes review of claims 1–17 of U.S. Patent No.
`8,612,536 B2 (Ex. 1001, “the ’536 patent”). Solarflare Communications,
`Inc. (“Patent Owner”) filed a Preliminary Response (Paper 6, “Prelim.
`Resp.”). Upon consideration of the Petition and Preliminary Response, we
`conclude, under 35 U.S.C. § 314(a), that Petitioner has not established a
`reasonable likelihood that it would prevail with respect to any of the
`challenged claims. Accordingly, we decline to institute an inter partes
`review of claims 1–17 of the ’536 patent.
`
`B. Related Matter
`The parties indicate that the ’536 patent has been asserted in
`Solarflare Communications v. Exablaze Pty. Ltd., Case No. 16-cv-01891
`(D. N.J.). Pet. 1; Paper 4, 1.
`
`C. Evidence Relied Upon
`Petitioner relies on the following prior art:
`Peter Druschel, Operating System Support for High-Speed
`Communication, VOL. 39, NO. 9 COMM. OF THE ACM 41–51 (Sept. 1996)
`(Ex. 1003, “Druschel”);
`U.S. Patent No. 7,451,456 B2, issued Nov. 11, 2008, filed June 19,
`2002 (Ex. 1004, “Andjelic”);
`U.S. Patent No. 6,594,787 B1, issued July 15, 2003, filed Sept. 17,
`1999 (Ex. 1005, “Chesson”);
`
`2
`
`
`
`IPR2016-01908
`Patent 8,612,536 B2
`
`
`Aled Edwards & Steve Muir, Experiences implementing a high
`performance TCP in user-space, PROCEEDINGS OF ACM SIGCOMM’95
`196–205 (Aug. 28–Sept. 1, 1995) (Ex. 1006, “Edwards”);
`Olivier Maquelin et al., Polling Watchdog: Combining Polling and
`Interrupts for Efficient Message Handling, ISCA ’23 PROCEEDINGS, VOL. 24,
`NO. 2 COMPUTER ARCHITECTURE NEWS 179–88 (May 22–24, 1996)
`(Ex. 1007, “Maquelin”).
`
`Petitioner also relies on the Declaration of Kevin Jeffay, Ph.D.
`(Ex. 1001, “Jeffay Decl.”).
`
`
`D. The Asserted Grounds
`Petitioner asserts the following grounds of unpatentability (Pet. 4):
`Reference(s)
`Basis
`Claims Challenged
`1–3, 5, 6, 10, 11, 13,
`and 14
`
`§ 103(a)
`
`Druschel and Andjelic
`
`Druschel, Andjelic, and Chesson
`
`§ 103(a)
`
`4 and 7–9
`
`§ 103(a)
`
`12 and 15–17
`
`Druschel, Andjelic, and Maquelin
`
`E. The ’536 Patent
`The ’536 patent describes methods of transmitting and receiving data
`in a data processing system. Ex. 1002, Abstract. The ’536 patent describes
`techniques in the context of the system depicted in Figure 1, reproduced
`below:
`
`3
`
`
`
`IPR2016-01908
`Patent 8,612,536 B2
`
`
`
`
`Figure 1 is a schematic diagram of a system with a network interface device
`in use. Id. at 8:60–61. Network interface device (NIC) 10 is connected via
`data link 5 to processing device (computer) 1 and connected via data link 14
`to data network 20. Id. at 1:18–21. Network device 30 and processing
`device 40 also are connected to network 20. Id. at 1:21–24. Computer 1
`includes a processor subsystem with processor 2 and a memory subsystem
`with memory 3. Id. at 1:44–48.
`According to the ’536 patent, conventionally, only the operating
`system (OS) of computer 1 (in particular, the kernel) could access the
`peripheral devices (including NIC 10) directly, with user level processes,
`such as application programs, required to access NIC 10 by calling routines
`in the operating system. Id. at 2:5–9, 2:14–15, 3:4–6. This was problematic
`in that “network transmit and receive operations can involve excessive
`context switching, and this can cause significant overhead.” Id. at 3:28–30.
`The ’536 patent describes a prior art solution to that concern, involving “the
`creation of user level protocol processing stacks operating in parallel with
`those of the operating system,” in which “[s]uch stacks can enable data
`transfers using standard protocols to be made without requiring data to
`traverse the kernel stack.” Id. at 3:36–39. The ’536 patent, however,
`
`4
`
`
`
`IPR2016-01908
`Patent 8,612,536 B2
`
`describes several problems with this approach, including the inability to
`continue some of the communications of the application if the application
`exits or crashes:
`It is common for transport protocols to mandate that a network
`connection outlives the application to which it is tethered. For
`example using the TCP protocol, the transport must endeavour
`to deliver sent, but unacknowledged data and gracefully close a
`connection when a sending application exits or crashes. This is
`not a problem with a kernel stack implementation that is able to
`provide the “timer” input to the protocol stack no matter what the
`state (or existence) of the application, but is an issue for a
`transport library which will disappear (possibly ungracefully) if
`the application exits, crashes, or stopped in a debugger.
`Id. at 5:44–54.
`The ’536 patent purports to solve these problems with an architecture
`in which an application bypasses the operating system to communicate with
`the NIC for a transmission operation. The operating system, however, is
`responsive to a failure message directed to the application when the
`application is no longer in communication with the NIC and the operating
`system performs a portion of the transmission operation in response to the
`failure message. Id. at 6:14–16, 6:53–57. Figure 5, reproduced below,
`illustrates an example of a transmission control protocol (TCP) transport
`architecture for providing an interface between NIC 10 and computer 1
`(id. at 9:21–24):
`
`5
`
`
`
`IPR2016-01908
`Patent 8,612,536 B2
`
`
`
`
`Figure 5 is a diagram of a TCP transport architecture. Id. at 9:1.
`In Figure 5, TCP code that performs protocol processing on behalf of
`a network connection is located both in a transport library (“TCP code”) at
`the TCP-U level and in the OS kernel at the OS level. Id. at 9:29–32. Data
`buffers, owned by the OS, are allocated in memory for use in cooperation
`with the NIC for the transmission and/or reception of data over the network.
`Id. at 9:54–57, 10:1–4. To transmit data, the application writes data to the
`
`6
`
`
`
`IPR2016-01908
`Patent 8,612,536 B2
`
`data buffers and triggers the NIC to read from the buffers to transmit the
`data. Id. at 10:9–12. If the data are not transmitted correctly, the application
`normally receives acknowledgements and retransmission requests and
`causes the NIC to retransmit the data. Id. at 10:16–21. The NIC includes a
`timer that determines how long the NIC will wait for such instructions.
`Id. at 10:22–27. If the application does not respond in that time, the NIC
`knows that the application is unresponsive and alerts the operating system,
`e.g., with an interrupt. Id. at 10:26–30. The OS, which has access to the
`data buffers, can then complete the data re-transmission while the
`application is unresponsive (e.g., the application is busy, descheduled, or
`intentionally ignoring the requests). Id. at 10:30–37.
`Claims 1 and 10 are the only independent claims. Claim 1 recites a
`method for transmitting data, whereas claim 10 is similar and recites a
`method for receiving data. Claims 1 and 10 are reproduced below:
`1.
`A data processing system for transmitting data,
`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;
`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;
`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
`
`7
`
`
`
`IPR2016-01908
`Patent 8,612,536 B2
`
`
`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 transmission
`operation by means of the network interface device.
`
`
`10. A data processing system for receiving data
`comprising:
`an operating system;
`an application;
`a non-operating-system functionality for performing
`receive processing;
`a network interface device capable of supporting a
`communication link over a network with another
`network interface device; and
`a processor subsystem having access to a memory and the
`network interface device;
`wherein:
`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;
`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
`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.
`
`
`
`8
`
`
`
`IPR2016-01908
`Patent 8,612,536 B2
`
`
`II. ANALYSIS
`Claim Construction
`A.
`We interpret claims of an unexpired patent using the broadest
`reasonable construction in light of the specification of the patent in which
`they appear. See 37 C.F.R. § 42.100(b); Cuozzo Speed Techs., LLC v. Lee,
`136 S. Ct. 2131, 2144–45 (2016). In applying a broadest reasonable
`construction, claim terms generally are given their ordinary and customary
`meaning, as would be understood by one of ordinary skill in the art in the
`context of the entire disclosure. See In re Translogic Tech., Inc., 504 F.3d
`1249, 1257 (Fed. Cir. 2007).
`As Petitioner points out (Pet. 12–13), claims 1, 2, and 10 include
`recitations of “means”:
`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 transmission operation by means of the network
`interface device (claim 1);
`wherein the non-operating-system functionality is configured to
`cause the network interface device to 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);
`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 (claim 10).
`Petitioner argues that each of these limitations recites sufficient structure for
`performing any recited function and, thus, these limitations should not be
`
`9
`
`
`
`IPR2016-01908
`Patent 8,612,536 B2
`
`treated as means-plus-function limitations under 35 U.S.C. § 112 ¶ 6.
`Pet. 13–14. Patent Owner does not take a position on these limitations.
`We agree with Petitioner. The standard for determining whether a
`claim should be treated under Section 112 ¶ 6 “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 each instance
`noted above, the claim recites specific structure for performing its function.
`For example, in claim 1, a “transmission operation” is performed by “the
`network interface device.” The recitation “by means of” simply acts as an
`introduction or identification of the structure rather than as a substitute for
`structure. Cf. Robert Bosch, LLC v. Snap-On Inc., 769 F.3d 1094, 1098–99
`(Fed. Cir. 2014) (“We are unaware of any precedent stating that the
`presumption [that Section 112 ¶ 6 applies to a claim reciting the word
`‘means’] is triggered by a claim’s use of the expression ‘by means of.’ In
`the past we have applied the presumption when a claim uses the word
`‘means’ as a noun in the claim: a ‘means’ for doing something. We have
`not done so for the phrase ‘by means of.’”). Accordingly, Section 112 ¶ 6 is
`not applicable to claims 1, 2, and 10.
`The parties do not identify any additional terms for construction. On
`the current record, we do not find it necessary to construe additional terms
`for purposes of this Decision.
`
`B. Asserted Grounds of Unpatentability
`A claim is unpatentable under 35 U.S.C. § 103(a) if the differences
`between the claimed subject matter and the prior art are “such that the
`
`10
`
`
`
`IPR2016-01908
`Patent 8,612,536 B2
`
`subject matter as a whole would have been obvious at the time the invention
`was made to a person having ordinary skill in the art to which said subject
`matter pertains.” We resolve the question of obviousness on the basis of
`underlying factual determinations, including: (1) the scope and content of
`the prior art; (2) any differences between the claimed subject matter and the
`prior art; (3) the level of skill in the art; and (4) objective evidence of
`nonobviousness, i.e., secondary considerations.1 See Graham v. John Deere
`Co., 383 U.S. 1, 17–18 (1966).
`In an obviousness analysis, some reason must be shown as to why a
`person of ordinary skill would have combined or modified the prior art to
`achieve the patented invention. See Innogenetics, N.V. v. Abbott Labs., 512
`F.3d 1363, 1374 (Fed. Cir. 2008). A reason to combine or modify the prior
`art may be found explicitly or implicitly in market forces; design incentives;
`the “interrelated teachings of multiple patents”; “any need or problem
`known in the field of endeavor at the time of invention and addressed by the
`patent”; and the background knowledge, creativity, and common sense of
`the person of ordinary skill. Perfect Web Techs., Inc. v. InfoUSA, Inc., 587
`F.3d 1324, 1328–29 (Fed. Cir. 2009) (quoting KSR Int’l Co. v. Teleflex Inc.,
`550 U.S. 398, 418–21 (2007)).
`
`
`1. Level of Ordinary Skill
`Petitioner contends that a person of ordinary skill in the art would
`have had a bachelor’s degree in computer science, computer engineering, or
`electrical engineering, and two to three years of professional experience in
`
`
`1 The current record does not include evidence of secondary considerations.
`
`11
`
`
`
`IPR2016-01908
`Patent 8,612,536 B2
`
`the design of software for network protocol processing, or, alternatively, a
`master’s degree in one of those fields. Pet. 5 (citing Ex. 1001 ¶25). Patent
`Owner does not propose a level of ordinary skill in the art. Petitioner’s
`proposal is consistent with the level of ordinary skill reflected by the prior
`art of record. See Okajima v. Bourdeau, 261 F.3d 1350, 1355 (Fed. Cir.
`2001); In re GPAC Inc., 57 F.3d 1573, 1579 (Fed. Cir. 1995); In re Oelrich,
`579 F.2d 86, 91 (CCPA 1978). For purposes of this Decision, we adopt
`Petitioner’s statement of the level of skill in the art.
`
`
`2. Alleged Obviousness over Druschel and Andjelic
`a. Overview of Druschel
`Druschel is a technical magazine article describing techniques for
`eliminating processing bottlenecks in high-speed networks, including I/O
`bottlenecks in operating systems. Ex. 1003, 41. The parties focus their
`arguments on the embodiment described with respect to Druschel’s Figure 3,
`reproduced below:
`
`12
`
`
`
`IPR2016-01908
`Patent 8,612,536 B2
`
`
`
`
`Figure 3 is a diagram of an application-device channel (ADC) architecture.
`Id. at 47.
`Figure 3 depicts an “approach that gives applications direct access to a
`network device for common I/0 operations, thus bypassing the OS kernel
`and removing protection boundaries from simple application-network data
`paths.” Id. With the use of ADCs, “[t]he OS is normally only involved in
`the establishment and termination of network connections.” Id. The
`“network adapter validates send and receive requests from application
`programs based on information provided by the OS during connection
`establishment.” Id. A copy of the network protocols software, including
`software that supports a standard application programming interface, is
`placed into each user domain as part of the standard library (protocol library)
`
`13
`
`
`
`IPR2016-01908
`Patent 8,612,536 B2
`
`that is linked with application programs. Id. This software is granted direct
`access to a set of functions provided by the network adapter sufficient to
`support common network send and receive operations without involving the
`OS kernel. Id. According to Druschel, “[a]n 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. These data structures
`include queues of buffer descriptors for the transmission and reception of
`network messages.” Id. “The network adaptor passes subsequently arriving
`network messages to the appropriate ADC, and transmits outgoing messages
`queued on an ADC by an application using the appropriate network
`connection.” Id. at 48.
`Druschel also states the following:
`User-level implementations of TCP / IP network software have
`been described in [18, 24]. The general approach is to separate
`and decentralize common-case operations and link the resulting
`code with user applications. A complete implementation of the
`network software remains in the kernel. The in-kernel software
`handles exceptional cases and tasks that require centralized
`control.
`Id. (brackets in original). The parties dispute the import of this passage, as
`explained below.
`
`
`b. Overview of Andjelic
`Andjelic describes techniques for providing both kernel-space access
`and user-space access to an NIC over the same NIC port. Ex. 1004, 3:11–
`14. Figure 3, reproduced below, illustrates an example:
`
`14
`
`
`
`IPR2016-01908
`Patent 8,612,536 B2
`
`
`
`
`Figure 3 is a schematic block diagram of a network device driver
`architecture. Id. at 4:45–47.
`Kernel-space device driver 10 incudes network device driver (NDD)
`core 14 and kernel-space agent 16, which, together with user-space device
`driver functionally 20, define the overall network device driver architecture.
`Id. at 6:54–59. “The interface between the kernel-level protocols 45 such as
`TCP/IP and DLI (Data Link Interface) on one hand and the NDD core 14 on
`the other hand is conveniently an existing network device driver API
`(Application Programming Interface) supplied with the OS.” Id. at 8:1–5.
`As shown in Figure 3, user applications 40 also can communicate directly
`with NIC 30 without going through kernel-space device driver 10:
`
`15
`
`
`
`IPR2016-01908
`Patent 8,612,536 B2
`
`
`The interface between the user application 40 and the user-space
`device driver functionality 20 is normally an API that supports
`sending/receiving messages directly between the user address
`space and the NIC 30, in combination with the FIFO-queue based
`interface 25 between the user-space device driver functionality
`20 and the NIC 30.
`Id. at 8:22–27.
`Andjelic describes kernel-space device driver 10 operating in one of
`two modes. In a first mode, also referred to as default mode, kernel-space
`device driver 10, in particular NDD core 14, is operable to access NIC 30
`directly via kernel-space-NIC interface 35. Id. at 3:34–36, 7:25–26.
`In a second mode, which Andjelic terms a “user-space tunneled access
`mode,” kernel-space driver 10 is operable to access NIC 30 indirectly via
`user-space device driver functionality 20. Id. at 3:36–39, 7:27–29.
`According to Andjelic:
`User-space messages are exchanged between user space and NIC
`without kernel involvement, and since the user-space device
`driver functionality typically works in polling mode, there will
`be no per message interrupts. Messages originating from kernel-
`level users are tunneled between the NDD core 14 and the NIC
`30, via the kernel agent 16, the user-space device driver
`functionality 20 and the associated interfaces 15, 25.
`Id. at 6:60–67.
`When in the user-space tunneled access mode, and the user
`application crashes, the OS orders kernel-space device driver 10 to switch
`back to the first mode. Id. at 3:43–46. Andjelic states: “The kernel agent 16
`may also be adapted for monitoring the status of any process using the user-
`space device driver functionality 20. This makes it possible for the kernel
`agent to order the NDD core 14 to switch back to default mode in the case of
`a user process failure.” Id. at 7:52–56. According to Andjelic, “[a]s a
`
`16
`
`
`
`IPR2016-01908
`Patent 8,612,536 B2
`
`second line of defense, or as an alternative, the kernel-space device driver
`may optionally be provided with a watchdog that switches back to the first
`operational mode if there has been no call from the user-space device driver
`functionality for a predetermined period of time.” Id. at 3:46–51.
`
`
`c. Claims 1–3, 5, 6, 10, 11, 13, and 14
`Petitioner contends that claim 1 would have been obvious over
`Druschel and Andjelic. Petitioner cites Druschel for the majority of
`claim 1’s limitations, while contending that a skilled artisan would have
`combined the teachings of Druschel and Andjelic for the last limitation.
`Pet. 19–29.
`Specifically, Petitioner argues that Druschel describes a CPU having
`access to a main memory and a network interface and that this corresponds
`to “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,” as recited in claim 1. Id. at 20.
`Referring to Druschel’s Figure 3, Petitioner contends that Druschel’s
`description of the “Application” storing data in a buffer and using the
`“Protocol Library” to communicate to the “Network Interface,” via an ADC,
`a request to send the data teaches “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,” as recited in claim 1. Id. at 21–23. Petitioner further
`contends that Druschel’s “Protocol Library” is a non-operating system
`functionality supporting network send and receive operations and, thus, in
`
`17
`
`
`
`IPR2016-01908
`Patent 8,612,536 B2
`
`conjunction with the ADC (which includes queues of buffer descriptors for
`transmission and reception of messages), teaches “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,” as recited in claim 1. Id. at 23–24.
`The parties dispute whether the prior art teaches the remaining
`limitation of claim 1, “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 transmission operation by means of the network
`interface device.” Petitioner contends that a combination of Druschel and
`Andjelic teaches this limitation. Id. at 24–29. Petitioner contends that
`Druschel teaches “an operating system configured to, while executing on the
`processor subsystem . . . access the data buffer and its corresponding
`connection state and continue the transmission operation by means of the
`network interface device,” and that the operating system does so in response
`to an exception. Id. at 25–26. Petitioner, however, concedes that Druschel
`does not specify what such an exception would be and, thus, does not
`disclose that the operating system acts “in response to the application being
`determined to be unresponsive,” as recited in claim 1. Id. at 26.
`Nevertheless, Petitioner argues that Andjelic, in its description of
`transitioning from a user-space tunneled access mode to a first mode in
`response to an application crashing, teaches the aspect of claim 1 missing
`from Druschel. Id. at 26–28. Petitioner argues that a skilled artisan would
`have had reasons to modify Druschel in light of Andjelic’s teaching. Id. at
`28–29.
`
`18
`
`
`
`IPR2016-01908
`Patent 8,612,536 B2
`
`
`As to Druschel’s teachings, Petitioner relies primarily on the
`following disclosure:
`User-level implementations of TCP/IP network software have
`been described in [18, 24]. The general approach is to separate
`and decentralize common-case operations and link the resulting
`code with user applications. A complete implementation of the
`network software remains in the kernel. The in-kernel software
`handles exceptional cases and tasks that require centralized
`control.
`Ex. 1003, 48 (brackets in original). Relying on Dr. Jeffay’s testimony,
`Petitioner argues that this disclosure in Druschel teaches a system that
`implements the TCP/IP protocol and, because it implements that protocol,
`would access the data buffer and its corresponding connection state and
`continue the transmission operation when the system encountered an
`exception. Pet. 25–26 (citing Ex. 1001 ¶¶ 39, 88–91).
`Specifically, Petitioner and Dr. Jeffay contend that a system that
`implements the TCP protocol must ensure that data sent by an application
`are received by a receiver even if the sending application terminates, citing
`to Edwards, “which is not part of this combination.” Id. at 26 (citing
`Ex. 1001 ¶ 39; Ex. 1006, 198). Edwards is a technical magazine article
`describing user-space implementations of TCP that outperform kernel TCP
`implementations. Ex. 1006, 196. In a “Design Overview” section, Edwards
`described a “problem we encountered,” namely, “[o]nce TCP has indicated
`to an application that data has been sent, it must ensure that data has been
`received by the receiver, even if the sending application terminates.” Id. at
`198. According to Edwards, “[i]n a kernel implementation, the protocol
`state data is stored in the kernel’s data area so the kernel can continue to
`process the data even after the application has finished.” Edwards noted that
`
`19
`
`
`
`IPR2016-01908
`Patent 8,612,536 B2
`
`in its user-space solution, “[w]e would need to provide some scheme
`whereby an application terminating would not cause all the protocol state
`and unacknowledged data to be lost.” Id.
`Citing to this disclosure in Edwards, Dr. Jeffay testifies that,
`according to one mechanism of TCP:
`When the sender determines that data has been lost it retransmits
`the data determined to be missing. Note, this process requires a
`sender to keep copies of data previously transmitted until the
`sender is satisfied that the data was successfully received. A
`consequence of this requirement is that a TCP implementation
`must be prepared to buffer previously transmitted data and
`continue operation (e.g., waiting for acknowledgements and
`possibly retransmitting data) even after the sending application
`has terminated.
`Ex. 1001 ¶ 39. Further, again relying on the same disclosure in Edwards,
`Dr. Jeffay concludes that “when Druschel’s in-kernel network takes over in
`an ‘exceptional case,’ for TCP connections, it will ‘access the data buffer
`and its corresponding connection state and continue the transmission
`operation by means of the network interface device’ as required by the
`claims.” Id. ¶ 91 (relying on id. ¶ 90, which refers back to ¶¶ 38, 39, and 43,
`which cite to Ex. 1006, 8).
`Patent Owner argues that none of Druschel, Andjelic, and Edwards
`describes an OS configured to access “a data buffer and its corresponding
`connection state” to “continue the transmission operation” for an application
`if the application is determined to be unresponsive. Prelim. Resp. 56–57,
`58–59.
`As to Druschel, Patent Owner argues that “Druschel nowhere teaches
`that the OS is configured to handle an exceptional case by accessing a data
`buffer and its corresponding connection state to continue a networking
`
`20
`
`
`
`IPR2016-01908
`Patent 8,612,536 B2
`
`operation begun by non-OS functionality for an application.” Id. at 60. We
`agree with Patent Owner. Druschel simply states that “[t]he in-kernel
`software handles exceptional cases and tasks that require centralized
`control.” Ex. 1003, 48. Druschel does not explain when or how the in-
`kernel software handles an exceptional case, and specifically does not
`mention the kernel accessing a data buffer or connection state or continuing
`a network connection for an application.
`Petitioner admits that “Druschel does not explicitly identify specific
`exceptional cases.” Pet. 26. Nevertheless, Petitioner contends, citing to
`Edwards and Dr. Jeffay, that a skilled artisan would have understood
`Druschel to describe an unspecified error condition, to which Druschel’s
`kernel takes over by accessing the data buffer for an application’s
`communication and corresponding connection state and continuing the
`application’s transmission operation. Id. (citing Ex. 1001 ¶¶ 90–91).
`Dr. Jeffay, for his part, merely repeats Petitioner’s argument that, because
`Edwards states that, under TCP, network software must ensure that data is
`transmitted even after a sending application terminates, Druschel must be
`describing a response to an error condition. Ex. 1001 ¶¶ 39, 90–91.
`Patent Owner responds by attacking Petitioner’s underlying bases for
`consulting Edwards in understanding Druschel. For example, Patent Owner
`argues that Druschel’s statement that “[t]he in-kernel software handles
`exceptional cases and tasks that require centralized control” does not refer to
`system behavior in the case of an error or crash of an application. Id. at 50.
`Rather, Patent Owner argues, Druschel draws a distinction between common
`cases, handled by an ADC, and more complex operations that must be
`handled by the kernel. Id. at 50–53. According to Patent Owner,
`
`21
`
`
`
`IPR2016-01908
`Patent 8,612,536 B2
`
`“[t]ermination of an application is not an uncommon or exceptional case—it
`happens routinely.” Id. at 62. Patent Owner (id. at 51) is correct that
`Druschel purports to describe a solution “that gives applications direct
`access to a network device for common I/O operations, thus bypassing the
`OS kernel and removing protection boundaries from simple application-
`network data paths” and that the protocol library to which the application is
`given access includes only “a restricted set of functions provided by the
`network adaptor” that are “sufficient to support common network send and
`receive operations without involving the OS kernel.” Ex. 1003, 47.
`Although an “exception” in the context of software can, in some cases, refer
`to an error condition, the evidence in Druschel cited by Patent Owner
`supports the argument that Druschel’s exceptional case is a more complex
`case rather than an error condition.
`Patent Owner also takes issue with Petitioner’s argument that
`Druschel’s Figure 3 refers to a system for communicating using TCP.
`Prelim. Resp. 63–65. As noted above, Petitioner and its expert consult
`Edwards for background on TCP and contend that it is relevant in light of
`Druschel’s description of a system that employs TCP communications.
`Pet. 26; Ex. 1001 ¶¶ 90–91. Petitioner’s basis for contending that Figure 3
`depicts a system that communicates using TCP appears to be Druschel’s
`statement that “[u]ser-level implementations of TCP/IP network software
`have been described in [18, 24]” (Ex 1003, 48 (brackets in original)).
`Pet. 16, 25, 37; Ex. 1001 ¶¶ 90–91.
`In response, Patent Owner argues that this statement in Druschel
`describes the work of others, and not Druschel’s implementation. Prelim.
`Resp. 64. Patent Owner points to other description in Druschel, stating that
`
`22
`
`
`
`IPR2016-01908
`Patent 8,612,536 B2
`
`“a parallel programming system implemented on a workstation cluster can
`
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
