Ex Parte Nadalin et al

Patent Trial and Appeal Board

Feb 24, 2015

11165483 (P.T.A.B. Feb. 24, 2015)

UNITED STATES PATENT AND TRADEMARK OFFICE
________________

BEFORE THE PATENT TRIAL AND APPEAL BOARD
________________

Ex parte ANTHONY J. NADALIN, BRUCE A. RICH,
and XIAOYAN Y. ZHANG
1

________________

Appeal 2012-008367
Application 11/165,483
Technology Center 2400
________________

Before CARL W. WHITEHEAD JR., JASON V. MORGAN, and
CHRISTA P. ZADO, Administrative Patent Judges.

MORGAN, Administrative Patent Judge.

DECISION ON APPEAL
Introduction
This is an appeal under 35 U.S.C. § 134(a) from the Examiner’s final
rejection of claims 1–39. We have jurisdiction under 35 U.S.C. § 6(b).
We AFFIRM.
Invention
Appellants invented a method and system for supporting the
establishment of a secure communication session by: (1) sending a
certificate request command from a server to a client and (2) sending a

1
International Business Machines Corporation is the Real Party in Interest.
App. Br. 1.
Appeal 2012-008367
Application 11/165,483

2

certificate command, accompanied by a public key certificate and an
attribute certificate, from the client to the server in response. See Abstract.
The attribute certificate is digitally signed by a private key bound to the
public key certificate and the attribute certificate contains credential
information. See id.
Exemplary Claims
Claims 1, 2, and 34, reproduced below with key limitations
emphasized, are representative:
1. A method for supporting establishment of a secure
communication session within a data processing system, the
method comprising:
providing an indication from a server to a client that the
server supports transfer of credential information during
establishment of the secure communication session, wherein the
indication is provided in a message that has been augmented to
include the indication;
sending a certificate request command from the server to
the client;
receiving a certificate command at the server from the
client in response to the certificate request command, wherein
the certificate command is accompanied by a public key
certificate and an attribute certificate that is tied to the public
key certificate by being digitally signed by a private key that is
bound to the public key certificate, and wherein the attribute
certificate contains credential information for an authentication
operation or an authorization operation that is performed after
establishment of the secure communication session; and
completing establishment of the secure communication
session in response to successfully verifying the public key
certificate, wherein as a consequence of being included in the
attribute certificate that is tied to the public key certificate, the
credential information need not be requested by the server after
establishment of the secure communication session.
Appeal 2012-008367
Application 11/165,483

3

2. The method of claim 1 wherein the secure
communication session is an SSL (Secure Sockets Layer)
session.
34. The method as described in claim 1 wherein the
certificate command also is accompanied by a second attribute
certificate that is digitally signed by the private key.
Rejections
The Examiner rejects claims 1–39 under 35 U.S.C. § 112, first
paragraph, as failing to comply with the written description requirement.
Ans. 4–5.
The Examiner rejects claims 1, 7–9, 11, 12, 18–20, 22, 23, 29–31, and
33–39 under 35 U.S.C. § 103(a) as being unpatentable over Stephen Farrell,
TLS extensions for AttributeCertificate based authorization, INTERNET-
DRAFT, Transport Layer Security Working Group, Internet Engineering
Task Force, available at http://tools.ietf.org/id/draft-ietf-tls-attr-cert-01.txt
(Aug. 20, 1998) (“Farrell”), Stephen Farrell and Russell Housley, An
Internet Attribute Certificate Profile for Authorization, RFC 3281, Network
Working Group, Internet Engineering Task Force, available at http://www.
ietf.org/rfc/rfc3281.txt (Apr. 2002) (“RFC 3281”), and Simon Blake-Wilson
et al., Transport Layer Security (TLS) Extensions, RFC 3546, Network
Working Group, Internet Engineering Task Force, available at http://www.
ietf.org/rfc/rfc3546.txt (June 2003) (“RFC 3546”). Ans. 6–12.
The Examiner rejects claims 2–6, 10, 13–17, 21, 24–28, and 32 under
35 U.S.C. § 103(a) as being unpatentable over Farrell, RFC 3281, RFC
3546, and Appellants’ Admitted Prior Art (“AAPA”). Ans. 12–14.
Appeal 2012-008367
Application 11/165,483

4

ISSUES
1. Did the Examiner err in finding the Specification fails to provide a
sufficient written description for “providing an indication from a server to a
client . . . in a message that has been augmented to include the indication,”
as recited in claim 1?
2. Did the Examiner err in finding the combination of Farrell, RFC
3281, and RFC 3546 teaches or suggests: (1) “providing an indication from
a server to a client that the server supports transfer of credential information
during establishment of the secure communication session, wherein the
indication is provided in a message that has been augmented to include the
indication” and (2) “an attribute certificate that is tied to the public key
certificate by being digitally signed by a private key that is bound to the
public key certificate,” as recited in claim 1?
3. Did the Examiner err in finding the combination of Farrell, RFC
3281, RFC 3546, and AAPA teaches or suggests “wherein the secure
communication session is an SSL (Secure Sockets Layer) session,” as
recited in claim 2?
4. Did the Examiner err in finding the combination of Farrell, RFC
3281, and RFC 3546 teaches or suggests “wherein the certificate command
also is accompanied by a second attribute certificate that is digitally signed
by the private key,” as recited in claim 34?
ANALYSIS
§ 112, first paragraph—Claims 1–39
In rejecting claim 1 under 35 U.S.C. § 112, first paragraph, as lacking
sufficient written description in the Specification, the Examiner concludes
that providing an indication from a server to a client in a message that has
Appeal 2012-008367
Application 11/165,483

5

been augmented to include the indication requires adding something to a
message or supplementing the message. Ans. 5.
Appellants contend the Examiner erred because the Specification
discloses the inclusion of novel data value 516 within “hello” command 504.
App. Br. 10–11 (citing Spec. 25, l. 20–26, l. 5, Fig. 5). Appellants argue
“[t]he claim phrase does not require the ‘indication’ be added in a
completely new data field, i.e., one that did not exist in the command in the
first instances; rather, the claim phrase merely recites that the message itself
includes the indication (where it did not do so before).” App. Br. 11–12; see
also Reply Br. 2 (“simply overwriting an existing data field with a ‘novel
data value’ suffices to meet the element”).
Although we agree with Appellants that augmenting a message to
include an indication does not require adding a new data field, Appellants
fail to identify where the Specification provides sufficient support for the
disputed recitation. As the Examiner correctly concludes, “the term
‘augmented’ as used in the claim . . . require[s] adding something to or
supplementing what is already existent or present.” Ans. 15 (emphasis
added).
In particular, the claim does not merely relate to providing an
indication in a message (e.g., by using an existing field in a manner that
provides the claimed indication). If it did, then the claim could simply recite
“providing an indication from a server to a client . . . wherein the indication
is provided in a message.” However, the claim further recites that the
“message . . . has been augmented to include the indication” (emphasis
added). That is, the claim requires that a message without the indication
Appeal 2012-008367
Application 11/165,483

6

existed and was changed (i.e., augmented) to include the indication.
Otherwise, the “has been augmented . . .” limitation would be superfluous.
Appellants do not direct us to any disclosure in the Specification of an
existing message changed or augmented to include the claimed indication.
Therefore, we agree with the Examiner: the Specification fails to provide a
sufficient written description for “providing an indication from a server to a
client . . . in a message that has been augmented to include the indication,”
as recited in claim 1. Ans. 5.
Accordingly, we sustain the Examiner’s 35 U.S.C. § 112, first
paragraph, rejection of claim 1, and claims 2–39, which Appellants do not
argue separately with respect to this issue. App. Br. 10–13.
§ 103(a)—Claims 1, 7–9, 11, 12, 18–20, 22, 23, 29–31, and 33
In rejecting claim 1 under 35 U.S.C. § 103(a), the Examiner finds
Farrell’s ACRequest (AttributeCertificates Request) command teaches or
suggests providing an indication of support of transfer of credential
information during establishment of a secure session. Ans. 6, 24 (citing
Farrell §§ 5.3, 5.3.1). The Examiner further finds RFC 3546’s use of
Extension fields that indicate what extensions a server supports teaches or
suggests providing this indication by augmenting a message, such as a client
hello or a server hello message, to provide the indication . Ans. 8, 24
(citing, e.g., RFC 3546 §§ 2.1, 2.2).
Appellants contend the Examiner erred because “[t]he extensions
described in RFC 3546 merely provide a vehicle by which the server or
client ‘may request extended functionality,’ but the reference does not also
teach that such ‘functionality’ is . . . support for the ‘transfer of credential
information during establishment of the secure communication session.”
Appeal 2012-008367
Application 11/165,483

7

App. Br. 20. Appellants’ arguments are unpersuasive, however, because the
Examiner relies on Farrell, not RFC 3546, to teach or suggest the
functionality of transferring credential information during establishment of a
secure communication session. Ans. 6, 24 (citing Farrell §§ 5.3, 5.3.1).
Appellants do not persuasively show error in the Examiner’s reliance on
Farrell to teach or suggest this functionality. Accordingly, we agree the
Examiner’s combination of Farrell, RFC 3281, and RFC 3546 teaches or
suggests “providing an indication from a server to a client that the server
supports transfer of credential information during establishment of the
secure communication session, wherein the indication is provided in a
message that has been augmented to include the indication,” as recited in
claim 1. Ans. 6, 8.
The Examiner further finds Farrell’s ACInfo data structure and
Certificate commands, in combination with RFC 3281’s use of a private key
to create a digital signature for an “acinfo” data structure, teaches or
suggests “an attribute certificate that is tied to the public key certificate by
being digitally signed by a private key that is bound to the public key
certificate,” as recited in claim 1. Ans. 7–8 (citing, e.g., Farrell § 5.3; RFC
3281 §§ 4.1, 4.2.2, 4.2.4, 4.2.7, and 5); see also Ans. 21 (citing, e.g., RFC
3281 § 1).
Appellants acknowledge “RFC 3281 describes that an attribute
certificate may be signed” and that “Farrell states that a ‘set of public key
certificates may also be ‘pushed’ with an acinfo [sic].” App. Br. 17.
However, Appellants contend the Examiner erred because RFC 3281
Section 1 merely refers “to what data is included within the attribute
certificate, and not whether the attribute certificate itself is digitally signed
Appeal 2012-008367
Application 11/165,483

8

(and/or by what).” Id. at 18. Appellants’ argument is not persuasive
because the Examiner correctly finds RFC 3281’s signatureValue field—
part of an AttributeCertificate—teaches or suggests signing an attribute
certificate. Ans. 7 (citing RFC 3281 § 4.1). In particular, RFC 3281 defines
an AttributeCertificate as:
AttributeCertificate ::= SEQUENCE {
acinfo AttributeCertificateInfo
signatureAlgorithm AlgorithmIdentifier
signatureValue BIT STRING
}
where AttributeCertificateInfo is further defined in detail. RFC 3281 § 4.1.
An artisan of ordinary skill would have recognized the signatureValue
field represents a digital signature of the acinfo field, and further—in
effect—of the AttributeCertificate itself. Thus, we agree with the Examiner,
RFC 3281 teaches or suggests digitally signing Farrell’s ACInfo structure.
Ans. 7–8.
Furthermore, we agree with the Examiner, RFC 3281 teaches or
suggests a public key certificate referenced by (or accompanying) an
attribute certificate that is signed by the private key corresponding to the
private key corresponding to the public key certificate. See Ans. 21 (citing
RFC 3281). Specifically, RFC 3281 teaches that “[o]ne way in which the
linkage between the request or identity and the AC can be achieved is the
inclusion of a reference to a PKC [(public key certificate)] within the AC
and the use of the private key corresponding to the PKC for authentication
within the access request.” RFC 3281 § 1. Thus, contrary to Appellants’
arguments (see App. Br. 18; Reply Br. 5), RFC 3281 teaches or suggests not
just digitally signing an attribute certificate, but digitally signing the attribute
certificate with a private key tied to a public key referenced by or
Appeal 2012-008367
Application 11/165,483

9

accompanying the attribute certificate. Therefore, we agree with the
Examiner the combination of Farrell, RFC 3281, and RFC 3546 teaches or
suggests “an attribute certificate that is tied to the public key certificate by
being digitally signed by a private key that is bound to the public key
certificate,” as recited in claim 1. Ans. 7–8.
Appellants further contend the Examiner erred because claim 1 recites
“‘providing an indication . . .’ after which a certificate request command is
sent from the server to the client.” App. Br. 16. Specifically, Appellants
argue “the ‘indication’ necessarily precedes the ‘certificate request’ because
the next step in each claim makes an explicit reference to the sending or
receiving of the ‘certificate request command.’” Id. at 16–17. However, we
agree with the Examiner that the claim recitations do not specify a particular
order for performing the steps identified by Appellants. Ans. 18. Method
steps are not ordinarily construed to require an order unless they expressly or
implicitly require performance in that order. Altiris, Inc. v. Symantec Corp.,
318 F.3d 1363, 1369 (Fed. Cir. 2003) (citing Interactive Gift Express, Inc. v.
Compuserve Inc., 256 F.3d 1323, 1342–43 (Fed. Cir. 2001)).
Appellants contend “the ‘indication’ must precede the certificate
request if the recited ‘establishment of a secure communications session’ is
to succeed . . . .” Reply Br. 5. However, Appellants do not persuasively
show how the order of these two communications from the server to the
client (an indication provided in a message and a certificate request
command) affects the success or failure of the secure communications
session establishment. Thus, Appellants’ arguments are not commensurate
with the scope of the claimed invention, and therefore not persuasive of error
in the Examiner’s rejection.
Appeal 2012-008367
Application 11/165,483

10

Accordingly, we sustain the Examiner’s 35 U.S.C. § 103(a) rejection
of claim 1, and claims 7–9, 11, 12, 18–20, 22, 23, 29–31, and 33, which
Appellants argue are patentable for similar reasons with respect to this issue.
App. Br. 16–21.
§ 103(a)—Claims 2–6, 10, 13–17, 21, 24–28, and 32
In rejecting claim 2 under 35 U.S.C. § 103(a), the Examiner finds
Appellants’ admission that SSL (secure socket layer) is the predecessor of
TLS (transport layer security) teaches or suggests wherein the secure
communication session is an SSL session. Ans. 13 (citing Spec. 1–2).
Appellants contend the Examiner erred because “even if TLS is a successor
to SSL, this does not imply that the teachings in Farrell are necessarily
applicable to SSL.” App. Br. 22. However, we agree with the Examiner the
admitted predecessor/successor relationship between SSL and TLS would
have taught or suggested to an artisan of ordinary skill that modifications to
TLS (e.g., modifications taught or suggested by Farrell) could also be
applied to its predecessor, SSL. Ans. 13. Appellants’ conclusory remarks
are insufficient to show error in the Examiner’s reliance on Appellants’
admission. Therefore, we agree with the Examiner the combination of
Farrell, RFC 3281, RFC 3546, and AAPA teaches or suggests “wherein the
secure communication session is an SSL (Secure Sockets Layer) session,” as
recited in claim 2. Id.
Accordingly, we sustain the Examiner’s 35 U.S.C. § 103(a) rejection
of claim 2, and claims 3, 4, 10, 13–15, 21, 24–26, and 32, which Appellants
argue are patentable for similar reasons with respect to this issue. App. Br.
23.
Appeal 2012-008367
Application 11/165,483

11

Similarly, Appellants contend the Examiner erred in rejecting claims
5, 6, 16, 17, 27, and 28 under 35 U.S.C. § 103(a) because Farrell merely
“discusses attribute certificates within the context of TLS” (rather than SSL).
App. Br. 23 (emphasis added); see also Reply Br. 10. However, as
discussed above, Appellants’ admission that SSL is the predecessor of TLS
is sufficient to show that it would have been obvious to an artisan of
ordinary skill to apply the teachings and suggestions of the prior art, as they
relate to modifying TLS, to modify SSL. Therefore, we also sustain the
Examiner’s 35 U.S.C. § 103(a) rejection of claims 5, 6, 16, 17, 27, and 28.
§ 103(a)—Claims 34–39
In rejecting claim 34 under 35 U.S.C. § 103(a), the Examiner finds
Farrell’s target extension, which defines Targets as a sequence of Target
values, each of which comprise a targetCertificate, teaches or suggests
wherein the certificate command also is accompanied by a second attribute
certificate that is digitally signed by the private key. Ans. 9 (citing RFC
3281 § 4.3.2). Appellants contend the Examiner erred because the target
extension “only concerns targeting certificates, and not the associating of
multiple attribute certificates with the certificate command, or the digitally
signing of the certificates with the same private key.” App. Br. 25
(emphases added).
In response, the Examiner finds Farrell’s disclosure of
AttributeCertificates, in plural, along with Farrell’s disclosure of an
attributes certificate carrier structure “which allows for requests for plural
ACs and for pushing plural ACs” also teaches or suggests a second attribute
certificate digitally signed and accompanying the certificate command in the
manner recited. Ans. 30 (citing, e.g., Farrell §§ 1, 2).
Appeal 2012-008367
Application 11/165,483

12

Appellants do not rebut the Examiner’s findings with respect to
Farrell, but merely submit the Examiner improperly cites new portions of
Farrell in a manner not found in the Final Rejection. Reply Br. 12.
However, allegations that an Examiner’s answer contains undesignated new
grounds of rejection are resolved by petition. MPEP § 1207.03(IV) (8th ed.,
July 2010). In light of the Examiner’s unrebutted findings, we agree with
the Examiner the combination of Farrell, RFC 3281, and RFC 3546 teaches
or suggests “wherein the certificate command also is accompanied by a
second attribute certificate that is digitally signed by the private key,” as
recited in claim 34. Ans. 29–30.
Accordingly, we sustain the Examiner’s 35 U.S.C. § 103(a) rejection
of claim 34, and claims 35–39, which Appellants do not argue separately
with respect to this issue. App. Br. 24–26.
DECISION
We affirm the Examiner’s decision rejecting claims 1–39.
No time period for taking any subsequent action in connection with
this appeal may be extended under 37 C.F.R. § 1.136(a). See 37 C.F.R.
§ 41.50(f).
AFFIRMED

tj