KONG INC

Patent Trials and Appeals BoardNov 12, 2020

2020006393 (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