throbber
NON-PUBLIC VERSION – PROTECTIVE ORDER MATERIAL
`Trials@uspto.gov
`
`Paper 50
`571-272-7822
`
`Filed: October 16, 2019
`
`
`
`
`
`
`
`
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`ZSCALER, INC.,
`Petitioner,
`v.
`SYMANTEC CORPORATION,
`Patent Owner.
`
`IPR2018-00913
`Patent 8,316,429 B2
`
`
`Before NEIL T. POWELL, DANIEL N. FISHMAN, and MINN CHUNG,
`Administrative Patent Judges.
`
`FISHMAN, Administrative Patent Judge.
`
`
`JUDGMENT
`Final Written Decision
`Determining All Challenged Claims Unpatentable
`35 U.S.C. § 318(a)
`
`
`
`
`
`
`NON-PUBLIC VERSION – PROTECTIVE ORDER MATERIAL
`
`
`

`

`IPR2018-00913
`Patent 8,316,429 B2
`
`INTRODUCTION
`I.
`A. Background and Summary
`Zscaler, Inc. (“Petitioner”) filed a Petition (Paper 1, “Petition” or
`“Pet.”) requesting inter partes review of claims 10–12 (the “challenged
`claims”) of U.S. Patent No. 8,316,429 B2 (“the ’429 patent,” Ex. 1001)
`pursuant to 35 U.S.C. §§ 311 et seq. Symantec Corporation (“Patent
`Owner”) filed a Preliminary Response. Paper 10 (“Prelim. Resp.”).
`On October 17, 2018, based on the record before us at that time, we
`instituted an inter partes review of all challenged claims on all grounds of
`unpatentability asserted in the Petition. Paper 13 (“Decision on Institution”
`or “Dec. on Inst.”).
`Patent Owner filed a Response (Paper 17, “PO Resp.”), Petitioner
`filed a Reply (Paper 26, “Reply”), and Patent Owner filed a Sur-Reply
`(Paper 35, “Sur-Reply”). 1
`The parties filed several unopposed motions to seal various papers and
`exhibits to protect alleged confidential information. See Papers 16, 25, 34,
`42, 44, 47. We address these motions below.
`Upon consideration of the complete record, we determine by a
`preponderance of the evidence that claims 10–12 are unpatentable.
`B. Real Parties in Interest
`Petitioner identifies Zscaler, Inc. as the sole real party in interest for
`Petitioner. Pet. 2. Patent Owner identifies Symantec Corporation and
`
`
`1 Patent Owner also filed a redacted version of its Response (Paper 18) and a
`redacted version of its Sur-Reply (Paper 36), and Petitioner filed a redacted
`version of its Reply (Paper 27), the redacted versions filed to protect alleged
`confidential information.
`
`2
`
`

`

`IPR2018-00913
`Patent 8,316,429 B2
`Symantec Limited as the real parties in interest for Patent Owner. Paper 6,
`2.
`
`C. Related Matters
`The parties inform us that the ’429 patent is presently asserted against
`Petitioner in the following litigation: Symantec Corp. v. Zscaler, Inc., Case
`No. 3:17-cv-04414-JST (N.D. Cal.) (transferred from 1:17-cv-00806-MAK
`in the District of Delaware). Pet. 2; Paper 6, 2. Petitioner further identifies
`two other inter partes reviews directed to claims of other patents of Patent
`Owner as well as a second petition challenging claims 1–9 and 13–17 of the
`’429 patent. Pet. 3 (citing Cases IPR2018-00616, IPR2018-00806, and
`IPR2018-00912). Petitioner also identifies another litigation involving other
`patents of Patent Owner (Symantec Corp. v. Zscaler, Inc., 17-cv-04426
`(N.D. Cal.) (transferred from 16-cv-01176 in the District of Delaware)).
`Patent Owner further identifies litigation 1:17-cv-00432-VAC-SRF
`involving the ’429 patent and IPR2018-00912 requesting review of certain
`claims of the ’429 patent. Paper 6, 2.
`D. The ’429 Patent
`The ’429 patent discloses that firewalls are common in computing
`networks to implement policies that determine which network traffic can
`pass between two network systems by blocking certain exchanges when one
`or more policies applicable to the information to be exchanged are not met.
`Ex. 1001, 1:14–22. Such firewalls are often implemented in a proxy server
`intermediate between two networks attempting to exchange information. Id.
`at 1:23–24. The firewall/proxy server intercepts information to be
`exchanged and examines the information to evaluate it against firewall
`rules/policies to determine whether the exchange should be allowed. Id. at
`1:30–34.
`
`3
`
`

`

`IPR2018-00913
`Patent 8,316,429 B2
`According to the ’429 patent, some applications, such as banking or e-
`commerce over the Internet, encrypt the information exchanges to protect
`sensitive information. Id. at 1:34–40. The ’429 patent explains that such
`encrypted communications usually cannot be read by the firewall and, thus,
`cannot be evaluated against rules/policies of the firewall to determine
`whether to allow or block the exchange. Id. at 1:41–50. According to the
`’429 patent, one possible solution is to permit the proxy to decrypt the
`encrypted communications and then evaluate the decrypted communication
`against the firewall policies. Id. at 1:51–55. The ’429 patent notes that such
`a solution is undesirable because, once decrypted, the communications could
`be attacked to improperly obtain private information (such as banking
`information of a customer). Id. at 1:55–2:3.
`The ’429 patent purports to address these security needs by
`intercepting secure (encrypted) communications and evaluating the
`intercepted information with respect to policies of the firewall without
`decrypting the communications. Id. at 2:30:39. Specifically, in an
`embodiment of the ’429 patent, a Uniform Resource Locator (“URL”) of a
`host computer involved in a communication is extracted from a digital
`certificate associated with the host, and the host is categorized based on the
`extracted URL. Id. at 2:30–33. The ’429 patent discloses an embodiment in
`which systems communicate using the Secure Socket Layer (“SSL”)
`standard protocol. See id. at 1:6–10. Figure 1 of the ’429 patent is
`reproduced below.
`
`4
`
`

`

`IPR2018-00913
`Patent 8,316,429 B2
`
`
`Figure 1 shows a conventional SSL handshake protocol between a
`client and a server, as known in the art. Id. at 3:11–12. Client 100 initiates a
`secure connection by sending client hello message 104 to server 102, which
`responds with server hello message 106. Id. at 4:40–43. Server hello
`message 106 includes server certificate 108. Id. at 4:45–48. In an
`embodiment, “[t]he present invention makes use of information in the
`Certificate Info field of the server’s digital certificate to identify the host the
`client is contacting and, based on that identification, determine whether or
`not SSL communications may be passed encrypted through a firewall at a
`proxy.” Id. at 5:34–38.
`
`5
`
`

`

`IPR2018-00913
`Patent 8,316,429 B2
`Figure 3 of the ’429 patent is reproduced below.
`
`
`Figure 3 depicts proxy/firewall 306 according to an embodiment of
`the ’429 patent that extracts information from a digital certificate used to
`decide whether to allow client 302 to communicate with server 312. Id. at
`
`6
`
`

`

`IPR2018-00913
`Patent 8,316,429 B2
`3:15–19. In the exemplary embodiment of Figure 3, client 302 attempts to
`communicate with server 312 through intermediate proxy/firewall 306. See
`id. at 6:17–7:28. Client 302 initiates an SSL connection with server 312 by
`sending client hello message 314, which is received by proxy/firewall 306.
`Id. at 6:39–42. Proxy/firewall 306 then sends its own proxy hello message
`316 to server 312 to which server 312 responds with server hello message
`318 that includes certificate 320. Id. at 7:10–19. Proxy/firewall 306 then
`extracts information 322 (URL 324) from certificate 320 to identify server
`312. Id. at 7:20–23. Proxy/firewall 306 uses URL 324 to determine
`category 326 for server 312 from URL database 310. Id. at 7:23–28. Based
`on the determined category, “a secure communication session (e.g., an SSL
`session) with said host may be granted or denied.” Id. at 2:33–35.
`In an embodiment, the invention may use information from a referrer
`header in categorizing a URL to determine whether secure communications
`may be allowed. Id. at 8:4–11. According to the ’429 patent, a web page
`may embed links/references to still other resources (e.g., other URLs and
`web pages). Id. at 8:12–47. The URL/resource identified in the referrer
`header of an HTTP request, from which the embedded resource is accessed,
`may be used to categorize the embedded resource and determine whether
`secure connections are allowed between the client and the embedded
`resource. Id. at 8:57–9:18.
`E. Illustrative Claim
`Claim 10, the sole independent claim among the challenged claims, is
`illustrative of the claimed subject matter and is reproduced below:
`10. A method, comprising:
`receiving, at a proxy, a client hello message from a client;
`
`7
`
`

`

`IPR2018-00913
`Patent 8,316,429 B2
`transmitting, from said proxy to a referring source of a request
`for an object, a request for a digital certificate associated
`with the referring source;
`categorizing, at the proxy, the referring source of the request for
`the object into one or more content categories, wherein the
`request for the object is made by the client to an Internet
`host and wherein the Internet host is referred to the client
`by the referring source; and
`based on the one or more content categories into which the
`referring source is categorized, determining, at the proxy,
`whether to (i) pass encrypted communication between the
`client and the Internet host through the proxy without
`decrypting the encrypted communication at the proxy or
`(ii) decrypt the encrypted communication between the
`client and the Internet host so as to permit examination of
`the encrypted communication at the proxy.
`Id. at 10:3–20.
`
`F. Prior Art and Asserted Grounds
`Petitioner asserts that the challenged claims would have been
`unpatentable on the following grounds:
`Claims Challenged
`35 U.S.C. §
`10–12
`103(a)
`
`Petitioner also relies on the testimony of Dr. Markus Jakobsson
`(Exs. 1003, 1046) in support of its assertions. Patent Owner relies on the
`
`References
`Levow, 2 Toneguzzo,3 and
`O’Laughlen4
`
`
`2 Levow et al., U.S. Patent Publication No. 2006/0248575 A1 (Ex. 1005,
`“Levow”).
`3 Toneguzzo et al., U.S. Patent Publication No. 2003/0182573 A1 (Ex. 1006,
`“Toneguzzo”).
`4 O’Laughlen et al., U.S. Patent Publication No. 2005/0015442 A1
`(Ex. 1007, “O’Laughlen”).
`
`8
`
`

`

`IPR2018-00913
`Patent 8,316,429 B2
`testimony of Sandeep Chatterjee, Ph.D. (Ex. 2007) in support of its
`assertions.
`
`II. ANALYSIS
`A. Legal Standards
`1. Obviousness
`A patent claim is unpatentable under 35 U.S.C. § 103(a) if the
`differences between the claimed subject matter and the prior art are “such
`that the subject matter[,] as a whole[,] would have been obvious at the time
`the invention was made to a person having ordinary skill in the art to which
`said subject matter pertains.” KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398,
`406 (2007). The question of obviousness is resolved based on underlying
`factual determinations, including (1) the scope and content of the prior art;
`(2) any differences between the claimed subject matter and the prior art;
`(3) the level of skill in the art; and (4) objective evidence of non-
`obviousness, i.e., secondary considerations. Graham v. John Deere Co., 383
`U.S. 1, 17–18 (1966).
`B. Level of Ordinary Skill in the Art
`Petitioner argues a person of ordinary skill in the art related to the
`’429 patent would have a Bachelor’s Degree in computer science, or a
`similar degree, and would also have two to three years of experience in
`“designing and developing Internet content filtering, web security, or
`firewall software programs.” Pet. 15 (citing Ex. 1003 ¶¶ 22–25).
`In our Decision on Institution, we determined the prior art, as well as
`the ’429 patent, require a degree of knowledge that is specific to “Internet
`content filtering, web security, or firewall software programs”—i.e., more
`than mere general knowledge of network security and distributed computing
`systems. Dec. on Inst. 10–11. For example, the ’429 patent discloses an
`
`9
`
`

`

`IPR2018-00913
`Patent 8,316,429 B2
`embodiment based on the exchange of hello messages and their respective
`digital certificates as is known in the SSL protocol but does not fully
`disclose details of that protocol or the hello messages. An ordinarily skilled
`artisan more generally knowledgeable in “network security, distributed
`computing systems, or a related technology field,” as Patent Owner had
`suggested in its proposed definition in the Preliminary Response (Prelim.
`Resp. 9 (citing Ex. 2001 ¶¶ 34–40)), may lack general knowledge of the SSL
`protocol as applied in web-based network exchanges.
`Accordingly, in our Decision on Institution, we adopted Petitioner’s
`definition of the level of ordinary skill in the art and determined that a
`person of ordinary skill in the art at the time of the invention of the ’429
`patent would have had a Bachelor’s Degree in computer science, or a similar
`degree, and would also have had 2–3 years of experience in designing and
`developing Internet content filtering, web security, or firewall software
`programs. Dec. on Inst. 11.
`In its Response, Patent Owner adopts the definition we adopted in the
`Decision on Institution. PO Resp. 6. Accordingly we discern no reason to
`modify our determination regarding the level of ordinary skill in the art, and
`we again determine that a person of ordinary skill in the art at the time of the
`invention of the ’429 patent would have had a Bachelor’s Degree in
`computer science, or a similar degree, and would also have had 2–3 years of
`experience in designing and developing Internet content filtering, web
`security, or firewall software programs.
`
`10
`
`

`

`IPR2018-00913
`Patent 8,316,429 B2
`
`C. Claim Construction
`In an inter partes review filed before the change in the Board’s
`standard of claim construction, 5 as is the case here, a claim in an unexpired
`patent shall be given its broadest reasonable construction in light of the
`specification of the patent in which it appears. 37 C.F.R. § 42.100(b)
`(2017); see also Cuozzo Speed Techs., LLC v. Lee, 136 S. Ct. 2131, 2142–46
`(2016) (upholding the use of the broadest reasonable interpretation
`standard). Under the broadest reasonable interpretation standard, claim
`terms generally are given their ordinary and customary meaning, as would
`be understood by one of ordinary skill in the art in the context of the entire
`disclosure. In re Translogic Tech., Inc., 504 F.3d 1249, 1257 (Fed. Cir.
`2007). “A fundamental rule of claim construction is that terms in a patent
`document are construed with the meaning with which they are presented in
`the patent document. Thus claims must be construed so as to be consistent
`with the specification, of which they are a part.” Merck & Co. v. Teva
`Pharms. USA, Inc., 347 F.3d 1367, 1371 (Fed. Cir. 2003) (citations omitted).
`“[A] claim construction analysis must begin and remain centered on the
`claim language itself . . . .” Innova/Pure Water, Inc. v. Safari Water
`Filtration Sys., Inc., 381 F.3d 1111, 1116 (Fed. Cir. 2004). “Though
`understanding the claim language may be aided by the explanations
`contained in the written description, it is important not to import into a claim
`
`
`5 For petitions filed on or after November 13, 2018, the Board adopted a
`different claim construction standard (namely that applied by the district
`courts in civil actions under 35 U.S.C. § 282(b)). See Changes to the Claim
`Construction Standard for Interpreting Claims in Trial Proceedings Before
`the Patent Trial and Appeal Board, 83 Fed. Reg. 51,340 (Oct. 11, 2018)
`(codified at 37 C.F.R. § 42.100(b) (2019)).
`
`11
`
`

`

`IPR2018-00913
`Patent 8,316,429 B2
`limitations that are not a part of the claim.” SuperGuide Corp. v. DirecTV
`Enters., Inc., 358 F.3d 870, 875 (Fed. Cir. 2004).
`Although the broadest reasonable interpretation standard is broad, the
`Board cannot interpret the words of a claim without regard for the full claim
`language and the written description. See TriVascular, Inc. v. Samuels, 812
`F.3d 1056, 1062 (Fed. Cir. 2016); Microsoft Corp. v. Proxyconn, Inc., 789
`F.3d 1292, 1298 (Fed. Cir. 2015). Our reviewing court has emphasized the
`importance of a patent’s specification as intrinsic evidence for construing
`claim terms. See Phillips v. AWH Corp., 415 F.3d 1303, 1315–17 (Fed. Cir.
`2005) (en banc). “[T]he specification . . . is the single best guide to the
`meaning of a disputed claim term.” Id. at 1314 (quoting Vitronics Corp. v.
`Conceptronic, Inc., 90 F.3d 1576, 1582 (Fed. Cir. 1996)). The court in
`Phillips stated that extrinsic evidence, such as dictionary definitions, may be
`useful, but is unlikely to result in a reliable interpretation of claim scope
`unless considered in the context of the intrinsic evidence. See Phillips, 415
`F.3d at 1319.
`Lastly, only terms that are in controversy need to be construed and
`only to the extent necessary to resolve the controversy. See Wellman, Inc. v.
`Eastman Chem. Co., 642 F.3d 1355, 1361 (Fed. Cir. 2011); Vivid Techs.,
`Inc. v. American Sci. & Eng’g, Inc., 200 F.3d 795, 803 (Fed. Cir. 1999).
`Other than the terms identified below, we discern no reason to
`construe any other claim terms.
`1. “Proxy”
`All challenged claims recite method steps that are performed by, or
`relate to, a proxy. Petitioner argues the ’429 patent expressly defines a
`proxy:
`
`12
`
`

`

`IPR2018-00913
`Patent 8,316,429 B2
`As used herein in the context of the present invention, the term
`proxy is meant to refer to a device that enforces a set of rules on
`network traffic by intercepting the network traffic that flows
`between a client and a server, parsing and analyzing the
`messages being sent in both directions, and modifying the traffic
`based on a collection of ‘if-then’ rules.
`Pet. 14 (quoting Ex. 1001, 3:38–43; citing Ex. 1003 ¶¶ 49–50).
`Patent Owner acknowledges the quoted definition, does not dispute
`the definition, and applies the definition in its Response. PO Resp. 16.
`In our Decision on Institution, we adopted Petitioner’s proffered
`construction (Dec. on Inst. 12) and we discern no reason to modify our
`construction. Thus, we continue to adopt the above-quoted express
`definition in the ’429 patent Specification as agreed to by the parties.
`Ex. 1001, 3:38–43.
`D. Obviousness Based on Levow, Toneguzzo, and O’Laughlen
`Petitioner contends all challenged claims (10–12) are unpatentable
`under 35 U.S.C. § 103(a) as obvious over the combination of Levow,
`Toneguzzo, and O’Laughlen. See Pet. 33–71.
`1. Overview of Levow (Ex. 1005)
`Levow is directed to security measures applied to network traffic
`including encrypted transmissions. Ex. 1005 ¶ 1. According to Levow, it is
`common for organizations to install firewall systems to determine whether
`exchanged information over a network violates any security rules. Id. ¶ 2.
`Levow further discloses that data encryption is one approach to provide
`security of data exchanged over a network. Id. ¶ 6. However, according to
`Levow, use of such encryption “may be employed intentionally or
`unintentionally to defeat other network security measures” such as content
`filtering by a security system (e.g., a firewall). Id. ¶ 7.
`
`13
`
`

`

`IPR2018-00913
`Patent 8,316,429 B2
`Levow purports to resolve such problems by providing the capability
`in a firewall system to decrypt exchanges over a network, filter the content
`to detect security violations, re-encrypt the information if no violations are
`detected, and forward the re-encrypted information to its intended
`destination. See id. ¶¶ 24, 32. Figure 2 of Levow is reproduced below.
`
`
`Levow’s Figure 2 depicts an exemplary security system. Id. ¶ 20.
`Security system 18 is positioned intermediate server 30 and clients 20, 22,
`and 24. Id. ¶ 24. Security system 18 includes decrypt/re-encrypt devices 36
`and 38 and content filter 40 to enforce security measures on information
`exchanged between client 20 and server 30 via encrypted connections 32 and
`34. Id. ¶ 31. In one embodiment, encrypted information is decrypted and
`filter 40 screens the decrypted information for certain blocked (disallowed)
`
`14
`
`

`

`IPR2018-00913
`Patent 8,316,429 B2
`words. Id. In another embodiment, “content filtering is based upon lists of
`sites that are always blocked or always allowed.” Id.
`Levow’s Figures 4 and 5 are reproduced below.
`
`
`
`15
`
`

`

`IPR2018-00913
`Patent 8,316,429 B2
`
`
`
`Levow’s Figures 4 and 5 reproduced above, together, present a
`flowchart describing exemplary security measures implemented by security
`system 18. See Ex. 1005 ¶¶ 22, 23, 45. At step 50 of Figure 4, client
`computer 20 (e.g., of Figure 2) issues a request for a secure connection to an
`identified resource (e.g., server 30 of Figure 2). Id. ¶ 36. Step 51
`determines whether the request has identified a resource that is on an ignore
`list (i.e., a list of trusted sites for which decryption and further filtering may
`be disregarded), to thereby determine whether the request may be passed on
`without further inspection. Id. According to Levow, a request for a secure
`connection for a banking transaction is an example of a request that need not
`be inspected further. Id. For such an identified request (e.g., a banking
`
`16
`
`

`

`IPR2018-00913
`Patent 8,316,429 B2
`transaction), step 53 disables any further security inspection/filtering
`measures by security system 18 for that requested connection. Id.
`If step 51 determines the requested resource (e.g., server 30) is not on
`the ignore list (e.g., a non-banking transaction), processing continues with
`steps 52 through 82 of Figures 4 and 5. See id. ¶¶ 38–44. Specifically, at
`step 52 security system 18 responds to the client to complete the secure
`protocol (SSL) handshake to thereby establish the requested secure
`connection between client 20 and security system 18. Id. ¶ 38. At step 54,
`the client’s request is compared with all security rules of the enterprise. Id.
`¶ 39. If the request fails to comply with one or more rules, as determined at
`step 56, the request is completed at step 58 with a refusal signal returned to
`the client. Id. If the request passes all rules of the enterprise, steps 60
`through 68 establish a second secure connection between security system 18
`and the requested resource (e.g., server 30). Id. ¶¶ 40–41. A secure
`exchange may then be established between the client and the server, through
`intermediate security system 18, with steps 70 through 82 decrypting and re-
`encrypting a returned response from the resource to further assure the
`response passes all security rules of the enterprise. Id. ¶¶ 42–44.
`As depicted above in Figure 2 of Levow, security system 18 includes
`decrypt/re-encrypt device 36 to decrypt requests from a client computer for
`further evaluation by content filter 40 and to re-encrypt responses returned
`from a responding resource. Id. ¶ 31. In like manner, decrypt/re-encrypt
`device 38 re-encrypts exchanges from a client that pass the tests of content
`filter 40 for forwarding to the requested resource and for decrypting returned
`responses for further evaluation by content filter 40. Id. Content filter 40
`may perform, for example, text screening to identify blocked words in the
`exchanges. Id.
`
`17
`
`

`

`IPR2018-00913
`Patent 8,316,429 B2
`2. Overview of Toneguzzo (Ex. 1006)
`Toneguzzo discloses content filtering for exchanges over the Internet
`using information in a digital certificate. Ex. 1006, code (57). According to
`Toneguzzo, its digital certificate may include a classification as well as a
`name and other information associated with a URL. Id. ¶ 25. In an
`embodiment, filtering of content may be added to a firewall system or router
`intermediate client systems and the Internet. See id. ¶ 97. The content may
`be filtered based on the classification in the digital certificate “and other
`information embedded in the certificate.” Id.
`
`3. Overview of O’Laughlen (Ex. 1007)
`O’Laughlen is generally directed to a proxy system positioned
`between a client and a server that receives HTTP requests from a client and
`forwards the requests to appropriate servers via the Internet. Ex. 1007 ¶ 3.
`Content returned from the server is then forwarded through the proxy to the
`client. Id. According to O’Laughlen, an HTTP request includes a “page
`view” field that includes a header indicating the URL from which the
`request was obtained. Id. ¶ 28. In particular, a web browser operable at a
`client, displaying content returned from a requested web page, may add the
`URL of that web page to the page view header such as when the web page
`content being processed by the client needs to request content from another
`URL embedded within the content being displayed. See id. That page view
`header, added to the request for an embedded URL in the web page, may
`then be used by the proxy for further processing such as access control to
`enable parental control of content retrieved by children. See id. ¶ 29.
`
`18
`
`

`

`IPR2018-00913
`Patent 8,316,429 B2
`Figure 6A of O’Laughlen is reproduced below.
`
`
`Figure 6A above is a flowchart depicting exemplary functions of a
`proxy. Id. ¶ 25. At step 605, the proxy determines whether a request
`includes a page view field. Id. ¶ 73. If not, step 610 determines if access to
`the requested URL is permitted (e.g., has the parent permitted a child to
`access the requested URL). Id. If access is permitted, step 615 retrieves the
`requested URL and returns it to the requesting client. Id. If step 610
`determines access is not permitted, step 620 denies access to the requested
`URL and returns an appropriate status to the requesting client. Id.
`
`19
`
`

`

`IPR2018-00913
`Patent 8,316,429 B2
`If step 605 determines the request includes a page view field, step 625
`determines whether access is permitted to the referring web site (referring
`URL) encoded within the page view field. Id. ¶ 74. If access is permitted,
`step 615 retrieves content of the requested URL and returns it to the
`requesting client. Id. If access is not permitted, step 630 determines
`whether the account (e.g., a parentally controlled account) can access the
`requested URL. Id. If so, step 615 retrieves the requested URL and returns
`the content to the requesting client. Id. If access is not permitted to the
`controlled account, step 620 denies access to the requested URL and returns
`an appropriate status to the requesting client. Id.
`In one exemplary embodiment, the proxy may store requested URLs
`and relationships among them such that URLs at a deeper level within a
`parent URL may be accessed if the parent URL is accessible. See id. ¶ 75.
`According to O’Laughlen, in one example, if access is permitted to the web
`site www.cnn.com, access to related deeper URL may be granted such as to
`www.cnn.com/2003/LAW/11/25/Jackson.case/index.html. Id. ¶ 76. By
`encoding the referring URL (e.g., www.cnn.com) into a page view header
`field of a request for a deeper URL (e.g., www.cnn.com/2003/LAW/11/25
`/Jackson.case/index.html), the proxy may determine whether access to the
`deeper URL is permitted. Id.
`4. Motivation to Combine Levow and Toneguzzo
`Petitioner argues that the ordinarily skilled artisan would have
`recognized that Levow and Toneguzzo could be combined because they are
`in the same field of endeavor (Pet. 72–73 (citing Ex. 1003 ¶¶ 149–51)) and
`the ordinarily skilled artisan would have immediately recognized the
`predictable results of such a combination because extracting information
`from a digital certificate, such as taught by Toneguzzo, in response to a hello
`
`20
`
`

`

`IPR2018-00913
`Patent 8,316,429 B2
`message in an SSL protocol handshake, as taught in Levow, was
`conventional activity (Pet. 77–78 (citing Ex. 1003 ¶ 156)). Petitioner further
`argues an ordinarily skilled artisan would have recognized Levow and
`Toneguzzo could be combined by applying known techniques (extracting
`information from a digital certificate) to improve accuracy in determining
`whether exchanges may be trusted to pass through without decryption to
`filter content—the accuracy improved by virtue of the digital certificate
`containing information that is verified. Pet. 78 (citing Ex. 1003 ¶ 157).
`Petitioner also argues the ordinarily skilled artisan would have recognized
`that Levow and Toneguzzo could be combined because inspecting
`Toneguzzo’s digital certificate to achieve filtering of exchanges would have
`been a trivial modification of Levow’s disclosure of inspecting the
`information within the client’s SSL request. Pet. 78–79 (citing Ex. 1003
`¶ 158).
`Having argued the ordinarily skilled artisan could have combined
`Levow and Toneguzzo, Petitioner contends the ordinarily skilled artisan
`would have been motivated to combine the references. Petitioner argues
`Levow discloses that the resource to be accessed by the client’s request
`could be identified, in the request, by name or by IP address and further
`discloses that the ignore list can similarly identify banking related web sites
`by name (URL) or network (IP) address. Pet. 73–74 (citing Ex. 1005 ¶¶ 15,
`37). Thus, Petitioner argues:
`[I]f Levow’s list included IP addresses and the request contained
`a URL, the system would need to perform a DNS lookup to
`translate the URL in the request to an IP address. However, if
`Levow’s list included server names (URLs) and the request
`contained an IP address, the system would need to perform a
`reverse DNS lookup to translate the IP address to a server name.
`
`21
`
`

`

`IPR2018-00913
`Patent 8,316,429 B2
`Pet. 74. Therefore, Petitioner contends, the ordinarily skilled artisan would
`have been motivated to combine the references because Levow “would be
`simplified if the system categorized the URL extracted from the server’s
`digital certificate obtained during the SSL handshake,” the extraction from a
`digital certificate as disclosed by Toneguzzo. Pet. 74. According to
`Petitioner, the combined teachings would allow Levow to apply the same
`steps because the ignore list of resources requiring no further security
`measures could contain only resource names (URLs) and there would be no
`need to perform a reverse DNS (Dynamic Name System) operation to
`translate an IP address to a URL. Pet. 74–75 (citing Ex. 1003 ¶¶ 152–53).
`
`Patent Owner argues that, for a number of reasons, the Petition fails to
`establish that the ordinarily skilled artisan would have been motivated to
`make the proposed combination and modifications. PO Resp. 12–26 and
`31–46. We address Patent Owner’s arguments below.
`a) Motivation to Reduce rDNS Overhead
`Patent Owner argues the ordinarily skilled artisan would not have
`been motivated to combine the references because Petitioner’s proposed
`combination “would in fact increase overhead in the combined system.” PO
`Resp. 13. Patent Owner further argues Petitioner’s proposed modification to
`Levow to “wait to receive an Internet host’s digital certificate before
`determining whether or not to decrypt communications would increase the
`number of SSL handshakes required to process requests identified on
`Levow’s ignore list.” Id. (citing Ex. 2007 ¶ 127). Patent Owner contends it
`is well known that such SSL handshakes involve substantial computational
`overhead and, thus, an ordinarily skilled artisan would not have been
`motivated to make the proposed combination of references and
`
`22
`
`

`

`IPR2018-00913
`Patent 8,316,429 B2
`modifications to Levow. Id. at 13–16. Understanding this alleged increased
`overhead, Patent Owner argues the ordinarily skilled artisan would not have
`been motivated to make the proposed combination of Levow and Toneguzzo
`because it would outweigh any advantage of eliminating the overhead
`associated with adding reverse DNS processing. Id. at 20–26.
`More specifically, Patent Owner argues Petitioner’s proposed
`combination requires Levow to establish two secure connections using the
`SSL protocol before obtaining a digital certificate from the identified host of
`the request. PO Resp. 17–20. In particular, Patent Owner proffers a version
`of Levow’s Figure 4 annotated by Patent Owner to show modifications to
`Levow as Patent Owner understands Petitioner’s proposed combination. Id.
`at 19. Patent Owner’s annotated Figure 4 is reproduced below.
`
`23
`
`

`

`IPR2018-00913
`Patent 8,316,429 B2
`
`
`Patent Owner argues its annotated figure above, based on Levow’s
`Figure 4, shows that Petitioner’s proposed modification to Levow (to extract
`information from a digital certificate) requires that step 51 (and 53) be
`moved to after step 64—i.e., after both the firs

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

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.

throbber

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.

Become a Member

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

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket