Ex Parte Pieczul et al

Patent Trial and Appeal Board

Apr 21, 2016

12966165 (P.T.A.B. Apr. 21, 2016)

UNITED STA TES p A TENT AND TRADEMARK OFFICE
APPLICATION NO. FILING DATE
12/966,165 12/13/2010
63400 7590 04/25/2016
IBM CORP, (DHJ)
c/o DAVID H. JUDSON
15950DALLAS PARKWAY
SUITE 225
DALLAS, TX 75248
FIRST NAMED INVENTOR
Olgierd Stanislaw Pieczul
UNITED STATES DEPARTMENT OF COMMERCE
United States Patent and Trademark Office
Address: COMMISSIONER FOR PATENTS
P.O. Box 1450
Alexandria, Virginia 22313-1450
www .uspto.gov
ATTORNEY DOCKET NO. CONFIRMATION NO.
AUS920100414US1 8234
EXAMINER
KU, SHIUH-HUEI P
ART UNIT PAPER NUMBER
2128
NOTIFICATION DATE DELIVERY MODE
04/25/2016 ELECTRONIC
Please find below and/or attached an Office communication concerning this application or proceeding.
The time period for reply, if any, is set in the attached communication.
Notice of the Office communication was sent electronically on above-indicated "Notification Date" to the
following e-mail address( es):
mail@davidjudson.com
PTOL-90A (Rev. 04/07)
UNITED STATES PATENT AND TRADEMARK OFFICE
BEFORE THE PATENT TRIAL AND APPEAL BOARD
Ex parte OLGIERD STANISLAW PIECZUL,
MARK ALEXANDER MCGLOIN, MARY ELLEN ZURKO,
DAVID SCOTT KERN, and BRENT ALLAN HEPBURN
Appeal2014-006566
Application 12/966, 165
Technology Center 2100
Before BRUCE R. WINSOR, KEVIN C. TROCK, and
AARON W. MOORE, Administrative Patent Judges.
MOORE, Administrative Patent Judge.
DECISION ON APPEAL
Appeal2014-006566
Application 12/966, 165
STATEMENT OF THE CASE
Appellants 1 appeal under 35 U.S.C. § 134(a) from a Final Rejection of
claims 1-24. We have jurisdiction under 35 U.S.C. § 6(b).
We affirm.
THE INVENTION
The application is directed to "[a] rich client [that] performs single
sign-on (SSO) to access a web- or cloud-based application." (Abstract.)
Claim 1, reproduced below, is illustrative:
1. A method of enabling a rich client to authenticate to and ac-
cess a web- or cloud-based application, comprising:
in response to an authentication request issued by the rich cli-
ent, obtaining an assertion on behalf of the rich client from an
identity provider;
in response to receiving the assertion, determining whether
the assertion can be verified and whether a user associated with
the assertion is permitted to access the application using the rich
client;
if the assertion can be verified and the user associated with
the assertion is permitted to access the application using the rich
client, exchanging the assertion for a token;
receiving a call together with the token; and
if the token is validated, providing data in response to the call.
1 Appellants identify International Business Machines Corporation as the
real party in interest. (See App. Br. 1.)
2
Appeal2014-006566
Application 12/966, 165
REFERENCES
The prior art relied upon by the Examiner in rejecting the claims on
appeal is:
Hinton et al.
Chow et al.
US 7,631,346 B2
US 8,225,385 B2
THE REJECTION
Dec. 8, 2009
July 17, 2012
Claims 1-24 stand rejected under 35 U.S.C. § 103(a) as being
unpatentable over Hinton and Chow. (See Final Act. 4--10.)
APPELLANTS' CONTENTIONS
Appellants argue that the rejections were improper for the following
reasons:
1. With respect to Group I claims 1, 3, 7-9, 11, 15-17, 19, and
23-24, (a) "Hinton does not disclose or suggest a 'rich client' within the
meaning of the claimed subject matter, namely, one that 'has an established
manner of authenticating to its own native server' but 'cannot authenticate
directly to the web- or cloud-based application"' (App. Br. 10); (b) "in
Hinton, the standard web client ... also does not issue an authentication
request or obtain an assertion (on behalf of the rich client) from an identity
provider" (id.); ( c) "Chow does not exchange any 'assertion for [a] token'"
(id. at 13-15); and (d) "the alleged motivation to combine the teachings ...
is not based on a rational underpinning" (id. at 15).
2. With respect to Group II claims 2, 10, and 18, the "references
also do not require any type of 'application server' of the type recited,
namely, one 'associated with the rich client"' and "the Examiner has failed
3
Appeal2014-006566
Application 12/966, 165
to provide any reasons for combining the teachings with respect to the
subject matter of these claims." (App. Br. 17.)
3. With respect to Group III claims 4--5, 12-13, and 20-21,
"neither Hinton nor Chow discloses making a determination regarding a
'rich client'" and "the Examiner has failed to provide any reasons for
combining the teachings with respect to the subject matter of these claims."
(App. Br. 17-18.)
4. With respect to Group IV claims 6, 14, and 22, "[n]either
Hinton nor Chow refers to REST." (App. Br. 18-19.)
ANALYSIS
Claim Construction
Appellants argue that "a 'rich client' is defined ... as a client that is
not 'browser-based' and that 'has an established manner of authenticating to
its own native server, but it is assumed that there is no authentication
mechanism by which the rich client can authenticate directly to the web- or
cloud-based application." (App. Br. 6.2) We do not agree.
With respect to "browser-based," the Specification explains that "[a]
'rich' client typically is not browser-based" (Spec. 1: 12, emphasis added),
confirming that a rich client may, at least atypically, be browser-based. We
find that this language was not "taken out of context" (Reply 2) and that
even if it does "refer[] to how the 'rich client' is supported but ... says
2 While the Specification states on page 1 that "a 'rich' client is a client ...
that supports its own interface (as opposed to merely exporting the web
interface from the web application itself)," Appellants do not incorporate
that concept into their construction and we therefore do not consider it.
4
Appeal2014-006566
Application 12/966, 165
nothing about what it is" (id.) that would not justify the "not browser-based"
construction Appellants are seeking.
We also find the passage "it is assumed that there is no authentication
mechanism by which the rich client can authenticate directly to the web- or
cloud-based application" insufficient to define all "rich clients." This
language does not provide the type of plain, unambiguous disclaimer
required by our reviewing Court. See In re Scroggie, 442 F. App'x 547, 550
(Fed. Cir. 2011) ("To act as a lexicographer, an applicant must define claim
terms with "reasonable clarity, deliberateness, and precision." (quoting In re
Paulsen, 30 F.3d 1475, 1480 (Fed. Cir. 1994)).
Group I (Claims 1, 3, 7-9, 15-17, 19, and 23-24)
For the Group I claims, Appellants first argue that "Hinton does not
disclose or suggest a 'rich client"' as Appellants construe that term. (See
App. Br. 10.) This argument is unpersuasive because, as explained above,
we do not adopt Appellants' claim construction. We accordingly conclude
that Appellants have not shown error in the Examiner's finding that Hinton's
"browser application 216" is a "rich client" as that term is used in this
application. 3
Appellants next argue that the Hinton client "does not issue an
authentication request or obtain an assertion (on behalf of the rich client)
from an identity provider" because "the web client simply makes a request
to the service provider for a protected resource (not an authentication
request), after which the service provider attempts to pull additional user
3 We do agree with Appellants that Hinton's "various other client
applications" are not relevant because they are neither identified nor alleged
to be seeking authentication. (See App. Br. 12.)
5
Appeal2014-006566
Application 12/966, 165
attribute information from the identity provider using the 'linked-user-
account creation' operation described above." (App. Br. 10.) We are not
persuaded. Claim 1 recites "in response to an authentication request issued
by the rich client, obtaining an assertion on behalf of the rich client from an
identity provider." In Hinton, the "assertion" is obtained from the identity
provider "in response to" a user request (made via the client) for
authentication to access a protected resource. (See Hinton, Fig. 1 lA, Item
1104 ("USER REQUESTS PROTECTED RESOURCE FOR WHICH SP
REQUIRES SESSION (AUTHENTICATION)").)
Turning to Chow, Appellants argue that "Chow does not exchange
any 'assertion for [a] token' - rather, in that system a client makes an
explicit authentication request that seeks multiple tokens" and "the
authentication request is not an 'assertion,' which the disclosure here defines
as 'indirect evidence of some action."' (App. Br. 13.) Appellants further
argue that "in Chow there is just a single authentication request and a single
response (the multiple security tokens); there is no 'exchanging the assertion
for a token' (a first operation) followed by receipt of a separate and distinct
'call together with the token [obtained by the exchange]' (a second
operation) and then a separate token validation (a third operation)." (Id.)
We agree with the Examiner. In the combination, Hinton includes the
authentication request by the client, the assertion from the identity provider,
and determining by the server whether the assertion can be verified and
whether the user may be permitted access. Chow teaches that a client
making an authentication request (such as the Hinton client passing the
assertion to the server) may be provided with a token (i.e., a token is
"exchanged" for the assertion), which is then used to obtain secure data.
6
Appeal2014-006566
Application 12/966, 165
(See, e.g., Chow, Fig. 4 & 12:47-14:50.) Because the claimed step of
providing the assertion is the same as, or at least analogous to, Chow's step
of requesting authentication, we agree that an artisan would have found it
obvious to respond with a token for subsequent use in accessing data. 4
Finally, Appellants argue that there would have been no motivation to
combine because Hinton "already has a Security Token Service 346 (as
shown in FIG. 4)." (App. Br. 15.) We find this argument unpersuasive
because Appellants fail to explain why the "Security Token Service 346"
would cause one skilled in art to not make the combination. If the Security
Token Service does not provide the same functionality as Chow's tokens,
then it would have little relevance. 5
For these reasons, we sustain the rejections of Group I claims 1, 3, 7-
9, 15-17, 19, and 23-24.
Group II (Claims 2, 10, and 18) and
Group III (Claims 4-5, 12-13, and 20--21)
For the Group II and III claims, Appellants make additional
arguments regarding "rich client." (See App. Br. 16-17.) We find these
unconvincing for the reasons articulated above. Additionally, Appellants
argue that the Examiner "failed to provide any reasons for combining the
teachings with respect to the subject matter of these claims." (App. Br. 17,
18.) This contention is unavailing because the additional features in these
4 The Specification also acknowledges this use of tokens as prior art. (See
Spec. 14--16 (describing the "known" single sign-on operation of Fig. 3).)
5 On the other hand, if the Security Token Service were to provide the same
functionality as Chow, so as to make the combination unnecessary, it
presumably would make Hinton an anticipatory reference.
7
Appeal2014-006566
Application 12/966, 165
dependent claims are found in Hinton, which is already part of the
combination, meaning that no additional reason to combine is required.
For these reasons, we sustain the rejections of Group II and III claims
2, 4--5, 10, 12-13, 18, and 20-21.
Group IV (Claims 6, 14, and 22)
These claims recite that "the call is a REST call." Appellants argue
that Chow only teaches SOAP, that "SOAP and REST are distinct from one
another as the specification clearly teaches," and that "no primafacie case is
established." (App. Br. 18-19.) Appellants and the Examiner both quote
the following passage from the Specification (at 23:7-10): "REST
(Representational State Transfer) is a lightweight XML-based protocol
commonly used for exchanging structured data and type information on the
Web. SOAP over HTTP may be used in lieu of REST for exchanging XML-
based messages over the network." (See App. Br. 18-19; Ans. 6.) In the
absence of evidence to the contrary, the selection of one "commonly used"
web protocol over another is routine engineering, not patentable invention.
See KSR Int'! Co. v. Teleflex Inc., 550 U.S. 398, 416 (2007) ("If a person of
ordinary skill can implement a predictable variation, § 103 likely bars its
patentability."). We accordingly sustain the rejection of claims 6, 14, and
22.
8
Appeal2014-006566
Application 12/966, 165
DECISION
The rejections of claims 1-24 are 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)(l)(iv)(2012).
AFFIRMED
9