Ex Parte Fork et al

Patent Trial and Appeal Board

Apr 26, 2016

13072884 (P.T.A.B. Apr. 26, 2016)

UNITED STA TES p A TENT AND TRADEMARK OFFICE
APPLICATION NO. FILING DATE
13/072,884 03/28/2011
63400 7590 04/28/2016
IBM CORP, (DHJ)
c/o DAVID H. JUDSON
15950DALLAS PARKWAY
SUITE 225
DALLAS, TX 75248
FIRST NAMED INVENTOR
Michael John Fork
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.
A US920 l 10065US 1 6950
EXAMINER
SAVENKOV, VADIM
ART UNIT PAPER NUMBER
2431
NOTIFICATION DATE DELIVERY MODE
04/28/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 MICHAEL JOHN FORK and VINCENT EDMUND PRICE
Appeal2014-008336
Application 13/072,884
Technology Center 2400
Before MAHSHID D. SAADAT, MATTHEW J. McNEILL, and SCOTT E.
BAIN, Administrative Patent Judges.
BAIN, Administrative Patent Judge.
DECISION ON APPEAL
Appellants 1 appeal under 35 U.S.C. § 134(a) from the Examiner's
final rejection of claims 1-21 and 26-28, which constitute all the claims
pending in the application. Claims 22-25 have been canceled. We have
jurisdiction under 35 U.S.C. § 6(b).
We reverse.
1 Appellants identify International Business Machines Corporation ("IBM")
as the real party in interest. App. Br. 1.
Appeal2014-008336
Application 13/072,884
STATEMENT OF THE CASE
Introduction
Appellants' invention relates to a token-based authentication system
in a computer network. See Spec. 1. Claims 1, 10, and 16 are independent.
Claim 1 is illustrative of the invention and reads as follows:
1. A method, operating within a service, of enabling access
by the service to an application executing in a computing entity,
compnsmg:
establishing, by the service, a trust relationship between
the service and an identity provider by which the service
becomes a trusted service;
requesting, by the trusted service, a token from the identity
provider;
rece1vmg, by the trusted service, the token from the
identity provider, the token having been generated by the identity
provider without requiring presentation by the trusted service of
user credential information;
the trusted service, on behalf of a user, using the token and
a user credential to establish the trusted service as an
authenticated user to the application; and
upon establishing the trusted service as an authenticated
user, the trusted service accessing the application.
App. Br. 22 (emphasis added).
The Rejections
Claims 1, 5---6, 8-10, 14--16, 20, 21, 26, and 27 stand rejected under
35 U.S.C. § 103(a) as unpatentable over Swift et al. (US 2006/0225132 Al;
2
Appeal2014-008336
Application 13/072,884
Oct. 5, 2006) and Dillaway et al. (US 7,797,544 B2; Sept. 14, 2010). Final
Act. 9--24.
Claims 2, 7, 11, and 17 stand rejected under 35 U.S.C. § 103(a) as
unpatentable over Swift, Dillaway, and Kariv et al. (US 2011/0307947 Al;
Dec. 15, 2011). Final Act. 24--27.
Claims 3, 4, 12, 13, 18, and 19 stand rejected under 35 U.S.C.
§ 103(a) as unpatentable over Swift, Dillaway, Kariv, and Mao et al. (US
2006/0294192 Al; Dec. 28, 2006). Final Act. 27-29.
Claims 9 stands rejected under 35 U.S.C. § 103(a) as unpatentable
over Swift, Dillaway, and Hardjono ("OAuth 2.0 support for the Kerberos
V5 Authentication Protocol;" June 9, 2010). Final Act. 29--30.
Claim 28 stands rejected under Swift, Dillaway, and Kou (US
6,363,365 B 1; Mar. 26, 2002). Final Act. 30-31.
ANALYSIS
We have reviewed the Examiner's rejections in light of the arguments
raised in the Briefs, on the record before us. For the reasons set forth below,
we do not sustain the Examiner's rejections.
Claim 1
Appellants assert that the Examiner's proposed combination of
references is improper, and the rejection cannot be sustained, because the
combination changes the basic principle of operation in Swift, rendering it
ineffective for its intended purpose of system security. App. Br. 12-14. We
agree.
Swift discloses a security protocol in which the user registers proxy
information with a "trusted security server." Final Act. 9 (citing Swift
3
Appeal2014-008336
Application 13/072,884
ilil0028, 0052). When a proxy client desires to access a target service on
behalf of a user, it sends a proxy request to the trusted security server, which
verifies the proxy authorization information previously entered by the user
and, if a match is found, returns a token (data structure) for authenticating
the proxy client. Id. at 9--11. Dillaway, by contrast, discloses a protocol in
which a first entity provides an attestation of its trustworthiness to a second
entity, which relies upon the attestation even if neither entity had any prior
information regarding the other. Id. at 12 (citing Dillaway Abstract); App.
Br. 13.
As Appellant asserts, combining the message attestation protocol of
Dillaway with the trusted security server of Swift would appear to permit the
proxy client of Swift to access its target service (application) without any
interaction by the user, administrator, or trusted server itself. See App. Br.
13. This would contradict Swift's basic security principle of the trusted
server acting as gatekeeper based on input from the administrator or user.
See id.; see also In re Gordon, 733 F.2d 900, 902 (Fed. Cir. 1984) (one of
ordinary skill in the art would not be motivated to modify a reference in a
manner rendering it "inoperable for its intended purpose").
The Examiner responds that "there is ... a disagreement regarding
how much security is adequate for" the Swift-Dillaway combination, Ans. 6,
and "it is generally accepted that additional security features [i.e., adding the
features of two computer security references] provide additional security."
Id. The Examiner, however, does not explain the asserted factual
"disagreement" with Appellant, nor provide support for the assumption that
combining different security protocols necessarily results in more security.
4
Appeal2014-008336
Application 13/072,884
See KSR Int? Co. v. T'elej7ex Inc., 550 U.S. 398, 418 (2007) (Examiner must
provide "articulated reasoning with some rational underpinning to support"
obviousness rejection, not "mere conclusory statements").
The Examiner also cites "greater efficiency from automation" in Swift
as a reason for the combination, and asserts that any increased security risk
would be balanced by gains in efficiency. Ans. 6. The fundamental premise
of Swift (and Dillaway), however, is security. See, e.g., Swift i-f 0003. Thus,
we are persuaded by Appellant's argument that "a skilled person trying to
modify a security system does not [look] for ways to make [the] security
model less secure (even if more automated)." Reply Br. 6.
For the foregoing reasons, Appellant's contentions have persuaded us
that the Examiner erred in finding one of ordinary skill in the art would
combine Swift and Dillaway to realize the invention recited in claim 1. We,
therefore, need not reach Appellants' remaining arguments with respect to
claim 1. We do not sustain the Examiner's rejection of claim 1.
Remaining Claims
Independent claims 10 and 16 include essentially the same limitations
as claim 1, including establishing a trust relationship "by the server," and
stand rejected on the same basis and under the same references as claim 1.
We, therefore, do not sustain the Examiner's rejection of claims 10 and 16,
for the reasons described above.
The remaining claims 2-9, 11-15, 17-21, and 26-28 are dependent
and include the limitations of their respective base claims 1, 10, or 16.
Therefore, we also do not sustain the Examiner's rejections of these claims.
5
Appeal2014-008336
Application 13/072,884
DECISION
The Examiner's rejections of claims 1-21and26-28 are reversed.
REVERSED
6