`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