Ex Parte Nakhjiri et al

Patent Trial and Appeal Board

Apr 20, 2016

11938048 (P.T.A.B. Apr. 20, 2016)

UNITED STA TES p A TENT AND TRADEMARK OFFICE
APPLICATION NO. FILING DATE
111938,048 11109/2007
74365 7590 04/22/2016
Slater & Matsil, LLP,
17950 Preston Road, Suite 1000
Dallas, TX 75252
FIRST NAMED INVENTOR
Madjid F. Nakhjiri
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.
HW 0748168US 3056
EXAMINER
CALLAHAN, PAULE
ART UNIT PAPER NUMBER
2437
NOTIFICATION DATE DELIVERY MODE
04/22/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):
uspatent@huawei.com
docketing@slatermatsil.com
PTOL-90A (Rev. 04/07)
UNITED STATES PATENT AND TRADEMARK OFFICE
BEFORE THE PATENT TRIAL AND APPEAL BOARD
Ex parte MADJID F. NAKHJIRI and GRANT RODOLPH
Appeal2014-005074
Application 11/938,048
Technology Center 2400
Before ALLEN R. MacDONALD, JEFFREY S. SMITH, and
MICHAEL M. BARRY, Administrative Patent Judges.
MacDONALD, Administrative Patent Judge.
DECISION ON APPEAL
Appeal2014-005074
Application 11/938,048
STATEMENT OF CASE
Appellants appeal under 35 U.S.C. § 134(a) from a final rejection of
claims 1-24. Final Act. 1. We have jurisdiction under 35 U.S.C. § 6(b ).
Exemplary Claim
Exemplary claim 1 under appeal reads as follows (emphasis and
formatting added):
1. A method of separating authentication and authorization
services in a communications system, comprising the steps of:
[(A)] authenticating a client node by an authenticating server
utilizing extensible authentication protocol;
[(B)] generating a first master key by the authenticating
server, wherein the master key matches a second master key
generated by the client node;
[ ( C)] generating an authorization token based upon the first
master key and usage data embedded in a service request by the
authenticating server matching a client node-generated second master
key-based authorization token; and
[(D)] authorizing services rendered to the client node via an
authorizing server, based upon information in the authorization token.
Rejections
The Examiner rejected claims 1---6, 19, 21, and 23 under 35 U.S.C.
§ 103(a) as being unpatentable over the combination of Salowey et al. (US
2007/0220598 Al, published Sept. 20, 2007), Patel (US 7,181,196 B2,
issued Feb. 20, 2007), and Aboba et al. (IETF EAP Working Group, Internet
Draft, "EAP Keying Format", Dec. 21, 2002 (retrieved from the Internet at:
>tools.ietf.org/id/draft-aboba-pppext-key-problem-05.txt<).). 1
1 Separate patentability is not argued for claims 2---6, 19, 21, and 23. As to
claims 19, 21, and 23, Appellants address them only by repeating or
2
Appeal2014-005074
Application 11/938,048
The Examiner rejected claims 7-18, 20, 22, and 24 under 35 U.S.C.
§ 103(a) as being unpatentable over the combination of Salowey, Patel,
Aboba, and Yun et al. (US 2007/0297611 Al, published Dec. 27, 2007). 2
Appellants ' Contentions
1. Appellants contend that the Examiner erred in rejecting claim 1
under 35 U.S.C. § 103(a) because:
Patel . . . fails to disclose generating a first master key by the
authenticating server, wherein the master key matches a second
master key generated by the client node because the client node
in Patel has a different process of calculating the MAC value in
comparison with the EAP server.
* * *
Patel fails to disclose the access terminal 120 actually calculates
its own master key. Indeed, it is not necessary for the access
terminal 120 to calculate its own master key because "the initial
Ki is available to the access terminal 120." Patel, col. 7, lines
17-18 (emphasis added). In other words, in Patel, the access
terminal 120 calculates the lVLA.C value directly based upon the
available Ki.
Furthermore, Patel specifically states the initial key Ki is
part of the subscriber identity module (SIM). For example, "the
SIM 121 may include an international mobile subscriber
referencing the arguments for claim 1 (App. Br. 8-11). Except for our
ultimate decision, claims 2-6, 19, 21, and 23 are not discussed further
herein.
2 Separate patentability is not argued for claims 7-18, 20, 22, and 24.
Rather, Appellants address claim 7 only by repeating the arguments for
claim 1. Further, Appellants address claims 8-18, 20, 22, and 24 only by
referencing the arguments for their respective independent claims (App. Br.
9-12). Thus, the rejection of these claims turns on our decision as to claim
1. Except for our ultimate decision, claims 7-18, 20, 22, and 24 are not
discussed further herein.
3
Appeal2014-005074
Application 11/938,048
identity (lMSl), an individual subscriber authentication key
(Ki)." Patel, col. 4, lines 31-33. A person skilled in the art will
recognize that the individual subscriber authentication key (Ki)
is generated by a network operator and assigned to the access
terminal during the personalization process. Therefore, Ki is
available to the access terminal 120.
App. Br. 7-8.
2. Appellants contend that the Examiner erred in rejecting claim 1
under 35 U.S.C. § 103(a) because:
Patel fails to disclose generating an authorization token based
upon the first master key and usage data embedded in a service
request by the authenticating server matching a client node-
generated second master key-based authorization token. As
described above, Patel fails to disclose a second master key
generated by the client node. As such, Patel does not disclose a
client node-generated second master key-based authorization
token, which is recited by claim 1.
App. Br. 8, emphasis in bold italics added.
3. Appellants also contend that the Examiner erred in rejecting claim 1
under 35 U.S.C. § 103(a) because:
In [the Answer], the Examiner acknowledges that the MAC
value generated by the client access terminal is used for an
authentication process rather than an authorization process. In
particular, the MAC value generated by the client access
terminal is used for authenticating the EAP server. This is
different from recited features of claim 1.
Reply Br. 2.
In Patel, there may be two MAC values, one generated by the
EAP server (hereinafter "EAP MAC value") and one generated
by the client access terminal (hereinafter "access terminal MAC
value["]). Neither is used for an authorization process. The EAP
MAC value is generated in an authentication process. See Patel,
Figure 3, step 225. The access terminal MAC value also is
generated in an authentication process.
4
Appeal2014-005074
Application 11/938,048
Reply Br. 3.
In rejecting claim 1, the Final Office Action states Patel teaches
"user terminal is taught as generating a MAC value which the
Examiner believe serves in a role as an authentication token."
Final Office Action, pages 3-4 (emphasis added).
Claim 1 recites an authorization token. The Examiner,
however, interprets the MAC value of Patel as an authentication
token rather than an authorization token. Appellants believe the
root cause of such an interpretation is the MAC values in Patel
are from an authentication process. As such, the MAC values
cannot be interpreted as an authorization token.
Reply Br. 4.
Issues on Appeal
Did the Examiner err in rejecting claim 1 as being obvious?
ANALYSIS
We have reviewed the Examiner's rejections in light of Appellants'
arguments (Appeal Brief and Reply Brief) that the Examiner has erred. We
disagree with Appellants' conclusions. Except as noted below, we adopt as
our own (1) the findings and reasons set forth by the Examiner in the action
from which this appeal is taken and (2) the reasons set forth by the Examiner
in the Examiner's Answer in response to Appellants' Appeal Brief. We
concur with the conclusions reached by the Examiner. We highlight the
following additional points.
As to Appellants' above contention 1, we disagree with Appellants'
argument for the reasons set forth by the Examiner. See Ans. 12- 19.
Separately, even if we were to agree with Appellants' premise that "it is not
necessary for the access terminal 120 to calculate its own master key
5
Appeal2014-005074
Application 11/938,048
because 'the initial Ki is, available to the access terminal 120"' (App. Br. 7-
8) (i.e., Patel uses a different process in the access terminal), we would still
agree with Examiner's ultimate conclusion. The teaching of Patel that "the
access terminal 120 can calculate the MAC value in the same manner as it is
calculated by the EAP server 145" is more than sufficient suggestion to
render obvious using the EAP server authorization key generation process in
the access terminal, even if such were not expressly taught.
As to Appellants' above contention 2, to the extent that Appellants are
arguing the generated second master key is not obvious, we disagree with
Appellants' argument for the above stated reasons. To the extent that
Appellants are arguing the Examiner erred because an authentication token
is generated in Patel rather than an authorization token, we disagree. As
acknowledged by Appellants at paragraph [0003] of their Specification, the
authorization and authentication processes are conventionally a solitary
process. Furthermore, the prior art demonstrates it was known to variously
separate and implement related authorization and authentication processes
either on a single server, or across multiple devices. 3 We conclude that an
artisan would recognize known authentication processes are applicable to
authorization processing, and vice-versa.
As to Appellants' above contention 3, it fails for the same reason
discussed above with respect to contention 2. Again, we conclude that an
artisan would recognize known authentication processes are applicable to
authorization processing, and vice-versa.
3 See, e.g., Patel Fig. 1 and col. 1, 1. 39 to col. 6, 1. 67 (separate authorization
and authentication processes on a single server); Salowey Fig. 1 and i-fi-125-
45 (authentication and authorization processes provided on separate devices
in a network).
6
Appeal2014-005074
Application 11/938,048
CONCLUSIONS
(1) The Examiner has not erred in rejecting claims 1-24 as being
unpatentable under 35 U.S.C. § 103(a).
(2) Claims 1-24 are not patentable.
DECISION
The Examiner's rejections of claims 1-24 are 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)(l )(iv).
AFFIRMED
7