Ex Parte Elrod

Patent Trial and Appeal Board

Dec 23, 2016

11897707 (P.T.A.B. Dec. 23, 2016)

United States Patent and Trademark Office
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
APPLICATION NO. FILING DATE FIRST NAMED INVENTOR ATTORNEY DOCKET NO. CONFIRMATION NO.
11/897,707 08/30/2007 Thomas Mitchell Elrod 05220.219 (P198) 6126
14400 7590 12/23/2016
Patent Dneket AHminisitratnr
EXAMINER
LOWENSTEIN SANDLER LLP
65 Livingston Avenue
DORAIS, CRAIG C
Roseland, NJ 07068 ART UNIT PAPER NUMBER
2194
MAIL DATE DELIVERY MODE
12/23/2016 PAPER
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.
PTOL-90A (Rev. 04/07)
UNITED STATES PATENT AND TRADEMARK OFFICE
BEFORE THE PATENT TRIAL AND APPEAL BOARD
Ex parte THOMAS MITCHELL ELROD
Appeal 2016-000103
Application 11/897,707
Technology Center 2100
Before HUNG H. BUI, KEVIN C. TROCK, and
AARON W. MOORE, Administrative Patent Judges.
MOORE, Administrative Patent Judge.
DECISION ON APPEAL
Appeal 2016-000103
Application 11/897,707
STATEMENT OF THE CASE
Appellant1 appeals under 35 U.S.C. § 134(a) from a Final Rejection of
claims 1—21, 26, and 32—38, which are all of the pending claims. We have
jurisdiction under 35 U.S.C. § 6(b).
We affirm.
THE INVENTION
The application is directed to “a method and apparatus for supporting
a secure communication between a remoting client and a remoting server.”
(Spec. 115.) Claim 1, reproduced below, is exemplary:
1. A method comprising:
forming, by a client invoker executed on a remoting client, a
secured socket based on a set of secure sockets layer (SSL)
parameters;
generating, by the client invoker, an invocation request with
the secured socket to a remoting server,
wherein the set of SSL parameters is based on keys of a SSL
socket builder of the remoting client, and
wherein said forming the secured socket comprises:
selecting, by a processing device, a first socket connection
from a pool of socket connections on the remoting client to
use for said generating the invocation request to the remoting
server;
determining if the first socket connection has timed out
while in the pool; and
repeating said selecting and determining until a non-timed
out socket connection of the pool of socket connections
1 Appellant identifies Red Hat, Inc. as the real party in interest. (See App.
Br. 3.)
2
Appeal 2016-000103
Application 11/897,707
becomes available or a threshold number of attempts is
reached;
creating, by the SSL socket builder, an SSL socket factory;
and
configuring the SSL socket factory with the set of SSL
parameters, wherein the SSL socket builder to swap in a new SSL
socket factory with an updated keystore, wherein configuring the
SSL socket factory comprises setting an attribute comprising at
least one of a keystore URL, a keystore password, a keystore
type, a truststore URL, a truststore password, or a truststore type.
THE REFERENCES
The prior art relied upon by the Examiner in rejecting the claims on
appeal is:
Alibakhsh et al. US 2001/0056505 A1 Dec. 27, 2001
Joseph et al. US 2004/0003085 Al Jan. 1, 2004
Sudhir Upadhyay, Understanding JSSE, http://java.sys-con.com/
node/84682 (May 11, 2005) (“Upadhyay”)
JBoss, Inc., JBoss Remoting Guide, JBoss Remoting Version
1.4.0 Final (Jan. 25, 2006) (“JBoss 1.4.0”)
JBoss, Inc., JBoss Remoting Guide, JBoss Remoting Version
2.0.0GA (Aug. 29, 2006) (“JBoss 2.0.0”)
Mayank Mishra, Simple 4 Steps to Use X509V1 Certificates to
Secure WS Communication Using WSIT, http://blogs.sun.com/
mayank/entry/simple_ 4_steps_to_use (not presently accessible
but dated Dec. 6, 2010) (“Mishra”)
THE REJECTIONS
1. Claims 1, 5, 11, 15, and 21 stand rejected under 35 U.S.C.
§ 103(a) as unpatentable over JBoss 1.4.0, Joseph, Alibakhsh, and JBoss
2.0.0. (See Final Act. 2—18.)
3
Appeal 2016-000103
Application 11/897,707
2. Claims 6, 10, 16, 20, 26, 33, 35, and 38 stand rejected under 35
U.S.C. § 103(a) as unpatentable over JBoss 1.4.0, Joseph, and JBoss 2.0.0.
(See Final Act. 18—36.)
3. Claims 2 and 12 stand rejected under 35 U.S.C. § 103(a) as
unpatentable over JBoss 1.4.0, Alibakhsh, and Upadhyay. (See Final Act.
36-37.)
4. Claims 7 and 17 stand rejected under 35 U.S.C. § 103(a) as
unpatentable over JBoss 1.4.0, Joseph, and Upadhyay. (See Final Act. 38—
39.)
5. Claims 3,4, 13, 14, and 32 stand rejected under 35 U.S.C.
§ 103(a) as unpatentable over JBoss 1.4.0, Joseph, Alibakhsh, and Mishra.
(See Final Act. 39-46.)
6. Claims 8, 9, 18, 19, 34, 36, and 37 stand rejected under 35
U.S.C. § 103(a) as unpatentable over JBoss 1.4.0, Joseph, and Mishra. (See
Final Act. 46—55.)
APPELLANT’S CONTENTIONS
Appellant argues the rejections are in error for the following reasons:
1. JBoss 1.4.0 “does not teach or suggest forming a secured socket
based on a set of SSL parameters, wherein the set of SSL parameters is
based on keys of a SSL socket builder of a remoting client, as claimed.”
(App. Br. 10.)
2. Regarding the motivation to combine, “the Office action asserts
a conclusion without any analysis or supporting evidence, and does not
address how the proposed modification would improve operation.” (App.
Br. 12.)
4
Appeal 2016-000103
Application 11/897,707
ANALYSIS
The Examiner finds “wherein the set of SSL parameters is based on
keys of a SSL socket builder of the remoting client” to be taught or
suggested in “at least the code box on pg. 41” of JBoss 1.4.0. (See final
Act. 4—5.)
Appellant argues the reference “does not teach or suggest any
configurable attributes or parameters that correspond to a client socket
builder or a SSL socket builder of a remoting client” and “[t]he only socket
builder taught by [JBoss 1.4.0] i[s] a server socket builder, which one of
skill in the art would recognize[] as separate and distinct from any client
socket builder.” (App. Br. 10, emphasis omitted.)
The Examiner responds that “[JBoss 1.4.0] page 41 above the
previously mapped code snippets . . . states that ‘the SSLSocketBuilder is
where the ssl server socket (and ssl socket for clients) originate and where
all properties for the ssl server socket are configured.’” (Ans. 6.) The
Examiner further points to code comments stating that “the server socket
factory MBean [is] to be used as attribute to socket invoker ... This service
provides the exact same API as the ServerSocketLactory, so [it] can be set as
an attribute of that type on any MBean requiring [a] ServerSocketLactory,”
as well as commented out code “showing] that the cited [‘]SocketBuilder’ is
essentially a remoting service and can be a proxy” which “makes it both a
client and a server and as such has those same attributes.” (Id. at 6—7.) The
Examiner concludes as follows:
In short, the SSLSocketBuilder and the code cited is providing a
service (therefore, this service is being provided to a client,
which is supported as a remote client, the evidence of which is
found throughout the code and the statements that this service is
5
Appeal 2016-000103
Application 11/897,707
offered as an MBean (which supports the providing of remote
services). When the client needs to provide customizations, the
service requester (i.e. a client) has to provide to the service it is
requesting with key store information. That information
therefore came from the client.
(Ans. 7.) Appellant does not respond to these findings.
We conclude that Appellant has not provided sufficient argument or
evidence to overcome the Examiner’s findings, as detailed in the Answer,
that JBoss 1.4.0 teaches or suggests the disputed limitation.
Regarding the motivation to combine, Appellant asserts that the
Examiner’s stated motivation—to “allow for the use of different transports
to fit different needs, yet still maintain the same API for making the remote
invocations and only requiring configuration changes, not code changes”—
“does not exhibit any articulated reasoning with some rational underpinning
to support the legal conclusion of obviousness.” (App. Br. 12.) We find
Appellant’s contention insufficient to show Examiner error. The argument
that the motivation is conclusory is itself conclusory, as Appellant fails to
articulate why, for example, a desire to maintain the same API for remote
invocations would not motivate one of skill in the art to make the
combination.
Because we find Appellant’s arguments unpersuasive, we sustain the
rejection of claims 1—21, 26, and 32—38 under 35 U.S.C. § 103(a).
6
Appeal 2016-000103
Application 11/897,707
DECISION
The rejections of claims 1—21, 26, and 32—38 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).
AFFIRMED
7