`571.272.7822
`
`Paper 27
`Entered: February 20, 2019
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`UNIFIED PATENTS INC.,
`Petitioner,
`
`v.
`
`SMART AUTHENTICATION IP, LLC,
`Patent Owner.
`____________
`
`Case IPR2017-02047
`Patent 8,082,213 B2
`____________
`
`FINAL WRITTEN DECISION
`35 U.S.C. § 318(a) and 37 C.F.R. § 42.73
`
`
`
`
`
`
`
`
`Before KEVIN W. CHERRY, MICHELLE N. WORMMEESTER, and
`JAMES A. WORTH, Administrative Patent Judges.
`
`WORMMEESTER, Administrative Patent Judge.
`
`
`
`
`
`IPR2017-02047
`Patent 8,082,213 B2
`
`
`I. INTRODUCTION
`Unified Patents Inc. (“Petitioner”) filed a Petition (Paper 3, “Pet.”)
`requesting inter partes review of claims 1–17 of U.S. Patent No. 8,082,213
`B2 (Ex. 1001, “the ’213 patent”). We initially instituted an inter partes
`review as to claims 1–10 and 12–17 based on two of the three grounds
`presented in the Petition. Paper 9 (“Institution Decision” or “Inst. Dec.”);
`see 35 U.S.C. § 314(a). After institution of trial, in light of the Supreme
`Court’s decision in SAS Institute Inc. v. Iancu, 138 S. Ct. 1348 (2018), we
`modified our Institution Decision to include review of all the challenged
`claims and all the grounds presented in the Petition. Paper 14.
`Smart Authentication IP, LLC (“Patent Owner”) filed a Patent Owner
`Response (Paper 18, “PO Resp.”), and Petitioner filed a Reply (Paper 20,
`“Pet. Reply”). With our authorization, Patent Owner subsequently filed a
`Sur-Reply (Paper 21, “PO Sur-Reply”).
`On November 6, 2018, we conducted an oral hearing. A copy of the
`transcript (Paper 26, “Tr.”) is included in the record.
`We have jurisdiction under 35 U.S.C. § 6(b). For the reasons that
`follow, we determine that Petitioner has shown by a preponderance of the
`evidence that claims 1–10 and 12–17 of the ’213 patent are unpatentable.
`Petitioner has not made such a showing, however, with respect to claim 11
`of the ’213 patent. This final written decision is issued pursuant to
`35 U.S.C. § 318(a).
`
`
`2
`
`
`
`IPR2017-02047
`Patent 8,082,213 B2
`
`
`II. BACKGROUND
`A. Related Proceedings
`The parties identify several related district court cases. Pet. 1–2;
`Paper 4, 2.
`
`
`B. The ’213 Patent
`The ’213 patent relates to user authentication, where a user controls
`the level and complexity of an authentication process carried out by an
`authentication service provider (“ASP”) on behalf of both the user and an
`entity seeking to authenticate the user. Ex. 1001, 2:1–10.
`To illustrate an example of user authentication according to the
`’213 patent, Figure 3 is reproduced below.
`
`
`
`3
`
`
`
`IPR2017-02047
`Patent 8,082,213 B2
`
`Figure 3 shows the interactions between a user, an ASP client, and an ASP.
`Id. at 3:47–48. First, the user starts an electronic transaction with the ASP
`client by requesting to log in to a commercial website or by requesting a
`product or service. Id. at 3:48–51. The ASP client obtains user information
`from the user. Id. at 3:51–55. The user information may include the user’s
`name, the user’s address or other contact information, the user’s billing
`information, the user’s employment information, or user-specified
`passwords. Id. at 4:18–27.
`Next, the ASP client transmits an authentication request to the ASP to
`determine whether the user is authentic. Id. at 3:55–59. The authentication
`request includes the information obtained from the user. Id.
`The ASP then carries out an authentication transaction with the user to
`authenticate the user according to predetermined authentication policies. Id.
`at 3:59–62. The user may specify each policy. Id. at 4:28–30. With respect
`to bank account transactions, for example, the user may specify that only
`transactions occurring between 1:00 pm and 4:00 pm on Monday through
`Friday are to be authorized, and that authorization must include
`variable-factor authentication using randomly generated passwords sent to
`the user’s cell phone and furnished by the user to the bank during the
`transactions. Id. at 4:31–40.
`Once the authentication transaction is complete, the ASP returns an
`authentication result to the ASP client, which uses the result to complete the
`electronic transaction with the user. Id. at 3:62–67.
`
`
`4
`
`
`
`IPR2017-02047
`Patent 8,082,213 B2
`
`
`C. Illustrative Claim
`Petitioner challenges claims 1–17 of the ’213 patent. Claims 1 and 12
`are independent. Claim 1 is illustrative of the claims under challenge:
`1. A user-authentication service implemented as routines that
`execute one or more computer systems interconnected by two or
`more communications media with both an authentication-service
`client, and a user, the user-authentication service comprising:
`the one or more computer systems;
`stored user-authentication policies specified by the user;
`stored user information;
`account interface routines that implement an account
`interface by which the user specifies, modifies, adds, and
`deletes user-authentication policies; and
`an
`implement
`authentication-interface
`routines
`that
`authentication interface by which, following initiation of a
`transaction by the user with the authentication service
`client,
`the authentication-service client submits an
`authentication request, through the first communications
`medium or through a second communications medium, to
`authenticate the user, the authentication interface routines
`employing a variable-factor authentication, when
`specified to do so by stored user-authentication policies,
`to authenticate the user on behalf of the authentication-
`service client during which the user communicates with
`the user-authentication
`service
`through
`a
`third
`communications medium different from the first and
`second communications media and a user device different
`from that employed by the user to initiate the transaction
`with the authentication-service client.
`
`
`
`D. The Instituted Grounds
`Petitioner asserts in its Petition three grounds based on obviousness
`under 35 U.S.C. § 103. Pet. 4, 12–86. Although we initially instituted inter
`
`5
`
`
`
`IPR2017-02047
`Patent 8,082,213 B2
`
`partes review on fewer than all claims challenged in the Petition, we
`subsequently modified our Institution Decision to include review of all the
`challenged claims and all the grounds presented in the Petition. Inst. Dec. 2;
`Paper 14, 2. The instituted grounds are as follows.
`Claims Challenged
`Reference(s)
`Basis
`1–17
`Harris1 and Owen2
`§ 103
`1–10
`Vandergeest3 and Delany4
`§ 103
`12–17
`Vandergeest
`§ 103
`In support of the instituted grounds, Petitioner relies on the declarations of
`Stephen Gray (Exhibits 1003 and 1010).
`
`
`III. ANALYSIS
`A. Claim Construction
`The claim construction standard applicable to this inter partes review
`proceeding is the broadest reasonable interpretation in light of the patent
`specification. See 37 C.F.R. § 42.100(b) (2017); Cuozzo Speed Techs. LLC
`v. Lee, 136 S. Ct. 2131, 2144–46 (2016) (upholding the use of the broadest
`
`
`1 Harris, U.S. Patent No. 8,751,801 B2, issued June 10, 2014 (Ex. 1004).
`2 Owen, Int’l Publ’n No. WO 03/032126 A2, published Apr. 17, 2003
`(Ex. 1006).
`3 Vandergeest, U.S. Patent No. 7,765,580 B2, issued July 27, 2010
`(Ex. 1005).
`4 Delany, U.S. Publ’n No. 2002/0156879 A1, published Oct. 24, 2002
`(Ex. 1007).
`
`6
`
`
`
`IPR2017-02047
`Patent 8,082,213 B2
`
`reasonable interpretation standard).5 Under this 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. See In re Translogic Tech., Inc., 504 F.3d 1249, 1257
`(Fed. Cir. 2007).
`Petitioner provides proposed interpretations of the claim terms
`“user-authentication policies,” “specified by the user,” “variable-factor
`authentication,” and “returning an authentication result.” Pet. 10–12. Patent
`Owner does not respond. See generally PO Resp. In light of the parties’
`arguments, we determine that no term requires express interpretation to
`resolve any controversy in this proceeding.
`
`
`B. Obviousness over Harris and Owen: Claims 1–17
`Petitioner argues that claims 1–17 of the ’213 patent would have been
`obvious over Harris and Owen. Pet. 12–50. Patent Owner responds that
`“Petitioner has failed to show that claims 1–11 are unpatentable as obvious
`in view of Harris and Owen for at least the reasons set forth in the Institution
`Decision.” PO Resp. 23 (citing Inst. Dec. 11–12). Patent Owner does not
`dispute Petitioner’s obviousness argument with respect to claims 12–17. See
`id. at 21–23. For the reasons explained below, we determine that Petitioner
`
`
`5 The revised claim construction standard for interpreting claims in inter
`partes review proceedings as set forth in the final rule published October 11,
`2018, does not apply to this proceeding because the new “rule is effective on
`November 13, 2018 and applies to all IPR, PGR and CBM petitions filed on
`or after the effective date.” 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) (to be codified at 37 C.F.R.
`pt. 42).
`
`7
`
`
`
`IPR2017-02047
`Patent 8,082,213 B2
`
`has not demonstrated by a preponderance of the evidence that claims 1–17
`would have been obvious over Harris and Owen.
`
`
`1. Harris
`Harris relates to user authentication based on multiple authentication
`factors. Ex. 1004, 2:35–38. To illustrate an example of user authentication
`according to Harris, Figure 7 is reproduced below.
`
`
`Figure 7 shows a system that uses two or more factors to authenticate a user
`to computer system 700 so that the computer system can process a request
`made by the user. Id. at 3:7–9, 18:9–16. When PC communication
`interface 720 receives a request from the user’s computer system 710, it
`
`8
`
`
`
`IPR2017-02047
`Patent 8,082,213 B2
`
`forwards the user’s request to request manager 740. Id. at 19:19–22.
`Request manager 740 signals first authentication manager 742, which then
`prompts the user for a user identifier and a password. Id. at 19:22–26. First
`authentication manager 742 compares the password received from the user
`to a password associated with the user that is stored in database 732. Id. at
`19:26–28. If the passwords match, first authentication manager 742
`provides the user identifier to request manager 740. Id. at 19:28–30.
`Request manager 740 forwards the user identifier and the user’s
`request to subsequent authentication identifier 744, which then tells request
`manager 740 the type and mode of any subsequent authentication factor that
`should be used to authenticate the user for the request. Id. at 19:31–35. If
`there is no such subsequent authentication factor, request manager 740 sends
`the user identifier and the request to service provider 760, which fulfills the
`request. Id. at 19:47–49. Otherwise, request manager 740 sends the type
`and mode of the second authentication factor and any third authentication
`factor to second authentication manager 750. Id. at 19:49–53.
`Second authentication manager 750 performs the second
`authentication based on the type and mode of the second authentication
`factor. Id. at 18:54–56. For example, the second authentication may require
`retrieving a device identifier from the user’s computer system, which is then
`compared with a device identifier registered for the user. Id. at 15:47–51.
`Alternatively, the second authentication may involve sending a secret to the
`user’s mobile device, which the user then enters into a web page for
`comparison with a stored secret for that user. Id. at 15:61–16:17. If the
`second authentication is successful, second authentication manager 750
`
`9
`
`
`
`IPR2017-02047
`Patent 8,082,213 B2
`
`signals request manager 740 and sends the type and mode of any third
`authentication factor to third authentication manager 752. Id. at 19:56–67.
`Third authentication manager 752 performs the third authentication.
`Id. at 20:16–19. If the third authentication is successful, third authentication
`manager 752 signals second authentication manager 750, which, in turn,
`signals request manager 740. Id. at 20:27–31. Request manager 740 then
`provides the user identifier and the user’s request to service provider 760,
`which fulfills the request. Id. at 20:31–33.
`
`
`2. Owen
`Owen also relates to multi-factor user authentication. Ex. 1006, 1:9–
`11. Owen describes a system with an authentication server that offers
`administrative utility for the management of server components. Id. at 24:3–
`4. For example, the authentication server allows for the creation,
`modification, enablement, and disablement of each component used. Id. at
`24:4–6.
`
`
`3. Analysis
`The challenged claims can be divided into two sets of claims:
`claims 1–11 and claims 12–17. We address each set of claims in turn.
`
`
`a. Claims 1–11
`Independent claim 1, which is directed to a user-authentication
`service, recites an “authentication interface by which . . . the
`authentication-service client submits an authentication request . . . to
`authenticate the user.” For this limitation, Petitioner relies on Harris. In
`
`10
`
`
`
`IPR2017-02047
`Patent 8,082,213 B2
`
`particular, Petitioner provides an annotated version of Figure 7 of Harris,
`which is reproduced below. Pet. 25–26.
`
`
`
`Figure 7 of Harris, as annotated by Petitioner
`
`As discussed above, Figure 7 illustrates a system for authenticating a user to
`computer system 700 so that the computer system can process a request
`made by the user. Ex. 1004, 3:7–9, 18:9–16. Petitioner identifies Harris’s
`PC communication interface 720 as an “authentication interface” and
`Harris’s service provider 760 as an “authentication-service client.” Pet. 25–
`26. Petitioner further argues that Harris “describ[es] that a service provider
`(i.e., the claimed ‘client’) submits an authentication request through a second
`
`11
`
`
`
`IPR2017-02047
`Patent 8,082,213 B2
`
`communications medium to the authenticating service, via an authentication
`interface, to authenticate the user.” Id. at 25. As support, Petitioner asserts
`that Harris teaches that
`“[w]hen the user makes a request [to the service provider], it may
`be made to a portion of the site that PC communication interface
`720 identifies as a request, and so [the service provider, via] PC
`communication interface 720 forwards the request to request
`manager 740 [which is part of the authentication service] . . . [If
`authentication is successful, r]equest manager 740 then provides
`the request and user identifier to [the service provider], which
`provides the service.”
`Id. at 26–27 (quoting Ex. 1004, 19:19–30) (alterations and omission added
`by Petitioner).
`We are not persuaded by Petitioner’s argument. Petitioner interprets
`Harris’s PC communication interface 720 as providing an interface between
`service provider 760 and what Petitioner refers to as the “authentication
`modules.” Id. at 26; see also Pet. Reply 20 (“Harris discloses, or at least
`renders obvious, that interface 720 is used by service provider 760 to
`communicate with the other components of system 700.”). We understand
`such modules to comprise what Petitioner identifies as an “authentication
`service.” See Pet. 26 (annotated version of Figure 7 of Harris). However,
`Harris teaches that “[c]omputer system 710 communicates over a network
`such as the Internet with authentication and service system 700 via PC
`communication interface 720.” Ex. 1004, 18:22–24. That is, Harris’s PC
`communication interface 720 provides an interface between the user and
`system 700, which includes service provider 760 as well as the
`authentication modules. See id. at 18:28–32 (“When the user connects to a
`registration portion of a web site hosted by authentication and service
`
`12
`
`
`
`IPR2017-02047
`Patent 8,082,213 B2
`
`system 700 via PC communication interface 720, PC communication
`interface 720 provides the connection to registration manager 730.”); id. at
`19:19–22 (“When the user makes a request, . . . PC communication
`interface 720 forwards the request to request manager 740.”). As we stated
`in our Institution Decision, Petitioner does not point us to any persuasive
`evidence showing that service provider 760 uses PC communication
`interface 720 to communicate with other components of system 700. Inst.
`Dec. 11. Indeed, Figure 7 of Harris shows that service provider 760 can
`communicate directly with other components of system 700 without going
`through PC communication interface 720. See Ex. 1004, Fig. 7; see also id.
`at 19:48–49 (“[R]equest manager 740 provides the request and user
`identifier to service provider 760.”).
`In its Reply, Petitioner contends that “Harris teaches, or at least
`renders obvious, that the web site is provided by service provider 760.” Pet.
`Reply 21–22. As support, Petitioner points us to where Harris teaches that
`service provider 760 “fulfills the request” or “provides the service.” Id.
`(citing Ex. 1004, 19:47–49, 20:32–33). Petitioner additionally points us to
`where Harris teaches that, “[w]hen the user connects to a registration portion
`of a web site hosted by authentication and service system 700 via PC
`communication interface 720, PC communication interface 720 provides the
`connection to registration manager 730.” Id. at 21 (citing Ex. 1004, 18:28–
`32). According to Petitioner, “the web site submits the registration request
`of the user via interface 720 to the authentication modules.” Id. Petitioner
`asserts that Harris “states that this process applies for ‘requests’ generally.”
`Id. (citing Ex. 1004, 19:19–22).
`
`13
`
`
`
`IPR2017-02047
`Patent 8,082,213 B2
`
`
`We remain unpersuaded by Petitioner. Even if the web site in Harris
`is provided by service provider 760, Petitioner still has not directed us to any
`persuasive evidence showing that service provider 760 uses PC
`communication interface 720 to communicate with other components of
`system 700. For example, as Petitioner points out, Harris teaches that,
`“[w]hen the user connects to a registration portion of a web site . . . via PC
`communication interface 720, PC communication interface 720 provides the
`connection to registration manager 730.” Ex. 1004, 18:28–32 (cited by Pet.
`Reply 21). Similarly, Harris also teaches that, “[w]hen the user makes a
`request . . . to a portion of the site . . . [,] PC communication interface 720
`identifies . . . and . . . forwards the request to request manager 740.” Id. at
`19:19–22 (cited by Pet. Reply 21). These teachings do not describe service
`provider 760 using PC communication interface 720 to communicate with
`registration manager 730 or request manager 740.
`Rather, the teachings in Harris indicate that PC communication
`interface 720 actively screens incoming communications from the user and
`forwards them to other components of system 700. In the latter scenario
`discussed above, once the user is authenticated, request manager 740 sends
`the user’s request to service provider 760 to be fulfilled. Id. at 19:47–49 (“If
`the type of any subsequent authentication factor is ‘none’, request manager
`740 provides the request and user identifier to service provider 760, which
`fulfills the request.”), 20:25–33 (“[S]econd authentication manager 750
`returns an indication that the user was authenticated to request manager 740.
`Request manager 740 then provides the request and user identifier to service
`provider 760, which provides the service.”); see also id. at 20:34–38 (“In
`one embodiment, subsequent authentication identifier 744 may also provide
`
`14
`
`
`
`IPR2017-02047
`Patent 8,082,213 B2
`
`to request manager 740 any additional authentication criteria and request
`manager 740 does not provide the request to service provider 760 until the
`additional authentication criteria are met.”). Accordingly, Harris’s PC
`communication interface 720 and what Petitioner identifies as the
`“authentication service” (see Pet. 26 (annotated version of Figure 7 of
`Harris)) function together much like a security guard who screens persons
`seeking access to a building. A person cannot enter the building to access
`any part of it until after the security guard has determined that the person
`carries the proper credentials for access.
`Moreover, with respect to the recited “authentication request,”
`Petitioner relies on Harris’s teaching that PC communication interface 720
`forwards “the request” to request manager 740. Pet. 26–27 (citing Ex 1004,
`19:19–30). As we explained in our Institution Decision (Inst. Dec. 12),
`however, that request in Harris refers to the user’s request for service, not an
`authentication request to authenticate the user. See Ex. 1004, 15:23–29
`(“After [registration] steps 402-408 . . . , the user can then authenticate
`himself or herself as part of a request for service.”), 19:19–30 (“When a user
`makes a request, . . . PC communication interface 720 forwards the request
`to request manager 740.”).
`We also noted (Inst. Dec. 12) that the only component in Harris that
`seems to make an authentication request is request manager 740, not service
`provider 760. See Ex. 1001, claim 1 (reciting “the authentication-service
`client submits an authentication request”). For example, Harris teaches that
`the “[r]equest manager signals first authentication manager 742, which
`prompts the user for his or her user identifier and password,” and that “[f]irst
`authentication manager 742 compares the password to that associated with
`
`15
`
`
`
`IPR2017-02047
`Patent 8,082,213 B2
`
`the user in database 732.” Ex. 1004, 19:19–30. Thus, it is request
`manager 740 that submits an authentication request to first authentication
`manager 742 to authenticate the user.
`In its Reply, Petitioner argues that “Harris discloses, or at least
`renders obvious, that the requests mentioned in columns 18–20 are
`authentication requests, not simply service requests.” Pet. Reply 23. For
`instance, Petitioner contends, “The initial description of Figure 7 makes it
`clear that the type of service requests being made are ones that require
`authentication.” Pet. Reply 23 (citing Ex. 1004, 18:9–16, 19:19–30).
`Petitioner also contends that “Harris teaches that the authentication
`managers within the authentication and service system 700 seek
`authentication of the user before the user is granted access to the requested
`service.” Id. at 24. In addition, Petitioner contends that, “while Harris
`discusses a user sending a request and then later being prompted for
`authentication credentials, Harris also teaches the option that the user can
`send a request along with authentication credentials.” Id. at 25–26 (internal
`citation omitted) (citing Ex. 1004, 15:30–32).
`We disagree with Petitioner. That the service requests in Harris
`require authentication or that authentication is sought prior to fulfilling a
`request does not mean necessarily that the service requests are authentication
`requests. Harris teaches explicitly that “[t]he request for service may be a
`request for a web page, a request for access, such as physical access to a
`location, or a request for an action to be performed, such as the transfer of
`cash or securities from one account to another account.” Ex. 1004, 15:23–
`29. Contrary to what Petitioner argues, such requests are not by themselves
`authentication requests. See Pet. Reply 24 (“Harris discloses that a request
`
`16
`
`
`
`IPR2017-02047
`Patent 8,082,213 B2
`
`from a user to access the web site hosted by service provider 760 is an
`authentication request because the user must provide sufficient security
`credentials to access the web site.”). As discussed above, we find that an
`authentication request occurs in Harris when request manager 740 signals
`first authentication manager 742, which then prompts the user for the user’s
`identifier and password and compares the password to the password
`associated with the user in database 732. See Ex. 1004, 19:19–30. Our
`finding is consistent with the teachings in the ’213 patent. In particular, the
`’213 patent teaches that “[t]he user 302 may initialize 304 an electronic
`transaction with the ASP client 306, such as by requesting to logon to a
`commercial website or requesting a product or service through an electronic
`medium,” and that “[t]he ASP client then transmits an authentication
`request 308 to the ASP 310 . . . to determine whether or not the user is
`authentic, so that the electronic transaction can proceed to completion.”
`Ex. 1001, 3:48–59. The service requests in Harris are like the electronic
`transaction in the ’213 patent, and the signal from request manager 740 to
`authentication manager 742 in Harris is like the authentication request in the
`’213 patent.
`Turning now to Petitioner’s reading of Harris’s teachings in the
`alternative (i.e., Petitioner’s reading that Harris teaches providing
`authentication credentials either after sending a request or along with the
`request), we note that Harris describes “a method of authenticating a user”
`that “involves several subprocesses,” including “Registration,” “Request for
`Service and Identification of the Factors,” “Authentication Using the Second
`Factor Identified,” and “Check for Other Authentication Steps, Provide
`Service when all are Completed.” Ex. 1004, 14:47–52, 15:22, 15:45, 16:63–
`
`17
`
`
`
`IPR2017-02047
`Patent 8,082,213 B2
`
`64. Figures 4A, 4B, 4C, and 4D provide flowcharts of Harris’s method, and
`Figure 7 shows a system for carrying out the method. Id. at 2:62–65
`(“FIG. 4, consisting of FIGS. 4A, 4B, 4C, and 4D, is a flowchart illustrating
`a method of authenticating one or more users using two or more factors.”),
`3:7–9 (“FIG. 7 is a system for authenticating a user using two or more
`factors.”). Accordingly, the descriptions of these figures should be read
`together, not in the alternative. For example, with respect to Figure 4B,
`Harris teaches that “the user may make the request for a service 410 and
`provides the user identifier and password of the user.” Ex. 1004, 15:30–32
`(cited at Pet. Reply 26). With respect to Figure 7, Harris teaches that,
`“[w]hen the user makes a request, . . . PC communication interface 720
`forwards the request to request manager 740,” and “[r]equest manager
`signals first authentication manager 742, which prompts the user for his or
`her user identifier and password.” Ex. 1004, 19:19–30 (cited by Pet.
`Reply 25). Read together, these teachings indicate that Harris’s step 410 of
`Figure 4B, in which the user makes a request for a service and provides the
`user’s identifier and password, is carried out by the system of Figure 7,
`where the user makes a request, PC communication interface 720 forwards
`the request to request manager 740, request manager 740 signals first
`authentication manager 742, and first authentication manager 742 prompts
`the user for the user’s identifier and password. That is, the description of the
`system of Figure 7 provides implementation details for the method steps of
`Figure 4B.
`We note Patent Owner’s contention that, “[f]or the first time in its
`Reply, [Petitioner] now argues that Harris discloses or at least renders
`obvious claim 1’s recitation of ‘an authentication interface by which,
`
`18
`
`
`
`IPR2017-02047
`Patent 8,082,213 B2
`
`following initiation of a transaction by the user with the authentication-
`service client, the authentication-service client submits an authentication
`service request.’” PO Sur-Reply 6. According to Patent Owner, “[t]he
`inclusion of this new argument is improper . . . and alone is grounds for the
`Board to refuse to consider the Reply in its entirety.” Id. Because we are
`unpersuaded by Petitioner’s arguments for the reasons given above, we need
`not address Patent Owner’s contention in this regard.
`In view of the foregoing, we determine that Petitioner has not
`demonstrated by a preponderance of the evidence that independent claim 1
`would have been obvious over Harris and Owen. As claims 2–11 depend
`from claim 1, we determine that Petitioner also has not demonstrated by a
`preponderance of the evidence that these dependent claims would have been
`obvious over Harris and Owen.
`
`
`b. Claims 12–17
`Independent claim 12 recites the step of “receiving user-identifying
`information from the authentication-service client.” For this limitation,
`Petitioner also relies on Harris. Specifically, Petitioner contends that Harris
`teaches that “the user may make the request for a service 410 and provides
`the user identifier and password of the user [to the client],” where “[t]he user
`identifier identifies the user.” Pet. 45 (citing Ex. 1004, 15:30–33, Fig. 4B).
`Petitioner also contends that “this information is sent from the client to the
`authentication system to perform the additional authentication procedures.”
`Id. Lastly, Petitioner contends that step 410 in Figure 4B of Harris “shows
`the authentication service ‘receiving user-identifying information from the
`authentication-service client.’” Id. (citing Ex. 1004, 15:30–44, Fig. 4B).
`
`19
`
`
`
`IPR2017-02047
`Patent 8,082,213 B2
`
`
`We disagree. The cited passage in Harris at column 15, lines 30–44,
`teaches that the user “provides the user identifier and password of the user”
`but does not indicate to which component the user information is being
`provided. In addition, Figure 4B is silent as to which component is
`providing the user information at step 410, indicating only that the
`information is received: “RCV REQ FOR SVC, USER ID, PASSWORD.”
`Petitioner’s theory that Harris’s “client” (i.e., service provider 760)
`receives the user identifier from the user and provides it to the authentication
`system at step 410 seems inconsistent with other teachings in Harris. For
`example, Harris teaches that first authentication manager 742 prompts the
`user for a user identifier and a password, and, if the password matches a
`password that is stored in a database, provides the user identifier to request
`manager 740. Ex. 1004, 19:22–30. Next, request manager 740 forwards the
`user identifier to subsequent authentication identifier 744 to determine if
`further authentication is needed. Id. at 19:31–35. If further authentication is
`needed, subsequent authentication identifier 744 provides information about
`the authentication factors to be used to request manager 740, which forwards
`the information to the authentication managers to carry out further
`authentication steps. Id. at 19:49–53. Once the user is authenticated,
`request manager 740 forwards the user identifier along with the user’s
`request to service provider 760, which then fulfills the request. Id. at 19:47–
`49, 20:26–38. That is, the user identifier flows from the user to first
`authentication manager 742, then to request manager 740, and then to
`subsequent authentication identifier 744. The user identifier also flows from
`request manager 740 to service provider 760. Thus, Harris describes
`
`20
`
`
`
`IPR2017-02047
`Patent 8,082,213 B2
`
`providing the user identifier to service provider 760 but not receiving the
`user identifier from service provider 760.
`We note that Petitioner does not address further in its Reply its
`assertion that claim 12 would have been obvious over Harris and Owen. See
`generally Pet. Reply. In view of the foregoing, we determine that Petitioner
`has not demonstrated by a preponderance of the evidence that independent
`claim 12 would have been obvious over Harris and Owen. As claims 13–17
`depend from claim 12, we determine that Petitioner also has not
`demonstrated by a preponderance of the evidence that these dependent
`claims would have been obvious over Harris and Owen.
`
`
`C. Obviousness over Vandergeest and Delany: Claims 1–10
`Petitioner argues that claims 1–10 of the ’213 patent would have been
`obvious over Vandergeest and Delany. Pet. 50–80. Patent Owner counters
`that the combination of Vandergeest and Delany does not teach the recited
`“variable-factor authentication.” PO Resp. 9. For the reasons explained
`below, we determine that Petitioner has demonstrated by a preponderance of
`the evidence that claims 1–10 would have been obvious over Vandergeest
`and Delany.
`
`
`1. Vandergeest
`Vandergeest relates to user authentication using multi-factor
`techniques. Ex. 1005, 1:15–19. To illustrate an example of user
`authe