UNITED STATES PATENT AND TRADEMARK OFFICE
`___________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`___________________
`
`NETSKOPE, INC,
`Petitioner,
`
`v.
`
`BITGLASS, INC,
`Patent Owner.
`
`___________________
`
`Case No. PGR2021-00091
`Patent No. 10,855,671
`___________________
`
`BITGLASS, INC’S
`PATENT OWNER RESPONSE
`
`Mail Stop “PATENT BOARD”
`Patent Trial and Appeal Board
`U.S. Patent and Trademark Office
`P.O. Box 1450
`Alexandria, VA 22313-1450
`
`11065527
`
`
`___________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`___________________
`
`NETSKOPE, INC,
`Petitioner,
`
`v.
`
`BITGLASS, INC,
`Patent Owner.
`
`___________________
`
`Case No. PGR2021-00091
`Patent No. 10,855,671
`___________________
`
`BITGLASS, INC’S
`PATENT OWNER RESPONSE
`
`Mail Stop “PATENT BOARD”
`Patent Trial and Appeal Board
`U.S. Patent and Trademark Office
`P.O. Box 1450
`Alexandria, VA 22313-1450
`
`11065527
`
`
`
`Case PGR2021-00091
`Patent No. 10,855,671
`
`
`TABLE OF CONTENTS
`
`I.
`II.
`
` Page(s)
`INTRODUCTION ........................................................................................ 1
`SUMMARY OF THE ’671 PATENT .......................................................... 4
`A. Overview of the ’671 Patent ............................................................... 4
`III. OVERVIEW OF THE CITED ART ............................................................ 7
`A.
`Sarukkai (Ex. 1004) ............................................................................ 7
`B.
`Rowley (Ex. 1005) ........................................................................... 12
`C.
`Cronk (Ex. 1006) .............................................................................. 14
`D. Woelfel (Ex. 1007) ........................................................................... 15
`IV. SKILL LEVEL OF A POSITA .................................................................. 17
`V.
`CLAIM CONSTRUCTION ....................................................................... 18
`VI. THE COMBINATION OF SARUKKAI AND ROWLEY DOES
`NOT RENDER CLAIMS 1,2, 4-5, 9-10 AND 12-13 OBVIOUS
`(GROUND 1) .............................................................................................. 18
`A. A POSITA Would Not Have Been Motivated to Modify
`Sarukkai to Remove the Proxy between the User and the IdP ........ 18
`The Petition Has Not Established a Prima Facie Case of
`Obviousness Because the Sarukkai-Rowley Combination
`Does not Show claim elements 1[b][ii] and 9[b][ii] ........................ 31
`VII. THE PETITION FAILS TO ESTABLISH THAT THE
`COMBINATION OF CRONK AND WOELFEL RENDERS
`OBVIOUS CLAIMS 1-2, 4-5, 9-10 AND 12-13 (GROUND 4) ............... 33
`A.
`The Petition Has Not Established That a POSITA Would
`Have Been motivated to Combine Cronk and Woelfel to
`Create the Claimed Invention ........................................................... 33
`
`B.
`
`11065527
`
`
`- i -
`
`
`
`Case PGR2021-00091
`Patent No. 10,855,671
`
`Page(s)
`
`
`
`B.
`
`C.
`
`The Petition Has Not Established That the Cronk-Woelfel
`Combination Discloses Limitations 1[a][iii] and 9[a][iii] of
`Claims 1 and 9 .................................................................................. 39
`The Petition Has Not Established That the Cronk-Woelfel
`Combination Discloses Elements 1[b][ii]/9[b][ii] ........................... 42
`VIII. THE PETITION FAILS TO ESTABLISH THAT THE KAHOL IS
`PRIOR ART OR THAT THE COMBINATION OF KAHOL AND
`PARLA RENDERS OBVIOUS CLAIMS 1-2, 4-5, 8-10, 12-13
`AND 16 (GROUND 7) ............................................................................... 45
`A.
`Priority Date of the ’671 Patent........................................................ 45
`1.
`The ’671 Patent Claims Priority to an Application
`Having an Effective Filing Date of August 1, 2013 .............. 45
`The ’274 Application Provide Written Description and
`Enabling Disclosure to Support the Challenged Claims
`1-2, 4-5, 8-10, 12-13, and 16 of the ’671 Patent .................... 46
`IX. THE PETITION FAILS TO ESTABLISH THAT CLAIMS 7-8
`AND 15-16 ARE INVALID UNDER SECTION 112 (GROUND
`8) ................................................................................................................. 60
`A.
`The ’671 Patent Discloses Multiple Identity Providers
`Relaying SSO Requests in Claims 7-8 ............................................. 61
`The ’671 Patent Discloses “A Request for the Rewritten
`URL from the User Device” ............................................................. 63
`THE PETITION GROUNDS 2, 3 AND 5 AND 6 SHOULD ALSO
`BE DENIED ............................................................................................... 66
`XI. CONCLUSION ........................................................................................... 67
`
`
`2.
`
`B.
`
`X.
`
`11065527
`
`
`- ii -
`
`
`
`
`
`Ex. 2001
`
`Ex. 2002
`
`Ex. 2003
`
`Ex. 2004
`
`Ex. 2005
`
`Ex. 2006
`
`Ex. 2007
`
`Ex. 2008
`
`Case PGR2021-00091
`Patent No. 10,855,671
`
`EXHIBIT LIST
`
`Declaration of Seth J. Nielson in Support of Patent Owner’s
`Preliminary Response [Nielson Decl.]
`File History of U.S. Patent Application No. 13957274 [‘274
`Application]
`File History of U.S. Patent Application No. 13797634
`[Sarukkai File History]
`Enterprise Identity Management: Beyond PKI into Federation,
`An Exostar Whitepaper, July 2005 [Enterprise Identity
`Management: Beyond PKI into Federation]
`Single Sign-On in Service-Oriented Computing, Geihs et al.,
`ICSOC 2003, LNCS 2910, pp. 384-393, 2003 [Single Sign-On
`in Service-Oriented Computing]
`Security and Privacy Considerations for the OASIS Security
`Assertion Markup Language (SAML) V2.0, OASIS Standard,
`15 March 2005 [Security and Privacy Considerations for the
`OASIS Security Assertion Markup Language (SAML) V2.0]
`Request For Comments 2616, Hypertext Transfer Protocol –
`HTTP/1.1, June 1999 [RFC 2616]
`Declaration of Seth J. Nielson in Support of Patent Owner’s
`Response
`
`11065527
`
`
`- iii -
`
`
`
`Case PGR2021-00091
`Patent No. 10,855,671
`
`
`I.
`
`INTRODUCTION
`On December 14, 2021 the Patent Trial and Appeal Board (“Board”) issued
`
`a decision (“Decision”) to institute an post grant review regarding the patentability
`
`of claims 1, 2, 4-10 and 12-16 of U.S. Patent No. 10,855,671 (Ex. 1001, the “’671
`
`patent”). The Decision was based on a petition for post grant review (“Petition”)
`
`filed by Netskope, Inc. (“Petitioner”).
`
`The Petition asserts eight separate grounds: Grounds 1, 2 and 3 allege
`
`obviousness under 35 U.S.C. § 103 primarily over Sarukkai (Ex. 1004) in view of
`
`Rowley (Ex. 1005). Grounds 4, 5 and 6 allege obviousness under 35 U.S.C. § 103
`
`primarily over Cronk (Ex. 1006) and Woelfel (Ex. 1007). Ground 7 alleges
`
`obviousness under 35 U.S.C. § 103 over Kahol (Ex. 1008) and Parla (Ex. 1009).
`
`Ground 8 alleges that claims 7, 8, 15 and 16 are unpatentable for lacking written
`
`description and enablement under 35 U.S.C. § 112. The Decision found that the
`
`Petition demonstrated a reasonable likelihood that claims 1, 2, 4-10 and 12-16
`
`were obvious under grounds 1, 2 and 3 and that claims 7, 8, 15 and 16 were
`
`unpatentable under 35 U.S.C. § 112. The Decision did not address Grounds 4, 5, 6
`
`and 7.
`
`The proposed Sarukkai and Rowley combination lacks the unique pair of
`
`communication paths recited in the claims of the ’671 patent. The claims require a
`
`11065527
`
`
`- 1 -
`
`
`
`direct communication between a user device and an identity provider (IdP), and a
`
`Case PGR2021-00091
`Patent No. 10,855,671
`
`
`separate communication between the user device and an application server that
`
`occurs thru a proxy. Neither Sarukkai nor Rowley disclose this arrangement of
`
`elements. Sarukkai discloses use of a proxy between the user and both the
`
`application server and the identity provider. Sarukkai does not disclose or suggest
`
`to remove the proxy between the user and the identity provider. The Petition
`
`points to a single passage in Sarukkai that mentions a user can login into the
`
`identity provider directly to support a position that this reference teaches to remove
`
`the proxy between the user and IdP. The Petitioner’s myopic view of this passage
`
`does not consider the entire context of the Sarukkai reference. Sarukkai discloses
`
`three different embodiments. In the first two embodiments the user initially seeks
`
`to logon to an application server which then redirects the user to the IdP thru a
`
`proxy for access validation. In the third embodiment the user initiates a logon to
`
`the identity provider thru a proxy. In this embodiment the user does not initially
`
`seek to logon to the application server. This is what is meant by the “directly”
`
`passage. The user can logon to the IdP directly without having to be redirected by
`
`the application server. Sarukkai does not suggest that the proxy can be removed
`
`from the communication path between the user device and the IdP.
`
`The combination of Cronk and Woelfel also do not render the claims
`
`obvious. The Cronk reference does not disclose a proxy. The Petition proposes to
`
`11065527
`
`
`- 2 -
`
`
`
`modify Cronk to include a proxy disclosed in Woelfel. The claims require that the
`
`Case PGR2021-00091
`Patent No. 10,855,671
`
`
`proxy have a cloud network location. The Woelfel proxy is located behind a
`
`firewall in a closed enterprise, not in the cloud. Additionally, the claims require an
`
`identity provider that is configured to authenticate validation requests for access to
`
`an application program. Modifying Cronk to include the Woelfel proxy would not
`
`result in an identity provider validating requests for access to an application
`
`program. Full validation for access to an application program is performed by the
`
`Woelfel proxy, using encryption split keys, not by the identity provider.
`
`The Petition alleges that the claims do not have written description support
`
`from an earlier application and thus the filing date of the claims is May 18, 2020.
`
`Given this filing date the Petitioner states that both Kahol and Parla are prior art.
`
`The Petitioner’s view is directed to one specific embodiment of the specification,
`
`completely ignoring another embodiment that does provide written description
`
`support for the claims. The priority date for the ’671 patent is the filing date of the
`
`original application, August 1, 2013. With this reference date neither Kahol nor
`
`Parla are prior art. The patentability of claims 1, 2, 4-10 and 12-16 should be
`
`maintained.
`
`11065527
`
`
`- 3 -
`
`
`
`II.
`
`Case PGR2021-00091
`Patent No. 10,855,671
`
`
`SUMMARY OF THE ’671 PATENT
`A. Overview of the ’671 Patent
`The ’671 patent is entitled “Secure Application Access System” and claims
`
`priority to an application (Application No. 13/957,274) filed on August 1, 2013.
`
`The specification includes multiple embodiments directed towards different types
`
`of access systems in a cloud environment. The ’671 specification identifies two
`
`growing security issues in enterprise IT environments that are relevant to many of
`
`the disclosures. First, growth of devices owned by the employee rather than the
`
`company (sometimes called “Bring Your Own Device” or BYOD) and the ever
`
`increasing trend of hosting company applications in the cloud. Ex 1001, 3:4-18.
`
`Different embodiments within the ’671 patent are grouped together under a
`
`section entitled, “3. Proxy Routing.” Id., 5:63-7:61. The ’671 patent discloses a
`
`process whereby an attempt to log in to an application program is redirected to “a
`
`centralized directory.” Id., 6:7-26. The ’671 patent reveals that “[m]any
`
`applications allow the administrator to delegate login to a centralized directory in a
`
`company. “Such delegation to a central directory is useful in a corporation where
`
`replicating the login information for every employee at each application is difficult
`
`to manage.” Id., 6:8-13, and “[i]n the case of delegated login, when a user attempts
`
`to login to an application from his content browser, the application redirects the
`
`user to the centralized directory. The user then presents their login credentials to
`
`11065527
`
`
`- 4 -
`
`
`
`the directory and, if successful, is redirected to the application.” Id., 6:16-21. The
`
`Case PGR2021-00091
`Patent No. 10,855,671
`
`
`’671 patent teaches that “the centralized directory” as used herein is performing the
`
`functions of an identity authentication, i.e., performing the role of an identity
`
`provider. Ex. 2008, ¶ 66.
`
`The ’671 patent describes an embodiment where access to the application is
`
`routed through a proxy after a successful delegated login with the centralized
`
`directory. Ex 1001, 6:27-33. As discussed above, the centralized directory, which
`
`is the identity provider, handles logins for multiple applications thus providing a
`
`corporation-level Single Sign-On function (“SSO”). Ex 1001, 6:7-47.
`
`This process is illustrated in Fig. 3b which shows interaction between a
`
`content browser, application server and centralized directory thru a proxy:
`
`
`
`11065527
`
`
`- 5 -
`
`
`
`Alternatively, the application server may direct the user directly to the
`
`Case PGR2021-00091
`Patent No. 10,855,671
`
`
`centralized directory without use of an intermediary proxy. The patent states in
`
`pertinent part:
`
`In an embodiment, direct access to the application may be restricted
`via a login process. Many applications allow the administrator to
`delegate login to a centralized directory in a company. Such
`delegation to a central directory is useful in a corporation where
`replicating the login information for every employee at each
`application is difficult to manage. The delegation may be
`implemented as a network call from the application server to the
`centralized directory, and may be specified as a URL or other means.
`In the case of delegated login, when a user attempts to login to an
`application from his content browser, the application redirects the user
`to the centralized directory. The user then presents his login
`credentials to the directory and, if successful, is redirected to the
`application. Id. 6:7-21.
`
`also,
`
`The application server 102 may redirect 310 the request to point to the
`centralized directory 308 via the proxy 101. The content browser 307
`then visits the centralized directory 308 via the proxy 101 and, upon
`successful login 311, is redirected 312 via the proxy 101 back to the
`application 102. The user, via the content browser 307, then interacts
`313 with the application 102 via the proxy 101. In an alternate
`embodiment, the first redirect 310 may be directed to the centralized
`
`11065527
`
`
`- 6 -
`
`
`
`Case PGR2021-00091
`Patent No. 10,855,671
`
`
`directory 308 but, upon successful login to the centralized directory
`308, the user is redirected to the application 102 via the proxy 101.
`Id. 6:29-39 (emphasis added).
`
`In accordance with the process disclosed in Fig. 3b the user attempts to log
`
`into an application whereupon the application provider redirects the user to the
`
`centralized directory. After validation by the centralized directory the user is then
`
`redirected to the application provider via a proxy.
`
`III. OVERVIEW OF THE CITED ART
`A.
`Sarukkai (Ex. 1004)
`U.S. Patent 9,137,131 to Sarukkai, et al. (“Sarukkai”), is entitled, “Network
`
`traffic monitoring system and method to redirect network traffic through a network
`
`intermediary.” As the title suggests, the invention includes various embodiments
`
`related to a “monitoring system.” The monitoring system “includes a monitor
`
`proxy server configured as a network intermediary between the client device and a
`
`federated identity provider and between the client device and the cloud service.”
`
`Ex. 1004, Abstract.
`
`Sarukkai teaches that the monitoring proxy can act as a reverse proxy for an
`
`identity provider in an SSO environment. The monitor proxy “… implements
`
`reverse-proxying of the federated identity handshake used to authenticate user
`
`access to a cloud-based service… [and then] the reverse proxy rewrites the redirect
`
`11065527
`
`
`- 7 -
`
`
`
`web address for accessing the cloud service so that network traffic between the
`
`Case PGR2021-00091
`Patent No. 10,855,671
`
`
`client device and the cloud service is redirected through a network proxy.” Id.,
`
`3:4-21. Sarukkai asserts that the invention enables “seamless” layering of the
`
`network proxy without requiring “client-side software.” Id.
`
`Conforming with the “seamless” integration, the client only interacts with
`
`the monitor proxy as if the monitor proxy were the identity provider.
`
`
`
`Id., Fig. 6 (cropped).
`This is further reinforced by Sarukkai’s definition of reverse proxy in that
`
`responses from the proxy act “as though they originated from the proxy server
`
`itself” rather than the real server. In order to achieve this transparency in the
`
`monitoring server, the Sarukkai proxy receives the user’s credentials for the IdP
`
`11065527
`
`
`- 8 -
`
`
`
`from the user directly. In other words, it pretends to be the IdP to the client.
`
`Case PGR2021-00091
`Patent No. 10,855,671
`
`
`Moreover, with the user’s credentials the monitor proxy turns around and pretends
`
`to be the client to the service. See, e.g., Id., 9:21-29; 9:61-10:13.
`
`Sarukkai discloses three different embodiments shown in Figs. 2 and 3; Figs.
`
`4 and 5 and Figs. 6 and 7, respectively. In the first two embodiments the user
`
`initially logs in to a service that redirects the user device to an IdP via a proxy. In
`
`the third embodiment the user can login to the IdP, via a proxy, directly without
`
`initially going to the target service. Notably in this embodiment there is still an
`
`IdP proxy between the user and the IdP. Sarrukai states that the user can login
`
`directly to the IdP. Id., 9:54-58. What is meant by this statement is that the user
`
`can login to the IdP without first going to the target service as described in the first
`
`two embodiments. The difference in approaches is shown by Figs. 3, 5 and 7
`
`(highlighted below).
`
`
`
`11065527
`
`
`- 9 -
`
`
`
`Client
`
`servicet.abc.com
`
`—_service1.com
`
`\dP
`
`Login to Request Target Resource
`abc.service1.com
`
`Redirect Userto Monitor Proxy
`service1.abc.com
`
`Provide Login Credentials
`
`Forward Credentials
`for Authentication
`
`Return Redirect URL
`and Token
`abc.service1.com
`
` Monitor Proxy
`
`Case PGR2021-00091
`Case PGR2021-00091
`Patent No. 10,855,671
`Patent No. 10,855,671
`
`
`Rewrite Redirect URL
`
`Return Modified URL and token
`service1.abc.com
`
`Request Target Resource
`
`Response with Requested Resource
`
`Proxied Traffic
`
`FIG. 3
`
`
`
`11065527
`11065527
`
`
`- 10 -
`-10-
`
`
`
`Case PGR2021-00091
`Case PGR2021-00091
`Patent No. 10,855,671
`Patent No. 10,855,671
`
`
`;
`Client
`
`Service RP
`IdP RP
`fed.abc.com service1.abc.com_servicel.com
`
`_—‘IdP
`
`Login to Request Target Resource
`abc.service1.com
`
`Redirect Userto IdP RP
`fed.abc.com
`
`Provide Login Credentials
`
`Forward Credentials
`for Authentication
`
`Return Redirect URL
`and Token
`abc.service1.com
`
`Response with Requested Resource
`
`Rewrite Redirect URL
`
`Return Modified URL and token
`service1.abc.com
`
`Proxied Traffic
`
`FIG. 5
`
`
`
`11065527
`11065527
`
`
`- 11 -
`- 11 -
`
`
`
`Case PGR2021-00091
`Patent No. 10,855,671
`
`
`
`
`Figs. 3 and 5 show an initial communication to the target service that then
`
`directs the user to the IdP via a proxy. In these embodiments the user is indirectly
`
`connected to the IdP thru a redirect by the service. In Fig. 7 the user is “directly”
`
`connected to the IdP thru the IdP proxy. There is not a redirect via the service.
`
`B. Rowley (Ex. 1005)
`U.S. Patent Application Publication 2008/0189778 to Rowley (“Rowley”) is
`
`entitled, “Secure authentication in browser redirection authentication schemes.”
`
`This reference is directed to “authenticating a client.” Rowley Abstract. Rowley
`
`11065527
`
`
`- 12 -
`
`
`
`discusses “a man in the middle problem” in systems that include a relying party
`
`Case PGR2021-00091
`Patent No. 10,855,671
`
`
`server and an IdP. Id. [0003]. In such a system redirects by a website may redirect
`
`to itself or a malicious party that can see the conversation between the user and the
`
`IdP, thus obtaining access to confidential information. Id. Rowley teaches an
`
`approach wherein“[t]he identity provider server authenticates the client without
`
`receiving a replayable credential from the client.” Id. This means, for example,
`
`not sending static credentials such as usernames and passwords. Instead, Rowley
`
`proposes user techniques such as exchanging public keys so that “[o]nly the
`
`legitimate owner or user of [keys] will be able to decrypt [the data]…” Id. [0036].
`
`Rowley does not teach that proxies or intermediaries should not be used. It
`
`identifies a malicious proxy server as a threat. Id. Fig 3; [0003], [0007], [0025]. In
`
`fact, the word “proxy” does not appear without the adjective “malicious” or
`
`reference to a malicious party. Id. A malicious proxy is not built in by design but
`
`is inserted or used without authorization by one or more parties. Authorized parties
`
`would not insert a malicious proxy by design. Ex. 2008, ¶ 96.
`
`Moreover, Rowley’s teachings about secure transmissions are meant to
`
`protect a client even if there is a malicious proxy. Id. ¶ 97. For example, Rowley
`
`describes using public key cryptography to protect the data. Ex. 1005, [0030]-
`
`[0040]. This ensures that only the authorized recipient can decrypt the data even if
`
`the data is intercepted. However, this method does require knowing for certain that
`
`11065527
`
`
`- 13 -
`
`
`
`a party has the correct keys of the other party. If a malicious server, for example,
`
`Case PGR2021-00091
`Patent No. 10,855,671
`
`
`convinces the client to accept its keys the client will still exchange its information
`
`with the malicious server. Rowley hints at these issues in the various discussions
`
`of how keys should be exchanged and approved for exchange. See, e.g., Id.
`
`[0033]-[0035].
`
`Even using these encryption protection mechanisms, Rowley still teaches
`
`not sending a “replayable” credential such as a username/password. Id. ¶ [0030].
`
`In other words, Rowley’s invention is to use a non-replayable credential (for
`
`certain kinds of long term protections) and secure authenticated channels (for
`
`instant protection against Man-in-the-Middle attacks).
`
`C. Cronk (Ex. 1006)
`U.S. Patent Application Publication 2012/0008786 to Cronk, et al. (“Cronk”)
`
`is entitled, “Apparatus and methods for content delivery and message exchange
`
`across multiple content delivery networks.” Cronk describes itself as “[m]ethods
`
`and apparatus for providing protected content to subscribers of a managed (e.g.,
`
`MSO) network via a content source accessible via an internetwork such as the
`
`Internet.” Cronk Abstract. Cronk discloses a hybrid system wherein an MSO
`
`network, such as cable broadcast, also makes “protected content” (e.g., copyrighted
`
`media) available over the Internet.
`
`11065527
`
`
`- 14 -
`
`
`
`Case PGR2021-00091
`Patent No. 10,855,671
`
`Cronk, in teaching how protected content may be made available, was aware
`
`that data would often be made available through (potentially many) third parties
`
`(e.g., websites) rather than directly to the user from a server controlled by the
`
`MSO. Cronk Abstract. Cronk envisions embodiments wherein the MSO acts as an
`
`identity provider in a federated SSO environment. Id.
`
`Cronk does not disclose modifications or changes to federated SSO. Ex.
`
`2008, ¶ 101. Cronk does mention use of a proxy, but this refers to using a different
`
`party to supply content to a user. Ex. 1006, [0093]. This reference to a proxy does
`
`not relate to for example a reverse proxy located between a user and a service
`
`provider.
`
`D. Woelfel (Ex. 1007)
`U.S. Patent Application Publication 2012/0278872 to Woelfel, et al.
`
`(“Woelfel”) is entitled, “System and method of federated authentication with
`
`reverse proxy.” Woelfel describes itself as “[a] Security Assertion Markup
`
`Language (SAML) conversation [is] intercepted in an enhanced Reverse Proxy
`
`server computer located in the path between a user and a server computer that
`
`provide cloud application services to the user.” Woelfel Abstract.
`
`Woelfel identifies a federated SSO as a circumstance in which reverse
`
`proxies must be used with care. The specification explains that:
`
`11065527
`
`
`- 15 -
`
`
`
`Case PGR2021-00091
`Patent No. 10,855,671
`
`
`To resolve the apparent incompatibility of federated SSO to operate in
`conjunction with a Reverse Proxy, the invention proposes a system
`and methods wherein a modified Reverse Proxy (termed PerspecSys
`Reverse Proxy) behaves as an Intercepting Proxy, inserting itself in
`the middle of the trusted authentication conversation between the SSO
`Identity Provider and the Cloud application…
`
`… difficulties can arise when using a conventional Reverse Proxy
`server. The difficulty is with the contents of the SAML assertion
`which contains specific information to the actual SaaS application and
`it’s URLs, including the return URL (i.e. the URL of the client). This
`will not match the URL provided by the Reverse Proxy (i.e. the URL
`of the Reverse Proxy). As a result, the assertion will fail, and the user
`will be unable to log into the actual web resource through a
`conventional Reverse Proxy.
`
`Ex. 1007, [0087], [0104]. A POSITA in possession of Woelfel would have
`
`understood that Woelfel is disclosing a custom or enhanced system that
`
`manages the incompatibilities identified. Ex 2008, ¶ 104.
`
`In one example, Woelfel discloses a modified reverse proxy that must split
`
`up the standard cryptographic key configuration that binds together the user, IdP,
`
`and SP into a split key configuration that binds together the user, IdP, and reverse
`
`proxy and also binds together the reverse proxy and the SP. Ex. 1007, [0121]-
`
`[0123].
`
`11065527
`
`
`- 16 -
`
`
`
`Woelfel discloses the PRS Reverse Proxy being located in an enterprise as
`
`Case PGR2021-00091
`Patent No. 10,855,671
`
`
`reflected in Fig. 1 shown below.
`
`
`
`IV. SKILL LEVEL OF A POSITA
`For purposes of this proceeding the Patent Owner does not dispute the
`
`Board’s definition of a person of ordinary skill in the art (“POSITA”). Dec., 19-
`
`
`
`20.
`
`11065527
`
`
`- 17 -
`
`
`
`V. CLAIM CONSTRUCTION
`At this stage of the proceeding the Patent Owner does not believe that the
`
`Case PGR2021-00091
`Patent No. 10,855,671
`
`
`Board needs to address any claim construction issue. The Patent Owner reserves
`
`all rights to seek specific claim constructions based on the response of the
`
`Petitioner.
`
`VI. THE COMBINATION OF SARUKKAI AND ROWLEY DOES NOT
`RENDER CLAIMS 1,2, 4-5, 9-10 AND 12-13 OBVIOUS (GROUND 1)
`The Board found it is more likely than not that claims 1, 2, 4, 5, 9, 10, 12
`
`and 13 are obvious under § 103 over Sarukkai and Rowley. Decision 38-39. For
`
`the reasons discussed below Sarukkai and Rowley do not render these claims
`
`obvious.
`
`A. A POSITA Would Not Have Been Motivated to Modify Sarukkai
`to Remove the Proxy between the User and the IdP
`The claims require a proxy between a user and an application program, and
`
`direct communication between the user and an identity provider (i.e. without a
`
`proxy). Sarukkai discloses embodiments that all require a proxy(ies) between the
`
`user, the service and an IdP. Ex. 1004 Figs. 2, 4 and 6. There is never a direct
`
`communication between the user and an identity provider. The Petition points to a
`
`passage in Sarukkai that purportedly suggest to remove the proxy between the user
`
`and the IdP. Pet. 35. The Board also cited this passage to support an initial
`
`determination of obviousness. Decision 26-7. This passage states in pertinent part
`
`11065527
`
`
`- 18 -
`
`
`
`“a user may login to an identity provider directly”. Ex. 1004, 9:54-55. Taken
`
`Case PGR2021-00091
`Patent No. 10,855,671
`
`
`within the context of the entire Sarukaai reference this passage is not suggesting to
`
`remove the proxy between the user and the IdP. This passage is merely describing
`
`a scenario wherein the user can initially login onto the IdP, instead of initially
`
`communicating with the service and then the IdP. This difference in login
`
`approaches is reflected by the following passages that describe the login steps for
`
`the embodiments of Figs. 2, 4 and 6 in Sarukkai.
`
`Fig. 2 embodiment: “To request a service from the cloud service 12, the
`
`client device 10 initiates a login process to the cloud service (:service1.com”) as is
`
`conventionally done.” Id. 5:27-29 (emphasis added).
`
`Fig. 4 embodiment: “To request a service from the cloud service 12, the
`
`client device 10 initiates a login process to the cloud service (:service1.com”) as is
`
`conventionally done.” Id. 8:13-16 (emphasis added).
`
`Fig. 6 embodiment: “To request a service from the cloud service 12, the
`
`client device 10 initiates a login process to the identity provider proxy server 45
`
`(e.g. “fed.ab-c.com”) as a means to authenticate the user before accessing the cloud
`
`service.” Id. 10:22-26 (emphasis added).
`
`The difference in the initial login steps is reflected in corresponding Figs. 3,
`
`5 and 7 (highlighted below).
`
`11065527
`
`
`- 19 -
`
`
`
`.
`Monitor Proxy
`.
`
`
`
`Client service1.abc.com—_service1.com \dP
`
`Case PGR2021-00091
`Case PGR2021-00091
`Patent No. 10,855,671
`Patent No. 10,855,671
`
`
`Response with Requested Resource
`
`Login to Request Target Resource
`abc.service1.com
`
`Redirect User to Monitor Proxy
`service1.abc.com
`
`Provide Login Credentials
`
`Rewrite Redirect URL
`
`Return Modified URL and token
`service1.abc.com
`
`Forward Credentials
`for Authentication
`
`Return Redirect URL
`and Token
`
`abc.service1.com
`
`Proxied Traffic
`
`FIG. 3
`
`
`
`
`
`11065527
`11065527
`
`
`- 20 -
`- 20 -
`
`
`
`Case PGR2021-00091
`Case PGR2021-00091
`Patent No. 10,855,671
`Patent No. 10,855,671
`
`
`;
`Client
`
`Service RP
`IdP RP
`fed.abc.com service1.abc.com_servicel.com
`
`_—‘IdP
`
`Login to Request Target Resource
`abc.service1.com
`
`Redirect Userto IdP RP
`fed.abc.com
`
`Provide Login Credentials
`
`Forward Credentials
`for Authentication
`
`Return Redirect URL
`and Token
`abc.service1.com
`
`Response with Requested Resource
`
`Rewrite Redirect URL
`
`Return Modified URL and token
`service1.abc.com
`
`Proxied Traffic
`
`
`
`FIG. 5
`
`
`
`11065527
`11065527
`
`
`- 21 -
`- 21 -
`
`
`
`Case PGR2021-00091
`Patent No. 10,855,671
`
`
`
`
`The first two embodiments of Sarukkai disclose a process wherein the user
`
`initially logs in to the service as indicated by the highlighted steps in Figs. 3 and 5
`
`above. In the third embodiment the login is initiated by direct communication with
`
`the IdP proxy as shown in Fig. 7. The cited “directly” passage is referring to the
`
`embodiment shown in Figs. 6 and 7. Notably, the “directly” passage is in a
`
`paragraph immediately preceding the descriptions of Figs. 6 and 7. The
`
`11065527
`
`
`- 22 -
`
`
`
`Case PGR2021-00091
`Patent No. 10,855,671
`
`connection between the “directly” passage and the embodiments of Figs. 6 and 7 is
`
`further reflected in the following language provided by Sarukkai:
`
`“In alternate embodiments of the present invention, a user may login to an
`
`identity provider directly or to an enterprise application distribution platform
`
`configured to provide users with access to application software to which the users
`
`are entitled.” Ex. 1004, 9:54-60 (emphasis added).
`
`“FIG. 6 is a diagram illustrating a network traffic monitoring system to
`
`redirect network traffic in alternative embodiments of the present invention.
`
`Referring to FIG. 6, an enterprise uses a published identity provider or an
`
`enterprise application distribution platform to provide users with access to one or
`
`more cloud services.” Ex. 1004, 9:61-66 (emphasis added).
`
`This section of Sarukkai is describing an embodiment where a user can
`
`“directly” login to a published IdP thru an IdP proxy (“The client device 10
`
`communicates with the identity provider 18, through the identity provider proxy
`
`server 45, to complete the authentication process.” Id. 10:27-29). Sarukkai does
`
`not disclose or suggest to remove the proxy between the user and the IdP. See also
`
`Ex. 2008, ¶¶ 137-146.
`
`To the contrary, the entire teaching of Sarukkai is to place a proxy
`
`intermediary between a user and both a server provider and an IdP. As an initial
`
`point this is reflected in the title of Sarrukai which states: “Network Traffic
`
`11065527
`
`
`- 23 -
`
`
`
`Monitoring System and Method to Redirect Network Traffic Through A Network
`
`Case PGR2021-00091
`Patent No. 10,855,671
`
`
`Intermediary.” Sarukkai states that the monitor system “includes a monitor proxy
`
`server configured as a network intermediary between the client device and a
`
`federated identity provider and between the client device and the cloud service.”
`
`Ex. 1004, Abstract. Sarukkai explains that “[a] salient feature of the network
`
`traffic monitoring system 20 is that no client agent or client software is required.”
`
`Id., 4:57-5:2. This is because the network traffic monitoring system works as an
`
`application proxy ser
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
