Petitioner’s Reply for IPR2015-00483
`
`Paper No. 43
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`___________________
`
`MICROSOFT CORPORATION, and
`INTERNATIONAL BUSINESS MACHINES CORPORATION,
`Petitioners,
`
`v.
`
`PARALLEL NETWORKS LICENSING, LLC,
`Patent Owner.
`
`
`
`
`
`
`
`
`
`Case No. IPR2015-004831
`Patent No. 5,894,554
`
`
`
`
`PETITIONERS’ REPLY
`
`
`
`
`
`
`
`
`
`
`
`
`
`1 IPR2015-00484 has been consolidated with this proceeding; International
`Business Machines Corporation was joined as a party to this proceeding via
`Motions for Joinder in IPR2015-01729 and IPR2015-01731.
`
`
`
`
`
`Paper No. 43
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`___________________
`
`MICROSOFT CORPORATION, and
`INTERNATIONAL BUSINESS MACHINES CORPORATION,
`Petitioners,
`
`v.
`
`PARALLEL NETWORKS LICENSING, LLC,
`Patent Owner.
`
`
`
`
`
`
`
`
`
`Case No. IPR2015-004831
`Patent No. 5,894,554
`
`
`
`
`PETITIONERS’ REPLY
`
`
`
`
`
`
`
`
`
`
`
`
`
`1 IPR2015-00484 has been consolidated with this proceeding; International
`Business Machines Corporation was joined as a party to this proceeding via
`Motions for Joinder in IPR2015-01729 and IPR2015-01731.
`
`
`
`
`
`Petitioner’s Reply for IPR2015-00483
`
`TABLE OF CONTENTS
`
`Claims 14, 15, 18, 19, 33 and 47 Are Unpatentable Over
`
`PATENT OWNER HAS FAILED TO ANTEDATE LEAF ..................... 1
`THE CLAIMS ARE UNPATENTABLE .................................................... 3
`A.
`SWEB95 Routes and Processes The Same Request (All Claims) ........ 3
`B.
`SWEB95 Uses Dynamic Page Server Information (All Claims) ........ 12
`C.
`SWEB95’s Page Servers Release The Web Server (All Claims) ....... 13
`D.
`Claim 15 (Connection Cache) Is Unpatentable ................................... 14
`E.
`Claim 16 (Logging Into A Data Source) Is Unpatentable .................. 17
`F.
`Claims 17, 29, 43, 49 (Page Cache) Are Unpatentable ....................... 18
`G.
`Claims 18, 19 (HTML Templates) Are Unpatentable ........................ 20
`H.
`Claims 21, 23, 35 and 37 Are Unpatentable ....................................... 21
`I.
`Claims 33 and 47 (Front End Server) Are Unpatentable .................... 21
`J.
`SWEB95 In View Of Leaf .................................................................. 22
`III. NO OBJECTIVE EVIDENCE OF NONOBVIOUSNESS ...................... 24
`
`I.
`II.
`
`
`
`
`
`i
`
`
`
`
`Petitioner’s Reply for IPR2015-00483
`
`I.
`
`PATENT OWNER HAS FAILED TO ANTEDATE LEAF
`No Evidence of Conception. Patent Owner seeks to remove Leaf as prior
`
`art by alleging an earlier conception and reasonable diligence. Resp. at 5-12, 49-
`
`50. The institution decision only applies Leaf against dependent claims 14-15, 18-
`
`19, 33 and 47, IPR2015-00483 Paper 10 at 23; IPR2015-00484 Paper 10 at 23, but
`
`Patent Owner offers no evidence of when the inventions defined by those claims
`
`may have been conceived, instead focusing solely on independent claim 12. Resp.
`
`at 10-12; see Ex. 2092, ¶39. But even its claim 12 analysis makes no attempt to
`
`address various limitations found in all independent claims, such as the “releasing”
`
`and “concurrently processes” limitations. See id. Thus, Patent Owner has not
`
`shown an earlier conception for any claim against which Leaf was applied.
`
`No Evidence of Diligence. In order to antedate Leaf, Patent Owner was
`
`also required to show reasonable diligence from a date just prior to the filing date
`
`of Leaf (March 26, 1996, Ex. 1060 at 1) to the date of Patent Owner’s constructive
`
`reduction to practice (April 23, 1996, Ex. 1001 at 1). To do so, Patent Owner must
`
`prove a continuous exercise of reasonable diligence. Microsoft Corp. v. Surfcast,
`
`Inc., IPR2013-00292, Paper 93 at 17-18 (Oct. 14, 2014). Even a short period of
`
`unexplained inactivity is sufficient to defeat a claim of reasonable diligence. See,
`
`e.g., In re Mulder, 716 F.2d 1542, 1542–46 (Fed. Cir. 1983).
`
`Patent Owner’s only evidence of activity during the critical period is Ex.
`
`
`
`
`
`Petitioner’s Reply for IPR2015-00483
`
`2099, which bears dates of April 2-4, 1996, and paragraph 42 of inventor Lowery’s
`
`declaration (Ex. 2092) summarily describing Ex. 2099. Thus, Patent Owner fails
`
`to provide any evidence of diligence for the vast majority of the critical period.
`
`And even as to Ex. 2099, it provides no relevant evidence of diligence, since that
`
`document only describes software related to help pages. Ex. 1085 (Lowery Dep
`
`Tr.) 65:21 – 66:14. The claims against which Leaf has been applied have nothing
`
`to do with help page software and Patent Owner does not even attempt to relate the
`
`disclosure of Ex. 2099 to any of those claims. See, e.g., Ex. 2092 ¶ 42.
`
`No Corroboration. Patent Owner also failed to corroborate its evidence of
`
`conception and diligence. The only testimony provided on those issues comes
`
`from Messrs. Lowery and Howell, both of whom are inventors of the 554 Patent,
`
`which is insufficient for corroboration as a matter of law, Price v. Symsek, 988
`
`F.2d 1187, 1194-95 (Fed. Cir. 1993); Medichem, S.A. v. Rolabo, S.L., 437 F.3d
`
`1157, 1171 (Fed. Cir. 2007). Patent Owner also cites various exhibits (to which
`
`Petitioner has objected, Paper 29 at 1-3) as corroborating, Resp. at 5-12, 49-50, but
`
`only attempts to authenticate those documents with inventor testimony, 483 Paper
`
`32 at 1-2. “Inventor testimony is not sufficient to authenticate a document offered
`
`to corroborate the inventor’s testimony.” Microsoft Corp. v. SurfCast, Inc.,
`
`IPR2013-00292, Paper 93 at 16. Nor can the inventors corroborate the dates on the
`
`documents Patent Owner relies on for these issues. Garmin Int’l Inc. v. Cuozzo
`
`2
`
`
`
`Petitioner’s Reply for IPR2015-00483
`
`Speed Techs. LLC, IPR2012-00001, Paper 59 at 22.
`
`II. THE CLAIMS ARE UNPATENTABLE
`The Petitions and accompanying expert declaration principally analyzed
`
`patentability using the broadest reasonable interpretation but also alternatively
`
`analyzed patentability using Patent Owner's Phillips constructions, supporting the
`
`unpatentability of the claims under either standard. See, e.g., Ex. 1007, ¶¶ 90-91,
`
`160. Patent Owner’s Response does not take issue with most of the Phillips
`
`constructions, and for the few that it did offer differing constructions, they do not
`
`alter the outcome. Ex. 1083 (Mitzenmacher Reply Decl.), ¶¶ 8-24.
`
`SWEB95 Routes and Processes The Same Request (All Claims)
`
`A.
`A Redirected Request Is The Same Request. Patent Owner’s principal
`
`argument is that, while the claims require a single request “to be received,
`
`intercepted, routed, dispatched and processed,” SWEB95 supposedly “requires
`
`multiple requests from the Web client for a single dynamic web page.” Resp. at
`
`22. Patent Owner's argument misunderstands the claims at issue and the disclosure
`
`of SWEB95. While SWEB95’s system (using conventional HTTP techniques, Ex.
`
`1009 at 10, Ex. 1083, ¶¶ 28-31) sends multiple transmissions to ultimately obtain
`
`the generation of a dynamic Web page, those transmissions each include the same
`
`request, as demonstrated below.
`
`Each independent claim recites “a dynamic Web page generation request.”
`
`3
`
`
`
`Petitioner’s Reply for IPR2015-00483
`
`Ex. 1001, cls. 12, 20, 32, 34, 46, 48. None requires a particular format of request
`
`or that the request is transmitted once in only a single packet. Indeed, the
`
`specification explains that the request exists before it is ever placed in a packet or
`
`transmitted. Ex. 1001 at 4:12-17; Ex. 1083, ¶14. The 554 Patent further explains
`
`that “the request” is communicated among various system elements (Web server,
`
`interceptor, dispatcher, page server) that may exist on the same or different
`
`physical machines, Ex. 1001 at 4:59-62, 5:20-21, confirming that in the disclosed
`
`system the request could be conveyed in different formats using different
`
`communications protocols, and still be the same request. Ex. 1083, ¶ 15. Thus, in
`
`the described system “the request” is not a particular packet or transmission, but
`
`the “ask” or “demand” for a particular Web page, which is passed among the
`
`system elements using different transmission techniques of differing formats.
`
`This understanding is confirmed by the ordinary usage in the field. For
`
`example, the HTTP specification of February 1996 (Ex. 2010) characterizes a
`
`redirected request as the same request as in the original transmission, Ex. 2010 at 6
`
`(referring to “forwarding the reformatted request”); at 27 (noting the redirection
`
`status codes “indicate[] that further action needs to be taken by the user agent in
`
`order to fulfill the request.”), and that a rewritten or translated request can be
`
`communicated among various network elements and remain the same request, Ex.
`
`2010 at 6; Ex. 1083, ¶¶ 13-17. Various papers and patents in the field confirm this
`
`4
`
`
`
`Petitioner’s Reply for IPR2015-00483
`
`conclusion. E.g., Ex. 1043 at 52 (“The client then automatically retransmits its
`
`request, but uses the new URL this time.”); see also Ex. 1012 at 4; Ex. 1087 at
`
`523; Ex. 1088 at 1. Indeed, if the technique were directed to something other than
`
`the original request it would not be called “redirection”. Ex. 1083, ¶ 18, 27. Thus,
`
`the person of ordinary skill in the art at the time of the invention (“Average
`
`Artisan”), applying the ordinary meaning of “request,” would have understood that
`
`a redirected HTTP transmission includes the same request as the original HTTP
`
`transmission.1 Ex. 1083, ¶¶ 13-18.
`
`Under this ordinary meaning of the claim language, SWEB95 discloses a
`
`single request that satisfies the various steps of the claims, since the same “ask” or
`
`“demand” for a Web page received and intercepted by the first Web server is
`
`routed and dispatched by that server, through the mechanism of URL redirection,
`
`to the server that eventually processes it. Ex. 1083, ¶¶ 28-34. For example, in its
`
`description of routing via redirection SWEB95 expressly shows a request for the
`
`exact same file – designated “myfile” – in both the original and redirected
`
`transmission. See Ex. 1009 at Fig. 6. Moreover, SWEB95 consistently refers to a
`
`
`
`1 To the extent Patent Owner claims Petitioner's expert testified otherwise, that
`
`mischaracterizes the testimony, which simply explained that HTTP transmissions
`
`require the exchange of multiple messages of different types. Ex. 1083, ¶ 23.
`
`5
`
`
`
`Petitioner’s Reply for IPR2015-00483
`
`request originally received at one server (Web server S0) as the same request
`
`redirected to a second server (page server S1) for processing. E.g., Ex. 1009 at 9
`
`(“After a request is routed to a processor via DNS, the scheduler in that processor
`
`makes a decision regarding whether to process this request or redirect it to another
`
`processor.”) (emphasis added); see also id. at 10, 12 & 15. Thus, a person of
`
`ordinary skill in the art, applying the ordinary meaning of “request,” would
`
`understand SWEB95 to disclose that the same request is received, intercepted,
`
`routed and dispatched by Web server S0, and then processed by page server S1.
`
`Ex. 1083, ¶¶ 28-34.
`
`Indeed, the Board’s own reading of SWEB95 came to this same conclusion.
`
`Paper 10 at 18 (“As disclosed by SWEB 95, for a single request, there is a server
`
`which receives the request (S0) and a server which locates or generates a Web
`
`page (S1).) (emphasis added).
`
`Patent Owner's proposed construction – that “request” be construed to mean
`
`“a message that asks for a Web page” – does not contradict that conclusion. Resp.
`
`at 22. The construction does not require a message of any particular format or
`
`require any specific information beyond that a particular Web page is sought. Nor
`
`does the construction preclude the same message from being placed in multiple
`
`transmissions or packets and redirected to additional servers at different times. All
`
`that is required is a message that asks for a Web page, and since the message of a
`
`6
`
`
`
`Petitioner’s Reply for IPR2015-00483
`
`redirected HTTP transmission (“get myfile”) is the same as the message of the
`
`original HTTP transmission (“get myfile”), Ex. 1083, ¶¶ 26, 31, Patent Owner’s
`
`construction reads squarely on the redirection technique disclosed in SWEB95.
`
`Patent Owner advances no evidence to contradict these conclusions because
`
`it and its expert read the claims as if they recited a particular HTTP request or
`
`packet, rather than “a dynamic Web page generation request.” See Resp. at 24; Ex.
`
`2091, ¶¶ 70-77. But the claims are not so narrow, and Patent Owner’s argument
`
`ignores that both the original and redirected HTTP transmissions contain the same
`
`message asking for a Web page, and therefore the same request. Ex. 1083, ¶¶ 31,
`
`36. Thus, even under Patent Owner’s Phillips construction, SWEB95 discloses a
`
`single request that is “received, intercepted, routed, dispatched and processed”.
`
`Redirection is Routing. Patent Owner also argues that SWEB95’s
`
`redirection technique is not “routing” as claimed, asserting that “the claim term
`
`‘routing’ requires the Web server to send or transfer the request to the page
`
`server,” Resp. at 29, and that such redirection simply sends a response back to the
`
`client without an intent to transfer anything to the page server, see id. at 28-29.
`
`But Patent Owner’s argument is again based on the erroneous assumption that “the
`
`request” that must be routed is the actual packet received by the Web server, rather
`
`than the message asking for a Web page, so it again misses the mark.
`
`7
`
`
`
`Petitioner’s Reply for IPR2015-00483
`
`Moreover, to the extent Patent Owner seeks an interpretation that excludes
`
`redirection, such an interpretation would be incorrect, since the ordinary meaning
`
`of “routing” covers redirection and nothing in the patent suggests a special
`
`meaning for that term was intended. Ex. 1083 at ¶¶ 34-39. For example, SWEB95
`
`expressly characterizes its redirection as a form of routing, noting that “this request
`
`needs to be transparently routed to this processor. … The approach that we
`
`eventually decided to implement is based on the fact that the HTTP protocol allows
`
`for a response called ‘URL Redirection’”. Ex. 1009 at 10. And the ordinary usage
`
`of the term “routing” from the time period was understood to cover redirection.
`
`Ex. 1091 at 7:16-19 (“routing can still be done on the HTTP requests by using
`
`HTML redirection.”); Ex. 1092 at 10 (“The two main classes of routing are through
`
`a packet rewriting mechanism or HTTP redirection.”); Ex. 1083, ¶31-34.
`
`Indeed, as early as 1999, inventor Lowery confirmed that “the patent covers
`
`the notion of redirecting that request to other machines,” Ex. 1089 at 1, as his co-
`
`inventor Howell conceded on cross-examination in this proceeding, Ex. 1086,
`
`Howell Tr. at 12:8-11 (Q. “One way the inventions claimed in the ’554 and ’335
`
`patents route requests to other servers is redirection; is that correct? A. Yes.”).
`
`Patent Owner has said the same in demand letters to accused infringers, Ex. 1090
`
`at 3, and its expert has testified in district court proceedings that modifying a URL
`
`included in the request, as is done for redirection, “is not going to make that a
`
`8
`
`
`
`Petitioner’s Reply for IPR2015-00483
`
`request for something else,” Ex. 1097 (Jones Dep. Tr.) at 58:8-24.
`
`Thus, the ordinary meaning of “routing” encompasses redirection, so the
`
`Board’s interpretation must as well. To the extent Patent Owner’s formal proposed
`
`interpretation (Resp. at 16) does not, it should be rejected and “routing” should be
`
`construed to mean what both parties agree it must: “send[ing] or transfer[ring] the
`
`request to the page server.” Resp. at 29 (“However construed ….”).
`
`Under the proper interpretation of the claims, SWEB95 discloses the
`
`claimed routing because redirection sends/transfers the message received by the
`
`initial server (Web server S0) to the server that will eventually fulfill it (page
`
`server S1). Ex. 1083, ¶¶ 13-22, 26-42; Ex. 1009 at 10-11; see also Ex. 1012 at 4
`
`(noting that URL redirection is a way to “redirect a client's request to another
`
`server.”) Thus, SWEB95’s URL redirection does “send or transfer the request to
`
`the page server,” as Patent Owner argues is required for routing. Ex. 1083, ¶ 41.
`
`Against this explicit evidence of the ordinary meaning of “routing” and how
`
`SWEB95 discloses it, Patent Owner cites three paragraphs of its expert’s testimony
`
`and no objective sources of evidence. See Resp. at 28, citing Ex. 2091, ¶¶ 78-80.
`
`The expert’s testimony, however, is simply ipse dixit, noting only that the
`
`redirection response is sent to the client and stating, without any explanation or
`
`support whatsoever, that “SWEB95 does not disclose ‘routing’ as that term is used
`
`in the ‘554 patent.” Ex. 2091, ¶ 79. Such naked assertions of fact cannot support
`
`9
`
`
`
`Petitioner’s Reply for IPR2015-00483
`
`the Board’s fact-finding, Cadiocom, LLC v. Robert Bosch Healthcare Sys., Inc.,
`
`IPR2013-00451, Paper 65 at 28-29 (Jan. 15, 2015), and do not constitute a
`
`preponderance of the evidence, particularly in view of the substantial evidence
`
`advanced by Petitioner, 37 C.F.R. § 42.65(a) (unsupported expert testimony may
`
`be given little to no weight).
`
`Obviousness. The Petitions also demonstrated that it would have been
`
`obvious to include other routing functionality in the scheme of SWEB95, such as
`
`request forwarding, and that the known efficiency obtained from that technique
`
`provided a motivation to employ it. 483 Pet. at 42-43. A SWEB95 system
`
`modified to include request forwarding would indisputably be receiving,
`
`intercepting, routing, dispatching and processing the same request, and so satisfy
`
`all elements of the claims, even if one were to accept Patent Owner’s arguments
`
`refuted above. Ex. 1083, ¶ 42.
`
`In response, Patent Owner argues that the Average Artisan would not have
`
`been motivated to modify SWEB95 to include request forwarding because
`
`“SWEB95 is predicated explicitly on URL redirection” and to do so “would
`
`fundamentally alter the entire described system….” Resp. at 41. Patent Owner
`
`again cites absolutely no evidence to support its sweeping statements. See id. Its
`
`unsupported lawyer argument should therefore be rejected, Silergy Corp., v.
`
`Monolithic Power Sys., Inc., IPR2015-00803, Paper 9 at 20 (Sept. 11, 2015), and
`
`10
`
`
`
`Petitioner’s Reply for IPR2015-00483
`
`cannot overcome Petitioner’s substantial evidence of motivation to combine, Ex.
`
`1007, ¶ 214; Ex. 1036 at 9; Ex. 1037 at 226-28; Ex. 1012 at 1; Ex. 1009 at 2.
`
`Moreover, neither Patent Owner nor its expert even attempt to dispute that
`
`request forwarding was known in the prior art, Ex. 1007, ¶ 214; Ex. 1036 at 207-
`
`208; Ex. 1037 at 78, 226-228; Ex. 1012 at 8, was known to provide efficiencies,
`
`Ex. 1007, ¶ 214; Ex. 1036 at 9; Ex. 1037 at 226-228; Ex. 1012 at 1, and was well
`
`within the level of skill of the Average Artisan, Ex. 1007, ¶ 214; Ex. 1036 at 9; Ex.
`
`1037 at 226-228; Ex. 1012 at 1. That the system of SWEB95 would have to be
`
`modified to include request forwarding does not show non-obviousness where, as
`
`here, such modifications were within the level of ordinary skill. Ex. 1007, ¶ 214;
`
`KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398, 420 (2007) (“[I]n many cases a person
`
`of ordinary skill will be able to fit the teachings of multiple patents together like
`
`pieces of a puzzle.”).
`
`Patent Owner also argues that SWEB95’s statement that an alternative
`
`routing technique disclosed in SWEB95, which envisioned modifying the Unix
`
`kernel, was “not a trivial undertaking and would likely be far beyond any person of
`
`ordinary skill in the art.” Resp. at 29-30. This argument is also unsupported by
`
`citation to evidence, see id, but is irrelevant, since Petitioner’s obviousness
`
`argument here is based on the use of the known technique of request forwarding
`
`and not on any modification of the Unix kernel. 483 Pet. at 42-43.
`
`11
`
`
`
`Petitioner’s Reply for IPR2015-00483
`
`B.
`SWEB95 Uses Dynamic Page Server Information (All Claims)
`Anticipation. Patent Owner argues that SWEB95 does not satisfy the claim
`
`language requiring selection of a page server based on “examining dynamic
`
`information regarding a load associated with each of said plurality of page servers”
`
`because SWEB95's servers function as both “Web servers” and “page servers” for
`
`different requests and that the dynamic load information used by SWEB95 is
`
`therefore supposedly not “page server specific.” Resp. at 31-32.
`
`The claims, however, do not require the use of information that is “page
`
`server specific,” whatever that means. They require only the use of load
`
`information associated with or from each of the page servers. Ex. 1001, cls. 12,
`
`20, 32, 34, 46, 48. SWEB95 indisputably employs such load information. Ex.
`
`1009 at 13 (tCPU based on CPUload, no. of operations required, and CPU speed); see
`
`also 483 Pet. at 31, 36-37, 40-42, 48; 484 Pet. at 31, 33. Moreover, to the extent
`
`Patent Owner intends “page server specific” to mean that only load information for
`
`page server functionality can be considered, the claims are not so limited. Ex.
`
`1083, ¶ 43.
`
`Obviousness. The Petitions also demonstrated that it would have been
`
`obvious to examine dynamic load information from page servers. 483 Pet. at 48;
`
`484 Pet. at 47-48. In response, Patent Owner asserts, without citation to evidence
`
`or explanation, that the Average Artisan would not have been motivated to employ
`
`12
`
`
`
`Petitioner’s Reply for IPR2015-00483
`
`such functionality in SWEB95 because the SWEB servers are “functionally
`
`equivalent.” Resp. at 42-43. Such unsupported lawyer argument cannot support
`
`the Board’s fact finding, or overcome the contrary evidence submitted by
`
`Petitioner. E.g., Ex. 1007, ¶ 251. Moreover, the functional equivalence of the
`
`SWEB servers has nothing to do with whether the Average Artisan would be
`
`motivated to examine page server load information. Ex. 1083, ¶ 44.
`
`C.
`SWEB95’s Page Servers Release The Web Server (All Claims)
`Anticipation. Patent Owner also argues that the SWEB95 page server does
`
`not “release” the Web server, asserting that there must be some type of relationship
`
`between the receipt of the request by the page server and the release of the Web
`
`server, though Patent Owner never explains what type of relationship is supposedly
`
`required by the claims. Resp. at 32-33. But neither the claims nor Patent Owner’s
`
`proposed construction of the “releasing” language require any such relationship or
`
`affirmative separate act to accomplish the releasing, Ex. 1001, cls. 12, 20, 32, 34,
`
`46, 48; Resp. at 15-16, and Patent Owner’s expert conceded on cross that under
`
`that construction the releasing limitation is satisfied when the "page server receives
`
`and handles said request, thereby freeing the Web server to handle other requests,"
`
`Ex. 1084, 12:16-23; see also id., 11:25 – 21:10. Indeed, the district court agreed
`
`that this same construction “means no more than that the page server handles
`
`requests, thereby freeing the Web server to handle other requests.” Ex. 2090 at 2-3
`
`13
`
`
`
`Petitioner’s Reply for IPR2015-00483
`
`n.1 (emphasis added); see also Ex. 1025 at 17. SWEB95 indisputably discloses
`
`such functionality. See, e.g., 483 Pet. at 26-27; Ex. 1083, ¶¶ 45-49.
`
`Obviousness. The Petitions also demonstrated it would have been obvious
`
`to release the SWEB95 Web server. 483 Pet. at 13-14. In response, Patent Owner
`
`implicitly admits that SWEB95 discloses releasing, Resp. at 43 (“…SWEB 95’s
`
`‘releasing’ is accomplished …”), but believes that modifying SWEB95 to include
`
`the type of releasing Patent Owner asserts is required by the claim “may not even
`
`have been possible for one of ordinary skill in the art” and “would likely be far
`
`beyond any person of ordinary skill in the art.” Id. However, Patent Owner again
`
`cites to no evidence to support its factual assertions, see id., leaving Petitioner’s
`
`evidence that SWEB95 could be so modified and that there was a motivation to do
`
`so, e.g., Ex. 1007, ¶¶ 215-17, as the unrebutted preponderance of the evidence.
`
`D. Claim 15 (Connection Cache) Is Unpatentable
`Anticipation. Patent Owner argues that the construction of “connection
`
`cache” should be “a stored pool of connections between a page server and one or
`
`more data sources” and asserts the NFS mounts disclosed in SWEB95 do not
`
`satisfy that construction. Resp. at 17, 33-34. The phrase “a stored pool of
`
`connections” is not supported by anything in the intrinsic record and the passages
`
`Patent Owner cites state only that the system includes a cache of connections. See
`
`id. at 17; Ex. 1083, ¶ 12. The proposed construction is also inconsistent with the
`
`14
`
`
`
`Petitioner’s Reply for IPR2015-00483
`
`Phillips construction Patent Owner proposed in parallel litigation: “a store of
`
`information identifying active connections,” Ex. 1093 at 52 (emphasis added), and
`
`neither Patent Owner nor its expert provide any explanation of why the extrinsic
`
`“stored pool” language should now be imported. Resp. at 17; Ex. 2091, ¶ 41.
`
`Nor does Patent Owner or its expert dispute Petitioner’s evidence of
`
`ordinary meaning, Ex. 1058 at 7:42-59; Ex. 1059 at 2, that the ordinary meaning of
`
`“connection cache” is stored information for allowing persistent and reusable
`
`connections to a data source, Ex. 1007, ¶¶ 148-149, or that such an ordinary
`
`meaning is consistent with the intrinsic record, Ex. 1007, ¶ 150.
`
`Similarly, Patent Owner’s purported evidence that NFS mounts do not
`
`constitute a connection cache consists solely of its expert’s unsupported and
`
`unexplained statement that “each time NFS is used a new connection needs to be
`
`opened.” Ex. 2091 at ¶ 83. Such ipse dixit expert testimony cannot support the
`
`Board’s fact-finding, Cadiocom, supra, nor overcome Petitioner’s evidence
`
`otherwise, Ex. 1007, ¶¶ 274-76; Ex. 1042 at 3, 21, 109; Ex. 1041 at 1; Ex. 1017 at
`
`470-73. Thus, on this record Patent Owner’s proposed construction, and its
`
`patentability argument based thereon, must be rejected.
`
`In any event, SWEB95’s disclosure of NFS mounts satisfies Patent Owner’s
`
`construction. NFS mounts do maintain connections to the mounted file systems,
`
`E.g., Ex. 1017 at 473 (explaining that TCP connection is established, "[b]oth the
`
`15
`
`
`
`Petitioner’s Reply for IPR2015-00483
`
`client and server set TCP's keepalive option on their ends of the connection" and
`
`"[a]ll applications on the client that use this server's filesystem share the single
`
`TCP connection"), so those connections are “a stored pool of connections between
`
`a page server and one or more data sources.” Ex. 1083, ¶ 54.
`
`Obviousness. The Petition also demonstrated it would have been obvious to
`
`maintain a connection cache in the system of SWEB95. 483 Pet. at 49-50. In
`
`response, Patent Owner asserts that SWEB95 does not propose using a connection
`
`cache to reduce response time. Resp. at 44 (“…nowhere in the reference is
`
`connection caching pointed to as the means for solving this problem.”). But that is
`
`not an argument for nonobviousness. Eisai Co. Ltd. v. Dr. Reddy's Labs., Ltd., 533
`
`F. 3d 1353, 1357 (Fed. Cir. 2008) (“[T]he requisite motivation can come from any
`
`number of sources and need not necessarily be explicit in the art.”).
`
`Patent Owner also asserts “Microsoft identifies no place where Ex. 1061
`
`[Mogul] even addresses connections between the Web server and a page server”
`
`(Resp. at 45), which is irrelevant, since the Petition proposed the use of a known
`
`connection cache, as evidenced by Leaf (Ex. 1060), with the Web server and page
`
`servers of SWEB95 (483 Pet. at 56-57). Moreover, Patent Owner does not dispute
`
`what the Petitions cited Mogul as evidence of: that maintaining a connection cache
`
`to a data source, and the advantages of doing so, were known. See 483 Pet. at 49-
`
`50; Resp. at 45. Patent Owner also argues that Ex. 1060 (Leaf) discloses only one
`
`16
`
`
`
`Petitioner’s Reply for IPR2015-00483
`
`connection and does not disclose a “data structure” associated with the
`
`connections. Resp. at 45-46. But the claim language does not require multiple
`
`anything (“maintaining a connection cache to said one or more data sources,” Ex.
`
`1001 cl. 15) and recites no structure other than a “cache”. Ex. 1083, ¶ 57.
`
`Moreover, Leaf discloses one cached connection per instance of its transaction
`
`gateway client, so it does disclose multiple cached connections. Ex. 1060 at 6:49-
`
`56, Fig. 3; Ex. 1083, ¶ 56. Finally, Patent Owner does not dispute that connection
`
`caches were known, were understood to be advantageous in many situations, and
`
`that a motivation to use them existed, e.g., Ex. 1007, ¶ 277; see Resp. at 45-46.
`
`E. Claim 16 (Logging Into A Data Source) Is Unpatentable
`Anticipation. The Petitions and supporting evidence demonstrated that
`
`SWEB95's use of NFS mounts satisfies the “logging in” limitation of claim 16
`
`because NFS supported “authentication” of the connections and “include[d] a slot
`
`for authentication parameters on every call.” 483 Pet. at 34-35 (emphasis added).
`
`Patent Owner does not attempt to refute this evidence; instead asserting, without
`
`citation of its own evidence, that authentication is not “required for a NFS mount.”
`
`Resp. at 34. But the undisputed evidence shows that authentication is “required”
`
`because “every call” includes “authentication parameters.” Ex. 1007, ¶ 283.
`
`Obviousness. As to obviousness, Patent Owner argues that SWEB95 does
`
`not (i) disclose the use of user identification and passwords to access data, or (ii)
`
`17
`
`
`
`Petitioner’s Reply for IPR2015-00483
`
`state that security was a concern. Resp. at 46. But those arguments are irrelevant,
`
`since Petitioner’s undisputed evidence showed such logging in was known in the
`
`art and the security it provided motivated its use, even if SWEB95 does not
`
`explicitly say so. E.g., Ex. 1007, ¶ 285; Ex. 1039 at 248; Ex. 1038 at 12.
`
`F. Claims 17, 29, 43, 49 (Page Cache) Are Unpatentable
`Anticipation. Patent Owner contends that SWEB95 does not disclose the
`
`page cache requirements of claim 17, because the “HTML files” stored in the
`
`SWEB system are supposedly not dynamically-generated files. Resp. at 34-35. It
`
`also asserts, without citation of any evidence or explanation, that the similar
`
`requirements of claims 29 and 43 are not disclosed because “[t]here is no
`
`discussion of caching” in SWEB95. Id. at 35.
`
`However, SWEB95 discloses storage subsystems “in which HTML files are
`
`stored,” Ex. 1009 at 6 (emphasis added), and Patent Owner has no evidence to
`
`dispute such storage constitutes a cache, Resp. at 34-35; Ex. 1007 at ¶ 290; Ex.
`
`1083, ¶ 61. Moreover, Patent Owner cites no evidence for the assumption that the
`
`cached “HTML files” of SWEB95 are only static Web pages. Its expert conceded
`
`the Average Artisan “understood that HTML files could be static or dynamically-
`
`generated,” Ex. 1084 at 11:12-24, confirming that the Average Artisan would
`
`understand SWEB95’s disclosure to include the caching of dynamically generated
`
`Web pages. Ex. 1083, ¶ 61. Patent Owner also cites no evidence to dispute that
`
`18
`
`
`
`Petitioner’s Reply for IPR2015-00483
`
`SWEB95 considers whether a Web page is cached in determining whether to
`
`choose a particular SWEB server. Resp. at 35. As demonstrated in the Petitions,
`
`484 Pet. at 40, SWEB95 considers processing time and file locality when choosing
`
`servers, Ex. 1009 at 6, 12-14; Ex. 1007, ¶¶ 384, 478.
`
`Obviousness, SWEB95 Alone or With Bradley. Patent Owner argues,
`
`without citation fo evidence or explanation, that SWEB95 “teaches away from the
`
`use of caches when dynamically generated Web pages are used,” apparently taking
`
`issue with SWEB95’s statement that “[t]he Harvest project [BD94] has introduced
`
`a HTTP cache which can be a major accelerator for pages without a dynamically
`
`created component”. Resp. at 46-47 (emphasis added).
`
`Far from teaching away, the statement that a caching technique “can be a
`
`major accelerator” is an express motivation to use that technique with SWEB95,
`
`even for pages with a dynamically generated component to be accessed later, as
`
`Petitioner’s expert confirmed, Ex. 1007, ¶ 292, and Patent Owner cites no evidence
`
`to dispute. Indeed, the use of caching with dynamically generated Web pages
`
`would have been even more advantageous, since it would have avoided the
`
`processing required to generate the page, Ex. 1083, ¶¶ 65-66, and SWEB95 already
`
`explicitly considers the processing time when choosing the server. Ex. 1009 at 13.
`
`Regarding SWEB95 + Bradley, Patent Owner asserts, without citation to
`
`evidence, that “Bradley does not disclose a page cache maintained on a page server
`
`19
`
`
`
`Petitioner’s Reply for IPR2015-00483
`
`… an
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
