NOTE: This disposition is nonprecedential.
United States Court of Appeals
for the Federal Circuit
______________________
INTERNATIONAL BUSINESS MACHINES
CORPORATION,
Appellant
v.
ANDREI IANCU, UNDER SECRETARY OF
COMMERCE FOR INTELLECTUAL PROPERTY
AND DIRECTOR OF THE UNITED STATES
PATENT AND TRADEMARK OFFICE,
Intervenor
______________________
2018-1065, 2018-1066
______________________
Appeals from the United States Patent and Trademark
Office, Patent Trial and Appeal Board in Nos. IPR2016-
00608, IPR2016-00609.
______________________
Decided: April 1, 2019
______________________
KARIM ZEDDAM OUSSAYEF, Desmarais LLP, New York,
NY, argued for appellant. Also represented by JOHN M.
DESMARAIS, KEVIN KENT MCNISH.
MONICA BARNES LATEEF, Office of the Solicitor, United
2 IBM v. IANCU
States Patent and Trademark Office, Alexandria, VA, ar-
gued for intervenor. Also represented by THOMAS W.
KRAUSE, MOLLY R. SILFEN.
______________________
Before MOORE, TARANTO, and CHEN, Circuit Judges.
TARANTO, Circuit Judge.
International Business Machines Corporation (IBM)
owns U.S. Patent No. 7,631,346, entitled “Method and Sys-
tem for a Runtime User Account Creation Operation
Within a Single-Sign-On Process in a Federated Compu-
ting Environment.” At the behest of several private com-
panies (who have settled and are not parties here), the
Patent Trial and Appeal Board of the Patent and Trade-
mark Office, acting as delegee of the PTO Director, 37
C.F.R. §§ 42.4, 42.108, instituted two related inter partes
reviews (IPRs) of various claims of the ’346 patent under
35 U.S.C. §§ 311−319. In IPR2016-00608, the Board found
that claims 1, 3, 12, 14, 15, and 18 are unpatentable be-
cause they are anticipated by Japanese Publication No.
Tokkai 2004-302907A (Sunada). In IPR2016-00609, the
Board found that claims 1, 3, 12, 13, 15, and 18 are un-
patentable because they are anticipated by U.S. Patent No.
7,680,819 (Mellmer).
We have jurisdiction to review the Board’s final written
decisions under 35 U.S.C. §§ 141(c), 319 and 28 U.S.C.
§ 1295(a)(4). We vacate the Sunada IPR decision because
it rests on an incorrect claim construction of the “federated
computing environment” limitation of all claims at issue,
and we remand for further consideration under the correct
construction. In the Mellmer IPR decision, the same claim-
construction error is present, but it does not affect our re-
sult. We reverse the Board’s decision in the Mellmer IPR
because we have been pointed to no substantial evidence to
support the Board’s finding that Mellmer discloses the sep-
arate “single-sign-on” limitation of all claims at issue.
IBM v. IANCU 3
I
The specification gives the background to the invention
described and claimed. It explains that “[e]nterprises” try
to give their users the benefit of being able to gain access
to multiple applications “without regard to authentication
barriers that protect each particular system supporting
those applications.” ’346 patent, col. 1, lines 14−24. Users
had come to expect reduction of authentication burdens: “A
user might assume that once he or she has been authenti-
cated by some computer system, the authentication should
be valid throughout the user’s working session, or at least
for a particular period of time, without regard to the vari-
ous computer architecture boundaries that are almost in-
visible to the user.” Id., lines 25–33. “Enterprises
generally try to fulfill these expectations in the operational
characteristics of their deployed systems . . . .” Id., lines
33–35. Among the techniques used to do so are “‘single-
sign-on’ (SSO) processes,” which aim to require of a user
“only one authentication process during a particular user
session.” Id., lines 53–61.
The specification explains that user expectations about
ease of access are coming to extend beyond the systems
within an enterprise to Internet domains of different enter-
prises: “users are coming to expect the ability to jump from
interacting with an application on one Internet domain to
another application on another domain without regard to
the authentication barriers that protect each particular do-
main.” Id., lines 43–46. “To reduce the costs of user man-
agement and to improve interoperability among
enterprises, federated computing spaces have been cre-
ated.” Id., lines 62–64 (emphasis added). The specification
then defines the term “federated” as based on a cooperative
relationship among enterprises that falls short of the uni-
tary control available within an enterprise:
A federation is a loosely coupled affiliation of enter-
prises which adhere to certain standards of
4 IBM v. IANCU
interoperability; the federation provides a mecha-
nism of trust among those enterprises with respect
to certain computational operations for the users
within the federation.
Id., col. 1, line 64 through col. 2, line 1 (emphasis added).
The specification underscores the inter-enterprise nature
of being “federated” by stating that “[a]s enterprises move
to support federated business interactions, these enter-
prises should provide a user experience that reflects the in-
creased cooperation between two businesses.” Id., col. 2,
lines 9–11 (emphasis added). In particular, “a user may
authenticate to one party that acts as an identity provider
and then single-sign-on to a federated business partner.”
Id., lines 12–14.
The specification discusses the special challenges of
providing single-sign-on capabilities in a “federated” envi-
ronment. Id., lines 19–42. The Background of the Inven-
tion section ends by asserting: “it would be advantageous
to have methods and systems in which enterprises can pro-
vide comprehensive single-sign-on experiences to users in
a federated computing environment in a lightweight man-
ner that does not require an extensive amount of a priori
processing.” Id., lines 44–48.
The one-paragraph Summary of the Invention immedi-
ately follows. It begins by stating that “[a] method, system,
apparatus, and computer program product are presented
to support computing systems of different enterprises that
interact within a federated computing environment.” Id.,
lines 53−56. The Summary then describes the contem-
plated process of users getting access to multiple federation
partners through a “single-sign-on”: “Federated single-
sign-on operations can be initiated at the computing sys-
tems of federation partners on behalf of a user even though
the user has not established a user account at a federation
partner prior to the initiation of the single-sign-on opera-
tion.” Id., lines 59–60. The Summary refers to “an identity
IBM v. IANCU 5
provider” as an example of initiating such a single-sign-on
user access to resources of a service provider: “For example,
an identity provider can initiate a single-sign-on operation
at a service provider while attempting to obtain access to a
controlled resource on behalf of a user.” Id., lines 60−63.
It then says what happens “[w]hen the service provider rec-
ognizes that it does not have a linked user account for the
user that allows a single-sign-on operation from the iden-
tity provider,” i.e., “the service provider creates a local user
account based at least in part on information from the iden-
tity provider.” Id., lines 63−67. It concludes: “The service
provider can also pull user attributes from the identity pro-
vider as necessary to perform the user account creation op-
eration.” Id., col. 2, line 67 through col. 3, line 2.
The independent claims at issue are 1, 15, and 18. We
follow the parties in focusing on claim 1, which recites:
A method for managing user authentication within
a distributed data processing system, wherein a
first system and a second system interact within
a federated computing environment and sup-
port single-sign-on operations in order to pro-
vide access to protected resources, at least one of
the first system and the second system comprising
a processor, the method comprising;
triggering a single-sign-on operation on behalf
of the user in order to obtain access to a protected
resource that is hosted by the second system,
wherein the second system requires a user account
for the user to complete the single-sign-on oper-
ation prior to providing access to the protected re-
source;
receiving from the first system at the second sys-
tem an identifier associated with the user; and
creating a user account for the user at the second
system based at least in part on the received
6 IBM v. IANCU
identifier associated with the user after triggering
the single-sign-on operation but before generat-
ing at the second system a response for accessing
the protected resource, wherein the created user
account supports single-sign-on operations be-
tween the first system and the second system on
behalf of the user.
Id., col. 44, lines 38–61 (emphasis added). No separate ar-
guments are presented as to the other claims at issue.
II
The disputes before us focus on the “federated compu-
ting environment” and “single-sign-on” claim limitations.
The Board and the parties agree that both phrases are lim-
iting, even though the first appears only in the preamble.
See J.A. 8, 52–53. IBM challenges, and the Director of the
Patent and Trademark Office defends, the Board’s con-
struction of “federated computing environment.” Sepa-
rately, IBM challenges, and the Director defends, the
Board’s finding that Mellmer teaches the “single-sign-on”
claim limitation.
These inter partes reviews of an unexpired patent are
subject to the PTO regulation (since changed) providing
that the Board should give the claims their broadest rea-
sonable interpretation in light of the specification. See 37
C.F.R. § 42.100(b); Cuozzo Speed Techs. LLC v. Lee, 136 S.
Ct. 2131, 2144–46 (2016). We review the Board’s claim con-
struction de novo here, because the Board relied exclu-
sively on intrinsic evidence to construe the claims. See
Teva Pharms. USA, Inc. v. Sandoz, Inc.,
135 S. Ct. 831, 841
(2015); In re Cuozzo Speed Techs., LLC,
793 F.3d 1268,
1279–80 (Fed. Cir. 2015), aff’d,
136 S. Ct. 2131 (2016).
“To anticipate a claim, a prior art reference must dis-
close every limitation of the claimed invention, either ex-
plicitly or inherently.” In re Schreiber,
128 F.3d 1473, 1477
(Fed. Cir. 1997). What a reference discloses and therefore
IBM v. IANCU 7
whether it anticipates a claim (as properly construed) pre-
sent fact questions. Id.; see Idemitsu Kosan Co. v. SFC Co.,
870 F.3d 1376, 1379 (Fed. Cir. 2017). We review the
Board’s factual findings for substantial evidence. In re
Chudik,
851 F.3d 1365, 1371 (Fed. Cir. 2017).
A
We turn first to the Board’s construction of the term
“federated computing environment,” which, though it ap-
pears in both IPRs before us, we will discuss only with ref-
erence to IPR2016-00608, the Sunada IPR. The Board
recognized that both IBM and the private companies that
requested the IPRs (“Petitioner”) agreed about what a “fed-
erated computing environment” means: “a ‘loosely coupled
affiliation of enterprises which adhere to certain standards
of interoperability; the federation provides a mechanism
for trust among those enterprises with respect to certain
computational operations for the users within the federa-
tion.’” J.A. 6−7 (emphasis added) (quoting Petition). 1 Un-
der that agreed-on construction, a “federated computer
environment” must involve a plurality of “enterprises.”
The Board rejected the parties’ agreed-on construction
“that the scope of the term is limited to an affiliation of en-
terprises.” J.A. 8 (emphasis in original). The Board did so
even while recognizing the specification passage, quoted
above, stating that “[a] federation is a loosely coupled affil-
iation of enterprises . . . .” See J.A. 8–9. Despite that pas-
sage, the Board concluded that a federated computing
environment “is not limited to enterprises.” J.A. 9.
1 Petitioner argued that the phrase, being in the pre-
amble, was not limiting, but the Board rejected that con-
tention, explaining that IBM clearly relied on the term as
limiting during prosecution. J.A. 7−8. The parties now be-
fore us (IBM and the Director) agree with the Board. We
do not question the Board’s conclusion.
8 IBM v. IANCU
The Board relied for that conclusion entirely on two
specification passages and their use of the word “entity.”
One passage, from column 10, states that “[i]n the context
of the present invention, a federation is a set of distinct en-
tities, such as enterprises, organizations, institutions, etc.,
that cooperate to provide a single-sign-on, ease-of-use ex-
perience to a user.” ʼ346 patent, col. 10, lines 62–64. The
other passage, from column 8, states that “[t]he terms ‘en-
tity’ or ‘party’ generally refers to an organization, an indi-
vidual, or a system that operates on behalf of an
organization, an individual, or another system.” Id., col. 8,
lines 31−33; see J.A. 8.
On those bases, the Board construed “federated compu-
ting environment” to mean
an environment having a loosely coupled affiliation
of entities that adhere to certain standards of in-
teroperability; the federation provides a mecha-
nism for trust among those entities with respect to
certain computational operations for the users
within the federation.
J.A. 9 (emphasis added). That construction uses the speci-
fication’s definitional passage but replaces “enterprises”
with “entities.” As the Board explained when finding this
claim element met in Sunada, the key significance of that
replacement is that, under the Board’s construction, “two
computer systems (or entities) within a single enterprise
could disclose a ‘federated computer environment.’” J.A. 30
(emphasis added); see J.A. 25, 27.
We conclude that the Board’s construction is not rea-
sonable in light of the specification. In the key specification
passage quoted above, which is on its face definitional, the
patent states that a “federation” is “a loosely coupled affil-
iation of enterprises.” ’346 patent, col. 1, lines 64–65. That
passage demands that the phrase “federated computing en-
vironment” be construed to require a plurality of
IBM v. IANCU 9
enterprises unless something else in the specification con-
tradicts the passage’s plain meaning. Nothing does.
In fact, the passage is reinforced by two key passages
in the specification. The Summary of the Invention states
that the invention is addressed to “computing systems of
different enterprises that interact within a federal compu-
ting environment.” Id., col. 2, lines 54–56 (emphasis
added). And the Background of the Invention confirms the
point. As discussed above, the Background makes clear
that the problem addressed by the patent is to ease user
authentications, through single-sign-on techniques, when
the resources to which a user seeks access are not within
the unitary control of a single enterprise but, instead, are
controlled by a plurality of enterprises, who must make co-
operative arrangements to establish trust mechanisms to
meet the greater challenges of simplifying user access
when unitary control is missing. See id., col. 1, line 14
through col. 2, line 48. Being “federated,” these passages
make clear, presupposes the absence of the unitary control
that a single enterprise could exercise over its own re-
sources.
The two passages that the Board relied on do not rea-
sonably support a contrary claim construction. The column
10 passage states: “In the context of the present invention,
a federation is a set of distinct entities, such as enterprises,
organizations, institutions, etc., that cooperate to provide a
single-sign-on, ease-of-use experience to a user.” Id., col.
10, lines 62–64. At least when understood in light of the
specification language already discussed, the column 10
passage is not reasonably read as an open-ended sweeping
in of all “entities,” including mere “systems” in the sense of
physical equipment. The column 10 passage refers to enti-
ties “such as” the ones listed and includes “etc.”—both of
which, in this context, indicate that only things of a type
similar to the itemized ones are covered, namely, other es-
tablishments or ventures or firms or the like. We have rec-
ognized that “such as” and “etc.” sometimes have just that
10 IBM v. IANCU
meaning. See Archer Daniels Midland Co. v. United States,
561 F.3d 1308, 1313 (Fed. Cir. 2009) (holding that the “rule
of ejusdem generis . . . limits the additional [things] in-
cluded by the general phrase ‘etc.’ to others of the types
listed”); United States v. Nichols Copper Co.,
29 C.C.P.A.
186, 191 (1941) (holding that “by the use of the words ‘such
as’ in the paragraph we are required to determine whether
a substance not specifically named in the paragraph is like
or similar to, or belongs to the same class as, the sub-
stances therein named”). That understanding is the only
reasonable one for the passage, given the plain meaning of
the definitional and other language we have already dis-
cussed. And it is confirmed by the patent’s statement that
“[a] federated environment includes federated enterprises
or similar entities that provide a variety of services for us-
ers.” ’346 patent, col. 15, lines 55–57 (emphasis added).
A “system,” referring to just the physical equipment
and not who controls it or deals with customers in provid-
ing access to it, is not of the same type as “enterprises, or-
ganizations, institutions.” And those words themselves
may be summarized by the term “enterprise” itself, as the
definitional passage does. The column 10 sentence just
conveys that a variety of very similar words can be used to
refer to the same thing. Indeed, the quoted passage ends
with a semicolon, and what immediately follows the semi-
colon confirms that “two enterprises” are needed. Id., col.
10, line 65–col. 11, line 1 (“[A] federated environment dif-
fers from a typical single-sign-on environment in that two
enterprises need not have a direct, pre-established, rela-
tionship defining how and what information to transfer
about a user.”).
The Board’s claim construction finds no better support
in the one other basis the Board cited—the column 8 state-
ment that “[t]he terms ‘entity’ or ‘party’ generally refers to
an organization, an individual, or a system that operates
on behalf of an organization, an individual, or another sys-
tem.” Id., col. 8, lines 31−33. That sentence is part of a
IBM v. IANCU 11
general section, headed “Terminology,” that indicates how
certain words may be used anywhere in the patent. The
sentence just declares that the highly general word “entity”
can refer to quite different things—an establishment, an
individual, physical things. That declaration does not fo-
cus on defining “federated,” and it does not say which of the
types of things that can be an “entity” are the types rele-
vant to “federation” or “federated computing environment.”
The column 10 passage does that, and as explained, it must
be understood as referring only to the type of entity that is
properly summarized by the term “enterprise.”
For those reasons, we conclude that a “federated com-
puting environment” requires a plurality of distinct enter-
prises. In light of that conclusion, we vacate the Board’s
final written decision in IPR2016-00608 and remand for
the Board to determine in the first instance whether, under
the correct claim construction, Sunada anticipates the
claims at issue in that IPR.
B
In its decision in IPR2016-00609, the Board found that
Mellmer anticipates the claims at issue there. IBM seeks
reversal on the ground that Mellmer does not teach the sin-
gle-sign-on limitation. We have been shown no substantial
evidence to support the Board’s finding that Mellmer
teaches that claim limitation, and we therefore reverse the
finding of anticipation in the Mellmer IPR.
The relevant claim limitation of the ’346 patent re-
quires “triggering a single-sign-on operation on behalf of
the user in order to obtain access to a protected resource
that is hosted by the second system.” Id., col. 44, lines 45–
47. The Board construed “single-sign-on operation” to
mean “a process by which a user is authenticated at a first
entity and subsequently not required to perform another
authentication before accessing a protected resource at a
second entity.” J.A. 56. And it adopted the specification
definition of “authentication” as meaning “the process of
12 IBM v. IANCU
validating a set of credentials that are provided by a user
or on behalf of a user.” ʼ346 patent, col. 9, lines 50–51; J.A.
56. It is undisputed before us that, under those definitions,
a user “perform[s]” an authentication when the user takes
an action that provides credentials, or that plays a role in
launching a provision of credentials on the user’s behalf, to
obtain access to resources. A “single-sign-on operation”
thus is one that does not require the user to take such ac-
tion to gain access to a second entity’s resources after the
user has been authenticated with a first entity.
The Mellmer patent is titled “Managing Digital Iden-
tity Information.” In an effort to “provide better ways to
manage personal information on the Internet,” Mellmer,
col. 2, lines 36–37, Mellmer describes a “basic architecture
for managing digital identity information in a network,”
such as the Internet, Id., Abstract. Mellmer teaches
“[v]arious enhancements,” among them, techniques for “se-
curely logging in to multiple sites with a single password
and doing so from any machine on the network.” Id. More
particularly, Mellmer describes a “DigitalMe” system that,
for a user with a DigitalMe ID, eases access to various in-
dependent websites (DigitalMe partners) that participate
in the system. Id., col. 2, lines 21–35; id., col. 8, lines 40–
61. The issue before us is whether a particular part of the
described system requires a second user authentication ac-
tion to gain access to a DigitalMe partner’s resources.
Among its many teachings, Mellmer discloses that us-
ers who have a DigitalMe identity can “view, create, edit,
and delete Profiles” containing information they may use
in their on-line activity. Id., col. 4, lines 8–10. Mellmer
calls graphical versions of that information “meCards.” Id.
Mellmer also describes “accessCards” that the DigitalMe
system uses when a user seeks access to a partner website.
Id., col. 24, line 48.
Columns 25–28 describe a process for a user to gain ac-
cess to a target site by first logging into a DigitalMe
IBM v. IANCU 13
account. It is not disputed that the initial login to the Dig-
italMe site is a first authentication. What happens there-
after depends on whether the user has an accessCard for
the target site or an account on the target site. The overall
set of possibilities is shown in a flow chart, which was used
by the Board, that combines Mellmer’s Figures 31–35. J.A.
5375; J.A. 62; see Mellmer, Figs. 31–35.
14 IBM v. IANCU
The steps shown in the upper left corner, involving log-
ging into DigitalMe, involve a first authorization. The par-
ties, the Board, and now the Director have all treated the
issue of whether Mellmer teaches the single-sign-on limi-
tation as reducing to the question whether a second user
authentication action is involved in the steps taken when
“no” is the answer to “User has an account on this site?”
and the target site has a relationship with DigitalMe. We
follow suit.
Mellmer calls that scenario the “No Account On This
Site Scenario,” Mellmer col. 25, line 60 through col. 26, line
25, and the Figure 34 illustration of that scenario is em-
bedded just below the middle of the above combination
flowchart. The steps are: “DigitalMe sends blank user
login credential with unique ID” to the target site; “Digi-
talMe constructs an accessCard”; “User picks a meCard”;
and “DigitalMe logs in with new account.” Notably, the
user’s picking of a meCard for association with an ac-
cessCard is essential to the successful login to the target
site in that scenario.
IBM argued that the user action of associating a me-
Card with an accessCard constitutes an action that
launches provision of credentials to allow access to the tar-
get site, i.e., constitutes a second user authentication ac-
tion, which means that this scenario does not teach a
“single-sign-on.” The Board found otherwise. The Board
recognized that “DigitalMe ‘will construct an accessCard,
prompt the user to associate a meCard, and re-issue the
post’ before the user is logged into the partner site in
Mellmer.” J.A. 65 (quoting Mellmer, col. 25, line 66
through col. 26, line 2). But the Board agreed with Peti-
tioner that “Mellmer ‘is silent as to what information is in-
cluded in the accessCard’ described in the ‘No Account On
This Site Scenario,’” “[t]hat is, Mellmer does not teach that
the accessCard in a ‘No Account On This Site Scenario’ in-
cludes a set of credentials.” J.A. 65–66. The Board added
that “Mellmer does not teach that a meCard includes a set
IBM v. IANCU 15
of credentials.” J.A. 66. Finally, the Board stated that
“DigitalMe initially attempts a login with ‘blank login
data’” in this scenario; 2 “the original test post does not in-
clude a set of credentials”; and “Mellmer does not further
disclose adding a set of credentials to the post before Digi-
talMe reissues it or before the use is logged into the partner
site.” J.A. 66–67. For those reasons, the Board found that
this scenario involved only one user authentication action,
and thus practiced a single-sign-on operation within the
relevant claim limitation of the ʼ346 patent. See J.A. 67.
The overall finding that this portion of Mellmer teaches
a process involving only one user authentication action is
not supported by substantial evidence. To begin with, even
if the Board were correct that Mellmer is “silent” about the
content of the accessCard, that characterization would not
alone support a finding that there was no user authentica-
tion action in this scenario if, as appears, the Board meant
that it simply could not tell one way or the other whether
the accessCard contains credentials. Silence in that sense
would not by itself suffice for the Petitioner to meet its bur-
den to prove, by a preponderance of the evidence, that there
was no user authentication action in this scenario. See 35
U.S.C. § 316(e). Nor would that burden be met merely by
adding a finding that IBM did not prove the opposite, i.e.,
a finding of “the absence of sufficient evidence showing the
provision or validation of a set credentials at the partner
site” in this scenario. J.A. 67.
In any event, the Board erred in its “silence” determi-
nation, and conclusion about the absence of evidence sup-
porting IBM’s position on this scenario, by taking too
narrow a view of Mellmer. The Board unreasonably viewed
2 Mellmer says of the test post: “DigitalMe software
attempts a login with blank login data, except for a globally
unique identity for the DigitalMe user.” Mellmer, col. 25,
lines 61–63 (emphasis added).
16 IBM v. IANCU
the No Account On This Site Scenario in isolation from its
plain context in Mellmer. This particular scenario is part
of a larger single flow chart with yes-no branching at vari-
ous points. This scenario is the ending of one path through
a process that, for the user, begins with the earlier common
portions of the flow chart. Those earlier portions neces-
sarily bear on the meaning of terms found throughout the
overall flow chart.
Once the focus is properly widened to what columns
24–26 teach for the whole set of options and scenarios
shown in the above flow chart, substantial evidence does
not support a finding that there is no user action triggering
an authentication at the target site in this particular sce-
nario. The Board did not question that the user action in
associating a meCard with an accessCard is necessary for
the logon, as the evidence undisputedly showed. Nor did
the Board question that DigitalMe then communicates
with the target site to trigger the logon to that site. The
flow chart and associated patent descriptions, together
with expert testimony, establish those facts. See J.A. 6482
(Spielman), 6362 (Olivier).
Even as to the accessCard, the evidence is one-sided
against the Board’s finding. Consistent with the flow
chart’s indication that accessCards directly lead to login at
the target site, Mellmer, in its descriptions of accessCards
in the earlier parts of the overall flow chart, repeatedly in-
dicates that accessCards contain authenticating infor-
mation that is used for authorization at the target site.
See, e.g., Mellmer, col. 24, line 62 through col. 25, line 4;
col. 25, lines 9–13 (“Users also need only remember their
DigitalMe user ID and password; the DigitalMe software
caches and submits all other web login credentials. Also,
from the DigitalMe site, the user can list, maintain, and
launch these accessCards directly.” (emphasis added)); col.
25, lines 32–43 (at lines 40–42: “DigitalMe software will
have captured this login data as an accessCard structure
which can be applied to login automatically in the future.”);
IBM v. IANCU 17
col. 25, line 63 through col. 26, line 2; col. 26, lines 32–35.
IBM’s expert, in her declaration, relied on this material to
attest that, in the No Account On This Site Scenario, “when
DigitalMe re-issues the post on behalf of the user” after the
user associates a meCard with the accessCard, the Digi-
talMe service is sending the user’s newly-created ac-
cessCard for the DigitalMe partner site—which accessCard
includes the user’s login information for the partner site.”
J.A. 6482.
The Board did not cite, and the Director in this court
has not cited, anything in Mellmer that supports a contrary
finding. Nor have we been shown any basis for discrediting
the testimony of IBM’s expert, which was grounded solidly
in consideration of the full column 24–26 passages relevant
to understanding what occurs in the No Account On This
Site Scenario. And the Petitioner, in its Reply, answered
IBM’s evidence only by insisting, incorrectly, that the No
Account On This Site Scenario be considered in isolation
from the column 24–26 material involving the other sce-
narios that are part of the overall set of options shown in
the combination flow chart. J.A. 5435–37. In these circum-
stances, we see no substantial evidence to support the
Board’s finding that Petitioner proved that Mellmer
teaches the single-sign-on limitation of the claims at issue
in this IPR.
III
The Board’s decision in IPR2016-00608 is vacated be-
cause it rests on an incorrect claim construction, and the
matter is remanded for further proceedings consistent with
this opinion. The decision in IPR2016-00609 is reversed.
Costs awarded to IBM.
VACATED AND REMANDED in No. 18-1065
REVERSED in No. 18-1066
