VMware, Inc.

Patent Trials and Appeals Board

Dec 17, 2020

2020000566 (P.T.A.B. Dec. 17, 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/195,728 06/28/2016 Avetik Hovhannisyan D025 8226
152606 7590 12/17/2020
Olympic Patent Works PLLC
4979 Admiral Street
Gig Harbor, WA 98332
EXAMINER
RECEK, JASON D
ART UNIT PAPER NUMBER
2458
MAIL DATE DELIVERY MODE
12/17/2020 PAPER
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.
PTOL-90A (Rev. 04/07)

UNITED STATES PATENT AND TRADEMARK OFFICE
BEFORE THE PATENT TRIAL AND APPEAL BOARD
Ex parte AVETIK HOVHANNISYAN,
ASHOT NSHAN HARUTYUNYAN, NAIRA MOVSES GRIGORYAN,
and ARNAK POGHOSYAN
Appeal 2020-000566
Application 15/195,728
Technology Center 2400
Before JAMESON LEE, JONI Y. CHANG, and
MICHAEL R. ZECHER, Administrative Patent Judges.

LEE, Administrative Patent Judge.
DECISION ON APPEAL
STATEMENT OF THE CASE
Pursuant to 35 U.S.C. § 134(a), Appellant1 appeals from the rejection
of claims 1–20. Appeal. Br. 2. The rejection of claims 3–10, 14–17, and 20
as drawn to patent-ineligible subject matter under 35 U.S.C. § 101 has been
withdrawn. Ans. 3. All claims, however, still remain subject to at least one
ground of rejection. Id. 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
VMWARE, INC. Appeal Br. 1.
Appeal 2020-000566
Application 15/195,728

2
APPLICATION SUBJECT MATTER
The Application is titled “Method and Subsystem that Collects,
Stores, and Monitors Population Metric Data within a Computer System.”
The Specification states that the described invention is directed to “methods
and subsystems for collecting and storing population metrics for types and
classes of components.” Spec. ¶ 1. According to the Specification, the
collection, storage, and processing of large volumes of metric data generated
by internal automated monitoring, administration, and management
subsystems within a modern distributed computing system on a daily or
weekly basis is rapidly becoming a computational bottleneck. Id. ¶ 2. The
Specification summarizes the invention as, in one embodiment, having a
graph-like representation of the configuration and state of a computer system
including “aggregation nodes that collect metric data for a set of multiple
object nodes and that collect metric data that represents the members of the
set over a monitoring time interval.” Id. ¶ 3. Independent claims are claims
1, 12, and 19. Claims 1 and 12 are reproduced below:
1. A state-information-storage subsystem within a
computer system that includes one or more processors, one or
more memories, and one or more data-storage devices, the
state-information-storage subsystem comprising:
current state information, including object entities
associated with metrics and aggregation entities associated with
population metrics, that is maintained within a combination of
one or more memories and one or more data-storage devices;
and
a state-information-storage subsystem control component
that maintains the current state information and that adds data
points to population metrics associated with aggregation
entities.
Appeal 2020-000566
Application 15/195,728

3
12. A method that stores and maintains state
information with respect to a computer system, within the
computer system, the method carried out within the computer
system that includes one or more processors, one or more
memories, and one or more data-storage devices, the method
comprising:
representing, as object entities, components of the
computer system with respect to which metric-data-point-
generating events are associated;
representing an aggregation of two or more object
entities as an aggregation entity; associating a population metric
with the aggregation entity;
storing the object entities and aggregation entity as state
information in one or more memories and/or data-storage
devices; and
when a metric-data-point-generating event occurs with
respect to an object of the aggregation,
when the metric for which the metric-data-
point-generating event generated a data point is the
population metric associated with the aggregation
entity,
adding the data-point generated by the
data-point-generating event to the
population-metric.
Claim 19 recites computer instructions that, when executed, instruct a
computer system to store and maintain state information by actions the same
as the steps recited in claim 12.
REFERENCES
Name Reference Date
Cox US 5,535,335 July 9, 1996
McMurry US 2015/0142940 A1 May 21, 2015

Appeal 2020-000566
Application 15/195,728

4
REJECTIONS
A. Claims 1–20 were finally rejected under 35 U.S.C. § 101 as
drawn to patent ineligible subject matter. Final Act. 7–8. The Examiner
subsequently withdrew this ground of rejection only as to claims 3–10, 14–
17, and 20. Ans. 3. The Examiner mistakenly states this ground as
remaining just for claims 1, 2, 11–13, and 19. Id. It remains for claim 18 as
well. Id.
B. Claims 1–20 were finally rejected under 35 U.S.C. § 103 as
obvious over McMurray and Cox. Final Act. 8–12. The Examiner
mistakenly states this ground as remaining just for claims 1 and 3–20. Ans.
3. It remains for claim 2 as well. Id.
OPINION
A. Claim Construction
1. “object entity,” “aggregation entity,”
“metrics,” “population metrics”
The claims use terms that, on this record, do not have a plain or well-
established meaning in the art, i.e., “object entity,” “aggregation entity,”
“metrics,” and “population metrics.” We discuss the meaning of these terms
in the context of the Specification.
Regarding “metrics,” the Specification describes as follows:
In a complex system, various types of information are
collected with regard to the operational states and statuses of
many, if not all, components, subcomponents, systems, and
subsystems. The information can be encoded in many different
ways, can be expressed in many different forms, and can be
provided by a number of different information sources. For
example, metrics may be provided by various types of
monitoring applications and monitoring hardware within a
computer system. As another example, metrics may be obtained
Appeal 2020-000566
Application 15/195,728

5
from log files that store various types of log messages and error
messages generated by computer-system components. However,
for purposes of the current discussion, this information can be
described as a set of time-stamped or time-associated floating-
point numbers. Clearly, even for descriptive textual information,
there is generally a finite number of different values or forms of
the information, as a result of which any such information can be
mapped to numerical values. Thus, no generality is lost by
considering the information from various types of monitoring
and diagnostic agents and subsystems within the system to be
floating-point values, also referred to as “metric values” and
“metric data.”
Spec. ¶ 52. Based on this disclosure in the Specification, we read “metrics”
or “metric” as meaning information with regard to the operational states
and statuses of one or more components, subcomponents, systems, and
subsystems. It can be mapped to a set of time-stamped floating-point values.
We see no meaningful distinction between “metrics” and “metric” in the
context of the Specification. The two appear to be used in the Specification
interchangeably. Neither the Examiner nor the Appellant has articulated a
difference.
Outside of the claims, the Specification does not use the term “object
entity,” except as a part of a bigger term “object-entity-aggregation method,”
which is used to describe what is shown in Figures 17 and 18. Spec. ¶ 20.
Instead, the Specification consistently uses the term “object node”
throughout. For instance, the Specification describes: “Figure 13 illustrates
a configuration-management database (“CMDB”). A CMDB is logically
organized as a graph in which various components and subsystems of the
computer system are represented by object nodes. The object nodes may be
associated with metrics and properties and are linked together via
Appeal 2020-000566
Application 15/195,728

6
relationship nodes.” Id. ¶ 54. Figure 13, illustrating a CMDB in graph
form, is reproduced below:

Figure 13 shows “a small portion of the logical organization of a
CMDB representing a current state of a computer system.” Id. In this
context, “object node” and “object entity” essentially mean the same, with
the difference being formalistic, i.e., if the logical organization is depicted in
the form of a tree-like graph, then the term “object node” is appropriate to
refer to a system, component of a system, or subsystem. But the
Specification indicates that the state of a computer system need not be
depicted in the form of a CMDB graph. Spec. ¶ 57.
Thus, the term “object entity” refers to a system, component of a
system, or subsystem, regardless of whether overall logical organization is
shown as a tree-like graph. In the specific example where the logical
organization is depicted as a tree-like graph, “objective entity” can be
referred to as an “objective node.” Based on our review of the record before
us, this construction is not inconsistent with any position taken by the
Appeal 2020-000566
Application 15/195,728

7
Examiner or Appellant, neither of whom articulated a meaningful distinction
between “object node” and “object entity.” For instance, Appellant has not
argued that the prior art shows object nodes but not object entities.
Similarly, outside of the claims, the Specification refers to
“aggregation node” and not “aggregation entity.” The Specification states:
“As shown in Figure 17, using the CMDB-like graph-like representation of a
portion of the configuration and state information for the multi-processor-
based system, a new type of node, referred to as an ‘aggregation node,’ has
been added to the logical representation.” Id. ¶ 65. Thus, “aggregation
node” is a special case of “aggregation entity” where the logical organization
of a computer system is depicted in the form of a tree-like graph.
“Aggregation entity,” on the other hand, is a more general term that applies,
regardless of whether the logical organization of a computer system is
depicted in the form of a tree-like graph. The two terms essentially have the
same substantive meaning. The Examiner has not articulated any distinction
between the two terms, and Appellant asserts the two terms, in the context of
the Specification, are used interchangeably. Appeal Br. 33. We focus on the
Specification’s description of “aggregation node.” Figure 17 is reproduced
below:
Appeal 2020-000566
Application 15/195,728

8

Figure 17 illustrates “an object-entity-aggregation method.” Id. ¶ 20.
The Specification states:
A first aggregation node 1702 represents all the backend-server
application components 1704–1714. A second aggregation node
1706 represents the request-processing application components
1718–1722. A third aggregation node 1724 represents all of the
application components of the type r 1726–1727 and a final
aggregation node 1730 represents the database-server
application components 1732–1733. An aggregation node is a
meta-level node that represents multiple object nodes. In Figure
17, an aggregation node represents all of the object nodes of a
particular type but, in alternative implementations, an
aggregation node may represent a subset of the nodes of a
particular type. Aggregation nodes allow certain of the metrics
associated with particular types of object nodes to be
accumulated within a single metric container associated with the
aggregation node, rather than individual metric containers
associated with the object nodes of the type represented by the
aggregation node. In other words, the metric data collected by
Appeal 2020-000566
Application 15/195,728

9
metric entities associated with aggregation nodes is population
data generated by multiple object nodes, rather than data
generated by a single individual node. Aggregation nodes can
therefore be used to collect, process, and analyze population data
for types and classes of application components, even though
individual application components may have relatively short
lifetimes with respect to the overall lifetime of a distributed
application and even though application-component nodes may
be highly distributed and mobile.
Id. ¶ 65 (emphases added).
A clearer illustration of aggregation nodes is provided in Figure 18,
reproduced below:

Figure 18 is a more detailed illustration of the object-entity-aggregation
method. Id. ¶ 20. The Specification explains that object node 1804 is a
member of aggregation node 1802, and object node refers to metric table
1812 containing entries for metrics associated with the type of object nodes
to which object node 1804 belongs. Id. ¶ 66. Each entry in the table is an
Appeal 2020-000566
Application 15/195,728

10
indication of the metric, as well as a reference to the aggregation node, for
any of the metrics that are currently being aggregated for that type of object
node, and thus “the metrics represented by entries 1814 and 1816 are both
population metrics accumulated within metric entities associated with
aggregation node 1802.” Id.
Paragraph 65 of the Specification explains that, although there were
problems with prior art systems in collecting metric data for application
components of modern, highly dynamic and mobile distributed applications,
the inventor’s use of an “object-entity-aggregation method” based on
introduction of a new type of node, an “aggregation node” as shown in
Figure 17, addresses those problems. Id. ¶ 65. It is further explained that
aggregation nodes allow metrics associated with particular types of object
nodes “to be accumulated within a single metric container associated with
the aggregation node, rather than individual metric containers associated
with the object nodes of the type represented by the aggregation node.” Id.
In the circumstances of this case, where the claim terms lack an
established meaning in the art, reading them so broadly that they bear little
or no relationship to what is described in Paragraph 65 of the Specification
as the invention and what it achieves is inappropriate, even under the rule of
broadest reasonable interpretation. In that regard, our reviewing court has
instructed as follows:
The correct inquiry in giving a term its broadest reasonable
interpretation in light of the specification is not whether the
specification proscribes or precludes some broad reading of the
claim term adopted by the examiner. And it is not simply an
interpretation that is not inconsistent with the specification. It is
an interpretation that corresponds with what and how the
inventor describes his invention in the specification, i.e., an
Appeal 2020-000566
Application 15/195,728

11
interpretation that is “consistent with the specification.” In re
Morris, 127 F.3d 1048, 1054 Fed. Cir. 1997) (citation and
internal quotation marks omitted); see also In re Suitco Surface,
603 F.3d 1255, 1259–60 (Fed. Cir. 2010).
In re Smith International, Inc., 871 F.3d 1375, 1382–83 (Fed. Cir. 2017).
Simply determining whether the specification precludes a proposed
construction would lead to the broadest possible interpretation of a claim
term, irrespective of consistent descriptions that indicate otherwise, which is
inappropriate. Smith, 871 F.3d at 1383.
Based on the foregoing, an “aggregation entity” is a collection of
object entities of a particular type, whereas“population metrics” or
“population metric” means an accumulation of a metric for each individual
component in a population of components. We see no meaningful
distinction between “population metrics” and “population metric” in the
context of the Specification. The two appear to be used in the Specification
interchangeably. Neither the Examiner nor the Appellant has articulated a
meaningful difference.
Thus, we read the larger phrase “current state information, including
object entities associated with metrics and aggregation entities associated
with population metrics” as referring to current state information of:
(1) object entities associated with metrics, where an
object entity is a system, component of a system, or subsystem,
where metrics means information with regard to the
operational states and statuses of one or more components,
subcomponents, systems, and subsystems, and
(2) aggregation entities associated with population
metrics, where an aggregation entity is a collection of object
Appeal 2020-000566
Application 15/195,728

12
entities of a particular type and where population metrics refers
to an accumulation of a metric for each individual component
in a population of components.
2. “state-information-storage subsystem control component that
maintains the current state information and that adds data
points to population metrics associated with aggregation
entities”
The Examiner has read the above-quoted language of claim 1 as
reciting a means-plus-function element “under 35 U.S.C. § 112(f) or
pre-AIA 35 U.S.C. 112, sixth paragraph.” Final Act. 6. The involved
application was filed on June 28, 2016, and does not claim priority to any
earlier filed application. Thus, post-AIA 35 U.S.C. § 112(f) applies.
Appellant disagrees that the above-quoted language constitutes recitation of
a means-plus-function element under 35 U.S.C. § 112(f). Appeal Br. 15–18.
35 U.S.C. § 112(f) states: “An element in a claim for a combination
may be expressed as a means or step for performing a specified function
without the recital of structure, material, or acts in support thereof, and such
claim shall be construed to cover the corresponding structure, material, or
acts described in the specification and equivalents thereof.” The statutory
section has two parts, a first part about expression of the means or step for
performing a specified function, and a second part about what is covered,
i.e., the corresponding structure, material, or acts described in the
Specification and equivalents thereof.
We need not decide whether the Examiner correctly regarded the
language at issue to be a means-plus-function recitation under 35 U.S.C.
§ 112(f). That is because, whether or not the language at issue constitutes a
means-plus-function recitation under 35 U.S.C. § 112(f), the Examiner’s
Appeal 2020-000566
Application 15/195,728

13
rejections of the claims as obvious over McMurry and Cox and as directed to
patent-ineligible subject matter cannot be sustained, for reasons discussed
below.
Further, resolution of this question would not lead to an
understandable position of the Examiner with respect to the appealed
rejections, because the Examiner never identified what he regards as
structure, material, or acts described in the Specification and corresponding
to the recited state-information-storage subsystem control component.
Stated differently, the Examiner’s analysis is incomplete. Even assuming
the Examiner is correct that the language sets forth a means-plus-function
element under 35 U.S.C. § 112(f), the Examiner failed to account for the
element by explaining how the prior art is applied to meet that
corresponding structure, and how, despite the presence of such
corresponding structure, claim 1 and the claims dependent thereon are drawn
to patent ineligible subject matter.
B. Obviousness Rejection of Claims 1–20 over McMurry and Cox
1. Claims 1, 12, and 19
Claim 1 recites “aggregation entities associated with population
metrics.” Claims 12 and 19 each recite an “aggregation entity” with which
is associated a “population metric.” Determinative of the appropriateness of
the obviousness rejection is the Examiner’s incorrect interpretation of
“aggregation entity,” “aggregation entities,” “population metrics,” and
“population metric,” under the rule of broadest reasonable interpretation that
applies during examination.

Appeal 2020-000566
Application 15/195,728

14
The Examiner states as follows:
The Office action acknowledged McMurry did not
disclose “aggregation entities associated with population
metrics”. The broadest reasonable interpretation of this term in
light of the specification is simply something (an entity) that
combines or aggregates a number (metric) that represents a
population. As previously explained, a family or city name could
represent an aggregation entity that is associated with a
population metric (e.g. how many family members, or population
of a city). The broadest reasonable interpretation of this
limitation, even in light of the specification, does not require a
specialized aggregation node or CMDB or any event type or
identifier as suggested by [A]ppellant.
Ans. 10–11 (emphasis added).
In our claim construction analysis discussed above, we already
construed the terms “aggregation entities” and “population metrics.” The
Examiner is correct that neither requires a CMDB, an event type, or an
identifier. But the Examiner still failed to show how a single counting
number, a sum, constitutes a population metric or population metrics
associated with an aggregation entity. The Examiner explains as follows:
McMurry does not explicitly disclose “aggregate entities
associated with population metrics” / “population metrics
associated with aggregation entities”. However, it is well known
human behavior to count the number of things (e.g. a census that
aggregates population metrics is thousands of years old). Cox
explicitly teaches aggregating the number of resources in the
distributed computing art (abstract, Figs. 1, 2A, col. 2 ln. 9–11,
col. 6 ln. 57–60).
It would have been obvious to one of ordinary skill in the
art before the effective filing date of the claimed invention to
modify McMurry to aggregate the population metrics as taught
by Cox for the purpose of maintaining network state.
Appeal 2020-000566
Application 15/195,728

15
Final Act. 9 (emphases added); see also Ans. 11. Cox states: “An aggregate
resource is defined as a logical resource composed of or containing a
number of real resources.” Cox 2:9–11. Cox further states: “Next the
program examines the retrieved record and determines the number of real
descendants which a given aggregate resource represents as shown in block
16.” Id. at 6:57–60.
Based on the above-quoted expressed reasoning of the Examiner, the
Examiner regards a family or a city as an aggregation entity, and the total
number of family members or the population of the city as a population
metric to which the aggregation entity is associated. Similarly, in the
environment of computer systems, the Examiner regards a particular type of
components as an aggregation entity and the total number of such
components as a population metric associated with the aggregation entity.
The Examiner states that “it is well known human behavior to count the
number of things” and the Examiner cites Cox as providing one such
example. Final Act. 9.
However, we do not see how, in the context of the invention
described in the Specification, a final count that reflects the total number of
a type of resource units constitutes a population metric or population metrics
associated with that group of resource units. The Examiner has not
adequately explained. Indeed, the Examiner’s construction is too broad and
also inconsistent with the Specification.
As we explained in the claim construction analysis above,
“aggregation entity” means a collection of object entities of a particular
type; “object entity” means a system, component of a system, or subsystem;
“metrics” means information with regard to the operational states and
Appeal 2020-000566
Application 15/195,728

16
statuses of one or more components, subcomponents, systems, and
subsystems; and “population metrics” means an accumulation of a metric for
each individual component in a population of components.
The count number in Cox upon which the Examiner relies is the total
number of real resource units. The Examiner has not explained how that
total number properly accounts for the requirement of “population metrics.”
“Population metrics” is not met simply by the total number of resource units.
It is not met by determining the total number in a population, as the
Examiner suggests by stating “a family or city name could represent an
aggregation entity that is associated with a population metric (e.g., how
many family members, or population of a city).” Ans. 10–11. As we
determined and explained above, “population metrics” means an
accumulation of a metric for each individual component in a population of
components.
The Examiner’s analysis is missing an accounting for accumulation of
a metric for each individual component, because the Examiner’s reasoning
lacks identification of any data specific to any individual component. For
instance, the total number of family members does not provide any status
information specific to any particular family member, e.g., name, age,
gender, income, phone number, address, employment, etc., and the total
number of people in a city also does not provide any such information
specific to any resident of the city.
For the foregoing reasons, the Examiner’s rejection of claims 1, 12,
and 19 as obvious over McMurray and Cox is erroneous and cannot be
sustained.
Appeal 2020-000566
Application 15/195,728

17
2. Claims 2–11, 13–18, and 20
Claims 2–11 each depend, directly or indirectly, from claim 1, and
thus incorporate all of the limitations of claim 1. The deficiencies of the
Examiner’s analysis for claim 1 equally apply to claims 2–11.
Claims 13–18 each depend, directly or indirectly, from claim 12, and
thus incorporate all of the limitations of claim 12. The deficiencies of the
Examiner’s analysis for claim 12 equally apply to claims 13–18.
Claim 20 depends from claim 19 and thus incorporates all of the
limitations of claim 19. The deficiencies of the Examiner’s analysis for
claim 19 equally apply to claim 20.
Accordingly, the Examiner’s rejection of claims 2–11, 13–18, and 20
as obvious over McMurry and Cox cannot be sustained.
C. The Rejection of Claims 1, 2, 11–13,
18, and 19 under 35 U.S.C. § 101 as
being drawn to patent-ineligible subject matter
An invention is patent-eligible if it claims a “new and useful process,
machine, manufacture, or composition of matter.” 35 U.S.C. § 101.
However, the Supreme Court has held that § 101 includes implicit
exceptions—laws of nature, natural phenomena, and abstract ideas—which
are not patent-eligible. See Alice Corp. v. CLS Bank Int’l, 573 U.S. 208,
216 (2014); Bilski v. Kappos, 561 U.S. 593, 601 (2010). In January 2019,
the Office issued the 2019 Revised Patent Subject Matter Eligibility
Guidance, 84 Fed. Reg. 50 (Jan. 7, 2019) (“2019 Guidance”), which
addresses the manner in which § 101 case law is to be applied by the
Appeal 2020-000566
Application 15/195,728

18
Office.2 We are required to adhere to the 2019 Guidance as a matter of
Office policy. 2019 Guidance at 51. The 2019 Guidance sets forth a four-
part analysis for determining whether a claim is eligible subject matter under
§ 101. The four parts are referred to as Step 1, Step 2A Prong 1, Step 2A
Prong 2, and Step 2B. See id. at 53–56.
1. 2019 Guidance Step 1
First, under “Step 1,” we consider whether the claimed subject matter
falls within the four statutory categories set forth in § 101, namely
“[p]rocess, machine, manufacture, or composition of matter.” 2019
Guidance at 53–54; see 35 U.S.C. § 101. Independent claim 1 recites a
“state-information-storage subsystem within a computer system that includes
one or more processors, one or more memories, and one or more data-
storage devices, the state-information-storage subsystem comprising . . . .”
Thus, it falls within the “machine” category. Independent claim 12 recites a
“method that stores and maintains state information with respect to a
computer system, within the computer system, the method carried out within
the computer system that includes one or more processors, one or more
memories, and one or more data-storage devices, the method comprising
. . . .” Thus, it falls within the “process category.” Independent claim 19
recites computer instructions which are stored within a “physical data-
storage device.” Thus, it falls within the “manufacture” category.
Consequently, we proceed to the next step of the analysis.

2 A further update was issued in October 2019. October 2019 Patent
Eligibility Guidance Update, 84 Fed. Reg. 55942 (October 18, 2019).
Appeal 2020-000566
Application 15/195,728

19
2. 2019 Guidance Step 2A Prong 1
Second, under “Step 2A Prong 1,” we evaluate “whether the claim
recites a judicial exception, i.e., an abstract idea, a law of nature, or a natural
phenomenon.” 2019 Guidance at 54; see Alice, 573 U.S. at 216 (2014);3
Bilski, 561 U.S. at 601–602.4 The 2019 Guidance identifies the following as
a sub-group of abstract ideas: “Mental processes—concepts performed in
the human mind (including an observation, evaluation, judgment, opinion).”
2019 Guidance at 52 (footnotes omitted). The Examiner applied the “mental
process” category of the judicial exception of abstract ideas, and explained
as follows:
Claims 1, 12, and 19 are directed to the abstract idea of a
mental process because they recited concepts performed in the
human mind. Specifically, the claims recite “current state
information including object entities associated with metrics”,
and “aggregation entities associated with population metrics”
that is maintained within one or more memories and one or more
data storage devices. This is directed to the mental process of a
person remembering information. For example, an aggregation
entity could be a family name and population metric could be
how many people are in the family. The claims further recite a
“state-information storage subsystem control component that
maintains the current state information” and “that adds data
points to population metrics associated with aggregation
entities”. Again, maintaining state-information is merely a
person remembering data. Adding data points to a metric is
simply replacing that data with new data. This is a mental
process that is performed in the human mind. Therefore, the

3 In Alice, a method of exchanging financial obligations between two parties
using a third-party intermediary to mitigate settlement risk is deemed an
abstract idea. Alice, 573 U.S. at 219.
4 In Bilski, a method of hedging or protecting against risk is deemed an
abstract idea. Bilski, 561 U.S. at 611.
Appeal 2020-000566
Application 15/195,728

20
claims are directed to an abstract idea under the PEG [patent
eligibility guideline].
Ans. 5–6. We agree with the Examiner that the independent claims recite a
mental process of remembering information, albeit specific types of
information, i.e., “current state information including object entities
associated with metrics,” and “aggregation entities associated with
population metrics.” We further agree with the Examiner that the recited
mental process includes remembering new information additional to what is
already being remembered, through the addition of data points.
For the foregoing reasons, we agree with the Examiner that claims 1,
12, and 19, as well as claims 2 and 11 which depend directly from claim 1,
claim 13 which depends directly from claim 12, and claim 18 which depends
indirectly from claim 1, each recite an abstract idea.
3. 2019 Guidance Step 2A Prong 2
Having determined that claim 1 recites an abstract idea, we proceed to
“Step 2A Prong 2” of the 2019 Guidance, which requires that we evaluate
whether “the claim as a whole integrates the recited judicial exception into a
practical application of the exception.” 2019 Guidance at 54. If the abstract
idea is so integrated, then the claim is not “directed to” a judicial exception
and is eligible subject matter, and the subject matter eligibility inquiry
concludes. Id. Otherwise, the inquiry requires further analysis under Step
2B. Id.
“A claim that integrates a judicial exception into a practical
application will apply, rely on, or use the judicial exception in a manner that
imposes a meaningful limit on the judicial exception, such that the claim is
more than a drafting effort designed to monopolize the judicial exception.”
Id.; see Mayo Collaborative Servs. v. Prometheus Labs., Inc., 566 U.S. 66,
Appeal 2020-000566
Application 15/195,728

21
78 (2012). The 2019 Guidance specifies that this evaluation is conducted by
first “[i]dentifying whether there are any additional elements recited in the
claim beyond the judicial exception(s),” then “evaluating those additional
elements individually and in combination to determine whether they
integrate the exception into a practical application.” 2019 Guidance at 54–
55.
The 2019 Guidance lists non-exhaustive exemplary considerations
tending to indicate that a judicial exception such as an abstract idea has been
integrated into a practical application:
An additional element reflects an improvement in the
functioning of a computer, or an improvement to other
technology or technical field;
an additional element that applies or uses a judicial
exception to effect a particular treatment or prophylaxis for a
disease or medical condition;
an additional element implements a judicial exception
with, or uses a judicial exception in conjunction with, a
particular machine or manufacture that is integral to the claim;
an additional element effects a transformation or reduction
of a particular article to a different state or thing; and
an additional element applies or uses the judicial
exception in some other meaningful way beyond generally
linking the use of the judicial exception to a particular
technological environment, such that the claim as a whole is
more than a drafting effort designed to monopolize the
exception.
Id. at 55 (footnotes omitted). The Examiner identified no such element in
the claims. Ans. 6. We disagree that there is none.
We begin by looking at the Specification with respect to what pre-
existing problems the disclosed invention is intended to solve, and then see
if the claims embody a practical application of the above-determined mental
Appeal 2020-000566
Application 15/195,728

22
process to improve the functioning of a computer or other technology. For
reasons discussed below, we find that they do.
Paragraph 64 in the Specification, quoted by Appellant on pages 22–
23 of the Appeal Brief, discusses problems and difficulties with pre-existing
distributed systems. Spec. ¶ 64. The Specification explains that over time a
distributed application may expand to include many more components, each
running within a virtual machine and/or container, and may even expand to
include additional component types. Id. Also, the Specification explains
that the mapping of application components may be dynamic and unstable
over time, “with components created and destroyed over relatively small
intervals of time with respect to the lifetime of the distributed application.”
Id. For those reasons, the Specification states that accumulation of metric
data by conventional means corresponding to metric objects “in the CMDB-
like representation shown in Figure 15E becomes problematic.” Id. The
Specification further states:
For one thing, the lifetime of an individual application
component may be insufficiently long to accumulate meaningful
metric data. For another, the metric data for a particular type of
application component, such as the backend-server components,
may be distributed among many different highly dynamic object
nodes, which makes processing and analysis of the data difficult.
Id. Appellant identifies a similar problem with what was conventional:
[I]t is well understood that collection, storage, and processing of
metric data is a critically important component of a modern
distributed computing systems. Because of the dynamic nature
of the mapping of distributed applications to hardware
components in modern distributed computing systems,
traditional mappings used by CMDBs do not provide for
collection of meaningful metric data, and without meaningful
metric data, effective automated administration and management
Appeal 2020-000566
Application 15/195,728

23
of distributed computing systems in distributed applications is
not possible.
Appeal Br. 24–25.
The Specification in Paragraph 65 explains how the disclosed
invention solves the above-noted challenge and difficulty with pre-existing
systems and reads as follows:
Figure 17–18 illustrate an object-entity-aggregation
method, using illustration conventions employed in previous
figures, that addresses the above-discussed problems associated
with collecting metric data for application components of
modern, highly dynamic and mobile distributed applications. As
shown in Figure 17, using the CMDB-like graph-like
representation of a portion of the configuration and state
information for the multi-processor-based system, a new type of
node, referred to as an “aggregation mode,” has been added to
the logical representation. A first aggregation node 1702
represents all of the backend-server application components
1704–1714. A second aggregation node 1706 represents the
request-processing application components 1718–1722. A third
aggregation node 1724 represents all of the application
components of type r 1726–1727 and a final aggregation node
1730 represents the database-server application components
1732–1733. An aggregation node is a meta-level node that
represents multiple object nodes. In Figure 17, the aggregation
nodes represent all of the object nodes of a particular type but, in
alternative implementations. an aggregation node may represent
a subset of the nodes of a particular type. Aggregation nodes
allow certain of the metrics associated with particular types of
object nodes to be accumulated within a single metric container
associated with the aggregation node, rather than individual
metric containers associated with the object nodes of the type
represented by the aggregation node. In other words, the metric
data collected by metric entities associated with aggregation
nodes is population data generated by multiple object nodes,
rather than data generated by a single individual node.
Aggregation modes can therefore be used to collect, process, and
analyze population data for types and classes of application
Appeal 2020-000566
Application 15/195,728

24
components, even though individual application components
may have relatively short lifetimes with respect to the overall
lifetime of a distributed application and even though application-
component nodes may be highly distributed and mobile. The
collection of population data for classes of component types can
greatly facilitate analysis of distributed-application operational
characteristics and behavior, allowing conclusions to be drawn
with respect to the performance of classes or subsets of
application components over extended periods of time.
Spec. ¶ 65 (emphases added). This technical solution is realized by the
claims which integrate the above-noted abstract idea into a practical
application, as discussed below. We focus on independent claim 1.
Claim 1 recites a state-information-storage subsystem which is
“within a computer system that includes one or more processors, one or
more memories, and one or more data-storage devices,” and which
comprises “current state information” and “a state-information-storage
subsystem control component that maintains the current state information
and that adds data points . . . .” Because “current state information “ has to
be “current,” and because the state-information-storage subsystem adds data
points, in claim 1 operation of the computer system is continually monitored
to produce the structured current state information required by the claim, i.e.,
object entities associated with metrics and aggregation entities associated
with population metrics. Based on above-noted description in the
Specification, with such structured current state information collected and
maintained in a state-information-storage subsystem, a new and improved
computer system is provided. In that regard, the U.S. Court of Appeals for
the Federal Circuit has stated the following:
Much of the advancement made in computer technology consists
of improvements to software that, by their very nature, may not
be defined by particular physical features but rather by logical
Appeal 2020-000566
Application 15/195,728

25
structures and processes. We do not see in Bilski or Alice, or our
cases, an exclusion to patenting this large field of technological
progress.
Enfish, LLC v. Microsoft Corp., 822 F.3d 1327, 1339 (Fed. Cir. 2016).
Indeed, in Enfish, the improvement lies in “the way computers operate,
embodied in [a] self-referential table.” Enfish, 822 F.3d at 1336.
For the foregoing reasons, we find that claim 1 recites elements which
improve the functioning of a computer system and, therefore, we determine
that the above-determined abstract idea, i.e., a mental process, has been
integrated into a practical application.
Claim 12 recites a method to store and maintain state information with
respect to a computer system, within the computer system, and the computer
system includes one or more processors, one or more memories, and one or
more date-storage devices. Although claim 12 does not expressly refer to
“current” state information, it is understood that state information is
monitored or tracked because claim 12 refers to actions taken “when a
metric-data-point-generating event occurs,” and claim 12 also refers to
“adding the data-point generated by the data-point-generating event to the
population-metric.” Thus, like claim 1, claim 12 requires active monitoring
of the components of the computer system to produce the structured state
information required by the claim. That, in turn, as we explained above,
constitutes a new and improved computer system.
Claim 19 is substantially the same as claim 12, except that it is
directed to computer instructions stored within a physical storage-device.
The steps in the method of claim 12 are recited as actions performed by one
or more processors within the computer system when the stored computer
instructions are executed by the one or more processors. Thus, like claim
Appeal 2020-000566
Application 15/195,728

26
12, claim 19 requires active monitoring of the components of the computer
system to produce the structured state information required by the claim.
That, in turn, as we explained above, constitutes a new and improved
computer system.
The Examiner did not separately analyze independent claims 12 and
19, nor has Appellant separately argued claims 12 and 19. They are similar
to independent claim 1. For similar reasons as we discussed above, the
abstract idea articulated by the Examiner has been, in the context of claims
12 and 19, integrated into a practical application in the form of a new and
improved computer system.
Claims 2 and 11 each depend directly from claim 1. Claim 13
depends directly from claim 12. Claim 18 depends from claim 11. By
virtue of dependency, our determination that claims 1 and 12 integrates an
abstract idea into a practical application equally applies to claims 2, 11, 13,
and 18 as well.
Because we find, under Step 2A Prong 2 that each rejected claim
integrates the articulated judicial exception into a practical application, we
need not go further in the analysis to Step 2B. 2019 Guidance at 54.
Further, the Examiner provided no substantive reasoning when
withdrawing the patent ineligibility rejection under 35 U.S.C. § 101 for
claims 3–10, 14–17, and 20, to distinguish those claims from the remaining
claims which are still subject to the rejection under 35 U.S.C. § 101, i.e.,
claims 1, 2, 11–13, 18, and 19. Ans. 3. Given this apparent inconsistency, it
is not clear to us how claims 1, 2, 11–13, 18, and 19 are patent ineligible if
claims 3–10, 14–17, and 20 are patent eligible.
Appeal 2020-000566
Application 15/195,728

27
For all of the foregoing reasons, the Examiner’s rejection of claims 1,
2, 11–13, 18, and 19 under 35 U.S.C. § 101 as being drawn to patent-
ineligible subject matter cannot be sustained.
CONCLUSION
Claims
Rejected
35
U.S.C. §
Reference(s)/Basis Affirmed Reversed
1, 2, 11–
13, 18, 19
101 Patent Eligibility 1, 2, 11–13,
18, 19
1–20 103 McMurray, Cox 1–20

REVERSED