Ex Parte Yerra et al

Patent Trial and Appeal Board

Jun 28, 2016

13631646 (P.T.A.B. Jun. 28, 2016)

UNITED STA TES p A TENT AND TRADEMARK OFFICE
APPLICATION NO. FILING DATE
13/631,646 09/28/2012
127660 7590 06/30/2016
PARKER IBRAHIM & BERG LLC
One Financial Center
Boston, MA 02111
FIRST NAMED INVENTOR
Srinivas Yerra
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.
0270076.U 3960
EXAMINER
TENG, LOUIS C
ART UNIT PAPER NUMBER
2492
NOTIFICATION DATE DELIVERY MODE
06/30/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):
patent@piblaw.com
PTOL-90A (Rev. 04/07)
UNITED STATES PATENT AND TRADEMARK OFFICE
BEFORE THE PATENT TRIAL AND APPEAL BOARD
Ex parte SRINIV AS YERRA, KRISTS KRILOVS,
DHARMENDRA MOHAN, RON FREDERICK, and TAMMY GREEN
Appeal2015-002007
Application 13/631,6461
Technology Center 2400
Before JOSEPH L. DIXON, JOHNNY A. KUMAR, and
JOHN D. HAMANN, Administrative Patent Judges.
HAMANN, Administrative Patent Judge.
DECISION ON APPEAL
Appellants file this appeal under 35 U.S.C. § 134(a) from the
Examiner's Final Rejection of claims 1-20. We have jurisdiction under
35 U.S.C. § 6(b).
We affirm-in-part.
THE CLAIMED INVENTION
Appellants' claimed invention relates to "establishing SSL sessions in
a client-proxy server network configuration, ... [including] exchanging
1 According to Appellants, the real party in interest is Blue Coat Systems,
Inc. App. Br. 4.
Appeal2015-002007
Application 13/631,646
digital certificates so as to allow authentication of one or more of the client,
proxy and server." Spec. i-f 1. Claim 1 is illustrative of the subject matter of
the appeal and is reproduced below.
1. A method for providing a client certificate from a proxy
to a server, the proxy communicatively coupled between a
client and the server, the method comprising:
configuring at the proxy a collection of one or more
client certificates and one or more client private keys, each
client certificate corresponding to a client private key;
defining a policy at the proxy which selects one of the
client certificates based on information associated with an
identity of the client;
in response to a request from the server to the proxy to
authenticate the identity of the client, selecting one of the client
certificates based on the defined policy; and
transmitting the selected client certificate from the proxy
to the server.
REJECTIONS ON APPEAL
(1) The Examiner rejected claims 6 and 9 under 35 U.S.C. § 102(b)
as being anticipated by Kersey et al. (US 7,506,368 Bl; iss. Mar. 17, 2009)
(hereinafter "Kersey").
(2) The Examiner rejected claims 1-3 under 35 U.S.C. § 103(a) as
being unpatentable over the combination of Kersey and Ovsiannikov
(US 2011/0264905 Al; pub. Oct. 27, 2011).
(3) The Examiner rejected claim 7 under 35 U.S.C. § 103(a) as
being unpatentable over the combination of Kersey and Brown et al.
(US 2013/0145151 Al; pub. June 6, 2013) (hereinafter "Brown").
(4) The Examiner rejected claim 8 under 35 U.S.C. § 103(a) as
being unpatentable over the combination of Kersey and Wason et al.
(US 2010/0228968 Al; pub. Sept. 9, 2010) (hereinafter "Wason").
2
Appeal2015-002007
Application 13/631,646
(5) The Examiner rejected claim 10 under 35 U.S.C. § 103(a) as
being unpatentable over the combination of Peles (US 7,769,994 B2; iss.
Aug. 3, 2010) and Tuecke et al., Internet X509 Public Key Infrastructure
(PK!) Proxy Certificate Profile, The Internet Society RFC 3820 (June 2004)
(hereinafter "Tuecke").
(6) The Examiner rejected claims 13 and 15 under 35 U.S.C.
§ 103(a) as being unpatentable over the combination of Kersey and Tuecke.
(7) The Examiner rejected claim 16 under 35 U.S.C. § 103(a) as
being unpatentable over the combination of Peles and Brown.
(8) The Examiner rejected claim 17 under 35 U.S.C. § 103(a) as
being unpatentable over the combination of Peles and Cooper et al., Internet
X509 Public Key Infrastructure Certificate and Certificate Revocation List
(CRL) Profile, The Internet Society RFC 5280 (May 2008) (hereinafter
"Cooper").
(9) The Examiner rejected claim 19 under 35 U.S.C. § 103(a) as
being unpatentable over the combination of Kersey and Cooper.
(10) The Examiner rejected claim 4 under 35 U.S.C. § 103(a) as
being unpatentable over the combination of Kersey, Ovsiannikov, and Song
et al. (US 2006/0174327 Al; pub. Aug. 3, 2006) (hereinafter "Song").
(11) The Examiner rejected claim 5 under 35 U.S.C. § 103(a) as
being unpatentable over the combination of Kersey, Ovsiannikov, and Peles.
(12) The Examiner rejected claims 11 and 12 under 35 U.S.C.
§ 103(a) as being unpatentable over the combination of Peles, Tuecke, and
Franck Martin, SSL Certificates HOWTO, Rev. v0.5 (2002) (hereinafter
"Martin").
3
Appeal2015-002007
Application 13/631,646
(13) The Examiner rejected claim 14 under 35 U.S.C. § 103(a) as
being unpatentable over the combination of Kersey, Tuecke, and Martin.
(14) The Examiner rejected claim 18 under 35 U.S.C. § 103(a) as
being unpatentable over the combination of Peles, Cooper, and Tuecke.
(15) The Examiner rejected claim 20 under 35 U.S.C. § 103(a) as
being unpatentable over the combination of Kersey, Cooper, and Tuecke.
ANALYSIS
We have reviewed the Examiner's rejections in light of Appellants'
contentions that the Examiner erred. In reaching our decision, we consider
all evidence presented and all arguments made by Appellants. We below
address specific findings and arguments.
(1) Emulated client certificate containing proxy public key
Appellants argue the Examiner errs in finding Kersey discloses,
inherently or otherwise, that "the emulated client certificate contain[ s] the
public key generated at the proxy," as recited in claim 6. App. Br. 13.
Specifically, Appellants first argue Kersey instead discloses that an emulated
client certificate can contain the client's public key. See id. at 13, n.6 (citing
Kersey col. 13, 11. 17-23; Fig. 7a). Appellants then contend that this
disclosure is an alternative to having the emulated client certificate contain
the proxy's public key, and thus, Kersey cannot inherently disclose the
disputed limitation. App. Br. 6; see also Reply Br. 5---6 (arguing the
Examiner has not established that the pseudo certificate generated at the
proxy must contain the proxy's public key, and in fact, the pseudo certificate
could contain the client's public key).
4
Appeal2015-002007
Application 13/631,646
The Examiner finds Kersey discloses the disputed limitation. Ans. 6.
Specifically, the Examiner finds "Kersey discloses establishing a [Secure
Socket Layer ("SSL")] connection between the proxy and the server ... for
transmitting the pseudo certificate from the proxy to the server .... " Id.
(quoting Kersey col. 13, 11. 8-10 ("After the handshaking has completed, the
transparent proxy 32 opens an SSL connection on the backend. The
transparent proxy then acts as the client in this scenario and has an
asymmetric key-pair that it will employ to complete handshake with the
server ... . "));see also id. (citing Kersey col. 13, 11. 31-38). The Examiner
also finds that SSL handshakes were well known in the art- and as
disclosed in Kersey- to include certificates including public keys. Ans. 6
(quoting Kersey col 3, 11. 41--43 ("In a typical SSL connection, a sender and
a receiver establish a secure end-to-end connection. A handshaking
operation occurs during which the sender and receiver exchange information
... includ[ing] encryption variables such as the encryption cipher, the
number of bits, and certificates including public keys."). The Examiner thus
finds Kersey discloses the disputed limitation. See id.; see also id.
("Certificates sent in an SSL exchange inherently must contain the public
key of the sender.").
We are not apprised of error in the Examiner's findings. We agree
with the Examiner and find Kersey explicitly discloses establishing a SSL
connection between the proxy and server, and also find Kersey discloses that
this connection requires that the emulated client certificate contain the public
key generated at the proxy. See Kersey col. 13, 11. 8-10 (disclosing the
proxy establishes a SSL connection with the server using a key-pair to
5
Appeal2015-002007
Application 13/631,646
complete the handshake), col. 3, 11. 41--43 (disclosing during handshaking
that the proxy and server exchange certificates including public keys).
We find Appellants' arguments concerning the emulated client
certificate containing the client's public key, instead of the proxy's public
key, to be unpersuasive. Kersey explicitly discloses establishing a SSL
connection between the proxy and server, completing the handshake, and
then the proxy generates a pseudo certificate. See Kersey col. 13, 11. 10-17.
The Examiner also has provided technical reasoning to reasonably support
that the certificate also includes the proxy's public key, which necessarily
flows from Kersey's teachings. See Kr parte H'halen, 89 USPQ2d l 078,
1084 (BP AI 2008) (precedential); see also In re Cruciferous Sprout Litig.,
301 F.3d 1343, 1349 (Fed. Cir. 2002) (citations and internal quotation marks
omitted) ("Under the principles of inherency, if the prior art necessarily
functions in accordance with, or includes, the claimed limitations, it
anticipates."). Moreover, Appellants' cite to an "alternative approach" also
is unpersuasive. See App. Br. 13 (citing Kersey col. 13, 11. 17-23; Fig. 7a);
Cf Seachange Int'!, Inc. v. C-COR Inc., 413 F.3d 1361, 1380 (Fed. Cir.
2005) (citation omitted) ("Teaching away is irrelevant to anticipation.").
Accordingly, we sustain the rejection of claim 6, and claims 7-9, for
which Appellants did not provide separate arguments for patentability.
(2) Each client certificate corresponding to a client private key
Appellants argue the combination of Kersey and Ovsiannikov fails to
teach or suggest "configuring at the proxy a collection of one or more client
certificates and one or more client private keys, each client certificate
corresponding to a client private key," as recited in claims 1 and 5. App. Br.
13-14, 18. Appellants argue that even accepting the Examiner's reasoning
6
Appeal2015-002007
Application 13/631,646
on what Ovsiannikov teaches, such reasoning does not teach or suggest that
the combination teaches or suggests storing at the proxy a collection of
client certificates and corresponding client private keys (not the CA's private
keys). See App. Br. 14; Reply Br. 7.
The Examiner finds the combination of Kersey and Ovsiannikov
teaches this disputed limitation. See Ans. 7. As to Kersey, the Examiner
finds it teaches a client sending a client certificate to a proxy during a SSL
handshake. Id. (citing Kersey col. 13, 11. 3--4). As to Ovsiannikov, the
Examiner finds it teaches "configuring a collection of configuration details,
including certificates, at an intermediary," such as a proxy. Id. (citing
Ovsiannikov i-f 312). The Examiner further finds "public key cryptography
is known to use a public and corresponding private key to perform
operations, such as signatures .... ". Id. (quoting Kersey col. 12, 11. 60-65)
("The issuer's digital signature is a signature of all the other fields in the
certificate, using the issuer's private key. In the example client certificate
shown in FIG. 7a, the signature would be generated using the Certificate
Authority ("CA's")] private key."). The Examiner thus finds "the disclosure
of a client's public key being included in a client certificate inherently
indicates that there exists a client's private key corresponding to the client's
public key, thus corresponding to the client certificate." Ans. 7.
We find Appellants' arguments persuasive. We agree with Appellants
that the cited portions of the combination fail to teach or suggest that client
private keys and their corresponding client certificates are both collected at
the proxy. Rather, the cited portions of the combination, and Ovsiannikov in
particular, teach only that client certificates are collected at the proxy. See
Ovsiannikov i-f 312. Although we agree with the Examiner that the public
7
Appeal2015-002007
Application 13/631,646
key in the client certificate inherently indicates that a corresponding client
private key exists, the client key is not taught to be collected at the proxy -
it can exist at the client instead. Accordingly, we do not sustain the
Examiner's rejection of claims 1 and 5, as well as claims 2--4, which depend
from claim 1 and incorporate the disputed limitation.
(3) Embedding the server certificate
Appellants argue the combination of Peles and Tuecke, and Tuecke in
particular, fails to teach or suggest "embedding the server certificate in a
field within the emulated server certificate," as recited in claim 10. App. Br.
14 (arguing nowhere does Tuecke teach that the fields of the proxy
certificate include an entire X.509 public key certificate issued to an end
entity). Appellants also contend that Tuecke teaches embedding identifying
information (e.g., server name) in the proxy certificate, and thus, there is no
motivation also to embed the entire server certificate. See Reply Br. 7-8.
The Examiner finds the combination of Peles and Tuecke, and Tuecke
in particular, teaches or suggests the disputed limitation. Ans. 8.
Specifically, the Examiner finds Tuecke teaches that the proxy certificate
must contain a subject field containing the issuer field. See id. (citing
Tuecke § § 1, 2 .1, 3 .4). The Examiner also finds the proxy certificate fields
"include fields of an X.509 public key certificate issued to an end entity, i.e.
a server." Id. (citing Tuecke § 2.1 (defining End Entity Certificate
("EEC"))). The Examiner finds it would have been obvious to one of
ordinary skill in the art also to embed the "server certificate within a field of
a proxy certificate for the same purpose of identifying the server."
We find Appellants' arguments persuasive. We agree with Appellants
that the cited portions of the combination fail to teach or suggest embedding
8
Appeal2015-002007
Application 13/631,646
the entire server certificate in a field within the emulated server certificate.
See Tuecke § § 1, 2 .1, 3. 4. We also agree with Appellants that the
Examiner's finding that one of ordinary skill in the art would have found it
obvious to embed the entire server certificate - as opposed to Tuecke' s
teaching of embedding only certain identifying fields - is unsupported by
the record evidence. Tuecke teaches embedding certain fields to identify the
server.
Accordingly, we do not sustain the Examiner's rejection of claim 10,
as well as claims 11 and 12, which depend from claim 10 and incorporate
the disputed limitation. In addition, our reasoning also applies to the
disputed limitation for claim 13, for which Appellants and the Examiner rely
on their arguments for claim 10, and thus, we also do not sustain the
Examiner's rejection of claim 13, as well as claims 14 and 15 which depend
therefrom.
(4) Signed by a private key ofthe server
Appellants argue the combination of Peles and Brown fails to teach or
suggest "sending from the proxy to the server an emulated server certificate
for the emulated server certificate to be signed by a private key of the server;
receiving from the server an emulated server certificate that has been signed
with the private key of the server; and sending from the proxy to the client
the emulated server certificate that has been signed with the private key of
the server," as recited in claim 16. App. Br. 15-16. According to
Appellants, Brown teaches away from the disputed limitations because it
teaches "that the signing of a certificate should be 'accomplished without the
involvement of an external certificate authority or any other third party."'
Id. at 16 (citing Brown i-f 20). Appellants argue Brown's teaching also
9
Appeal2015-002007
Application 13/631,646
applies to the proxy server. Id. (quoting Brown if 18 ("In view of the
changing identities of devices on a network, it is proposed ... to have a
certificate trust system that does not require the involvement of an external
certificate authority or any other third party[, and] ... that each device in a
network may act as its own certificate authority.")); see also Reply Br. 10
(citing Spec. if 60-61; Fig. 8 (arguing that the Examiner relies on
impermissible hindsight)).
The Examiner finds the combination teaches the disputed limitations.
See Ans. 9-10; Final Act. 20-21. The Examiner first finds Brown teaches or
suggests "'each device in a network may act as its own certificate
authority."' Ans. 9 (citing Brown if 18). The Examiner also finds "Brown
does not teach that each device in a network is required to act as its own
certificate authority, but merely that external certificate authorities and other
third parties that are not in the network should not have to be relied upon."
See id. The Examiner further finds:
[T]he modification of Peles to incorporate the teachings of
Brown by adding an intermediary proxy between a client and a
server acting as its own certificate authority does not disparage
or render the teachings unsatisfactory for their intended purpose
because in the context of Peles, neither the proxy nor the server
are external entities or third parties because they are integral
elements in the communication chain. Further, Brown's
exclusion of third parties does not specifically contemplate the
added benefit of proxies and when Peles and Brown are
combined, it is clear that a proxy acting on behalf of a server
which is acting as its own certificate authority would require an
emulated certificate generated by the proxy to be sent to, and
signed by, the server.
Ans. 9.
10
Appeal2015-002007
Application 13/631,646
We agree with the Examiner's findings and adopt them as our own
with respect to these disputed limitations. Appellants have not established
that Brown teaches away from the claimed invention and have not
demonstrated that "a person of ordinary skill, upon reading the reference,
would be discouraged from following the path set out in the reference, or
would be led in a direction divergent from the path that was taken by the
applicant." In re Gurley, 27 F.3d 551, 553 (Fed Cir. 1994). We agree with
the Examiner that one of ordinary skill in the art would have found the
disputed limitations obvious in light of Brown and Kersey' s combined
teachings, including Kersey's teaching of using a proxy server as an
intermediary. See Medichem, S.A. v. Rolabo, S.L., 437 F.3d 1157, 1165
(Fed. Cir. 2006) ("Where the prior art contains 'apparently conflicting'
teachings ... each reference must be considered 'for its power to suggest
solutions to an artisan of ordinary skill ... consider[ing] the degree to which
one reference might accurately discredit another."') citing In re Young, 927
F.2d 588, 591 (Fed. Cir. 1991).
Furthermore, Appellants' arguments amount to a piecemeal attack on
Kersey and Brown, despite the Examiner relying on the combined teachings
of these references. See In re Merck & Co., 800 F.2d 1091, 1097 (Fed. Cir.
1986) ("Non-obviousness cannot be established by attacking references
individually where the rejection is based upon the teachings of a
combination of references."). We also find Appellants' assertion of
impermissible hindsight unsupported. Accordingly, we sustain the rejection
of claim 16.
11
Appeal2015-002007
Application 13/631,646
(5) Emulated server certificate containingproxypublic key
Appellants argue that the combination of Peles and Cooper fails to
teach or suggest "generating an emulated server certificate chain based on
the server certificate chain, the emulated server certificate chain containing a
plurality of emulated certificates, each emulated certificate containing a
public key generated at the proxy," as recited in claim 17. App. Br. 17;
Reply Br. 11. Appellants argue that "establishing an SSL connection need
not send an emulated certificate containing the sender's public key." App.
Br. 1 7 (citing Appellants' arguments above that Kersey teaches a proxy can
send an emulated client certificate using the client's public key, rather than
the proxy's public key). Appellants thus contend "it is not inherent that the
emulated server certificate generated by the proxy contains a public key of
the proxy." See id.
The Examiner finds the combination, and Peles in particular, teaches
or suggests the disputed limitation. Ans. 10. In accordance with the
Examiner's findings for claim 6, the Examiner finds Peles teaches
establishing a SSL connection, which "involves sending a certificate
containing the sender's public key," as well as teaches a proxy that generates
an emulated server certificate for use in a SSL connection with a client. See
id. (citing Peles col. 7, 11. 35-58). The Examiner thus finds the emulated
server certificate generated by the proxy must contain the proxy's public key
for use in the SSL connection. Ans. 10.
Based on our reasoning above, we agree with the Examiner that the
combination of Peles and Cooper teaches or suggests the disputed limitation.
For example, we agree that Peles teaches the proxy establishing a SSL
connection with the end entities, including the client, and that such
12
Appeal2015-002007
Application 13/631,646
connection requires a certificate exchange including the proxy's public key.
See Peles col. 7, 11. 35-58; supra. As above, we find Appellants' arguments
concerning Kersey's teachings of alternative approaches unpersuasive.
Accordingly, we sustain the rejection of claim 17, as well as claims
18, 19, and 20 for which Appellants did not provide separate arguments for
patentability.
DECISION
( 1) We affirm the Examiner's § 102 (b) rejection of claims 6 and 9.
(2) We affirm the Examiner's§ 103(a) rejections of claims 7, 8,
and 16-20.
(3) We reverse the Examiner's§ 103(a) rejections of claims 1-5
and 10-15.
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).
AFFIRMED-IN-PART
13