Ex Parte Boykin et al

Board of Patent Appeals and Interferences

Feb 19, 2010

10355530 (B.P.A.I. Feb. 19, 2010)

UNITED STATES PATENT AND TRADEMARK OFFICE
____________________

BEFORE THE BOARD OF PATENT APPEALS
AND INTERFERENCES
____________________

Ex parte JAMES RUSSELL BOYKIN, ALBERTO GIAMMARIA, BRIAN
JOSEPH SCHLOSSER, and KEVIN GARY TAPPERSON
____________________

Appeal 2009-003961
Application 10/355,530
Technology Center 2100
____________________

Decided: February 19, 2010
____________________

Before LANCE LEONARD BARRY, HOWARD B. BLANKENSHIP, and
THU A. DANG, Administrative Patent Judges.

DANG, Administrative Patent Judge.

DECISION ON APPEAL

Appeal 2009-003961
Application 10/355,530

I. STATEMENT OF CASE
Appellants appeal the Examiner’s final rejection of claims 1-21 under
35 U.S.C. § 134(a). We have jurisdiction under 35 U.S.C. § 6(b).
We affirm.

A. INVENTION
According to Appellants, the invention relates to a technique “for
determining the defining ClassLoader class of a Java class as it is being
defined within a Java Virtual Machine (JVM)” (Spec. 32, ll. 7-9).

B. ILLUSTRATIVE CLAIM
Claim 1 is exemplary and reproduced below:

1. A method for processing information, the method
comprising:

storing an identity of a class loader class that loads a
class into a virtual machine;

invoking a class load hook routine after the identity of
the class loader class has been stored; and

retrieving the stored identity of the class loader class in
response to invoking the class load hook routine.

C. REJECTION
The prior art relied upon by the Examiner in rejecting the claims on
appeal is:
Cohen US 6,072,953 Jun. 6, 2000
Judge US 6,430,570 Aug. 6, 2002
2
Appeal 2009-003961
Application 10/355,530

Claims 1-6, 8-13, and 15-20 stand rejected under 35 U.S.C. § 102(b)
as being anticipated by Cohen.
Claims 7, 14, and 21 stand rejected under 35 U.S.C. § 103(a) as being
unpatentable over Cohen in view of Judge.

II. ISSUES
Have Appellants shown that the Examiner erred in finding that Cohen
discloses:
1) “storing an identity of a class loader class that loads a class into
a virtual machine” (claim 1)?
2) “invoking a class load hook routine after the identity of the
class loader class has been stored” (claim 1)?
3) “retrieving the stored identity of the class loader class in
response to invoking the class load hook routine” (claim 1)?

III. FINDINGS OF FACT
The following Findings of Fact (FF) are shown by a preponderance of
the evidence.
Cohen
1) Cohen discloses a method for Java class file analysis and
modification (col. 5, ll. 12-13).
2) The method extends a ClassLoader class, via a
ClassTransformer sub-class registered with an instance of the ClassLoader
class, to include a ClassTransformer interface (col. 6, ll. 5-12; Fig. 4).
3
Appeal 2009-003961
Application 10/355,530

3) Before the ClassLoader class does any processing on the class
file, the class file contents are passed to the ClassTransformer interface (col.
6, ll. 30-32; Fig. 4).
4) The ClassTransformer interface uses its “select” method to
determine if a class is a valid target for modification (col. 4, l. 62 – col. 5, l.
4; col. 6, ll. 30-34).
5) If the class is a valid target, the ClassTransformer interface uses
its “transform” method to modify the class file (col. 5, ll. 5-11; col. 6, ll. 34-
37).
6) After transformation, the modified class file is passed from the
ClassLoader class to the Java Virtual Machine, where “it is loaded normally
and treated as if it had been originally received in its modified form” (col. 6,
ll. 37-40).

IV. PRINCIPLES OF LAW
Claim Interpretation
The claims measure the invention. See SRI Int’l v. Matsushita Elec.
Corp., 775 F.2d 1107, 1121 (Fed. Cir. 1985) (en banc). “[T]he PTO gives
claims their ‘broadest reasonable interpretation.’” In re Bigio, 381 F.3d
1320, 1324 (Fed. Cir. 2004) (quoting In re Hyatt, 211 F.3d 1367, 1372 (Fed.
Cir. 2000)). “Moreover, limitations are not to be read into the claims from
the specification.” In re Van Geuns, 988 F.2d 1181, 1184 (Fed. Cir. 1993)
(citing In re Zletz, 893 F.2d 319, 321 (Fed. Cir. 1989)).
35 U.S.C. § 102
In rejecting claims under 35 U.S.C. § 102, “[a] single prior art
reference that discloses, either expressly or inherently, each limitation of a
4
Appeal 2009-003961
Application 10/355,530

claim invalidates that claim by anticipation.” Perricone v. Medicis Pharm.
Corp., 432 F.3d 1368, 1375 (Fed. Cir. 2005) (citation omitted).
“Anticipation of a patent claim requires a finding that the claim at issue
“reads on” a prior art reference.” Atlas Powder Co. v. IRECO, Inc., 190
F.3d 1342, 1346 (Fed Cir. 1999). “In other words, if granting patent
protection on the disputed claim would allow the patentee to exclude the
public from practicing the prior art, then that claim is anticipated, regardless
of whether it also covers subject matter not in the prior art.” Id. (citations
omitted).
35 U.S.C. § 103(a)
Section 103 forbids issuance of a patent when “the differences
between the subject matter sought to be patented and the prior art are such
that the subject matter as a whole would have been obvious at the time the
invention was made to a person having ordinary skill in the art to which said
subject matter pertains.” KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 406
(2007). In KSR, the Supreme Court emphasized “the need for caution in
granting a patent based on the combination of elements found in the prior
art,” and discussed circumstances in which a patent might be determined to
be obvious. Id. at 415 (citing Graham v. John Deere Co., 383 U.S. 1, 12
(1966)). The Court reaffirmed principles based on its precedent that “[t]he
combination of familiar elements according to known methods is likely to be
obvious when it does no more than yield predictable results.” Id. at 416.

5
Appeal 2009-003961
Application 10/355,530

V. ANALYSIS
35 U.S.C. § 102
As to independent claim 1, Appellants acknowledge that Cohen
discloses “the relative situation of a class loader and a virtual machine,” but
argue that Cohen does not teach “an identity associated with the class loader
class, let alone storing that identity in the manner claimed” (App. Br. 13).
The Examiner finds that registering of Cohen’s “ClassTransformers
with their instance of the extended ClassLoader” teaches the recited storing
of a class loader class identity (Ans. 8; citing col. 6, ll. 11-16). That is, the
Examiner reads “an identity of a class loader class” of claim 1 on Cohen’s
ClassTransformer sub-class of the extended ClassLoader class.
Thus, the first issue we address on appeal is whether Cohen teaches
“storing an identity of a class loader class that loads a class into a virtual
machine” (claim 1).
We begin our analysis by giving the claims their broadest reasonable
interpretation. See In re Bigio, 381 F.3d at 1324. Furthermore, our analysis
will not read limitations into the claims from the specification. See In re
Van Geuns, 988 F.2d at 1184.
Claim 1 simply does not place any limitation on what “identity” and
“class loader class” mean, include, or represent, other than that the “class
loader class” is one “that loads a class into a virtual machine.” We therefore
interpret the “storing” step of claim 1 as reading on the storing of any
identifying feature, e.g., condition or character, of a class that is used to load
another class into a virtual machine.
Cohen discloses a method for Java class file analysis and modification
(FF 1). The method registers the ClassTransformer sub-class with an
6
Appeal 2009-003961
Application 10/355,530

instance of the ClassLoader class, which extends the ClassLoader class to
include a ClassTransformer interface (FF 2). Before a class is defined, the
contents of the class file are passed to the ClassTransformer interface (FF 3),
which uses its “select” method to determine if the class should be modified
(FF 4) and its “transform” method to perform the modification (FF 5). The
modified class file is passed from the ClassLoader class to the Java Virtual
Machine, where it is defined in its modified form (FF 6).
A skilled artisan would have understood Cohen’s ClassLoader class,
which passes the modified class files to the Java Virtual Machine, as a “class
loader class that loads a class into a virtual machine” (claim 1). Since
Cohen’s ClassTransformer sub-class is part of (and inherits properties of)
the ClassLoader class, the skilled artisan would have understood the
ClassTransformer sub-class as an identifying feature, e.g., condition or
character, of the ClassLoader class; and, in turn, understood the registering
of the ClassTransformer sub-class as “storing an identity of a class loader
class that loads a class into a virtual machine” (claim 1).
Accordingly, Appellants have not shown the Examiner erred in
finding that Cohen teaches the “storing” step of claim 1.
Appellants further argue that the “invoking” step of claim 1 “subjects
the invocation of the standard JVMPI class load hook to the storage of the
class loader identity,” and that Cohen therefore cannot teach the “invoking”
step because it “contains no disclosure about storing the identity of a class
loader” (App. Br. 14-15).
The Examiner finds that the “invoking” step reads on Cohen’s
ClassTransformer interface and the use of its “transform” method (Ans. 9).
7
Appeal 2009-003961
Application 10/355,530

Thus, another issue we address on appeal is whether Cohen teaches
“invoking a class load hook routine after the identity of the class loader class
has been stored” (claim 1).
In view of our finding that Cohen’s registering of the
ClassTransformer sub-class teaches the “storing” step of claim 1, we find
Appellants’ argument unpersuasive.
Furthermore, Appellants’ disclosure defines a “class load hook” as a
routine that “allows a Java class to be modified” (Spec. 2, ll. 1-6). Since
Cohen’s “transform” method modifies a class (FF 5) after registering of the
ClassTransformer sub-class (FF 2), a skilled artisan would have understood
Cohen’s method as “invoking a class load hook routine after the identity of
the class loader class has been stored” (claim 1).
Accordingly, Appellants have not shown the Examiner erred in
finding that Cohen teaches the “invoking” step of claim 1.
Appellants also argue that Cohen does not teach the “retrieving” step
of claim 1 because the cited disclosure “simply states that a select method
returns true if a class provided by a user is a valid target for transformation”
(Reply Br. 3).
The Examiner finds that “Cohen teaches using the select method to
retrieve the identity of the class loader class in response to invoking the class
load hook routine (transform method)” (Ans. 10).
Thus, another issue we address on appeal is whether Cohen teaches
“retrieving the stored identity of the class loader class in response to
invoking the class load hook routine” (claim 1).
Claim 1 simply does not place any limitation on what “retrieving the
stored identity” means, includes, or represents, other than that the “stored
8
Appeal 2009-003961
Application 10/355,530

identity of the class loader class” is retrieved “in response to invoking the
class load hook routine.” We therefore interpret the “retrieving” step of
claim 1 as reading on any determination of the “stored identity of the class
loader class” in response to “invoking the class load hook routine.”
Cohen’s ClassTransformer sub-class and its “transform” method are
respectively applied, above, to the “stored identity of the class loader class”
and “class load hook routine” of claim 1. A skilled artisan would have
understood the ClassTransformer sub-class as being determined in response
to the invoking of its “transform” method; and, in turn, understood Cohen’s
method as “retrieving the stored identity of the class loader class in response
to invoking the class load hook routine.”
Accordingly, Appellants have not shown the Examiner erred in
finding that Cohen teaches the “retrieving” step of claim 1.
For the above reasons, Appellants have not shown the Examiner erred
in rejecting claim 1. We therefore affirm the rejection of claim 1, and
dependent claims 3-6 falling therewith, under 35 U.S.C. § 102(b) as being
anticipated by Cohen.
As Appellants do not provide separate arguments for independent
claims 8 and 15, those claims fall with representative claim 1. See 37 C.F.R.
§ 41.37(c)(1)(vii). We therefore also affirm the rejection of claims 8 and 15,
and their dependent claims 10-13 and 17-20 falling therewith, under 35
U.S.C. § 102(b) as being anticipated by Cohen.
Claim 2 depends from claim 1 and recites “using the stored identity of
the class loader class to modify information associated with the class before
the class is defined by the virtual machine.”
9
Appeal 2009-003961
Application 10/355,530

Appellants argue that because “Cohen does not teach anything related
to storing an identity of a class loader in the manner of claim 1, Cohen also
does not teach using the stored identity in the manner of claim 2” (App. Br.
17). As Appellants have not shown that Cohen fails to teach the “storing”
step of claim 1, we find this argument unpersuasive.
Accordingly, Appellants have not shown the Examiner erred in
rejecting claim 2. We therefore affirm the rejection of claim 2, and claims 9
and 16 falling therewith, under 35 U.S.C. § 102(b) as being anticipated by
Cohen.
35 U.S.C. §103(a)
Claim 7 depends from claim 1 and recites “invoking an instrumented
method within the class loader class, wherein the instrumented method is a
‘defineclass’ method for the class loader class; and saving the identity of the
class loader class within an instrumented version of a native ‘defineClass0’
method.”
Appellants acknowledge that “Judge teaches how the defineclass
method works within the class loader,” but argue that a “standard defineclass
method does not teach specific instrumentation of a different method
defineclass0 as recited in claim 7” because “[m]any more discrete teachings
are required to find that defineclass suggests a defineClass0, a defineclass0
suggests a storing capability, and that the storing capability of defineclass0
method is used for storing a class loader’s identity” (App. Br. 21).
Claim 7 simply does not place any limitation on what “defineclass”
means, includes, or represents, other than that it is invoked as an
instrumented method within the class loader class. Therefore, contrary to
Appellants’ argument, we do not interpret the step of “invoking … a
10
Appeal 2009-003961
Application 10/355,530

‘defineclass’ method” as suggesting a “defineClass0” method. As such, we
find Appellants’ argument unpersuasive.
Further, we note that the Appeal Brief’s summary of claimed subject
matter cites step 608 of Appellants’ Figure 6 as supporting the recited step of
“invoking … a ‘defineclass’ method” (App. Br. 7). Step 608 appears to be
identical to the admitted prior art step 508 of Appellants’ Figure 5. We see
no reason why this prior art step patentably distinguishes over the allegedly
standard “defineclass” method of Judge.
Claim 7 also does not place any limitation on what “native
‘defineclass0’ method” means, includes, or represents, other than that “the
identity of the class loader class” is saved “within an instrumented version of
a native ‘defineClass0’ method.” Appellants argue that this language
suggests a capability to store the class loader’s identity. This argument
“merely points out what a claim recites” without specifying how the feature
patentably distinguishes over the applied art. 37 C.F.R. § 41.37(c)(vii); see
also 37 C.F.R. § 1.111(b). Thus, we find the argument unpersuasive.
Further, we note that the Appeal Brief’s summary of claimed subject
matter cites step 614 of Appellants’ Figure 6 as supporting the recited step of
“saving the identity … within … a native ‘defineClass0’ method” (App. Br.
7). With respect to step 614, Appellants’ disclosure states, “The
‘ClassLoader.probe$defineC1assO’ method invokes the
‘C1assLoaderMap.put’ method (step 612), which saves the identity of
ClassLoader ‘Y’ as the defining ClassLoader for class ‘X’ in an appropriate
data structure (step 614)” (Spec. 21, ll. 8-12; Board’s emphasis). Thus, for
whatever “native ‘defineclass0’ method” may mean, we interpret the step of
“saving the identity … within … a native ‘defineClass0’ method” as reading
11
Appeal 2009-003961
Application 10/355,530

on the mere storing of an “identity” within a data structure. As explained
with respect to claim 1, a skilled artisan would have understood the
registering of Cohen’s ClassTransformer sub-class as teaching this feature.
Accordingly, Appellants have not shown the Examiner erred in
rejecting claim 7. We therefore affirm the rejection of claim 7, and claims
14 and 21 falling therewith, under 35 U.S.C. § 103(a) as being unpatentable
over Cohen in view of Judge.

VI. CONCLUSIONS
Appellants have not shown that the Examiner erred in finding that
claims 1-6, 8-13, and 15-20 are anticipated by the teachings of Cohen.
Appellants have not shown that the Examiner erred in finding that
claims 7, 14, and 21 are unpatentable over the teachings of Cohen in view of
Judge.

VII. DECISION
The Examiner’s decision rejecting claims 1-6, 8-13, and 15-20 under
35 U.S.C. § 102(e) is affirmed.
The Examiner’s decision rejecting claims 7, 14, and 21 under
35 U.S.C. § 103(a) is affirmed.
12
Appeal 2009-003961
Application 10/355,530

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

IBM CORP (YA)
C/O YEE & ASSOCIATES PC
P.O. BOX 802333
DALLAS, TX 75380
13