Ex Parte Nadalin et alDownload PDFPatent Trial and Appeal BoardFeb 24, 201511165483 (P.T.A.B. Feb. 24, 2015) Copy Citation 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 Copy with citationCopy as parenthetical citation