Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
Currently pending claims are 1 – 18.
Response to Arguments
Applicant's arguments with respect to the subject matter of the instant claims have been fully considered but are not persuasive.
As per claim 1, Applicant asserts that Herrmann does not teach “determining, at the proxy server, whether modification of the request is required prior to authentication; and modifying, at the proxy server, the received authentication request prior to authentication” because Herrmann discloses that the primary RADIUS server generates a RADIUS Access-Challenge packet to obtain more information from the client … to make a decision to accept or reject the connection. Examiner respectfully disagrees with the following rationale:
(a) Applicant’s argument is irrelevant to the claimed subject matter because the matter associated with a RADIUS Access-Challenge packet generated by the primary RADIUS server has not been recited into the claim at all; and besides:
(b) Examiner notes according to MPEP 2111 of the broadest and reasonable claim interpretations, applicant’s argument has no merit since the alleged limitation such as “what is the exact content of the received authentication request to be modified prior to authentication” has not been specifically recited into the claim. Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
(c) In light of that, Herrmann teaches the proxy server forwards the Access Request message to the primary RADIUS server for authentication (FIG. 7A / E-703) and also determines the necessity of format compatibility that is understandable between a PPP dialer clients (as a EAP client) and a RADIUS server (Para [0066] Line 1 – 7) by forming / translating a new message in a format appropriate for transmission to the RADIUS server (Para [0084] / Last sentence). As such, Herrmann does teach determining, at the proxy server, whether modification of the request is required prior to authentication and thus Applicant's arguments are respectfully traversed.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1 – 5, 7 – 16 & 18 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Herrmann et al. (U.S. Patent 2004/0107360).
As per claim 1 & 11, Herrmann teaches a computer-implemented method for enabling multi-factor authentication for incompatible third-party Remote Authentication Dial-In User Service (“RADIUS”) clients using a proxy server, the method comprising the following steps performed by a processor within the proxy server (Herrmann: FIG. 4 / E-330):
receiving, at the proxy server, an authentication request from a particular, third-party RADIUS client (Herrmann: FIG. 7A / E-703 & Para [0090] Line 1 – 3, Para [0089] Line 1 – 8: (a) a proxy server, as an intermediary server, receives a network access request from a client device for authentication and forwards the authentication request to a primary RADIUS server, wherein (b) a client device can be a (remote access) PPP dialer, which is a RADIUS dial-in client device using PPP (Point-to-Point Protocol) to communicate TCP/IP protocol over a telephone network that constitutes one type of 3rd-party RADIUS client devices);
validating, at the proxy server, the received authentication request for compatibility with a RADIUS server prior to authentication (Herrmann: see above, FIG. 7A / E-703 & Para [0066] Line 1 – 7 and Para [0084] / Last sentence: the proxy server, as a part of an integrated gateway device (IGW server), forwards the Access Request message to the primary RADIUS server for authentication (FIG. 7A / E-703) and also determines the necessity of format compatibility that is understandable between a PPP dialer clients (as a EAP client) and a RADIUS server (Para [0066] Line 1 – 7) by forming / translating a new message in a format appropriate for transmission to the RADIUS server – i.e. between an EAP client and the RADIUS server (Para [0084] / Last sentence));
determining, at the proxy server, whether modification of the request is required prior to authentication (Herrmann: see above (repeated herein), FIG. 7A / E-703 & Para [0066] Line 1 – 7 and Para [0084] / Last sentence: the proxy server, as a part of an integrated gateway device (IGW server), forwards the Access Request message to the primary RADIUS server for authentication (FIG. 7A / E-703) and also determines the necessity of format compatibility that is understandable between a PPP dialer clients (as a EAP client) and a RADIUS server (Para [0066] Line 1 – 7) by forming / translating a new message in a format appropriate for transmission to the RADIUS server – i.e. between an EAP client and the RADIUS server (Para [0084] / Last sentence));
modifying, at the proxy server, the received authentication request, if during the last step it was determined that modification of the request is required (Herrmann: see above & Para [0066] Line 1 – 7 and Para [0076] Line 1 – 5: see immediate above);
forwarding, by the proxy server, the validated and modified authentication request to the RADIUS server (Herrmann: see above & Para [0090] Line 1 – 3: the proxy server forwards the Access Request message to the primary RADIUS server for authentication purpose (i.e. as an authentication request));
receiving, at the proxy server, a response from the RADIUS server (Herrmann: see above & Para [0076] Line 1 – 5: (e.g.) receiving a RADIUS Access-Accept messages (as a response) from the RADIUS server);
translating, at the proxy server, the response from the RADIUS server into a compatible format for the particular, third-party RADIUS client (Herrmann: see above & Para [0066] Line 1 – 7: a proxy sever as a part of an integrated gateway device (IGW server) determines the necessity of format compatibility that is understandable between a PPP dialer clients (as a EAP client) and a RADIUS server); and
forwarding, by the proxy server, the response from the RADIUS server to the particular, third-party RADIUS client (Herrmann: see above & FIG. 7B / E-710: forwarding the response to the client indicating an accepted access-request from the RADIUS server (along with a policy challenge)).
As per claim 2 & 12, Herrmann teaches wherein validating the authentication request comprises identifying missing attributes required by the RADIUS server (Herrmann: see above FIG. 7B / E-709 & Para [0090]: (e.g.) missing an (additional) access challenge attributes as required by the RADIUS server).
As per claim 3, 8 & 16, Herrmann teaches wherein determining whether to modify the request comprises performing a comparison of predetermined compatible authentication request formats with the received authentication request (Herrmann: see above & Para [0066] Line 1 – 7, Para [0076] Line 1 – 5 and Para [0084] Last sentence: a proxy sever as a part of an integrated gateway device (IGW server) determines a necessity of format compatibility that is understandable between a PPP dialer clients (as a EAP client) and a RADIUS server by forming a new message in a format appropriate for transmission to the RADIUS server (Para [0084] / Last sentence)).
As per claim 4, Herrmann teaches wherein modifying the authentication request includes adding required attributes to the request which were absent in the initial request received from the particular, third-party RADIUS client (Herrmann: see above, FIG. 7B / E-709 & Para [0090]: (e.g.) absent / missing (e.g.) the access challenge attributes for authentications as additionally required by the RADIUS server).
As per claim 5, Herrmann teaches to remove superfluous attributes from the authentication request that are not required by the RADIUS server (Herrmann: see above & Para [0075] Last sentence: some attributes can be removed depending on such attributes as the complexity of the decision-making process and the associated performance impact – i.e. in view of impacting the system performance).
As per claim 7, Herrmann teaches determining, by the proxy server, whether a user is granted or denied access based on the response (Herrmann: see above and FIG. 7B / E-709 & E-710).
As per claim 9, Herrmann teaches wherein the proxy server communicates with the RADIUS server using an encrypted communication channel employing a shared secret (Herrmann: see above & Para [0035] Line 1 – 5: using a channel encryption associated with SSL session communications).
As per claim 10 & 15, Herrmann teaches wherein translating the response includes applying prescribed logic by code executing in the processor to reflect specific criteria defined by the particular, third-party RADIUS client (Herrmann: see above & Para [0066] Line 1 – 7, Para [0076] Line 1 – 5 and Para [0084] Last sentence).
As per claim 13, the instant claim is directed to a claimed content having functionality corresponding to the Claims 2 & 5, and are rejected by a similar rationale.
As per claim 14, Herrmann teaches wherein the proxy server is further configured to accept a shared secret for establishing secure communication with both a particular third-party RADIUS client among the third-party RADIUS clients and the RADIUS server (Herrmann: see above & Para [0054]: e.g., a PIN and card token).
As per claim 18, Herrmann teaches wherein the system is further configured to identify and discard attributes from the authentication request that otherwise cause the RADIUS server to reject the request (Herrmann: see above & Para [0066] Line 1 – 7, Para [0076] Line 1 – 5 and Para [0084] Last sentence: determining a necessity of format compatibility and discarding the original type of attributes and then translating to a new type of attributes in a format appropriate for transmission to the RADIUS server so as to avoid a rejection by the RADIUS server (Para [0084] / Last sentence)).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the exclaimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim 6 is rejected under 35 U.S.C.103 as being unpatentable over Herrmann et al. (U.S. Patent 2004/0107360), in view of Ganapathi et al. (U.S. Patent 10,944631).
As per claim 6, Ganapathi (& Herrmann) teaches wherein the proxy server is configured to compare the request with a predetermined compatible request captured by a simulation tool (Herrmann: see above) || (Ganapathi: Col. 4 Line 51 – 53 / Line 59 – 60 & Col. 18 Line 19 – 21 / Line 33 – 36 / Line 29 – 32 and Col. 17 Line 28 – 34: (a) receiving a network access request, by a proxy server, from a user device as well as from a network request simulator (tool), (b) the dynamic object of request parameters from the user device can be compared with the (predetermined) static object of request parameters as capture from the network simulation tool so as to determine an adaptability (elasticity) of optimizing the network request parameters for dynamic object of request parameters from the user device – for example, maximum burst size to avoid congestions non-linear overloading conditions during the TCP connection periods).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention was made to propose the modification of configuring the proxy server to compare the request with a predetermined compatible request captured by a simulation tool because Ganapathi teaches to alternatively, effectively and securely provide a comprehensive security mechanism by receiving a network access request, at a proxy server, from a user device as well as from a network request simulator (tool), (b) the dynamic object of request parameters from the user device can be compared with the (predetermined) static object of request parameters as capture from the network simulation tool so as to determine an adaptability (elasticity) of optimizing the network request parameters for dynamic object of request parameters from the user device – for example, maximum burst size to avoid congestions non-linear overloading conditions during the TCP connection periods (see above) within the Herrmann’s system of a proxy server forwarding the network access request message to the primary RADIUS server for authentication purpose (see above).
Claim 17 is rejected under 35 U.S.C.103 as being unpatentable over Herrmann et al. (U.S. Patent 2004/0107360), in view of Guo et al. (CN 14-555-51 A).
As per claim 17, Guo (& Herrmann) wherein the proxy server further comprises a FreeRADIUS server installed on a computing platform in communication with the RADIUS server and configured to implement modifications to the authentication requests (Herrmann: see above: modifications to the (access) authentication requests received from a client) || (Guo: Page 5 / 2nd Para: a FreeRADIUS server can be installed and operated along with a proxy server (i.e. as a part of the proxy server) for user login and authentication purpose as well as further transferring an access request to a remote server (e.g. a RADIUS server)).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention was made to propose the modification of utilizing a FreeRADIUS server installed on a computing platform in communication with the RADIUS server and configured to implement modifications to the authentication requests because Guo teaches to alternatively, effectively and securely provide a comprehensive security mechanism install and operate a FreeRADIUS server along with a proxy server for user login and authentication purpose and further transferring an access request to a remote server (e.g. a RADIUS server) (see above) within the Herrmann’s system of a proxy server forwarding the network access request message to the primary RADIUS server for authentication purpose (see above).
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LONGBIT CHAI whose telephone number is (571)272-3788. The examiner can normally be reached Monday - Friday 9:00am-5:00pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Lynn D. Feild can be reached at 571-272-2092. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
---------------------------------------------------
/Longbit Chai/
Longbit Chai E.E. Ph.D.
Primary Examiner, Art Unit 2431
No. #2570 – 2026 ---------------------------------------------------