throbber
Trials@uspto.gov
`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

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


Or .

Accessing this document will incur an additional charge of $.

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

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket