VMware, Inc.

Patent Trials and Appeals Board

Apr 1, 2021

2019004696 (P.T.A.B. Apr. 1, 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/958,988 12/04/2015 Arjun Dube C542 5025
152606 7590 04/01/2021
Olympic Patent Works PLLC
4979 Admiral Street
Gig Harbor, WA 98332
EXAMINER
MEANS, JAREN M
ART UNIT PAPER NUMBER
2447
MAIL DATE DELIVERY MODE
04/01/2021 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 ARJUN DUBE, RAKESH SINHA, and
VISHWAS NAGARAJA

Appeal 2019-004696
Application 14/958,9881
Technology Center 2400
Before CAROLYN D. THOMAS, BARBARA A. BENOIT, and
JOHN R. KENNY, Administrative Patent Judges.
KENNY, Administrative Patent Judge.
DECISION ON APPEAL
STATEMENT OF THE CASE
Pursuant to 35 U.S.C. § 134(a), Appellant2 appeals from the
Examiner’s decision to reject claims 1–20, which constitute all pending
claims. Final Act. 1; Appeal Br. 1. We have jurisdiction under 35 U.S.C.
§ 6(b).
We AFFIRM.

1 This application was filed on December 4, 2015.
2 We use the word Appellant to refer to “applicant” as defined in 37 C.F.R.
§ 1.42(a). Appellant identifies the real party in interest as VMware, Inc.
Appeal Br. 1.
Appeal 2019-004696
Application 14/958,988

2
SPECIFICATION
The Specification is directed to workflow-based cloud-management
systems and automated-application-release-management subsystems.
Spec. ¶ 1.
CLAIMS
Claims 1, 12, and 20 are the pending, independent claims. Claims 1
and 12 are reproduced below:
1. A workflow-based cloud-management system incorporated
within a cloud-computing facility having multiple servers, data-
storage devices, and one or more internal networks, the
workflow-based cloud-management system comprising:
an infrastructure-management-and-administration
subsystem;
a workflow-execution engine;
an automated-application-deployment subsystem; and
an automated-application-release-management subsystem
that executes application-release-management
pipelines that each comprises one or more stages, each
having one or more tasks and that interfaces to one or
more artifact repositories through a model-based
artifact-management-subsystem interface to access
artifacts on behalf of the executing application-
release-management pipelines.
12. A method that provides for execution of application-release-
management pipelines, by an automated-application-release-
management-subsystem component of a workflow-based cloud-
management system that is incorporated within a cloud-
computing facility having multiple servers, data-storage
devices, and one or more internal networks and that accesses
artifacts through a model-based artifact-management-subsystem
interface, the method comprising:
configuring an application-release-management pipeline
to include one or more stages, each having one of
Appeal 2019-004696
Application 14/958,988

3
more tasks, that include one or more search-spec
handles for one or more artifacts; and
launching, by a management controller, execution of the
application-release-management pipeline, during
which the management controller resolves the search
specs into one or more artifact models.
Appeal Br. 31, 33.
REFERENCES
The Examiner relies on the following prior art:
Name Reference Date
Watters US 2013/0174117 A1 July 4, 2013
Tanner US 2015/0026171 A1 Jan. 22, 2015
REJECTIONS
Claims 1–11 stand rejected under 35 U.S.C. § 101 as directed to non-
statutory subject matter. Final Act. 14.
Claims 1–4, 12–15, and 20 stand rejected under 35 U.S.C. § 102(a)(1)
as anticipated by Watters. Final Act. 15.
Claims 5–11 and 16–19 stand rejected under 35 U.S.C. § 103(a) as
unpatentable over the combination of Watters and Tanner. Final Act. 23.
OPINION
A. Statutory Subject Matter
35 U.S.C. § 101 enumerates four statutory categories of statutory
subject matter: processes, machines, manufactures, and compositions of
matter. “For all categories [of statutory subject matter] except process
claims, the eligible subject matter must exist in some physical or tangible
form." Digitech Image Techs. v. Electronics for Imaging, 758 F.3d 1344,
1348 (Fed. Cir. 2014). “[A] process is a series of acts.” NTP, Inc. v.
Research in Motion, Ltd., 418 F.3d 1282, 1316 (Fed. Cir. 2005). Software
expressed as code or a set of instructions detached from any medium is an
Appeal 2019-004696
Application 14/958,988

4
idea without physical embodiment. See Microsoft Corp. v. AT&T Corp.,
550 U.S. 437, 449 (2007). Further, “[i]f a claim covers material not found in
any of the four statutory categories, that claim falls outside the plainly
expressed scope of § 101 even if the subject matter is otherwise new and
useful." In re Nuijten, 500 F.3d 1346, 1354 (Fed. Cir. 2007).
The Examiner determines that claim 1 is directed to non-statutory
subject matter because it: (i) lacks the necessary physical attributes or
objects to constitute a machine or manufacture, (ii) does not constitute a
series of steps or acts, and (iii) does not constitute a composition of matter.
Final Act. 14. The Examiner further finds that nothing in claim 1
necessarily includes a piece of physical hardware, indicating that “[t]he
servers and data-storage devices that are being claimed are part of the
‘computing facility’ and are not being limited to the workflow-based cloud-
management system itself.” Ans. 22. Further, the Examiner determines that
“the servers could be virtual servers[,] which are merely software in nature.”
Id. at 22–23. And the Examiner finds that “[t]he other components [recited
in the rejected claims,] such as engines, subsystems, pipelines, interfaces and
controllers could also merely be software modules or subroutines.” Id. at 23.
Appellant disagrees, arguing that claim 1 is directed to a system that is
incorporated within a cloud-computing facility, and as such, that system
includes electromechanical machines. Appeal Br. 11. Appellant further
asserts that claim 1 recites "an automated-application-release-management
subsystem that executes application-release-management pipelines that each
comprises one or more stages." Id. at 13. According to Appellant,
“[b]ecause the subsystem carries out a real-world, physical operations,
namely executing application-release-management pipelines, the subsystem
Appeal 2019-004696
Application 14/958,988

5
cannot be only computer instructions, but must additionally include physical
devices.” Id. Appellant also argues that the Examiner has not met the
requirements for a prima facie case for a rejection under section 101. Id.
We agree with the Examiner that claim 1 is directed to non-statutory
subject matter. Although the preamble of claim 1 recites that its workflow-
based cloud-management system is incorporated in “a cloud-computing
facility having multiple servers, data-storage devices, and one or more
internal networks,” we determine that this preamble recitation is not
limiting. Appeal Br. 31. “In general, a preamble limits the invention if it
recites essential structure or steps, or if it is ‘necessary to give life, meaning,
and vitality’ to the claim.” Catalina Mktg. Int'l, Inc. v. Coolsavings.com,
Inc., 289 F.3d 801, 808 (Fed. Cir. 2002). Here, the structure of the
workflow-based cloud-management system is defined by the body of the
claim, not by the preamble. In particular, although the recited cloud
computing facility is a structure, it is not the structure of the workflow-based
cloud-management system. Rather, the recited cloud computing facility is
where the workflow-based cloud-management system is intended to be used,
but an intended use is not limiting. Pitney Bowes, Inc. v. Hewlett-Packard
Co., 182 F.3d 1298, 1305 (Fed. Cir. 1999).
The limitations recited by the body of claim 1 encompass software per
se, which is non-tangible subject matter. Microsoft Corp., 550 U.S. at 449;
MPEP § 2106 (“Non-limiting examples of claims that are not directed to any
of the statutory categories include . . . software per se.”). Thus, we sustain
the section 101 rejection of claim 1, and of claims 2–11, not argued
separately. Appeal Br. 11–13.
Appeal 2019-004696
Application 14/958,988

6
B. Anticipation Rejection
1. Claim 1
Appellant argues that Waters does not disclose a number of recitations
of claim 1. We address each disputed recitation below.
a. Cloud Computing Facility
Appellant argues that Waters does not anticipate claim 1 because
Water does not disclose a cloud-management system incorporated within a
cloud-computing facility, as recited in the preamble of claim 1.
Appeal Br. 14. Appellant, however, does not present any persuasive
argument as to why we should construe the recitation of a cloud-computing
facility in the preamble of claim 1 to be limiting, and as set forth above, we
determine that recitation is not. Id. Thus, Watters’ purported lack of
disclosure of the cloud-computing facility recited in the preamble of claim 1
does not undermine the anticipation rejection of that claim.
b. Workflows, Workflow-Based Systems, and Workflow-
Execution Engines
The Examiner finds that Watters discloses workflows, workflow-
based systems, and workflow-execution engines by teaching a:
[s]ystem and method for forming a cloud appliance. The system
includes a management server, an artifact repository, a
continuous integration server, and build managers. The
management server includes source code and a project script for
forming the cloud appliance.
Final Act. 15 (quoting Watters, code (57)). Further, the Examiner finds that
Watters discloses a workflow-execution engine by teaching that “the
assigned build manager downloads project scripts and other support files
from the source code management repository and executes the build
process.” Id. (quoting Watters ¶ 81). The Examiner construes a “workflow”
Appeal 2019-004696
Application 14/958,988

7
as a “set of programs that aids in the tracking and management of all the
activities in a project from start to finish,” which the Examiner indicates is a
definition provided by a Microsoft Computer Dictionary. Ans. 23. The
Examiner explains that Watters satisfies this definition by disclosing many
different algorithms that pass a piece of work from initiation to completion.
Id. Further, the Examiner finds that Watters’ management of its cloud
appliance is done by a set of programs that aid in the tracking and
management of all activities of the system by the management server. Id. at
24.
Appellant disagrees, arguing that the Specification defines the terms
“workflow,” “workflow-based,” and “workflow-execution engine” in a
manner inconsistent with the Examiner’s construction, and that when these
terms are given their meanings in the Specification, Watters does not
disclose a workflow, a workflow-based system, and a workflow-execution
engine. Reply Br. 13–14. Appellant also argues that, although the Examiner
did not provide a full cite to the Microsoft Computer Dictionary at issue, that
dictionary was likely published twenty or more years ago. Id. at 14.
Appellant asserts that the term “workflow” has more recently become
strongly associated with the meaning set forth in the Specification. Id.
Appellant also argues that it could not present new evidence on appeal and,
thus, questions whether the Examiner could rely on new dictionary
definition in the Answer. Id.
We find that Watters discloses workflows, workflow-based systems,
and workflow-execution engines. The only definition for “workflow”
provided by the parties in this appeal is the definition provided by the
Examiner: “[a] set of programs that aids in the tracking and management of
Appeal 2019-004696
Application 14/958,988

8
all the activities in a project from start to finish.” Ans. 23. This definition is
actually too narrow for the term “workflow,” because it is, in fact, the
definition for the term “workflow application” in the Microsoft Computer
Dictionary (5th Edition) (2002). Ex. A. And workflows do not have to be
applications. Thus, the proper construction of the term “workflow” would
encompass a set of programs that aids in the tracking and management of all
the activities in a project from start to finish, but it would also encompass
other devices or items that aid in the tracking and management of all the
activities in a project from start to finish, such as a paper workflow.
Nevertheless, if Watters’s workflow satisfies the narrower construction
provided by the Examiner, that workflow would also satisfy a broader
construction that encompasses the full scope of the term. The Examiner
finds, and Appellant does not dispute, that Watters discloses a set of
programs that aids in the tracking and management of all the activities in a
project from start to finish. Ans. 23–24; Reply Br. 12–14. Thus, Watters
discloses a workflow. Accordingly, Watters’ system is a workflow-based
system, and Watters’ execution engine is a workflow-execution engine.
We are not persuaded by Appellant’s contrary argument that a
workflow, as the term is used in the Specification, does not encompass a set
of programs that aids in the tracking and management of all the activities in
a project from start to finish. Reply Br. 13–14. Although Appellant asserts
that the Specification defines the term “workflow” in a manner that would
preclude such coverage, Appellant does not set forth that definition, nor does
Appellant cite where that definition is in the Specification. Id. Further,
although Appellant argues that the definition for “workflow” has changed in
recent years and is now inconsistent with the definition cited by the
Appeal 2019-004696
Application 14/958,988

9
Examiner, Appellant does not cite any dictionaries to support that argument.
Id. at 14. In addition, although Appellant asserts that it could not provide a
new dictionary definition on appeal and suggests that the Examiner may be
similarly limited (id.), in actuality, the prohibition under 37 C.F.R.
§ 41.33(d)(2) on introducing new evidence on appeal does not extend to
dictionary definitions. See 37 C.F.R. § 41.30 (definition of Evidence).
Accordingly, we agree with the Examiner that Watters discloses
workflows, workflow-based systems, and workflow-execution engines.
c. Infrastructure-Management-and-Administration Subsystem
The Examiner finds that Watters’ build managers constitute an
infrastructure-management-and-administration subsystem. Final Act. 15;
Ans. 25–26. Appellant disagrees, arguing that the Specification requires that
the infrastructure management and administration system “provide[]
interfaces that allow service architects to develop various types of services
and resource descriptions that can be provided to users and clients of the
cloud-computing facility or facilities, including many management and
administrative services and functionalities implemented as workflows."
Appeal Br. 14–15 (quoting Spec. ¶ 55). Appellant asserts that Watters’
build managers and continuous integration servers do not provide such
interfaces. Id. at 15.
We agree with the Examiner on this issue. The portion of the
Specification that Appellant argues defines the term “infrastructure
management and administration facility” does not actually define the term.
Appeal Br. 14–15; Spec. ¶ 55. Rather, that section describes characteristics
of a particular infrastructure management and administration facility
disclosed in the Specification (i.e., infrastructure management and
Appeal 2019-004696
Application 14/958,988

10
administration facility 1114), and we cannot import limitations from the
Specification into the claims. Seachange Intern., Inc. v. C-COR, Inc.,
413 F.3d 1361, 1377 (Fed. Cir. 2005). Thus, we agree with the Examiner
that Watters discloses an infrastructure-management-and-administration
system.
d. Automated-Application-Deployment Subsystem
The Examiner finds that Watters’ continuous integration server is an
automated-application-deployment subsystem. Final Act. 16. Appellant
disagrees, arguing that Watters does not disclose the automated-application-
deployment subsystem described in the Specification as:
an integrated application-deployment environment to facilitate
building and launching complex cloud-resident applications on
the cloud computing facility or facilities. The application-
deployment facility provides access to one or more artifact
repositories that store and logically organize binary files and
other artifacts used to build complex cloud-resident applications
as well as access to automated tools used, along with workflows,
to develop specific automated application-deployment tools for
specific cloud-resident applications.
Appeal Br. 16–17 (quoting Spec. ¶ 55).
We agree with the Examiner on this issue. Appellant’s quote from the
Specification above does not define the term “automated-application-
deployment subsystem.” Spec. ¶ 55. Instead, it describes characteristics of
a particular application-deployment facility disclosed in the Specification
(i.e., application-deployment facility 1112) (id.), but we cannot import
limitations from the Specification into the claims. Thus, we agree with the
Examiner that Watters discloses an automated-application-deployment
subsystem.
Appeal 2019-004696
Application 14/958,988

11
e. Automated-Application-Release-Management Subsystem
The Examiner finds that Watters discloses an automated-application-
release-management subsystem. Final Act 16 (citing Watters ¶¶ 23, 44, 74).
Appellant disagrees, arguing that Figure 2 of Watters shows that humans are
involved with the release of Watters’s software. Appeal Br. 17 (arguing that
developers 225, testers 230, and release manager 245 are human beings).
We agree with the Examiner on this issue. The mere fact that humans
interact with Watters’ release management system does not mean that
system is not automated. After getting input from the involved humans,
Watters’ release management system automates the release of involved
cloud appliance, and nothing in claim 1 precludes human interaction.
Watters ¶ 23 (“a key component of an automated environment is a source
code management repository through which all changes to source code,
packaging, databases, configurations, etc. are made.” (emphasis added)).
Thus, we agree with the Examiner that Watters discloses an automated-
application-release-management subsystem.
f. One of More Stages Having One or More Tasks
As indicated above, claim 1 recites that the automated application
release subsystem “executes application-release-management pipelines that
each comprises one or more stages, each having one or more tasks.”
Appellant argues that the Examiner has not shown that Watters discloses
stages that each have one or more tasks. Appeal Br. 18. The Examiner finds
that Watters discloses sections that track and retrieve previous versions of
software and that these sections are stages. Ans. 30–31. The Examiner
further finds that the steps performed in those stages are tasks and defines
the term “task” as a step performed in an algorithm to accomplish a function.
Appeal 2019-004696
Application 14/958,988

12
Id. The Examiner states that: “[t]he word ‘task’ is too broad of a term to be
given any weight beyond a step or function performed by a computer
algorithm.” Id. at 31. Appellant responds that the Examiner fails to give
weight to the term “tasks.” Reply Br. 19–20. We disagree. The Examiner’s
statement regarding weight does not imply that the Examiner gave the term
“task” no weight. Rather, the Examiner defined the term, declined to give
weight to any broader definition for the term, applied his stated definition,
and found that Watters disclosed the requisite tasks. Ans. 30–31. Thus, the
Examiner gave the term weight, and we agree with the Examiner that
Watters discloses the recited stages and tasks.
g. Model-Based Artifact-Management Subsystem
The Examiner finds that a model-based-artifact-management
subsystem encompasses a software artifact management subsystem that uses
modeling to accomplish its goal of artifact management. Ans. 32. The
Examiner further finds that Watters discloses a model-based build manager
subsystem (Maven) that is used to manage Watters’ build process with the
use of its artifact repository. Id. (citing Watters ¶ 7). Appellant disagrees,
arguing that the recited subsystem does not encompass a build manager that
parses Maven Project Object Model files. Appeal Br. 18; Reply Br. 20–21.
Appellant asserts that the Specification defines the term “model-based
artifact management subsystem” in a manner that excludes Watters’ model-
based build manager subsystem. Appeal Br. 18; Reply Br. 20–21.
Appellant, however, does not provide the Specification’s definition for the
term, and we see no definition in the portions of the Specification cited by
Appellant in the Reply Brief (Spec. ¶¶ 76, 78, quoted in Reply Br. 20–21).
The Examiner’s interpretation is reasonable, and Appellant has given us no
Appeal 2019-004696
Application 14/958,988

13
persuasive reason to find error with it. Appeal Br. 18; Reply Br. 20–21.
Thus, we agree with the Examiner that Watters discloses a model-based
artifact-management subsystem.
h. Summary
We sustain the anticipation rejection of claim 1.
2. Claim 12
For claim 12, Appellant relies on its arguments regarding claim 1.
Appeal Br. 20. In addition, Appellant argues that Watters does not disclose
“one or more search-spec handles for one or more artifacts,” as recited in
claim 12. Id. at 20–21, 33. The Examiner finds that Watters’ version
numbers and revision numbers are search spec handles for artifacts. Ans.
33–34. The Examiner explains that the Specification teaches that a search-
spec handle is an identifier for one or more artifacts. Id. at 33 (citing Spec.
¶ 79). Appellant disagrees, arguing that thousands of artifacts could be
associated with the same version number. Reply Br. 21–22. We agree with
the Examiner on this issue. Claim 12 does not require that a search-spec
handle correspond to only one artifact. Instead, claim 12 recites that the
“one or more search-spec handles” are “for one or more artifacts”; the term
“one or more artifacts” encompasses thousands of artifacts. Appeal Br. 33.
Thus, we sustain the anticipation rejection of claim 12.
3. Claims 2–4, 13–15, and 20
Appellant does not separately argue claims 2–4, 13–15, and 20 from
claims 1 and 12. Appeal Br. 13–29. Thus, we sustain the anticipation
rejection of claims 2–4, 13–15, and 20.
Appeal 2019-004696
Application 14/958,988

14
C. Obviousness Rejection
For the obviousness rejection of claims 5–11 and 16–19, Appellant
relies on its arguments regarding the anticipation rejection of claims 1–4,
12–15, and 20. Appeal Br. 29. Thus, we sustain the obviousness rejection
of claims 5–11 and 16–19.
DECISION SUMMARY
In summary:
Claim(s)
Rejected
35 U.S.C. § Reference(s)/Basis Affirmed Reversed
1–11 101 Statutory Subject
Matter
1–11
1–4, 12–15,
20
102 Watters 1–4, 12–
15, 20

5–11, 16–19 103 Watters, Tanner 5–11, 16–
19

Overall Outcome 1–20
No time period for taking any subsequent action in connection with
this appeal may be extended under 37 C.F.R. § 1.136(a). See 37 C.F.R.
§ 1.136(a)(1)(iv).

AFFIRMED