Paper No. 6
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`___________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`______________
`
`AKAMAI TECHNOLOGIES, INC.,
`Petitioner,
`
`v.
`
`LIMELIGHT NETWORKS, INC.,
`Patent Owner.
`
`______________
`
`
`
`Case IPR2016-01011
`Patent 7,715,324
`
`______________
`
`Patent Owner's Preliminary Response
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Patent Owner Limelight Ex. 2008
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`___________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`______________
`
`AKAMAI TECHNOLOGIES, INC.,
`Petitioner,
`
`v.
`
`LIMELIGHT NETWORKS, INC.,
`Patent Owner.
`
`______________
`
`
`
`Case IPR2016-01011
`Patent 7,715,324
`
`______________
`
`Patent Owner's Preliminary Response
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Patent Owner Limelight Ex. 2008
`
`
`
`Table of Contents
`
`I.
`
`II.
`
`INTRODUCTION ........................................................................................ 1
`
`SUMMARY OF THE PATENTED TECHNOLOGY ............................. 2
`
`III. CLAIM CONSTRUCTION ........................................................................ 3
`
`A.
`
`B.
`
`Uniform Resource Indicator ......................................................................... 4
`
`Protocol Attribute Selector ............................................................................ 8
`
`IV. STANDARD FOR INSTITUTING INTER PARTES REVIEW ........... 10
`
`V.
`
`A.
`
`B.
`
`THE PETITION DOES NOT MEET PETITIONER’S BURDEN TO
`SHOW A REASONABLE LIKELIHOOD OF SUCCESS ON ANY OF
`ITS ASSERTED GROUNDS OF INVALIDITY .................................... 12
`
`ALL GROUNDS: One of Ordinary Skill in the Art Would Not Combine
`Devanneax with Chu ................................................................................... 12
`
`ALL GROUNDS: None of the Cited Art Discloses the “protocol attribute
`selector” of Claims 6, 7, 8, 10 and 11 ......................................................... 17
`
`VI. CONCLUSION ........................................................................................... 20
`
`
`
`
`
`Page i of ii
`
`
`
`EXHIBIT LIST
`
`Exhibit
`2001
`2002
`
`2003
`
`2004
`
`2005
`
`2006
`2007
`
`Description
`Declaration of Dr. Kevin Almeroth (“Dr. Almeroth Declaration”)
`Attachment to Dr. Almeroth Declaration – CV of Dr. Kevin
`Almeroth
`Attachment to Dr. Almeroth Declaration – List of Materials
`Considered”
`Microsoft Visual C# 2008 Comprehensive: An Introduction to
`Object-Oriented Programming by Joyce Farrell, p. 821
`Joint Claim Construction and Prehearing Statement, No. 3:15-cv-
`720-JAG, Dkt. 112 (E.D. Va. June 20, 2016)
`U.S. Patent No. 6,108,703
`Order, No. 3:15-cv-720-JAG, Dkt. 146 (E.D. Va. Aug. 9, 2016)
`
`Page ii of ii
`
`
`
`I.
`
`INTRODUCTION
`
`Patent Owner, Limelight, Inc. (“Patent Owner”), submits the following
`
`Preliminary Response to the Petition for Inter Partes Review (the “Petition”) filed
`
`by Akamai Technologies, Inc. (“Petitioner”) regarding Claims 1, 2, 4, 5, 6, 7, 8,
`
`10, and 11 (“Challenged Claims”) of U.S. Patent No. 7,715,324 (“the ’324
`
`Patent”). Akamai has alleged that Claims 1, 2, 5, 6, 7, 8, and 11 are unpatentable
`
`under 35 U.S.C. § 103(a) in view of U.S. Patent Publication No. 2007/0156845
`
`(“Devanneaux”), and further in view of U.S. Patent Publication No. 2007/0226375
`
`(“Chu”) (“Ground 1”). (Petition at 14). Additionally, Akamai alleges that claims
`
`4 and 10 are unpatentable under 35 U.S.C. § 103(a) in view of the Devanneaux and
`
`Chu, further in view of the publication titled “Transmission Control Protocol,
`
`DARPA Internet Program, Protocol Specification” (“RFC793”) (“Ground 2”)
`
`(collectively, “Grounds of Rejection”). (Id.).
`
`As a threshold matter, the Petition fails to show how the cited references,
`
`alone or in combination, meet all of the limitations of any of the challenged claims.
`
`The rules require that “[e]ach petition … must include … [a] full statement of the
`
`reasons for the relief requested, including a detailed explanation of the significance
`
`of the evidence.” 37 C.F.R. § 42.22(a)(2); see also 37 C.F.R. § 42.104(b)(4)-(5).
`
`As explained by the Supreme Court, “rejections on obviousness grounds cannot be
`
`sustained by mere conclusory statements; instead, there must be some articulated
`
`Page 1 of 20
`
`
`
`reasoning with some rational underpinning to support the legal conclusion of
`
`obviousness.” KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 418 (2007), quoting In
`
`re Kahn, 441 F.3d 977, 988 (Fed. Cir. 2006). In this case, the Petition includes
`
`unsupported conclusory statements that the cited references disclose various claim
`
`elements. The Petition further fails to articulate why it would have been obvious to
`
`combine the cited references. Additionally, the Petition relies on an incorrect
`
`construction for the term “uniform resource indicator (URI),” which is present in
`
`all of the claims. This construction is contradicted by the intrinsic evidence as well
`
`as the ordinary and customary meaning the term would have to one of ordinary
`
`skill in the art at the relevant time. Accordingly, Petitioner has failed to articulate
`
`specific reasoning, based on evidence of record, to support the legal conclusion of
`
`obviousness for the Challenged Claims.
`
`II.
`
`SUMMARY OF THE PATENTED TECHNOLOGY
`
`The ’324 Patent relates to improvements in the optimization of network
`
`protocols (such as TCP) used to connect networked computers—servers and clients
`
`in particular. The ’324 Patent discloses systems and methods where a server can
`
`actively monitor network connections, such as TCP sockets, for requests. (See,
`
`e.g., Ex. 1001, 2:10-4:52, 23:14-24:48). When requests come in, the server can
`
`analyze the request to determine whether the connection should be optimized. (Id.).
`
`If the connection should be optimized, the server can re-configure the connection.
`
`Page 2 of 20
`
`
`
`The ’324 Patent discloses systems and methods that can therefore update the
`
`configuration of protocols used for active connections, throughout the duration of
`
`the connections, on a request-by-request basis. (Id.).
`
`III. CLAIM CONSTRUCTION
`In an inter partes review, the Board construes claim terms in an unexpired
`
`patent according to their broadest reasonable construction in light of the
`
`specification of the patent in which they appear. 37 C.F.R. § 42.100(b); Cuozzo
`
`Speed Technologies v. Lee, 136 S. Ct. 2131, 2144-45 (June 20, 2016). The claim
`
`language should be read in light of the specification as it would be interpreted by
`
`one of ordinary skill in the art. In re Am. Acad. Of Sci. Tech. Ctr., 367 F.3d 1359,
`
`1364 (Fed. Cir. 2004). The broadest reasonable meaning given to claim language
`
`must take into account any definitions presented in the specification. Id. (citing In
`
`re Bass, 314 F.3d 575, 577 (Fed. Cir. 2002)).
`
`In the Petition, Petitioner proposed a construction for only one claim
`
`limitation: “Uniform Resource Indicator” or “URI.” In this Preliminary Response,
`
`Patent Owner rebuts Petitioner’s construction of URI in Section III(A), below, as it
`
`is unduly narrow and conflicts with the ordinary and customary meaning of URI.
`
`In Section III(B), Patent Owner also construes “protocol attribute selector.” All
`
`other claim limitations should be given their ordinary and customary meaning.
`
`Page 3 of 20
`
`
`
`A. Uniform Resource Indicator
`As noted above, Petitioner proposes a construction for only one claim
`
`limitation: “Uniform Resource Indicator” or “URI”. Specifically, Petitioner argues
`
`that “patentee apparently acted as its own lexicographer in crafting this new term,”
`
`(Petition at 10), and that the ’324 Patent provides a new, never before used,
`
`definition for URI, where URI means “information in a request’s Uniform Resource
`
`Locator (‘URL’), such as all or part of a URL.” (Petition at 9). Notably, this
`
`construction was first presented by Petitioner in its litigation with Patent Owner,
`
`and is at odds with the broadest reasonable construction and its plain meaning. (Ex.
`
`2005, 2-3). Indeed, as shown below, “URI” was commonly used in industry at the
`
`time of the ’324 Patent, and means “a sequence of characters that identifies a
`
`requested resource, such as all or part of a URL.” (Ex. 2001, ¶¶37-43). This
`
`definition is supported by the ’324 Patent and common industry standards used at
`
`the time of the ’324 Patent.
`
`The Challenged Claims specify a “uniform resource indicator (URI).” The
`
`’324 Patent uses the term “Uniform Resource Indicator (URI)” interchangeably
`
`with the term “Uniform Resource Identifier (URI).” (See, e.g. Ex. 1001 at 16:6-8
`
`(“The depicted portion of the process begins in block 416 where a uniform
`
`resource indicator (URI) is requested by the client 102.”) (emphasis added); id. at
`
`7:18-23 (“HTTP utilizes Uniform Resource Locators (URLs), Uniform Resource
`
`Page 4 of 20
`
`
`
`Names (URNs), and Uniform Resource Identifiers (URIs) to identify information .
`
`. . . Other embodiments use URIs, URNs, other identifiers, or other information.”)
`
`(emphasis added); Ex. 2001, ¶38). Furthermore, the terms Uniform Resource
`
`Indicator and Uniform Resource Identifier are used interchangeably by computer
`
`scientists and are understood to have the same meaning. (Id.). For example,
`
`Microsoft Visual C# 2008 Comprehensive: An Introduction to Object-Oriented
`
`Programming by Joyce Farrell directly states that “[a] Uniform Resource Indicator
`
`is also known as a Uniform Resource Identifier.” (Ex. 2004, 3; Ex. 2001, ¶38
`
`(emphasis added)). According, a POSITA would understand that Uniform
`
`Resource Indicator and Uniform Resource Identifier, which share the acronym
`
`“URI”, are interchangeable terms, and are used as such in the ’324 Patent. (Ex.
`
`2001, ¶38).
`
`“URI” is a term well-understood in the art at the time of the ’324 Patent.
`
`(Id. at ¶¶37-39). Indeed, Petitioner’s own cited art of RFC3986 states “[a]
`
`Uniform Resource Identifier (URI) is a compact sequence of characters that
`
`identifies an abstract or physical resource.” (Ex. 1006, 1 (emphasis added)).
`
`Petitioner even admits that the term URI is governed by RFC3986. (Petition at 9).
`
`And Petitioner’s proposed construction, where a URI is limited to “information in
`
`a request’s Uniform Resource Locator,” is at odds with the plain meaning provided
`
`for in the ’324 Patent and RFC3986, where URIs and URLs are treated separately:
`
`Page 5 of 20
`
`
`
`Other embodiments use application-layer protocols other than HTTP
`in conjunction with TCP; use TCP alone, i.e., without HTTP; use
`other protocols; or, use other application-layer protocols
`in
`conjunction with other protocols. HTTP utilizes Uniform Resource
`Locators (URLs), Uniform Resource Names (URNs), and Uniform
`Resource Identifiers (URIs) to identify information. URLs are used in
`the primary embodiment. Other embodiments use URIs, URNs, other
`identifiers, or other information. A URL begins with the scheme
`identifier, which identifies the namespace, purpose, and syntax of the
`remainder of the URL.
`
`(Ex. 1001, 7:16-26 (emphasis added); Ex. 2001, ¶¶39-40).
`
`Section 1.1.2 of RFC3986, entitled “Examples,” is particularly illustrative,
`
`showing that URIs can take many forms, whether it be a URL, an email address, a
`
`phone number, or otherwise:
`
`
`
`Page 6 of 20
`
`
`
`(Ex. 1006, 5; Ex. 2001, ¶41; see also Ex. 2001, ¶40). Thus, Petitioner’s proposed
`
`construction, where a URI is limited to “information in a request’s Uniform
`
`Resource Locator” is unduly limiting and erroneous. (Ex. 2001, ¶¶40-41).
`
`Conversely, Patent Owner’s construction of URI, where URI means “a
`
`sequence of characters that identifies a requested resource, such as all or part of a
`
`URL,” is harmonic with the ’324 Patent and RFC3986. As noted above, RFC3986
`
`shows that a URI can take many forms, including that of a URL. (Ex. 1006 at 5).
`
`And RFC3986 states “[a] Uniform Resource Identifier (URI) is a compact
`
`sequence of characters that identifies an abstract or physical resource.” (Id. at 1
`
`(emphasis added)). This is consistent with the ’324 Patent’s teaching that a URL
`
`(a form of URI) “identif[ies] information” (i.e. a resource) and consists of a
`
`sequence of characters which includes “an alphanumeric string containing the
`
`scheme, the host field, any optional following strings, and special characters such
`
`as “;”, “/”, and “?” that are reserved for special functions such as designating a
`
`hierarchical structure in the URL.” (Ex. 1001, 7:20-22, 7:33-37; Ex. 2001, ¶¶42-
`
`43).
`
` Additionally, a POSITA would understand
`
`that a URL such as
`
`http://www.cnn.com/story and a portion of that URL, http://www.cnn.com, are
`
`both URLs (and thus are both URIs). (Ex. 2001, ¶43). In view of the foregoing,
`
`Patent Owner’s construction of URI or Uniform Resource Indicator as “a sequence
`
`Page 7 of 20
`
`
`
`of characters that identifies a requested resource, such as all or part of a URL” is
`
`the proper construction. (Id. at ¶¶37-43).
`
`Protocol Attribute Selector
`
`B.
`Claims 6, 7, 8, 10 and 11 require a “protocol attribute selector.” In the
`
`underlying litigation, the term “protocol attribute selector” was originally agreed
`
`by the parties to mean “a software process that can analyze each request to select
`
`protocol attributes to be used to deliver requested content.” (Ex. 2005, 2).
`
`Petitioner has subsequently changed its position in the litigation, and now
`
`disagrees with this construction. (Ex. 2007, 1). However, as shown below, the
`
`original agreed construction is the appropriate construction and is the broadest
`
`reasonable construction in view of the specification.
`
`The ’324 Patent states:
`
`The URI is evaluated by the protocol attribute selector 212 to find a
`match to something in the table 220. The table 220 is queried in block
`424 for any attributes. Retrieved attributes are communicated to the
`TCP handler 214 in block 428. The connection is established in block
`432 according to the selected attributes to connect the end user system
`102 with the server 206. The content object is delivered in block 436.
`This process is performed on each URI such that each connection or
`socket can be independently controlled, if desired.
`
`(Ex. 1001, 16:9-18 (emphasis added)). Thus, the ’324 Patent discloses that the
`
`“protocol attribute selector” analyzes each URI (i.e. each request). (Id.; Ex. 2001,
`
`Page 8 of 20
`
`
`
`¶45). The ’324 Patent never limits the capability of the “protocol attribute selector”
`
`to perform the above process for anything less than “each URI.” In fact, the ’324
`
`Patent repeatedly affirms the opposite, stating that “the present process can be
`
`repeated for each new request (e.g., R2/C1)” – in other words, “Request 2 over
`
`Connection 1” – “and/or each new connection (e.g., R1/C2)”:
`
`Since server 206 is capable of modifying transport layer parameters
`on a connection-by-connection and even a request-by-request basis,
`the present process can be repeated for each new request (e.g.,
`R2/C1) and/or each new connection (e.g., R1/C2) as determined by
`the data source 750 or caching function.
`
`(See, e.g., Ex. 1001, 21:9-14 (emphasis added); see also, id. at 22:8-11 (“the
`
`process can be repeated for each new request (e.g., R2/C1) and/or each new
`
`connection (e.g., R1/C2)”) (emphasis added), 18:14-19 (“As illustrated, a single end
`
`user computer 102 can establish multiple connections to a given server 206 and
`
`each connection can carry multiple content requests. Protocol stack 700 is
`
`configured such that TCP settings can be adjusted on a per-connection or even a
`
`per-request basis”) (emphasis added), 14:19-24 (“[A] modified TCP software stack
`
`that accepts and implements changes to the TCP protocol attributes on a per-
`
`connection or per-request basis.”) (emphasis added); Ex. 2001, ¶46).
`
`The ’324 Patent also states that the “protocol attribute selector” permits
`
`modifying protocol configurations on a “connection-by-connection” basis (Ex.
`
`Page 9 of 20
`
`
`
`1001, 16:5-6) “such that each connection or socket can be independently
`
`controlled” (id. at 16:17-18). However, the ’324 Patent never suggests that
`
`implementing this control process “on each URI” means that a given connection
`
`with multiple requests can be “independently controlled” just once. Such a reading
`
`would stand in contrast to the ’324 Patent’s repeated disclosure of embodiments for
`
`which “the present process can be repeated for each new request (e.g., R2/C1)” (i.e.
`
`subsequent requests over the same connection). (Ex. 1001, 21:9-14 (emphasis
`
`added); Ex. 2001, ¶46). Further, a POSITA would understand in view of the
`
`specification
`
`that modifying protocol configurations on a “connection-by-
`
`connection” basis merely relates to connections that do not have multiple requests
`
`associated with them. (Ex. 2001, ¶47).
`
`Accordingly, “protocol attribute selector” means “a software process that
`
`can analyze each request to select protocol attributes to be used to deliver
`
`requested content.” (Id. at ¶¶44-48).
`
`IV. STANDARD FOR INSTITUTING INTER PARTES REVIEW
`The Board has discretion to “deny some or all grounds for unpatentability
`
`for some or all of the challenged claims.” 37 C.F.R. § 42.108(b); see 35 U.S.C. §
`
`314(a). Petitioner bears the burden of demonstrating a reasonable likelihood that it
`
`would prevail in showing unpatentability on the grounds asserted in its petition. 37
`
`C.F.R. § 42.108(c). The Board may only institute a petition for inter partes review
`
`Page 10 of 20
`
`
`
`where “the information presented in the petition … shows that there is a reasonable
`
`likelihood that the petitioner would prevail with respect to at least 1 of the claims
`
`challenged in the petition.” 35 U.S.C. § 314(a); 37 C.F.R. § 42.108(c). Petitioner
`
`bears the burden of showing that this statutory threshold has been met. See, e.g.,
`
`Office Patent Trail Practice Guide, 77 Fed. Reg. 48,756 (Aug. 14, 2012)
`
`[hereinafter “Practice Guide”] (“The Board … may institute a trial where the
`
`petitioner establishes that the standards for instituting the requested trial are met.”).
`
`Ultimately, “the burden of persuasion is on the petitioner to prove ‘unpatentability
`
`by a preponderance of the evidence,’ 35 U.S.C. § 316(e), and that burden never
`
`shifts to the patentee.” In re Magnum Oil Tools Int'l, Ltd., No. 2015-1300, 2016
`
`WL 3974202, at *6 (Fed. Cir. July 25, 2016) (emphasis added).
`
`“To satisfy its burden of proving obviousness, a petitioner cannot employ
`
`mere conclusory statements.” Id. at *10. “The petitioner must instead articulate
`
`specific reasoning, based on evidence of record, to support the legal conclusion of
`
`obviousness.” Id. The Board is “[not] free to adopt arguments on behalf of
`
`petitioners that could have been, but were not, raised by the petitioner during an
`
`IPR.” Id. “[T]he Board must base its decision on arguments that were advanced
`
`by a party, and to which the opposing party was given a chance to respond.” Id. It
`
`is the “petitioner’s burden to demonstrate both that a skilled artisan would have
`
`been motivated to combine the teachings of the prior art references to achieve the
`
`Page 11 of 20
`
`
`
`claimed invention, and that the skilled artisan would have had a reasonable
`
`expectation of success in doing so.” Id. (internal quotes omitted).
`
`Each ground raised by Petitioner in the Petition is based on claims of
`
`obviousness under 35 U.S.C. § 103. In connection with these grounds, Petitioner
`
`must show where each claim limitation is found in the prior art. See, e.g., Kinetic
`
`Concepts, Inc. v. Smith & Nephew, Inc., 688 F.3d 1342, 1360 (Fed. Cir. 2012).
`
`Failure to do so defeats an assertion that a claim is obvious. Id. The Office Patent
`
`Trial Practice Guide specifies that among the many responses a patent owner can
`
`submit in response to a petition include: “The prior art lacks a material limitation
`
`in all of the independent claims. … The prior art teaches or suggests away from a
`
`combination that the petitioner is advocating.” Practice Guide, 77 Fed. Reg. at
`
`48,764. The Petition fails for both of these reasons.
`
`V. THE PETITION DOES NOT MEET PETITIONER’S BURDEN TO
`SHOW A REASONABLE LIKELIHOOD OF SUCCESS ON ANY OF
`ITS ASSERTED GROUNDS OF INVALIDITY
`A. ALL GROUNDS: One of Ordinary Skill in the Art Would Not
`Combine Devanneaux with Chu
`
`Petitioner argues that the Challenged Claims are obvious based on the
`
`combination of Devanneaux and Chu. Specifically, Petitioner contends a POSITA
`
`would be motivated to combine Devanneaux with Chu because:
`
`Devanneaux and Chu are in the same technical field, because both
`describe transport layer protocol optimization, because both refer to
`
`Page 12 of 20
`
`
`
`computers with operating systems implementing transport layer
`protocol optimizations, and because both provide for customizing
`those optimizations, one of ordinary skill in the art would have been
`motivated to look to Chu to provide operating system-specific
`implementation details that are not otherwise explicit in Devanneaux.
`
`(Id. at 20). However, a POSITA would not be motivated to combine Devanneaux
`
`and Chu. Devanneaux relates to content-delivery networks (“CDN”), which are
`
`uncontrolled, highly unpredictable server-based networks configured to deliver
`
`internet content to end users. (Ex. 2001, ¶52). For example, Devanneaux states
`
`the following in describing the problems involved with hosting web content:
`
`As such, the capability and flexibility of the supporting Internet
`infrastructure for the Web site becomes mission-critical. In particular,
`the infrastructure must provide good performance for all end user
`consumers, regardless of their location. The site must scale to
`handle high traffic load during peak usage periods. It must
`remain available 24x7, regardless of conditions on the Internet.
`When performance, reliability, or scalability problems do occur, Web
`site adoption and usage can be negatively impacted, resulting in
`greater costs, decreased revenue, and customer satisfaction issues.
`
`[0007] It is known in the prior art to off-load Web site content for
`delivery by a third party distributed computer system. One such
`distributed computer system is a "content delivery network" or
`"CDN" that is operated and managed by a service provider.
`
`Page 13 of 20
`
`
`
`(Ex. 1004 at ¶¶6-7 (emphasis added)). Thus, servers in a CDN must be capable of
`
`“provid[ing] good performance” regardless of the end user consumer’s location and
`
`regardless of the network traffic patterns, which may include spikes in network
`
`traffic or prolonged periods of high traffic during peak usage periods. (Id.; Ex.
`
`2001, ¶52). Accordingly, Devanneaux teaches that CDN traffic patterns are
`
`unpredictable and uncontrolled. (Ex. 2001, ¶52). Such a teaching is consistent
`
`with what a POSITA would have understood about one of the principle motivations
`
`for using a CDN: flash crowds. (Id.). Flash crowds are large unanticipated spikes
`
`in requests, sometimes caused by external events of widespread interest. (Id.).
`
`Such events create significant spikes in demand and are not predictable. (Id.).
`
`Another patent from Petitioner, U.S. Patent No. 6,108,703, highlights this
`
`unpredictability while describing the motivation for using a CDN as an alternative
`
`to a content provider using their own resources as:
`
`Although mirroring and related load-balancing solutions do allow a
`Content Provider to distribute load across a collection of servers, the
`aggregate capacity of the servers must be sufficient to handle peak
`demands. This means that the Provider must purchase and maintain a
`level of resources commensurate with the anticipated peak load
`instead of the true average load. Given the highly variable and
`unpredictable nature of the Internet, such solutions are expensive
`and highly wasteful of resources.
`
`(Ex. 2006, 15:16-25 (emphasis added); Ex. 2001, ¶52).
`
`Page 14 of 20
`
`
`
`At the other end of the spectrum is Chu, which focuses on a plug-in TCP
`
`architecture for end-user computer workstations or PCs, as opposed to content
`
`servers. (Ex. 2001, ¶53). Indeed, Chu uses the word “server” only six times and
`
`only in paragraphs 54, 69, and 70. Of these, paragraph 69 is instructive:
`
`[0069] The plug-in approach also enables employing an aggressive,
`special-purpose technique in a controlled network environment. For
`instance, a server in a data center with a well-controlled traffic
`pattern or well-tuned queuing model might deploy a non-compliant
`congestion control technique that allows packets to be sent without
`slow-start or any bandwidth throttling. This technique could be
`useful, for example, to eliminate the overhead of congestion control
`for connections that transfer data between two servers on a
`dedicated network link, or to expedite connections that exchange
`cluster membership heartbeat messages within the data center.
`Previously, such service variation either was not possible, or would
`require multiple servers.
`
`(Ex. 1007 at ¶69 (emphasis added)).
`
` Chu’s “well-controlled” network
`
`requirements are in stark contrast to the server-based CDNs of Devanneaux which,
`
`as discussed above, do not have “well-controlled traffic patterns” or a “well-tuned
`
`queuing model.” (Ex. 2001, ¶¶52-53). Since Chu teaches away from applying its
`
`TCP plug-in architecture to environments which are not well-controlled, a POSITA
`
`would not have combined the plug-in TCP architecture of Chu with the CDN
`
`servers of Devanneaux. (Id.).
`
`Page 15 of 20
`
`
`
`Further, Petitioner contends that:
`
`[T]he inclusion of the Chu plug-in architecture in the Devanneaux
`“operating system” 204 (in FIG. 2 there) is a simple substitution of
`one known element for another to obtain predictable results, or
`applying a known
`technique
`to a known device ready for
`improvement to yield predictable results.
`
`(Petition at 20-21). However, Petition cites no evidence in support of its
`
`contentions that the inclusion of the Chu plug-in TCP architecture in the
`
`Devanneaux operating system is a simple substitution or that the combination is
`
`the application of a known technique to a known device ready for improvement to
`
`yield predictable results. Such conclusory statements are insufficient to provide
`
`the motivation to combine these references as Petitioner has failed to provide
`
`articulated reasoning with some rational underpinning to support the legal
`
`conclusion of obviousness. In re Kahn, 441 F.3d 977, 988 (Fed. Cir. 2006).
`
`Indeed, paragraph 70 of Chu shows that the implementation of Chu’s plug-in TCP
`
`architecture in a server environment would not be simple or routine because of the
`
`potential detrimental impact on normal server operations:
`
`[0070] Finally, per-connection tuning can also be used to deploy and
`test experimental TCP behaviors on a limited set of TCP connections
`on a production server without exposing other, normal operations on
`the server to the riskier new behavior.
`
`(Ex. 2001, ¶54; Ex. 1007, ¶70).
`
`Page 16 of 20
`
`
`
`For at least these reasons, a POSITA would not combine Devanneaux and
`
`Chu, and thus Petitioner has failed to meet its burden to show that the Challenged
`
`Claims are unpatentable as obvious
`
`B. ALL GROUNDS: None of the Cited Art Discloses the “protocol
`attribute selector” of Claims 6, 7, 8, 10 and 11
`
`Claim 6 requires a “protocol attribute selector,” which, as defined above,
`
`means “a software process that can analyze each request to select protocol
`
`attributes to be used to deliver requested content.” (Ex. 2005, 2). Claims 7, 8, 10
`
`and 11 depend from Claim 6, and each requires a protocol attribute selector.
`
`Petitioner contends that Devanneaux discloses a protocol attribute selector,
`
`arguing:
`
`“A given XML-based configuration file includes a set of content
`handling rules and directives that facilitate one or more advanced
`content handling features. Thus, for example, when an edge server
`management process receives a request for content, it searches an
`index file for a match on a customer hostname associated with the
`request.” Devanneaux, ¶0021.
`
`(Petition at 49). However, Petitioner’s argument does not show that Devanneaux
`
`analyzes “each request,” as required by the claim, to select protocol attributes to be
`
`used to deliver requested content on a particular connection. (Ex. 2001, ¶55).
`
`Instead, Devanneaux states that metadata is selected on a customer-specific,
`
`customer domain-specific, basis:
`
`Page 17 of 20
`
`
`
`According to the present invention, a given CDN edge server is
`configured to provide one or more extended content delivery features.
`To this end, the CDN edge servers are configurable to provide these
`delivery features on a customer-specific, customer domain-specific,
`preferably using XML-based configuration files that are distributed to
`the edge servers using a metadata configuration system such as
`described above.
`
`(Ex. 1004, ¶21 (emphasis added); see also id. at ¶11 (“A CDN edge server is
`
`configured to provide one or more extended content delivery features on a domain-
`
`specific, customer-specific basis.”) (emphasis added), ¶23 (“Although
`
`the
`
`remainder of this description focuses primarily on the content prefetching
`
`capability, one of ordinary skill in the art will appreciate that, by using XML-based
`
`configurations, this function can be combined readily with other edge server
`
`functions that are also defined in such customer-specific, domain-specific
`
`configurations.”) (emphasis added), ¶84 (“Thus, for example, to enable path
`
`optimization, the customer-specific, domain-specific configuration file may include
`
`a path optimization directive such as the following.”) (emphasis added), ¶86 (“To
`
`enable edge server-to-edge server (or other client-server) TCP optimizations, the
`
`following metadata can be set in the configuration file, once again on a customer-
`
`specific, domain-specific, basis.”) (emphasis added); Ex. 2001, ¶56).
`
`Petitioner does not provide any argument as to how Devanneaux’s disclosure
`
`of providing customer-specific, domain-specific optimizations by searching an
`
`Page 18 of 20
`
`
`
`index file for a match on a customer hostname (Ex. 1004, ¶21) would involve
`
`analyzing each request to select protocol attributes to be used to deliver requested
`
`content on a particular connection. (Petition at 49). Indeed, a POSITA
`
`implementing the teachings of Devanneaux would have no reason to analyze each
`
`request in a connection to provide customer-specific, domain-specific optimizations
`
`because a single search in an index file for a match on a customer hostname would
`
`be sufficient to optimize the connection for a specific customer and domain at the
`
`time of the invention. (Ex. 2001, ¶¶55-57). Thus, a POSITA would not understand
`
`Devanneaux to disclose a “protocol attribute selector,” which is “a software process
`
`that can analyze each request to select protocol attributes to be used to deliver
`
`requested content.”
`
`According, Petitioner has failed to meet its burden to show where each claim
`
`limitation is found in the prior art. Kinetic Concepts, 688 F.3d at 1360.
`
`Accordingly, since “the Board must base its decision on arguments that were
`
`advanced by a party, and to which the opposing party was given a chance to
`
`respond,” Petitioner has not met its burden to show that Claims 6, 7, 8, 10 and 11
`
`are unpatentable as obvious for at least this reason. In re Magnum Oil, 2016 WL
`
`3974202, at *10.
`
`Page 19 of 20
`
`
`
`VI. CONCLUSION
`In view of the foregoing, Patent Owner respectfully requests that the Board
`
`deny institution of trial in this inter partes review.
`
`Dated: August 19, 2016
`
`
`
`Respectfully submitted,
`
`GREENBERG TRAURIG, LLP
`
` /hjb/
`
`Heath J. Briggs (Reg. No. 54,919)
`1200 17th Street, Suite 2400
`Denver, CO 80202
`briggsh@gtlaw.com
`Phone: (303) 572-6500
`Fax: (303) 572-6540
`
`Barry J. Schindler (Reg. No. 32,938)
`Lennie A. Bersh (Reg. No. 55,000)
`GREENBERG TRAURIG, LLP
`500 Campus Drive, Suite 400
`Florham Park, NJ 07932
`Telephone: 973-360-7900
`Facsimile: 973-301-8410
`SchindlerB@gtlaw.com
`BershL@gtlaw.com
`
`Vimal M. Kapadia (Reg. No. 73,310)
`GREENBERG TRAURIG, LLP
`MetLife Building
`200 Park Avenue,
`New York, New York 10166
`Telephone: (212) 801-9200
`Facsimile: (212) 801-6400
`KapadiaV@gtlaw.com
`
`Counsel for Patent Owner Limelight, Inc.
`
`Page 20 of 20
`
`
`
`CERTIFICATE OF SERVICE
`
`I hereby certify that on this 19th day of August, 2016, a copy of this Patent
`
`Owner's Preliminary Response including all attachments and exhibits has been
`
`served in its entirety via electronic mail by emailing Petitioner’s lead counsel at
`
`ppysher@choate.com with a courtesy copy to AkamaiIPR@choate.com, as
`
`provided for by Petitioner’s listed Service Information in its Petition.
`
`
`
`
`
` Respectfully submitted,
`
` GREENBERG TRAURIG, LLP
`
`_/hjb/____________________
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
