VMWARE, INC.

Patent Trials and Appeals Board

May 21, 2021

2020000165 (P.T.A.B. May. 21, 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.
15/063,528 03/08/2016 RAJESH KHAZANCHI C421.02 7031
152606 7590 05/21/2021
Olympic Patent Works PLLC
4979 Admiral Street
Gig Harbor, WA 98332
EXAMINER
WINDER, PATRICE L
ART UNIT PAPER NUMBER
2452
MAIL DATE DELIVERY MODE
05/21/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 RAJESH KHAZANCHI, SERVESH SINGH, KIRAN SINGH,
RISHI SARAF, AGILA GOVINDARAJU, VISHAL JAIN, and SHYAM
SUNDAR RAO MANKALA

________________

Appeal 2020-000165
Application 15/063,528
Technology Center 2400
________________

Before JAMES R. HUGHES, JENNIFER L. MCKEOWN, and
JASON J. CHUNG, Administrative Patent Judges.

CHUNG, Administrative Patent Judge.

DECISION ON APPEAL
Pursuant to 35 U.S.C. § 134(a), Appellant1 appeals the Non-Final
Rejection of claims 1–6, 11, 13–16 and 20.2 We have jurisdiction under
35 U.S.C. § 6(b).
We AFFIRM.

1 We use the word “Appellant” to refer to “applicant” as defined in
37 C.F.R. § 1.42. According to Appellant, VMWARE, INC. is the real party
in interest. Appeal Br. 1.
2 Claims 7–10, 12, 17–19 are objected to as being upon a rejected base
claim, but would be allowable if rewritten in independent form including all
of the limitations of the base claim and any intervening claim. Final Act. 9.
Appeal 2020-000165
Application 15/063,528

2

INVENTION
The invention relates to an automated application-release-
management facilities that accommodate inter-application dependencies in
branching pipelines. Spec. ¶ 2. Claim 1 is illustrative of the subject matter
on appeal and is reproduced below:
1. An automated-application-release-management subsystem within
a cloud-computing facility having multiple servers, data-storage
devices, and one or more internal networks, the automated-
application-release-management subsystem comprising:
a dashboard user interface;
an automated-application-release-management controller;
an interface to a workflow-execution engine within the
cloud-computing facility;
an artifact-storage-and-management subsystem; and
representations of branching application-release-
management pipelines, stored in one or more memories within
the cloud-computing facility, that include one or more
branch points corresponding to one or more corresponding inter-
application dependencies.

Appeal Br. 17 (Claims Appendix).

REJECTION
The Examiner rejects claims 1–6, 11, 13–16, and 20 under 35 U.S.C.
§103 as being unpatentable over Maes (US 2016/0239595 A1, pub. Aug. 18,
2016) in view of Scheiner (US 2016/0239280 A1, pub. Aug. 18, 2016).
Final Act. 5–9.

Appeal 2020-000165
Application 15/063,528

3

ANALYSIS
I. Maes teaches the limitations “application-release-management-
pipelines,” “branching,” “branch points” and “inter-application
dependencies”
A. Application-release-management-pipelines
The Examiner finds Maes describes a collection of workflows that
implement “designing, provisioning, deploying and managing” application
services in a cloud system, which teaches the limitation “application-release-
management-pipelines” recited in claims 1, 14 and 20. Ans. 9, 12, 14, 15
(citing Maes ¶¶ 17, 20, 21).
Appellant argues Maes fails to teach the limitation “application-
release-management pipeline” because blueprints in Maes are descriptions
of collections of workflows, rather than a set of sequentially executable tasks
or workflows. Appeal Br. 8–10. We disagree with Appellant.
As an initial matter, the Examiner makes additional findings in the
Examiner’s Answer. Compare Ans. 9–12 (citing Maes ¶¶ 17, 20, 31, 33, 62,
145) (presenting new findings by citing to paragraph 17, 20, 31, 33, 62,
145), with Final Act. 6 (citing Maes ¶¶ 60, 71–74). Appellant does not rebut
the Examiner’s additional findings and clarified responses in the Answer.
Even if Appellant did rebut the Examiner’s additional findings and
clarified responses in the Answer, the Specification describes “application-
release-management-pipeline” as “a sequence of stages that each comprises
a number of sequentially executed tasks . . . or workflows” in a non-limiting
context. Appeal Br. 8–9 (citing Spec. ¶¶ 67–68). The Examiner concludes,
based on Maes’ disclosures, that Maes teaches a collection of workflows that
implement “designing, provisioning, deploying and managing” application
Appeal 2020-000165
Application 15/063,528

4
services in a cloud system. Ans. 9 (citing Maes ¶ 17). In addition, the
Examiner concludes (again based on Maes’ disclosures) that Maes teaches
arranging the workflows per action along a tree that hierarchically organizes
the sequences in which the actions are to be performed; and Maes teaches
each branch of the tree from the root object of the blueprint details the steps
required to build each tier. Ans. 9 (citing Maes ¶ 20). Further, the Examiner
finds Maes describes executing the objects’ workflow of the blueprint in an
order, which the Examiner concludes teaches the limitation “application-
release-management-pipelines” recited in claims 1, 14 and 20. Ans. 12, 14,
15 (citing Maes ¶ 21).
Therefore, we agree with the Examiner's findings and ultimate
conclusion that Maes teaches “application-release-management-pipelines”
recited in claims 1, 14, and 20. Ans. 9, 12, 14, 15 (citing Maes ¶¶ 17, 20,
21). Appellant does not persuade us of error.
B. “Branching” and “branch points”
The Examiner finds Maes’ workflows incorporate a number of
branches and each side of the branches is executed in a sequential series of
steps, which teaches the limitations “branching” and “branch points” recited
in claims 1, 14 and 20. Ans. 9–10, 16 (citing Maes ¶¶ 20, 31, 33).
Appellant argues Maes fails to teach the limitation “branching
application-release-management pipeline” because the blueprints do not
contain branch points disclosed in the current application that are special
gating-rule tasks to detect the absence of items in an artifact rate and launch
execution of different application release-management pipelines than the
application-release-management pipelines including the branch points.
Appeal Br. 11. We disagree with Appellant.
Appeal 2020-000165
Application 15/063,528

5
For this issue, the Examiner provides additional determinations and
clarified responses in the Answer. Compare Ans. 16 (making additional
determinations that it is commonly known in the art that branch points are
where different pipelines meet and execution of each stage of a pipeline
leads to a branch point, and incorporating a specifically designed “special
gating rule task” as suggested by Appellant would be an additional feature
that is not inherent to the branch point), with Final Act. 6 (lacking the
aforementioned determinations). Appellant does not rebut the Examiner’s
additional determinations and clarified responses in the Answer.
Even if Appellant did rebut the Examiner’s additional determinations
and clarified responses in the Answer, we agree with the Examiner’s
determination that “branching” and “branch point” are not defined in the
Specification. Ans. 16. Instead, the Specification describes “branching,”
“branch point,” and “inter-application dependencies” using non-limiting,
exemplary language, such as “example,” “may be,” “one possible example,”
“one example of many possible,” “may be varied to produce a variety of
different implementations” etc., which falls short of a limiting definition.
Spec. ¶¶ 72–80. We also agree with the Examiner that it is commonly
known in the art that a branch point is where different pipelines meet and
execution of each stage of one pipeline leads to the branch point, and
incorporating a specifically designed “gating rule task” as suggested by
Appellant would be additional feature that is not inherent to the branch
point. Ans. 16.
As such, the cited portions of Maes relied upon by the Examiner
would have taught one having ordinary skill in the art that the workflow
incorporates a number of branches where each side of the branch is executed
Appeal 2020-000165
Application 15/063,528

6
in a sequential series of steps or action, which we conclude teach or suggest
“branching” and “branch points” as recited in claims 1, 14 and 20. Id. at 9–
10 (citing Maes ¶¶ 20, 31, 33). Accordingly, Appellant does not persuade us
of error.
C. Inter-application dependencies
The Examiner finds Maes’ description of dependencies derived
between nodes of the blueprints teaches the limitation “inter-application
dependencies” recited in claims 1, 14 and 20. Ans. 10–12 (citing Maes
¶¶ 62, 145).
Appellant argues that Maes fails to teach the limitation “inter-
application dependencies” because Maes is not directed to building, testing,
and releasing applications, but instead directed to services, and Maes does
not anywhere discuss any type of dependency between services or between
blueprints. Appeal Br. 11. We disagree with Appellant.
Regarding “inter-application dependencies,” we agree with the
Examiner’s determination that the Specification does not define “inter-
application dependencies,” and features such as “a gating rule constitutes
inter-application dependency” relied upon by Appellant in the arguments are
not recited in rejected claims. Ans. 10–12.
Moreover, the cited portions of Maes relied upon by the Examiner
describe dependencies derived between the nodes of the blueprints, which
we conclude teach or suggest the limitation “inter-application dependencies”
recited in claim 1 (and similarly recited in claims 14 and 20) when
interpreting the claim using its broadest reasonable construction. Id. at 7–8
(citing Maes ¶¶ 62, 145).
Appeal 2020-000165
Application 15/063,528

7
Therefore, Appellant does not persuade us of error in the Examiner’s
findings and ultimate conclusion that Maes teaches the limitations
“application-release-management-pipelines,” “branching,” “branch points”
and “inter-application dependencies” recited in claims 1, 14 and 20.

II. Maes teaches an automated-application-release management
subsystem within a cloud-computing facility
The Examiner finds Maes describes blueprints and topologies
implement a cloud service automation (CSA) system with servers, which the
Examiner maps to the limitation “cloud-computing facility.” Ans. 16 (citing
Maes ¶ 20). The Examiner also finds Maes describes a lifecycle
management engine within the cloud service system executing a collection
of workflows that are arranged per action along a tree that hierarchically
organizes the sequences in which the actions are to be performed, which the
Examiner maps to the limitation “automated-application-release-
management subsystem.” Ans. 16 (citing Maes ¶ 16).
Appellant argues that Maes fails to teach the limitation “an
automated-application-release-management subsystem within a cloud-
computing facility having multiple servers, data storage devices, and one or
more internal networks” because the cited portions of Maes’ does not teach
any types of sub-system within a cloud-computing facility, and Maes’
blueprints are not application-release management pipelines executed by the
currently claimed automated-application-release management subsystem.
Appeal Br. 12. We disagree with Appellant.
As an initial matter, the Examiner makes additional findings and
provides clarified responses in the Answer. Compare Ans. 16 (citing Maes
¶¶ 16, 20) (presenting additional findings which cite Maes paragraphs 16,
Appeal 2020-000165
Application 15/063,528

8
20), with Final Act. 5 (citing Maes ¶¶ 17–18). Appellant does not rebut the
Examiner’s additional findings and clarified responses in the Answer.
Even if Appellant did rebut the Examiner’s additional findings and
clarified responses in the Answer, the cited portions of Maes describe
blueprints and topologies implement a cloud service automation (CAS)
system with servers, which at least suggests the limitation “cloud-computing
facility having multiple servers.” Ans. 16 (citing Maes ¶ 20); see also Maes
¶¶ 1, 19, 42 (showing the management system includes data storage devices,
and one or more internal networks). Moreover, the cited portions of Maes
describe the lifecycle management engine (i.e., subsystem) within the cloud
service system executing the collection of workflows that are arranged per
action along a tree that hierarchically organizes the sequences in which the
actions are to be performed (i.e., Maes’ disclosure describes a subsystem
sequentially executing tasks/workflows such as pipelines, which suggests the
limitation “automated-application-release-management subsystem.” Ans. 16
(citing Maes ¶ 16).
Therefore, Appellant does not persuade us of error in the Examiner’s
findings and resulting conclusion that Maes teaches the limitation
“automated-application-release management subsystem within a cloud-
computing facility” recited in claims 1 (and similarly recited in claims 14
and 20).
III. Maes teaches an automated-application-release management
controller
The Examiner finds Maes describes a lifecycle management engine
operating as a controller to obtain and execute the workflows and actions
that are associated with the workflows, which the Examiner maps to the
Appeal 2020-000165
Application 15/063,528

9
limitation “automated-application-release management controller.” Ans. 17
(citing Maes ¶¶ 33, 36).
Appellant argues Maes fails to teach “automated-application-release
management controller” because paragraph 67 of the current application
describes an automated-application-release-management controller
sequentially initiating execution of various workflows that together
implement a release pipeline and serving as an intermediary between the
dashboard user interface and the workflow-execution engine, while the cited
paragraph 64 of Maes does not mention workflows, release pipelines,
dashboard user interfaces, a workflow-execution engine, and/or indication
that the management broker. Appeal Br. 13. We disagree with Appellant.
As an initial matter, the Examiner provides additional findings and
clarified responses in the Answer. Compare Ans. 17 (citing Maes ¶¶ 33, 36)
(presenting newly cited paragraphs 33 and 36), with Final Act. 5 (citing
Maes ¶ 64). Appellant does not rebut the Examiner’s additional findings
and clarified responses in the Answer.
Even if Appellant did rebut the Examiner’s additional findings and
clarified responses in the Answer, the cited portions of Maes disclose the
lifecycle management engine (i.e., the claimed controller) used to obtain and
execute the workflows and actions that are associated with the workflows
(i.e., the claimed automated application release pipeline), which teaches or at
least suggests the limitation “automated-application-release management
controller” recited in claims 1, 14 and 20. Ans. 17 (citing Maes ¶¶ 33, 36).
Therefore, Appellant does not persuade us of error in the Examiner’s
findings and resulting conclusion that Maes teaches the limitation
Appeal 2020-000165
Application 15/063,528

10
“automated-application-release management controller” recited in claims 1,
14 and 20.
IV. Maes teaches an interface to a workflow-execution engine within the
cloud-computing facility
The Examiner finds Maes describes the lifecycle management engine
obtains the workflows and executes the workflows, and the lifecycle
management topology implements the cloud service automation. Ans. 18
(citing Maes ¶¶ 33, 66, 67). The Examiner determines that Maes’ lifecycle
management engine (in the cloud-computing facilities) inherently interfaces
with the workflows, in that the lifecycle management engine obtains the
workflows, which teaches the limitation “interface to a workflow-execution
engine within the cloud-computing facility.” Ans. 18.
Appellant argues Maes fails to teach an interface to a workflow-
execution engine within the cloud-computing facility because there is no
mention of any type of interfaces to the lifecycle management machine and
no indication of the LCM is included in a cloud-computing facility in the
cited paragraph 33 of Maes. Appeal Br. 13. We disagree with Appellant.
As an initial matter, the Examiner makes additional findings and
clarified responses in the Answer. Compare Ans. 18 (citing Maes ¶¶ 33, 66,
67) (presenting newly citied paragraph 66), with Final Act. 5 (citing Maes ¶¶
33, 67). Appellant does not rebut the Examiner’s additional findings in the
Answer. Moreover, Appellant do not rebut the Examiner’s additional
determinations and clarified reasoning in the Answer. Compare Ans. 18
(making additional determinations that lifecycle management engine
inherently interfaces with the workflows), with Final Act. 5 (lacking the
aforementioned determinations).
Appeal 2020-000165
Application 15/063,528

11
Even if Appellant did rebut the Examiner’s additional findings and
clarified responses in the Answer, we agree with the Examiner’s conclusion
that by obtaining the workflows, the lifecycle management engine (i.e.,
controller) in the cloud-computing facilities inherently interfaces with the
workflows, which teaches or at least suggests the limitations “an interface to
a workflow-execution engine within the cloud-computing facility” recited in
claims 1, 14 and 20. Ans. 18 (citing Maes ¶¶ 33, 66, 67).
Therefore, Appellant does not persuade us of error in the Examiner’s
findings and ultimate conclusion that Maes teaches the limitation “interface
to a workflow-execution engine within the cloud-computing facility” recited
in claims 1, 14 and 20.
V. Maes teaches an artifact-storage-and management subsystem
The Examiner finds Maes discloses the lifecycle management engine
obtaining artifacts required to deploy the application from secure storage
devices such as a definitive software library. Ans. 18 (citing Maes ¶¶ 101,
150). The Examiner determines the artifacts are used for management of the
cloud service because the artifacts are resources for checking the cloud
service. Ans. 18.
Appellant argues Maes fails to teach an artifact-storage-and
management subsystem because there is no mention of any type of artifact
or of the artifact-storage-and management subsystem in the cited paragraphs
101 and 150 of Maes. Appeal Br. 13. We disagree with Appellant.
Appellant does not rebut the Examiner’s additional determinations
and clarified responses in the Answer. Compare Ans. 18 (making additional
determinations that the purpose of the artifacts are for management of the
Appeal 2020-000165
Application 15/063,528

12
cloud service), with Final Act. 6 (lacking the aforementioned
determinations).
Even if Appellant did rebut the Examiner’s additional determinations
and clarified responses in the Answer, the cited portions of Maes describe
the definitive software library storing the artifacts, and using artifacts for
management of the cloud service, which teaches or at least suggests the
limitation “artifact-storage-and-management subsystem.” Ans. 18 (citing
Maes ¶¶ 101, 150); see also Maes ¶ 89 (showing managing/checking
artifacts).
Therefore, Appellant does not persuade us of error in the Examiner’s
concluding that Maes teaches the limitation “artifact-storage-and-
management subsystem” recited in claims 1, 14 and 20.
VI. Maes teaches representations of branching application-release-
management pipelines, stored in one or more memories within the cloud-
computing facility, that include one or more branch points corresponding to
one or more corresponding inter-application dependencies
The Examiner finds Maes’ blueprints are descriptions of a collection
of workflows, the workflows are executable and arranged in a tree that
hierarchically organizes the sequences in which the actions are to be
performed, and branches of the workflows detail the steps required to build
each tier (hierarchy), which the Examiner maps to the limitation
“representations of branching application-release-management pipelines.”
Ans. 9, 12 (citing Maes ¶¶ 17, 18, 20, 21, 31, 33). The Examiner also finds
Maes describes dependencies derived between the nodes of the blueprints,
which the Examiner maps to the recited “inter-application dependencies.”
Ans. 12–13 (citing Maes ¶¶ 62, 145).
Appellant argues Maes fails to teach representations of branching
Appeal 2020-000165
Application 15/063,528

13
application-release-management pipelines, stored in one or more memories
within the cloud-computing facility, that include one or more branch points
corresponding to one or more corresponding inter-application dependencies
because the Examiner does not point to anything specific to represent
branching application-release-management pipelines in the cited paragraphs
60 and 71–74 of Maes. Appeal Br. 13–14. Appellant argues Maes does not
clearly indicate that the blueprint is executed sequentially because paragraph
21 of Maes does not state the execution of workflow must follow any order.
Reply Br. 17–183. We disagree with Appellant.
As an initial matter, the Examiner makes additional findings and
clarified responses in the Answer. Compare Ans. 9, 12 (citing Maes ¶¶ 17,
18, 20, 21, 31, 33, 62, 145) (presenting additional findings citing Maes ¶¶ 17
18, 20, 21, 31, 33, 62, 145), with Final Act. 5 (citing Maes ¶¶ 60, 71–74).
Appellant only rebuts the Examiner’s additional finding relating to Maes
¶ 21 in the Answer. Further, Appellant does not persuade us of error
because Maes describes that the blueprint is sequentially executed, which at
least suggests the limitation “pipeline.” Ans. 9, 12 (citing Maes ¶¶ 17, 18,
20, 21, 31, 33, 62, 145).
Even if Appellant did rebut all of the Examiner’s additional findings
and clarified responses in the Answer, we agree with the Examiner’s
findings and conclusions. That is, the cited portions of Maes disclose that

3 We determine that Appellant’s argument in the Reply Brief pertaining to
Maes’ teaching that the blueprint is executed sequentially is timely because
the Examiner makes the blueprint’s sequential execution conclusion for the
first time in the Answer. Compare Ans. 12 (the Examiner concludes the
blueprint is executed sequentially), with Final Act. 6 (lacking any mention of
blueprint’s sequential execution).
Appeal 2020-000165
Application 15/063,528

14
blueprints are descriptions of a collection of workflows (i.e.,
representations); the workflows are executable, arranged along a tree that
hierarchically organizes the sequences in which the actions are to be
performed (i.e., application-release-management pipelines); and branch of
the workflows (i.e., branching and branch points) that details the steps
required to build each tier, and dependencies derived between the nodes of
the blueprints (i.e., this teaches inter-application dependencies), which teach
or at least suggest the limitation “representations of branching application-
release-management pipelines, stored in one or more memories within the
cloud-computing facility, that include one or more branch points
corresponding to one or more corresponding inter-application
dependencies.” Ans. 9, 12 (citing Maes ¶¶ 17, 18, 20, 21, 31, 33, 62, 145).
Therefore, Appellant does not persuade us of error in the Examiner’s
conclusion that Maes teaches the limitation “representations of branching
application-release-management pipelines, stored in one or more memories
within the cloud-computing facility, that include one or more branch points
corresponding to one or more corresponding inter-application dependencies”
recited in claims 1, 14 and 20.

VII. The Examiner provides a sufficient reason for combining Maes
and Scheiner
The Examiner concludes that Scheiner teaches a dashboard user
interface (Ans. 19; Final Act. 6 (citing Scheiner, Fig. 5A)) and the Examiner
further concludes that it would have obvious to a person having ordinary
skill in the art at the time of invention to combine Scheiner and Maes’
managing deployment plans with workflows and artifacts to allow a user to
Appeal 2020-000165
Application 15/063,528

15
use the interface to access and modify the deployment plans. Ans. 19 (citing
Scheiner ¶¶ 3, 47).
Appellant argues the Examiner does not provide a reason why a
combination Scheiner and Maes would have been obvious to one skilled in
art because the Examiner merely inserts meaningless assertions such as
“‘incorporating Scheiner’ dashboard in Mae’s blueprint system would have
improved effectiveness’” and “‘motivation would have been to facilitate
consolidated information while operating automated lifecycle management
and thereby allow the use to assess the deployment or deployment plan.’”
Appeal Br. 14–15.
As an initial matter, the Examiner makes additional findings and
clarified responses in the Answer. Compare Ans. 19 (citing Scheiner ¶¶ 3,
47 (presenting additional findings citing to Scheiner ¶ 3), with Final Act. 6
(citing Scheiner ¶ 47). Appellant does not rebut the Examiner’s additional
findings and clarified responses in the Answer.
Even if Appellant did rebut the Examiner’s additional findings and
clarified responses in the Answer, we agree with the Examiner’s findings
and conclusions. That is, the Examiner’s combinability determination relies
on Scheiner ¶ 47 (for combining Maes with Scheiner). Ans. 19 (citing
Scheiner ¶¶ 3, 47). The above-noted teachings suggest that the combination
involves the predictable use of prior art elements according to their
established functions. The Supreme Court has held that in analyzing the
obviousness of combining elements, a court need not find specific teachings,
but rather may consider “the background knowledge possessed by a person
having ordinary skill in the art” and “the inferences and creative steps that a
person of ordinary skill in the art would employ.” KSR Int'l Co. v. Teleflex
Appeal 2020-000165
Application 15/063,528

16
Inc., 550 U.S. 398, 418 (2007). To be nonobvious, an improvement must be
“more than the predictable use of prior art elements according to their
established functions,” id. at 417, and the basis for an obviousness rejection
must include an “articulated reasoning with some rational underpinning to
support the legal conclusion of obviousness.” Id. at 418 (citation omitted).
Here, the Examiner has provided a rationale for the combination, which is to
allow the use to assess the deployment or deployment plan and improve
effectiveness. Ans. 19 (citing Scheiner ¶¶ 3, 47). Accordingly, we find that
the Examiner has provided sufficient motivation for Maes with the teachings
of Scheiner.
Moreover, Appellant has not provided persuasive evidence that
combining the respective teachings of the references (as proffered by the
Examiner – Final Act. 6; Ans.19) would have been “uniquely challenging or
difficult for one of ordinary skill in the art,” or that such a combination
would have “represented an unobvious step over the prior art.” Leapfrog
Enters., Inc. v. Fisher-Price, Inc., 485 F.3d 1157, 1162 (Fed. Cir. 2007).
Nor has Appellant provided any objective evidence of secondary
considerations, which, as our reviewing court explains, “operate[] as a
beneficial check on hindsight.” Cheese Systems, Inc. v. Tetra Pak Cheese
and Powder Systems, Inc., 725 F.3d 1341, 1352 (Fed. Cir. 2013).
Accordingly, Appellant does not persuade us of error in the
Examiner’s conclusion that a person having of ordinary skill in the art at the
time of the invention would have combined Maes and Scheiner.
Appellant does not argue claims 1–6, 11, 13–16, 20 separately with
particularity. Therefore, we sustain the Examiner’s rejection of:
Appeal 2020-000165
Application 15/063,528

17
(1) independent claims 1, 144, and 20; and (2) dependent claims 2–6, 11, 13,
and 15–16 under 35 U.S.C. § 103.
We have only considered those arguments that Appellant actually
raised in the Briefs. Arguments Appellant could have made, but chose not to
make, in the Briefs have not been considered and are deemed to be waived.
See 37 C.F.R. § 41.37(c)(1)(iv).

CONCLUSION

TIME PERIOD FOR RESPONSE
No time period for taking any subsequent action in connection with
this appeal may be extended under 37 C.F.R. § 1.136(a)(1)(iv). See
37 C.F.R. § 1.136(a)(1)(iv) (2018).

4 Claim 14 states “when the artifact-storage-and-management subsystem
does not contain one or more artifacts, launches execution of one or more of
the one or more additional application-release-management pipelines”
(hereinafter “conditional limitation”). Because claim 14 is a method claim,
in the event of further prosecution, the Examiner should determine whether
to give this conditional limitation patentable weight. See Ex parte
Schulhauser, No. 2013-007847, 2016 WL 6277792 (PTAB Apr. 28, 2016)
(precedential).
Claim(s)
Rejected
35 U.S.C.
§
Reference(s)/Basis Affirmed Reversed
1–6, 11,
13–16, 20
103 Maes, Scheiner 1–6, 11,
13–16, 20

Overall
Outcome
1–6, 11,
13–16, 20

Appeal 2020-000165
Application 15/063,528

18

AFFIRMED