Microsoft Technology Licensing, LLC

Patent Trials and Appeals Board

Jun 9, 2021

2020000357 (P.T.A.B. Jun. 9, 2021)

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