Microsoft Technology Licensing, LLCDownload PDFPatent Trials and Appeals BoardJun 9, 20212020000357 (P.T.A.B. Jun. 9, 2021) Copy Citation 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. 14/815,799 07/31/2015 Eddie W.M. Fong MS1-6241US 7714 143198 7590 06/09/2021 MICHAEL BEST & FRIEDRICH LLP (MS) 790 N WATER ST SUITE 2500 MILWAUKEE, WI 53202 EXAMINER WANG, HANNAH S ART UNIT PAPER NUMBER 2454 NOTIFICATION DATE DELIVERY MODE 06/09/2021 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): mkeipdocket@michaelbest.com PTOL-90A (Rev. 04/07) UNITED STATES PATENT AND TRADEMARK OFFICE ________________ BEFORE THE PATENT TRIAL AND APPEAL BOARD ________________ Ex parte EDDIE W. M. FONG, NAGARAJU PALLA, RICARDO SOARES STERN, RAJMOHAN RAJAGOPALAN, BHAVIN J. SHAH, NARENDRA BABU ALAGIRISWAMY, KARAN SINGH REKHI, and PARIKSHIT PATIDAR ________________ Appeal 2020-000357 Application 14/815,799 Technology Center 2400 ________________ Before BRADLEY W. BAUMEISTER, MICHAEL J. STRAUSS, and JEREMY J. CURCURI, Administrative Patent Judges. BAUMEISTER, Administrative Patent Judge. DECISION ON APPEAL Appellant appeals under 35 U.S.C. § 134(a) from the Examiner’s final rejection of claims 1–7, 9–13, and 15–19, which constitute all of the pending claims.1 Appeal Br. 7–11.2 We have jurisdiction under 35 U.S.C. § 6(b). We reverse. 1 Appellant identifies the real party in interest as Microsoft Technology Licensing, LLC. Appeal Brief 2, filed July 18, 2019 (“Appeal Br.”). 2 Rather than repeat the Examiner’s positions and Appellant’s arguments in their entirety, we refer to the above mentioned Appeal Brief, as well as the following documents for their respective details: the Final Action mailed January 25, 2019 (“Final Act.”); the Examiner’s Answer mailed August 16, 2019 (“Ans.”); and the Reply Brief filed October 16, 2019 (“Reply Br.”). Appeal 2020-000357 Application 14/815,799 2 CLAIMED SUBJECT MATTER Appellant describes the present invention as follows: Technologies are described herein for changelog transformation and correlation in a multi-tenant cloud service. Components within the multi-tenant cloud service generate changelogs that describe changes made to hardware or software components within the multi-tenant cloud service. The changelogs are received and transformed from different schemas into a common schema. A central change management service (“CCMS”) exposes a network service application programming interface (“API”), or other type of interface, through which other network services can obtain the changelogs that have been transformed into the common schema. For example, services can obtain changelogs in order to correlate changes to anomalies or other events taking place in the multi-tenant cloud service, to identify upstream or downstream components that might be impacted by a change, to provide a user interface for viewing the changelogs, the correlation, or the potential impact of a change, and/or to perform other types of functions. Abstract. Independent claim 1, reproduced below with disputed language emphasized, illustrates the appealed claims: 1. A computer-implemented method for central management of changelogs corresponding to changes to components in a multi-tenant cloud service, the method comprising: obtaining, with a computer, changelogs from a plurality of services executing in the multi-tenant cloud service, the changelogs describing changes to the software or hardware of components in the multi-tenant cloud service and the changelogs being expressed using a plurality of schemas; transforming, with the computer, the changelogs expressed using the plurality of schemas to a plurality of changelogs expressed using a common schema, wherein each of the plurality of changelogs expressed using the common schema Appeal 2020-000357 Application 14/815,799 3 describes changes to a component in the multi-tenant cloud service; exposing, with the computer, a network service application programming interface (API) for accessing the plurality of changelogs expressed using the common schema; receiving, from a service executing in the multi-tenant cloud service, a call through the network service API for a set of changelogs included in the plurality of changelogs expressed using the common schema, the set of changelogs requested via the call describing changes to the components in the multi-tenant cloud service associated with a single tenant; and responding to the call by accessing mapping data describing relationships between the components and a plurality of tenants of the multi-tenant cloud service to determine a set of components in the multi-tenant cloud service servicing the single tenant, searching, based on the mapping data, the plurality of changelogs expressed using the common schema to identify changelogs associated with the set of components in the multi-tenant cloud service determined using the mapping data to be servicing the single tenant, and returning the changelogs identified from the plurality of changelogs associated with the set of components in the multi-tenant cloud service servicing the single tenant in response to the call. STATEMENT OF THE REJECTIONS Claims 1, 4, 9, 10, 15, and 16 stand rejected under 35 U.S.C. § 103 as being unpatentable over Harishankar (US 2016/0056993 A1; published Feb. 25, 2016), Chari (US 2015/0242486 A1; published Aug. 27, 2015), and Kumar (US 2013/0179560 A1; published July 11, 2013). Final Act. 7–27. Appeal 2020-000357 Application 14/815,799 4 Claim 2 stands rejected under 35 U.S.C. § 103 as being unpatentable over Harishankar, Chari, Kumar, and Maclinovsky (US 2011/0078411 A1; published Mar. 31, 2011). Final Act. 27–28. Claim 3 stands rejected under 35 U.S.C. § 103 as being unpatentable over Harishankar, Chari, Kumar, and Yoon (US 2007/0088764 A1; published Apr. 19, 2007). Final Act. 28–29. Claims 5–7, 11–13, and 17–19 stand rejected under 35 U.S.C. § 103 as being unpatentable over Harishankar, Chari, Kumar, and Duyanovich (US 2008/0195369 A1; published Aug. 14, 2008). Final Act. 29–33. STANDARD OF REVIEW The Board conducts a limited de novo review of the appealed rejection for error based upon the issues identified by Appellant, and in light of the arguments and evidence produced thereon. Ex parte Frye, 94 USPQ2d 1072, 1075 (BPAI 2010) (precedential). DETERMINATIONS AND CONTENTIONS The Examiner finds that Harishankar’s tenant-specific log is generated in compliance with a MetaModel describing the hardware and software resources of the tenant’s cloud-based service. Final Act. 9 (citing Harishankar, Abstract, ¶¶ 45–46). Based on this teaching, the Examiner finds that Harishankar discloses “[returning] changelogs associated with the set of components in the multi-tenant cloud service determined using the mapping data to be servicing the single tenant,” as recited. Id. The Examiner finds that the MetaModel in Harishankar is used to generate the tenant-specific log because Harishankar teaches applying a Appeal 2020-000357 Application 14/815,799 5 particular tenant’s MetaModel to identify the hardware or software resources providing the tenant’s cloud-based service and to enable the monitoring of those resources. Final Act. 9 (citing Harishankar ¶ 45). The Examiner further finds that Harishankar teaches, for every tenant hosted by the cloud, logs from resources in cloud resource pools are pushed from the resource to a corresponding tenant-specific log. Id. at 10 (citing Harishankar ¶ 41). The Examiner acknowledges that Harishankar does not explicitly teach generating all resource logs and then searching for tenant-specific logs. Final Act. 6, 10. However, the Examiner posits that a common repository of logs is generated by the resource pools (id. at 4; Ans. 4), and the Examiner reasons that a search of all these resource logs is implied by the very nature of selecting certain logs for retrieval from the resource pools: The resource logs from the resource pools 216 are for multiple tenants in the multi-tenant cloud service. Given the broadest reasonable interpretation, the selecting process of resource logs from the resource pool 216 in order to output to tenant-specific log 226 for each tenant implies the “searching” of logs in order to generate tenant-specific logs in 226 for a single tenant of multiple cloud tenants. Final Act. 10 (citing Harishankar Figure 2, ¶¶ 40–41). To reinforce Harishankar’s implied teachings, the Examiner additionally relies on Chari, which expressly teaches searching a set of logs in order to select logs of a particular user. Final Act. 11 (citing Chari ¶¶ 26, 82–85); Ans. 6. The Examiner further determines that motivation existed to combine the references. Final Act. 11–12. The Examiner further relies on Kumar for teaching the step of providing change logs in a common format. Final Act. 18–19 (citing Kumar Appeal 2020-000357 Application 14/815,799 6 ¶¶ 19–20, 25, 34–35). The Examiner determines that motivation exists to further combine the references. Final Act. 19 (citing Kumar ¶¶ 11, 34). The Examiner further reasons that the tenant-specific log is generated in response to a “call” because Harishankar teaches that a log collection for a particular tenant is enabled when a cloud administrator initially configures the MetaModel for the tenant’s cloud-based service. Final Act. 8 (citing Harishankar ¶ 40). Appellant argues, inter alia, that the MetaModel in Harishankar is not used to search a common repository of logs as posited by the Examiner, or even to perform any search at all. Appeal Br. 9. Instead, Appellant contends that Harishankar automatically establishes and maintains a tenant- specific log for each individual tenant. Id. The MetaModel, according to Appellant, is used to determine what individual tenant logs to automatically “push” a particular resource log to when a resource log is received for a resource as part of creating and maintaining the tenant-specific log. Id. Appellant further argues that Chari fails to remedy these deficiencies. Appeal Br. 10. More specifically, Appellant argues that Chari teaches searching data in logs to identify user access patterns, but does not disclose searching logs using resource-to-tenant mapping data to identify resource logs relevant to a particular tenant of a cloud service. Id. at 10; Reply Br. 3. According to Appellant, the combination of Harishankar and Chari would merely disclose (1) generating individual tenant-specific logs, as taught by Harishankar, and (2) analyzing the generated tenant-specific logs to identify patterns. Final Act 10; Reply Br. 3. Kumar, according to Appellant, is silent with respect to accessing tenant-specific using mapping data and thus also fails to cure the deficiencies of Harishankar. Id. at 11. Appeal 2020-000357 Application 14/815,799 7 Appellant argues, inter alia, that even assuming solely for the sake of argument that Harishankar teaches searching a common repository of logs using the MetaModel, such searching is only performed to create and maintain the tenant-specific log, but is not performed in response to any type of received request or “call,” as claimed. Reply Br. 2–3. According to Appellant, the “pull” approach of the claimed invention is in direct contrast to the automatic log maintenance of Harishankar, and the presently claimed invention desirably eliminates duplication of logs by only producing a tenant-specific log when it is requested. Id. ANALYSIS Even accepting for the sake of argument the Examiner’s position that an implied search is performed in Harishankar to create the tenant-specific log, the Examiner has not established that the search is in response to a request for the log. We understand that Harishankar could conceivably be interpreted as performing an implied search of one domain comprising the resource pools to select certain resource logs based on a MetaModel- compliant protocol. But even under such an interpretation, searching is not performed specifically in response to a call being made. Rather, the protocol or “push” architecture of Harishankar dictates performing the protocol on a continuing basis prior to any request being made. Furthermore, Chari does not remedy the deficiencies of Harishankar because Chari does not disclose using a MetaModel, or other similar mapping information, to search and “pull” logs upon request. For the foregoing reasons, Appellant persuades us of error in the Examiner’s obviousness rejection of claim 1. We, therefore, reverse the Appeal 2020-000357 Application 14/815,799 8 rejection of this claim and of claims 4, 9, 10, 15, and 16, which either depend from claim 1 or otherwise recite similar claim language. See Appeal Br. 15–16, 17–18. With respect to the remaining rejections of dependent claims 2, 3, 5– 7, 11–13, and 17–19, the Examiner does not rely on any of the additionally cited references to cure the deficiency of the obviousness rejection of claim 1, explained above. Final Act. 27–33. We, therefore, reverse these obviousness rejections for the reasons set forth in relation to claim 1. DECISION SUMMARY In summary: REVERSED Claim(s) Rejected 35 U.S.C. § Reference(s)/ Basis Affirmed Reversed 1, 4, 9, 10, 15, 16 103 Harishankar, Chari, Kumar 1, 4, 9, 10, 15, 16 2 103 Harishankar, Chari, Kumar, Maclinovsky 2 3 103 Harishankar, Chari, Kumar, Yoon 3 5–7, 11–13, 17–19 103 Harishankar, Chari, Kumar, Duyanovich 5–7, 11– 13, 17–19 Overall Outcome 1–7, 9–13, 15–19 Copy with citationCopy as parenthetical citation