Ex Parte Cuomo et al

Board of Patent Appeals and Interferences

Jun 30, 2010

09907848 (B.P.A.I. Jun. 30, 2010)

UNITED STATES PATENT AND TRADEMARK OFFICE
____________

BEFORE THE BOARD OF PATENT APPEALS
AND INTERFERENCES
____________

Ex parte GENNARO A. CUOMO, MATT RICHARD HOGSTROM, and
NATARAJ NAGARATNAM
____________

Appeal 2009-005894
Application 09/907,848
Technology Center 2400
____________

Decided: June 30, 2010
____________

Before JOHN A. JEFFERY, KEVIN F. TURNER, and THOMAS S. HAHN,
Administrative Patent Judges.

TURNER, Administrative Patent Judge.

DECISION ON APPEAL
STATEMENT OF THE CASE
Appellants appeal under 35 U.S.C. § 134 from the final rejection of
claims 1, 4-9, 11-15, 21, 24-29, 31, 34-39, and 41-45. We have jurisdiction
under 35 U.S.C. § 6(b).
We AFFIRM.
Appellants’ disclosure relates to a method, apparatus, and computer
implemented instructions for enforcing security policies for security
unaware applications (Spec. p. 1, ll. 8-12).
Appeal 2009-005894
Application 09/907,848

2
Independent claim 1 is illustrative of the invention and reads as
follows:

1. A computer-implemented method for enforcing security
policies, the method comprising:

responsive to loading a class in a class loader, determining
whether a security policy exists for the class prior to the class
being executed by the class loader, wherein the determining
step includes analyzing a policy file, and wherein the security
policy is determined to exist for the class if a class name of the
class is present in the policy file; and

responsive to a determination that the security policy exists for
the class, inserting a set of bytecodes, as specified by the
security policy for the class, into bytecodes of the class,
wherein the set of bytecodes inserted determines security
privileges for access to resources of the class based on the
security policy, and wherein the determining and inserting steps
are performed after the class is developed.

The Examiner relies on the following prior art references to show
unpatentability:
Peterka US 6,948,183 B1 Sep. 20, 2005

Geoff A. Cohen et al., Automatic Program Transformation with JOIE,
Proceedings of the 1998 USENIX Annual Technical Symposium, pp. 1-12
(1998) (hereinafter “Cohen”).

Claims 1, 4-9, 11-15, 21, 24-29, 31, 34-39, and 41-45 stand rejected
under 35 U.S.C. § 103(a) as being obvious over Cohen and Peterka.

ISSUE
Appellants argue that Cohen fails to describe any type of security
policy or policy file (Br. 12-13), and also Peterka does not disclose that
Appeal 2009-005894
Application 09/907,848

3
bytecodes are inserted per the security policy for the class that is being
loaded (Br. 13-14). Appellants also argue that, in Peterka, the application
that is checked for proper permission is already required to be executing, not
as recited in claim 1: “prior to the class being executed by the class loader”
(Br. 14), and that one of ordinary skill in the art would not have been
motivated to combine Cohen and Peterka because the authors of Cohen
acknowledge that they did not know how to implement security in their code
transformation procedures (Br. 15).
The Examiner finds that Cohen’s disclosure of a specific subset of
classes is a policy file (Ans. 6), and that Cohen teaches the insertion of
bytecodes of a class, so that the combination of Cohen and Peterka would
suggest the same (Ans. 7). The Examiner also finds it would have been
obvious to provide checking prior to executing a class because that is when
policy checking is performed, as opposed to Peterka’s policies with
permissions which are defined at class loading time (Ans. 7). The Examiner
also finds that the combination would have been motivated and the question
posed by Cohen shows that Cohen contemplated modifying the system to
add security and access permissions (Ans. 8).
Only those arguments actually made by Appellant have been
considered in this decision. Arguments which Appellant could have made
but chose not to make in the Brief have not been considered and are deemed
to be waived. See 37 C.F.R. § 41.37(c)(1)(vii).
Thus, the issue arising from the respective positions of Appellant and
the Examiner is:
Appeal 2009-005894
Application 09/907,848

4
Would one of ordinary skill in the art have combined Cohen and
Peterka to teach or suggest all of the elements recited in the claims 1, 4-9,
11-15, 21, 24-29, 31, 34-39, and 41-45?

FINDINGS OF FACT
1. The instant Specification details a method, apparatus, and
computer implemented instructions for enforcing security policies for
security unaware applications (Spec. p. 1, ll. 8-12). In response to loading a
class, a determination is made as to whether a security policy exists for the
class, and code is inserted into the class based on the security policy if that
security policy exists (Spec. p. 4, ll. 4-10).
2. Cohen is directed to system using load-time transformation where
classes are modified at load time according to user-supplied directives. This
allows users to select transformations that add new features, customize the
implementation of existing features, and apply the changes to all classes in
the environment (Abs.).
3. Cohen specifies that a transformation registered with a class loader
can be applied to all classes or some specific subset that are eventually
loaded into the machine (p. 2, §2.2).
4. Cohen also discloses bytecode modifications, in addition to
changes to fields and properties of a class, which can be made such that
instructions can be reordered or replaced, new instructions can be inserted,
or a range of instructions protected by a handler can be modified, by splicing
new code into the existing implementation (p. 4, §3.5).
5. Cohen discusses, with respect to security issues, that “[t]here is
also [a] question of how to determine the access permission of a transformed
Appeal 2009-005894
Application 09/907,848

5
class: can classes ever gain or lose permissions due to being transformed?”
(p. 10, §7.2).
6. Peterka is directed to a system that entities to define flexible
security policies for the execution of downloaded applications on digital
television receivers (Abs.).
7. Peterka specifies that a software application is provided to the
receiver and data defining conditions for access to the receiver retrieved and
utilized to determine whether the security policy contains a permission for
the software application to access the receiver function (Col. 3, ll. 38-67).

PRINCIPLES OF LAW
“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).
KSR disapproved a rigid approach to obviousness (i.e., an analysis
limited to lack of teaching, suggestion, or motivation). KSR, 550 U.S. 398 at
419 (“The obviousness analysis cannot be confined by a formalistic
conception of the words teaching, suggestion, and motivation, or by
overemphasis on the importance of published articles and the explicit
content of issued patents.”).

Appeal 2009-005894
Application 09/907,848

6
ANALYSIS
Appellants argue that Cohen fails to describe any type of security
policy or policy file (Br. 12-13). The Examiner finds that Cohen’s
disclosure of a specific subset of classes is a policy file (Ans. 6). We agree
with the Examiner.
As the Examiner points out, Cohen provides that a transformation can
be applied to all classes or some specific subset (FF 3). This application is
analogous to the application of a policy and a determination of such a subset
would be determined by something equivalent to a policy file. While
Appellants are correct that a “security” policy is not specified, it need not be
if the combination suggests that the policy can be a security policy, as
determined in the rejection. We find no error in determining claim elements
are rendered obvious from the teachings of both references since this is the
essence of obviousness under 35 U.S.C. § 103.
Appellants also argue that Peterka does not disclose that bytecodes are
inserted per the security policy for the class that is being loaded (Br. 13-14).
The Examiner finds that Cohen teaches the insertion of bytecodes of a class,
so that the combination of Cohen and Peterka would suggest the same (Ans.
7). We agree with the Examiner.
The fact that Peterka “merely indicat[es] allowable permissions” and
“does not provide any specification as to any particular additional security
code to be executed to provide proper resource access” (Br. 13-14), is not
fatal to the rejection because the insertion of bytecodes is taught by Cohen
(FF 4). While Cohen does not provide for their insertion per a security
policy, Peterka does teach checking a security policy for accessing particular
Appeal 2009-005894
Application 09/907,848

7
functions (FF 7), and together would suggest the insertion per a security
policy. As such, we do not find Appellants’ argument to be compelling.
Appellants argue that, in Peterka, the application that is checked for
proper permission is already required to be executing, not as recited in claim
1: “prior to the class being executed by the class loader” (Br. 14). The
Examiner finds it would have been obvious to provide checking prior to
executing a class because that is when policy checking is performed, as
opposed to Peterka’s policies with permissions which are defined at class
loading time (Ans. 7). We agree with the Examiner.
While Appellants are correct about the actual teachings of Peterka,
they have failed to appreciate that modifications would be necessary for the
combined system to perform correctly. The Examiner acknowledges that
Peterka’s permissions are centered around security domains which are
defined at class loading time, whereas policy checking is performed before a
class is executed (Ans. 7). We agree with the Examiner that the combination
would logically check the security policy prior to executing the class. As
such, we do not find Appellants’ argument to be compelling.
Appellants further argue that one of ordinary skill in the art would not
have been motivated to combine Cohen and Peterka because the authors of
Cohen acknowledge that they did not know how to implement security in
their code transformation procedures (Br. 15). The Examiner also finds that
the combination would have been motivated and the question posed by
Cohen shows that Cohen contemplated modifying the system to add security
and access permissions (Ans. 8). We generally agree with the Examiner.
We cannot agree with the Examiner that the question posed by Cohen
(FF 5) shows that Cohen contemplated modifying the system to add security
Appeal 2009-005894
Application 09/907,848

8
and access permissions. The question posed could equally show that they
were uncertain that it could have been properly accomplished. However, we
find the motivation supplied by the Examiner to combine Cohen and Peterka
(Ans. 4) would have been sufficient for one of ordinary skill in the art. In
addition, we do not find the question posed in Cohen to rise to the level of
teaching away from the combination or proceeding contrary to accepted
wisdom. In order to teach away, one disclosure must “criticize, discredit, or
otherwise discourage the solution” found in another reference or claimed in
an application. In re Fulton, 391 F.3d 1195, 1201 (Fed. Cir. 2004).
Similarly, we do not find the question posed in Cohen to reflect accepted
wisdom to which Appellants allege they are acting contrary to (Br. 15). As
such, we do not find that the disclosure of Cohen substantiates the non-
obviousness of the combination of Cohen and Peterka. Thus, we find no
error in the rejection of claims 1, 4-9, 11-15, 21, 24-29, 31, 34-39, and 41-45
under U.S.C. § 103(a) as being obvious over Cohen and Peterka.

CONCLUSION
The decision of the Examiner rejecting 1, 4-9, 11-15, 21, 24-29, 31,
34-39, and 41-45 under U.S.C. § 103(a) as being obvious over Cohen and
Peterka is affirmed.

DECISION
The Examiner’s rejection of claims 1, 4-9, 11-15, 21, 24-29, 31, 34-
39, and 41-45 before us on appeal is AFFIRMED.
No time period for taking any subsequent action in connection with
this appeal may be extended under 37 CFR § 1.136(a)(1)(iv).
Appeal 2009-005894
Application 09/907,848

9

AFFIRMED

ack
cc:

IBM CORPORATION
3039 Cornwallis Rd.
Dept. T81 / B503, Po Box 12195
Research Triangle Park, NC 27709