Ex Parte Aman et al

Board of Patent Appeals and Interferences

Jul 27, 2011

10428893 (B.P.A.I. Jul. 27, 2011)

UNITED STATES PATENT AND TRADEMARK OFFICE
____________________

BEFORE THE BOARD OF PATENT APPEALS
AND INTERFERENCES
____________________

Ex parte JEFFREY D. AMAN, DAVID V. BOSTJANCIC, DONNA N.
ENG DILLENBERGER, GREGORY M. DRITSCHLER, MARK F.
HULBER, MARK W. JOHNSON, HIREN R. SHAH, ALAN M. WEBB,
and PETER B. YOCOM
____________________

Appeal 2009-010776
Application 10/428,893
Technology Center 2100
____________________

Before HOWARD B. BLANKENSHIP, THU A. DANG,
and DEBRA K. STEPHENS, Administrative Patent Judges.

DANG, Administrative Patent Judge.

DECISION ON APPEAL

Appeal 2009-010776
Application 10/428,893

2
I. STATEMENT OF THE CASE
Appellants appeal under 35 U.S.C. § 134(a) from a Final Rejection of
claims 1-8, 11-18, and 21-28. We have jurisdiction under 35 U.S.C. § 6(b).
We affirm.

A. INVENTION
Appellants’ invention relates to Application Response Measurement
(ARM) Application Programming Interface (API) and method that reports
the workload of a distributed transaction processing environment; wherein, a
hop count indicating the depth of the application in the call tree is passed
within a correlator by a parent application to a child application to construct
the topology of the transaction processing environment (Abstract; Spec.
17:8-19:2).

B. ILLUSTRATIVE CLAIM
Claim 1 is exemplary:
1. A method of providing workload reporting in a
distributed transaction processing environment having a
call tree in which a child application performs a child
transaction on behalf of a parent application performing a
parent transaction, each of said applications being at a
given depth in said call tree, said method comprising the
steps of:

associating with each of said applications a hop count
indicating the depth of said application in said call tree;
and

using the hop count associated with each of said
applications to construct a topology of said transaction
processing environment in which said applications are
Appeal 2009-010776
Application 10/428,893

3
represented in accordance with their depth in said call
tree and in which performance data collected for said
applications is organized in accordance with the hop
counts assigned to said applications.

C. REJECTIONS
The prior art relied upon by the Examiner in rejecting the claims on
appeal is:
Bare US 6,580,715 B1 Jun. 17, 2003
Johnson, Tivoli Systems, The Application Response Measurement
(ARM) API, Version 2, Dec. 1997.

Garg et al., HP Labs, Web Transaction Analysis and Optimization
(TAO), Feb. 28, 2002.

Claims 1-3, 8, 11-13, 18, 21-23, and 28 stand rejected under 35 U.S.C.
§ 103 (a) as being unpatentable over Johnson in view of Bare.
Claims 4-7, 14-17, and 24-27 stand rejected under 35 U.S.C. § 103 (a)
as being unpatentable over Johnson in view of Bare and Garg.

II. ISSUES
The issues are whether the Examiner has erred in determining that:
1. the combination of Johnson and Bare would have suggested “using
the hop count associated with each of said applications to construct a
topology of said transaction processing environment in which said
applications are represented in accordance with their depth in said call tree
and in which performance data collected for said applications is organized
in accordance with the hop counts assigned to said applications” (claim 1,
emphasis added) and
Appeal 2009-010776
Application 10/428,893

4
2. one would have been motivated to include the hop count indicator
disclosed in Bare within the correlator disclosed in Johnson.

III. FINDINGS OF FACT
The following Findings of Fact (FF) are shown by a preponderance of
the evidence.
Johnson
1. Johnson is directed to an Application Response Measurement
(ARM) Application Programming Interface (API) for monitoring and
measuring the application performance in a distributed transaction
processing environment (col. 1:38-col. 2:10; col. 4: 28-32; and col. 10:42-
44).
2. In practice many client/server transactions consist of nested
subtransactions; wherein, when a user requests a client to perform some
action (a parent transaction), the client processes the transaction until it
needs service from Server B then passes the transaction on to Server B,
spawning a child transaction (col.13:15-28 and col. 14:20-40). Server B
processes this child transaction and may decide to divide the transaction into
two child transactions for Servers C and D to process (id.). The application
can provide correlation information about parent/child relationships along
with each transaction; wherein, client/server passes a correlator having
parent/child information needed to know how the transactions and
subtransactions relate to each other (id.).
3. An ARM agent monitors how long the transaction takes and a
Correlation Application (management application) uses this performance
information along with all correlation information regarding the parent/child
Appeal 2009-010776
Application 10/428,893

5
relationships to determine why there may have been a delay in a transaction
(Figs. 1, 3, and 5; col. 11:25-col. 12:26; and col. 15:5-8). The correlator for
the parent transaction is sent in the arm_start call (a call that indicates an
instance of a transaction has begun) (col.8:19-20 and col. 12:23-25). Other
transaction metrics can be passed on with the arm_start call (id.).
Bare
4. Bare is directed to a load balancing switch protocol that passes
a hop count indicator within a switch cost packet through a network to
indicate the cost and hop count of a particular path (Fig. 11; col. 1, ll. 25-30;
and col. 27, ll. 30-32). The packet is sent from switch to switch,
incrementing the hop count along the way (col. 29, ll. 29-31).

IV. ANALYSIS
Claims 1-3, 8, 11-13, 18, 21-23, and 28
Appellants do not provide separate arguments with respect to
independent claims 1, 11, and 21 (App. Br. 8-13). Further, Appellants do
not provide separate arguments with respect to claims 2, 3, 8, 12, 13, 18, 22,
23, and 28 depending from claims 1, 11, and 21. Accordingly, we select
independent claim 1 as being representative of the claims. See 37 C.F.R. §
41.37(c)(1)(vii).
Appellants contend that the “correlators passed between parent
transactions and child transaction” disclosed in Johnson “do not by
themselves indicate the ‘nestedness’ of a particular transaction in the
transaction hierarchy represented by a call tree” or “the significance of the
degree of nestedness of a particular transaction” (App. Br. 10).
Appeal 2009-010776
Application 10/428,893

6
Appellants argue further that “Bare does not suggest organizing
collected performance data in accordance with assigned hop counts” since
“the switch cost packet … is not ‘organized in accordance with the hop
counts’”(App. Br. 12).
Appellants argue that Bare “does not provide a motivation for
maintaining such a hop count in applicants’ claimed transaction processing
environment” (App. Br. 11). Appellants assert further that “Examiner’s
combining of these references can hardly be justified on the ground of any
relevant ‘teaching’” since “the differences between the two references … are
glaring and militate against combining them in the manner suggested” (id.).
The Examiner, however, finds that “Johnson does indeed teach a call
tree depicting parent-child relationships between transactions” (Ans.10).
The Examiner finds that the disclosure of “‘T1 is the parent of T2 … and T2
is the parent of T3[]’ … clearly indicates ‘nestedness’ of the transactions”
(Ans. 10-11). The Examiner finds further “that since the hop count is
incremented at each subsequent node, a particular hop count is indeed
indicative of the depth of a particular node and of the degree of nestedness”
(Ans. 11). The Examiner notes “that a motivation to combine references
need only be found in either reference or in the knowledge generally
available to one of ordinary skill in the art” and “that it is generally known to
one of ordinary skill in the art that transaction optimization and efficiency is
a motivation in itself” (Ans. 11-12). The Examiner finds further “that
Johnson teaches constructing a topology of the transaction processing
environment … and Bare teaches maintaining a hop count to aid in the
creation and analysis of topologies” (Ans. 12). The Examiner concludes that
Appeal 2009-010776
Application 10/428,893

7
both Johnson and Bare “strive to achieve optimal performance, including
minimizing delays and overhead” (id.).
Appellants’ argument that Johnson does not teach or suggest
“nestedness” and “a degree of nestedness” is not commensurate in scope
with the specific language of claim 1. In particular, claim 1 does not recite
such “nested ness” or “a degree of nestedness” as Appellants argue.
To determine whether the combination of Johnson and Bare teach or
would have suggested “associating with each of said applications a hop
count indicating the depth of said application in said call tree” and “using the
hop count … to construct a topology … in which said applications are
represented in accordance with their depth in said call tree and in which
performance data collected for said applications is organized in accordance
with the hop counts,” as required by claim 1, we give the claim its broadest
reasonable interpretation consistent with the Specification. See In re Morris,
127 F.3d 1048, 1054 (Fed. Cir. 1997). However, we will not read
limitations from the Specification into the claims. In re Van Geuns, 988
F.2d 1181, 1184 (Fed. Cir. 1993).
Claim 1 does not place any limitation on what “hop count” and
“topology” means, includes, or presents other than that “hop count”
“indicat[es] the depth of said application in said call tree” and “topology”
represents applications “in accordance with their depth in said call tree.”
Thus, we give “hop count” its broadest reasonable interpretation as the
corresponding number of successive calls made from a parent application to
a child application within a call tree, as consistent with the Specification and
as specifically defined in claim 1. Further, we give “topology” its broadest
reasonable interpretation as a mapping of the applications based upon their
Appeal 2009-010776
Application 10/428,893

8
respective positions within the call tree, as consistent with the Specification
and as specifically defined in claim 1.
Johnson is directed to an ARM API that monitors and measures the
application performance (FF 1), wherein the application provides correlation
information about parent/child relationships along with each transaction by
having the client/server to pass a correlator having the parent/child
information needed to know how the transactions and subtransactions relate
to each other (FF 2). An ARM agent monitors the performance of each
transaction and a Correlation Application uses this performance information
along with all correlation information to determine why a delay exists (FF
3). Particularly, since the Correlation Application (management
application) uses all correlation information regarding the parent/child
relationships (FF 3), we find this correlation information passed in the
correlator to represent the call tree having all parent/child information and
indicating the depth within the call tree. We find further that the Correlation
Application represents a management server that uses the correlation
information to build the mapping of the parent/child applications and
organizes the performance data relative to this mapping.
Bare is directed to a load balancing switch protocol that passes a hop
count indicator with a switch cost packet through a network to indicate the
cost of a particular path; wherein, each switch increments the hop count
when the packet is sent from switch to switch (FF 4). Accordingly, we find
Bare to disclose a hop count which represents the corresponding number of
successive calls made from a parent to a child within a call tree.
The Supreme Court has stated that “[t]he combination of familiar
elements according to known methods is likely to be obvious when it does
Appeal 2009-010776
Application 10/428,893

9
no more than yield predictable results.” KSR Int’l Co. v. Teleflex Inc., 550
U.S. 398, 416 (2007).
Thus, we find no error in the Examiner’s finding that the combination
of Johnson’s distributed transaction processing environment (including the
correlator) that measures application performance with the hop count
indicator, as disclosed in Bare, produces a distributed transaction processing
environment having a hop count associated with each subtransaction/call
which would have been obvious (Ans. 5 and 10-12; FF 1-4).
That is, in view of our claim construction above, we find the
combination of Johnson and Bare to teach or would have at least suggested
“associating each of said applications a hop count indicating the depth of
said application in said call tree” as claimed. We find further that the
combination would have at least suggested a management server that uses
this hop count to build the topology of the call tree and associates the
performance data with the hop counts, as specifically required by claim 1.
Accordingly, we find that Appellants have not shown that the
Examiner erred in rejecting independent claims 1, 11, and 21 and claims 2,
3, 8, 12, 13, 18, 22, 23, and 28 depending from claims 1, 11, and 21 under
35 U.S.C. § 103(a) over Johnson and Bare.
Claims 4-7, 14-17 and 24-27
Appellants do not provide arguments for claims 4-7, 14-17, and 24-27
separate from those of claims 1, 11, and 21 from which they respectively
depend (App. Br. 13). As Appellants have not shown the Examiner erred in
rejecting claims 1, 11, and 21, we also affirm the rejection of claims 4-7, 14-
17, and 24-27 over the combined teachings of Johnson, Bare, and Garg
under 35 U.S.C. § 103(a).
Appeal 2009-010776
Application 10/428,893

10
V. CONCLUSION AND DECISION
The Examiner’s rejection of claims 1-8, 11-18, and 21-28 under
35 U.S.C. § 103(a) is affirmed.
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).

AFFIRMED

peb