Avaya Inc.

Patent Trials and Appeals Board

Apr 7, 2021

2019006297 (P.T.A.B. Apr. 7, 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/670,296 03/26/2015 Kurt Haserodt 4366-697 6552
48500 7590 04/07/2021
SHERIDAN ROSS P.C.
1560 BROADWAY, SUITE 1200
DENVER, CO 80202
EXAMINER
CHANG, JULIAN
ART UNIT PAPER NUMBER
2455
NOTIFICATION DATE DELIVERY MODE
04/07/2021 ELECTRONIC
Please find below and/or attached an Office communication concerning this application or proceeding.
The time period for reply, if any, is set in the attached communication.
Notice of the Office communication was sent electronically on above-indicated "Notification Date" to the
following e-mail address(es):
cjacquet@sheridanross.com
edocket@sheridanross.com
pair_Avaya@firsttofile.com
PTOL-90A (Rev. 04/07)
UNITED STATES PATENT AND TRADEMARK OFFICE
________________

BEFORE THE PATENT TRIAL AND APPEAL BOARD
________________

Ex parte KURT HASERODT, WILLIAM T. WALKER, and BENNY
ELLIS
________________

Appeal 2019-006297
Application 14/670,296
Technology Center 2400
________________

Before ALLEN R. MACDONALD, BARBARA A. BENOIT, and
RUSSELL E. CASS, Administrative Patent Judges.

CASS, Administrative Patent Judge.

DECISION ON APPEAL
Appellant1 appeals under 35 U.S.C. § 134(a) from the Examiner’s
final rejection of claims 1–20 under 35 U.S.C. § 103. Appeal Br. 1.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. Appellant lists Avaya, Inc. as the real party in interest. Appeal Brief
filed February 3, 2019 (“Appeal Br.”) 2.
2 Rather than repeat the Examiner’s positions and Appellant’s arguments in
their entirety, we refer to the above mentioned Appeal Brief, as well as the
following documents for their respective details: the Final Action mailed
August 2, 2018 (“Final Act.”); the Examiner’s Answer mailed June 24, 2019
(“Ans.”); and the Reply Brief filed August 26, 2019 (“Reply Br.”).
Appeal 2019-006297
Application 14/670,296
2
BACKGROUND
The present invention relates to a system and method for configuring
clusters of servers in a telecommunications system. Spec. 1:5–6. As
background, the Specification explains that voice portal platforms can use a
cluster of servers that work together as a single system, provide fault
resilience, and support scaling by adding more servers to the cluster. Id. at
1:24–26. In the event of a system failure, clustering can preserve data and
ensure resource availability to end users. Id. at 1:26–27. According to the
Specification, “[t]here is a need for a general purpose application platform
that can configure and define multiple server clusters.” Id. at 2:3–4.
To address this perceived need, the Specification discloses a system
that can include first and second clusters that each provide a set of services
or applications to other components of the system. Id. at 8:11–12. Each
cluster has a common set of cluster definitions for its member servers, but
the first and second clusters have different sets of cluster definitions. Id. at
8:12–15. In other words, the cluster profiles and attribute definitions for
different clusters can be different, while the member server profiles and
attribute definitions within a selected cluster are homogenous. Id. at 8:15–
19. For example, while different clusters can have different sets of software
modules installed on their respective set of member cluster servers, each
server of a particular cluster has the same software modules installed. Id. at
8:19–22.
Generally, a cluster includes a cluster profile which includes a cluster
profile name and/or identifier (such as “Data Center 1 Cluster”). Id. at
11:16–18. All clusters with the same cluster profile name and/or identify
may have the same configuration. Id. at 11:21–22. The cluster profile can
include a set of attributes that define the requirements and rules for the
Appeal 2019-006297
Application 14/670,296
3
cluster. Id. at 11:30–31. Installable software modules stipulated by the
attributes can be loaded and installed for each cluster, thereby causing all
cluster elements in a selected cluster to have a common set of installable
software modules. Id. at 11:30–12:3.
Claims 1, 5, and 6 are illustrative of the claims at issue in this appeal,
and are reproduced below:
1. A system, comprising:
first and second clusters of servers,
the first cluster corresponding to a first set of cluster
attributes defining an identical set of attributes for each member
server of the first cluster, wherein each member server of the
first cluster has identical installed applications and
a second set of cluster attributes defining an identical set of
attributes for each member server of the second cluster, wherein
each member server of the second cluster has identical installed
applications,
wherein the first and second sets of cluster attributes are
different and
wherein each of the member servers of the first cluster and
each of the member servers of the second cluster comprise a
processor, memory, and a network interface; and
wherein each member server of the first cluster has identical
installed applications [to] provide a first service that is different
from a second service provided by each member server of the
second cluster.
5. The system of claim 1, wherein the first and second sets
of cluster attributes are part, respectively, of first and second
cluster definitions, each of the first and second cluster
definitions further comprising a plurality of a cluster name,
cluster type, server identifiers, and application identifiers.
6. The system of claim 5, wherein the first and second sets
of cluster definitions comprise the server identifiers and
Appeal 2019-006297
Application 14/670,296
4
application identifiers and wherein the server identifiers of the
first and second sets of cluster definitions are disjoint sets.
Appeal Br. 14, 15 (Claims App.).
THE EXAMINER’S REJECTIONS
The prior art relied upon by the Examiner is set forth in the following
table:
Name Reference Date
Saletore US 2005/0188055 A1 Aug. 25, 2005
Fung US 2005/0262495 A1 Nov. 24, 2005
Goin US 2005/0289071 A1 Dec. 29, 2005
Saha US 2006/0037016 A1 Feb. 16, 2006
Davis US 2012/0117571 A1 May 10, 2012
Arigaya US 2016/0277316 A1 Sept. 22, 2016
Final Act. 4–17.
In the Final Office Action, the Examiner rejected claims 1–16 and 19
under 35 U.S.C. § 103 as being unpatentable over Goin in view of Arigaya.
Final Act. 4–14. The Examiner also rejected claims 17 and 20 under 35
U.S.C. § 103 as being unpatentable over Goin and Arigaya further in view of
Saha and Saletore. Id. at 14–16. The Examiner further rejected claim 18
under 35 U.S.C. § 103 as being unpatentable over Goin and Arigaya in view
of Davis. Id. at 16–17. Appellant disputes the Examiner’s rejections,
focusing on claims 1 and 6. Appeal Br. 5–12.
ANALYSIS
Claim 1
The Examiner finds that Goin teaches all of the elements of claim 1
except for the requirement that “each member server of the first cluster has
identical installed applications [to] provide a first service that is different
from a second service provided by each member server of the second
Appeal 2019-006297
Application 14/670,296
5
cluster.” Final Act. 4–5 (citing Goin ¶¶ 45, 85, Fig. 3). The Examiner relies
on Arigaya for this claim element. Id. at 5 (citing Arigaya ¶ 42, Fig. 5).
Appellant makes four arguments on appeal: (1) Goin’s “cluster” is
different from the claimed “cluster(s)” of servers; (2) Goin does not teach a
cluster having “an identical set of attributes for each member server” of the
cluster; (3) the teaching relied on from Arigaya is happenstance and not
enabling; and (4) Arigaya is silent on whether each server has identical
installed applications. Appeal Br. 5–10.
We find that the Examiner has sufficiently established that claim 1
would have been obvious over Goin and Arigaya. Goin teaches identifying
clusters of similarly-configured computers by gathering and analyzing
system and business configuration information values from a set of
computers. Goin, code (57), ¶ 10. Goin also explains that “business
configuration information” of a computer can include “the specific business
application software installed” (id. ¶ 29), and that “computers running
particular business application software might be formed into a cluster” (id.
¶ 51). Goin also provides an example of a first cluster that requires all of its
servers to have the Oracle and SAP business database software programs
installed, and another cluster that requires all of its servers to have the
software development programs Java and C++ installed, as shown in Figure
3, reproduced below:
Appeal 2019-006297
Application 14/670,296
6

Figure 3 of Goin shows two server clusters with different installed
applications. Id. ¶¶ 85–86.
Arigaya also discloses clusters each made up of “calculation nodes,”
which the Examiner and Appellant agree are “member servers.” Arigaya
Fig. 1, ¶ 42; Appeal Br. 9 (referring to “each member server (Arigaya’s
‘node’)”); Ans 4 (“Arigaya discloses a cluster of calculation nodes (i.e.,
servers)”). The clusters may each have an “application ID” identifying an
application implemented in the cluster, and different clusters can execute
different applications. Arigaya ¶¶ 56–57, Fig. 5. For example, Arigaya
shows an embodiment in Figure 5 where the member servers of one cluster
(Cluster 1) implement a “scan server” application, and the member servers
of another cluster (Cluster n) implement a “web server” application. Id. at
Fig. 5. We agree with the Examiner that the combination of Goin and
Arigaya teaches the limitations of claim 1.
We are not persuaded by Appellant’s arguments. First, Appellant
argues that Goin’s “cluster” is different from the claimed “cluster(s),” citing
an Internet source stating that “[a] cluster consists of two or more computers
working together to provide a higher level of availability, reliability, and
scalability than can be obtained by using a single computer.” Appeal Br. 5.
Appellant contends that Goin’s clusters do not meet this definition because
they are merely “logical constructs that are no more than labels and
Appeal 2019-006297
Application 14/670,296
7
synonymous with ‘peer groups,’” and thus are not “two or more computers
working together.” Id. However, we agree with the Examiner that Goin
discloses that the computers in a cluster may work together to provide
failure protection, thereby providing a higher level of availability and
reliability than can be obtained by a single computer. Ans. 4; Goin ¶ 6
(“Computers can also be clustered into groups of computers that back each
other up in a fully-automated fashion, with a computer that fails or that is not
performing properly automatically switched out of service and replaced with
another backup computer.”). As a result, we find that Goin discloses
clusters of servers even under Appellant’s definition.
Second, Appellant argues that Goin does not teach a cluster having
“an identical set of attributes for each member server” of the cluster because
“[w]hile Goin discloses ‘Java’ and ‘C++’ being common to both Server E
and Server F [in Figure 3], Goin does not disclose identical attributes of the
severs in Cluster 2” because “‘Perl’ is available on Server E but not Server
F.” Appeal Br. 7. Similarly, Appellant asserts that Goin teaches that
Servers A and B both include Oracle and SAP, but Server B additionally
includes “SQL.” Id.
We disagree. The claim language at issue provides for “a first set of
cluster attributes defining an identical set of attributes for each member
server of the first cluster.” We agree with the Examiner that under the
broadest reasonable interpretation of this claim language, the “identical set
of attributes” merely set forth what attributes a server must possess in order
to be a member of the group, and do not require that every attribute of every
server must be identical. See Ans. 5. This interpretation is supported by
Appellant’s Specification, which allows a cluster to be “open” so that
applications beyond the ones required by the cluster may be installed. Spec.
Appeal 2019-006297
Application 14/670,296
8
2:31–3:7 (“A cluster can be defined by many different attributes, including .
. . whether or not additional applications beyond the listed and optional
applications can be installed (e.g., whether the cluster is ‘open’ (or any
application permitted) or ‘closed’ (or blocked from installing non-listed
applications.”))). We find that the claim language includes both the “open”
and “closed” cluster embodiments in the specification. See In re Katz
Interactive Call Processing Patent Litig., 639 F.3d 1303, 1324 (Fed. Cir.
2011) (“[T]here is a strong presumption against a claim construction that
excludes a disclosed embodiment.”).
Third, Appellant argues that it is merely “happenstance” and “not an
enabling teaching” that Arigaya teaches two different clusters (Cluster 1 and
Cluster n in Figure 5) running different applications. Appeal Br. 8. To
support this argument Appellant points to the fact that Arigaya’s Figure 5
discloses another cluster (Cluster 2 in Figure 5) that includes applications
that overlap with those of Cluster 1. Id.
We do not agree with this argument. Figure 5 of Arigaya discloses a
“first cluster” (Cluster 1) and a “second cluster” (Cluster n) which have
different attributes and run different applications (“scan server” for Cluster 1
and “web server” for Cluster n). Because claim 1 uses the transitional
phrase “comprising,” it does not preclude the presence of additional clusters
in the system which may have similar or overlapping applications.
Consequently, the fact that Arigaya discloses a third cluster with
applications overlapping those of Cluster 1 does not take it out of the scope
of claim 1. Additionally, Appellant fails to sufficiently show that Arigaya’s
disclosure is not enabling and, in any event, enablement is not necessary for
a § 103 rejection. See Amgen Inc. v. Hoeschst Marion Roussel, Inc., 314
F.3d 1313, 1357 (Fed. Cir. 2003) (“Under § 103, however, a reference need
Appeal 2019-006297
Application 14/670,296
9
not be enabled; it qualifies as a prior art, regardless, for whatever is
disclosed therein.”).
Finally, Appellant argues that “Arigaya’s Fig. 5 is entirely silent as to
whether or not each member server (Arigaya’s ‘node’) ha[s] identical
installed applications.” Appeal Br. 9. Appellant further contends that on
“one of ordinary skill would not be able to ascertain from Fig. 5 that Arigaya
teaches the elements that comprise each of cluster 1 and cluster n are
identical.” Appeal Br. 9.
We do not agree. The Examiner’s rejection is based on obviousness,
not anticipation. Unlike anticipation, “which requires that a single reference
describe each and every element of a claimed invention, the question under
35 [U.S.C. §] 103 is not merely what the references expressly teach but what
they would have suggested to one of ordinary skill in the art” at the time of
the invention. Merck & Co. v. Biocraft Labs., Inc., 874 F.2d 804, 807–08
(Fed. Cir. 1989) (quoting In re Lamberti, 545 F.2d 747, 750 (CCPA 1976))
(citation omitted) (emphasis added). We find that Arigaya would have
suggested to one of ordinary skill the use of a cluster with each member
server (Arigaya’s calculation nodes 22 in Figure 1) having an identical
installed application, based on: (1) its disclosure of the cluster’s
“application ID” as “the identification information of the application
implemented in the cluster,” (2) its statement that “[t]he application ID may
be information indicative of a process which can be executed by the cluster”
(Arigaya ¶ 57), and (3) its disclosure that “the calculation nodes 22
[(member servers)] belonging to one of the clusters 20 can execute a process
related to a common function common to these calculation nodes 22”
(Arigaya ¶ 42). Specifically, Figure 5 discloses Cluster 1 with each
calculation node (member server) running the “scan server” application, and
Appeal 2019-006297
Application 14/670,296
10
Cluster n with each calculation node (member server) running the “web
server” application. Arigaya Fig. 5, ¶¶ 42, 57.
Therefore, we sustain the Examiner’s rejection of claim 1.
Claims 2–5 and 7–20
Appellant does not separately argue independent claims 8 and 15, or
dependent claims 2–4, 7, 9–14, and 16–20. Consequently, we sustain the
Examiner’s rejection of these claims.
Claim 6
As noted above, claim 6 (which depends from claim 5) recites that the
first and second clusters have first and second cluster definitions comprising
comprise server identifies and application identifiers, “wherein the server
identifiers of the first and second sets of cluster definitions are disjoint sets.”
The Examiner relies on Goin for this element. Final Act. 12–13 (citing Goin
¶ 48, Fig. 3).
Appellant argues that “Goin does not explicitly teach clusters that
have disjointed set[s],” but instead, “by happenstance, one example of a
disjointed set is provided,” and “no teaching is provided in Goin as to why.”
Appeal Br. 10. Appellant further argues that “one could point to Goin’s Fig.
4 and conclude that disjointed sets are explicitly not taught,” presumably
because it discloses an embodiment with four clusters, some of which have
overlapping applications. Id. The Examiner responds that Appellant’s
argument is not persuasive because claim 6 does not require that every
cluster’s set of installed applications is disjoint from every other’s, but rather
merely requires that one cluster’s installed applications disjoint from a
second cluster’s installed applications. Ans. 7.
We agree with the Examiner. Claim 6 merely requires that the
identifiers “of the first and second sets” of cluster definitions are disjoint
Appeal 2019-006297
Application 14/670,296
11
sets. Goin discloses that cluster definitions may include particular software
that is installed (Goin ¶ 84), and Goin’s Figure 3 discloses an embodiment
having two clusters with disjoint sets of installed applications—Cluster 1
with Oracle and SAP and Cluster 2 with Java and C++. Figure 4’s
disclosure of another embodiment where some of the servers have sets of
installed applications that are not disjoint does not alter the fact that Figure 3
discloses what is claimed.
Consequently, we sustain the Examiner’s rejection of claim 6.
CONCLUSION
We affirm the Examiner’s rejection of claims 1–20.
In summary:

Claim(s)
Rejected
35 U.S.C.
§
Reference(s)/Basis Affirmed Reversed
1–16, 19 103 Goin, Arigaya 1–16, 19
17, 20 103 Goin, Arigaya,
Saha, Saletor
17, 20
18 103 Goin, Arigaya,
Davis
18
Overall
Outcome
1–20

AFFIRMED