Hutzel, Daniel et al.

Patent Trials and Appeals Board

Aug 4, 2020

2019002153 (P.T.A.B. Aug. 4, 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.
14/508,503 10/07/2014 Daniel Hutzel 22135-0464001/131063US01 8384
32864 7590 08/04/2020
FISH & RICHARDSON, P.C. (SAP)
PO BOX 1022
MINNEAPOLIS, MN 55440-1022
EXAMINER
KABIR, MOHAMMAD H
ART UNIT PAPER NUMBER
2199
NOTIFICATION DATE DELIVERY MODE
08/04/2020 ELECTRONIC
Please find below and/or attached an Office communication concerning this application or proceeding.
The time period for reply, if any, is set in the attached communication.
Notice of the Office communication was sent electronically on above-indicated "Notification Date" to the
following e-mail address(es):
PATDOCTC@fr.com
PTOL-90A (Rev. 04/07)
UNITED STATES PATENT AND TRADEMARK OFFICE
BEFORE THE PATENT TRIAL AND APPEAL BOARD
Ex parte DANIEL HUTZEL, VOLKER DRIESEN, and ANDREAS JAHR
Appeal 2019-002153
Application 14/508,503
Technology Center 2100
Before JAMES R. HUGHES, JUSTIN BUSCH, and
CATHERINE SHIANG, Administrative Patent Judges.
BUSCH, Administrative Patent Judge.
DECISION ON APPEAL
Pursuant to 35 U.S.C. § 134(a), Appellant1 appeals from the
Examiner’s decision to reject claims 1–20. We have jurisdiction under
35 U.S.C. § 6(b).
We affirm.
CLAIMED SUBJECT MATTER
Appellant’s disclosure relates generally to “computer-implemented
methods for development and deployment of a product to a multi-server

1 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 SAP SE. Appeal
Br. 4.
Appeal 2019-002153
Application 14/508,503
2
landscape.” Spec. ¶ 3; see Spec., Abstract. More specifically, the claimed
subject matter essentially receives various user input to define and generate
the necessary components and metadata to create a “product package” for
deploying a project in a multi-server environment. Spec. ¶ 3. Claims 1, 8,
and 15 are independent claims. Representative claim 1 is reproduced below:
1. A computer-implemented method for development and
deployment of a product to a multi-server landscape, the method
being executed using one or more processors and comprising:
receiving, by the one or more processors, first user input
defining a product and indicating two or more components that
the product comprises, each of the two or more components
comprising one or more functional features that describe
functions of a respective component and are grouped together
based on a perspective that defines actions to be performed with
the two or more components during run-times;
receiving, by the one or more processors, second user
input comprising a project definition of a project, the project
being associated with development and deployment of the
product to a multi-server landscape comprising a first server
providing a first run-time environment using a first programming
language and a second server providing a second runtime
environment using a second programming language that is
different from the first programming language, each of the first
programming language and the second programming language
comprising one of a compiled language and an interpreted
language, the second user input indicating respective integrated
development environments (IDEs) used to develop the two or
more components for a single deployment to the first run-time
environment and the second run-time environment; and
receiving, by the one or more processors, third user input,
and in response to the third user input, automatically, by the one
or more processors:
providing metadata indicating the project, the two or
more components of the product, the first run-time
environment and the second run-time environment for
deployment of the two or more components,
Appeal 2019-002153
Application 14/508,503
3
receiving the two or more components respectively
developed using the two or more IDEs, and
generating a product package comprising the
metadata and the two or more components and providing
dependencies between the two or more components, the
dependencies comprising an order, in which the two or
more components are to be deployed relative to one
another.
REJECTIONS
Claims 1, 2, 4–9, 11–16, and 18–20 stand rejected under 35 U.S.C.
§ 103 as obvious in view of Winterfeldt (US 2013/0232480 A1; Sept. 5,
2013), Gidugu (US 2011/0264754 A1; Oct. 27, 2011), and Erickson (US
8,543,733 B1; Sept. 24, 2013). Final Act. 9–23.
Claims 3, 10, and 17 stand rejected under 35 U.S.C. § 103 as obvious
in view of Winterfeldt, Gidugu, Erickson, and Driesen (US 8,434,060 B2;
Apr. 30, 2013). Final Act. 23–25.
ANALYSIS2
We have reviewed the Examiner’s rejections in light of Appellant’s
arguments that the Examiner erred. In reaching this decision, we have
considered all evidence presented and all arguments Appellant made.
Arguments Appellant could have made, but chose not to make in the Briefs,
are deemed waived. See 37 C.F.R. § 41.37(c)(1)(iv).

2 Should this matter undergo further prosecution, we leave to the Examiner
to consider the Patent Office Guidance (issued after the Answer was mailed)
and to decide whether the claims, which generally relate to receiving user
input and generating a product package including generating metadata and
receiving product components, recite patent eligible-subject matter under
35 U.S.C. § 101 or whether the claims recite merely an abstract idea without
significantly more. See Elec. Power Grp, LLC v. Alstom S.A., 830 F.3d
1350 (Fed. Cir. 2016).
Appeal 2019-002153
Application 14/508,503
4
Appellant argues the claims as a group. See Appeal Br. 14–15 (“In
view of the foregoing, Winterfeldt fails to disclose or render obvious each
and every feature of claims 1, 8, and 15. . . . each of claims 2, 4-7, 9, 11-14,
16, and 18-19 is also patentable over Winterfeldt, Gidugu, and Erickson for
at least the same reasons.”). We select independent claim 1 as
representative. See 37 C.F.R. § 41.37(c)(1)(iv).
The Examiner finds the combination of Winterfeldt, Gidugu, and
Erickson teaches or suggests every limitation recited in representative claim
1. Final Act. 9–17. Of particular relevance to this Appeal, the Examiner
finds: (1) Winterfeldt teaches “receiving . . . input defining a product and
indicating two or more components that the product comprises, each . . .
comprising . . . functional features that . . . are grouped together based on a
perspective that defines actions to be performed . . . during run-times” and
(2) “receiving . . . input comprising a project definition of a project . . .
associated with development and deployment . . . to a multi-server landscape
comprising a first server providing a first run-time environment . . . and a
second server providing a second runtime environment” (the first and second
servers using a respective different respective programming languages).
Final Act. 9–12 (citing Winterfeldt ¶¶ 4, 5, 7, 21, 23, 26, 39, 63, Figs. 3B, 4;
Ans. 3–8 (additionally citing Winterfeldt ¶¶ 20, 24, 34, 36, 52, 74).
THE “RECEIVING . . . FIRST USER INPUT” STEP
Appellant argues Winterfeldt’s application blueprints define
infrastructure agnostic deployment topologies for installing applications by
capturing the application structure as a collection of components executing
on virtual computing resources. Appeal Br. 13–14 (quoting Winterfeldt
¶¶ 5, 21). Appellant asserts Winterfeldt fails to teach the details of the
Appeal 2019-002153
Application 14/508,503
5
“receiving . . . first user input” step because Winterfeldt’s components “are
grouped together as a collection for deployment, which is different than one
or more functional features that describe functions of a respective
component and are grouped together based on a perspective that defines
actions to be performed with the two or more components during run-times,”
as recited in representative claim 1. Appeal Br. 14 (emphases omitted); see
Reply Br. 3. Appellant also asserts that “merely defining dependencies
between components” does not teach the particular details of the “receiving
. . . first user input” step. Reply Br. 3.
We generally agree with how Appellant characterizes Winterfeldt’s
disclosures. In fact, the majority of Appellant’s argument merely
paraphrases Winterfeldt’s disclosures then asserts, without further
explanation, that Winterfeldt does not teach the disputed limitation. Appeal
Br. 13–14 (citing Winterfeldt ¶¶ 5, 21). But Appellant fails to persuasively
explain how the paraphrased portions of Winterfeldt demonstrate error in the
Examiner’s finding that Winterfeldt teaches or suggests the relevant portion
of the disputed limitation.
Winterfeldt relates to “a logical, multi-tier application blueprint that
can be used to create and manage . . . multiple applications in a cloud
infrastructure.” Winterfeldt, Abstract. Winterfeldt groups components
based on actions to be performed by the components during run-time.
Accord Final Act. 10–11 (citing Winterfeldt ¶¶ 4, 21, 39); Ans. 3–4
(additionally citing Winterfeldt ¶¶ 34, 36, 63); see also Winterfeldt ¶¶ 5
(“The application blueprints define the structure of the application, enable
the use of standardized application infrastructure components, and specify
installation dependencies and default configurations.”), 21 (describing a
blueprint as capturing “the structure of an application 108 as a collection of
Appeal 2019-002153
Application 14/508,503
6
application components executing on virtual computing resources,” and
describing components of a single application being installed in multiple
run-time environments, such as an application store and a database), 26
(describing assembling and arranging elements “into a topology that
represents virtual computing resources and application components for
supporting execution of application.”), 34 (“[A]dministrator 104 specifies
one or more application components, such as services and code components,
which may be installed on a virtual machine for supporting execution of an
application”), 52 (“The user may specify one or more dependencies between
application components to declare a relationship between the application
components that defines an interconnected structure of distributed portions
of the application (e.g., multiple tiers of the application).”).
Winterfeldt may use the metadata regarding dependencies between
components during deployment. Winterfeldt ¶ 4 (“To deploy such a multi-
tier application, a developer . . . must coordinate with a system administrator
. . . to determine which . . . software services (e.g., software packages)
should be provisioned to support execution of the application.”).
Without further explanation regarding the alleged distinction between
the disputed portion of the receiving first user input step and Winterfeldt’s
teachings, we look to Appellant’s statements and Specification for guidance
regarding the disputed limitation’s meaning to discern the alleged
distinction. Appellant identifies Specification paragraphs 24, 36, and 45 as
well as Figure 4 as supporting the receiving first user input step. See Appeal
Br. 8 (citing Spec. ¶¶ 24, 36, 45, Fig. 4). These paragraphs generally
describe a package builder that can build a product package that can be
deployed and executed across multiple servers during run-time based on
user-entered product definitions, product components, and dependencies
Appeal 2019-002153
Application 14/508,503
7
between the components. See Spec. ¶¶ 24, 36, 45. More specifically,
paragraph 24 discloses that a product (also referred to as an application) may
be a set of components that execute across multiple servers during run-time.
Spec. ¶ 24. Paragraph 36 discloses that the package builder service builds
the product package. Spec. ¶ 36. Paragraph 45 describes various user input
provided to define the product. Spec. ¶ 45. Figure 4 is a flow chart
depicting these and other steps at a high level. Spec., Fig. 4.
Winterfeldt’s components are similar to the claimed components, and
Winterfeldt groups its components together into a blueprint in a manner
similar to how claim 1 groups components together into a package. Both
claim 1 and Winterfeldt define an application by identifying components
that will be deployed and execute in a multi-tiered landscape at run-time.
See Winterfeldt ¶ 21; see also id. ¶ 4 (“Developers see an application as a
group of components with interdependencies.”). Both claim 1 and
Winterfeldt define relationships between the components.
Even accepting Appellant’s characterizations, Appellant does not
persuasively explain why the fact that Winterfeldt’s blueprint groups
components together for deployment fails to teach or suggest (or “is
different than”) the disputed limitation. For these reasons, we agree with the
Examiner that Winterfeldt teaches, or at least suggests, grouping together
components with functional features “based on a perspective that defines
actions to be performed” by the components during run-time.
THE “RECEIVING . . . SECOND USER INPUT” STEP
Appellant also argues Winterfeldt fails to teach or suggest the details
of the “receiving . . . second user input.” Appeal Br. 14; Reply Br. 4–5. In
particular, Appellant argues Winterfeldt discloses centrally generating and
Appeal 2019-002153
Application 14/508,503
8
managing multiple deployment plans for different deployment environments
from a single blueprint and Winterfeldt is silent regarding a teaching of “a
single deployment to the first run-time environment and the second run-time
environment.” Appeal Br. 14 (citing Winterfeldt ¶¶ 23, 90) (emphasis
omitted); Reply Br. 5. Appellant asserts, without further explanation, that
Winterfeldt’s centrally managed multiple deployment plans that deploy an
application to different deployment environments are different than claim
1’s recited “second user input indicating respective integrated development
environments (IDEs) used to develop the two or more components for a
single deployment to the first run-time environment and the second run-time
environment.” Appeal Br. 14; Reply Br. 5. Appellant also argues the
Examiner ignores portions of Winterfeldt that teach away from the second
user input step. Reply Br. 4–5 (quoting Winterfeldt ¶ 23).
As with Appellant’s other characterizations of Winterfeldt, we
generally agree with how Appellant characterizes Winterfeldt’s relevant
disclosures, which generally just paraphrases Winterfeldt’s cited portions.
Appeal Br. 14 (citing Winterfeldt ¶¶ 23, 90). But, as with the other disputed
limitation, Appellant fails to persuasively explain how this fact demonstrates
error in the Examiner’s finding that Winterfeldt teaches, or at least suggests,
the relevant portion of the receiving second user input step.
Once again, absent further explanation from Appellant, we look to the
Specification to discern the meaning of the recited receiving second user
input step. Appellant identifies Specification paragraphs 15, 30–33, and 47
as supporting the receiving second user input step. See Appeal Br. 8–9
(citing Spec. ¶¶ 15, 30–33, 47). The Specification discloses a system that
generally includes development tools (e.g., integrated development
environments (IDEs)), a product or package builder service, a deploy
Appeal 2019-002153
Application 14/508,503
9
service. Spec. ¶ 15; see Spec. ¶¶ 31–33, 47. “[A] product, also referred to
as an application, can execute across multiple, disparate servers and other
devices during the run-time” and “can be described as a set of components
and a set of packages.” Spec. ¶ 24. Run-time environments may include
servers, databases, and operating systems that execute components in run-
time. Spec. ¶ 28. A single product package may be used to deploy the
product in a multi-server landscape. Spec. ¶ 30; see Spec. ¶ 37.
As discussed above, Winterfeldt generally relates to creating and
managing multi-tier application blueprints. Winterfeldt ¶¶ 4–6. More
specifically, Winterfeldt’s blueprint may specify an application uses certain
web applications executing on particular application servers and a certain
databases on other servers. Winterfeldt ¶ 21. Accordingly, we agree with
Appellant that Winterfeldt generally provides a platform that allows users or
administrators to deploy an application using a single blueprint to various
deployment environments (e.g., test, development, and production
environments). Winterfeldt ¶¶ 5, 21.
However, that is merely one feature Winterfeldt teaches. As the
Examiner notes, Winterfeldt also teaches using the logical blueprint to create
and manage (e.g., deploy) multi-tier applications in a cloud infrastructure.
Winterfeldt ¶¶ 4–7, 20–22, 34, 36, 52; accord Final Act. 11–12 (citing
Winterfeldt ¶¶ 5, 23); Ans. 6 (additionally citing 21, 34, 36, 63). The
Examiner further clarifies that the claimed single deployment refers to
deploying the program or application to multiple servers in a distributed
environment, which the Examiner finds Winterfeldt teaches. Ans. 6 (citing
Winterfeldt ¶ 52).
“[The] mere disclosure of alternative designs does not teach away.”
In re Mouttet, 686 F.3d 1322, 1334 (Fed. Cir. 2002) (citations omitted). “A
Appeal 2019-002153
Application 14/508,503
10
reference may be said to teach away when a person of ordinary skill, upon
reading the reference, would be discouraged from following the path set out
in the reference, or would be led in a direction divergent from the path that
was taken by the applicant.” In re Kahn, 441 F.3d 977, 990 (Fed. Cir. 2006)
(citation omitted).
Therefore, we disagree with Appellant’s argument that merely
because Winterfeldt teaches using the same blueprint to deploy an
application or product to multiple deployments (e.g., a test environment, a
development environment, and a production environment), it teaches away
from the disputed limitation. As discussed above and as explained by the
Examiner, even though Winterfeldt’s blueprint may be used for multiple
deployments, Winterfeldt uses a single blueprint for each deployment to
deploy the various components in a multi-tier (or multi-server) landscape
where each server or tier executes in a different run-time environment.
CONCLUSION
For these reasons, we are not persuaded the Examiner erred in
rejecting representative claim 1 as obvious in view of Winterfeldt, Gidugu,
and Erickson. Nor are we persuaded the Examiner erred in rejecting
independent claims 2, 4–9, 11–16, and 18–20, which Appellant does not
argue separately with particularity, as obvious in view of Winterfeldt,
Gidugu, and Erickson. Similarly, Appellant does not argue dependent
claims 3, 10, and 17 separately with particularity. Accordingly, we are not
persuaded the Examiner erred in rejecting these claims for the same reasons.
Appeal 2019-002153
Application 14/508,503
11
DECISION SUMMARY
Claims
Rejected 35 U.S.C. § References Affirmed Reversed
1, 2, 4–9,
11–16, 18–20 103
Winterfeldt,
Gidugu, Erickson
1, 2, 4–9, 11–
16, 18–20
3, 10, 17 103
Winterfeldt,
Gidugu,
Erickson, Driesen
3, 10, 17
Overall
Outcome 1–20
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). See 37 C.F.R.
§ 1.136(a)(1)(iv).
AFFIRMED