Official 38-page decision posted by PTAB: Pape

Official 38-page decision posted by PTAB:

Paper No. 7
571.272.7822 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
2
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.
IPR2017-01041
Patent 8,484,698 B2
3
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.
IPR2017-01041
Patent 8,484,698 B2
4
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
IPR2017-01041
Patent 8,484,698 B2
5
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).
IPR2017-01041
Patent 8,484,698 B2
6
E. ASSERTED GROUNDS OF UNPATENTABILITY
Petitioner asserts the following grounds of unpatentability under
35 U.S.C. § 103.
1
Pet. 8–9.
Challenged Claims References
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.
IPR2017-01041
Patent 8,484,698 B2
7
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,
IPR2017-01041
Patent 8,484,698 B2
8
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” 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
IPR2017-01041
Patent 8,484,698 B2
9
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 the connection request” and “a communication session . . .
commence.” 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
IPR2017-01041
Patent 8,484,698 B2
10
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.
IPR2017-01041
Patent 8,484,698 B2
11
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. “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
IPR2017-01041
Patent 8,484,698 B2
12
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)).
IPR2017-01041
Patent 8,484,698 B2
13
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
IPR2017-01041
Patent 8,484,698 B2
14
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) (“ 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
(representative decision) (“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).
IPR2017-01041
Patent 8,484,698 B2
15
“provide 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.
IPR2017-01041
Patent 8,484,698 B2
16
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” when
the user is not authentic or authorized is “sen . . . 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.
IPR2017-01041
Patent 8,484,698 B2
17
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 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).
IPR2017-01041
Patent 8,484,698 B2
18
users.” Pet. 44; Ex. 1002 ¶ 111; see Ex. 1002 ¶ 113. Petitioner and
Dr. McDaniel further allege that “[l]ike Bulfer, Falk teaches two-factor
authentication using ‘something the user knows’ and ‘something the user
has.’” Pet. 44; Ex. 1002 ¶ 112. Moreover, Petitioner and Dr. McDaniel
represent that “Feigen, Bulfer, and Falk each describe a system where the
security system grants or denies the user’s access.” Pet. 45; Ex. 1002 ¶ 113.
Thus, according to Petitioner and Dr. McDaniel, the combination of Feigen,
Bulfer, and Falk “would have been obvious to a skilled artisan seeking to
implement the heightened level of authentication . . . suggested by Feigen.”
Pet. 45; Ex. 1002 ¶ 113; see Pet. 40–42; Ex. 1002 ¶¶ 94, 101–105.
From these assertions, Petitioner and Dr. McDaniel conclude:
“Accordingly, it would have been obvious to employ the instruction
mechanisms used in these references to grant or deny access to a user,”
including “implementing [Feigen’s] security host (26) to issue an instruction
to destination host (28) to grant or deny access” “in the same way that
authentication center (30) in Falk transmits to service node (26) the result of
a comparison of a response code from personal unit (20) with an expected
response.” Pet. 45; see Ex. 1002 ¶ 113. Dr. McDaniel further opines that
this proposed implementation “would use known techniques with
predictable results, as described in the references, and yield an instruction to
grant or deny access, as called for in the [’]698 Patent.” Ex. 1002 ¶ 113.
In response, Patent Owner argues that even if an ordinarily skilled
artisan would have been motivated to combine Feigen and Bulfer as
Petitioner proposes,6 Petitioner does not demonstrate why such an artisan
6 Patent Owner advances numerous alleged deficiencies in Petitioner’s
proffered motivation to combine Feigen, Bulfer, and Falk. Prelim.
IPR2017-01041
Patent 8,484,698 B2
19
would have “further modif[ied] the combination of Feigen and Bulfer with
Falk” and, therefore, fails to “justify its proposed three-reference
combination.” Prelim. Resp. 26–27, 30. Patent Owner argues that “ o the
extent Petitioner purports to base its motivation to combine . . . on the
assertion that all three references are in the same field, this is insufficient” to
provide a reason, with rational underpinning, to combine specific teachings
of the references. Id. at 31 n.10. Patent Owner also contends Petitioner’s
assertions that Bulfer and Falk have the same teachings raise “questions as
to why a [person of ordinary skill in the art] would have been motivated to
combine both Bulfer and Falk into Feigen,” yet “Petitioner never addresses
what benefit Falk allegedly brings to the proposed combination that would
not have been present with Bulfer alone.” Id. at 30 n.9.
Moreover, Patent Owner asserts that Petitioner “does not propose
incorporating Falk’s second-factor authentication ‘challenge code’ into the
combined Feigen/Bulfer system to yield a system with yet another
authentication factor.” Id. at 31. Rather, according to Patent Owner,
“Petitioner relies on Falk only for its alleged disclosure of transmitting an
instruction to a host computer to grant or deny access.” Id. at 31–32. Thus,
Patent Owner argues that “Petitioner’s proposed Feigen/Bulfer/Falk
combination does not align with its purported motivation to incorporate
Falk” and Petitioner is merely “cherry-pick[ing] from disparate disclosures
in a failed attempt to try to cobble together the claimed invention of the
’698 patent” in a “classic case of improper hindsight analysis.” Id.

Resp. 25–37, 46–50. As discussed below, we agree with Patent Owner that
Petitioner’s alleged reasons to combine Falk with Feigen and Bulfer are
deficient. Thus, we need not address Patent Owner’s other assertions.
IPR2017-01041
Patent 8,484,698 B2
20
We agree with Patent Owner that Petitioner’s arguments and evidence
are insufficient to explain and demonstrate why an ordinarily skilled artisan
would have combined Feigen and Bulfer with Falk and more particularly,
Falk’s teaching regarding sending a message to service node 26 with the
result of an authentication determination. We find Petitioner’s proffered
reasons to combine Falk to be excessively generic and to lack the specificity
that our governing precedent requires of a motivation to combine. See, e.g.,
Nuvasive, 842 F.3d at 1381–82 (“ he factual inquiry whether to combine
references must be thorough and searching, and the need for specificity
pervades . . . .” (quotations omitted)); Magnum Oil, 829 F.3d at 1380 (“To
satisfy its burden of proving obviousness, a petitioner cannot employ mere
conclusory statements” and “must instead articulate specific reasoning,
based on evidence of record . . . .”). In particular, Petitioner’s vague
assertions do not substantiate a reason that would have prompted one of
ordinary skill in the art to combine the specific relevant element or teaching
of Falk—i.e., authentication center 30 sending a message to service node 26
with the result of the user authentication—with Feigen and Bulfer to achieve
the invention recited in the challenged claims of the ’698 patent. See KSR,
550 U.S. at 418 (“t can be important to identify a reason that would have
prompted a person of ordinary skill in the relevant field to combine the
elements in the way the claimed new invention does.” (emphasis added));
Magnum Oil, 829 F.3d at 1381 (“t was [petitioner’s] burden to
demonstrate . . . that a skilled artisan would have been motivated to combine
the teachings of the prior art references to achieve the claimed
invention . . . .” (second alteration in original) (emphasis added) (quotations
omitted)); ActiveVideo Networks, Inc. v. Verizon Commc’ns, Inc., 694 F.3d
1312, 1328 (Fed. Cir. 2012) (determining that obviousness showing was
IPR2017-01041
Patent 8,484,698 B2
21
deficient for “fail[ure] to explain why a person of ordinary skill in the art
would have combined elements from specific references in the way the
claimed invention does” (first emphasis added)).
In particular, Petitioner’s assertions that Feigen, Bulfer, and Falk are
“focused on the same security processes that provide authentication and
authorization of users” and describe “security system [that] grant[] or
den[y] the user’s access,” as well as that Bulfer and Falk both “teach[]
two-factor authentication using ‘something the user knows’ and ‘ . . . has,’”
are insufficient to support an obviousness showing. Pet. 44–45; see id.
at 42; Ex. 1002 ¶¶ 94, 105, 111–113. These arguments assert no more than
that the three references are in the same field and their disclosed systems
share broad and general similarities, such as providing for user
authentication that results in a grant or denial of user access. We agree with
Patent Owner that these assertions, without more, are inadequate to provide
sufficiently specific reasoning, with rational underpinning, to combine
Falk—and particularly, Falk’s message from authentication center 30 to
service node 26 upon completion of user authentication—with Feigen and
Bulfer. See Prelim. Resp. 30–31 nn.9–10; TRW Auto. US LLC v. Magna
Elecs., Inc., Case No. IPR2014-00257, slip op. at 4 (PTAB Aug. 28, 2014)
(Paper 18) (“That each reference may be in the field of ‘vehicular vision’ is
insufficient, in and of itself, to provide a reason with rational[] underpinning
as to why one of ordinary skill in the art would have sought to combine
specific teachings of such references.”). For example, Petitioner never
identifies or explains adequately any benefit or improvement gained by
adding Falk, and specifically, Falk’s relevant message, to the proposed
combination of Feigen and Bulfer. See Nuvasive, 842 F.3d at 1384–86
(holding obviousness determination to be unsupported where petitioner
IPR2017-01041
Patent 8,484,698 B2
22
asserted only that a skilled artisan would have been motivated to combine
the prior art “to obtain additional information,” yet the record lacked any
articulation as to “why the additional information would benefit [a skilled
artisan]” and “why [such an artisan] would have been motivated” “to obtain
this additional information”).
Likewise deficient are Petitioner’s arguments that a skilled artisan
would have been motivated to combine both Bulfer and Falk with Feigen to
address Feigen’s suggestion to “heighten the strength” of the one-factor
authentication in Feigen, because Falk, “[l]ike Bulfer,” “teaches two-factor
authentication using ‘something the user knows’ and ‘ . . . has.’” Pet. 40, 42,
44–45; see Ex. 1002 ¶¶ 94, 105, 112–113. First, Petitioner does not explain
persuasively why an artisan would have further modified the combined
teachings of Feigen and Bulfer to send a message to security host 26 with
the authentication result as taught by Falk. As Petitioner argues, Bulfer
teaches two-factor authentication using “something the user knows” (user
identification information) and “something the user has” (wireless remote
communication device 70’). See Ex. 1004, 2:50–60, 3:1–39, 3:50–55, 4:12–
55, Fig. 2; Pet. 42, 44. As explained above, Petitioner proposes to
implement Bulfer’s second authentication factor, using revalidation
information sent to wireless remote communication device 70’, in Feigen.
E.g., Pet. 42–44 (asserting that the combination of Feigen and Bulfer would
“implement[] Bulfer’s mobile device ‘something the user has’ approach as
an additional step to Feigen’s ‘something the user knows’ password
authentication” (emphasis added)); id. at 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’) . . . .” (emphasis added)); id. at 36–39, 48–49; Ex. 1002 ¶¶ 95–
IPR2017-01041
Patent 8,484,698 B2
23
98, 107–110, 138, 145, 167–171, 180–185, 199, 219. Indeed, Petitioner
relies on the same proffered reasoning—i.e., achieving the heightened level
of authentication and security that Feigen suggests—to support combining
Bulfer’s second authentication factor with Feigen. See Pet. 40–44 (arguing
that “one of ordinary skill in the art would have been motivated to combine
Feigen and Bulfer to achieve Feigen’s suggestion of stronger security by
security host (26)” and similarly, “to address the need for enhanced security
identified in Feigen by applying the teachings of Bulfer”); Ex. 1002 ¶¶ 94,
101–110. Even assuming that this proffered reasoning is sufficient support
for the proposed combination of Feigen with Bulfer’s second authentication
factor, it does not provide sufficient explanation as to why an ordinarily
skilled artisan—having implemented this combination of Feigen with
Bulfer’s second authentication factor and, thus, increased Feigen’s
authentication and security level—also would look to add Falk, and
specifically, Falk’s teaching of sending a message to security host 26 with
the authentication result, to this combination of Feigen and Bulfer.
Second, as Patent Owner points out, although Petitioner proposes to
combine Bulfer’s second authentication factor with Feigen, Petitioner does
not articulate clearly or adequately a proposed combination of Falk’s second
authentication factor—which includes sending a challenge code to personal
unit 20, which in turn then generates a response code that is sent to
authentication center 30 and compared to the expected response code—with
Feigen and Bulfer.7
See Ex. 1005, 5:24–33, 5:45–62, Fig. 3; Prelim.
7 Given that Petitioner does not articulate such a combination, Petitioner also
fails to explain how such a combination of Feigen with both Bulfer’s and
Falk’s second authentication factors, which use mobile devices, would
IPR2017-01041
Patent 8,484,698 B2
24
Resp. 31–32; Pet. 36–45; Pet. 51, 60–61, 64, 66 (arguing that “sing”
Falk’s “functionality” regarding sending an “authenticated or not
authenticated message,” Feigen’s security host 26 can issue an instruction
“to grant or deny access based on the comparison of [Bulfer]’s revalidation
information received over wireless communication system (50’)” (emphasis
added)); Ex. 1002 ¶¶ 151, 186, 212, 235 (same). Rather, Petitioner
specifically proposes to combine only Falk’s alleged teaching of an
instruction to service node 26 to grant or deny access.8
Accordingly, we
agree with Patent Owner that the proffered reasoning of Petitioner regarding
increasing the authentication and security level in Feigen does not relate or
link sufficiently to the specific teaching of Falk that Petitioner proposes to
combine with Feigen and Bulfer. See Prelim. Resp. 31; ActiveVideo, 694
F.3d at 1328 (determining that expert testimony was insufficient to support
an obviousness showing where it “b[ore] no relation to any specific
combination of prior art elements”).

operate, as required to support a motivation to combine. See Personal Web
Techs., LLC v. Apple, Inc., 848 F.3d 987, 994 (Fed. Cir. 2017) (holding an
obviousness determination improper where the record lacked a “clear,
evidence-supported account” of “how the combination” would work).
8 Pet. 45 (proposing to “implement[]” in Feigen’s security host 26, Falk’s
teaching of authentication center (30) “transmit[ting] to service node (26)
the result of a comparison” of a received and expected response code);
Ex. 1002 ¶ 113 (same); Pet. 36–40 ((chart “show[ing] the correspondence
between” ground 1 and the ’698 patent) (relying on Falk only for alleged
teaching of “security computer (40) instruct[ing] host computer (34) to grant
access or deny access”)); Ex. 1002 ¶ 98 (same); see also Pet. 51, 60–61, 64,
66 ((analysis of independent claims 1, 48, 53, and 54) (arguing that “sing”
Falk’s “functionality” of sending an “authenticated or not authenticated
message” to service node 26, Feigen’s security host 26 can issue an
instruction “to grant or deny access based on the comparison of [Bulfer]’s
revalidation information”)); Ex. 1002 ¶¶ 151, 186, 212, 235 (same).
IPR2017-01041
Patent 8,484,698 B2
25
In addition to the deficiencies in Petitioner’s proffered reasons to
combine discussed above, Petitioner’s argument and evidence lack adequate
support for the motivation to combine Falk with Feigen and Bulfer for an
additional, independent reason. In particular, Petitioner fails to address
meaningful relevant differences between the operation and functionality of
Feigen’s destination host 28 and Falk’s service node 26 with respect to
connection or access requests and why, despite these differences, an
ordinarily skilled artisan would have been motivated to combine Feigen’s
system, modified by Bulfer, with Falk’s message to service node 26
regarding the authentication result, as Petitioner proposes.
Specifically, in Falk, service node 26 “receives” the user’s access
request and “in response,” it “requests authentication.” Ex. 1005, 6:4–16,
6:63–67; see id. at 5:20–25. After authentication, authentication center 30
“sends a message” to “inform the service node 26 of the results”—i.e.,
“authenticated/not authenticated”—and service node 26 grants access if the
authentication was successful and denies access if the authentication was
unsuccessful. Id. at 6:45–58, 7:14–18; see id. at 5:52–58. Accordingly,
these disclosures of Falk make clear that while authentication center 30 is
performing the authentication, service node 26—having received the user’s
access request and requested authentication of the user in response to that
request—is awaiting the result of the pending authentication. Thus,
authentication center 30, upon completing the requested authentication,
informs service node 26 of the result of the authentication that it requested.
Feigen, in contrast, operates differently. In Feigen, source host 22 in
outside network 12 sends a connection request message for an application
service on destination host 28 in inside network 14—but filter 16 “routes”
the request to security host 26, which “intercept” the request. Ex. 1003,
IPR2017-01041
Patent 8,484,698 B2
26
4:3–10, 5:5–10. Security host 26 “prevents [the connection request] from
being transmitted within inside network 14,” and thus from “reach[ing] its
intended destination” of destination host 28, unless and until it determines
that the user is authentic and authorized. Id. at 4:3–31, 5:5–10; see id.
at [57], 7:1–7, 7:33–51, Figs. 3, 5. If security host 26 determines that the
user is not authentic or authorized, it sends a “failed access message to the
client” and “continue to prevent” the request “from being released onto
inside network 14,” thereby preventing connection with destination host 28.
Id. at 7:1–7, 7:40–45, Fig. 5 (tasks 102–104, 114). If, however, security
host 26 determines that the user is authentic and authorized, it “release”
the request and the request is received by destination host 28. Id. at [57],
4:22–31, 7:45–51, Fig. 3, Fig. 5 (task 116). Accordingly, as a result of
security host 26’s interception of the connection request, destination host 28
has not received, and is not even aware of, the connection request while
security host 26 is performing authentication. Nor does destination host 28
request the authentication. Rather, destination host 28 receives the
connection request only if security host 26 determines that the user is
authorized and authentic, and is never made aware of the request if the user
is not authorized or authentic. Therefore, security host 26 essentially acts as
a gatekeeper, handling whether access to inside network 14, and destination
host 28 therein, is granted or denied by either allowing the request onto
inside network 14, or sending the client a failed access message and
preventing the request from being transmitted onto the network.
Petitioner does not address these distinctions in the operation of
Feigen’s and Falk’s systems or articulate why—despite these differences—
one of ordinary skill would have been motivated to combine Feigen’s system
with Falk’s teaching of sending service node 26 the result of the
IPR2017-01041
Patent 8,484,698 B2
27
authentication (i.e., authenticated/not authenticated), based on which service
node 26 grants or denies access to the user. In particular, Petitioner fails to
explain adequately why an artisan would have been motivated to modify
Feigen to issue such a message to destination host 28, which—in contrast to
Falk’s service node 26—does not request, and is unaware of, the
authentication and does not receive the connection request unless and until
security host 26 determines that the user is authorized. See generally
Pet. 38, 46–47, 55, 63–66 (relying, in unpatentability analysis, on Feigen’s
teachings regarding filter 16 and security host 26 intercepting a connection
request and preventing it from being transmitted to inside network 14).
Moreover, with respect to claim 48, Petitioner’s proffered reasoning
as to why an ordinarily skilled artisan would have combined Falk’s message
to service node 26 with Feigen and Bulfer to reach the relevant “instruction”
limitation suffers from an additional deficiency. Claim 48 recites that “the
second software module,” which is “on a security computer,” “outputs an
instruction to the first software module,” which is “on an Internet-connected
web server,” “to grant access to the host computer or deny access thereto.”
Ex. 1001, 18:5–26. Like the other challenged independent claims 1, 53,
and 54, claim 48 requires that the instruction be issued from the “security
computer.” Id. at 14:44–46, 18:5–26, 18:59–62, 19:7–11. Unlike these
claims, however, claim 48 requires that the instruction be issued to the “web
server,” rather than the “host computer” itself. See id. Petitioner identifies
the “security computer” as Feigen’s security host 26, “augmented by
Bulfer”; the “host computer” as Feigen’s destination host 28; and the “web
server” as Feigen’s filter 16. Pet. 55–56, 60. In addressing this limitation of
claim 48, Petitioner argues, and Dr. McDaniel identically opines, that
“sing th[e] functionality from Falk” regarding an “authenticated or not
IPR2017-01041
Patent 8,484,698 B2
28
authenticated message,” “security host (26) in Feigen can issue an
instruction to grant or deny access based on the comparison of revalidation
information received over wireless communication system (50’).” Id. at 60–
61; Ex. 1002 ¶ 186. Further, Petitioner and Dr. McDaniel allege that an
artisan “could have easily and without undue experimentation sent this
instruction to the first software module on Feigen’s filter 16 to grant access
to the host computer or deny access thereto.” Pet. 61; Ex. 1002 ¶ 187.
As discussed above, however, Feigen’s filter 16—located between
outside network 12 and inside network 14—“routes” a connection request
message for destination host 28 in inside network 14 to security host 26,
which upon determining that the user is authentic and authorized,
“release” the request “to inside network 14.” Ex. 1003, 4:1–10, 4:23–31,
5:54–59, 7:45–51, Figs. 1, 5. Further, in Falk, the relevant message with the
result of the authentication is sent directly to service node 26, to which the
user seeks access. Ex. 1005, 6:4–6, 6:45–58, 7:14–17. Petitioner fails to
explain adequately why—even if a skilled artisan were motivated to add
Falk’s message informing service node 26 of the authentication result to
Feigen’s system—such an artisan would have modified the teachings of both
Feigen and Falk such that the message, or alleged instruction, would be sent
from Feigen’s security host 26 upstream to filter 16, rather than directly to
destination host 28 within inside network 14.
Accordingly, we determine that Petitioner’s argument and evidence is
insufficient to explain and support a reason, with rational underpinning, to
combine Feigen and Bulfer with Falk, and particularly, Falk’s teaching of
sending a message with the authentication result to service node 26, to
achieve the methods and apparatus recited in independent claims 1, 48, 53,
and 54 as well as their challenged dependent claims.
IPR2017-01041
Patent 8,484,698 B2
29
5. “web server” (Claims 48–52)
Independent claim 48 recites “an Internet-connected web server.”
Ex. 1001, 18:5–6. In addressing this limitation, Petitioner argues Feigen
explains that filter 16 “perform intercepting and routing.” Pet. 55–56
(citing Ex. 1003, 2:44–48, 2:63–3:15, 4:3–11, 4:66–5:14, 7:65–68); see
Ex. 1002 ¶ 172 (same). Based on Feigen’s statements that filter 16 can be “a
router, bridge, gateway, or the like” and that “nothing requires the filtering
device to function only as a filter,” Petitioner and Dr. McDaniel allege that
“a person of skill in the art would have also understood that filter (16) . . .
could be a web server.” Pet. 56 (quoting Ex. 1003, 2:63–3:15, citing
Ex. 1003, 1:20–32, 2:44–48); Ex. 1002 ¶ 173. Dr. McDaniel further opines
that in this passage, “Feigen is talking about a standard network device that
typically sits at the edge of the network and processes incoming requests
from the Internet (outside network 12).” Ex. 1002 ¶ 173.
Patent Owner contends that Petitioner’s assertions are “legally and
factually” “without merit.” Prelim. Resp. 56. Patent Owner argues that
Petitioner “appears to admit implicitly that [Feigen] does not explicitly
disclose the claimed web server.” Id. Rather, Patent Owner contends that
Petitioner and Dr. McDaniel assert “at most, that the filter could be a web
server”—“not that it is” such a server. Id. at 56–57. According to Patent
Owner, the “only substance added by Dr. McDaniel” consists of a
“conclusory statement—offered without evidentiary support—[that] still
says nothing about the filter necessarily acting as or rendering obvious the
claimed web server.” Id. at 57 (quoting Ex. 1002 ¶ 173). Thus, Patent
Owner asserts that Petitioner fails to show that one of ordinary skill “would
have,” as opposed to merely “could have,” combined the asserted prior art to
yield the claimed invention, as required for an obviousness showing. Id.
IPR2017-01041
Patent 8,484,698 B2
30
We agree with Patent Owner that Petitioner’s argument that Feigen’s
filter 16 “could be” a “web server,” as well as Petitioner’s cited supporting
evidence, are insufficient to support an obviousness showing for this
limitation of claim 48. Petitioner does not argue that Feigen discloses
filter 16 to be a “web server,” and based on our review of the cited passages
of Feigen, Feigen does not include such an express disclosure. See Pet. 55–
56; Ex. 1002 ¶¶ 172–173. Nor does Petitioner provide explanation and
evidence adequate to support that Feigen teaches, suggests, or otherwise
would have conveyed to a skilled artisan that filter 16 is a “web server.”
Specifically, the passage of Feigen on which Petitioner’s argument
focuses states: “Filter 16 is desirably provided by a conventional filtering
device, such as a router, bridge, gateway, or the like. However, nothing
requires the filtering device to function only as a filter.” Ex. 1003, 3:3–6;
see Pet. 56; Ex. 1002 ¶ 173. This passage explains only that filter 16,
although preferably a typical filtering device, is not limited to functioning as
a filter. Petitioner and Dr. McDaniel do not explain sufficiently or provide
evidentiary support adequate to demonstrate how or why this passage would
have taught or suggested that filter 16 is a “web server.” Dr. McDaniel’s
testimony that “Feigen is talking about a standard network device that
typically sits at the edge of the network and processes incoming requests
from the Internet (outside network 12)” not only lacks factual support but
also fails to articulate why such an understanding of Feigen’s disclosures
would lead a skilled artisan to understand that Feigen teaches or suggests
that filter 16 is a “web server.” Ex. 1002 ¶ 173; see 37 C.F.R. § 42.65(a)
(“Expert testimony that does not disclose the underlying facts or data on
which the opinion is based is entitled to little or no weight.”).
IPR2017-01041
Patent 8,484,698 B2
31
The other cited passages of Feigen fare no better in regard to a
teaching or suggestion of filter 16 as a “web server.” See Ex. 1003, 1:20–32,
2:44–48, 2:63–3:2, 3:7–15, 4:3–11, 4:66–5:14, 7:65–68; Pet. 55–56. For
example, several cited passages describe the function of filters generally and
filter 16 specifically. In particular, Feigen explains that “[f]ilters selectively
block certain classes of data traffic while allowing other classes of data
traffic to pass” (Ex. 1003, 1:28–30) and filter 16 “routes [a] first connection
request to security host 26,” which “intercept” the request and “prevents it
from being transmitted within inside network 14” (id. at 4:6–9, 5:5–. Yet
this described functionality of filter 16 blocking and routing requests, alone
and without more, does not teach or suggest a “web server.” Further,
Petitioner offers no explanation or support as to how or why it would do so.
Moreover, to the extent Petitioner is asserting that one of ordinary
skill “could” have modified Feigen’s filter 16 or combined Feigen with the
other prior art references to reach a “web server,” this is insufficient for
obviousness. See Pet. 56; Ex. 1002 ¶ 173. As the U.S. Court of Appeals for
the Federal Circuit has made clear, “[o]bviousness concerns whether a
skilled artisan not only could have made but would have been motivated to
make the combinations or modifications of prior art to arrive at the claimed
invention.” Personal Web, 848 F.3d at 994 (quotation omitted).
Claims 49–52 depend, directly or indirectly, from independent
claim 48. Ex. 1001, 18:27–46. Petitioner’s analysis of the additional
limitations of these dependent claims does not cure the deficiencies in
Petitioner’s showing that Feigen would have conveyed to an ordinarily
skilled artisan the “web server” of independent claim 48. See Pet. 61–63.
Thus, Petitioner has not shown sufficiently that the combination of
Feigen, Bulfer, and Falk renders obvious the “web server” of claims 48–52.
IPR2017-01041
Patent 8,484,698 B2
32
6. Conclusion
For the reasons given, we determine that Petitioner has not shown a
reasonable likelihood that it would prevail in establishing that Feigen,
Bulfer, and Falk render obvious claims 1–3, 5–7, 15, 20–24, and 48–54.
C. ALLEGED OBVIOUSNESS OVER FEIGEN, BULFER, FALK, AND TURTIAINEN
Petitioner contends that claims 50 and 52 would have been obvious
over the combination of Feigen, Bulfer, Falk, and Turtiainen. Pet. 66–75.
Patent Owner contests Petitioner’s arguments. Prelim. Resp. 62–64.
Claim 50 depends directly from independent claim 48, and claim 52
further depends from claim 50. Ex. 1001, 18:31, 18:43. Claim 50 recites the
additional method step of: “providing a third software module for installing
on the mobile device in the authentication channel, wherein the third
software module receives the instruction outputted to the mobile device from
the second software module, displays a message to the subscriber, and
receives the input from the mobile device.” Id. at 18:31–38. Claim 52, in
turn, specifies that “the displayed message is a notification containing an
instruction for the subscriber to reply to the notification using the mobile
device’s input device.” Id. at 18:43–46.
1. Overview of Turtiainen
Turtiainen discloses a method and apparatus to provide authentication
to an application through the use of a mobile station, which acts as a
“personal authentication device.” Ex. 1006, [57], 1:5–10, 15:30–32. In one
disclosed method, user 22 using terminal 16 sends a request to access
application 45, a banking service, and requests a transfer between bank
accounts. Id. at 16:17–22, 17:18–25, Figs. 2, 5. Application 45 then
retrieves authentication data for the user and sends a text message to the
user’s mobile station 1. Id. at 17:25–29. Mobile station 1 displays the text
IPR2017-01041
Patent 8,484,698 B2
33
message, which “asks the user to confirm or to deny the transaction by
pressing ‘Yes’ or ‘No’ keys.” Id. at 17:29–31, 18:5–6, Figs. 3, 5. The user’s
response is transmitted back to the application, which allows the transaction
to proceed if the user responds “Yes.” Id. at 17:31–34, Fig. 5.
2. The Deficiencies in Petitioner’s Showing of Obviousness for
Independent Claim 48 Apply to Dependent Claims 50 and 52
In this asserted ground challenging dependent claims 50 and 52,
Petitioner relies on its showing that independent claim 48 would have been
obvious over Feigen, Bulfer, and Falk, and adds Turtiainen only to address
the additional limitations of dependent claims 50 and 52. See Pet. 66–75.
Accordingly, the deficiencies, discussed above, in Petitioner’s obviousness
showing for claim 48—regarding the recited “web server” and the alleged
motivation to combine Feigen, Bulfer, and Falk—carry through to these
claims. Petitioner’s specific arguments directed to the additional limitations
of these dependent claims and the alleged motivation to further combine
Turtiainen with Feigen, Bulfer, and Falk do not cure the deficiencies. See id.
3. Alleged Motivation to Combine Turtiainen with Feigen, Bulfer, and Falk
Petitioner’s showing that claims 50 and 52 would have been obvious
over Feigen, Bulfer, Falk, and Turtiainen suffers from a further defect,
specifically in Petitioner’s proffered motivation to combine Turtiainen’s
teachings with the proposed combination of Feigen, Bulfer, and Falk. Patent
Owner argues that even if an ordinarily skilled artisan would have been
motivated to combine Feigen, Bulfer, and Falk, Petitioner still fails to
establish a sufficient reason why such an artisan “would have been
motivated to further modify th[is] three-reference combination” with
Turtiainen “to create the asserted four-reference combination.” Prelim.
Resp. 63. For the reasons given below, we agree with Patent Owner that
IPR2017-01041
Patent 8,484,698 B2
34
Petitioner’s assertions regarding why, as well as how, an artisan would have
combined Turtiainen with the proposed combination of Feigen, Bulfer, and
Falk are inadequate to support an obviousness determination.
Petitioner provides three alleged reasons why a person of ordinary
skill in the art would have combined Turtiainen with Feigen, Bulfer, and
Falk—each of which is deficient. First, Petitioner asserts that because
Turtiainen, “[l]ike Bulfer and Falk, . . . teaches authentication that relies on
‘something the user has’ – a mobile phone,” “a skilled artisan that wants to
add the heightened security suggested by Feigen would be motivated to look
to Turtiainen as another teaching of adding ‘something the user has’ to
security host (26).” Pet. 72; see Ex. 1002 ¶¶ 123, 125. As discussed above,
however, Petitioner—in its proffered combination of Feigen, Bulfer, and
Falk—proposes to combine Bulfer’s second authentication factor, which
implements a “something the user has” approach by transmitting
revalidation information to the user’s wireless remote communication
device 70’, with Feigen’s system to achieve the heightened security that
Feigen suggests. E.g., Pet. 36–44, 46–49, 55, 57–60; Ex. 1002 ¶¶ 94–96, 98,
101–110, 167–171, 180–185. Petitioner fails to articulate and support
adequately why a person of ordinary skill, having combined this additional
authentication factor of Bulfer with Falk, would have been motivated to
keep looking to additional teachings of “something the user has” approaches
to authentication and why such a person would have turned to, and
combined the teachings of, Turtiainen in particular.
Second, Petitioner contends that “Turtiainen’s detailed teaching of a
mobile device with application software would motivate a skilled artisan to
incorporate this functionality.” Pet. 73–74; see Ex. 1002 ¶ 125. Yet
Petitioner’s assertion that Turtiainen has “detailed teachings” of application
IPR2017-01041
Patent 8,484,698 B2
35
software for a mobile device—without more—does not explain and show
sufficiently why one of ordinary skill would have sought to integrate these
teachings into the proposed combination of Feigen, Bulfer, and Falk. For
instance, Petitioner does not represent that, or articulate why, these teachings
would have improved, or otherwise been beneficial to, the combined system
of Feigen, Bulfer, and Falk. See Nuvasive, 842 F.3d at 1384–86 (holding
obviousness determination to lack adequate support where petitioner argued
only that a skilled artisan would have been motivated to combine the prior
art “to obtain additional information,” yet the record lacked any articulation
as to “why the additional information would benefit [a skilled artisan]”).
Third, Petitioner argues that a “skilled artisan would have been
motivated to incorporate the user interface application functionality of
Turtiainen’s mobile station (1) in Bulfer’s mobile device (70),” reasoning
that “Bulfer describes a system that includes wireless remote communication
device 70 that receives revalidation messages and allows a user to respond,”
which is “similar to” Turtiainen’s “detailed” description of mobile station 1.
Pet. 73; see Ex. 1002 ¶¶ 121, 126–127. The alleged similarities in the
functionality of Bulfer’s wireless remote communication device and
Turtiainen’s mobile station, however, are alone insufficient to support a
reason to combine Turtiainen’s functionality with Bulfer’s device. Instead,
these alleged similarities merely raise the unanswered question of why an
artisan would have sought to add comparable functionality from Turtiainen’s
mobile station to Bulfer’s device, or to replace the functionality of Bulfer’s
device with that of Turtiainen’s mobile station. Again, Petitioner identifies
no benefit or improvement from such an addition to, or replacement of, the
functionality of Bulfer’s device—which includes receiving revalidation
information that user 10 “must send back to system 30,” displaying this
IPR2017-01041
Patent 8,484,698 B2
36
information, prompting the user to enter the information, and receiving the
user input—and which Petitioner already has proposed to incorporate in the
combination of Feigen, Bulfer, and Falk. Ex. 1004, 3:19–37, 4:24–44, 4:65–
5:8, Fig. 3; see Pet. 59, 62–63; Ex. 1002 ¶¶ 180–181, 189–190, 192.
In addition, Petitioner addresses how one of ordinary skill allegedly
would have incorporated the application functionality of Turtiainen’s mobile
station 1 in Bulfer’s remote wireless communication device 70’, asserting
that this “combination would only require known techniques to implement
Turtiainen’s ‘something the user has’ approach as additional functionality.”
Pet. 73. Dr. McDaniel further testifies that Turtiainen’s “‘something the
user has’ approach” would be implemented as “additional functionality to
the ‘something the user knows’ (username and password) and ‘something
the user has’ (peripheral device) authentications” in the combination of
Feigen, Bulfer, and Falk “to achieve predictable results.” Ex. 1002 ¶ 127.
As noted above, Petitioner’s proposed combination of Feigen, Bulfer,
and Falk features Bulfer’s wireless remote communication device 70’,
including its functionality for the second factor of authentication related to
receiving and displaying revalidation information, prompting the user to
input this information, and receiving the user input. Petitioner fails to
specify what particular “additional functionality” from Turtiainen it is
proposing to add to this functionality of Bulfer’s device, whether all of the
functionality of Turtiainen’s mobile station related to receipt of, display of,
and response to a confirmation text message, or only some of this
functionality. See Pet. 72–75; see also 37 C.F.R. §§ 42.22(a)(2),
42.104(b)(4) (explaining that the Petition must “specify where each element
of the claim is found in the prior art patents or printed publications” and
provide a “detailed explanation of the significance of the evidence”).
IPR2017-01041
Patent 8,484,698 B2
37
Further, if Petitioner is proposing to add only some of this functionality,
Petitioner does not specify which functionality it proposes to add from
Turtiainen’s mobile station and which relevant functionality of Bulfer’s
device would remain in the proposed combination. See Pet. 72–75. Nor
does Petitioner articulate adequately, with supporting evidence, how the
proposed combination, implementing Bulfer’s second authentication factor
using revalidation information, would operate using some or all of the
relevant functionality of Turtiainen’s mobile station. See id.
Accordingly, Petitioner’s argument and evidence regarding why and
how an ordinarily skilled artisan would have combined Turtiainen’s
teachings with Feigen, Bulfer, and Falk are insufficient to support a
motivation to combine the four references.
4. Conclusion
For the reasons given, we determine that Petitioner has not established
a reasonable likelihood that it would prevail in showing that claims 50 and
52 would have been obvious over Feigen, Bulfer, Falk, and Turtiainen.
III. CONCLUSION
In conclusion, we determine that the information in the Petition does
not establish a reasonable likelihood that Petitioner would prevail in
showing that the challenged claims of the ’698 patent, claims 1–3, 5–7, 15,
20–24, and 48–54, are unpatentable. Thus, we do not institute inter partes
review of any of the challenged claims on any of the asserted grounds.
IV. ORDER
Accordingly, it is:
ORDERED that pursuant to 35 U.S.C. § 314(a), the Petition is denied,
and no trial is instituted as to any claim of U.S. Patent No. 8,484,698 B2.
IPR2017-01041
Patent 8,484,698 B2
38
For PETITIONER:
Duo Security, Inc.
John D. Garretson (Lead Counsel)
Amy M. Foust
SHOOK, HARDY & BACON L.L.P.
jgarretson@shb.com
afoust@shb.com
Centrify Corporation
Darren M. Franklin
SHEPPARD, MULLIN, RICHTER, & HAMPTON LLP
dfranklin@sheppardmullin.com
Trustwave Holdings, Inc.
Brian A. Jones
MCDERMOTT WILL & EMERY
bajones@mwe.com
For PATENT OWNER:
Steven Pepe (Lead Counsel)
James L. Davis, Jr.
Matthew J. Rizzolo
ROPES & GRAY LLP
steven.pepe@ropesgray.com
james.l.davis@ropesgray.com
matthew.rizzolo@ropesgray.com