Paper No. _____
`
`
`
`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
`____________
`
`
`
`PATENT OWNER’S PRELIMINARY RESPONSE
`
`5095028.5
`
`

`
`
`
`I.
`
`TABLE OF CONTENTS
`
`INTRODUCTION ............................................................................................. 1
`
`II. DISCUSSION OF THE ’536 PATENT AND CHALLENGED
`CLAIMS ..........................................................................................................11
`
`A. Technology Overview ...............................................................................11
`
`1. OS Kernel networking functionality. ..................................................11
`
`2. User-level networking functionality. ..................................................13
`
`3. Network Protocols Impose Timing Requirements. .............................13
`
`4. Inventors’ Recognition of Time-Related Problems with Prior
`Attempts at User-Level Networking. ..................................................14
`
`5. The ’536 Patent’s Solution. .................................................................15
`
`B. Independent Claim 1 ..................................................................................19
`
`C. Independent Claim 10 ................................................................................20
`
`III. THE PETITION SHOULD BE DENIED BECAUSE IT FAILS TO
`DEMONSTRATE A REASONABLE LIKELIHOOD OF
`PREVAILING AS TO ANY CHALLENGED CLAIM .................................22
`
`A. Overview of Cited References ...................................................................23
`
`1. Druschel ...............................................................................................23
`
`2. Andjelic ...............................................................................................26
`
`3. Edwards ...............................................................................................34
`
`B. Overview of Grounds 1-3 and their Deficiencies. .....................................35
`
`C. There is No Reason Why A POSA Would Have Modified Druschel
`Based On Andjelic. ....................................................................................37
`
`1. Druschel and Andjelic Describe Alternative Solutions, and
`Andjelic’s “Watchdog Mechanism” is Linked to its Particular
`Solution. ..............................................................................................37
`
`2. The Petition Provides No Supportable Reason For Combining
`Druschel and Andjelic in the Manner Proposed by Petitioner. ...........45
`
`a. References Being In The Same Field and Capable of
`Being Combined Is Legally Insufficient. .................................... 45
`
`
`
`i
`
`

`
`
`
`b. The Sole Technical Rationale Advanced In The Petition Is
`Unsupported By the References. ................................................. 46
`
` Druschel does not have “the problem” fixed by i.
`
`
`Andjelic. .............................................................................. 47
`
` Druschel already “ensure[s] that protocol processing ii.
`
`
`can survive an application becoming unresponsive.” ......... 48
`
` Druschel does not cease to rely on user-level iii.
`
`
`networking in exceptional cases. ........................................ 49
`
` The Petition Cites Expert Testimony That Fails To
`iv.
`Support The Rationale Offered in the Petition for
`Modifying Druschel Based on Andjelic. ............................ 52
`
`3. The Petition’s Failure to Offer a Supportable Rationale for
`Modifying Druschel Based on Andjelic Is Fatal to All Grounds........55
`
`D. Ground 1: The Petition Fails to Demonstrate that the Alleged
`Combination of Druschel and Andjelic Would Have Met All
`Limitations Of Any of the Independent Claims. .......................................55
`
`1. The Petition Fails to State With Specificity How A POSA
`Allegedly Would Have Combined the Teachings of the
`References. ..........................................................................................57
`
`2. The Petition Fails to Demonstrate that All Claim Elements Of
`Either Independent Claim Are Met By The Proposed
`Combination of Druschel and Andjelic. ..............................................58
`
`a. Petitioner’s Assertion That Druschel Discloses an OS
`Configured to Access a Data Buffer and its Corresponding
`Connection State to Continue a Networking Operation
`Begun by a Non-OS Functionality, is Unsupported. .................. 59
`
`b. Edwards Does Not Support Petitioner’s Assertion that
`Druschel Teaches Having the Kernel Continue a User-
`Level Networking Operation ...................................................... 61
`
`3. Conclusion re Missing Limitation. ......................................................69
`
`E. Grounds 2-3 Suffer The Same Deficiencies as Ground 1. ........................69
`
`IV. CONCLUSION ................................................................................................71
`
`
`
`
`
`
`
`ii
`
`

`
`
`
`CASES
`
`TABLE OF AUTHORITIES
`
`
`In re Am. Acad. of Sci. Tech Ctr.,
`367 F.3d 1359 (Fed. Cir. 2004) ............................................................................54
`
`In re Butler,
`1999 WL 164952 (Fed. Cir. Mar. 23, 1999) ........................................................46
`
`Kinetic Concepts v. Smith & Nephew,
`688 F.3d 1342 (Fed. Cir. 2012) ..................................................................... 37, 45
`
`KSR Int’l Co. v. Teleflex Inc.,
`550 U.S. 398 (2007) ...................................................................................... 46, 55
`
`Microsoft Corp. v. Enfish,
`2016 WL 6994254 (Fed. Cir. Nov. 30, 2016) ............................................... 45, 46
`
`PAR Pharm. v. TWi Pharm., Inc.,
`773 F.3d 1186 (Fed. Cir. 2014) ............................................................................68
`
`Seabery N.A. v. Lincoln Global, Inc.,
`IPR2016-00749, Paper 13 (Sept. 21, 2016) .................................................. 54, 64
`
`TRW Automotive US LLC v. Magna Elecs. Inc.,
`IPR2014-00293 and IPR2014-00294, Paper 19 (July 1, 2014) ...........................58
`
`REGULATIONS
`
`37 C.F.R. § 42.65(a) .................................................................................................55
`
`
`
`
`
`
`
`iii
`
`

`
`
`
`APPENDIX LISTING OF EXHIBITS
`
`
`Exhibit Description
`2001 Collins English Dictionary, 540 (HarperCollins, 3rd ed. 1994)
`2002 Andrew S. Tanenbaum, Computer Networks, 61-65 (Prentice Hall PTR,
`4th ed. 2003)
`2003 Radia Perlman, Interconnections, 168-176 and 288-292 (Addison-
`Wesley, 2nd ed. 2000)
`James F. Kurose, Computer Networking, 254-285 and 482-488 (Pearson
`Educ., Inc., 3rd ed. 2005)
`
`2004
`
`
`
`iv
`
`

`
`
`
`I.
`
`INTRODUCTION
`
`Petitioner seeks inter partes review of claims 1-17 of U.S. Patent No.
`
`8,612,536 (“the ’536 patent”) based on three grounds. Ground 1 is based on
`
`alleged obviousness over Druschel (Ex. 1003) and Andjelic (Ex. 1004), the
`
`combination of which is alleged to meet all the limitations of independent claims 1
`
`and 10 and many of the dependent claims. Each of Grounds 2 and 3 challenges
`
`only dependent claims not challenged in Ground 1 by adding another reference to
`
`the Druschel/Andjelic combination.
`
`Petitioner’s assertion that the independent claims would have been obvious
`
`over Druschel and Andjelic is fatally deficient for numerous reasons. Druschel and
`
`Andjelic provide alternative solutions and Andjelic addresses a technical challenge
`
`not present in Druschel; a person having ordinary skill in the art (POSA) at the
`
`time of the invention would have had no reason to combine these references. In
`
`addition, neither Druschel nor Andjelic recognizes the problem solved by the
`
`claims of the ’536 Patent or offers the claimed solution, and any combination of
`
`these references fails to meet all the limitations recited in any of the challenged
`
`claims.
`
`The ’536 Patent describes and claims a data processing system that achieves
`
`performance improvements in networked computer systems in a highly specific
`
`manner. These techniques may be used in commercial environments where
`
`
`
`1
`
`

`
`
`
`maximizing speed is hyper-critical, such as computerized systems for high speed
`
`trading (e.g., of stocks or commodities) where speed in receiving incoming
`
`information, processing that information and sending a communication that
`
`executes a transaction based on the received information can be the difference
`
`between a transaction being consummated or not, which can mean millions of
`
`dollars gained or lost for high speed traders.
`
`Patent Owner Solarflare Communications, Inc. (“Solarflare”) and Petitioner
`
`(“Exablaze”) both sell specialized networking products to institutions that engage
`
`in high speed trading. Solarflare filed suit against Exablaze alleging infringement
`
`of the ’536 Patent and five other Solarflare patents. Exablaze’s Petition was
`
`undoubtedly filed in response to that lawsuit.
`
`The ’536 Patent claims a data processing system for transmitting (claim 1)
`
`or receiving (claim 10) data from a network. Network communications are
`
`typically performed in accordance with one or more network protocols that specify
`
`aspects of how data is to be transmitted from a sender over a network to a receiver.
`
`See, e.g., Ex. 1001, ¶¶33-39. Many network protocols (e.g., TCP/IP) transmit data
`
`in packets that include a payload of data and a header. Id. In some such protocols,
`
`large data transfers are split into smaller packets sent through the network
`
`separately and then put back together in order at the receiver. Packet headers
`
`include information, specified by the network protocol, used in transmitting the
`
`
`
`2
`
`

`
`
`
`payload from the sender through the network to the receiver, and the network
`
`protocol typically specifies actions to be taken by the sender and receiver to ensure
`
`reliable, ordered and error-checked delivery of information over a network. Id.
`
`Typically, the operating systems (“OS”) of the computers that transmit and
`
`receive a packet using network protocols (e.g., TCP/IP) perform networking
`
`operations (including “protocol processing” specified by the network protocol
`
`being used) on the transmitted and received packets. Id., ¶28, ¶40; Ex. 1002, 2:14-
`
`50 and 3:4-26. The networking operations are typically performed by a portion of
`
`the OS referred to as the “kernel.”
`
`Typical protocol processing tasks performed on the transmitting computer
`
`include creating packets by combining payload data with packet headers, checking
`
`to determine whether acknowledgements for sent packets are received and re-
`
`transmitting packets for which no acknowledgment has been timely received. Ex.
`
`1001, ¶¶33-39; Ex. 1002, 4:1-67. Typical protocol processing tasks performed by
`
`the receiving computer include error checking, sending acknowledgements of
`
`received packets, extracting payloads of data from received packets, and
`
`combining in the proper order the payloads of data from multiple related packets.
`
`Ex. 1001, ¶¶33-39; Ex. 1002, 4:1-67.
`
`Having the OS kernel perform protocol processing advantageously
`
`unburdens each application program from having to perform this functionality on
`
`
`
`3
`
`

`
`
`
`its own. Ex. 1001, ¶¶27-29; Ex. 1002, 2:9-13. However, it comes with
`
`disadvantages. One relates to a performance impact due to “context switching” that
`
`results from computer’s processor, which can only execute code for one
`
`application or the OS kernel at a time, having to switch the processor’s context
`
`from the application to the kernel to allow the kernel to perform protocol
`
`processing. Id.; Ex. 1002, 3:4-33. The performance penalty arises in part due to the
`
`time incurred in swapping data and code into and out of the processor’s memory.
`
`Ex. 1001, ¶¶27-29; Ex. 1002, 3:4-33.
`
`The Background of the ’536 Patent explains that this performance hit from
`
`having the OS kernel perform protocol processing was known, and that solutions
`
`had been proposed with “user level” protocol processing stacks within an
`
`application’s context, outside of the OS/kernel, so that protocol processing could
`
`be performed without having to switch the context from the application to the
`
`OS/kernel. Ex. 1001, ¶¶40-44; Ex. 1002, 3:4-67. The user-level protocol
`
`processing stack was provided alongside a protocol processing stack in the
`
`OS/kernel so that protocol processing could either be performed using the user-
`
`level stack without switching the context to the OS/kernel, or in the conventional
`
`manner by having the OS/kernel perform protocol processing. Ex. 1001, ¶¶40-44;
`
`Ex. 1002, 3:4-67.
`
`
`
`4
`
`

`
`
`
`Druschel describes an example of the type of system described in the
`
`Background of the ‘536 Patent. Ex. 1001, ¶44. As shown in Figure 3 (reproduced
`
`below), Druschel discloses a user-level protocol library accessible to the
`
`application so that the application can use the library to perform protocol
`
`processing itself without switching context to the OS/kernel. Ex. 1003
`
`(“Druschel”), 004-0051, 010-012, 011 (“… a copy of this [network protocol]
`
`software is placed into each user domain as part of the standard library …. A
`
`complete implementation of the network software remains in the kernel”); Ex.
`
`1001, ¶¶56-61.
`
`
`
`Druschel, Fig. 3 at 010; Ex. 1001, ¶61. The OS/kernel retains the ability to perform
`
`protocol processing in parallel with the protocol processing performed in the user-
`
`level. Druschel, 010-012; Ex. 1001, ¶44, ¶61 (“the OS maintains an in-kernel
`
`network protocol stack”). To support this parallel network protocol processing,
`
`
`1 Citations to Druschel use the page numbers added and used by Petitioner.
`
`
`
`5
`
`

`
`
`
`Druschel discloses a network interface card (NIC) having two (or more) ports: one
`
`(or more) to receive communications for which the network processing is
`
`performed outside the OS/kernel and another to receive communications for which
`
`the network processing is performed by the OS/kernel. Druschel refers to the NIC
`
`ports as “paths” to the NIC. This Petition uses the same term (“port”) that is used
`
`by Andjelic to describe the NIC ports, which are points of access between the NIC
`
`and the host device through which the OS or a user-level application executing on
`
`the host device communicates with the NIC.2 Because of Druschel’s multiple
`
`ports, one or more applications/processes may access the NIC directly from the
`
`user-level, while other applications/processes access the NIC in parallel using the
`
`traditional path through the OS kernel. Druschel, 012 (“a subset of the processes
`
`can use ADCs, and the remaining processes must use the normal I/O path through
`
`the OS kernel”).
`
`Andjelic provides an alternative to Druschel for user-level networking.
`
`Andjelic’s Background acknowledges the existence of systems like Druschel’s, but
`
`states that they suffered a disadvantage by requiring a NIC with separate ports to
`
`
`2 The NIC ports should not be confused with physical ports (e.g., an Ethernet port)
`
`into which a cable can be plugged or with a TCP port or other component of a
`
`network address.
`
`
`
`
`
`6
`
`

`
`
`
`receive communications that pass through the OS/kernel and those that do not,
`
`because some “off the shelf” NICs do not have such a multi-port capability. Ex.
`
`1004 (“Andjelic”), 2:9-48; Ex. 1001, ¶¶65-66. Andjelic describes techniques
`
`(detailed below) that enable a computer to provide user-level network protocol
`
`processing in parallel with OS-based network protocol processing, for use with a
`
`NIC having only a single port. Andjelic, 3:11-51; Ex. 1001, ¶¶66-68.
`
`The ’536 Patent Background acknowledges user-level networking
`
`techniques like those in Druschel and Andjelic, but notes that prior approaches
`
`“have not addressed a number of the problems required to achieve a complete,
`
`robust, high-performance commercially viable implementation” of protocol
`
`processing outside the OS/kernel. Ex. 1002, 3:64-67. The unaddressed problems
`
`included one arising from the requirement of some typical network protocols that
`
`certain actions be performed within specified time periods—e.g., a sender must
`
`retransmit a packet for which no acknowledgement was timely received, a receiver
`
`must send an acknowledgement of a received packet, etc. Ex. 1002, 3:17-26, 4:61-
`
`67, 10:9-58. When network protocol processing is handled by the OS, the OS has
`
`the ability to grant itself immediate control of the processor (i.e., switch out any
`
`process that may be running and switch the OS code into the processor) to take
`
`action required by a network protocol within its time constraints. Id., 2:61-63. A
`
`user-level protocol processing stack has no ability to immediately grant itself
`
`
`
`7
`
`

`
`
`
`control of the processor if it urgently needs to take action, and must request such
`
`access and must compete for processor time with other user-level functionality. Id.,
`
`1:62-2:13, 2:63-66; Ex. 1001, ¶29.
`
`The’536 Patent inventors appreciated that user-level protocol processing
`
`stacks may therefore sometimes fail to timely fulfill the network protocol
`
`requirements needed to ensure robust reliable network communication. The ’563
`
`Patent explains that while “[i]n some situations [the user-level functionality] alone
`
`may be sufficient to allow the data to be transmitted successfully” and that
`
`“[n]ormally, [networking operations] can be expected to be done by the
`
`application,” problems may arise relating to “acknowledgements, retransmission
`
`requests, etc.” when an application “has been descheduled” by the OS and cannot
`
`access the processor, or is “busy,” or otherwise “unresponsive.” Ex. 1002, 10:9-39,
`
`3:17-26, 4:61-67.
`
`The ‘536 Patent proposes a solution to this problem. Specifically, network
`
`operations (e.g., a transmission or receive operation) may be performed by an
`
`application using non-OS functionality, but the application stores the networking
`
`information in a data buffer accessible by the OS. Id., 9:33-10:8. If the application
`
`becomes temporarily unresponsive for any reason (e.g., because it has been
`
`“descheduled” by the OS and is unable to execute or is “busy” performing other
`
`tasks), the OS steps in, accesses the data buffer and the corresponding connection
`
`
`
`8
`
`

`
`
`
`state, and continues the network operation for the application. Id., 10:22-39, 10:42-
`
`58. In this manner, the benefits of having the application perform user-level
`
`networking are obtained, but the OS can step in to continue a network operation if
`
`and when necessary, until the application is again responsive, to ensure that
`
`network communications are performed in a robust and reliable manner. Id.
`
`All of the challenged claims recite a data processing system with an
`
`application configured to cause data to be written to a data buffer and request a
`
`non-OS functionality to send the data to be transmitted over a network (claims 1-
`
`9), or an application configured to read received data from a data buffer by means
`
`of a non-OS functionality (claims 10-17), and wherein the OS is configured to, in
`
`response to the application being determined to be unresponsive, access the data
`
`buffer and its corresponding connection state and continue the transmission
`
`or data reception operation. Id., 16:44-18:41.
`
`Neither Druschel nor Andjelic even recognizes the problem that an
`
`application performing user-level protocol processing becoming temporarily
`
`unresponsive could lead to unreliable network communication for that application.
`
`Thus, neither Druschel nor Andjelic proposes any solution to this problem, let
`
`alone the specifically claimed solution wherein the OS can access a data buffer and
`
`its corresponding connection state and continue a networking operation for an
`
`unresponsive application. The Petition’s attempt to demonstrate that a
`
`
`
`9
`
`

`
`
`
`“combination” of Druschel and Andjelic could somehow teach this claimed feature
`
`that neither of them remotely suggests predictably fails and is fatally flawed in
`
`numerous ways.
`
`No supportable reason to combine: the Petition’s alleged reasons for
`
`combining Druschel and Andjelic are boilerplate conclusory rationales (e.g., “can
`
`be combined”) the Federal Circuit has routinely rejected and are unsupported by
`
`the record. Given that Druschel and Andjelic describe alternative, mutually
`
`exclusive implementations, a person having ordinary skill in the art (“POSA”) at
`
`the time of the invention would have chosen one approach or the other—e.g.,
`
`Druschel if a multi-port NIC were available and Andjelic if only a single-port NIC
`
`were available—and would not have modified either reference based on the
`
`teachings of the other.
`
`Missing limitation: neither Druschel nor Andjelic describes a system in
`
`which the OS is configured to access a data buffer and continue a networking
`
`operation if an application is determined to be unresponsive, and no supportable
`
`combination of these references meets this requirement of all the challenged
`
`claims. The Petition essentially concedes this but points to a third reference
`
`(Edwards) that it says is “not a part of this combination” to somehow inject this
`
`missing limitation into Druschel. This unusual approach is fatally flawed and based
`
`on mischaracterizations of both Druschel and Edwards, including the incredible
`
`
`
`10
`
`

`
`
`
`assertion that Druschel necessarily meets this limitation when performing TCP
`
`processing even though Druschel does not perform TCP processing.
`
`
`
`The Petition fails to meet its burden of demonstrating that Petitioner is likely
`
`to prevail in demonstrating unpatentability of any challenged claim. Institution
`
`should be denied.
`
`II. DISCUSSION OF THE ’536 PATENT AND CHALLENGED CLAIMS
`
`A. Technology Overview
`
`The ’536 Patent claims an improved system for transmitting and receiving
`
`data from a network. A computer transmits and receives data over a network in
`
`accordance with a network protocol. See, e.g., Ex. 1002, 1:34-43, 3:4-26, 4:1-67;
`
`Ex. 1001, ¶¶33-39. A typical network protocol assists the sender and receiver in
`
`communicating over the network by allowing the receiver to make sense of the
`
`received data (e.g., by describing its format) and by specifying control signaling
`
`between the sender and receiver (e.g., error checking, retransmission requests, flow
`
`control) to ensure reliable transmission through the network. Id; Ex. 1002, 4:1-67.
`
`1. OS Kernel networking functionality.
`
` Networking functionality (e.g., protocol processing such as error checking,
`
`sending acknowledgements, retransmission, etc.) is typically performed by the OS
`
`kernel (also referred to as kernel-level functionality) on the computers that transfer
`
`and receive the data over the network. Id., 2:14-3:26; Ex. 1001, ¶40. A computer
`
`
`
`11
`
`

`
`
`
`typically has a network interface (e.g., a NIC) through which the computer
`
`connects to a network. The kernel is a portion of the OS that controls the hardware
`
`of the computer system (including the NIC), and typically performs network
`
`protocol processing. Ex. 1002, 2:14-15; Ex. 1001, ¶28. Applications typically run
`
`on a computer in what is called “user level” (or “user mode”) which is distinct
`
`from the kernel. Id.; Ex. 1002, 2:19-22.
`
`Having the OS perform protocol processing tasks to support network
`
`communications is, like other OS-level services, advantageous in that it unburdens
`
`each application program from having to perform this functionality itself. Id., 2:9-
`
`13. However, it comes with disadvantages, including a performance impact due to
`
`“context switching.” Id., 3:27-33; Ex. 1001, ¶29.
`
`Context switching is a well-known concept that results from a single
`
`processor (or a single core, where a processor has multiple cores) being limited to
`
`executing code for one application or the OS at a given time. Id. Thus, although a
`
`user may experience multiple applications and the OS as running
`
`“simultaneously,” in reality multiple contexts are time-multiplexed into the
`
`processor which only executes one context (the OS or an application) at a time.
`
`Switching from one context to another incurs a performance penalty swapping
`
`code and data into and out of the processor’s memory depending on which context
`
`is being executed. Id.; Ex. 1001, ¶40; Ex. 1002, 3:4-33. When networking
`
`
`
`12
`
`

`
`
`
`functionality is implemented in the OS there may be a context switch associated
`
`with each transmit/receive operation, which can lead to a large number of context
`
`switches during times of heavy network traffic and negatively impact system
`
`performance. Ex. 1002, 3:28-39; Ex. 1003, 005 (“current systems require that the
`
`operating system kernel be involved in each individual I/O operation”); Ex. 1001,
`
`¶40.
`
`2.
`
`User-level networking functionality.
`
`The ’536 Patent notes that prior attempts had been made at non-OS
`
`implementations of networking functionality to reduce the impact of context
`
`switching, including implementations in the “user level” where applications
`
`typically execute. Ex. 1002, 3:35-67, 2:21-22, 5:1-16; Ex. 1001, ¶¶40-44.
`
`3.
`
`Network Protocols Impose Timing Requirements.
`
`Some known networking technologies, such as the Transmission Control
`
`Protocol (TCP), provide dependable communication in part by requiring
`
`communicating entities to take certain actions within set periods of time. Ex. 1002,
`
`3:17-26, 4:61-67; Ex. 1001, ¶¶37-39. If an action is not taken within the time
`
`period set by the protocol, senders and/or receivers may infer communication
`
`difficulties such as a lost transmission or network congestion, and may respond by
`
`adjusting communication flow, such as by retransmitting a communication or
`
`
`
`13
`
`

`
`
`
`reducing the rate of communication to relieve congestion. See, e.g., Ex. 2004, 264-
`
`271. Such adjustments may cause significant slowdown in communication.
`
`4.
`
`Inventors’ Recognition of Time-Related Problems with
`Prior Attempts at User-Level Networking.
`
`The OS controls what context executes in the processor at any time and can
`
`interrupt any process (e.g., an application) currently using the processor and take
`
`the context to allow the OS to execute its own functionality. Ex. 1002, 2:61-63.
`
`Processes (e.g., applications) other than the OS have no such ability and must
`
`compete with other processes for access to the processor. Id., 1:63-2:13; Ex. 1001,
`
`¶29.
`
`An OS implementing network functionality can ensure that network protocol
`
`timing requirements are met, because the OS can take control of the processor
`
`whenever necessary to perform tasks required by the network protocol. Ex. 1002,
`
`2:61-63, 4:61-67. Conversely, the ’563 Patent explains that while “[i]n some
`
`situations [user-level networking functionality] alone may be sufficient to allow
`
`the data to be transmitted successfully,” that is not always the case because user-
`
`level processes must compete for access to the processor. Ex. 1002, 10:9-39.
`
`Thus, problems may arise relating to “acknowledgements, retransmission requests,
`
`etc.” when an application “has been descheduled” by the OS and cannot access the
`
`processor, or is “busy,” or otherwise “unresponsive.” Id.
`
`
`
`14
`
`

`
`
`
`The’536 Patent inventors appreciated that while prior work had shown user-
`
`level networking functionality to be technologically possible, such
`
`implementations experienced inadvertent violations of protocol timing
`
`requirements due to applications becoming “unresponsive,” and those violations
`
`prevented user-level networking functionality from offering reliable networking
`
`performance.
`
`“Most implementations to date … have demonstrated the potential
`
`of user-level transports, but have not addressed a number of the
`
`problems required to achieve a complete, robust, high-performance
`
`commercially viable implementation.”
`
`Id., 3:28-67, 10:9-41; see also id., 5:8-56.
`
`5.
`
`The ’536 Patent’s Solution.
`
`The ’536 patent provides networking functionality both in the OS and
`
`outside the OS, and configures the OS to support the non-OS networking
`
`functionality in response to a determination that an application is unresponsive. Id.,
`
`6:1-11; 9:26-49; Ex. 1001, ¶52, ¶46. The support provided by the OS enables the
`
`non-OS networking functionality to perform robustly.
`
`An example of a data processing system in which networking functionality
`
`is implemented both inside the OS and outside the OS (in the user level) is shown
`
`in Fig. 5 (annotated below). Ex. 1002, 9:29-32, 9:50-53, Fig. 5; Ex. 1001, ¶47.
`
`
`
`15
`
`

`
`
`
`“User level”
`
`Standard
`OS network
`functionality
`
`OS network support functionality
`
`Non-operating
`system network
`functionality
`
`Memory-mapped
`data buffer and
`connection state
`in OS memory,
`accessible to OS
`and non-OS
`functionality
`
`
`An application executing in the user level may interact with non-OS network
`
`functionality to perform networking tasks such as sending and receiving data. Ex.
`
`1002, 10:9-11; Ex. 1001, ¶¶45-47, ¶50. When data is to be sent, the non-OS
`
`network functionality may place the data into data buffers within a region of
`
`memory owned by the OS but mapped to the application’s memory and accessible
`
`to both the OS and the application. Ex. 1002, 10:9-11, 9:33-40; Ex. 1001, ¶¶45-47,
`
`¶50. For stateful protocols (i.e., those where an action to be taken depends on a
`
`“state” of the connection) the OS functionality also stores the connection state in a
`
`memory location accessible to OS and the non-OS network functionality. Ex.
`
`1002, 9:33-40.
`
`
`
`16
`
`

`
`
`
`During routine operation, the non-OS functionality handles all the
`
`application’s networking tasks without involvement of the OS, thereby achieving
`
`the performance benefit that comes with reduced context switching. Id., 10:9-13,
`
`10:26-27.
`
`As mentioned above, certain networking events trigger a requirement that a
`
`particular action be taken within a time window (e.g., receipt of a communication
`
`may require sending an acknowledgment of receipt within a time window). Ex.
`
`1002, 10:16-20. When an event occurs that requires an action within a specified
`
`time period, the NIC may notify the non-OS networking functionality executing
`
`within the application’s context (e.g., through an event queue) and a timer may be
`
`started. Ex. 1002, 10:24-25; Ex. 1001, ¶50. If the application takes the required
`
`action within the time specified by the protocol, the timer is reset. Ex. 1002, 10:25-
`
`26; Ex. 1001, ¶51. In such a case, the networking tasks are performed entirely and
`
`reliably at the user level and there is no need for OS involvement. Ex. 1002, 10:9-
`
`13 (“In some situations this alone may be sufficient to allow the data to be
`
`transmitted successfully over the network.”), 10:20-27 (“Normally this can be
`
`expected to be done by the application.”).
`
`Circumstances may arise that prevent the user-level networking functionality
`
`from responding in a timely manner. This may be due to competition in time-
`
`sharing of the processor that prevents the user-level application from gaining
`
`
`
`17
`
`

`
`
`
`access to the processor in time to perform a particular action within a specified
`
`time window, or due to the application executing in the processor but being busy
`
`performing other tasks. Id., 10:9-41 (explaining that problems may arise in
`
`response to “acknowledgements, retransmission requests, etc.” “if the application
`
`is busy or has been descheduled.”).
`
`If the application does not respond to a network notification by taking an
`
`action before the timer expires, it is determined that the application is
`
`“unresponsive.” Id., 10:27-31; Ex. 1001, ¶52. The OS then accesses the data buffer
`
`and connection state for the network connection and performs the action on the
`
`application’s behalf within the required time window. Id.; Ex. 1002, 10:27-31. In
`
`doing so, the OS steps in and continues the application’s ongoing network
`
`operation, ensuring continued reliable communication. Id., 10:27-41. Future
`
`networking actions for the connection will be handled by the non-OS
`
`functionality—unless the application is again unable to handle them in a timely
`
`manner, in which case the OS will again step in as needed. Id. The OS can support
`
`applications in this manner for both transmit and receive networking operations.
`
`Id., 11:5-6 (“… data can continue to be received fo