Ex Parte Hinton et al

Patent Trial and Appeal Board

Oct 16, 2014

12182654 (P.T.A.B. Oct. 16, 2014)

UNITED STATES PATENT AND TRADEMARK OFFICE
____________________

BEFORE THE PATENT TRIAL AND APPEAL BOARD
____________________

Ex parte HEATHER MARIA HINTON,
SRIDHAR R. MUPPIDI, and DAVID EUGENE COX
____________________

Appeal 2012-006606
Application 12/182,654
Technology Center 2400
____________________

Before ROBERT E. NAPPI, BRUCE R. WINSOR, and
JOHN F. HORVATH, Administrative Patent Judges.

HORVATH, Administrative Patent Judge.

DECISION ON APPEAL

Appeal 2012-006606
Application 12/182,654

2
STATEMENT OF THE CASE
Appellants appeal under 35 U.S.C. § 134 from a rejection of claims 1–
27. We have jurisdiction under 35 U.S.C. § 6(b).
We affirm.

SUMMARY OF THE INVENTION
The claims are directed to a computer implemented method for
propagating information from a trust chain.
Claim 1, reproduced below, is illustrative of the claimed subject
matter:
1. A computer implemented method for propagating
information in a trust chain processing, the method comprising:
receiving, upon a trust client invoking the trust chain
processing, a mapped security information, the mapped security
information being stored in a data storage associated with a
data processing system;
locating, according to a configuration, a set of security
information attributes in the mapped security information;
packaging the set of security information attributes to
form a packaged security information;
issuing the packaged security information to a target
system, the target system being distinct from the trust client that
invoked the trust chain processing; and
monitoring the trust chain processing, using a monitoring
module in the trust chain processing, the monitoring providing
a subset of the set of security information attributes to a
monitoring log using a uniform schema, the monitoring module
identifying the subset according to information corresponding
to the target system in the configuration.

Appeal 2012-006606
Application 12/182,654

3
REJECTIONS
1. Claims 1, 2, 6–11, 15–20, and 24–27 stand rejected under
35 U.S.C §103(a) as being unpatentable over Understanding
WebLogic,1 Securing WebLogic,2 Birk,3 and Pearson.4
2. Claims 3–5, 12–14, and 21–23 stand rejected under 35 U.S.C
§103(a) as being unpatentable over Understanding WebLogic,
Birk, and Profiles for the OASIS Security Assertion Markup
Language (SAML).5

ISSUES
A. Whether Pearson’s identity provider provides a subset of a set of
security information attributes to a monitoring log using a uniform
schema, where the subset is based on a configuration.
B. Whether WebLogic Server includes a configuration that identifies
a plurality of trust chain processing modules.
C. Whether WebLogic Server or Birk loads a configuration as part of
dynamically configuring trust chain processing.

1 BEA Systems, Inc., Understanding WebLogic Security (BEA Systems,
Inc.,version 9.0, 2005).
2 BEA Systems, Inc., Securing WebLogic Server (BEA Systems, Inc.,
version 9.1, 2005).
3 U.S. Pat. Pub. No. 2006/0015727 A1, Jan. 19, 2006.
4 U.S. Pat. Pub. No. 2006/0218629 A1, Sept. 28, 2006.
5 Conor P. Cahill et al., Profiles for the OASIS Security Assertion Markup
Language (SAML) V2.0 (John Hughes et al. eds., version 2.0, 2005).
Appeal 2012-006606
Application 12/182,654

4
ANALYSIS
We have reviewed the Examiner’s rejections in light of Appellants’
arguments that the Examiner has erred. We are not persuaded by
Appellants’ arguments, and sustain the Examiner’s rejections for the
following reasons.

A. Whether Pearson’s identity provider provides a subset of a set of
security information attributes to a monitoring log using a uniform
schema, where the subset is based on a configuration.

Appellants argue that the Examiner has erred in rejecting claim 1
because Pearson fails to disclose a monitoring module for monitoring trust
chain processing that provides (1) a subset of security information attributes
(2) to a monitoring log (3) using a uniform schema, where the subset of
security information attributes is (4) determined based on a configuration.
App. Br. 16–17. We find Appellants’ arguments unpersuasive, and therefore
sustain the Examiner’s rejection.6

1. Whether Pearson’s identity provider provides security
information attributes to a monitoring log.

Appellants first argue that nothing in Pearson “teach[es] or suggest[s]
that Pearson’s identity provider system sends a log entry to a log server.”
App. Br. 16. The Examiner finds Pearson’s identify provider is a monitoring
module, and that Pearson teaches, in paragraph 35, that the identity provider
sends a log entry to a log server. Ans. 9. We agree with the Examiner.

6 Appellants do not separately argue for the patentability of claims 2, 6–11,
15–20, and 24–27; therefore, we sustain the Examiner’s rejection of these
claims as well.
Appeal 2012-006606
Application 12/182,654

5
Pearson discloses a log monitored single sign-on (“SSO”) system
consisting of a customer / web browser, a first service provider, a second
identity provider, and a log server. Pearson ¶ 31, Fig. 3. The Examiner
finds, and we agree, that upon validating the authenticity of the customer /
web browser, Pearson teaches:
[T]he second identity provider sends a log record to the master
log server that contains the customer’s Single Sign-On
username, the second identity provider identifier, the log server
identifier, the opaque session identifier, a timestamp, and a
record identifier that identifies that this is a “SSO Session Start”
record.
Id. ¶ 35 (emphasis added). Thus, we sustain the Examiner’s finding that
Pearson teaches a monitor module (identity provider) that sends security
information attributes to a monitoring log (master log server).

2. Whether Pearson’s identity provider provides a subset of
security information attributes to a monitoring log.

Appellants next argue that even if Pearson’s identity provider does
send log entries to a monitoring log (we find supra it does), Pearson fails to
disclose that the information in the log entries are a subset of security
information attributes in the mapped security information. App. Br. 16. The
Examiner finds that both Pearson and WebLogic disclose processing SAML
(Security Assertion Markup Language) statements, and that the information
Pearson logs in the “SSO Session Start” record (e.g., username, second
identity provider identifier, etc.) is a subset of security information attributes
since it does not contain all of the security information in the processed
SAML statements, such as the SAML statements disclosed in WebLogic.
Ans. 18–19. We agree with the Examiner.
Appeal 2012-006606
Application 12/182,654

6
The Examiner rejected claim 1 as obvious in view of Understanding
WebLogic, Securing WebLogic, Birk, and Pearson, not as anticipated by
Pearson. The well-known “test for obviousness is what the combined
teachings of the references would have suggested to one of ordinary skill in
the art.” In re Young, 927 F.2d 588, 591 (Fed. Cir. 1991). Consequently,
“[n]on-obviousness cannot be established by attacking references
individually where the rejection is based upon the teachings of a
combination of references.” In re Merck & Co., 800 F.2d 1091, 1097 (Fed.
Cir. 1986).
We therefore sustain the Examiner’s finding that the combination of
Understanding WebLogic, Securing WebLogic, Birk, and Pearson discloses
a monitoring module for monitoring trust chain processing that provides (1)
a subset of security information attributes (2) to a monitoring log.

3. Whether Pearson’s identity provider provides security
information attributes to a monitoring log using a uniform
schema.

Appellants next argue that even if Pearson’s identity provider does
send log entries to a monitoring log (we find it does), Pearson fails to
disclose that it sends the log entries to the monitoring log using a uniform
schema, since the content and organization of the “SSO Session Start” and
“Authentication Request—First Login” records are different. App. Br. 16–
17. We are not persuaded by Appellants’ arguments.
First, the Examiner finds, and we agree, that the Specification does
not define “uniform schema” or provide any particular structure for a
“uniform schema,” but merely indicates that “‘[a] schema is information
about the organization of data.’” Ans. 21 (quoting Spec. ¶ 72). Next, the
Appeal 2012-006606
Application 12/182,654

7
Examiner finds, and we agree, that a “schema” generally refers to the layout
of a database rather than the records written to the database, and that a
database with a uniform schema can have multiple tables, storing different
types of records having different data structures. Ans. 19–20; see also,
Understanding WebLogic 6-19. Consequently, the Examiner finds, and we
agree, that providing information to a monitoring log using a uniform
schema includes providing different types of records having different data
structures to the monitoring log, such as Pearson’s “SSO Session Start” and
“Authentication Request—First Login” records. Ans. 19–20.
Moreover, we note that Appellants’ argument is premised on
Appellants’ belief that Pearson’s “SSO Session Start” and “Authentication
Request—First Login” records are sent to the same log server. To the
contrary, Pearson discloses:
[T]he second identity provider sends a log record to the master
log server that contains the customer’s Single Sign-On
username, the second identity provider identifier, the log server
identifier, the opaque session identifier, a timestamp, and a
record identifier that identifies that this is a “SSO Session
Start” record. . . . In addition to the master log record that the
second identify provider submits to the master log server . . .
the second identify provider submits a log record to a log
server, e.g., to the first log server. In a particular embodiment,
the log record indicates an SSO session start. Further, the log
record includes the opaque session identifier, the identity
provider identifier, the service provider identifier that is making
the authentication request, a timestamp, and a record identifier
that indicates that this is an “Authentication Request—First
Login.”
Pearson ¶ 35 (emphasis added), Fig. 3. Thus, Pearson teaches sending the
“SSO Session Start” record to the master log server, and the “Authentication
Request—First Login” record to the first log server. Id. Consequently, even
Appeal 2012-006606
Application 12/182,654

8
if the Examiner’s finding that providing information to a monitoring log
using a uniform schema includes providing different types of records having
different data structures to the monitoring log was erroneous, it would be
immaterial to our decision since Pearson does not in fact teach sending the
“SSO Session Start” and “Authentication Request—First Login” records to
the same log server as Appellants contend.
For all the reasons discussed above, we sustain the Examiner’s finding
that Pearson’s identity provider system provides security information
attributes to a monitory log using a uniform schema.

4. Whether Pearson’s identity provider provides a subset of
security information attributes based on a configuration.

Appellants next argue that Pearson’s identity provider does not
provide a subset of the set of security information attributes based on a
configuration. App. Br. 17. Specifically, Appellants argue that:
Pearson cannot logically select the (absent) security attributes
to include in the (absent) log entry using the (absent) uniform
schema according to any particular criterion, let alone
according to a particular information in a particular
configuration, such as the information corresponding to the
target system in the configuration in claim 1.
App. Br. 17. The Examiner finds: (a) Pearson teaches a single sign-on
server that includes a monitoring module and generates SAML assertions;
(b) Understanding WebLogic teaches generating SAML assertions using
Credential Mapping providers that have been configured for particular target
sites or resources; and therefore (c) the combination teaches selecting
security information attributes for a target based on a configuration. Ans. 9,
21; see Pearson ¶ 46; Understanding WebLogic 2-7, 3-12. Appellants argue
Appeal 2012-006606
Application 12/182,654

9
that WebLogic’s configurable Credential Mapping providers disclose
mapping security information based on a target, not locating or selecting it.
App. Br. 19. The Examiner finds “no rational distinction between
‘mapping’ information and ‘locating’ information,” and since security
information “attributes exist and are configurable they are also inherently
and necessarily located in order to be processed.” Ans. 22–23. We agree
with the Examiner.
Pearson discloses an identity provider that logs an “SSO Session
Start” record in a master log server. Pearson ¶ 35. Pearson also discloses
generating SAML assertions that include at least some of the information
stored in the “SSO Session Start” record. Id. ¶¶ 37, 46. Understanding
WebLogic discloses configuring Credential Mapping providers to issue
SAML assertions to particular targets or resources. Understanding
WebLogic 2-7. Credential Mapping providers are configured to provide “a
mapping of credentials used by WebLogic Server to credentials used in a
legacy or remote system,” and are able to “handle several different types of
credentials (for example, username/password combinations, SAML
assertions, public key certificates, and alias/credential type combinations).”
Id. at 4-12. In other words, Credential Mapping providers are configured to
locate, select, and map subsets of security information attributes (e.g.,
username/password) based on target systems in order to generate SAML
assertions for those target systems. Consequently, we agree with and sustain
the Examiner’s finding that the combination of Pearson and WebLogic
discloses providing a subset of security information attributes based on a
configuration.

Appeal 2012-006606
Application 12/182,654

10
B. Whether WebLogic Server includes a configuration that identifies
a plurality of trust chain processing modules.

Appellants argue that the Examiner has erred in rejecting claim 2
because Securing WebLogic merely discloses that the process of configuring
the WebLogic Server is iterative, not that the WebLogic Server identifies a
plurality of modules to be included in trust chain processing. App. Br. 20.
We are not persuaded by Appellants’ argument.
Claim 1 recites, inter alia, “locating, according to a configuration, a
set of security information attributes in [a] mapped security information.”
Claims App’x. Claim 2 recites, inter alia, “wherein the configuration
identifies a plurality of processing modules to be included in the trust chain
processing.” Id. Appellants do not construe the term “configuration,” nor is
the term defined in Appellants’ Specification. Nonetheless, in view of the
discussion in paragraphs 59 and 61 of Appellants’ Specification, it is
apparent that the scope of the term “configuration” includes parameters that
identify one or more security modules.
The Examiner finds Securing WebLogic, on pages 2-7 and 2-8,
discloses that WebLogic Server includes a configuration that identifies a
plurality of trust chain processing modules. Ans. 10, 24. In particular, the
Examiner finds Securing WebLogic discloses that “configurable elements
are used in WebLogic,” allowing for a “multitude of configurations available
for the system for processing.” Id. at 24. We agree with the Examiner.
Securing WebLogic discloses customizing WebLogic Server’s default
security configuration by “Configur[ing] additional security providers.”
Securing WebLogic 2-7 (emphasis added). Security providers are “modular
components that handle specific aspects of security, such as authentication
Appeal 2012-006606
Application 12/182,654

11
and authorization.” Id. at 2-2 (emphasis added). The different types of
security providers WebLogic Server can use include: Authentication,
Identity Assertion, Authorization, Role Mapping, Adjudication, Credential
Mapping, Keystore, Certificate Lookup and Validation, Certificate Registry
and Auditing. Id. at 2-2 to 2-4. Authentication security providers are used
to verify users or system processes, in part by “remembering, transporting
and making identity information available to various components of a
system when that information is needed.” Id. at 2-2 (emphasis added).
Credential Mapping security providers map “credentials used by WebLogic
Server to credentials used in a legacy or remote system, [and] tell WebLogic
Server how to connect to a given resource in that system.” Id. at 2-3
(emphasis added).
In view of the above disclosures, we agree with and sustain the
Examiner’s finding that Securing WebLogic teaches or suggests that
WebLogic includes a configuration that identifies a plurality of trust chain
processing modules. For example, the combination teaches or suggests a
WebLogic Server configuration capable of identifying customized
Authentication and Credential mapping security providers that have been
configured to verify users to particular legacy target systems when users
wish to log into those systems.

C. Whether WebLogic Server or Birk loads a configuration as part of
dynamically configuring a trust chain processing.

Appellants argue that the Examiner has erred in rejecting claim 3
because “the combination of Understanding WebLogic, Securing WebLogic,
Birk, Pearson, and Profile is insufficient to teach or suggest at least the
Appeal 2012-006606
Application 12/182,654

12
dynamically configuring feature of claim 3.” App. Br. 23. We are not
persuaded by Appellants’ arguments, and therefore sustain the Examiner’s
rejection of claim 3.7
Claim 3 depends from claim 1, and recites, inter alia, “loading the
configuration as a part of [sic] dynamically configuring the trust chain
processing.” Claims App’x. Claim 1 recites locating and selecting security
information attributes for a target system based on a configuration. The
Examiner finds that claim 3 does not define what is intended by the term
“dynamic,” that it’s plain and ordinary meaning is changing or not static,
and that the combination of Understanding WebLogic, Securing WebLogic,
Birk, Pearson, and Profile teaches dynamically processing security
information. Ans. 25. For example, the Examiner finds the security
information processes described in Understanding WebLogic are dynamic.
Id. at 13–14. Appellants contend the Examiner has not provided support for
this finding. App. Br. 22. We disagree.
With respect to claim 1, the Examiner finds Understanding
WebLogic’s disclosure of configuring Credential Mapping providers to
generate SAML assertions for particular target systems teaches or suggests
locating and selecting security information attributes for a target system
based on a configuration. Ans. 9, 21; see Understanding WebLogic 2-7. We
agree with the Examiner’s finding, and also find that it fully supports the
Examiner’s additional finding with respect to claim 3, namely, that
Understanding WebLogic’s security information processes are dynamic.
Ans. 14. Thus, for example, a Credential Mapping provider configured to

7 Appellants do not separately argue for the patentability of claims 4, 5, 12–
14, and 21–23; therefore, we sustain the Examiner’s rejection of these claims
as well.
Appeal 2012-006606
Application 12/182,654

13
generate SAML assertions for a target system would locate and select the
security information attributes needed to generate those SAML assertions in
the course of dynamically configuring trust train processing for that target
system (e.g., by configuring the trust trains needed to process login requests
to that target system).
The Examiner also finds that Birk’s disclosure of a JAAS (Java
Authentication and Authorization Service) login service teaches dynamically
processing security information since the JAAS login service maps security
information received at runtime to a principal and credential of a JAAS
subject, and since “a run time mapping of login information could not be
static.” Ans. 13–14, 25; see Birk ¶ 49. Appellants argue that Birk merely
discloses storing a JAAS Subject at runtime, not that the JAAS login process
is dynamically configured at runtime. App. Br. 22. We are not persuaded
by Appellants’ argument.
Birk discloses a process by which an end user 502 can login to an
application server 510 by way of a proxy server 504. Birk ¶ 48. The end
user sends identity information (e.g., a user id and password) to the proxy
server, which forwards it to a trust associated interceptor (TAI) 506 that acts
as a gateway between the end user and the application server. Id. The
application server includes a customizable JAAS login module 512 that can
create a JAAS Subject using a TAI.getSubject method 514, and map the end
user’s login information into a principal and credential of the JAAS Subject.
Id. ¶ 49. The use of JAAS Subjects and credentials allows the end user’s
“authorization and authentication information [to] be propagated
downstream to other servers.” Id.
Appeal 2012-006606
Application 12/182,654

14
Birk further discloses that the JAAS framework “allows pluggable
login modules to be used for performing authentication regardless of
underlying authentication technology.” Id. ¶ 57 (emphasis added).
Consequently, Birk discloses a “Web inbound login configuration 602,
inbound configuration 604 and outbound login configuration 606. Each
login configuration includes a number of login modules that are called in
sequence for an authentication login.” Id. ¶ 58, Fig. 6. In short, Birk
discloses an authentication system that dynamically processes login requests
via one or more configurations, where each configuration dynamically
identifies and calls one or more login modules to process the request.
For the reasons noted above, we agree with the Examiner that either
Understanding WebLogic or Birk teaches or suggests loading a
configuration as a part of dynamically configuring a trust chain processing,
and sustain the Examiner’s rejection of claim 3.

DECISION
For the above reasons, the Examiner’s rejection of claims 1–27 is
affirmed.
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) (2009).

AFFIRMED

msc