Ex Parte Nakhjiri et al

Patent Trial and Appeal BoardApr 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