Ex Parte ESPINO

Patent Trial and Appeal Board

Apr 25, 2016

13555596 (P.T.A.B. Apr. 25, 2016)

UNITED STA TES p A TENT AND TRADEMARK OFFICE
APPLICATION NO. FILING DATE
13/555,596 07/23/2012
25537 7590 04/27/2016
VERIZON
PA TENT MANAGEMENT GROUP
1320 North Court House Road
9th Floor
ARLINGTON, VA 22201-2909
FIRST NAMED INVENTOR
Maye! ESPINO
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.
COS01020Cl 9365
EXAMINER
OHBA, MELLISSA M
ART UNIT PAPER NUMBER
2164
NOTIFICATION DATE DELIVERY MODE
04/27/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):
patents@verizon.com
PTOL-90A (Rev. 04/07)
UNITED STATES PATENT AND TRADEMARK OFFICE
BEFORE THE PATENT TRIAL AND APPEAL BOARD
Ex parte MA YEL ESPINO
Appeal2014-009730
Application 13/555,596
Technology Center 2100
Before HOWARD B. BLANKENSHIP, ALLEN R. MacDONALD, and
STEPHEN C. SIU Administrative Patent Judges.
SIU, Administrative Patent Judge
DECISION ON APPEAL
Appeal2014-009730
Application 13/555,596
This is a decision on appeal under 35 U.S.C. § 134(a) from the
Examiner's rejection of claims 1-20. We have jurisdiction under 35 U.S.C.
§ 6(b ).
The disclosed invention relates generally to lightweight directory
access protocol applications. Para. 3. Claim 1 reads as follows:
1. A hand-held apparatus, comprising:
a client configured to communicate with a directory
server using a lightweight directory access protocol
(LDAP); and
a memory configured to store a customizable
parameter and an executable computer instruction for
implementing an application program interface (API) that
includes a function call to enable communications
between a plurality of calling applications and the client,
wherein the customizable parameter specifies how
the client generates a query to the directory server for
updating the plurality of calling applications, the function
call storing a preference of one of the calling applications
in the memory, the preference including a parameter to
enable the one calling application to have data for the one
calling application automatically retrieved by the client
upon the client connecting to the directory server,
wherein each one of a plurality of processes
executing on the apparatus includes a unit of activity
characterized by a sequential thread of execution, a current
state, and an associated set of resources.
The Examiner relies upon the following references as evidence in
support of the rejections:
Dalby
Ambrosini
Chandra
Rob ohm
US 2002/0057284 Al
US 2002/0078004 Al
US 2002/0138582 Al
US 2002/0136222 Al
2
May 16, 2002
June 20, 2002
Sept. 26, 2002
Sept. 26,2002
Appeal2014-009730
Application 13/555,596
The Examiner rejects claims 1-8 and 14--20 under 35 U.S.C. § 103(a)
as being unpatentable over Ambrosini and Dalby; claims 9 and 10 under 35
U.S.C. § 103(a) as being unpatentable over Ambrosini, Dalby, and Chandra;
and claims 11-13 under 35 U.S.C. § 103(a) as being unpatentable over
Ambrosini, Dalby, and Robohm.
ANALYSIS
Claims 1-8 and 14--20 - Ambrosini and Dalby
Claim 1, for example, recites a function call to enable
communications between a plurality of calling applications and the client
and that the function call stores a preference of one of the calling
applications in the memory. Appellants argue that Ambrosini and Dalby fail
to disclose or suggest these features. App. Br. 8.
The Examiner finds that Ambrosini discloses an "LDAP operation"
(or "fi1nction call") that enables communication bet\~1een a calling
application and the client, as recited in claim 1. Ans. 5---6 (citing Ambrosini
iii! 24--26, 28-30, Figs. 1 and 2).
Appellants argue that the "LDAP operation" of Ambrosini is not the
same or suggestive of the "function call," as claimed, because the "LDAP
operation" of Ambrosini is "not included in an APL" App. Br. 9. Claim 1
recites an interface that includes a function call. The Examiner states that
Ambrosini "teaches an LDAP, which serves as an interface." Ans. 5. We
note that, as the Examiner points out, Ambrosini discloses a system and
method in which "LDAP serves as an interface" that "receiv[ es] from a user
an LDAP operation." Ambrosini if 13, 24. Hence, Ambrosini discloses an
"interface" that includes an "LDAP operation," upon receipt of the LDAP
3
Appeal2014-009730
Application 13/555,596
operation from the user. Appellants do not assert or demonstrate
persuasively a difference between the "interface" of "LDAP" (as disclosed
by Ambrosini) and an "API," as recited in claim 1, both of which includes a
function call (or "LDAP operation").
Appellants also argue that the "LDAP operation" of Ambrosini is not
the same or suggestive of the "function call," as claimed because the "LDAP
operation" of Ambrosini "does not 'enable communications between a
plurality of calling applications and the client."' App. Br. 9, 11. The
Examiner states that Ambrosini discloses this feature. Ans. 5-6. Claim 1
recites a function call to enable communications between a plurality of
applications and the client. We note that, as the Examiner points out,
Ambrosini discloses a system and method "implemented within the scope of
LDAP as one or more application programs" and including "receiving from
a user an LDAP operation directed to an LDAP search engine." Ambrosini
i-fi-f 12-13. Ambrosini also discloses that the LDAP operation "can be a
request to access information from a directory database" and the "operation
can be a read, write, search, or compare operation or any other LDAP
defined operation and combinations thereof." Ambrosini i138. In other
words, Ambrosini discloses a "function call" (i.e., "LDAP operation") that
enables communications between a plurality of calling applications (i.e.,
within the scope of LDAP as one or more application programs) and the
client (i.e., the user communicates within the scope of LDAP as one or more
application programs to "request to access information" via "a read, write,
search or compare operation or any other LDAP defined operation").
Appellants do not assert or demonstrate persuasively a difference between
enabling communication between a client and one or more LDAP
4
Appeal2014-009730
Application 13/555,596
applications, as disclosed by Ambrosini, and a function call enabling
communications between a plurality of calling applications (within the scope
of LDAP, as disclosed by Ambrosini) and the client (i.e., enabling a user to
communicate within the scope of LDAP as one or more application
programs).
Appellants also argue that the "LDAP operation" of Ambrosini is not
the same or suggestive of the "function call," as claimed, because the
"LDAP operation" of Ambrosini is an "operation" and "cannot store a
preference and ... clearly does not store anything." App. Br. 10. The
Examiner states that Ambrosini discloses this feature. Ans. 6-7. Claim 1
recites the function call storing a preference and that the preference includes
a parameter to enable an application. As the Examiner points out,
Ambrosini discloses "reformatting" an "LDAP operation" with "one or more
application specific parameters." Ambrosini i-f 13. Hence, the "LDAP
operation" includes or "stores" the "one or more application specific
parameters."
In Ambrosini, "[ t ]he method further can include the step of providing
the reformatted LDAP operation to the LDAP search engine" and
subsequent execution of the operation (e.g., "read, write, search or compare
operation, or any other LDAP defined operation and combinations thereof').
Ambrosini i-fi-1 13, 38. Hence, Ambrosini discloses an LDAP operation (i.e.,
"function call") that stores (i.e., includes or "stores") a preference (the
"preference" including "a parameter to enable ... application," as recited in
claim 1 ). Appellants do not demonstrate persuasively a difference between
the LDAP operation storing "one or more application specific parameters"
5
Appeal2014-009730
Application 13/555,596
of Ambrosini and a function call storing a preference, the preference
including a parameter, as recited in claim 1.
Appellants also argue that Ambrosini fails to disclose or suggest a
"customizable parameter that specifies how a client generates a query to a
directory server." App. Br. 9. We agree with the Examiner that Ambrosini
discloses or suggests this feature for at least the reasons set forth by the
Examiner. Ans. 6-7. For example, Ambrosini discloses the LDAP
operation reformatted "based on 'application specific parameters."' Ans. 7;
see also Ambrosini i-f 14. Appellants do not demonstrate persuasively a
difference between the parameters of Ambrosini and the parameters recited
in claim 1, for example.
Appellants argue that Ambrosini fails to disclose or suggest a
parameter that "correspond[ s] to the claimed 'preference of one of the
calling applications."' App. Br. 13. Claim 1 recites a function call "storing
a preference of one of the calling applications" and "the preference including
a parameter." As previously discussed, Ambrosini discloses an LDAP
operation (i.e., a "function call") that stores "application specific
parameters" (i.e., a "preference," the "preference including a parameter," as
recited in claim 1 ), the "application specific parameters" of Ambrosini being
of one or more application programs to "request to access information" via
"a read, write, search or compare operation, or any other LDAP defined
operation." Ambrosini i-fi-112-13, 38. Appellants do not demonstrate
persuasively a difference between the LDAP operation storing a parameter
(or "preference") of one or more applications (or "any other LDAP defined
operation").
6
Appeal2014-009730
Application 13/555,596
Appellants do not provide additional arguments in support of claims
2-8 and 14--20 or arguments pertaining to Dalby. Appellants also do not
provide additional arguments with respect to claims 9-13 or arguments
pertaining to Chandra or Robohm. App. Br. 14--15.
Obviousness-type Double Patenting - Claims 1-8
According to Appellants, the Examiner rejects claims 1-8 "based on
obviousness-type double patenting over claims 1through21 of U.S. Patent
No. 8,015,574 and claims 1through20 of U.S. Patent No. 7,243,355." App.
Br. 6. Appellants also state that "Appellant will consider the appropriateness
of filing a Terminal Disclaimer" based on the disposition of "the other
rejections on Appeal." App. Br. 7. We, therefore, defer deciding the
obviousness-type double patenting issue such that Appellants may "consider
the appropriateness of filing a Terminal Disclaimer," as Appellants state.
DECISION
We affirm the Examiner's rejection of claims 1-8 and 14--20 under 35
U.S.C. § 103(a) as being unpatentable over Ambrosini and Dalby; claims 9
and 10 under 35 U.S.C. § 103(a) as being unpatentable over Ambrosini,
Dalby, and Chandra; and claims 11-13 under 35 U.S.C. § 103(a) as being
unpatentable over Ambrosini, Dalby, and Robohm.
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