Hewlett Packard Enterprise Development LP

Patent Trials and Appeals Board

Mar 2, 2022

2021000686 (P.T.A.B. Mar. 2, 2022)

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/188,312 06/21/2016 Chiu Wai Tsang 90190333 9780 146568 7590 03/02/2022 MICRO FOCUS LLC 500 Westover Drive #12603 Sanford, NC 27330 EXAMINER KHANAL, SANDARVA ART UNIT PAPER NUMBER 2453 NOTIFICATION DATE DELIVERY MODE 03/02/2022 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): software.ip.mail@microfocus.com PTOL-90A (Rev. 04/07) UNITED STATES PATENT AND TRADEMARK OFFICE BEFORE THE PATENT TRIAL AND APPEAL BOARD Ex parte CHIU WAI TSANG and CHRISTOPHER JOHNSON Appeal 2021-000686 Application 15/188,312 Technology Center 2400 Before MINN CHUNG, CHRISTA P. ZADO, and PHILLIP A. BENNETT, Administrative Patent Judges. BENNETT, Administrative Patent Judge. DECISION ON APPEAL STATEMENT OF THE CASE Pursuant to 35 U.S.C. § 134(a), Appellant1 appeals from the Examiner’s decision to reject claims 1, 4-6, 11, 13-15, 18, 19, and 21-30. Claims 2, 3, 7-10, 12, 16, 17, and 20 are cancelled. We have jurisdiction under 35 U.S.C. § 6(b). We reverse. 1 “Appellant” refers to “applicant” as defined in 37 C.F.R. § 1.42(a). Appellant identifies the real party in interest as Micro Focus LLC. Appeal Br. 1. Appeal 2021-000686 Application 15/188,312 2 CLAIMED SUBJECT MATTER Appellant’s Specification discloses: Examples described herein may allow for horizontal scaling and sharding (e.g., partitioning) of a database amongst nodes within a multi-node cluster via a clustering layer that is agnostic to database structure and minimizes or avoids altogether modifications to the database and existing application layers such as the data access object layer, service layer, and API layer. Spec. ¶ 15. Claim 1, reproduced below, is illustrative of the claimed subject matter: 1. A first node for a multi-node cluster, comprising: a processing resource; a non-transitory machine-readable storage medium comprising instructions executable by the processing resource to: receive, at an application programming interface (API) layer, an API call from a client to access a database resource; intercept the API call from the API layer at a clustering layer between the API layer and a service layer; determine, at the clustering layer, whether the database resource of the API call is located in the first node or in a second node of the multi-node cluster; discover, at the clustering layer, whether a number of nodes of the multi-node cluster has changed; and based on discovering that the number of the nodes of the multi-node cluster has changed, issue, at the clustering layer, further API calls for sharding of a database including moving database resources between the nodes of the multi-node cluster, the further API calls comprising: a first further API call that when issued by the clustering layer to an API layer of the second node causes retrieval of the database resources from the second node, and Appeal 2021-000686 Application 15/188,312 3 a second further API call that when issued by the clustering layer to an API layer of a third node of the multi-node cluster causes creation of the database resources at the third node. Appeal Br. (Claims Appendix i). REFERENCES2 The Examiner relies on these references: Name Reference Date Hickman US 6,523,036 B1 Feb. 18, 2003 Kulesza US 10,216,770 B1 Feb. 26, 2019 Ransil US 2007/0168336 A1 July 19, 2007 Surtani US 2012/0246202 A1 Sept. 27, 2012 REJECTIONS Claims 1, 4-6, 11, 13-15, 18, 19, 22, 24, 26, and 28-30 stand rejected under 35 U.S.C. § 103 as being unpatentable over Surtani and Kulesza. Final Act. 4. Claims 21 and 25 stand rejected under 35 U.S.C. § 103 as being as being unpatentable over Surtani, Kulesza, and Hickman. Final Act. 23. Claims 23 and 27 stand rejected under 35 U.S.C. § 103 as being as being unpatentable over Surtani, Kulesza, and Ransil. Final Act. 25. ISSUE Has the Examiner erred in determining that the leader node described in Kulesza teaches, suggests, or otherwise renders obvious the limitation “issue, at the clustering layer, further API calls for sharding of a database 2 Citations to the references are to the first named inventor/author only. Appeal 2021-000686 Application 15/188,312 4 including moving database resources between the nodes of the multi-node cluster,” as recited in claim 1? ANALYSIS The Examiner rejects claim 1 as obvious over the combined teachings of Surtani and Kulesza. Final Act. 4. Relevant to the issue raised by Appellant, the Examiner finds that Kulesza’s leader node 410, depicted in and described in connection with Figure 4, teaches a “clustering layer” and its associated API calls, as recited in claim 1. Final Act. 6-7. Specifically, the Examiner finds that Kulesza’s description of the leader node detecting a scaling event and directing data transfer of locally stored data to other computer nodes teaches “issue, at the clustering layer, further API calls for sharding of a database including moving database resources between the nodes of the multinode cluster.” Final Act. 7 (citing Kulesza col. 12, ll. 12- 13, col. 12, ll. 38-42, col. 6, ll. 48-56). The Examiner explains: [S]ince distributed data warehouse systems support API for a variety of database operations such as creating a database, clearing, and/or other operations (see col. 6: lines 48-56)), it is evident that the instructions and request sent to current compute nodes for 20 and additional compute nodes for 30 are API calls. Final Act. 3. Appellant’s argument is relatively simple. Appellant argues nothing in Kulesza indicates that the operations carried out by the leader node 410 are initiated via API call as required by claim 1. Appellant argues the portion of Kulesza cited to show API calls does not relate to the leader node, but instead relates to client interactions. Appeal Br. 8-9 (“However, this API appears to be how a client interacts with a data warehouse cluster.”). Appellant asserts the leader node “is not the client of Kulesza that uses an Appeal 2021-000686 Application 15/188,312 5 API” and that “[t]here is no evidence that the leader node of Kulesza issues any API calls.” Appeal Br. 9. We are persuaded of reversible Examiner error. Kulesza relates to distributed database systems wherein “scaling clusters may be performed while maintaining access to the State in the state for cluster.” Kulesza col. 2, ll. 34-36. Kulesza teaches that “the distributed data warehouse systems . . . may support a standard or custom application programming interface (API) for a variety of database operations.” Kulesza col. 6, ll. 48-52. Kulesza describes these supported database operations as including “creating a database, creating a table, altering a table, creating a user, dropping a user, inserting one or more roes any table, copying values, selecting data from within a table (e.g., querying a table), canceling or aborting a query, and/or other operations.” Kulesza col. 6, ll. 52-56. Kulesza further teaches that “clients . . . may communicate with a data warehouse cluster via a desktop computer, laptop computer, . . . , or any other computing system,” and that “[a]pplication programming interfaces (APIs) may be implemented to provide standardized message formats for clients, such as for when clients are communicating with distributed data warehouse service manager.” Kulesza col. 8, ll. 6-25. Appellant does not appear to meaningfully challenge that Kulesza’s leader node performs the operations of the recited clustering layer. Instead, Appellant’s challenge focuses on the issue of whether the leader node carries out those operations via API calls. Kulesza’s description of the functionality of the leader node does not indicate with any specificity how the operations requested and/or performed by the leader node are communicated within the system. For example, Kulesza indicates: Appeal 2021-000686 Application 15/188,312 6 [E]ach of the computer nodes in a distributed data warehouse cluster may implement a set of processes running on the node server’s (or other computing device’s) operating system that manage communication with the leader node, for example, to receive commands, send back data, and route compiled code to individual query processes . . . in order to execute a given query. Kulesza col. 11, ll. 36-42. Although Kulesza describes internode communication between the leader node and various other nodes, Kulesza does not indicate that commands are issued and received via API. The portions of Kulesza cited by the Examiner do not lend any additional support for the Examiner’s finding that the leader node transacts via API. Kulesza states that the leader node “may also be receiving queries for select data from a client” and that the “leader node may send various instructions and requests to service the queries to current compute node(s) and additional compute node(s) according to the monotone distribution scheme.” Kulesza col. 12, ll. 24-28. The Examiner explains that “[b]ased on broadest reasonable interpretation, the limitation ‘an API call’ is interpreted to mean any calls or requests that is made/issued to an application so that the application performs the requested operation, function, or routine.” Ans. 8 (emphasis omitted). The Examiner supports this interpretation by citing the description of API calls set forth in Appellant’s Specification. Ans. 8 (citing Spec. ¶¶ 25, 28). The Examiner emphasizes that the Specification states “an API call may represent a requested operation, function, or routine to be performed by an application.” Ans. 8 (quoting Spec. ¶ 25). However, the Examiner omits a portion of Appellant’s description of an API call. Specifically, the sentence highlighted by the Examiner further describes an API call as being “implemented by the multi-node cluster and Appeal 2021-000686 Application 15/188,312 7 that is recognized by the API layer of the application.” Spec. ¶ 25. This additional description indicates that an API call is recognized at the API layer, and is not a command issued at a different layer within the application protocol. Moreover, Examiner’s interpretation is unreasonably broad because it ignores this additional context provided by the specification. See In re Smith Int’l, Inc., 871 F.3d 1375, 1382-83 (Fed. Cir. 2017) (internal citations omitted) (“The correct inquiry in giving a claim term its broadest reasonable interpretation in light of the specification is . . . an interpretation that corresponds with what and how the inventor describes his invention in the specification, i.e., an interpretation that is ‘consistent with the specification.’”). Under the Examiner’s unreasonably broad interpretation, any command issued to an application, including one issued directly to the application without any connection to an API layer or even any external interface, is encompassed within the Examiner’s interpretation. See In re NTP, Inc., 654 F.3d 1279, 1288 (Fed. Cir. 2011) (“While the Board must give the terms their broadest reasonable construction, the construction cannot be divorced from the specification and the record evidence.”). Kulesza does not provide any clear indication that the leader node communicates with other nodes via API calls. Rather, to the extent any detail is provided regarding the operation of the leader node, Kulesza provides that a monotone distribution scheme is used to facilitate service requests. However, the Examiner does not provide any reasoning, other than the unreasonably broad interpretation of the limitation “an API call” discussed above, for why a person of ordinary skill in the art would have understood the monotone distribution scheme used by Kulesza as one in which database operations are implemented via API calls. Without Appeal 2021-000686 Application 15/188,312 8 explanation or reasoning to show why a person of skill in the art would have possessed such an understanding, we are constrained by the record before us to reverse the rejection of claim 1. Remaining Claims The disputed limitation discussed above is recited in each of the independent claims. As such, we do not sustain the rejection of independent claims 14 and 18 for the reasons discussed above with respect to claim 1. The remaining claims are dependent and stand with their respective independent claims. CONCLUSION We reverse the Examiner’s decision to reject the claims. DECISION SUMMARY Claims Rejected 35 U.S.C. § Reference(s)/Basis Affirmed Reversed 1, 4-6, 11, 13-15, 18, 19, 22, 24, 26, 28-30 103 Surtani, Kulesza 1, 4-6, 11, 13-15, 18, 19, 22, 24, 26, 28-30 21, 25 103 Surtani, Kulesza, Hickman 21, 25 23, 27 103 Surtani, Kulesza, Ransil 23, 27 Overall Outcome 1, 4-6, 11, 13-15, 18, 19, 21-30 REVERSED