Ex Parte Dayka et al

Patent Trial and Appeal Board

Sep 28, 2016

12986517 (P.T.A.B. Sep. 28, 2016)

UNITED STA TES p A TENT AND TRADEMARK OFFICE
APPLICATION NO. FILING DATE FIRST NAMED INVENTOR
12/986,517 01107/2011
46429 7590 09/30/2016
CANTOR COLBURN LLP-IBM POUGHKEEPSIE
20 Church Street
22nd Floor
Hartford, CT 06103
John C. Dayka
UNITED STATES DEPARTMENT OF COMMERCE
United States Patent and Trademark Office
Address: COMMISSIONER FOR PATENTS
P.O. Box 1450
Alexandria, Virginia 22313-1450
www .uspto.gov
ATTORNEY DOCKET NO. CONFIRMATION NO.
POU920100033US1 6552
EXAMINER
ALMEIDA, DEVINE
ART UNIT PAPER NUMBER
2492
NOTIFICATION DATE DELIVERY MODE
09/30/2016 ELECTRONIC
Please find below and/or attached an Office communication concerning this application or proceeding.
The time period for reply, if any, is set in the attached communication.
Notice of the Office communication was sent electronically on above-indicated "Notification Date" to the
following e-mail address( es):
usptopatentmail@cantorcolbum.com
PTOL-90A (Rev. 04/07)
UNITED STATES PATENT AND TRADEMARK OFFICE
BEFORE THE PATENT TRIAL AND APPEAL BOARD
Ex parte JOHN C. DA YKA, MICHAEL J. JORDAN,
and TAMAS VISEGRADY
Appeal2015-001429
Application 12/986,517
Technology Center 2400
Before JAMES R. HUGHES, KRISTEN L. DROESCH, and
JOHN A. EVANS, Administrative Patent Judges.
HUGHES, Administrative Patent Judge.
DECISION ON APPEAL
STATEMENT OF THE CASE
Appellants seek our review under 35 U.S.C. § 134(a) of the
Examiner's final decision rejecting claims 13-18. Claims 1-12 have been
canceled. (Final Act. l; App. Br. 1.)1 We have jurisdiction under 35 U.S.C.
§ 6(b ).
We affirm.
1 We refer to Appellants' Specification ("Spec."), filed Jan. 7, 2011; Appeal
Brief ("App. Br.") filed June 18, 2014; and Reply Brief ("Reply Br.") filed
Nov. 10, 2014. We also refer to the Examiner's Answer ("Ans.") mailed
Sept. 11, 2014, and Final Office Action (Final Rejection) ("Final Act.")
mailed Nov. 26, 2013.
Appeal2015-001429
Application 12/986,517
Appellants' Invention
The invention concerns communication computer program products to
securely transport cryptographic structures over general-purpose application
program interfaces. The computer program product distributes keys (codes)
of a domain-specific cryptographic service provider (DCSP) over a general
cryptographic service provider (GCSP) by generating a first set of functional
keys in the DCSP, providing the functional keys to the GCSP, generating a
second set of functional keys in the GCSP (GCSP functional keys) that are
equivalent to the first set of functional keys (the functional keys generated in
the DCSP), and encoding the GCSP functional keys in the GCSP utilizing
key encoding keys (codes). Each key encoding key includes restrictions on
the types of key encoding keys each key encoding key may encode. Also, a
computing device may receive an encoded key, which may encode at a first
functional key. The computing device unwraps the encoded key in a general
cryptographic service provider (GCSP) until the first functional key is
discovered, wherein the first functional key does not include a wrap
template, and provides the first functional key to a domain-specific
cryptographic service provider (DCSP). (Spec. i-fi-f l, 9-13; Abstract.)
Representative Claims
Independent claims 13 and 15, reproduced below with and the key
disputed limitations emphasized, further illustrate the invention:
13. A computer program product for distributing keys
of a domain-specific cryptographic service provider (DCSP)
over a general cryptographic service provider (GCSP), the
computer program product comprising:
a computer readable storage medium having computer
readable program code embodied therewith, the computer
2
Appeal2015-001429
Application 12/986,517
readable program code causing a computing device to perform a
method comprising:
generating functional keys in the DCSP;
providing the functional keys to the GCSP;
generating GCSP functional keys that are equivalent to the
functional keys; and
encoding the GCSP functional keys in the GCSP with key
encoding keys, wherein each key encoding key includes
restrictions on the types of key encoding keys each key encoding
key may encode.
15. A computer program product for distributing
cryptographic keys, the computer program product comprising:
a computer readable storage medium having computer
readable program code embodied therewith, the computer
readable program code causing a computing device to perform a
method comprising:
receiving an encoded key at a computing device, the
encoded key encoding at least a first functional key;
unwrapping the encoded key in a general cryptographic
service provider on the computing device until the first functional
key is discovered, the first functional key not including a wrap
template; and
providing the first functional key to a domain-specific
cryptographic service provider on the computing device.
Rejections on Appeal
1. The Examiner rejects claim 15 under 35 U.S.C. § 102(b) as
being anticipated by Jueneman (US 2008/0130895 Al, pub. June 5, 2008).
2. The Examiner rejects claims 13, 14, and 16-18 under 35 U.S.C.
§ 103(a) as being unpatentable over Jueneman and Matyas (US 4,924,514,
iss. May 8, 1990).
3
Appeal2015-001429
Application 12/986,517
ISSUES
Based upon our review of the record, Appellants' contentions, and the
Examiner's findings and conclusions, the issues before us follow:
1. Did the Examiner err in finding that Jueneman and Matyas
teach or suggest "encoding the GCSP functional keys in the GCSP with key
encoding keys, wherein each key encoding key includes restrictions on the
types of key encoding keys each key encoding key may encode," (claim 13)
as recited in Appellants' claim 13?
2. Did the Examiner err in finding that Jueneman discloses
"unwrapping the encoded key in a general cryptographic service provider on
the computing device until the first functional key is discovered, the first
functional key not including a wrap template; and providing the first
functional key to a domain-specific cryptographic service provider," (claim
15) as recited in Appellants' claim 15?
ANALYSIS
The Obviousness Rejection of Claims 13, 14, and 16--18
Appellants address the Examiner's§ 103 of claims 13, 14, and 16-18
before addressing the Examiner's§ 102 rejection of claim 15 (infra). We
consider Appellants' arguments seriatim as they are presented in the Appeal
Brief pages 3 and 4 and the Reply Brief pages 1 and 2. Appellants do not
separately argue dependent claims 14 and 16-18 (App. Br. 3--4).
Accordingly, we select independent claim 13 as representative of
Appellants' arguments and grouping with respect to claims 13, 14, and 16-
18. 37 C.F.R. § 41.37(c)(l)(iv).
4
Appeal2015-001429
Application 12/986,517
We have reviewed the rejection of claims 13, 14, and 16-18 in light of
Appellants' arguments. In reaching this decision, we have considered all
evidence and all arguments made by Appellants. We are not persuaded that
Appellants identify reversible error. We agree with and adopt the
Examiner's findings, reasoning, and conclusions as set forth in the Final
Office Action (Final Act. 4---6) and the Examiner's Answer (Ans. 2-3). We
highlight the following for emphasis.
Appellants contend that Jueneman and Matyas do not teach the
disputed limitations of claim 13, namely - "each key encoding key includes
restrictions on the types of key encoding keys each key encoding key may
encode" (claim 13). See App. Br. 3--4; Reply Br. 1-2. Specifically,
Appellants contend Matyas does not describe codes or keys that place
restrictions on the types of codes (key encoding keys) each code (key
encoding key) may encode (App. Br. 3--4; Reply Br. 1-2)-Matyas's
"control vector does not have any relation to which types of key encoding
keys each key encoding key may encode. Rather, the control vector serves
as means to limit access to keys, not limit how the key may be used" (App.
Br. 3).
Appellants further contend that claim 13 "recites a method in which
functional keys are generated in a ... [DCSP], following which general
[GCSP] keys are generated that are equivalent to the functional keys
generated in the DCSP." And, Jueneman does not teach this feature
because:
There is only one key generation step in Jueneman's description
for Fig. 3. Thus, instead of actually generating a triple-DES
message encryption key (the logical result of the operations
required in claim 13), Jueneman replaces the original key
5
Appeal2015-001429
Application 12/986,517
generation request with a request to generate an AES-256 key
(0074) and generates that key instead.
App. Br. 4. We find Appellants' contentions unpersuasive of Examiner
error.
As to Appellants' arguments with respect to Matyas, as explained by
the Examiner (Final Act. 5; Ans. 2-3), Matyas describes a control vector
which specifies a CV Type - that defines how the key may be used - and
includes additional bits that specify how the key operates (see Matyas col.
13, 1. 61---col. 14, 1. 54). Appellants do not address the entire portion of
Matyas cited by the Examiner, and do not sufficiently explain how the
control vector does not include restrictions on the types of keys (key
encoding keys) each cryptographic key (key encoding key) may encode.
Therefore, we find Appellants' general arguments are insufficient to traverse
the Examiner's rejection.
With respect to Appellants' arguments concerning Jueneman's key
generation, Appellants' arguments are not commensurate with the scope of
claim 13. Claim 13 does not recite "generating a triple-DES message
encryption key" (supra). Further, Appellants point to Jueneman's Figure 3
and assert Jueneman only describes a single key generation step. Supra. As
explained by the Examiner, however, Jueneman describes a Legacy
Cryptographic Application Interface (CAPI) and a Limited Change Scenario
(LCS) Cryptographic Service Provider (CSP) that produce an LCS dual-key
certificate (Jueneman Fig. 1; i-fi-1 64---69) for a legacy application (Jueneman
Fig. 3; i-fi-173-82). Final Act. 4--5; Ans. 3. Jueneman's Figure 1 and
corresponding text describe multiple key/certificate generation steps. Also,
Appellants do not address the Examiner's additional explanation in the
Examiner's Answer in their Reply Brief. Therefore, we find Appellants'
6
Appeal2015-001429
Application 12/986,517
general arguments are insufficient to traverse the Examiner's rejection.
Thus, Appellants do not persuade us of error in the Examiner's
obviousness rejection of claim 13. Accordingly, we affirm the Examiner's
rejection of independent claim 13, dependent claim 14 (which is dependent
on claim 13), and dependent claims 16-18 (dependent on claim 15,
discussed infra), not separately argued with particularity (supra).
The Anticipation Rejection of Claim 15
We have reviewed the rejection of claim 15 in light of Appellants'
arguments. In reaching this decision, we have considered all evidence and
all arguments made by Appellants. We are not persuaded that Appellants
identify reversible error. We agree with and adopt the Examiner's findings,
reasoning, and conclusions as set forth in the Final Office Action (Final Act.
3--4) and the Examiner's Answer (Ans. 3). We highlight the following for
emphasis.
Appellants contend that Jueneman does not disclose the disputed
features of claim 15, namely, that the "first functional key not including a
wrap template" (claim 15). See App. Br. 4; Reply Br. 2. Specifically,
Appellants contend that:
Juenaman [sic] only teaches a single service (a domain
specific one; see FIG. 12). The Office Action does not even
attempt to show the two service providers and only generally
avers to their existence.
Further, Fig. 1 shows an asymmetric (public-private) key
generation procedure, while Fig. 3 shows the symmetric key
generation procedure described above. Neither of these (nor the
associated text) teach or suggest the required limitation that the
first functional key not include a wrap template.
App. Br. 4.
7
Appeal2015-001429
Application 12/986,517
We find Appellants' contentions unpersuasive of Examiner error.
First, as explained by the Examiner (Ans. 3), Appellants reference a non-
existent figure (Jueneman's Fig. 12) and state that Jueneman "only teaches a
single service" (App. Br. 4). This argument is facially defective. Assuming,
without deciding, that Appellants make the same arguments as made with
respect to claim 13 (supra) - that Jueneman only describes a single key
generation step/single cryptographic service, we again find Appellants'
general arguments are insufficient to traverse the Examiner's rejection.
Appellants also generally assert that Jueneman does not describe a
first functional key not including a wrap template. See App. Br. 4; Reply Br.
2. Simply asserting that the prior art cited by the Examiner (Jueneman's
Figs. 1, 3; i-fi-164---69, 73-82) does not disclose the recited feature is
insufficient to overcome the Examiners factual findings. We agree with the
Examiner that the cited portions of Jueneman (Jueneman's Figs. 1, 3; i-fi-164--
69, 73-82), describe encryption where a first functional key does not include
a wrap template.
Thus, Appellants do not persuade us of error in the Examiner's
anticipation rejection of claim 15. We, accordingly, affirm the Examiner's
rejection of 15.
CONCLUSION
Appellants have not shown that the Examiner erred in rejecting claim
15 under 35 U.S.C. § 102(b).
Appellants have not shown that the Examiner erred in rejecting claims
13, 14, and 16-18 under 35 U.S.C. § 103(a).
8
Appeal2015-001429
Application 12/986,517
DECISION
We affirm the Examiner's rejections of claims 13-18.
No time period for taking any subsequent action in connection with
this appeal may be extended under 37 C.F.R. § 1.136(a)(l )(iv).
AFFIRMED
9