Ex Parte Kalibjian et al

Patent Trial and Appeal Board

Jul 31, 2013

11177715 (P.T.A.B. Jul. 31, 2013)

UNITED STATES PATENT AND TRADEMARK OFFICE
____________________

BEFORE THE PATENT TRIAL AND APPEAL BOARD
____________________

Ex parte JEFF KALIBJIAN, RALPH BESTOCK, LARRY HINES, DALE
W. HOPKINS, VLADIMIR LIBERSHTEYN, STEVEN W. WIERENGA,
and SUSAN LANGFORD
____________________

Appeal 2011-001396
Application 11/177,715
Technology Center 2400
____________________

Before THU A. DANG, JAMES R. HUGHES,
and JEFFREY S. SMITH, Administrative Patent Judges.

DANG, Administrative Patent Judge.

DECISION ON APPEAL

Appeal 2011-001396
Application 11/177,715

2
I. STATEMENT OF THE CASE
Appellants appeal under 35 U.S.C. § 134(a) from a Final Rejection of
claims 1-20 (App. Br. 4). We have jurisdiction under 35 U.S.C. § 6(b).
We affirm-in-part.

A. INVENTION
Appellants’ invention is directed to a system and method for policy
protected cryptographic Application Programing Interfaces (API); wherein,
the application exists in a first secure memory partition and the API exists in
a second secure memory partition (Abstract).

B. ILLUSTRATIVE CLAIM
Claim 1 is exemplary:
1. A method for software execution by a computer, comprising:

executing an application in a first secure memory partition;

formatting a request to comply with a pre-defined secure
communication protocol;

transmitting the request from the application to a cryptographic
application programming interface (API) of the application, the API being in
a second secure memory partition that is separate and secure from the first
secure memory partition; and

verifying, in the second secure memory partition, that the request
complies with a security policy before executing the request.

Appeal 2011-001396
Application 11/177,715

3
C. REJECTIONS
The prior art relied upon by the Examiner in rejecting the claims on
appeal is:
Lin US 2001/0018746 A1 Aug. 30, 2001
FIPS PUB 140-2: "Security Requirements for Cryptographic Modules"
Issued May 25, 2001

Aspencrypt.com: "Learn About Windows Cryptography" (C)1999 Persits
Software (hereinafter Aspencrypt 1)

Aspencrypt.com: "Encrypt and Decrypt Files and Messages" (C)1999 Persits
Software (hereinafter Aspencrypt 2)

Claims 1, 6-8, 11, and 17-19 stand rejected under 35 U.S.C. § 102(b)
as being anticipated by Lin.
Claims 2, 10, and 14-16 stand rejected under 35 U.S.C. § 103(a) as
being unpatentable over Lin in view of FIPS.
Claims 3-5, 9, 12, 13, and 20 stand rejected under 35 U.S.C. § 103(a)
as being unpatentable over Lin in view of Aspencrypt 1 and Aspencrypt 2.

II. ISSUES
The dispositive issues before us are whether the Examiner has erred in
determining that Lin teaches:
1. “executing an application in a first secure memory partition” and
“transmitting the request from the application to a cryptographic application
programming interface (API) of the application, the API being in a second
secure memory partition that is separate and secure from the first secure
memory partition” (claim 1, emphasis added); and
Appeal 2011-001396
Application 11/177,715

4
2. “encrypting the call with a cryptographic algorithm before
transmitting the call from the application to the API” (claim 8, emphasis
added).

III. FINDINGS OF FACT
The following Findings of Fact (FF) are shown by a preponderance of
the evidence.
The Invention
1. According to Appellants, one exemplary embodiment of the
invention discloses a secure operating system that includes secure memory
partitions or processing space that insures applications running in one
partition 210A cannot gain access and corrupt applications running in
another partition 210B (¶ [0020]).
Lin
2. Lin discloses a security architecture of memory layers where an
application within an Application layer may place a call to a Common
Security Services Manager (CSSM) Application Programming Interface
(API) within a Security Services Layer having security policies either
implemented with its own policy stored in a CSSM specific policy
description file 520 or by calling a generic trust policy library Pass Through
API (Fig. 2; ¶¶ [0068] and [0080]).
3. When the CSSM uses its own policy stored in a CSSM specific
policy description file 520, the CSSM only attaches itself to security
modules whose digital certificates have been signed by module developers
(¶ [0080]).
Appeal 2011-001396
Application 11/177,715

5
AspEncrypt
4. AspEncrypt discloses symmetric encryption functionality using
a CryptoKey object that enables file and text encryption using a hashing
algorithm in the application using a few lines of code (¶¶ 1st, 2nd, and 3rd).

IV. ANALYSIS
Claim 1, 6, 7, 11, and 17-19
Appellants contend that although “Lin teaches a CDSA that has a set
of layered security services” (App. Br. 18), “[t]hese layered security
services…are not provided in different secure memory partitions” (App. Br.
13). Appellants assert that although “[m]emory is often divided or
partitions, but such partitions are not secure” (App. Br. 14, emphasis
removed).
However, the Examiner finds that “[a]ll that is required to establish
the plurality of partitions is to show evidence within the prior art that any
form of demarcation exists between the one or more user applications and
the component that verifies the security policy” (Ans. 8). The Examiner
notes that “Lin teaches a memory means divided into a plurality of layers”
including “an application layer… [having] application programs that … a
typical user … would directly interact with … a security services
management layer … includ[ing] … a policy interpreter … capable of
enforcing a security policy on a request made by an application (id.). The
Examiner notes further that as to a secure memory partition, “this feature
had been inherent to all modern computers for well over a decade” (Ans. 9).
In the Reply Brief, Appellants contend that “Lin never states or even
suggests that the layers are secure” and that the Examiner’s “reli[ance] on
Appeal 2011-001396
Application 11/177,715

6
several secondary references in a 102 rejection … is improper… to show[]
that the layers in Lin are secure” (Reply Br. 3, emphasis removed).
We give the claim its broadest reasonable interpretation consistent
with the Specification. See In re Morris, 127 F.3d 1048, 1054 (Fed. Cir.
1997). Claim 1 does not define what “secure memory partition” means,
includes, or represents other than two partitions must be “separate and
secure” from one another (claim 1). The Specification merely discloses one
“exemplary embodiment” of a secure operating system having secure
memory partitions which insure that applications running within one
partition cannot gain access of applications running in another partition (FF
1). That is, we note that the term “secure memory partition” is used, but not
defined, in paras. [0019] and [0020], of the Specification as Appellants
contend (App. Br. 12; FF 1). Thus, we give “the API being in a second
secure memory partition that is separate and secure from the first secure
memory partition” its broadest reasonable interpretation as the API resides
in any storage unit that is separate and secure from another storage unit, as
consistent with the Specification and claim 1.
Lin discloses a security architecture including a memory divided into
layers including a Security Services Layer having an CSSM API; wherein,
CSSM API evaluates a request from an application in the Application layer
using security policies either implemented with its own policy stored in a
CSSM specific policy description file or by calling a generic trust policy
library Pass Through API (FF 2). We find that the Application layer to be a
storage unit that comprises an application. We find further that the Security
Services Layer comprises a storage unit that is separate and secure from the
Application layer. That is, we find that Lin’s security architecture and
Appeal 2011-001396
Application 11/177,715

7
method comprises “executing an application in a first secure memory
partition” and “transmitting the request from the application to a
cryptographic application programming interface (API) of the application,
the API being in a second secure memory partition that is separate and
secure from the first secure memory partition” (claim 1).
Accordingly, we find no error in the Examiner’s rejection of claim 1
under 35 U.S.C. § 102(b) over Lin. Further, independent claims 7 and 17
having similar claim language and claims 6, 11, 10, 18, and 19 (depending
from claims 1, 7, and 17) which have not been argued separately, fall with
claim 1.
Claim 8
Appellants contend that “[c]alls in Lin are not encrypted and then
transmitted from an application to an API” (App. Br. 15, emphasis
removed).
After reviewing the record on appeal, we agree with Appellants.
Though we agree with the Examiner that Lin discloses the CSSM only
attaches itself to security modules whose digital certificates have been
signed by module developers (FF 3), we cannot find any teaching in the
Examiner’s recited portion of Lin of the step of “encrypting the call with a
cryptographic algorithm before transmitting the call from the application to
the API” as required by claim 8 (emphasis, added) in the recited portions of
ref referenced by the Examiner (Ans. 12). That is, encryption of security
modules does not support a finding of encrypting a call prior to sending the
call from an application to the API.
Accordingly, we find that Appellants have shown that the Examiner
erred in rejecting claim 8 under 35 U.S.C. § 102(b) over Lin.
Appeal 2011-001396
Application 11/177,715

8
Claims 2, 10, and 14-16
Appellants argue that claim 14 is patentable over the cited prior art for
the same reasons asserted with respect to claim 1 (App. Br. 18).
As noted supra, however, we find that Lin discloses all the features of
claim 1. We therefore affirm the Examiner’s rejection of claim14 under 35
U.S.C. § 103 over Lin in view of FIPS. Further, claims 2, 10, 15, and 16
(depending from claims 1, 7, and 14) which have not been argued separately,
fall with claim 14.
Claims 3-5, 9, 12, 13, and 20
As to claim 9, Appellants contend that although “Aspencrypt teaches
different types of hash algorithms,” “[n]owhere does Aspencrypt teach or
even suggest that a call would be hashed before it is transmitted from an
application to an API” (App. Br. 19).
However, the Examiner finds that Aspencrypt discloses an “API
function ‘GenerateKeyFromPassword’” (Ans. 14). Thus, “[m]aking the call
to GenerateKeyFromPassword … implicitly entails both supplying the API
with a specific hash function and subsequently using said hash function to
create a hash as part of the process to generate a cryptographic key for future
encryption and decryption” (id.).
As noted supra, Lin discloses a security architecture of memory layers
including a Security Services Layer having an API with security policies that
receives calls from applications located in the Applications layer (FF 2). We
find that the step of transmitting a call from the application comprises
sending a call from the application to the API.
In addition, AspEncrypt discloses file and text encryption using a
hashing algorithm in the application using a few lines of code (FF 4). We
Appeal 2011-001396
Application 11/177,715

9
find that file and text encryption comprises use of a hashing algorithm to
encrypt data.
We find that the combination of Lin and AspEncrypt at least suggests
providing “hashing the call with a hashing algorithm before transmitting the
call from the application to the API” (claim 1).
Accordingly, we find no error in the Examiner’s rejection of claim 9
under 35 U.S.C. § 103(a) over Lin in view of AspEncrypt. Further, claims
3-5, 12, 13, and 20 (depending from claims 1, 7, and 17) which have not
been argued separately, fall with claim 9.

V. CONCLUSION AND DECISION
The Examiner’s rejection of claims 1, 6, 7, 11, and 17-19 under
35 U.S.C. § 102(b) and of claims 2-5, 9, 10, 12-16, and 20 under 35 U.S.C. §
103(a) is affirmed; while the Examiner’s rejection of claim 8 and 19 under
35 U.S.C. § 102(b) is reversed.
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-IN-PART

tkl