DETAILED ACTION
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 .
Status of claims
This office action is in response to claims filed on 06/02/2025; the parent application priority date of 07/26/2021 is considered
Claims 1-20 are pending and rejected; claims 1, 12 and 20 are independent claims
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 07/15/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, 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.
Claim(s) 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Shastri et al. US Pub. No.: 2017/0118025 A1 (hereinafter Shastri) in view of Karnaros et al. US Pub. No.: 2022/0303268 A1 (hereinafter Karnaros).
Shastri discloses:
As to claim 1, a system, comprising: one or more processors, coupled with memory, to:
transmit, for display via a graphical user interface of a first system, one or more indications of a plurality of applications to log in without a password input to a service provided by a service provider via an interface of the service provider (see Shastri Figs. 1-5 and ¶¶100, 53, 61, GUI 500 may display an interactive area 502 with one or more interactive elements, e.g., interactive elements 510, 512, 514, for selecting different options for obtaining security information [i.e. one or more indications of a plurality of applications to login without a password input to a service]. Interactive element 510 may corresponding to an option to receive security information at an application on a mobile device [i.e. for display via a graphical user interface of a first system];¶¶63-64, The resource may be accessed through an interface, such as a graphical user interface, presented in an application (e.g., a browser). To determine access, an application of access management system 140 may facilitate an authentication process ¶¶43-44, Access management system 140 may also provide services or software applications can include non-virtual and virtual environments. In some embodiments, these services may be offered as web-based or cloud services or under Software as a Service (SaaS) model to the users of clients [i.e. one or more applications to a service provided by a service provider via an interface of the service provider]);
cause, responsive to a selection of an application of the plurality of applications, display of a first window of the application via the graphical user interface, wherein the first window of the application comprises a first request for a communication to exchange between the application and a second system (see Shastri Fig. 5-6 and ¶101, The authentication processes may include multi-factor authentication, which can utilize authentication processes on device 602…, device 602 may provide an interface with a prompt 604 requesting biometric (e.g., fingerprint) input for authentication [i.e. display a first window of the application]. Interactive element 606 may be used to provide the biometric input,[i.e. display of a first window of the application comprises a first request for a communication to exchange between the application and a second system]; ¶¶70-72, An application at client 204 may prompt a user with an interface to choose an option for receiving temporary access information. Step 232 may be performed based on the option selected [i.e. in response to selection of an option of the plurality of applications, display of a first window of the application via the graphical user interface ]. The application may communicate with access management system 140 to provide the option for temporary access information. At step 232, temporary access information may be provided using a variety of techniques to ensure secure access for registration of a device as a trusted device [i.e. wherein the first window of the application comprises a first request for a communication to exchange between the application and a second system]. Techniques include sending the temporary access information to a device (e.g., client 202) of the user, an email account of the user, a device associated with a phone number (e.g., an short messaging system message), or to a device through an application, such as one downloaded at client 202)
determine, based on the communication between the application and the second system, that the first request is satisfied (see Shastri ¶72, access management system 140 may verify the temporary access information to determine that the temporary access information is correct as generated and is valid for the criteria defined for the temporary access information.)
activate, responsive to the determination that the second request is satisfied, the application to cause the application to establish a log-in via the interface, and without the password input via the interface, to access, from the first system, the service provided by the service provider (see Shastri ¶¶74, 90, At step 286, access management system 140 may communicate with client 204 to enable access to a resource. Access management system 140 may send information to notify an application on client 204 to enable access to resources. The information may include information about resources that are accessible or information for displaying options to enable access [i.e. without the password input via the interface, to access, from the first system, the service provided by the service provider]).
Even though Shastri implicitly discloses:
in response to the determination that the first request is satisfied, cause display of a second window of the application via the graphical user interface, wherein the second window of the application comprises a second request for data to be provided via the application of the service provider using the second system (see Shastri Figs.2A-2B, 6-7 and ¶¶63, 101-102, Device 602 may provide an interface with an element 622 …, the security information may be provided by access management system or may be generated at device 602 by the application…, Interactive element 624 may enable a user to request operation of device 602 to capture security data displayed at a device to be registered with access management system 140.[i.e. in response to the determination that the first request is satisfied, cause display of a second window of the application via the graphical user interface]; ¶77, Upon determining that client 204 is a trusted device that is registered, access management system 140 may generate security data; ¶78, because client 204 is a trusted device (e.g., a device identified as being authenticated for a user based on multi-factor authentication), at step 266, access management system may send the security information to client 204 for the application at client 204 to generate the security data. [i.e. , wherein the second window of the application comprises a second request for data to be provided via the application of the service provider using the second system];
determine, based on the data provided via the graphical user interface, responsive to the second request, that the second request is satisfied (see Shastri ¶86, At step 280, access management system 140 may verify access based on communication received from client 202. Access management system may verify that the information (e.g., a request identifier or a security key) received from client 202 as obtained from the security data captured from client 204 matches the information in the security data sent to client 204 at step 266) ; and
Shastri does not explicitly disclose but the related art Karnaros discloses
wherein the second window of the application comprises a second request for data to be provided via the application of the service provider using the second system (see Karnaros ¶40 the registration process of FIG. 2 includes additional authentication operations to provide additional security to the registration process. These additional authentication operations can involve a security code generated by the server(s) 108, signed by the smartphone 104, or entered by the user into the desktop 106.) [i.e. second window of the application comprising a second request for data to be provided via the application of the service provider]
Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the invention, to modify the password-less authentication for access management disclosed by Shastri to include the second window of the application comprising a second request for data to be provided via the application of the service provider, as thought by Karnaros. A person of ordinary skill in the art would have been motivated to do so, because additional/second data would provide enhance security and prevent an authorized access to resources. (see Karnaros ¶29).
As to claim 2, the combination of Shastri and Karnaros teaches the system of claim 1, wherein the one or more processors further:
generate, responsive to the activation of the application, for display on the graphical user interface, a notification to use the application of the service provider for a subsequent log-in to an account to use the service of the service provider (see Shastri ¶¶63, 90, At step 288, an application on client 204 may enable access to resources. For example, the application may provide an interface (e.g., portal) to access different resources. The resources may be provided by one or more resource management systems.; ¶120, the first device and/or its location may be identified as a trusted source for access, thereby permitting password-less authentication upon subsequent requests from the device/location.) , and wherein the first system includes a client device providing the graphical user interface and the second system includes one of a messaging system, email system or a phone system associated with a user of the account.(see Shastri Fig. 2A-2B, client device (204, 202)/first system, and Access management system (104)/ second system; Fig. 5 and ¶70, At step 232, temporary access information may be provided using a variety of techniques to ensure secure access for registration of a device as a trusted device. Techniques include sending the temporary access information to a device (e.g., client 202) of the user, an email account of the user, a device associated with a phone number (e.g., an short messaging system message), or to a device through an application, such as one downloaded at client 202) [i.e. second system including messaging/email/phone system as server for authentication]).
As to claim 3, the combination of Shastri and Karnaros teaches the system of claim 2, wherein the one or more processors further:
receive a validation of a login to access the account associated with the interface of the service provider that provides the service and wherein the service of the service provider utilizes a computer structure of the service provider to access employer data corresponding to one of a payroll, a benefit, or a financial information of one or more employees (see Shastri ¶¶157, a cloud service provider's system may host an application, and a user may, via a communication network such as the Internet, on demand, order and use the application; ¶5, a user may attempt to access a human resources database to gather information about certain employees such as salary information. The user's web browser makes a request to the application, which requires authentication)
As to claim 4, the combination of Shastri and Karnaros teaches the system of claim 1, wherein the plurality of applications configured to log-in, without any password and via the interface, comprise one or more applications configured to execute at least one of: a process that texts a sign-in passcode to a client device; a process that uses a biometric authentication on the client device; a process that transmits audio data comprising a passcode to the client device; or a process that sends an email to an email address (see Shastri ¶70 Techniques include sending the temporary access information to a device (e.g., client 202) of the user, an email account of the user, a device associated with a phone number (e.g., an short messaging system message), or to a device through an application, such as one downloaded at client 202) .
As to claim 5, the combination of Shastri and Karnaros teaches the system of claim 1, wherein the one or more processors further: generate, responsive to the selection of the application from the plurality of applications, the first window comprising a first prompt for a selection of the second system to provide the data responsive to the second request; determine, responsive to communication comprising the selection of the second system, that the first request is satisfied (see Shastri Figs. 5-6, ¶¶100-101, illustrates an example of a device 602 (e.g., computing device 114 or client 202), that enables another device (e.g., computing device 104 or client 204) to be registered as a trusted device. Device 602 is shown with different GUIs of an application (e.g., mobile authenticator application) of access management system 140. The application may be used for registration of a device (e.g., client 204) as a trusted device and/or may be used for password-less authentication of a user at the trusted device after registration)
As to claim 6, the combination of Shastri and Karnaros teaches the system of claim 5, wherein the one or more processors further:
generate, responsive to the determination that the first request is satisfied, the second window comprising a second prompt for a passcode communicated to the application of the service provider via the second system; and determine, using the passcode provided via the second system, that the second request is satisfied see Shastri Figs.2A-2B, 6-7 and ¶¶63, 101-102, Device 602 may provide an interface with an element 622 …, the security information may be provided by access management system or may be generated at device 602 by the application…, Interactive element 624 may enable a user to request operation of device 602 to capture security data displayed at a device to be registered with access management system 140.[i.e. in response to the determination that the first request is satisfied, cause display of a second window of the application via the graphical user interface]; ¶77, Upon determining that client 204 is a trusted device that is registered, access management system 140 may generate security data; ¶78, because client 204 is a trusted device (e.g., a device identified as being authenticated for a user based on multi-factor authentication), at step 266, access management system may send the security information to client 204 for the application at client 204 to generate the security data. [i.e. , wherein the second window of the application comprises a second request for data to be provided via the application of the service provider using the second system]) In addition (see Karnaros ¶40 the registration process of FIG. 2 includes additional authentication operations to provide additional security to the registration process. These additional authentication operations can involve a security code generated by the server(s) 108, signed by the smartphone 104, or entered by the user into the desktop 106 [i.e. second window of the application comprising a second request for data to be provided via the application of the service provider])
Similar rational applied as above to combine the cited prior art references.
As to claim 7, the combination of Shastri and Karnaros teaches the system of claim 6, wherein the one or more processors further: log in to an account associated with the interface of the service provider, via the application utilizing the passcode during a subsequent log-in, to use the service of the service provider to access employer data via the interface of the service provider (see Shastri ¶27, The term “password-less” signifies that each of the alternatives enable the user to gain access to the service provider account through the interface in subsequent entry attempts via alternative structures that do not require that the user provide a password, as more fully explained below; ¶41, FIG. 4 is a graphic illustration of use of the enabled “text a passcode sign in” password-less sign-in alternative 306 and includes a window 420 that the configured processor presents to a user in response to subsequent login request from the user to access a service provider account interface for which the user has selected the “text a passcode sign in” password-less sign-in alternative 306 (at FIG. 1 204), as confirmed in window 410 of FIG. 3.)
As to claim 8, the combination of Shastri and Karnaros teaches the system of claim 1, wherein the one or more processors further:
authenticate, using a camera of the first system, a user associated with an account associated with the interface of the service provider; and log in, responsive to the authentication of the user using the camera and using the application, to the account to use the service of the service provider during a subsequent log-in (see Shastri ¶81, application may be configured to utilize one or more functions (e.g., camera, mic, or video recorder) on a device to capture security data presented at a client. In some embodiments, the security data sent at step 270 may be sent upon the user gaining access to the application at step 272. The application may communicate with access management system 140 for authentication of the user. Upon successful authentication, access management system 140 may sent the security data).
As to claim 9, the combination of Shastri and Karnaros teaches he system of claim 1, wherein the one or more processors further:
present for display, via the graphical user interface, a quick response code that comprises a link to a uniform resource location (see Karnaros ¶129, login service encodes the screen identifier and a login link (e.g., a URL of an API endpoint implemented by the login service) into a QR code and serves a page to the browser that includes the QR code);
generate, via a biometric routine of the first system, an authentication output to authenticate an identity indicia associated with an account (see Shastri ¶81, Authentication techniques may include biometric authentication and other input driven authentication techniques); and
log in, responsive to the authentication output and via the application, to an account to use the service of the service provider, responsive to the authentication output (see Shastri ¶81, Authentication techniques may include biometric authentication and other input driven authentication techniques).
Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the invention, to modify the password-less authentication for access management disclosed by Shastri to include a quick response code that comprises a link to a uniform resource location, as thought by Karnaros. A person of ordinary skill in the art would have been motivated to do so, because subsequently, the mobile computing device decodes the QR code and launches a login agent that is associated with the login link. (see Karnaros ¶130).
As to claim 10, the combination of Shastri and Karnaros teaches the system of claim 1, wherein the communication between the application and the second system includes a telephone number associated with the first system and wherein the one or more processors further determine, responsive to the communication comprising voice data, that the first request is satisfied (see Shastri ¶77, Upon determining that client 204 is a trusted device that is registered, access management system 140 may generate security data. The security data may be audio data, video data, image data, other types of data).
As to claim 11, the system of claim 10, wherein the data to be provided via the application in the second window include a passcode provided via the voice data (see ¶185, user interface input devices may include voice recognition sensing devices that enable users to interact with voice recognition systems (e.g., Siri® navigator), through voice commands)
As to independent claim 12, this claim directed to a method executed by the system of claim 1; therefore it is rejected along similar rationale
As to independent claim 20, this claim directed to a non-transitory computer readable media storing instructions executed by the system of claim 1; therefore it is rejected along similar rationale.
As to dependent claims 13-19, these claims contain substantially similar subject matter as claim 2-8; therefore they are rejected along the same rationale.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NEGA WOLDEMARIAM whose telephone number is (571)270-7478. The examiner can normally be reached Monday to Friday, 8am-5pm.
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, Cathy Thiaw can be reached at 5712701138. 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.
NEGA . WOLDEMARIAM
Examiner
Art Unit 2407
/N.W/ Examiner, Art Unit 2407
/Catherine Thiaw/ Supervisory Patent Examiner, Art Unit 2407 8/18/2026
Prosecution Insights