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
This non-final action is responsive to application filed on 01/27/2025. Claims 1-20 are pending, with claims 1, 10 and 16 being independent.
Priority
This application claims the benefit of priority under 35 U.S.C. § 119(e) to U.S. Provisional Application No. 63/735,092, filed on December 17, 2024.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 01/27/2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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 claimed 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.
Claims 1, 4, 9, 10, 13, 16 and 18 are rejected under 35 U.S.C. 103 as being unpatentable Schlicher (US 2019/0124089, published Apr. 25, 2019).
As per claim 1, Schlicher discloses a method comprising:
receiving, by an authentication intermediator, a login identifier for a user (Schlicher Fig. 6, Flow Control 22/24 get separate user authentication from Authenticator 28; Schlicher par. 23, The event-based authenticator subsystem 28 receives requests identifying a username or usernames to authenticate, and then determines an authentication method corresponding to each username. [Implicitly, Flow Control 22/24 receives username so that it can make request separate user authentication for the username from Authenticator 28), wherein the login identifier includes a username (Schlicher par. 23, The event-based authenticator subsystem 28 receives requests identifying a username or usernames to authenticate, and then determines an authentication method corresponding to each username);
requesting, by the authentication intermediator, one or more authentication methods associated with the login identifier from a centralized authentication server (Schlicher Fig. 6, Flow Control 22/24 get separate user authentication from Authenticator 28; Schlicher par. 23, The event-based authenticator subsystem 28 receives requests identifying a username or usernames to authenticate, and then determines an authentication method corresponding to each username), wherein the one or more authentication methods are configured to authenticate the user to a system or a device via the centralized authentication server (see Schlicher Fig. 5, get separate user authorization at 512 to Retrieve Files in Vault at 518), and wherein the centralized authentication server is separate from the system or the device (see Schlicher Fig. 2, Authenticator 28 is separate from Data Vault Repository 70);
obtaining the one or more authentication methods from the centralized authentication server based on the login identifier (Schlicher par. 23, The event-based authenticator subsystem 28 receives requests identifying a username or usernames to authenticate, and then determines an authentication method corresponding to each username); and
instantiating an authentication session with the user based on the one or more authentication methods (Schlicher par. 24, The event-based authenticator subsystem 28 can execute the authentication method by communicating with a separate user device corresponding to the user who corresponds to the username account).
Note, Schlicher teaches that Flow Control 22/24 (correspond to authentication intermediator) and Authenticator 28 (correspond to centralized authentication server), and teaches that obtaining authentication method and instantiating authentication session by Authenticator 28 (correspond to centralized authentication server), but does not teaches obtaining authentication method and instantiating authentication session by Flow Control 22/24 (correspond to authentication intermediator) (i.e., obtaining, by the authentication intermediator, the one or more authentication methods from the centralized authentication server based on the login identifier; and instantiating, by the authentication intermediator, an authentication session with the user based on the one or more authentication methods).
However, obtaining authentication method and instantiating authentication session by Flow Control 22/24 (i.e., obtaining, by the authentication intermediator, the one or more authentication methods from the centralized authentication server based on the login identifier; and instantiating, by the authentication intermediator, an authentication session with the user based on the one or more authentication methods) was an obvious matter of design choice to offload tasks (e.g., authenticating user) from one unit (e.g., Authenticator 28) to another unit (Flow Control 22/24) for reducing workload of Authenticator 28.
As per claim 4, Schlicher discloses the method of claim 1, wherein the system includes a computer system comprising one or more software applications (this limitation is optional), and wherein the device includes a user device or a network device (Schlicher Fig. 2, Data Vault Repository 70).
As per claim 9, Schlicher discloses the method of claim 1, wherein the authentication intermediator is a function running on a server or computing device that is separate from the device or the system (see Schlicher Fig. 2, Flow Control 22/24 is separate from Data Vault Repository 70).
Claims 10 and 13 do not teach or further define over the limitations in claims 1 and 4 respectively. As such, claims 10 and 13 are rejected for the same reasons as set forth in claims 1 and 4, respectively.
Claims 16 and 18 do not teach or further define over the limitations in claims 1 and 4 respectively. As such, claims 16 and 18 are rejected for the same reasons as set forth in claims 1 and 4, respectively.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable Schlicher (US 2019/0124089, published Apr. 25, 2019) and Koottayi et al. (US 2018/0288063, published Oct. 4, 2018).
As per claim 7, Schlicher discloses the method of claim 1, but does not explicitly disclose wherein the user connects to the authentication intermediator via a pluggable authentication module (PAM).
Koottayi teaches:
the user connects to the authentication intermediator via a pluggable authentication module (PAM) (Koottayi par. 76, the one or more proxies 150 may be authentication proxies that handle user authentication for resources… An example of such an authentication proxy is a pluggable authentication module (PAM) used in Linux systems).
It would have been obvious to one skilled in the art before the effective filing date of the claimed invention to modify the method of Schlicher with the teaching of Koottayi to incorporate a pluggable authentication module (PAM) for the user connects to the authentication intermediator via a pluggable authentication module (PAM). One of ordinary skilled in the art would have been motivated because it offers the advantage of providing a common authentication scheme that can be used with a wide variety of applications.
Claims 8, 15 and 20 are rejected under 35 U.S.C. 103 as being unpatentable Schlicher (US 2019/0124089, published Apr. 25, 2019) and Kakutani (US 2018/0288063, published Oct. 4, 2018).
As per claim 8, Schlicher discloses the method of claim 1, but does not explicitly disclose further comprising:
updating the one or more authentication methods stored on the centralized authentication server based on one or more additional authentication methods associated with the user.
Kakutani teaches:
updating the one or more authentication methods stored on the centralized authentication server based on one or more additional authentication methods associated with the user (Kakutani par. 84, If the control unit 1 has received the user authentication method via the processing of step S0805 at this time, the control unit 1 stores the received contents in the HDD 204 as the first authentication method and the second authentication method).
It would have been obvious to one skilled in the art before the effective filing date of the claimed invention to modify the method of Schlicher with the teaching of Kakutani for updating the one or more authentication methods stored on the centralized authentication server based on one or more additional authentication methods associated with the user. One of ordinary skilled in the art would have been motivated because it offers the advantage of improving security and providing more flexibility for user in authentication.
Claim 15 does not teach or further define over the limitations in claim 8. As such, claim 15 is rejected for the same reasons as set forth in claim 8.
Claim 20 does not teach or further define over the limitations in claim 8. As such, claim 20 is rejected for the same reasons as set forth in claim 8.
Allowable Subject Matter
Claims 2, 3, 5, 6, 11, 12, 14, 17 and 19 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten to include all of the limitations of the base claim and any intervening claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 10616196 B1; User Authentication With Multiple Authentication Sources And Non-binary Authentication Decisions
An authentication request is received from an application server to authenticate a user for access to a protected resource. Pre-flow rules and the authentication request are evaluated to dynamically determine a plurality of authentication servers to invoke for the authentication request and an order for the invocation. A first authentication server is contacted to obtain a first authentication result for the user. In-flow rules and the first authentication result are evaluated to determine if additional authentication of the user should be performed. A second authentication server is contacted based on the determined invocation order and/or a result of the in-flow rules to obtain a second authentication result for the user. Decision rules and the first and second authentication results are evaluated to determine an authentication decision.
US 20220311801 A1; System And Method For Identifying Authentication Method Of Secure Shell (SSH) Sessions
The disclosure relates generally to identifying an authentication method for SSH sessions. The disclosed system and method may be used in several different technical fields including network security monitoring, incident response and network forensics and/or mis-use detection.
US 20170337366 A1; Working Method Of Voice Authentication System And Device
The method includes that: an application server sends user information sent by an application interface and a stored application name to an authentication server; the authentication server generates a push authentication request according to a generated challenge value, the user information and the application name and sends the push authentication request to a mobile terminal token; the mobile terminal token generates voice information, collects the voice response of user, generates a first response value according to the challenge value and sends the challenge value to the authentication server when determining that logon is authorized; the authentication server generates a second response value, returns successful authentication when two response values are identical.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KHANG DO whose telephone number is (571)270-7837. The examiner can normally be reached Monday-Friday 8:00 - 5:00 EST.
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, RUPAL DHARIA can be reached at (571) 272-3880. 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.
/KHANG DO/Primary Examiner, Art Unit 2492
Prosecution Insights