Paper No. __
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`_____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`_____________
`
`EXABLAZE PTY. LTD. and ZOMOJO PTY. LTD.,
`Petitioners,
`
`v.
`
`SOLARFLARE COMMUNICATIONS, INC.,
`Patent Owner.
`_____________
`
`Case No. IPR2016-01832
`Patent No. 8,645,558
`_____________
`
`PATENT OWNER’S PRELIMINARY RESPONSE
`
`
`
`
`
`
`
`
`
`
`
`
`

`
`
`
`
`
`I.
`
`TABLE OF CONTENTS
`
`INTRODUCTION ............................................................................................. 1
`
`II. OVERVIEW OF THE ’558 PATENT AND CHALLENGED CLAIMS ........ 6
`
`III. CLAIM CONSTRUCTION............................................................................... 9
`
`A. “in response to signaling from a thread of the application” ......................10
`
`IV. THE PETITION SHOULD BE DENIED BECAUSE IT FAILS TO
`DEMONSTRATE A REASONABLE LIKELIHOOD OF
`PREVAILING AS TO ANY CHALLENGED CLAIM .................................13
`
`A. Level of Ordinary Skill in the Art .............................................................13
`
`B. Mansley Does Not Disclose a System as Claimed ....................................13
`
`1. Mansley’s CLAN ................................................................................13
`
`2. Mansley’s TCP/IP over CLAN Implementation .................................16
`
`3. Petitioners Mischaracterize Mansley as Teaching that the
`TCP/IP Stack Extracts Traffic Data ....................................................21
`
`4. Petitioners Mischaracterize Mansley as Teaching that the
`TCP/IP Stack Provides the Sockets API .............................................25
`
`C. Ground 1: None of claims 1–5, 7 and 10–12 are anticipated by
`Mansley .....................................................................................................26
`
`1. The Petition Fails to Demonstrate That Mansley Anticipates
`Claim 1 ................................................................................................26
`
`a. Mansley’s TCP/IP Stack Does Not Extract Traffic Data ........... 28
`
`b. Mansley’s TCP/IP Stack Does Not Provide the Sockets
`API .............................................................................................. 34
`
`c. None of Dependent Claims 2–5, 7 and 10–12 Are
`Anticipated by Mansley .............................................................. 41
`
`d. Conclusion Regarding Ground 1 ................................................ 42
`
`D. Ground 2: Claim 6 would not have been obvious over Mansley and
`Riddoch ......................................................................................................42
`
`E. Ground 3: Claims 8-9 would have been obvious over Mansley in
`view of the Knowledge of a PHOSITA .....................................................42
`
`V. CONCLUSION ................................................................................................43
`
`
`
`
`
`

`
`
`
`CASES
`
`TABLE OF AUTHORITIES
`
`
`Abbott Labs. v. Baxter Pharma. Prods., Inc.,
`471 F.3d 1363 (Fed. Cir. 2006) ............................................................................11
`
`Amazon.com, Inc. v. Personalized Media Comm’s, LLC,
`IPR2014-01527, Paper No. 42 (PTAB March 23, 2016) .....................................13
`
`Ariosa Diagnostic v. Verinata Health, Inc.,
`805 F.3d 1359 (Fed. Cir. 2014) ............................................................................28
`
`EMI Grp. N. Am., Inc. v. Intel Corp.,
`157 F.3d 887 (Fed. Cir. 1998) ..............................................................................11
`
`Enfish, LLC v. Microsoft Corp.,
`822 F.3d 1327 (Fed. Cir. 2016) ............................................................................26
`
`In re Am. Acad. of Sci. Tech Ctr. ,
`367 F.3d 1359 (Fed. Cir. 2004) ............................................................................30
`
`In re Bass,
`314 F.3d 575 (Fed. Cir. 2002) ..............................................................................10
`
`In re: Magnum Oil Tools International, Ltd.,
`829 F.3d 1364 (Fed. Cir. 2016) ............................................................................41
`
`Microsoft Corp. v. Proxyconn, Inc.,
`789 F.3d 1292 (Fed. Cir. 2015) ............................................................................10
`
`MindGeek, S.A.R.L. v. Skky Inc.,
`IPR2014-01236, Paper No. 45 (PTAB Jan. 29, 2016) .........................................10
`
`Net MoneyIN, Inc. v. VeriSign, Inc.,
`545 F.3d 1359 (Fed. Cir. 2008) ............................................................................26
`
`Seabery N.A. v. Lincoln Global, Inc.,
`IPR2016–00749, Paper No. 13 (PTAB Sept. 21, 2016) .......................................30
`
`Tempo Lighting, Inc. v. Tivoli, LLC,
`742 F.3d 973 (Fed. Cir. 2014) ................................................................. 10, 12, 13
`
`ii
`
`

`
`
`
`Trivascular, Inc. v. Samuels,
`812 F.3d 1056 (Fed. Cir. 2016) ............................................................................10
`
`Vivid Techs., Inc. v. Am. Sci. & Eng’g, Inc.,
`200 F.3d 795 (Fed. Cir. 1999) ..............................................................................12
`
`Volkswagen Grp. of Am., Inc. v. Signal IP, Inc.,
`IPR2015-01088, Paper No. 7 (PTAB Oct. 29, 2015) ...........................................11
`
`STATUTES
`
`35 U.S.C. §316(e) ....................................................................................................28
`
`REGULATIONS
`
`37 C.F.R. § 42.65(a) ......................................................................................... 30, 33
`
`37 C.F.R. § 42.100(b) ................................................................................................ 9
`
`
`
`iii
`
`

`
`I.
`
`INTRODUCTION
`
`Petitioners seek inter partes review of claims 1-12 of U.S. Patent No.
`
`8,645,558 (“the ’558 patent”) based on a single primary reference, Mansley (Ex.
`
`1003). Petitioners allege that Mansley anticipates independent claim 1 and the
`
`majority of the dependent claims, and renders the other dependent claims obvious.
`
`The Petition fails to demonstrate that Mansley discloses all the limitations of
`
`independent claim 1, and indeed Mansley manifestly does not. The Petition does
`
`not meet its burden and should be denied.
`
`The ’558 Patent describes and claims a specific data processing system that
`
`achieves performance improvements in networked computer systems. These
`
`techniques can be used in commercial environments where 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 executing 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 Petitioners
`
`(collectively “Exablaze”) both sell specialized networking products to institutions
`
`that engage in high speed trading. Solarflare filed suit against Exablaze in United
`
`States Federal Court for the District of New Jersey alleging infringement of the
`
`1
`
`

`
`’558 Patent and five other Solarflare Patents. Exablaze’s Petition was undoubtedly
`
`filed in response to that lawsuit.
`
`The ’558 Patent claims a data processing system for receiving data from a
`
`network and that has a protocol processing entity that performs “protocol
`
`processing” in a specific manner. Network communications are typically
`
`performed in accordance with one or more network protocols that specify
`
`numerous aspects of how data is to be transmitted from a sender over a network to
`
`a receiver. Most network protocols (e.g., TCP/IP) transmit data in packets that
`
`include a payload of data (referred to in the ’558 Patent as “traffic data”) and a
`
`“header” that includes information, specified by the network protocol, used in in
`
`transmitting the payload of traffic data from the sender through the network to the
`
`receiver.
`
`In a typical system, the operating system (“OS”) of a computer that receives
`
`a packet transmitted using a network protocol (e.g., TCP/IP) performs “protocol
`
`processing” on the received packet. The specific protocol processing tasks vary
`
`depending on the specified protocol. Typical protocol processing tasks include
`
`error checking, sending an acknowledgement that the packet was received,
`
`extracting the payload of traffic data from the packet, sending the traffic data to an
`
`application program running on the receiving computer for which the data is
`
`intended (e.g., to an email application if the received packet is an email), and
`
`2
`
`

`
`
`
`determining whether the received packet is one of several related packets so that its
`
`payload of traffic data should be combined with the payloads from other packets
`
`before being sent to the application program.
`
`The ’558 Patent describes, and all of the challenged claims recite, a new type
`
`of protocol processing entity that performs protocol processing in a way that
`
`improves performance for reasons explained below. In the claimed system,
`
`protocol processing of data received from a network to extract traffic data is
`
`performed not in response to the data being received from the network, but rather
`
`in response to signaling from an application program requesting whether data is
`
`available.
`
`All of the Grounds rely upon a single prior art reference, Ex. 1003
`
`(“Mansely”), to allegedly disclose the protocol processing entity recited in all the
`
`challenged claims. Mansley is an article relating to a highly specialized network
`
`called CLAN (Collapsed Local Area Network), and specifically relates to
`
`techniques for connecting a CLAN network to the Internet via a network gateway.
`
`As Mansley acknowledges, CLAN was developed by a team of people including
`
`Steve Pope (Chief Technology Officer of Patent Owner Solarflare and the lead
`
`inventor on the ’558 Patent challenged herein) and Dave Riddoch (another
`
`Solarflare employee and named inventor on the ’558 Patent). Mansley’s author,
`
`Kieran Mansley, is also a Solarflare employee.
`
`3
`
`

`
`
`
`Exablaze repeatedly mischaracterizes Mansley and those
`
`mischaracterizations are fatal to the Petition. Mansley’s system does not operate
`
`how the Petition alleges, and the entity in Mansley that the Petition alleges meets
`
`the claimed “protocol processing entity” manifestly does not.
`
`Among the unique characteristics of the CLAN network described in
`
`Mansley is that each computer connected to the CLAN has a memory or queue that
`
`is made available to the other computers on the CLAN, and a sending computer
`
`controls the transfer of data over the CLAN by writing that data into the memory
`
`queue of the receiving device. Exablaze’s Petition largely ignores this unique
`
`aspect of the manner in which the CLAN operates, even though it is described in
`
`Mansley and further detailed in numerous publications listed in Mansley’s
`
`“References.” Mansley, p.15-16.
`
`Mansley describes a system where TCP/IP is run on top of a CLAN. A
`
`CLAN network implements its own robust network protocol and it is unnecessary
`
`and redundant to run additional network protocols on top of a CLAN. However,
`
`Mansley teaches doing so to allow a CLAN network to be connected, through a
`
`gateway, to the Internet (a network using the TCP/IP network protocols). Mansley
`
`explicitly teaches that when TCP/IP packets are received from the Internet at the
`
`gateway, the gateway assists the servers in the CLAN network with protocol
`
`processing by “having the gateway strip headers from incoming packets and
`
`4
`
`

`
`
`
`deliver the headers and payloads to the servers in separate queues.” Mansley, p.14.
`
`This is consistent with the way Mansley describes “implementation” of TCP/IP
`
`over CLAN for communications that originate within the CLAN – the sender
`
`separates “the headers from the payloads and transfer[s] them into separate
`
`queues.” Id., p.12. Thus, while computers on the CLAN that receive data perform
`
`other forms of protocol processing on the data in response to a request from an
`
`application, the protocol processing performed does not include protocol
`
`processing to extract traffic data as recited in all the challenged claims.
`
`The Petition mischaracterizes Mansley’s teachings by pointing to sections of
`
`Mansley that reference protocol processing performed in response to a request
`
`from an application and suggesting that these sections teach extraction of traffic
`
`data. They do not. As such, the Petition resorts to “Graphics” that purport to
`
`illustrate how Mansley operates. These Graphics are inaccurate and misleading.
`
`Quite simply, the Petition fails to establish that Mansley teaches that the receiver
`
`performs protocol processing to extract traffic data as recited in all the challenged
`
`claims. That failure is fatal to all three Grounds in the Petition, as Mansley alone
`
`is alleged to disclose this feature.
`
`All the challenged claims also require that the protocol processing entity that
`
`extracts the traffic data provide an application programming interface (API) to
`
`interface with the application for which the traffic data is intended. The Petition
`
`5
`
`

`
`
`
`alleges that a particular entity in Mansley (the “TCP/IP stack”) meets the claimed
`
`protocol processing entity and provides a particular API (the “sockets API”).
`
`Petition, p.25. This assertion is flatly contradicted by Mansley, which explicitly
`
`states that the TCP/IP stack does not provide the sockets API. All the Grounds in
`
`the Petition fail for this additional reason.
`
`II. OVERVIEW OF THE ’558 PATENT AND CHALLENGED CLAIMS
`
`The ’558 Patent claims an improved system for receiving data from a
`
`network. A computer receives data over a network in accordance with a network
`
`protocol. Ex. 1002, 43:15-21. 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 the format in which the data was
`
`transmitted and carried through the network) 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.
`
`As an example, Figure 23 of the ’558 Patent shows a UDP packet 43 within
`
`an IP packet 40. Id., 48:13-29. User Datagram Protocol (UDP) is an alternative to
`
`Transmission Control Protocol (TCP). The IP and UDP headers (41 and 44)
`
`include the destination for the packet and the traffic data is “carried as the payload”
`
`45. Id. In TCP and UDP packets, the computer receiving the data uses the known
`
`6
`
`

`
`
`
`protocol to extract the payload from the headers and deliver the payload traffic data
`
`to its destination application using the header information. Id.
`
`
`
`Separation of headers from the traffic data and other protocol processing
`
`(e.g., error checking, sending acknowledgements, etc.) is typically performed by
`
`the operating system on the computer that receives the packet. Id., 43:49-56. A
`
`computer typically has a network interface through which the computer connects to
`
`a network. When the network interface connecting a computer to a network
`
`receives data, the network interface typically sends a signal – known as an
`
`interrupt – to the operating system (OS). Id., 43:49-51. In response to the
`
`interrupt, the OS separates the traffic data from the headers, performs other
`
`protocol processing (e.g., error checking, sending acknowledgements) and sends
`
`the traffic data to its destination application. Id., 43:53-56.
`
`Having the OS perform protocol processing is, like other OS level services,
`
`advantageous in that it unburdens each application program from having to
`
`perform this functionality on its own. However, it comes with disadvantages. One
`
`disadvantage relates to a performance impact due to “context switching.” Id.,
`
`7
`
`

`
`
`
`43:57-67. Context switching is a well-known concept that results from a single
`
`processor core in a computer system having the capability to only execute code for
`
`one application or the OS at a given time. Thus, although a user may not notice
`
`and may experience multiple applications and the OS as running “simultaneously,”
`
`in reality multiple contexts are time-multiplexed into each processor core which
`
`only executes one context (the OS or an application) at a time. Switching from one
`
`context to another incurs a performance penalty due to the time incurred in
`
`swapping code into and out of the processor’s memory depending on which
`
`context is being executed at any given time. Id.
`
`Another disadvantage with conventional protocol processing is that the use
`
`of interrupts and system calls to signal the OS that data requiring protocol
`
`processing has been received, as those interrupts and system calls use system
`
`resources. Id.
`
`The ’558 Patent discloses embodiments of a data processing system that
`
`perform protocol processing outside of the OS to avoid context switching, and do
`
`so in response to signaling from an application program requesting whether data is
`
`available and thereby eliminates interrupts and system calls conventionally used to
`
`initiate protocol processing in response to data being received. Protocol processing
`
`is performed by a protocol processing entity that provides an application
`
`programming interface (API) configured to process the received data in accordance
`
`8
`
`

`
`
`
`with a network protocol to extract traffic data from the received data. Id., 65:28-
`
`31.
`
`The challenged claims (1-12) include only a single independent claim
`
`(claim 1) which recites:
`
`[A] A data processing system for receiving data from a network, and
`
`processing that data in accordance with a network protocol to
`
`extract traffic data therefrom,1 the data processing system having:
`
`[B] a memory;
`
`[C] a network interface for receiving the data from the network and
`
`storing the data in the memory;
`
`[D] an operating system for supporting one or more applications;
`
`[E] an application supported by the operating system; and
`
`[F] a protocol processing entity providing an application
`
`programming interface (API) configured to process the received
`
`data in accordance with a network protocol to extract traffic data
`
`therefrom, the protocol processing entity being arranged to perform
`
`protocol processing of the received data in the memory in response to
`
`signaling from a thread of the application to request whether data is
`
`available for one or more endpoints of the data processing system.
`
`III. CLAIM CONSTRUCTION
`
`In this proceeding, claim terms should be given their broadest reasonable
`
`interpretation (BRI). 37 C.F.R. § 42.100(b). For a term that is explicitly defined in
`
`the specification, the BRI is that definition. MindGeek, S.A.R.L. v. Skky Inc.,
`
`
`1 Emphasis added throughout unless otherwise indicated.
`
`9
`
`

`
`
`
`IPR2014-01236, Paper No. 45, p.5 (PTAB Jan. 29, 2016) (“The Office must apply
`
`the broadest reasonable meaning to the claim language, taking into account any
`
`definitions presented in the specification.”) (citing In re Bass, 314 F.3d 575, 577
`
`(Fed. Cir. 2002)). For other terms, the BRI is the plain and ordinary meaning
`
`consistent with the specification. Trivascular, Inc. v. Samuels, 812 F.3d 1056,
`
`1061-1062 (Fed. Cir. 2016) (“Under a broadest reasonable interpretation, words of
`
`the claim must be given their plain meaning, unless such meaning is inconsistent
`
`with the specification and prosecution history”). The “PTO should also consult the
`
`patent’s prosecution history” in construing claims in accordance with the BRI in
`
`post grant proceedings. Microsoft Corp. v. Proxyconn, Inc., 789 F.3d 1292, 1298
`
`(Fed. Cir. 2015). But “the PTO is under no obligation to accept a claim
`
`construction proffered as a prosecution history disclaimer.” Tempo Lighting, Inc. v.
`
`Tivoli, LLC, 742 F.3d 973, 978 (Fed. Cir. 2014).
`
`A.
`
`“in response to signaling from a thread of the application”
`
`Claim 1 recites the protocol processing entity being arranged to perform
`
`protocol processing “in response to signaling from a thread of the application.”
`
`The Petition offers an alleged “interpretation” of this phrase that does not interpret
`
`it all, but instead repeats virtually every word in the phrase and then seeks to
`
`improperly append a negative limitation – “not in response to receiving the data
`
`from the network”– to the end of this phrase. Petition, p.10.
`
`10
`
`

`
`
`
`Petitioners’ improper “interpretation” is irrelevant to the Petition –
`
`Petitioners do not even attempt to apply the purported “interpretation” to their
`
`alleged unpatentability analysis. Petition, pp. 27-30. Petitioners’ “claim
`
`construction” argument seems to be nothing more than an improper litigation-
`
`driven attempt to seek an irrelevant advisory opinion from the Board.
`
`Patent Owner disagrees that Petitioners’ prosecution history disclaimer
`
`argument is correct – neither the specification nor the prosecution history supports
`
`Petitioners’ assertion of a “clear and unmistakable” disclaimer. Petition, p.10.
`
`However, the Board need not address Petitioners’ prosecution history
`
`disclaimer argument because it is not relevant for any Ground. Abbott Labs. v.
`
`Baxter Pharma. Prods., Inc., 471 F.3d 1363, 1368 (Fed. Cir. 2006) (unnecessary to
`
`construe a phrase “with numerical exactitude,” as claims were anticipated under
`
`“any definition … that the claims might reasonably bear”); EMI Grp. N. Am., Inc.
`
`v. Intel Corp., 157 F.3d 887, 895 (Fed. Cir. 1998) (“[I]t is irrelevant whether the
`
`district court achieved a technologically perfect definition, because there is no
`
`dispute that the corresponding step of the Intel process is within the literal scope of
`
`[limitation].”); Volkswagen Grp. of Am., Inc. v. Signal IP, Inc., IPR2015-01088,
`
`Paper No. 7, p.8 (PTAB Oct. 29, 2015) (“Only those terms which are in
`
`controversy need to be construed, and only to the extent necessary to resolve the
`
`11
`
`

`
`
`
`controversy.”) (citing Vivid Techs., Inc. v. Am. Sci. & Eng’g, Inc., 200 F.3d 795,
`
`803 (Fed. Cir. 1999)).
`
`As this Preliminary Response demonstrates, the Petition fails to establish
`
`that Mansley discloses all of the elements of claim 1 for reasons unrelated to the
`
`language Petitioners seek to construe. For instance, the plain language of claim 1
`
`requires that the protocol processing entity provide “an application programming
`
`interface (API) configured to process the received data in accordance with a
`
`network protocol to extract traffic data” regardless of what such processing is
`
`performed in response to. This is not in dispute. Petition, p.25. This Preliminary
`
`Response demonstrates that the Petition fails to establish that Mansley discloses
`
`what the parties agree the claims require. This, coupled with the fact that
`
`Petitioners do not even use their prosecution history disclaimer “interpretation” in
`
`their analysis (Petition, pp.27-30), confirms that addressing Petitioners’
`
`prosecution disclaimer argument is not necessary or required.
`
`Independently, the Board need not address Petitioners’ argument based on a
`
`purported “prosecution history disclaimer” because the Board is not bound by
`
`prosecution history disclaimer. Tempo Lighting, 742 F.3d at 978 (“the PTO is
`
`under no obligation to accept a claim construction proffered as a prosecution
`
`history disclaimer.”); MindGeek, IPR2014-01236, Paper No. 45, p.8 (same);
`
`12
`
`

`
`
`
`Amazon.com, Inc. v. Personalized Media Comm’s, LLC, IPR2014-01527, Paper
`
`No. 42, p.41 (PTAB March 23, 2016) (citing Tempo Lighting for same).
`
`IV. THE PETITION SHOULD BE DENIED BECAUSE IT FAILS TO
`DEMONSTRATE
`A
`REASONABLE
`LIKELIHOOD
`OF
`PREVAILING AS TO ANY CHALLENGED CLAIM
`
`A. Level of Ordinary Skill in the Art
`
`Petitioners allege that a person of ordinary skill in the art would have “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.”
`
`Petition, p.4. For the purpose of this preliminary response only, Patent Owner does
`
`not dispute this level of skill in the art.
`
`B. Mansley Does Not Disclose a System as Claimed
`
`Mansley is titled “Engineering a User-Level TCP for the CLAN Network.”
`
`The petition seizes on the “User-Level TCP” aspect of Mansley, but largely
`
`ignores the “CLAN Network” aspect of the article. Indeed, Petitioners make
`
`almost no effort to explain what the highly specialized CLAN Network is and how
`
`it operates in ways that differ from typical networks.
`
`1. Mansley’s CLAN
`
`A “CLAN” is a “Collapsed LAN” or “Collapsed Local Area Network.” See
`
`Mansley, p.8. CLAN was developed by a team including Steve Pope and David
`
`13
`
`

`
`
`
`Riddoch, both Solarflare employees (Dr. Pope is Solarflare’s CTO) and named
`
`inventors on the ’558 Patent. Id., p.15-16 (Acknowledgements, and References
`
`[28] and [29]). Kieran Mansley, author of Mansley, is also a Solarflare employee.
`
`CLAN “is a low latency, high performance, user-level network” developed
`
`primarily for use in “the server room and cluster computing” and is a “connection
`
`oriented” “physical network.” Id., pp.11, 9.
`
`A CLAN network includes a switch connected to hosts within the CLAN
`
`network, and may include a Bridge to allow for connection to other networks. This
`
`is shown, for example, in Riddoch (Ex. 1005), p.19, which Mansley describes as
`
`having “detailed descriptions of the hardware and software support” for the CLAN
`
`network. Mansley, p.9.
`
`
`
`Mansley teaches that to set up a connection between computers in the CLAN
`
`network, memory is “mapped from one host across the [CLAN] network to
`
`another.” Id. This creates a message space, referred to as a “Distributed Message
`
`14
`
`

`
`
`
`Queue (DMQ),” shared by the sending and receiving computers – the DMQ
`
`“physically resides in the memory of the receiver and the sender has a mapping of
`
`[the DMQ] in its own address space.” Id. The DMQ is shown in Mansley Figure 1
`
`(below). Given that the DMQ is a memory space shared between the sender and
`
`receiver, the sender can access this shared memory space (DMQ) to write data to
`
`it, and the receiver can access the shared memory space (DMQ) to retrieve data
`
`from it. Id. Thus, data is transmitted across the CLAN network by having the
`
`sender write the data to the DMQ memory space on the receiver. Id. This process
`
`is characterized in Mansley as “send-directed” because it is the sender that controls
`
`the transfer of data across the network and “the sender determines the final location
`
`(in the receiver’s [DMQ] memory) of the data, not the receiver.” Id., p.11.
`
`
`
`15
`
`

`
`
`
`Both the sender and receiver keep copies of a read pointer and a write pointer to
`
`mark the current read and write positions in the DMQ. Id., p.9. Transferring data
`
`from a sender to a receiver across the CLAN simply involves “writing packets to
`
`[the DMQ] and updating the queue pointers.” Id.
`
`2. Mansley’s TCP/IP over CLAN Implementation
`
`CLAN is a reliable network that can be used directly by application
`
`programs without the need for any higher level network protocol to run on top of
`
`it. Mansley, p.14. For example, CLAN replaces all layers of the 7-layer protocol
`
`stack Exablaze’s expert references except for the application layer. See Ex. 1001
`
`(Jeffay Decl.), ¶34. However, a bridge must be used to connect a CLAN “to the
`
`wider world” which can include networks using other network protocols, and
`
`Mansley teaches a specific approach of using a bridge that acts as a gateway to the
`
`Internet and “help[s] with TCP processing” of Internet communications transmitted
`
`using TCP/IP. Mansley, pp.8, 14. The bridge topology is shown in Mansley’s
`
`Figure 5 (reproduced below).
`
`16
`
`

`
`
`
`
`
`Data sent over the Internet using the TCP/IP protocols is sent in packets that,
`
`like the UDP packets described above, have headers and payloads of traffic data.
`
`To send TCP/IP communications over the CLAN (e.g., between Host 1 outside the
`
`CLAN network and Host 2 inside the CLAN network in Figure 5), Mansley
`
`teaches using two separate DMQs, one for the TCP headers and the other for the
`
`payloads. Mansley, p.12 (“We separate the headers from the payloads and transfer
`
`them into two separate queues.”). Mansley teaches that the separation of the
`
`headers from the payloads is done by the sender, not the receiver.
`
`As mentioned above, the CLAN is connected to the Internet via a bridge that
`
`serves as a gateway to the CLAN network. Id., p.14 (“To connect the CLAN
`
`network to the wider world we require a bridge.”); id., p.8 (“network gateway
`
`which connects CLAN to the Internet to assist a server cluster in protocol
`
`processing.”). When the gateway receives a TCP/IP packet destined for a CLAN
`
`17
`
`

`
`
`
`server (e.g., Host 2 in Figure 5), “the gateway strip[s] headers from incoming
`
`packets and deliver[s] the headers and payloads to the servers in separate queues,
`
`in the same way as is done for intra-cluster communication.” Id., p.14. With the
`
`payload (traffic data) stored in a separate queue, the receiver performs “protocol
`
`processing directly on the data, in place, without copying it.” Id., p.11.
`
`Thus, Mansley is explicit that for TCP/IP communications that originate
`
`outside the CLAN, the payload of traffic data is stripped by the gateway when the
`
`TCP/IP packet is received by the gateway, and the gateway places the payloads
`
`and headers into separate dedicated queues in the CLAN server that receives the
`
`data. Id., p.14; Jeffay Decl., ¶ 83 (equating payload and traffic data). Thus, the
`
`protocol processing performed by the CLAN server that receives the data does not
`
`involve extracting traffic data from a TCP/IP packet because the payload traffic
`
`data was already extracted by the gateway.
`
`Mansley is also explicit that the sender delivers “the headers and payloads to
`
`the servers in separate queues” in “the same way” for communications that
`
`originate within the CLAN (“intra-cluster communication”). Mansley, p.14. That
`
`is, if a TCP/IP communication is sent “intra-cluster” from one computer on the
`
`CLAN to another, the sender transmits the headers separately from the payload
`
`traffic data and places each into a dedicated queue (DMQ) on the receiving
`
`computer.
`
`18
`
`

`
`
`
`Thus, regardless of whether a TCP/IP communication originates from inside
`
`or outside the CLAN, the protocol processing performed by the receiving CLAN
`
`server does not involve extracting traffic data from the TCP packet because the
`
`traffic data was already extracted by the sender and placed in a separate queue on
`
`the receiver.
`
`Mansley describes the receiving CLAN server as performing other types of
`
`protocol processing using a TCP/IP stack, but that protocol processing does not
`
`involve extraction of traffic data. While Mansley is not exhaustive about these
`
`other types of protocol processing, a POSA would have understood that
`
`conventional protocol processing for TCP/IP includes numerous tasks unrelated to
`
`extracting the payload of traffic data (e.g., error checking, sending an
`
`acknowledgement, requesting retransmission, etc.). Id., p.14 (including
`
`retransmission requests as a type of protocol processing performed by the
`
`gateway); see also Ex. 1002 at 43:15-36, 46:36-41 (describing integrity checks,
`
`retransmission requests, handling of flow control data as types of “protocol
`
`processing”). “Delivery” of the data to the application after protocol processing by
`
`the TCP/IP stack is simply the application reading the information from the
`
`payload queue. Mansley, p.11 (“we are able to perform both delivery and protocol
`
`processing directly on the data, in place, without copying it.”).
`
`19
`
`

`
`
`
`Mansley teaches a unique CLAN TCP/IP architecture that includes the
`
`application, a network interface, and a TCP/IP stack. In Mansley’s architecture,
`
`“rather than the components being arranged in a linear fashion they are arranged
`
`with the CLAN network code acting as a hub.” Id., p.10.
`
`
`
`As shown by the arrow in Fi