Ex Parte Lewis

Board of Patent Appeals and Interferences

Jun 23, 2009

09577231 (B.P.A.I. Jun. 23, 2009)

UNITED STATES PATENT AND TRADEMARK OFFICE
_____________

BEFORE THE BOARD OF PATENT APPEALS
AND INTERFERENCES
_____________

Ex parte LUNDY LEWIS
_____________

Appeal 2009-000882
Application 09/577,2311
Technology Center 2400
______________

Decided:2 June 23, 2009
_______________

Before LEE E. BARRETT, LANCE LEONARD BARRY, and
JEAN R. HOMERE, Administrative Patent Judges.

BARRETT, Administrative Patent Judge.

DECISION ON APPEAL

1 Filed May 23, 2000, titled "Method and Apparatus for Component
to Service Mapping in Service Level Management (SLM)," which claims the
benefit of Provisional Application 60/135,492, filed May 24, 1999.
2 The two-month time period for filing an appeal or commencing a
civil action, as recited in 37 C.F.R. § 1.304, begins to run from the decided
date shown on this page of the decision. The time period does not run from
the Mail Date (paper delivery) or Notification Date (electronic delivery).

Appeal 2009-000882
Application 09/577,231

2
This is an appeal under 35 U.S.C. § 134(a) from the Examiner’s final
rejection of claims 4 and 13-62, which are all of the pending claims. We
have jurisdiction under 35 U.S.C. § 6(b).
Oral argument was held on June 10, 2009.
We affirm.

STATEMENT OF THE CASE
A. Appellant’s invention
The invention relates to service level management, wherein business
processes are composed of services. A state of the service is defined by one
or more service parameters, and the service parameters depend upon
performance of network components that support the service, e.g.,
component parameters. The state of the service may depend, for example,
on a collection of service parameter values for availability, reliability,
security, integrity and response time. A service level agreement is a contract
between a supplier and a customer that identifies services supported by a
network, service parameters for the services, and service levels (e.g.,
acceptable levels) for each service parameter. See Abstract.

B. The claims
The independent claims before us are claims 4, 13, 27, and 49, of
which claims 4 and 13 read:
4. A method of monitoring a state of a service supported by a
network, wherein the network includes a plurality of network
components, wherein the service supports a business process under
Appeal 2009-000882
Application 09/577,231

3
service level management in association with a service level
management domain, the method comprising the steps of:

selecting one or more network components on which the
service depends from among the plurality of network components;

mapping the one or more selected network components to the
service; monitoring the one or more selected network components to
determine the state of the service;

monitoring the state of the service to detect a change in the
state;

when the state of the service changes, determining a cause of
the change in the state of the service by performing an action, the
action comprising one or more of:

invoking a routine to determine an operational characteristic of
at least one of the selected network components,

constructing a database query to determine the operational
characteristic of at least one of the selected network components, and

requesting a change to one or more parameters of at least one of
the selected network components.

13. A method for monitoring a service, the service supporting a
business process under service level management in association with a
service level agreement, wherein the service is monitored by an
enterprise management system, wherein the business process depends
on at least a portion of a network, the method comprising the steps of:

mapping at least one component of the network on which the
service depends to the service;

Appeal 2009-000882
Application 09/577,231

4
monitoring, at the enterprise management system, at least one
parameter of the mapped network component, the at least one
parameter indicating an operational characteristic of the network
component that is indicative of a state of the service, wherein the state
of the service is indicative of a current level of service relative to an
agreed upon level of service in the service level agreement;

determining, at the enterprise management system, the state of
the service from the parameter of the monitored network component;
and

monitoring, at the enterprise management system, the state of
the service to provide service level management for the business
process that indicates the current level of service relative to the agreed
upon level of service.

Claims App., Br. 17-18.

C. The references relied upon

Taghadoss US 6,052,722 Apr. 18, 2000
Glitho US 6,233,449 B1 May 15, 2001
(filed Aug. 24, 1998)
Yemini US 6,249,755 B1 Jun. 19, 2001
(filed Jul. 15, 1997)
Bhoj US 6,304,892 B1 Oct. 16, 2001
(filed Nov. 02, 1998)

D. The rejections
Claim 4 stands rejected under 35 U.S.C. § 103(a) as unpatentable over
Bhoj in view of Yemini.
Claims 13-17, 19-35, 37-53, and 55-62 stand rejected under 35 U.S.C.
§ 103(a) as unpatentable over Yemini, Bhoj, and Taghadoss.
Appeal 2009-000882
Application 09/577,231

5
Claims 18, 36, and 54 stand rejected under 35 U.S.C. § 103(a) as
unpatentable over Yemini, Bhoj, and Taghadoss, further in view of Glitho.

PRINICIPLES OF LAW
"On appeal to the Board, an applicant can overcome a rejection by
showing insufficient evidence of prima facie obviousness or by rebutting the
prima facie case with evidence of secondary indicia of nonobviousness."
In re Kahn, 441 F.3d 977, 985-86 (Fed. Cir. 2006) (quoting In re Rouffet,
149 F.3d 1350, 1355 (Fed. Cir. 1998)).
For an obviousness rejection, the combination of references must
teach or suggest to a person of ordinary skill in the art all of the claim
limitations. 35 U.S.C. § 103(a).
Arguments not made are waived. See 37 C.F.R. § 41.37(c)(1)(vii)
("Any arguments or authorities not included in the brief or a reply brief . . .
will be refused consideration by the Board, unless good cause is shown.");
In re Watts, 354 F.3d 1362, 1367 (Fed. Cir. 2004) ("Just as it is important
that the PTO in general be barred from raising new arguments on appeal to
justify or support a decision of the Board, it is important that the applicant
challenging a decision not be permitted to raise arguments on appeal that
were not presented to the Board." (Footnote omitted.)). Cf. In re Baxter
Travenol Labs., 952 F.2d 388, 392 (Fed. Cir. 1991) ("It is not the function of
this court to examine the claims in greater detail than argued by an appellant,
looking for nonobvious distinctions over the prior art.").
Appeal 2009-000882
Application 09/577,231

6
DISCUSSION
Claim 4 - Bhoj and Yemini
Issues
Does the combination of Bhoj and Yemini teach: (1) "selecting one or
more network components on which the service depends from among the
plurality of network components"; (2) "mapping the one or more selected
network components to the service"; (3) "monitoring the one or more
selected network components to determine the state of the service"; and
(4) "when the state of the service changes, determining a cause of the change
in the state of the service by performing an action"?

Contentions
The Examiner finds that Bhoj teaches the steps of selecting, mapping,
monitoring a network component, and monitoring a state of the service, but
does not teach that when the state of the service changes, determining a
cause of the change by one of the recited actions (Final Rej. 2-3; Ans. 4).
The Examiner finds that Yemini teaches at column 8, lines 17-67, selecting a
network component, mapping the network component to a service,
monitoring the state of the component to detect a change in state, and when
the state of the service changes, determining a cause of change in the state of
the service by performing an action (Final Rej. 3; Ans. 4-5). The Examiner
concludes that it would have been obvious to combine Yemini with Bhoj,
"because mapping out where a problem is occurring in a network can aid in
finding a resolution to fix said network problem" (Final Rej. 4; Ans. 5).
Appeal 2009-000882
Application 09/577,231

7
Appellant argues that neither Bhoj nor Yemini, alone or in
combination, teaches, discloses, or suggests: (1) "selecting one or more
network components on which the service depends from among the plurality
of network components"; (2) "mapping the one or more selected network
components to the service"; (3) "monitoring the one or more selected
network components to determine the state of the service"; and (4) "when
the state of the service changes, determining a cause of the change in the
state of the service by performing an action."
Appellant argues that neither Bhoj nor Yemini teaches "selecting one
or more network components on which the service depends from among the
plurality of network components." It is argued that Bhoj relates to SLAs and
does not disclose or suggest that the SLAs include a selection of one or more
network components (Br. 7-8). It is argued that Bhoj states that the
components of an SLA include the parties, the service objectives, etc.
(col. 6, lines 24-27), and none of these components teach selecting network
components (Br. 8). It is argued that Bhoj precludes selecting network
components in the manner claimed, because Bhoj prevents any one domain
from having complete access to each of the data service systems; for
example, Bhoj teaches providing an abstract view of the underlying data
service system that is independent of the underlying implementation (Br. 8).
It is argued that Yemini does not teach the "selecting" limitations (Br. 8-9).
Appellant argues that neither Bhoj nor Yemini teaches "mapping the
one or more selected network components to the service." It is noted that the
Examiner relies on column 8, lines 17-67 of Yemini, where components
Appeal 2009-000882
Application 09/577,231

8
entered into the system are automatically "selected" to be monitored.
However, Appellant argues that Yemini relates only to describing or
representing network components without reference to services (Br. 9). It is
noted that the Examiner also relies on Bhoj, column 9, lines 25-52 for
"selecting" and "mapping" (Final Rej. 13). Appellant argues that this does
not teach "selecting" because Bhoj "does not selectively choose one or more
network components that a service depends on" (Br. 10) because it collects
all management data, and does not teach "mapping" because Bhoj teaches
providing an abstract view of the underlying data service system that is
independent of the underlying implementation (Br. 10-11).
Appellant argues that neither Bhoj nor Yemini teaches "monitoring
the one or more selected network components to determine the state of the
service." It is argued that Bhoj describes managing data between a
requesting system and a responding system without giving the requesting
system complete access to the responding data service system and that does
not teach monitoring one or more selected network components (Br. 11).
Appellant argues that Yemini does not teach or suggest actively monitoring
components (Br. 11-12).
Appellant argues that neither Bhoj nor Yemini teaches "when the state
of the service changes, determining a cause of the change in the state of the
service by performing an action . . . for at least the reason that neither Bhoj
nor Yemini, either alone or in combination, provide [sic] awareness over the
'state of the service'" (Br. 12).

Appeal 2009-000882
Application 09/577,231

9
Facts - contents of Bhoj
Bhoj describes that in independently administered control domains of
a network, the system administrator in one control domain is not able to
access another control domain to detect problems in that control domain, or
to measure service performance of the other data service system unless the
system administrator is given access to the other control domain (col. 2,
ll. 4-13). Bhoj relates to a management system for accessing selective
management data and/or measurement information in accordance with a
predetermined service agreement from a number of independently
administered data service systems (col. 2, ll. 38-54).
Figure 3 of Bhoj shows a data access network system 30 that includes
a number of independently administered data service systems 31-33
connected together via a network 34 (col. 3, ll. 53-61). The data access
network system 30 includes a management system formed of a number of
service management systems 31a-33a, each located in one the data service
systems 31-33 (col. 3, l. 62 - col. 4, l. 1). Each service management system
31a-33a can provide selective management data of the underlying data
service system to another requesting service management system located in
another data service system in accordance with a predetermined service level
agreement between the two domains (col. 4, ll. 1-9).
Bhoj describes that service level agreements (SLAs) are used to define
agreements among the data service systems 31-33 to share resources, and to
allow each of the data service systems to offer service quality guarantees to
their respective customers (col. 5, l. 67, to col. 6, l. 4). An SLA is a contract
Appeal 2009-000882
Application 09/577,231

10
between the provider and the user that specifies the level of service expected
during its term. An SLA can specify levels of service such as 100%
availability of the backbone of the service provider, average monthly latency
of not more than 85 milliseconds round-trip, notification of outage within 15
minutes of an outage, installation by a quoted date, etc. (col. 6, ll. 28-61).
The SLAs are converted into a contract specification (contract) to be used by
the service management systems (col. 7, ll. 22-25). Bhoj states:
A contract specification is derived from an SLA to indicate the service
attributes that are meaningful for correct service behavior. The
contract specification contains both the service attributes and the
bounds within which the service attributes must stay in order for the
service to behave in a desired manner. Attributes must both be
quantifiable and measurable to be included in a contract specification.

Col. 7, ll. 25-32.
Bhoj describes that the "service model" of the corresponding data
service system offers the agreed data service as follows:
A service model of a data service system describes the service
implemented by the corresponding data service system as well as the
dependencies between the service components within the data service
system. The service model identifies the various components of the
data service system that enable the service. For example, if the
service being managed is electronic mail, the service model would list
the components as the e-mail server host, the networks connecting the
e-mail host to the Internet, the e-mail application itself, the name
server used to resolve host names to Internet addresses, and so on.
The service model also expresses interdependencies that exist among
the different components of the service. From the above e-mail
example, all components identified in the service model should
function properly for the e-mail service to work. The
interdependencies capture the cause and effect between the
Appeal 2009-000882
Application 09/577,231

11
components of a service. The service model also identifies the
measurements and metrics that are available from each component.
Thus, the e-mail server could identify the number of e-mail
transactions, and active measurements could be used to get an
estimate of the response time seen by e-mail clients. . . . As described
above, a service model information includes customer dependent data
and system dependent data. [Emphasis added.]

Col. 9, ll. 25-52.
Figure 5 of Bhoj shows a service management system 100, which can
be one of the service management systems 31a-33a of Figure 3. The service
management system 100 includes a service manager 200 connected to a
contract repository 210 to receive contract templates. Bhoj describes
connection to a local system 240:
The service manager 200 is also connected to a local
measurement/management system 240 (hereinafter referred to as local
system 240). The local system 240 provides all management data of
the data service system within which the service management system
100 is located to the service manager 200. The local system 240
collects all the management data from the local infrastructure and
applications of the underlying data service system of the service
management system 100. Based on the management data collected,
the local system 240 provides an abstract view of the underlying data
service system to the service manager 200 that is independent of the
underlying implementation. The service manager 200 uses software
and/or hardware tools as means to obtain the management data and to
provide the abstract view. [Emphasis added.]

Col. 11, ll. 24-38.
Bhoj further describes connection to a service model module 260:
The service manager 200 is also connected to a service model
module 260. The service model module 260 stores the service model
Appeal 2009-000882
Application 09/577,231

12
information of the data service system within which the service
management system 100 is located. As described above, the service
model includes a description of the service that the data service
system of the service management system 100 is managing as well as
the dependencies between the service components of the underlying
data service system.

Col. 12, ll. 19-27.

Analysis
Bhoj describes that the "service model of a data service system
describes the service implemented by the corresponding data service system
as well as the dependencies between the service components within the data
service system" (col. 9, ll. 25-28). The service model is stored in the service
model module 260, which is part of the service management system 100 of
Figure 5 located in a data service system 31-33 of Figure 3. We interpret the
"service implemented by the corresponding data service system" to
correspond to the claimed "service supported by a network" in claim 4.
Bhoj describes:
The service model identifies the various components of the data
service system that enable the service. For example, if the service
being managed is electronic mail, the service model would list the
components as the e-mail server host, the networks connecting the
e-mail host to the Internet, the e-mail application itself, the name
server used to resolve host names to Internet addresses, and so on.

Col. 9, ll. 28-35. We find that identifying components that enable the
service teaches the claim limitations of "selecting one or more network
components on which the service depends from among the plurality of
network components" and "mapping the one or more selected network
Appeal 2009-000882
Application 09/577,231

13
components to the service." That is, in the example, the e-mail service
depends on the e-mail server host, the networks connecting the e-mail host
to the Internet, and so on. These components are "mapped" to the e-mail
service because they are identified with the service. "Mapping" only
requires some association between components and the service, e.g., the
"component-to-service parameter mapping" can be declaring that some
component parameter is a service parameter (a one-to-one mapping)
(Spec. 33: 12-21).
Appellant argues that the SLA relied upon by the Examiner does not
teach or suggest the "selecting" or "mapping" steps (Br. 7-9). It is argued
that Yemini does not cure the deficiencies of Bhoj (Br. 8-11). It is argued
that the Examiner's reasoning that the claim language could be interpreted as
all network components being selected relies on the incorrect presumption
that the service depends on every component of a network (Reply Br. 2). It
is argued that the Examiner fails to identify any passage of Bhoj or Yemini
that teaches the "selecting" and "mapping" steps (Reply Br. 3). Appellant
argues (Reply Br. 3) that the Examiner's finding that Bhoj teaches
"selecting" because "the system 'selects' [an] error to find out why it is in
error" (Ans. 16) does not address the claim language of "selecting one or
more network components on which the service depends." It is argued that
Bhoj and Yemini do not disclose mapping (Br. 9; Reply Br. 4).
We review the teachings of the references, not just the Examiner's
reasoning. The Examiner pointed to column 9, lines 25-52, at page 13 of the
Final Rejection, and we find that this part of Bhoj teaches the limitations of
Appeal 2009-000882
Application 09/577,231

14
"selecting" and "mapping" as discussed above. Bhoj teaches that "the
management data are abstract or derived measurements computed from
element level measurements" (col. 15, ll. 12-14), which indicates that
components identified as enabling a service are selected and measured.
Bhoj's teaching that the local system 240 provides an abstract view "that is
independent of the underlying implementation" (col. 11, l. 35) does not
suggest that components are not identified and measured, but only that the
component measurements are presented in an abstract view.
Bhoj describes that the "service model also identifies the
measurements and metrics that are available from each component" (col. 9,
ll. 41-43). The local measurement/management system 240 (local
system 240) in Figure 5 "collects all the management data from the local
infrastructure and applications of the underlying data service system of the
service management system 100. Based on the management data collected,
the local system 240 provides an abstract view of the underlying data service
system to the service manager 200 that is independent of the underlying
implementation." (Col. 11, ll. 29-35.) The measurement data is stored as
attributes in a cache 301 in Figure 7 (col. 11, l. 66 to col. 12, l. 6). The
system dependent data of the service model is stored in a system dictionary
312, which controls the storage 301 to receive the management data (col. 14,
ll. 22-24). "[T]he management data are abstract or derived measurements
computed from element level measurements." (Col. 15, ll. 12-14). Thus,
Bhoj teaches "monitoring the one or more selected network components" by
the local system 240. The fact that the local system 240 takes element
Appeal 2009-000882
Application 09/577,231

15
(component) level measurements and converts them into an abstract view is
not precluded by the claim language.
Appellant's arguments that Bhoj does not teach "monitoring" because
there is no complete access to a data system is not persuasive. Bhoj provides
monitoring within the data service system.
Bhoj describes that in response to a request for verification, the
service manager loads the contract template into the contract template
module 302 and loads customer dependent data from the customer SLA
database 310 into the verification interface 303. The contract template
module causes the storage 301 to obtain the actual system management data
of the underlying data service system, and "[t]hen the contract template is
evaluated in the contract template module 302 by computing the values of
the assertions defined in the contract template using the attribute values and
customer-specific data (i.e., parameters, bounds, and thresholds)" (col. 15,
ll. 18-22). Since Bhoj monitors the network components to determine
whether the performance meets the service contract, Bhoj teaches
"monitoring the one or more selected network components to determine the
state of the service" and "monitoring the state of the service to detect a
change in the state."
Bhoj reports the state of the service(s), that is, the extent to which the
guarantees offered in the SLA are met. For example, Figure 10, although
not described in Bhoj, shows the extent of service conformance for several
service components, including ISP access and a mail system.
Appeal 2009-000882
Application 09/577,231

16
Bhoj does not describe "when the state of the service changes,
determining a cause of the change in the state of the service by performing
an action." The rejection relies on Yemini for this step and the specific
actions. Yemini describes a method for determining the source of a problem
in a complex system of managed components (Abstract), including computer
networks (col. 1, ll. 15-22). The Examiner concludes that one of ordinary
skill in the art would have been motivated to determine a cause of a problem
with the state of the service in Bhoj using the method of Yemini. Appellant
argues that the combination of Bhoj and Yemini does not teach or suggest
"when the state of the service changes, determining a cause of the change in
the state of the service by performing an action" for at least the reason that
neither provides awareness over the "state of the service" (Br. 12). Bhoj
determines monitoring the state of the service, and Yemini is only required
to show that it was known to take action to determine the cause of a problem
in a communication system. Appellant does not contest this teaching of
Yemini or the motivation to combine in the Briefs. Although Appellant
raised the issue of motivation to combine at the oral hearing, it was noted
that this argument was not supported by the Briefs--we do not know what
the Examiner would have said if presented with the argument. In
conclusion, the limitation, "when the state of the service changes,
determining a cause of the change in the state of the service by performing
an action," would have been obvious over Yemini.

Conclusion
Appeal 2009-000882
Application 09/577,231

17
The combination of Bhoj and Yemini teaches or suggests:
(1) "selecting one or more network components on which the service
depends from among the plurality of network components"; (2) "mapping
the one or more selected network components to the service";
(3) "monitoring the one or more selected network components to determine
the state of the service"; and (4) "when the state of the service changes,
determining a cause of the change in the state of the service by performing
an action." The rejection of claim 4 is affirmed.

Claims 13-17, 19-35, 37-53, and 55-62 - Yemini, Bhoj, and Taghadoss
Appellant argues that Yemini and Bhoj, alone or in combination, fail
to teach or suggest the features of: (1) "mapping at least one component of
the network on which the service depends to the service"; (2) "monitoring
. . . at least one parameter of the mapped network component, the at least one
parameter indicating an operational characteristic of the network component
that is indicative of a state of the service"; and (3) "monitoring . . . the state
of the service to provide service level management for the business process
that indicates the current level of service relative to the agreed upon level of
service," as recited in claim 13, and the similar features in claims 27 and 49
(Br. 12-14). It is argued that the Examiner errs in finding that "Taghadoss
teaches associating a component of the network to the service" because
Taghadoss is limited to information associated with the network resources
themselves and not mapping to a service (Br. 13).
We agree with Appellant that Taghadoss does not teach mapping to a
service, but for the reasons discussed with respect to claim 4, we find that
Appeal 2009-000882
Application 09/577,231

18
Bhoj describes the argued limitations. Accordingly, the rejection of
claims 13-17, 19-35, 37-53, and 55-62 is affirmed.

Claims 18, 36, and 54 - Yemini, Bhoj, Taghadoss, and Glitho
Appellant argues that Glitho fails to cure the deficiencies of Yemini,
Bhoj, and Taghadoss with respect to the rejection of independent claims 13,
27, and 49 (Br. 14-15). Because Appellant does not argue the separate
patentability of claims 18, 36, and 54 but relies on the patentability of the
independent claims, the rejection of claims 18, 36, and 54 stands or falls
with the rejection of the independent claims. Accordingly, the rejection of
claims 18, 36, and 54 is affirmed.

CONCLUSION
The rejections of claims 4 and 13-62 under 35 U.S.C. 103(a) are
affirmed.
Requests for extensions of time are governed by 37 C.F.R. § 1.136(b).
See 37 C.F.R. § 41.50(f).
AFFIRMED

erc

PILLSBURY WINTHROP SHAW PITTMAN, LLP
P.O. BOX 10500
McLEAN, VA 22102b