Ex Parte Blakley et al

Patent Trial and Appeal Board

Mar 25, 2013

10334284 (P.T.A.B. Mar. 25, 2013)

UNITED STATES PATENT AND TRADEMARK OFFICE
________________

BEFORE THE PATENT TRIAL AND APPEAL BOARD
________________

Ex parte GEORGE ROBERT BLAKLEY III,
HEATHER MARIA HINTON, ANTHONY JOSEPH NADALIN, and
AJAMU AKINWUNMI WESLEY
________________

Appeal 2010-007794
Application 10/334,284
Technology Center 2400
________________

Before JEAN R. HOMERE, JASON V. MORGAN, and
TREVOR M. JEFFERSON, Administrative Patent Judges.

MORGAN, Administrative Patent Judge.

DECISION ON APPEAL
Appeal 2010-007794
Application 10/334,284

2
STATEMENT OF THE CASE
Introduction
This is an appeal under 35 U.S.C. § 134(a) from the Examiner’s final
rejection of claims 1, 3 – 7, 9 – 13, and 15 – 20. Claim 2, 8, and 14 are
canceled. App. Br. 3. We have jurisdiction under 35 U.S.C. § 6(b)(1).
We affirm-in-part.
Invention
The invention relates to a method in which federated domains interact
within a federated environment. Domains within a federation can initiate
federated single-sign-on operations for a user at other federated domains. A
point-of-contact server within a domain relies upon a trust proxy within the
domain to manage trust relationships between the domain and the federation.
Trust proxies interpret assertions from other federated domains as necessary.
Trust proxies may have a trust relationship with one or more trust brokers,
and a trust proxy may rely upon a trust broker for assistance in interpreting
assertions. See Abstract.
Exemplary Claims (Emphases Added)
1. A method for authenticating a user within a data processing
system to enable the user to access a controlled resource, the
method comprising:
generating an authentication assertion for the user at a
first trust proxy within a first domain;
at a system in a second domain, receiving a request from
a client to access a controlled resource within the second
domain;
sending the authentication assertion from the first
domain to a second trust proxy in the second domain;
Appeal 2010-007794
Application 10/334,284

3
validating the authentication assertion at the second trust
proxy in the second domain;
upon validating the authentication assertion, building a
session for the user so that the user appears to the system in the
second domain as an authenticated user; and
providing access to the controlled resource using the
session.
3. The method of claim 1 further comprising:
within the first domain, generating the authentication
assertion for the user at the first trust proxy prior to receipt of
the request for the controlled resource at the system in the
second domain; and
pushing the authentication assertion from the first
domain to the second domain along with the request for the
controlled resource.
4. The method of claim 1 further comprising:
pulling the authentication assertion from the second trust
proxy from the first trust proxy after receipt of the request for
the controlled resource at the system in the second domain.
5. The method of claim 1 further comprising:
establishing a trust relationship between the first trust
proxy and the second trust proxy.
6. The method of claim 1 further comprising:
maintaining an indirect relationship between the first
trust proxy and the second trust proxy through a trust broker.
Rejection
The Examiner rejects claims 1, 3 – 7, 9 – 13, and 15 – 20 under 35
U.S.C. § 102(e) as being anticipated by Moreh (US 6,959,336 B2; Oct. 25,
2005; filed Apr. 7, 2001). Ans. 3 – 4.
Appeal 2010-007794
Application 10/334,284

4
ISSUES
1. Did the Examiner err in finding that Moreh discloses (1)
“generating an authentication assertion for the user at a first trust proxy
within a first domain,” “sending the authentication assertion from the first
domain to a second trust proxy in the second domain,” and “validating the
authentication assertion at the second trust proxy in the second domain,” and
(2) “building a session for the user” and “providing access to the controlled
resource using the session,” as recited in claim 1?
2. Did the Examiner err in finding that Moreh discloses “pushing the
authentication assertion from the first domain to the second domain along
with the request for the controlled resource,” as recited in claim 3?
3. Did the Examiner err in finding that Moreh discloses “pulling the
authentication assertion from the second trust proxy from the first trust
proxy,” as recited in claim 4?
4. Did the Examiner err in finding that Moreh discloses “establishing
a trust relationship between the first trust proxy and the second trust proxy,”
as recited in claim 5?
5. Did the Examiner err in finding that Moreh discloses “maintaining
an indirect relationship between the first trust proxy and the second trust
proxy through a trust broker,” as recited in claim 6?
ANALYSIS
Claims 1, 7, 13, 19, and 20
In rejecting independent claim 1, the Examiner finds that Moreh,
which is directed to a method and system of federated authentication service,
discloses “generating an authentication assertion for the user at a first trust
Appeal 2010-007794
Application 10/334,284

5
proxy within a first domain,” “sending the authentication assertion from the
first domain to a second trust proxy in the second domain,” and “validating
the authentication assertion at the second trust proxy in the second domain,”
as recited in claim 1. See Ans. 3 (citing Moreh col., 5, ll. 12 – 17, col. 6, ll.
16 – 17 and 20 – 23, and col. 14, ll. 28 – 47). Specifically, the Examiner
finds that Moreh discloses a protocol proxy (i.e., a first trust proxy), such as
FAST (federated authentication service technology) Protocol Proxy 132, in a
first domain 112 that generates an authentication name assertion (i.e., an
authentication assertion). See Ans. 6 (citing Moreh col. 2, ll. 48 – 62 and col.
6, ll. 16 – 17); see also Moreh fig. 2. The Examiner finds that Moreh
discloses sending this authentication name assertion to a server application
in a second domain 114, such as Application 126 with XML Adapter 138,
which then validates the authentication name assertion using the secure
remote protocol (SRP). See Ans. 7 – 8; see also Moreh fig. 2.
Appellants argue that the Examiner erred because the protocol proxy
is not a trust proxy. See App. Br. 12. Specifically, Appellants argue “a server
that ‘establishes and maintains a trust relationship between two entities in a
federation’ by handling authentication token format translation and any user
identity or attribution [sic] translation.” Id. However, the Specification
describes a “trust proxy” broadly as an entity that “establishes and maintains
a trust relationship between two entities in a federation.” Spec. 37, ll. 21 –
24. The Specification further states that a “trust proxy generally has the
ability to handle authentication token formation translation,” Spec. 37, ll. 24
– 25 (emphasis added), and discloses an embodiment in which a trust proxy
is “responsible for any user identity translation or attribute translation,”
Spec. 38, ll. 24 – 25. Accordingly, under the broadest reasonable
Appeal 2010-007794
Application 10/334,284

6
interpretation, we find that consistent with the Specification that a trust
proxy is any entity that establishes and maintains a trust relationship
between two entities in a federation.
Moreh discloses a “protocol proxy to . . . authenticate the client based
on the client credentials, and to create from the client credentials an
authentication name assertion allowing the client to access the server
application.” Moreh col. 2, ll. 58 – 62. By creating an authentication name
assertion that allows the client to access the server application, the protocol
proxy establishes and maintains a trust relationship between the client and
the server application (two entities in a federation). Thus, the protocol proxy
is a first trust proxy. Therefore, we agree with the Examiner, Ans. 6, that
Moreh discloses “generating an authentication assertion for the user at a first
trust proxy within a first domain,” as recited in claim 1.
Appellants argue that the Examiner erred in finding that the server
application discloses a second trust proxy. See App. Br. 12 – 13.
Specifically, Appellants argue that the challenge-response protocol of the
SRP “simply proves to the server application that the client is the ‘proper
owner’ of the name assertion . . . . [A] trust proxy, in contrast, handles
‘authentication token format translation’ and any ‘user identity or attribution
translation’ to establish and maintain a trust relationship.” App. Br. 13.
However, as discussed above, Appellants’ arguments are based on
limitations that are not found in the claim recitations and that are not
supported by any special definition in the Specification. Thus, Appellants’
arguments are not commensurate with the scope of the claimed invention
and are not persuasive of error in the Examiner’s rejection.
Appeal 2010-007794
Application 10/334,284

7
Furthermore, Moreh discloses that “client 22 presents a name
assertion to a server application 38, the server application 38 retrieves the
SRP verifier from the name assertion and uses the SRP scheme to challenge
the client 22 to prove possession of the SRP secret.” Moreh col. 5, ll. 23 –
27. Because the server application uses the SRP scheme to challenge the
client in order to allow the client to access the server application, the server
application establishes and maintains a trust relationship between two
entities in a federation: the client and the server application itself. Thus, the
server application falls within a broad but reasonable interpretation of a trust
proxy. Moreh further illustrates an example where the client, which is
associated with employee 118, is in a first domain 112 while the server
application, Application 126 with XML Adapter 138, is in a second domain
114. See Moreh fig. 2 and col. 10, ll. 39 – 41. Since the client in the first
domain associated with employee 118 presents the authentication name
assertion to the server application in the second domain, we agree with the
Examiner, Ans. 3, that Moreh discloses “sending the authentication assertion
from the first domain to a second trust proxy in the second domain,” as
recited in claim 1.
Appellants further argue that the Examiner erred because the SRP
protocol simply “‘[verifies] that the subject [20] was the original and
intended recipient of the [name assertion] document . . .,’” App. Br. 14
(citing Moreh col. 14, ll. 41 – 44), but the verification “does not ‘validate the
[name] assertion’ – which is what the claim requires,” id; see also Reply Br.
5. That is, Appellants argue that the server application’s validation applies
only to the subject of the authentication name assertion, not to the
authentication name assertion itself. However, the Examiner correctly finds
Appeal 2010-007794
Application 10/334,284

8
that Moreh discloses that a “valid name assertion” must be used by the client
to access the server application. See Ans. 8 (citing Moreh col. 3, ll. 60 – 65).
The Examiner also correctly finds that the authentication name assertion is
digitally signed, enabling the server application to use the authentication
name assertion to give the client access to the server application. See Ans. 8
(citing, e.g. Moreh col., 5, ll. 12 – 17). Moreover, Moreh’s authentication
name assertions also have an expiration time. See Moreh col. 10, ll. 17 – 18;
see also Moreh col. 16, ll. 18 – 22. Thus, as part of verifying that a client is
authorized to access the server application, the server application also
validates that the authentication name assertion is properly signed and has
not expired (i.e., is still valid). Therefore, we agree with the Examiner, Ans.
3, that Moreh discloses “validating the authentication assertion at the second
trust proxy in the second domain,” as recited in claim 1.
In rejecting claim 1, the Examiner further relies on Moreh as
disclosing building a session for a user and providing access to a resource
using the session. See Ans. 3 (citing col. 2, ll. 48 – 62, col. 3, ll. 60 – 62, col.
5, ll. 1 – 4, col. 6, ll. 1 – 19, and col. 9, ll. 9 – 17). Appellants argue that the
Examiner erred because Moreh “says nothing about ‘building a session for
the user’ for” the purpose of accessing the server application. App. Br. 14.
Appellants contend “[t]he term ‘session’ is defined in the written description
as ‘the set of transactions from (and including) the initial user authentication
(i.e. logon), to logout.’” Id. However, the Examiner correctly finds that the
term “session” is not given a special definition in the Specification, see Ans.
9, but instead a reasonable broad interpretation of a “session” includes a
“connection between a client and server by which the client [can] access the
server,” Ans. 10.
Appeal 2010-007794
Application 10/334,284

9
Appellants argue that the Examiner’s findings impermissibly
“conflate the ‘building a session’ and ‘providing access using the session’
steps – which are distinct – into a single [step].” Reply Br. 7; see also App.
Br. 15. However, the Examiner correctly finds that Moreh’s use of a
protocol proxy and authentication name assertion allows the server
application to authenticate the client, thus allowing the client to access the
server application. See Ans. 10 (citing, e.g., Moreh col. 2, ll. 60 – 62). That
is, by verifying that the client is entitled to access the server application,
Moreh’s server application creates an authenticated connection with the
client, and thus builds a session for the user. The client then uses the
connection to access the server application (i.e., access the controlled
resource). See Moreh col. 2, ll. 60 – 62. Therefore, we agree with the
Examiner, Ans. 3, that Moreh disclose both “building a session for the user”
and “providing access to the controlled resource using the session,” as
recited in claim 1.
Accordingly, we find the Examiner did not err in rejecting claim 1, or
in rejecting claims 7, 13, 19 and 20, which Appellants do not argue
separately with sufficient specificity. See App. Br. 16.
Claims 3, 9, and 15
In rejecting claim 3, which depends on claim 1, the Examiner finds
that Moreh discloses generating the assertion prior to receipt of the request
and pushing the assertion from the first domain to the second domain along
with the request for the controlled resource. See Ans. 3 – 4 (citing Moreh
col. 6, ll. 25 – 31). Specifically, the Examiner finds that the authentication
name assertion is re-usable and is thus used for subsequent requests to a
Appeal 2010-007794
Application 10/334,284

10
server application (i.e., that the authentication name assertion is generated
prior to receipt of such subsequent requests). See Ans. 11.
Appellants argue the Examiner erred because in Moreh “there is no
‘pushing’ of the assertion from the protocol proxy to the server application.
. . . Rather, where the assertion is re-usable, the client provides it to the
server application directly.” App. Br. 17. That is, Appellants argue that
Moreh fails to disclose pushing the authentication assertion from a first trust
proxy to a second trust proxy. However, Appellants’ arguments are not
commensurate with the scope of the claimed invention. Claim 3 does not
require a push from the first trust proxy or even a push to a second trust
proxy; rather, claim 3 recites “pushing the authentication assertion from the
first domain to the second domain” (emphasis added). In Moreh, the client
for employee 118 is in a first domain 112 while the application server, XML
Adapter 138 with Application 126, is in a second domain 114. See Moreh
fig. 2. The client presents the re-usable authentication name assertion to
make subsequent requests to access the server application. See Moreh col. 6,
ll. 26 – 28. This presentation represents a push of the authentication name
assertion from a first domain 112 to a second domain 114, as part of a
request to access the server application (i.e., a request for a controlled
resource). Therefore, we agree with the Examiner, Ans. 3 – 4, that Moreh
discloses “pushing the authentication assertion from the first domain to the
second domain along with the request for the controlled resource,” as recited
in claim 3.
Accordingly, we find the Examiner did not err in rejecting claim 3, or
in rejecting claims 9 and 15, which Appellants do not argue separately with
sufficient specificity. See App. Br. 17.
Appeal 2010-007794
Application 10/334,284

11
Claims 4, 10, and 16
In rejecting claim 4, which depends on claim 1, the Examiner finds
that Moreh discloses “pulling the assertion from the first domain.” Ans. 3 –
4 (citing Moreh col. 6, ll. 25 – 31). Appellants argue the Examiner erred
because “nothing gets pulled from the protocol proxy because the client
already has the name assertion.” App. Br. 18; see also Reply Br. 9. That is,
Appellants argue that Moreh fails to disclose “pulling the authentication
assertion from the second trust proxy from the first trust proxy,” as recited in
claim 4.
We agree with Appellants. Unlike claim 3, which merely requires a
push from the first domain to the second domain, claim 4 recites that the
second trust proxy pulls the authentication assertion from the first trust
proxy. Yet, in Moreh the client presents the authentication name assertion to
the server application (i.e., the second trust proxy). See Moreh col. 6, ll. 26 –
28. Furthermore, the Examiner’s findings do not show that the server
application pulls the authentication name assertion from the protocol proxy
(i.e., the first trust proxy). Therefore, we find the Examiner erred in finding
that Moreh discloses “pulling the authentication assertion from the second
trust proxy from the first trust proxy,” as recited in claim 4.
Accordingly, we find the Examiner erred in rejecting claim 4, and in
rejecting claims 10 and 16, which contain similar recitations and are argued
similarly. See App. Br. 18.
Claims 5, 11, and 17
In rejecting claim 5, which depends on claim 1, the Examiner finds
that Moreh discloses “establishing a trust relationship between the first trust
Appeal 2010-007794
Application 10/334,284

12
proxy and the second trust proxy.” See Ans. 4 (citing Moreh col. 7, ll. 5 – 14
and col. 16, ll. 14 – 22). In particular, the Examiner finds that Moreh’s
server application only trusts authentication name assertions produced by an
authentic protocol proxy. See Ans. 12 – 13 (citing Moreh col. 8, ll. 6 – 8).
Appellants argue the Examiner erred because “client 22 merely
delivers the name assertion (generated by the protocol proxy) to the server
application; it does not ‘establish a trust relationship’ in any way.” App. Br.
18; see also Reply Br. 9 – 10. However, Appellants’ arguments are not
responsive to the Examiner’s rejection, which relies on the protocol proxy
being able to authenticate itself using its own valid name assertion with
which it signs generated authentication name assertions for clients. See
Moreh col. 8, ll. 2 – 11. This self-authentication capability enables the server
application to trust the protocol proxy, which thus establishes a trust
relationship between the protocol proxy (i.e., a first trust proxy) and the
server application (i.e., a second trust proxy). Therefore, we agree with the
Examiner, Ans. 4 and 12 – 13, that Moreh discloses “establishing a trust
relationship between the first trust proxy and the second trust proxy,” as
recited in claim 5.
Accordingly, we find the Examiner did not err in rejecting claim 5, or
in rejecting claims 11 and 17, which Appellants do not argue separately with
sufficient specificity. See App. Br. 19.
Claims 6, 12, and 18
In rejecting claim 6, which depends on claim 1, the Examiner finds
that Moreh discloses “maintaining an indirect relationship between the first
trust proxy and the second trust proxy through a trust broker.” See Ans. 4
Appeal 2010-007794
Application 10/334,284

13
(citing Moreh col. 7, ll. 5 – 14 and col. 16, ll. 14 – 22). In particular, the
Examiner finds that Moreh’s authentication agent acts as the claimed trust
broker. See Ans. 13 (citing Moreh col. 7, ll. 5 – 14).
Appellants argue the Examiner erred because “client 22 is not a ‘trust
broker.’” App. Br. 19; see also Reply Br. 10. However, the Examiner relied
on Moreh’s authentication agent, not on its client, as disclosing a trust
broker. See Ans. 13. This authentication agent is used to resolve subject
information to an appropriate authentication mechanism. See Moreh col. 7,
ll. 9 – 10. The Examiner also finds that Moreh explicitly discloses a trust
relationship between Moreh’s protocol proxy and server application (i.e., a
maintained indirect relationship). See Ans. 13 (citing Moreh col. 8, ll. 6 – 8).
Appellants’ arguments do not persuasively address the Examiner’s findings
and therefore (1) fail to show a meaningful distinction between the
authentication agent of Moreh and the claimed trust broker and (2) fail to
show a meaningful distinction between the trust relationship between
Moreh’s protocol proxy and server application and the claimed maintained
indirect relationship. Therefore, we agree with the Examiner, Ans. 4 and 13,
that Moreh discloses “maintaining an indirect relationship between the first
trust proxy and the second trust proxy through a trust broker,” as recited in
claim 6.
Accordingly, we find the Examiner did not err in rejecting claim 6, or
in rejecting claims 12 and 18, which Appellants do not argue separately with
sufficient specificity. See App. Br. 19.
Appeal 2010-007794
Application 10/334,284

14
DECISION
We affirm the Examiner’s decision to reject claims 1, 3, 5 – 7, 9, 11 –
13, 15, and 17 – 20.
We reverse the Examiner’s decision to reject claims 4, 10, and 16.
No time period for taking any subsequent action in connection with
this appeal may be extended under 37 C.F.R. § 1.136(a)(1)(iv).

AFFIRMED-IN-PART

tj