KONG INC

Patent Trials and Appeals Board

Nov 12, 2020

15641835 - (D) (P.T.A.B. Nov. 12, 2020)

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.
15/641,835 07/05/2017 Marco PALLADINO 077576-8001.US02 5407
22918 7590 11/12/2020
PERKINS COIE LLP - PAO General
P.O. BOX 1247
SEATTLE, WA 98111-1247
EXAMINER
KE, PENG
ART UNIT PAPER NUMBER
3992
NOTIFICATION DATE DELIVERY MODE
11/12/2020 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):
patentprocurement@perkinscoie.com
PTOL-90A (Rev. 04/07)
UNITED STATES PATENT AND TRADEMARK OFFICE
____________

BEFORE THE PATENT TRIAL AND APPEAL BOARD
____________

Ex parte MARCO PALLADINO, AUGUSTO MARIETTI,
and MICHELE ZONCA
____________

Appeal 2020-006393
Application 15/641,835
Patent 9,077,773 B2
Technology Center 3900
____________

Before ALLEN R. MacDONALD, JOHN A. JEFFERY, and
ERIC B. CHEN, Administrative Patent Judges.

JEFFERY, Administrative Patent Judge.

DECISION ON APPEAL
Under 35 U.S.C. § 134(a), Appellant1 appeals from the Examiner’s
decision to reject claims 1–12, 14–32, 34–41, and 43–79. We have
jurisdiction under 35 U.S.C. § 6(b).
We REVERSE.

1 We use the word “Appellant” to refer to “applicant” as defined in 37
C.F.R. § 1.42. Appellant identifies the real party in interest as KONG INC.
Appeal Br. 2.
Appeal 2020-006393
Application 15/641,835
Patent 9,077,773 B2

2
STATEMENT OF THE CASE
Appellant seeks to reissue U.S. Patent 9,077,773 (“’773 patent”)
directed to distributing application programming interfaces (APIs) in a social
hub that enables users to access APIs that others submitted to the hub. To
provide additional functionality, users can wrap submitted APIs in a
standard description format and add various add-ons on top of an existing
API infrastructure. See Abstract. Claim 28 is illustrative:
28. A management system comprising:
means for receiving a text-based search query indicating
API specific search criteria;
means for searching a categorized APT data store using
the API specific search criteria;
means for providing one or more APIs that match the
API specific search criteria via an online platform;
means for providing a plurality of add-ons, wherein each
add-on of the plurality of add-ons provides functionality in
addition to an API of the one or more APIs;
means for receiving a selection of a first API of the one
or more APIs that match the API specific search criteria
responsive to providing the one or more APIs;
means for receiving an indication of a selection of an
add-on of the plurality of add-ons;
means for associating the add-on of the plurality of add-
ons with the first API;
means for automatically generating a plurality of client
libraries based on user-generated parameters associated with the
first API, and based on a standard description format associated
with the first API;
means for providing the plurality of client libraries
associated with the first API responsive to receiving the
selection of the first API;
means for receiving a selection of a first client library of
the plurality of client libraries associated with the first API; and
means for providing the first API via the online platform.
Appeal 2020-006393
Application 15/641,835
Patent 9,077,773 B2

3
THE REJECTIONS
The Examiner rejected claim 28 under 35 U.S.C. § 102(e) as
anticipated by Farah (US 2011/0231280 Al; published Sept. 22, 2011).
Final Act. 4–6.2
The Examiner rejected claims 1–10, 12, 14–19, 21–27, 29–32, 34–
39,3 41, and 43–79 under 35 U.S.C. § 103 as unpatentable over Farah and
Brinskelle (US 8,856,869 Bl; issued Oct. 7, 2014). Final Act. 7–25.
The Examiner rejected claims 11, 20, and 40 under 35 U.S.C. § 103 as
unpatentable over Farah, Brinskelle, and Michels (US 9,027,039 B2; issued
May 5, 2015). Final Act. 25–26.

THE ANTICIPATION REJECTION
The Examiner finds that Farah discloses every recited element of
independent claim 28 including, among other things, (1) means for
providing add-ons, where each add-on provides an additional function to an
API when the add-on is associated with a respective API; (2) means for
associating the add-on with the first API; and (3) means for automatically
generating plural client libraries based on user-generated parameters and
standard description format associated with the API. Final Act. 4–6.

2 Throughout this opinion, we refer to (1) the Final Rejection mailed
February 3, 2020 (“Final Act.”); (2) the Appeal Brief filed June 18, 2020
(supplemented July 7, 2020) (“Appeal Br.”); (3) the Examiner’s Answer
mailed August 31, 2020 (“Ans.”); and (4) the Reply Brief filed September
14, 2020 (“Reply Br.”).
3 Although claim 35 depends from cancelled claim 33, we nonetheless
presume that it was intended to depend from independent claim 30.
Appeal 2020-006393
Application 15/641,835
Patent 9,077,773 B2

4
According to the Examiner, Farah’s paragraphs 58 to 60 disclose these three
elements. See id.
Appellant argues that the Examiner not only ignored the distinction
between the recited APIs, add-ons, and client libraries, the Examiner also
ignored Appellant’s remarks in the amendment filed on December 6, 2019
that contested seven different features of claim 28. Appeal Br. 5–8; Reply
Br. 2. Appellant adds that Farah does not disclose, among other things, the
recited client libraries that are not merely generic product catalogs, but
rather code chunks that programmers import into their development projects
as the term is understood in the art and in light of the Specification. See id.

ISSUE
Under § 102, has the Examiner erred in rejecting claim 28 by finding
that Farah discloses (1) means for providing add-ons, where each add-on
provides an additional function to an API when the add-on is associated with
a respective API; (2) means for associating the add-on with the first API;
and (3) means for automatically generating plural client libraries based on
(a) user-generated parameters, and (b) standard description format, both of
which are associated with the first API?

ANALYSIS
We begin by noting that Appellant’s arguments in the Brief are
inartfully presented and, consequently, Appellant’s position on appeal is not
a model of clarity. Notably, Appellant does not articulate many arguments
explicitly in the Appeal Brief, but instead “reasserts” every argument
Appeal 2020-006393
Application 15/641,835
Patent 9,077,773 B2

5
presented in an amendment filed on December 6, 2019. See Appeal Br. 6.
This piecemeal practice not only improperly incorporates in the Appeal
Brief arguments made during prosecution, it makes our task of discerning
Appellant’s position on appeal all the more difficult. See Manual of Patent
Examining Procedure (MPEP) § 2144.04(IV)(A) (9th ed. Rev. 10.2019, June
2020) (“It is essential that the Board be provided with a brief fully stating
the position of the appellant with respect to each ground of rejection
presented for review in the appeal so that no search of the Record is required
in order to determine that position. Thus, the brief should not incorporate or
reference previous responses.”). Cf. LeVeen v. Edwards, 57 USPQ2d 1406,
1413 (BPAI 2000) (noting that it is not the decisionmaker’s job to scour the
record and invent some theory which supports a party’s case); see also
DeSilva v. DiLeonardi, 181 F.3d 865, 867 (7th Cir. 1999) (“[A] brief must
make all arguments accessible to the judges, rather than ask them to play
archaeologist with the record.”).
The Examiner attempts to respond to these improperly-incorporated
arguments by, among other things, summarizing them in an Appendix to the
Examiner’s Answer. See Ans. 21–28. The Examiner also responds to
Appellant’s arguments that were articulated explicitly in the Appeal Brief
elsewhere in the Answer. See Ans. 4–20.
Despite Appellant’s less than artful briefing,4 we are nonetheless
persuaded that the Examiner’s anticipation rejection is erroneous on this

4 Appellant’s additional contentions in the Reply Brief that the Examiner
entered an undesignated new ground of rejection in the Answer (see, e.g.,
Reply Br. 4–8) are petitionable—not appealable—matters that are not before
us. See 37 C.F.R. § 41.40(a) (noting that any request seeking review of the
Appeal 2020-006393
Application 15/641,835
Patent 9,077,773 B2

6
record. As Appellant indicates (Reply Br. 2), the claim recites APIs, add-
ons, and client libraries separately, thus distinguishing those elements.
We, therefore, first construe the term “API.” According to the
Specification, “[a]pplication programming interfaces (APIs) are
specifications intended to be used as interfaces by software components to
communicate with each other. For example, APIs can include specifications
for routines, data structures, object classes, and variables.” ’773 patent,
col. 1, ll. 19–23. The Specification adds that “[a]n API specification can
take many forms, including an International Standard such as POSIX,
vendor documentation such as the Microsoft Windows API, and/or the
libraries of a programming language (e.g., Standard Template Library in
C++ or JavaAPI).” Id. col. 1, ll. 23–27.
This description is consistent with the term’s meaning in the art. For
example, one special-purpose dictionary defines the term “API” as “the
interface presented to writers of an application by the underlying operating
system. . . . An API is defined at source code level and provides a level of
abstraction between the application and the kernel (or other privileged
utilities) to ensure the portability of the code.” DICTIONARY OF COMPUTER
SCIENCE, ENGINEERING, AND TECHNOLOGY 20 (Phillip A. Laplante ed. 2001)
(“Laplante Computer Dictionary”). That dictionary adds that “[a]n API can

Examiner’s failure to designate a new ground of rejection must be made via
a petition filed before filing a Reply Brief). Where, as here, no such petition
was filed, Appellant’s arguments regarding any alleged new ground of
rejection in the Answer are, therefore, waived. See id.; see also MPEP
§ 1208(I).

Appeal 2020-006393
Application 15/641,835
Patent 9,077,773 B2

7
also provide an interface between a high level language and lower level
utilities and services which were written without consideration for the
calling conventions supported by compiled languages.” Id. 20–21.
Another special-purpose dictionary defines “API” as “[a] standardized
interface via which an application program can access services provided by
the operating system or other subsystems.” Dick Pountain, THE PENGUIN
CONCISE DICTIONARY OF COMPUTING 15 (2003) (“Penguin Computing
Dictionary”). That dictionary adds that “[a]n API is usually defined by
source code in a high-level programming language such as C or C++, and
consists of a set of functions each of which invokes a particular service;
programmers then call these functions from their own programs.” Id.
Another special-purpose dictionary defines “API” in pertinent part as
“[a] functional interface supplied by the operating system or by a separately
orderable licensed program that allows an application program written in a
high-level language to use specific data or functions of the operating system
or licensed program.” IBM DICTIONARY OF COMPUTING 28 (10th ed. 1994).
Given this understanding of what an API means in the art, the
Examiner’s mapping an “application” in Farah to the recited API (see Final
Act. 5–6; Ans. 25) is problematic on this record. Farah’s paragraphs 58 to
60, on which the Examiner relies in this regard (see Final Act. 5–6), describe
a Subscription App Store functionality that, among other things, (1) adds
requested new applications to the App Store, and (2) enables administrators
to create new bundles, namely combinations of applications, services, and/or
add-ons, to add to the store. See Farah ¶ 58–60; Fig. 12.
Appeal 2020-006393
Application 15/641,835
Patent 9,077,773 B2

8
Farah’s paragraphs 58 to 60, however, say nothing about APIs, much
less whether the applications in the App Store include, or were created with,
an API. Farah’s paragraphs 94 and 95 fare no better in this regard, for
although the user can search for applications via the graphical user interface
of Figure 19, to say that this functionality necessarily searches for APIs as
the Examiner indicates (Final Act. 4–5) strains reasonable limits on this
record given the commonly-understood meaning of the term “API” in the art
noted above.
Nor do we find that Farah necessarily discloses means for providing
add-ons, where each add-on provides an additional function to an API when
the add-on is associated with a respective API, let alone means for
associating the add-on with the first API as claimed. Here again, Farah’s
paragraphs 58 to 60, on which the Examiner relies for teaching these
limitations (see Final Act. 5; Ans. 22), say nothing about APIs, much less
whether the applications in the App Store include, or were created with, an
API. Although Farah’s paragraph 59 notes that a bundle added to the App
Store can include add-ons, we cannot say—nor has the Examiner shown—
that these add-ons necessarily provide additional functions to an API, much
less that they are associated with an API as claimed.
Nor do we find that Farah necessarily discloses means for
automatically generating plural client libraries based on (1) user-generated
parameters, and (2) a standard description format, both of which are
associated with the first API as claimed. We reach this conclusion despite
the Specification not defining the term “client libraries,” unlike other terms
whose concrete definitions leave no doubt as to their meaning. See, e.g.,
Appeal 2020-006393
Application 15/641,835
Patent 9,077,773 B2

9
’773 patent col. 3, ll. 24–35 (defining “one embodiment” or “an
embodiment” explicitly); see also id. col. 16, ll. 55–65 (defining “machine-
readable (storage) medium” explicitly); col. 17, ll. 25–43 (defining various
other terms explicitly).
The Specification does, however, note that the disclosed cloud API
hub automatically generates libraries in multiple languages providing for
universal or near-universal access to the API. ’773 patent, col. 4, ll. 20–22.
By automatically generating these libraries, which can include Bash, Ruby,
Python, PHP, Node.js, C#, Java, and Objective-C, the hub allows users to
consume APIs from any kind of source API server. See id. col. 4, ll. 22–26;
col. 15, ll. 35–38.
Although this discussion informs our understanding of the recited
“client libraries,” the term is not so limited. According to a special-purpose
dictionary, the term “library” is defined as “[a] collection of commonly used
routines that may be called from within newly written programs to save
having to write them again.” Penguin Computing Dictionary 248. That
dictionary adds that “[l]ibrary routines kept in source code form may be
incorporated into a new program using an include statement that makes a
compiler treat library code as if it were part of the new source file.” Id.
Another computer dictionary defines the term “library” as “a set of
precompiled routines that may be linked with a program at compile time or
loaded at load time or dynamically at run time.” Laplante Computer
Dictionary 276.
Given this understanding of what a library means in the art, and
considered in light of the Specification, we construe the recited “client
Appeal 2020-006393
Application 15/641,835
Patent 9,077,773 B2

10
libraries” as a set of source-code routines that can be called from, and
incorporated into, a computer program, where the routines are associated
with a client. Accord Appeal Br. 7–8 (noting that client libraries are not
applications, but rather code chunks that must be implemented within the
scope of a greater application to provide functionality).
With this construction, we find the Examiner’s mapping the recited
client libraries to Farah’s bundle of applications and add-ons in paragraph 59
(see Ans. 12, 22) problematic. On this record, we cannot say—nor has the
Examiner shown—that this bundle necessarily includes source-code routines
that can be called from, and incorporated into, a computer program
consistent with the commonly-understood meaning of the term “library” in
the art considered in light of the Specification. And even if Farah’s bundles
of applications and add-ons in paragraph 59 could somehow be considered
“client libraries”—which they are not—the Examiner has still not shown
these purported bundle-based libraries are necessarily generated
automatically based on (1) user-generated parameters, and (2) a standard
description format, both of which are associated with the first API as
claimed.
That the Examiner also equates undisclosed APIs in Farah with the
recited client libraries (see Ans. 12) only further undermines the propriety of
the Examiner’s anticipation rejection. Not only is Farah silent regarding
APIs, the Examiner’s mapping effectively conflates the recited APIs with
the recited client libraries—elements that are claimed separately. Accord
Reply Br. 2 (noting this distinction). It is well settled that where, as here, a
claim requires two separate elements, namely APIs and client libraries, one
Appeal 2020-006393
Application 15/641,835
Patent 9,077,773 B2

11
element construed as having two separate functions will not suffice to meet
the claim’s terms. See Lantech, Inc. v. Keip Mach. Co., 32 F.3d 542, 547
(Fed. Cir. 1994); see also In re Robertson, 169 F.3d 743, 745 (Fed. Cir.
1999) (claims requiring three separate means not anticipated by structure
containing only two means using one element twice).
Therefore, we are persuaded that the Examiner erred in rejecting
independent claim 28.

THE OBVIOUSNESS REJECTIONS
Because the Examiner has not shown that the additional cited prior art
cures Farah’s foregoing deficiencies regarding the rejection of independent
claim 28, we do not sustain the obviousness rejection of (1) independent
claims 1, 17, 27, 29, 30, and 72 that recite commensurate API and library
limitations; and (2) independent claim 47 that recites commensurate API
limitations. See Final Act. 7–26. We also do not sustain the rejections of
dependent claims 2–12, 14–16, 18–26, 31, 32, 34–41, 43–46, 48–71, and
73–79 for similar reasons. Because this issue is dispositive in resolving this
appeal, we need not address Appellant’s other associated arguments.

CONCLUSION
In summary:
Claims
Rejected
35 U.S.C.
§
Reference(s)
/Basis
Affirmed Reversed
28 102(e) Farah 28
1–10, 12,
14–19,
21–27,
29–32,
103 Farah,
Brinskelle
1–10, 12,
14–19, 21–
27, 29–32,
Appeal 2020-006393
Application 15/641,835
Patent 9,077,773 B2

12
34–39,
41, 43–
79
34–39, 41,
43–79
11, 20,
40
Farah,
Brinskelle,
Michels
11, 20, 40
Overall
Outcome
1–12, 14–
32, 34–41,
43–79

REVERSED