Trials@uspto.gov
`571.272.7822
`
`Paper No. 7
`Filed: October 16, 2017
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`DUO SECURITY INC., CENTRIFY CORPORATION, and
`TRUSTWAVE HOLDINGS, INC.,
`Petitioner,
`
`v.
`
`STRIKEFORCE TECHNOLOGIES, INC.,
`Patent Owner.
`____________
`
`Case IPR2017-01041
`Patent 8,484,698 B2
`____________
`
`Before KERRY BEGLEY, KIMBERLY MCGRAW, and
`JOHN A. HUDALLA, Administrative Patent Judges.
`
`BEGLEY, Administrative Patent Judge.
`
`
`DECISION
`Denying Institution of Inter Partes Review
`37 C.F.R. § 42.108
`
`
`
`
`Duo Security Inc., Centrify Corporation, and Trustwave Holdings,
`Inc. (collectively, “Petitioner”) filed a Petition requesting inter partes review
`of claims 1–3, 5–7, 15, 20–24, and 48–54 of U.S. Patent No. 8,484,698 B2
`(Ex. 1001, “’698 patent”). Paper 2 (“Pet.”). StrikeForce Technologies, Inc.
`(“Patent Owner”) filed a Preliminary Response. Paper 6 (“Prelim. Resp.”).
`
`

`

`IPR2017-01041
`Patent 8,484,698 B2
`Pursuant to 35 U.S.C. § 314(a), an inter partes review may not be
`instituted unless “the information presented in the petition . . . and any
`response . . . shows that there is a reasonable likelihood that the petitioner
`would prevail with respect to at least 1 of the claims challenged in the
`petition.” Having considered the Petition and the Preliminary Response, we
`determine that the information presented does not show that there is a
`reasonable likelihood that Petitioner would prevail in establishing the
`unpatentability of any of the challenged claims of the ’698 patent. Thus, for
`the reasons given below, we deny institution of an inter partes review.
`I. BACKGROUND
`A. RELATED MATTERS
`The parties represent that the ’698 patent is the subject of numerous
`
`ongoing and completed actions before various district courts. Paper 3, 2–3;
`Pet. 5. In actions before the U.S. District Court for the District of New
`Jersey, Patent Owner alleges that Petitioner infringes the ’698 patent (Case
`Nos. 2:16-cv-03571, 2:16-cv-03573, and 2:16-cv-03574). Paper 3, 2; Pet. 5.
`
`In addition, before the Office, the ’698 patent also is the subject of
`IPR2017-01064, filed by Petitioner. Pet. 5–6; Paper 3, 2.
`B. THE ’698 PATENT
`The ’698 patent is directed to security systems that provide user
`
`authentication. Ex. 1001, 1:20–25. According to the ’698 patent, prior art
`authentication systems typically are in-band systems in which data and
`authentication information are exchanged on a single channel. Id. at 2:31–
`3:14, 5:63–6:12, Fig. 1. To increase security, the ’698 patent instead
`implements an out-of-band system with “an authentication channel that is
`separated from the [access] channel carrying the information . . . for actual
`information transfer.” Id. at 3:14–20, 4:52–57, 6:9–23; see id. at 1:20–25.
`2
`
`
`
`

`

`IPR2017-01041
`Patent 8,484,698 B2
`
`In particular, the ’698 patent discloses a multichannel, out-of-band
`security system for granting or denying access to a host computer in
`response to a user’s access request. Id. at [57], 4:34–36. In the first
`authentication factor, the user seeking access to the host computer presents
`user identification and password data over an access channel. Id. at [57],
`4:36–39. This information is intercepted and transmitted to a security
`computer, which verifies the information. Id. at [57], 4:35–36. Next, in the
`second authentication factor, the security computer communicates with the
`user through a peripheral device, such as a telephone, within a separate
`authentication channel. Id. at [57], 4:39–42. The security computer
`authenticates the user via a password entered on the telephone keypad and
`may further authenticate the user using a biometric system, which controls
`access based on “characteristics of the human body,” such as fingerprints or
`voice. Id. at [57], 2:13–17, 4:39–46, 6:47–59. Upon obtaining a match, the
`security computer instructs the host computer to grant access. Id. at [57].
`
`One embodiment of the disclosed security system is illustrated in
`Figure 1A, reproduced below. Id. at 5:17–20, 6:30–33, Cert. of Corr.
`
`
`
`
`3
`
`

`

`IPR2017-01041
`Patent 8,484,698 B2
`Figure 1A depicts first embodiment 20 applied to a wide area network, such
`as the Internet, where the user seeking access and its equipment are remote
`from the host computer. Id. at 5:17–20, 6:14–18, 6:30–33; see id. at 5:43–
`45, 6:34–59, 9:10–12:26, Figs. 9A–E. In access network 30, user 24 using
`remote computer 22 requests access to web page 32 located at host
`computer 34. Id. at 6:33–40, 9:24–27. In the first authentication factor, host
`computer 34 requests a login procedure in which the user is prompted to
`enter a user identification and password. Id. at 9:27–33. After the user
`enters this information, router 36, internal to corporate network 38, diverts
`the information to out-of-band security network 40 containing security
`computer 52, where authentication occurs. Id. at 6:40–42, 6:60–66, 9:33–
`35. Security computer 52 verifies the password using stored password
`information. Id. at 9:36–54; see id. at 7:11–25. Upon verification, security
`computer 52 sends a verification message to host computer 34, which
`transmits the message to remote computer 22. Id. at 9:55–10:19, Fig. 9B.
`In the second authentication factor, security computer 52 initiates an
`out-of-band telephone call to user 24. Id. at 6:35–37, 10:20–30. When the
`user answers telephone 26, security computer 52 retrieves and plays for the
`user a prompt to enter a dual tone multi frequency (“DTMF”) password on
`the telephone keypad. Id. at 10:30–48, 15:50–55, 17:19–20. Security
`computer 52 verifies the DTMF password entered by the user. Id. at 10:48–
`65. Security computer 52 then retrieves and plays for the user a prompt for a
`speech password. Id. at 11:10–37. Using voice recognition technology,
`security computer 52 verifies that the speech password received from
`user 24 has the same pattern as a previously stored sample of the user’s
`speech pattern. Id. at 11:26–30, 11:37–42; see id. at 6:47–59. After
`verifying that the stored and received speech patterns match, security
`4
`
`
`
`

`

`IPR2017-01041
`Patent 8,484,698 B2
`computer 52 informs the user that access is granted and sends an
`authentication message to host computer 34. Id. at 11:57–12:24. Host
`computer 34 then grants access to the authenticated user. Id. at 12:24–26.
`C. ILLUSTRATIVE CLAIM
`Of the challenged claims, claims 1, 48, 53, and 54 of the ’698 patent
`are independent. Claim 1, reproduced below, is illustrative:
`1. A software method for employing a multichannel security
`system to control access to a computer, comprising the steps of:
`receiving at an interception device in a first channel a login
`identification demand to access a host computer also in the
`first channel;
`verifying the login identification;
`receiving at a security computer in a second channel the
`demand for access and the login identification;
`outputting from the security computer a prompt requesting
`transmission of data;
`receiving the transmitted data at the security computer;
`comparing the transmitted data to predetermined data; and
`depending on the comparison of the transmitted and the
`predetermined data, outputting an instruction from the
`security computer to the host computer to grant access to
`the host computer or deny access thereto.
`Ex. 1001, 14:30–46.
`
`D. EVIDENCE OF RECORD
`The Petition relies upon the following asserted prior art references:
`U.S. Patent No. 5,699,513 (issued Dec. 16, 1997) (Ex. 1003, “Feigen”);
`U.S. Patent No. 5,736,932 (issued Apr. 7, 1998) (Ex. 1004, “Bulfer”);
`U.S. Patent No. 5,668,876 (issued Sept. 16, 1997) (Ex. 1005, “Falk”); and
`International Publication No. WO 99/44114 (published Sept. 2, 1999)
`(Ex. 1006, “Turtiainen”).
`In addition, Petitioner supports its contentions with the Declaration of
`Patrick McDaniel, Ph.D. (Ex. 1002).
`
`
`
`5
`
`

`

`IPR2017-01041
`Patent 8,484,698 B2
`E. ASSERTED GROUNDS OF UNPATENTABILITY
`Petitioner asserts the following grounds of unpatentability under
`35 U.S.C. § 103.1 Pet. 8–9.
`References
`Challenged Claims
`1–3, 5–7, 15, 20–24, and 48–54 Feigen, Bulfer, and Falk
`50 and 52
`Feigen, Bulfer, Falk, and Turtiainen
`
`II. ANALYSIS
`A. CLAIM CONSTRUCTION
`The Board interprets claim terms of an unexpired patent using the
`“broadest reasonable construction in light of the specification of the patent.”
`37 C.F.R. § 42.100(b); see Cuozzo Speed Techs., LLC v. Lee, 136 S. Ct.
`2131, 2144–46 (2016) (upholding the use of the broadest reasonable
`interpretation standard). We presume a claim term carries its “ordinary and
`customary meaning,” which is the meaning “the term would have to a person
`of ordinary skill in the art” at the time of the invention. In re Translogic
`Tech., Inc., 504 F.3d 1249, 1257 (Fed. Cir. 2007) (citation omitted).
`Here, based on our review of the record and the dispositive issues in
`our determination of whether to institute inter partes review, we determine
`that no claim terms of the ’698 patent require an express construction to
`resolve the issues presented by the patentability challenges. See Vivid
`Techs., Inc. v. Am. Sci. & Eng’g, Inc., 200 F.3d 795, 803 (Fed. Cir. 1999)
`(holding that only claim terms that “are in controversy” need to be construed
`and “only to the extent necessary to resolve the controversy”).
`
`1 The Leahy-Smith America Invents Act (“AIA”), Pub. L. No. 112–29,
`125 Stat. 284, 287–88 (2011), revised 35 U.S.C. § 103, effective March 16,
`2013. Because the application that issued as the ’698 patent was filed before
`this date, we refer to the pre-AIA version of § 103 throughout this Decision.
`
`
`
`6
`
`

`

`IPR2017-01041
`Patent 8,484,698 B2
`B. ALLEGED OBVIOUSNESS OVER FEIGEN, BULFER, AND FALK
`Petitioner argues claims 1–3, 5–7, 15, 20–24, and 48–54 of the
`’698 patent would have been obvious over Feigen, Bulfer, and Falk.
`Pet. 36–66. Patent Owner disputes these assertions. Prelim. Resp. 24–62.
`1. Overview of Feigen
`Feigen provides an “improved method and apparatus for providing
`
`security for a communication network” through “user authentication.”
`Ex. 1003, 7:55–58; see id. at 1:5–13, 1:56–2:12, 7:57–67. In particular,
`Feigen provides security for inside network 14 via security host 26, which
`ensures that only users who are authentic and “authorized to do so may
`access application services residing on inside network 14.” Id. at [57], 2:57–
`3:3. Figure 1 of Feigen is reproduced below.
`
`
`Figure 1 depicts computer network environment 10 with inside network 14
`and outside network 12, which preferably is the Internet. Id. at 2:20–23,
`
`
`
`7
`
`

`

`IPR2017-01041
`Patent 8,484,698 B2
`2:36–47. Outside network 12 features transmission media 18, coupled to
`remote networks 20, which contain source hosts 22 running client
`applications. Id. at 2:48–54. Inside network 14, in turn, features
`transmission media 24, which is coupled to filter 16, security host 26, and
`destination hosts 28. Id. at 2:61–64. Within inside network 14, a security
`service runs on security host 26 and application services run on destination
`hosts 28. Id. at 2:63–3:1, 3:16–18. Filter 16, located between outside
`network 12 and inside network 14, is “desirably . . . a conventional filtering
`device, such as a router, bridge, gateway, or the like.” Id. at 2:39–41, 3:3–9.
`When a client application running on source host 22 in outside
`network 12 requests a connection, via a first connection request message,
`with an application service running on destination host 28 in inside
`network 14, filter 16 recognizes that the connection request has a source
`address in outside network 12 and a destination address in inside
`network 14. Id. at 3:46–50, 3:66–4:6, Fig. 2 (entry 52); see id. at 3:66–7:54,
`Figs. 3–5. Accordingly, “filter 16 routes this first connection request to
`security host 26,” which “intercept[s]” the request and “prevents it from
`being transmitted within inside network 14.” Id. at 4:6–9, 5:5–8; see id.
`at [57], 3:60–65, Fig. 3. Source host 22 then sends a second connection
`request message, requesting connection to the security service on security
`host 26. Id. at 4:12–14; see id. at 5:27–32. The security service begins a
`communication session with source host 22. Id. at 4:19–22, 6:44–50.
`During this session, the security service confirms the first connection
`request by authenticating and authorizing the user operating source host 22.
`Id. at [57], 4:23–25. Specifically, the security service performs a one-factor
`authentication in which the service prompts the user to enter user
`identification data and determines whether the received data “indicate[] that
`8
`
`
`
`

`

`IPR2017-01041
`Patent 8,484,698 B2
`the user is an authentic user.” See id. at 6:50–59. In the preferred
`embodiment, this authentication uses a one-time password, but the
`“strength” of the authentication process “may vary in accordance with the
`needs of network 14.” Id. at 6:59–67. If the security service confirms the
`user’s authenticity, it proceeds to determine whether the user is authorized to
`access the requested application service on destination host 28 by, for
`example, considering user privileges. Id. at 7:33–41. If the security service
`fails to confirm the user’s authenticity or authorization, it sends a “failed
`access message” to the client and continues to prevent the request “from
`being released onto inside network 14,” thereby preventing connection with
`destination host 28. Id. at 7:1–7, 7:41–45.
`Upon confirming that the user is authentic and authorized to access
`the requested application service on destination host 28, the security service
`on security host 26 “releases . . . to inside network 14” the “first connection
`request [that] it ha[d] intercepted.” Id. at [57], 4:25–27, 5:53–57, 7:45–49,
`Figs. 3, 5. The targeted application service at destination host 28 “then
`acknowledge[s] the connection request” and “a communication session . . .
`commence[s].” Id. at 4:27–30, 7:49–51; see id. at [57], 5:57–59.
`2. Overview of Bulfer
`Bulfer is directed to controlled access systems with improved security
`
`to ensure that a user attempting to gain access is authorized to do so.
`Ex. 1004, 1:5–12, 1:31–32. According to Bulfer, some situations, such as a
`user with high level access to a secure building, may warrant a higher level
`of security than access systems that require a user to enter only “intangible
`security information,” such as a personal identification number (“pin” or
`“PIN”) or password, can provide. Id. at 1:13–30. Therefore, Bulfer
`provides a two-factor authentication system that requires the user not only to
`9
`
`
`
`

`

`IPR2017-01041
`Patent 8,484,698 B2
`enter user identification data but also to have a particular wireless remote
`communication device, such as a pager or cellular telephone, and to enter
`revalidation information that the system sends to this device. Id. at [57],
`1:33–46; see id. at 3:6–8, Figs. 2–3.
`
`In one embodiment, user 10 requests access to secured system 30 via
`communication link 20. Id. at 2:38–40, 3:50–54. In the first authentication
`factor, system 30 requires the user to enter information that identifies the
`user, such as a pin or password, and checks the validity of this information.
`Id. at 2:50–54, 2:56–59, 3:50–64. If the information is valid, the system
`proceeds to the second authentication factor, which requires the user to enter
`revalidation information into a particular wireless remote communication
`device 70’ that the user is required to have. Id. at 1:50–60, 3:1–21, 4:12–55,
`Fig. 3. Specifically, system 30 identifies the user’s device 70’; generates
`revalidation information, such as a “random or substantially random
`number”; and sends a message via communication link 40’ to wireless
`communication system 50’ that can communicate with device 70’. Id.
`at 3:1–30, 4:12–24, 4:65–5:8, Fig. 3. This message instructs system 50’ to
`call device 70’, via wireless communication link 60’, and to send device 70’
`a message with the revalidation information that user 10 “must send back to
`system 30.” Id. at 3:22–26, 4:24–26, 4:65–5:8, Fig. 3. Device 70’ then may
`display the revalidation information for user 10 and prompt the user to enter
`the information. Id. at 3:29–31, 4:26–34, 4:65–5:8; see id. at 4:27–30.
`User 10 may send this message back to system 30 via a return channel
`through device 70’, link 60’, system 50’, and link 40’. Id. at 3:32–37, 4:35–
`44, 4:65–5:8, Fig. 3. Next, system 30 compares the revalidation information
`that it sent and received. Id. at 4:45–49. If the information matches,
`system 30 allows access to the user. Id.
`10
`
`
`
`

`

`IPR2017-01041
`Patent 8,484,698 B2
`
`3. Overview of Falk
`Falk provides an authentication system and procedure that requires a
`
`user attempting to access an electronic service to carry a separate personal
`unit. Ex. 1005, [57], 1:5–9, 1:65–2:5. In particular, in Falk’s two-factor
`authentication system, the user must know the appropriate user PIN and
`possess the correct personal unit 20, which calculates a response code based
`on the PIN, a received challenge code, and an internal secret key. See id.
`at [57], 4:32–37, 5:4–7, 5:30–34, 5:45–47, 7:5–7, Fig. 3.
`Falk’s authentication process begins when a user at terminal 22 (e.g.,
`a telephone or computer) initiates a request for access to service node 26 by
`transmitting the request over service access network 24 to service node 26.
`Id. at 3:8–13, 5:20–24, 6:3–6. “[S]ervice node 26, in response to the access
`request, requests authentication via an authentication challenge network 28.”
`Id. at 6:12–15; see id. at 6:63–67. Service node 26 generates, or causes
`authentication center 30 to generate, a challenge code, which is sent to
`personal unit 20 (e.g., a pager). Id. at 5:25–29; see id. at [57], 3:4–9, 4:8–31,
`6:15–18. Personal unit 20 then prompts the user to input a PIN and
`generates a response code using a stored algorithm, based on the PIN, the
`challenge code, and a secret key. Id. at 5:29–34, 5:45–47; see id. at [57],
`6:19–22, 7:5–7. Next, personal unit 20 may display the response code, the
`user may manually input the response code into terminal 22, and the code
`may be transmitted to authentication center 30. See id. at 5:48–54, 6:31–45.
`Authentication center 30 compares the received response code to an
`expected response code. Id. at 5:54–62, 6:41–42, 7:14–15. Authentication
`center 30 then may send a message to “inform . . . service node 26 of the
`results,” i.e., whether the user is “authenticated/not authenticated.” Id.
`at 5:55–57, 6:46–48, 7:14–17. If the response code is acceptable and the
`11
`
`
`
`

`

`IPR2017-01041
`Patent 8,484,698 B2
`user is authenticated, service node 26 permits the user access to its services.
`Id. at 5:57–59, 6:55–58, Fig. 3. If, however, the response code is not
`acceptable and the user is not authenticated, service node 26 denies the user
`access to its services. Id. at 6:48–50, Fig. 3.
`4. Alleged Motivation to Combine Feigen, Bulfer, and Falk
`(Claims 1–3, 5–7, 15, 20–24, and 48–54)
`a. Legal Standards
`A patent claim is unpatentable as obvious under 35 U.S.C. § 103(a) if
`“the differences between” the recited subject matter “and the prior art are
`such that the subject matter as a whole would have been obvious at the time
`the invention was made to a person having ordinary skill in the art to which
`said subject matter pertains.” 35 U.S.C. § 103(a). An invention “composed
`of several elements is not proved obvious merely by demonstrating that each
`of its elements was, independently, known in the prior art.” KSR Int’l Co. v.
`Teleflex Inc., 550 U.S. 398, 418 (2007). Rather, to establish obviousness, it
`is petitioner’s “burden to demonstrate both that a skilled artisan would have
`been motivated to combine the teachings of the prior art references to
`achieve the claimed invention, and that the skilled artisan would have had a
`reasonable expectation of success in doing so.” In re Magnum Oil Tools
`Int’l, Ltd., 829 F.3d 1364, 1381 (Fed. Cir. 2016) (quotations omitted); see
`KSR, 550 U.S. at 418. Moreover, a petitioner cannot satisfy this burden by
`“employ[ing] mere conclusory statements” and “must instead articulate
`specific reasoning, based on evidence of record,” to support an obviousness
`determination. Magnum Oil, 829 F.3d at 1380. Stated differently, there
`must be “articulated reasoning with some rational underpinning to support
`the legal conclusion of obviousness.” KSR, 550 U.S. at 418 (quoting In re
`Kahn, 441 F.3d 977, 988 (Fed. Cir. 2006)).
`
`
`
`12
`
`

`

`IPR2017-01041
`Patent 8,484,698 B2
`The “factual inquiry” into the reasons for “combin[ing] references
`must be thorough and searching, and the need for specificity pervades . . . .”
`In re Nuvasive, Inc., 842 F.3d 1376, 1381–82 (Fed. Cir. 2016) (quotations
`omitted). A determination of obviousness cannot be reached where the
`record lacks “explanation as to how or why the references would be
`combined to produce the claimed invention.” TriVascular, Inc. v. Samuels,
`812 F.3d 1056, 1066 (Fed. Cir. 2016); see Nuvasive, 842 F.3d at 1382–86
`(holding that an obviousness determination cannot be reached where there is
`no “articulat[ion of] a reason why a [person having ordinary skill in the art]
`would combine” and “modify” the prior art teachings). This required
`explanation as to how and why the references would be combined avoids an
`impermissible “hindsight reconstruction,” using “the patent in suit as a guide
`through the maze of prior art references, combining the right references in
`the right way so as to achieve the result of the claims in suit.” TriVascular,
`812 F.3d at 1066; In re NTP, Inc., 654 F.3d 1279, 1299 (Fed. Cir. 2011).
`b. Discussion
`
`Petitioner argues that one of ordinary skill in the art “would have been
`motivated to combine the teachings of Feigen, Bulfer, and Falk.” Pet. 40–
`45.2 As support, Petitioner asserts that Feigen discloses “single factor
`
`
`2 We note that, as Patent Owner argues, Petitioner’s arguments, along with
`Dr. McDaniel’s supporting testimony, regarding the proposed combinations
`and modifications of Feigen, Bulfer, and Falk are often vague and
`non-specific. See, e.g., Prelim. Resp. 45–51. To the extent Petitioner
`intended to proffer proposed combinations or modifications distinct from
`those we discuss below, Petitioner has not met its burden to state any such
`combinations or modifications clearly and with specificity (and, thus, to
`notify adequately Patent Owner and the Board of any such combinations and
`modifications). See Harmonic Inc. v. Avid Tech., Inc., 815 F.3d 1356, 1363
`
`
`
`
`13
`
`

`

`IPR2017-01041
`Patent 8,484,698 B2
`authentication” but “specifically suggests that the reader seek out stronger
`authentication techniques to use within its invention” by stating that the
`“strength” of the “authentication process . . . may vary in accordance with
`the needs of network 14.” Id. at 40–41 (emphasis omitted) (quoting
`Ex. 1003, 6:59–62); see Ex. 1002 ¶¶ 101–102, 104. According to Petitioner
`and Dr. McDaniel, one of ordinary skill would have understood that higher
`security can be achieved through known “[m]ultifactor authentication
`systems,” which often combine two or more categories of authentication
`approaches, including “(i) something the user knows,” such as a password or
`PIN, “(ii) something the user has,” such as a key card, and “(iii) something
`the user is,” i.e., a physical characteristic, such as fingerprints or voice.
`Pet. 21–22, 41–42; Ex. 1002 ¶¶ 50–54, 102–103. Therefore, Petitioner and
`Dr. McDaniel represent that an artisan—interested in heightening security as
`suggested by Feigen—“would have logically consulted” references related
`to multifactor authentication, such as Bulfer and Falk, both of which teach
`“two-factor authentication” using “‘something the user knows’ and
`‘something the user has.’” Pet. 40, 42, 44; Ex. 1002 ¶¶ 94, 105, 112.
`
`Specifically, Petitioner argues that one of ordinary skill “would have
`been motivated to address the need for enhanced security identified in
`Feigen by applying the teachings of Bulfer,” given Bulfer’s statements that
`certain systems “require a higher level of security” and its system
`
`(Fed. Cir. 2016) (“[T]he Petitioner has the burden from the onset to show
`with particularity why the patent it challenges is unpatentable.” (citing
`35 U.S.C. § 322(a)(3))); Liberty Mut. Ins. Co. v. Progressive Cas. Ins. Co.,
`Case CBM2012-00003, slip op. at 14–15 (PTAB Oct. 25, 2012) (Paper 8)
`(representative decision) (“[I]t is the responsibility of the Petitioner to
`clearly articulate [the proposed combination].”); 35 U.S.C. § 312(a)(3);
`37 C.F.R. §§ 42.22(a)(2), 42.104(b)(4)–(5).
`
`
`
`14
`
`

`

`IPR2017-01041
`Patent 8,484,698 B2
`“provide[s] improved security for controlled access systems.” Pet. 42, 44
`(quoting Ex. 1004, 1:25–31); Ex. 1002 ¶¶ 106–107, 110. In particular,
`Petitioner proposes to implement Bulfer’s second authentication factor,
`using revalidation information sent to wireless remote communication
`device 70’, in Feigen’s system and specifically, to “augment[]” Feigen’s
`security host 26 “to include” and “to perform” this functionality as an
`“additional [authentication] step.”3 According to Petitioner and
`Dr. McDaniel, this combination of Feigen and Bulfer would have required
`only “known techniques of implementing Bulfer’s mobile device ‘something
`the user has’ approach as an additional step to Feigen’s ‘something the user
`knows’ password authentication.” Pet. 42–43; Ex. 1002 ¶¶ 107–110.
`
`To this combination of Feigen and Bulfer, Petitioner proposes to
`“further combine[]” Falk’s teaching regarding its authentication center 30
`“send[ing] a message to the service node 26,” to which the user is seeking
`access, to “inform the service node 26 of the results” of authentication such
`that service node 26 grants or denies access to the user. Ex. 1005, 5:54–57,
`6:40–58, 7:14–18, Fig. 3; Pet. 36, 40, 45, 51, 60–61 (citing Ex. 1005, 5:48–
`
`
`3 Pet. 42–44 (proposing to “implement[] Bulfer’s mobile device ‘something
`the user has’ approach as an additional step to Feigen’s ‘something the user
`knows’ password authentication”); Ex. 1002 ¶¶ 106–110 (same); Pet. 46–47
`(“When Bulfer is combined with Feigen, security host (26) in Feigen is
`augmented to include Bulfer’s second form of authentication – revalidation
`via a remote wireless device (70’) . . . .”); Ex. 1002 ¶¶ 138, 170, 199, 219
`(same); Pet. 48–49 (“When combined with Bulfer, . . . [Feigen’s] security
`host (26) . . . performs a second factor authentication . . . through a
`revalidation process over wireless communication device (70’).”); Ex. 1002
`¶¶ 145, 206, 226 (same); see Pet. 36–37, 39 (composite figure of Feigen and
`Bulfer and chart showing alleged correspondence between ground 1 and the
`’698 patent), 45–51, 55, 57, 60, 63–66; Ex. 1002 ¶¶ 150, 167–171, 180, 185.
`
`
`
`15
`
`

`

`IPR2017-01041
`Patent 8,484,698 B2
`57, 6:44–58, 7:14–17, Fig. 3); see Pet. 64, 66; Ex. 1002 ¶¶ 97–98, 113, 151,
`186. Petitioner argues that these disclosures of Falk teach “sending an
`instruction to the host computer to grant or deny access,” as the challenged
`claims of the ’698 patent require. Pet. 36. Specifically, Petitioner relies on
`these disclosures of Falk4 as allegedly teaching the limitation of independent
`claims 1 and 53 that recites “outputting an instruction from the security
`
`
`4 Even if Petitioner were to rely on Feigen or Bulfer as allegedly teaching or
`suggesting these limitations, the passages of these references cited in the
`Petition are insufficient to teach or suggest the limitations. First, as to
`Feigen, the “failed access message” that security host 26 “return[s]” when
`the user is not authentic or authorized is “sen[t] . . . to the client”—not to
`destination host 28, the alleged “host computer,” or to filter 16, the alleged
`“web server,” which are the required recipients of the instruction per the
`claim language. Ex. 1003, 7:1–7, 7:36–45, Fig. 3 (task 104); e.g., Pet. 50,
`56. Moreover, security host 26’s “release[]” of the connection request
`message, sent by source host 22, “to inside network 14” when the user is
`authentic and authorized does not teach or suggest the required instruction to
`grant or deny access to the host computer. Ex. 1003, [57], 4:3–6, 4:24–31,
`7:45–51, Figs. 3, 5 (task 116); see id. at 10:4–27. Specifically, source
`host 22’s connection request message, itself, is a request, not an instruction
`to grant or deny access. Further, in merely releasing that message to inside
`network 14, without more, security host 26 does not output an instruction to
`grant or deny access to destination host 28—even if destination host 28, after
`receiving the message, ultimately communicates with the user. Rather,
`security host 26—by either allowing the request to inside network 14, or
`sending a failed access message to the client and preventing the request from
`reaching inside network 14—effectively grants or denies access to
`destination host 28. Accordingly, the cited portions of Feigen alone do not
`teach or suggest sufficiently the relevant limitations, and Petitioner does not
`explain why or how they do so. Second, in Bulfer, secured system 30, to
`which the user requests access, “compares” the sent and returned
`revalidation information and based on whether they match, “allows” or
`“denies” the user access to itself. Ex. 1004, 2:38–40, 3:50–54, 4:45–54,
`Fig. 2 (steps 110, 128–134). Thus, Bulfer does not teach or suggest
`outputting any instruction to grant or deny access to the host computer.
`
`
`
`16
`
`

`

`IPR2017-01041
`Patent 8,484,698 B2
`computer to the host computer to grant access to the host computer or deny
`access thereto,” as well as the nearly identical limitation of independent
`claim 54 and the corresponding limitation of independent claim 48 that
`recites “the second software module . . . outputs an instruction to the first
`software module to grant access to the host computer or deny access
`thereto.”5 Accordingly, to reach the methods and apparatus recited in
`independent claims 1, 48, 53, and 54 and their dependent claims, Petitioner
`proposes combining “this functionality from Falk” with the combined
`system of Feigen and Bulfer such that Feigen’s “security host (26) . . .
`issue[s] an instruction . . . to grant or deny access” to destination host 28
`“based on the comparison of [Bulfer’s] revalidation information.” Pet. 45,
`51, 60–61; Ex. 1002 ¶¶ 113, 151, 186, 212, 235; see Pet. 64, 66.
`
`In support of this proposed combination, Petitioner argues, and
`Dr. McDaniel opines, that a skilled artisan would have been “motivated to
`combine Feigen and Bulfer with Falk at least because Falk is focused on the
`same security processes that provide authentication and authorization of
`
`
`5 Pet. 36 (explaining that Falk is “further combined to teach sending an
`instruction to the host computer to grant or deny access”); id. at 50–51, 60–
`61, 64, 66 ((Petition’s analysis of relevant claim limitations) (referring to
`Feigen and Bulfer without asserting that they teach or suggest any
`instruction to grant or deny access and expressly relying on Falk’s
`“authenticated or not authenticated message” as teaching an “instruction . . .
`to grant or deny access”)); id. at 36, 40 (relying on Falk alone for alleged
`teaching of “security computer (40) instruct[ing] host computer (34) to grant
`access or deny access”); see Ex. 1002 ¶¶ 97–98, 151, 186, 212, 235; see also
`Ex. 1010, 26, 29–31, 84, 87–89, 121–22, 124–26, 153, 156–58 (asserting
`that only Falk, not Feigen or Bulfer, “describes outputting an instruction
`from the security computer . . . to grant . . . or deny access” to the host
`computer and, thus, that “Feigen, Bulfer, and Falk combined describe” the
`relevant claim limitations).
`
`
`
`17
`
`

`

`IPR2017-01041
`Patent 8,484,698 B2
`users.” Pet. 44; Ex. 1002 ¶ 111; see Ex. 1002 ¶ 113. Petitioner and
`Dr. McDaniel further allege tha