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 .
This written action is responding to the amendment dated on 12/30/2025.
Claims 1-2, 7, 13-14, 18 and 20 has been amended.
Claims 1-20 are submitted for examination.
Claims 1-20 are pending.
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.
Response to Arguments
Applicant’s amendment, filed on December 30, 2025, has claims 1-2, 7, 13-14, 18 and 20 amended and all other claims has been previously presented. Claims 1, 14 and 20 are independent claims.
Applicant’s remark, filed on December 30, 2025 at pages 11-14, indicates, “… Applicant notes that claim 1 recites a scheme of a first device requesting authentication by a second device. The scheme is implemented with: (1) a first device identifies, to a server, a second device to authenticate its login request; (2) the server transmits the login request with a GUI element to the second device; and (3) the second device provides, via the GUI element, credential to the server for authenticating the first device. In contrast, Bokare's authentication, as acknowledged in the Office Action on page 4, is based on session token and by the same device as depicted in, e.g., FIGs. 2 and 3 and described in, e.g., para. [0034], [0005] and [0045]. Although Narasimhan teaches the concept of authentication by a different device, Narasimhan implements the concept differently from the above step recited in claim 1. For example, Narasimhan in para. [0066]-[0067] teaches, "[0066] In some implementations, the method 400 includes requesting a second user on a second device to authenticate a first user on a first device (different from the second device). For example, user Alice and user Bob may share the same user name for a payment account, e.g., because they are husband and wife. [0067] Therefore, when user Alice tries to log into the payment account on her smartphone (which is not a trusted device with respect to the payment account), user Bob receives a message 402 asking him to either approve or deny Alice's request to authenticate herself for logging into the payment account. User Bob can send a response 404 to approve user Alice's login request." (Emphasis added). In above para. [0066]-[0067], Narasimhan teaches that Bob either approve or deny Alice's request. Narasimhan does not teach and/or suggest the claim recited … In contrary to claim 1, Narasimhan teaches a "passwordless experience". For example, Narasimhan in para. [0083] teaches, "[0083] A push notification (PN) will be sent to the trusted primary device (TPD). The user then confirms the registry of the new device from the TPD. The server now pushes the corresponding SK for the TPD into the ND. Now the ND is ready for a passwordless experience." (Emphasis added). Narasimhan's "passwordless experience" teaches away from the claim recited, "authenticating, by the server, the first user based on the login credential received from the second device." (Emphasis added). The above deficiency cannot be remedied by Vincent, as Vincent does not teach multiple users assessing the same account. The above claim element is similarly present in independent claims 14 and 20, thus is not taught and/or suggested by the cited references for at least similar reasons. In light of the above, applicant respectfully submits that claims 1, 14 and 20, and dependent claims 2-13 that depend on claim 1, claim 15-19 that depend on claim 14, are patentable in view of cited references.”
Applicant’s arguments have been fully considered and is found persuasive. However, a new ground of rejection is made based on a new prior art by Vincent et al. (US 9,706,401), hereinafter Vincent.
Examiner acknowledges that the combination of the previously applied prior-art references does not discloses “authenticating, by the server, the first user based on the login credential received from the second device”. However, the newly applied reference by Vincent shows, in Fig. 1, a system comprising a first device, a second device and a server in communication to facilitate user-authentication-based approval of a first device via communication with a second device in accordance with an embodiment. Specifically, Vincent, in Col. 5, lines 25-26, teaches a server 102 including an identity provider 120 and an identity provider component will perform user authentication. In addition, Col. 11-12, lines 58-3 of Vincent discloses that second device will receive a security challenge that comprise a request for the user to provide one or more credentials (e.g., a user ID and password) via interaction with user interface 142. The response 212 to the security challenge will only be generated and transmitted to identity provider 120 (i.e., the server) by second user-authentication-based approval logic 140 (i.e., second device) only after the user inputs the requested credentials via user interface 142. Finally, at Col. 12, lines 20-31; describes when the response 212 to the security challenge is sent to identity provider 120, then identity provider 120 will examine response 212 to determine if it comprises a valid response to the security challenge. If identity provider 120 determines that response 212 is a valid response to the security challenge, then identity provider 120 will approve first device 104. Identity provider 120 may approve first device 104 by sending a security token 214 to first user authentication-based approval logic 130 of first device 104 via communication channel 110, wherein the security token indicates that a user of first device 104 has been authenticated”. Thus, Examiner submits that the newly identified reference by Vincent discloses the claimed amended feature. Please also refer to the detailed prior-art rejection below.
Additionally, Examiner submits that after carefully reviewed the previously applied reference by Bokare, it has been concluded that Bokare discloses some of the amended claimed features. Specifically, Bokare, in Parag. [0036], discloses receiving, from one or more clients, a request to access resources associated with the user account (i.e., first user account). For example, communication module 108 may, as part of server 206 in FIG. 2, receive, from client 208 (i.e., first device), access request 218 to access user resources 210 associated with user account 214”. Paragraphs [0005] and [0045] clearly discloses authentication policy may include (1) displaying (i.e., using a GUI), on the associated device (i.e., second device), a notification that the request to access the resources associated with the user account has been received, (2) displaying, on the associated device, information identifying the client (i.e., first device identifier) requesting access to the resources associated with the user account, (3) obtaining, via the associated device, permission to access the resources associated with the user account, and/or (4) authenticating the user account using authentication factors obtained via the associated device and display a notification (i.e., login notification) that a request to access the resources associated with the user account has been received. Therefore, Bokare teaches “transmitting, by the server, a login request notification of the login request, to the second device identified by the second device identification, to request the second user associated with the second device to authenticate the login request of the first user and wherein the login request notification comprises the first device identification and a graphical user interface (GUI) element configured to display the first device identification on the second device and allow the second user to enter, in the second device, a login credential corresponding to the login request” (Additional citation has been provided). Finally, Narasimhan discloses a second device identification of the second device different from the first device. At Parag. [0053], Narasimhan discloses the user can register the device (e.g., the desktop computer) with a service provider of the payment account (e.g., the PAYPAL Inc.). In some embodiments, registering the device includes providing a device identifier (e.g., an IMEI number of a phone) or other information (e.g., uniquely) identifying the device (e.g., a device name, a device's make and model, and a device version number) to the authentication system, which can register the device identifier in the user database. Therefore, examiner submits that Narasimhan’s device identifier has been interpreted as the second device identifier. (See rejection below)
Examiner respectfully submits that the new combination of Bokare, Narasimhan and Vincent teaches the feature limitations of the amended independent claim 1.
Applicant’s remark, filed on September 22, 2025 at pages 10-13, indicates, “The above claim element is similarly present in independent claims 14 and 20, thus is not taught and/or suggested by the cited references for at least similar reasons. In light of the above, applicant respectfully submits that claims 1, 14 and 20, and dependent claims 2-13 that depend on claim 1, claim 15-19 that depend on claim 14, are patentable in view of cited references.”
Please refer to the aforementioned response in the above item 9, which addresses how the new combination of prior art by Bokare, Narasimhan and Vincent would render the amended independent claims 14 and 20 obvious.
Regarding dependent claims 2-13 and 15-19 please refer to the aforementioned response, which addresses how the new combination of prior arts by Bokare, Narasimhan, Vincent, along with Richards and Zavesky would render the claim limitations obvious.
Claim Objections
Claim 1 is objected to because of the following informalities: Claim 1 recites, “… wherein the login request notification comprises the first device identification and a graphical user interface (GUI) element configured to display the first device identification on the second device …”. However, it is not clear how a login request comprises a GUI element configured to display the first device identification on the second device. Appropriate correction is required.
Claim Rejections - 35 USC § 103
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 (i.e., changing from AIA to pre-AIA ) 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.
Claims 1-6, 8, 12-17 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Bokare et al. (US 2017/0195429 A1) hereinafter Bokare, in view of Narasimhan et al. (US 2017/0372310 A1) hereinafter Narasimhan, and Vincent et al. (US 9,706,401) hereinafter Vincent.
Regarding claim 1, Bokare teaches:
A computer-implemented method comprising (Bokare, Parag. [0004]; “In one example, a computer-implemented method”);
hosting, by a server, at least one online service accessed by a plurality of users utilizing a [plurality of] user account[s], wherein each of the user accounts is configured for a plurality of concurrent authenticated access sessions by a plurality of devices (Bokare, Parag. [0025]; “In one embodiment, one or more of modules 102 from FIG. 1 may, when executed by at least one processor of associated device 202, server 206, and/or client 208, enable associated device 202, server 206, and/or client 208 to facilitate single sign-on for multiple devices. For example, and as will be described in greater detail below, sign-on module 104 may establish a login session 212 for a user account 214. Session module 106 may, in response to establishing login session 212, provide a session token 216 for user account 214 to a device associated with user account 214. Communication module 108 may receive, from at least one client 208, an access request 218 to access user resources 210 associated with user account 214. Verification module 110 may determine that associated device 202 possesses session token 216 for user account 214. Access module 112 may, in response to determining that associated device 202 possesses session token 216, provide, to client 208, access to user resources 210 associated with user account 214” … Parag. [0031]; “For example, sign-on module 104 may execute on a web server that receives login requests from users to access services provided by the web server”. … Parag. [0032]; “In some examples, sign-on module 104 may establish the login session for the user account occurs in response to receiving a request to access the resources associated with the user account. For example, sign-on module 104 may, as part of server 206 in FIG. 2, initiate login session 212 after receiving a request from client 208 or associated device 202 to access user resources 210”);
receiving, by the server, a login request to establish, via a first user account, a first authenticated access session between the at least one online service and a first device associated with a first user, attempting to access the first user account (Bokare, Parag. [0031]; “For example, sign-on module 104 may execute on a web server that receives login requests from users to access services provided by the web server” … Parag. [0036]; “At step 306, one or more of the systems described herein may receive, from one or more clients, a request to access resources associated with the user account (i.e., first user account). For example, communication module 108 may, as part of server 206 in FIG. 2, receive, from client 208 (i.e., first device), access request 218 to access user resources 210 associated with user account 214”.),
wherein the login request comprises the first device identification of the first device (Bokare, Parag. [0031]; “For example, sign-on module 104 may execute on a web server that receives login requests from users to access services provided by the web server” … Parag. [0036]; “At step 306, one or more of the systems described herein may receive, from one or more clients, a request to access resources associated with the user account. For example, communication module 108 may, as part of server 206 in FIG. 2, receive, from client 208, access request 218 to access user resources 210 associated with user account 214”. … … Parag. [0045]; “An authentication policy may, for example, specify that the associated device should display a notification that a request to access the resources associated with the user account has been received. In another example, an authentication policy may specify that the associated device should display information identifying the client requesting access to the resources associated with the user account, such as the client's location or IP address (i.e., first device identifier). An authentication policy may also direct the associated device to obtain permission to access the resources associated with the user account or obtain additional authentication factors that may be used to authenticate the client to the user account”) and [a second device identification of the second device different from the first device];
transmitting, by the server, a login request notification of the login request, to the second device [identified by the second device identification], to request the second user associated with the second device to authenticate the login request of the first user (Bokare, Parag. [0005]; “In some examples, establishing the login session for the user account occurs in response to receiving a request to access the resources associated with the user account. In some examples, the computer-implemented method may further include applying an authentication policy before providing access to the resources associated with the user account, where the authentication policy may include (1) displaying, on the associated device (i.e., second device), a notification that the request to access the resources associated with the user account has been received, (2) displaying, on the associated device, information identifying the client (i.e., first device identifier) requesting access to the resources associated with the user account, (3) obtaining, via the associated device, permission to access the resources associated with the user account, and/or (4) authenticating the user account using authentication factors obtained via the associated device” … Parag. [0045]; “An authentication policy may, for example, specify that the associated device should display a notification that a request to access the resources associated with the user account has been received. In another example, an authentication policy may specify that the associated device should display information identifying the client requesting access to the resources associated with the user account, such as the client's location or IP address. An authentication policy may also direct the associated device to obtain permission to access the resources associated with the user account or obtain additional authentication factors that may be used to authenticate the client to the user account”),
wherein the login request notification comprises the first device identification and a graphical user interface (GUI) element configured to display the first device identification on the second device and allow the second user to enter, in the second device, a login credential corresponding to the login request (Bokare, Parag. [0005]; “In some examples, establishing the login session for the user account occurs in response to receiving a request to access the resources associated with the user account. In some examples, the computer-implemented method may further include applying an authentication policy before providing access to the resources associated with the user account, where the authentication policy may include (1) displaying, on the associated device, a notification that the request to access the resources associated with the user account has been received, (2) displaying, on the associated device, information identifying the client requesting access to the resources associated with the user account, (3) obtaining, via the associated device, permission to access the resources associated with the user account, and/or (4) authenticating the user account using authentication factors obtained via the associated device” … Parag. [0045]; “An authentication policy may, for example, specify that the associated device should display a notification that a request to access the resources associated with the user account has been received. In another example, an authentication policy may specify that the associated device should display information identifying the client requesting access to the resources associated with the user account, such as the client's location or IP address. An authentication policy may also direct the associated device to obtain permission to access the resources associated with the user account or obtain additional authentication factors that may be used to authenticate the client to the user account” … Parag. [0058]; “For example, in certain embodiments I/O controller 520 may control or facilitate transfer of data between one or more elements of computing system 510, such as processor 514, system memory 516, communication interface 522, display adapter 526, input interface 530, and storage interface 534.” … Parag. [0061]; “As illustrated in FIG. 5, computing system 510 may also include at least one display device 524 coupled to communication infrastructure 512 via a display adapter 526. Display device 524 generally represents any type or form of device capable of visually displaying information forwarded by display adapter 526. Similarly, display adapter 526 generally represents any type or form of device configured to forward graphics, text, and other data from communication infrastructure 512 (or from a frame buffer, as known in the art) for display on display device 524.”); and
[authenticating, by the server, the first user based on the login credential received from the second device].
Bokare does not appear to explicitly teach:
a plurality of user accounts;
… a second device identification of the second device different from the first device;
the second device identified by the second device identification
authenticating, by the server, the first user based on the login credential received from the second device.
However, Narasimhan teaches:
a plurality of user accounts (Narasimhan, Parag. [0046]; “The user database 220 may store information identifying one or more user accounts (as shown in FIG. 7).”);
a second device identification of the second device different from the first device (Narasimhan, Parag. [0053]; “Upon a successful identity verification, the user can register (306) the device (e.g., the desktop computer 302) with a service provider of the payment account (e.g., the PAYPAL Inc.). In some embodiments, registering the device includes providing (310) a device identifier (e.g., an IMEI number of a phone) or other information (e.g., uniquely) identifying the device (e.g., a device name, a device's make and model, and a device version number) to the authentication system 106, which can register the device identifier in the user database 220” … Parag. [0066-0067]; “In some implementations, the method 400 includes requesting a second user on a second device to authenticate a first user on a first device (different from the second device). For example, user Alice and user Bob may share the same username for a payment account, e.g., because they are husband and wife. Therefore, when user Alice tries to log into the payment account on her smartphone (which is not a trusted device with respect to the payment account), user Bob receives a message 402 asking him to either approve or deny Alice's request to authenticate herself for logging into the payment account. User Bob can send a response 404 to approve user Alice's login request.” Examiner submits that the claimed first device is interpreted as Narasimhan’s secondary/second device and the claimed second device is interpreted as Narasimhan’s primary/first device.);
the second device identified by the second device identification(Narasimhan, Parag. [0053]; “Upon a successful identity verification, the user can register (306) the device (e.g., the desktop computer 302) with a service provider of the payment account (e.g., the PAYPAL Inc.). In some embodiments, registering the device includes providing (310) a device identifier (e.g., an IMEI number of a phone) or other information (e.g., uniquely) identifying the device (e.g., a device name, a device's make and model, and a device version number) to the authentication system 106, which can register the device identifier in the user database 220” … Parag. [0066-0067]; “In some implementations, the method 400 includes requesting a second user on a second device to authenticate a first user on a first device (different from the second device). For example, user Alice and user Bob may share the same username for a payment account, e.g., because they are husband and wife. Therefore, when user Alice tries to log into the payment account on her smartphone (which is not a trusted device with respect to the payment account), user Bob receives a message 402 asking him to either approve or deny Alice's request to authenticate herself for logging into the payment account. User Bob can send a response 404 to approve user Alice's login request.”.)
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Bokare before them, to modify Bokare that teaches the computer-implemented method; to include support for a plurality of user accounts, and providing a login request notification comprises the second device identification of the second device. One would have been motivated to have an improved overall system in which a user can perform transactions that require accessing protected resources (see Narasimhan Abstract).
Bokare in view of Narasimhan does not appear to explicitly teach:
authenticating, by the server, the first user based on the login credential received from the second device.
However, Vincent teaches:
authenticating, by the server, the first user based on the login credential received from the second device (Vincent, Col. 5, lines 11-16; “FIG. 1 is a block diagram of an example system 100 that facilitates user-authentication-based approval of a first device via communication with a second device in accordance with an embodiment. As shown in FIG. 1, system 100 includes a server 102, a first device 104, and a second device 106.” … Col. 5, lines 25-26; “As shown in FIG. 1, server 102 includes an identity provider 120.” … Col. 11-12, lines 58-3; “The manner in which the user of second device 106 can authorize the sending of response 212 to identity provider 120 will vary depending upon the type of security challenge that was received from identity provider 120. For example, the security challenge may comprise a request for the user to provide one or more credentials (e.g., a user ID and password) via interaction with user interface 142. In accordance with such an embodiment, response 212 to the security challenge will only be generated and transmitted to identity provider 120 by second user-authentication-based approval logic 140 only after the user inputs the requested credentials via user interface 142.” … Col. 12, lines 20-31; “If response 212 to the security challenge is sent to identity provider 120, then identity provider 120 will examine response 212 to determine if it comprises a valid response to the security challenge. If identity provider 120 determines that response 212 is a valid response to the security challenge, then identity provider 120 will approve first device 104. For example, identity provider 120 may approve first device 104 by sending a security token 214 to first user authentication-based approval logic 130 of first device 104 via communication channel 110, wherein the security token indicates that a user of first device 104 has been authenticated.”)
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Bokare, Narasimhan and Vincent before them, to modify Bokare in view of Narasimhan that teaches the computer-implemented method; to include the authentication of a first user by the server using the credentials received. One would have been motivated to authenticate a user/device, using a GUI, when sharing access to services, as taught by Vincent (see Vincent Col. 12, lines 20-31).
Regarding claim 2, the combination of Bokare, Narasimhan and Vincent teaches the method of claim 1. Narasimhan further teaches:
wherein the second device identification is registered with the first user account (Narasimhan, Parag. [0044]; “In an embodiment, as part of registering the new device 102C as a trusted device, the authentication system 106 stores a secure key (e.g., an encrypted password or device identifier) on the secure element of the device 102C.”)
Regarding claim 3, the combination of Bokare, Narasimhan and Vincent teaches the method of claim 1.
Bokare further teaches:
upon authorization of the login request via the GUI element (Bokare, Parag. [0005]; “In some examples, establishing the login session for the user account occurs in response to receiving a request to access the resources associated with the user account. In some examples, the computer-implemented method may further include applying an authentication policy before providing access to the resources associated with the user account, where the authentication policy may include (1) displaying, on the associated device, a notification that the request to access the resources associated with the user account has been received, (2) displaying, on the associated device, information identifying the client requesting access to the resources associated with the user account, (3) obtaining, via the associated device, permission to access the resources associated with the user account, and/or (4) authenticating the user account using authentication factors obtained via the associated device” … Parag. [0045]; “An authentication policy may, for example, specify that the associated device should display a notification that a request to access the resources associated with the user account has been received. In another example, an authentication policy may specify that the associated device should display information identifying the client requesting access to the resources associated with the user account, such as the client's location or IP address. An authentication policy may also direct the associated device to obtain permission to access the resources associated with the user account or obtain additional authentication factors that may be used to authenticate the client to the user account” … Parag. [0058]; “For example, in certain embodiments I/O controller 520 may control or facilitate transfer of data between one or more elements of computing system 510, such as processor 514, system memory 516, communication interface 522, display adapter 526, input interface 530, and storage interface 534.” … Parag. [0061]; “As illustrated in FIG. 5, computing system 510 may also include at least one display device 524 coupled to communication infrastructure 512 via a display adapter 526. Display device 524 generally represents any type or form of device capable of visually displaying information forwarded by display adapter 526. Similarly, display adapter 526 generally represents any type or form of device configured to forward graphics, text, and other data from communication infrastructure 512 (or from a frame buffer, as known in the art) for display on display device 524.), transmitting, by the server, information to associate login credentials of the first user of the first device with the second authenticated login session of the second device (Bokare, Parag. [0044]; “Access module 112 may provide access to the resources associated with the user account in a variety of ways. For example, access module 112 may, as part of a web server, create a session ID for the client and provide a cookie to the web browser running on the client to identify the session in transmissions between the client and web server. In another example, access module 112 may establish a connection between the client and server to be used with connection-oriented communication (such as SSL/TLS) between the client and server. In another example, access module 112 may be part of an authentication service that, in response to determining that the associated device possesses the session token, notifies the server that the client has been authenticated to the user account and should therefore be granted access to the resources associated with the account”).
Regarding claim 4, the combination of Bokare, Narasimhan and Vincent teaches the method of claim 1.
Narasimhan further teaches:
wherein the login credentials comprise a one-time login credential for use in connection with authenticating the login request only (Narasimhan, Parag. [0052]; “For example, as shown in FIG. 3, a user is registering (304) a payment account on the desktop computer 302. As part of the registration, the user may verify her identity by answering security questions (e.g., the name of her best female high school friend) or providing information uniquely identifying the user (e.g., the user's Social Security Number and Date of Birth) or confirm a phone number by sending a 1-time code.”).
Regarding claim 5, the combination of Bokare, Narasimhan and Vincent teach the method of claim 1.
Bokare further teaches:
wherein the login request notification is transmitted via the at least one online service (Bokare; Parag. [0005]; “In some examples, establishing the login session for the user account occurs in response to receiving a request to access the resources associated with the user account. In some examples, the computer-implemented method may further include applying an authentication policy before providing access to the resources associated with the user account, where the authentication policy may include (1) displaying, on the associated device, a notification that the request to access the resources associated with the user account has been received, (2) displaying, on the associated device, information identifying the client requesting access to the resources associated with the user account”).
Regarding claim 6, the combination of Bokare, Narasimhan and Vincent teaches the method of claim 1.
Bokare further teaches:
wherein selection/operation of the GUI element (Bokare, Parag. [0005]; “In some examples, establishing the login session for the user account occurs in response to receiving a request to access the resources associated with the user account. In some examples, the computer-implemented method may further include applying an authentication policy before providing access to the resources associated with the user account, where the authentication policy may include (1) displaying, on the associated device, a notification that the request to access the resources associated with the user account has been received, (2) displaying, on the associated device, information identifying the client requesting access to the resources associated with the user account, (3) obtaining, via the associated device, permission to access the resources associated with the user account, and/or (4) authenticating the user account using authentication factors obtained via the associated device” … Parag. [0045]; “An authentication policy may, for example, specify that the associated device should display a notification that a request to access the resources associated with the user account has been received. In another example, an authentication policy may specify that the associated device should display information identifying the client requesting access to the resources associated with the user account, such as the client's location or IP address. An authentication policy may also direct the associated device to obtain permission to access the resources associated with the user account or obtain additional authentication factors that may be used to authenticate the client to the user account” … Parag. [0058]; “For example, in certain embodiments I/O controller 520 may control or facilitate transfer of data between one or more elements of computing system 510, such as processor 514, system memory 516, communication interface 522, display adapter 526, input interface 530, and storage interface 534.” … Parag. [0061]; “As illustrated in FIG. 5, computing system 510 may also include at least one display device 524 coupled to communication infrastructure 512 via a display adapter 526. Display device 524 generally represents any type or form of device capable of visually displaying information forwarded by display adapter 526. Similarly, display adapter 526 generally represents any type or form of device configured to forward graphics, text, and other data from communication infrastructure 512 (or from a frame buffer, as known in the art) for display on display device 524.), transmitting, by the server, information to associate login credentials of the first user of the first device with the second authenticated login session of the second device (Bokare, Parag. [0044]; “Access module 112 may provide access to the resources associated with the user account in a variety of ways. For example, access module 112 may, as part of a web server, create a session ID for the client and provide a cookie to the web browser running on the client to identify the session in transmissions between the client and web server. In another example, access module 112 may establish a connection between the client and server to be used with connection-oriented communication (such as SSL/TLS) between the client and server. In another example, access module 112 may be part of an authentication service that, in response to determining that the associated device possesses the session token, notifies the server that the client has been authenticated to the user account and should therefore be granted access to the resources associated with the account”),
In addition, Narasimhan teaches:
to authorize the login request includes providing verification, by the first user of the first device, that the second device is associated with a trusted entity (Narasimhan, Parag. [0053]; “Upon a successful identity verification, the user can register (306) the device (e.g., the desktop computer 302) with a service provider of the payment account (e.g., the PAYPAL Inc.). In some embodiments, registering the device includes providing (310) a device identifier (e.g., an IMEI number of a phone) or other information (e.g., uniquely) identifying the device (e.g., a device name, a device's make and model, and a device version number) to the authentication system 106, which can register the device identifier in the user database 220” … Parag. [0066-0067]; “In some implementations, the method 400 includes requesting a second user on a second device to authenticate a first user on a first device (different from the second device). For example, user Alice and user Bob may share the same username for a payment account, e.g., because they are husband and wife. Therefore, when user Alice tries to log into the payment account on her smartphone (which is not a trusted device with respect to the payment account), user Bob receives a message 402 asking him to either approve or deny Alice's request to authenticate herself for logging into the payment account. User Bob can send a response 404 to approve user Alice's login request.” Examiner submits that under the broadest reasonable interpretation (BRI),the claimed first device is interpreted as Narasimhan’s secondary device and the claimed second device is interpreted as Narasimhan’s primary device. Therefore, Alice device is associated to Bob device that is the trusted device).
Regarding claim 8, the combination of Bokare, Narasimhan and Vincent teaches the method of claim 1.
Bokare further teaches:
making a determination that the first device is trusted prior to enabling authorization of the login request by the first device (Bokare, Parag. [0034]; “The term “associated device,” as used herein, generally refers to a device associated with a user account that is expected to be accessible to the user and/or someone authorized to control access to the user account. Examples of associated devices include, without limitation, a mobile phone or tablet computer that is expected to remain in the user's possession. The user may be asked to identify an associated device when the user account is created or when providing authentication credentials to be associated with the account”).
Regarding claim 12, the combination of Bokare, Narasimhan and Vincent teaches the method of claim 1.
Bokare further teaches:
registering, by the server, [a first device identification for the first device with] the first user account (Bokare, Parag. [0023]; “As illustrated in FIG. 1, exemplary system 100 may also include one or more databases, such as database 120. In one example, database 120 may be configured to store user account information, such as user IDs and credentials in encrypted form. Database 120 may represent portions of a single database or computing device or a plurality of databases or computing devices. For example, database 120 may represent a portion of server 206 in FIG. 2”)
Narasimhan further teaches:
registering a first device identification for the first device (Narasimhan, Parag. [0052]; “In some embodiments, the first device where a user registers a user identifier (as opposed to logging into an account using an existing user identifier) is considered the primary trusted device.”).
Regarding claim 13, the combination of Bokare, Narasimhan and Vincent teaches the method of claim 1.
Narasimhan further teaches:
registering, by the server, after the authenticating the first user, the second device identification for the second device with the first user account (Narasimhan, Parag. [0037]; “In some embodiments, a user device 102 is considered a trusted device after a user registers the user device 102 with a service provider (also referred to as a device on-boarding process in the present disclosure). For example, after meeting a predefined number of authentication criteria, a user can register, with the service provider, a corresponding device identifier (e.g., a phone number or an IMEI number) that identifies the user device 102.” … Parag. [0053]; “Upon a successful identity verification, the user can register (306) the device (e.g., the desktop computer 302) with a service provider of the payment account (e.g., the PAYPAL Inc.) (i.e., first user account register to make payments). In some embodiments, registering the device includes providing (310) a device identifier (e.g., an IMEI number of a phone) or other information (e.g., uniquely) identifying the device (e.g., a device name, a device's make and model, and a device version number) to the authentication system 106”. … Parag. [0055]; “In some embodiments, the user can register two or more devices as trusted devices in association with different user identifiers (e. g., for different application).”)
Regarding claim 14, the claim recites similar limitations as claims 1, 2, 12, and 13 and is rejected for similar reasons as claims 1, 2, 12, and 13 using similar teachings and rationale.
Regarding claim 15, the rejection of claim 14 is applied and in addition it is a method claim that recites similar limitations as corresponding claim 3 and is rejected for similar reasons as claim 3 using similar teachings and rationale.
Regarding claim 16, the rejection of claim 15 is applied and in addition it is a method claim that recites similar limitations as corresponding claim 4 and is rejected for similar reasons as claim 4 using similar teachings and rationale.
Regarding claim 17, the rejection of claim 14 is applied and in addition the claim recites similar limitations as corresponding claim 6 and is rejected for similar reasons as claim 6 using similar teachings and rationale.
Regarding claim 20, the claim recites similar limitations as corresponding claims 1 and 14 and is rejected for similar reasons as claims 1 and 14 using similar teachings and rationale.
Claims 7, 9 and 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over Bokare et al. (US 20170195429 A1) hereinafter Bokare, in view of Narasimhan et al. (US 2017/0372310 A1) hereinafter Narasimhan, and Vincent et al. (US 9,706,401) hereinafter Vincent as applied to claims 1 and 8, and further in view of Richards et al. (US 2015/0128240 A1) hereinafter Richards.
Regarding claim 7, the combination of Bokare, Narasimhan and Vincent teaches the method of claim 1.
Bokare further teaches:
wherein the login request notification, from the server to the second device advising the second user of the second device that another user is attempting to log into the first user account, is transmitted (Bokare, Parag. [0005]; “In some examples, establishing the login session for the user account occurs in response to receiving a request to access the resources associated with the user account. In some examples, the computer-implemented method may further include applying an authentication policy before providing access to the resources associated with the user account, where the authentication policy may include (1) displaying, on the associated device, a notification that the request to access the resources associated with the user account has been received, (2) displaying, on the associated device, information identifying the client requesting access to the resources associated with the user account, (3) obtaining, via the associated device, permission to access the resources associated with the user account, and/or (4) authenticating the user account using authentication factors obtained via the associated device” … Parag. [0045]; “An authentication policy may, for example, specify that the associated device should display a notification that a request to access the resources associated with the user account has been received. In another example, an authentication policy may specify that the associated device should display information identifying the client requesting access to the resources associated with the user account, such as the client's location or IP address. An authentication policy may also direct the associated device to obtain permission to access the resources associated with the user account or obtain additional authentication factors that may be used to authenticate the client to the user account”)
The combination of Bokare, Narasimhan and Vincent does not expressly teach:
upon submission, by the first user of the first device, of one or both an incorrect username and an incorrect password
However, Richards further teaches:
upon submission, by the second user of the second device, of one or both an incorrect username and an incorrect password (Richards, Parag. [0015]; “The requestor (i.e., second user) sending the request may or may not be the registered user indicated in the request” … Parag. [0053]; “The requestor, instead, may have already registered as a user of the system but needs to be authenticated because: the system may require authenticators to confirm the identity of the requestor, the requestor forgot their login information (e.g. username, password), the requestor's login information expired, the particular transaction imposes heightened authentication, or for any other reason”).
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Bokare, Narasimhan, Vincent and Richards before them, to modify Bokare in view of Narasimhan and Vincent that teaches the computer-implemented method. One would have been motivated to have an improved overall system in which system detects when a user enter incorrect credentials as taught by Richards (see Richards [0015]).
Regarding claim 9, the combination of Bokare, Narasimhan and Vincent teaches the method of claim 8.
The combination of Bokare, Narasimhan and Vincent does not expressly teach:
wherein the determination includes assessing a quantity of times that the first user device has been used to successfully log into the first user account to access the at least one online service.
However, Richards further teaches:
wherein the determination includes assessing a quantity of times that the first user device has been used to successfully log into the first user account to access the at least one online service (Richards, Parag. [0090]; “Information related to authentication test/factors used in the calculation of a trust score, including historical information regarding past authentication processes in which the authenticator was used to verify the requestor/user can be used to improve the quality of the trust scoring process applied to the authenticator. For example, an analytics tool (such as a web analytics tool or BI tool) may produce various metrics such as measures of each authenticator's responsiveness and authentication success based on a combination of other criteria (e.g. environment variables associated with the authenticator”).
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Bokare, Narasimhan, Vincent and Richards before them, to modify Bokare in view of Narasimhan and Vincent that teaches the computer-implemented method. One would have been motivated to have an improved overall system in which the system detects and counts when a user enters correct credentials to log in as taught by Richards (see Richards [0090]).
Regarding claim 18, the rejection of claim 14 is incorporated. In addition, claim 18 recites limitations that correspond to claim 7, and therefore, is rejected for same rationale and motivation as applied against claim 7.
Regarding claim 19, the combination of Bokare, Narasimhan and Vincent teaches the method of claim 14. Bokare further teaches the method comprising:
making a determination that the first device is trusted prior to enabling authorization of the login request by the first device (Bokare, Parag. [0034]; “The term “associated device,” as used herein, generally refers to a device associated with a user account that is expected to be accessible to the user and/or someone authorized to control access to the user account. Examples of associated devices include, without limitation, a mobile phone or tablet computer that is expected to remain in the user's possession. The user may be asked to identify an associated device when the user account is created or when providing authentication credentials to be associated with the account”);
[wherein the determination includes assessing a quantity of times that the first user device has been used to successfully log into the first user account to access the at least one online service].
The combination of Bokare, Narasimhan and Vincent does not expressly teach:
wherein the determination includes assessing a quantity of times that the first user device has been used to successfully log into the first user account to access the at least one online service.
However, Richards teaches:
wherein the determination includes assessing a quantity of times that the first user device has been used to successfully log into the first user account to access the at least one online service (Richards, Parag. [0090]; “Information related to authentication test/factors used in the calculation of a trust score, including historical information regarding past authentication processes in which the authenticator was used to verify the requestor/user can be used to improve the quality of the trust scoring process applied to the authenticator. For example, an analytics tool (such as a web analytics tool or BI tool) may produce various metrics such as measures of each authenticator's responsiveness and authentication success based on a combination of other criteria (e.g. environment variables associated with the authenticator”).
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Bokare, Narasimhan, Vincent and Richards before them, to modify Bokare in view of Narasimhan and Vincent that teaches the computer-implemented method. One would have been motivated to have an improved overall system in which the system detects and counts when a user enter correct credentials to log in as taught by Richards (see Richards [0090]).
Claims 10 and 11 are rejected under 35 U.S.C. 103 as being unpatentable over Bokare et al. (US 20170195429 A1) hereinafter Bokare, in view of Narasimhan et al. (US 2017/0372310 A1) hereinafter Narasimhan, and Vincent et al. (US 9,706,401) hereinafter Vincent as applied to claim 1, and further in view of Zavesky et al. (US 2019/0158492 A1) hereinafter Zavesky.
Regarding claim 10, the combination of Bokare, Narasimhan and Vincent teaches the method of claim 1.
the combination of Bokare, Narasimhan and Vincent does not expressly teach:
wherein access to the first user account and the at least one online service, by the second device, is conditioned upon continued login of the first device with the first user account
However, Zavesky teaches:
wherein access to the first user account and the at least one online service, by the second device, is conditioned upon continued login of the first device with the first user account (Zavesky, Parag. [0018]; “However, in another example, the collective authorization may be maintained based upon the continued presence of the two or more authorized users” … Parag. [0034]; “At step 210, the processing system detects an interaction of a first user and a second user. In one example, the detecting the interaction of the first user and the second user comprises detecting a presence of the first user and the second user at a location, e.g., a geographic location. In one example, the presence of the first user and the second user at the location is detected via at least one of: a biometric detection of at least one of the first user or the second user at the location or a detection of a mobile endpoint device of at least one of the first user or the second user at the location, e.g., via RFID, Wi-Fi, Wi-Fi Direct, Bluetooth, and/or BLE communications, depending upon the device types and capabilities of the mobile endpoint device(s)”… Parag. [0040]; “At step 270, the processing system detects an end to the interaction of the first user and the second user. In one example, the processing system detects the end to the interaction of the first user and the second user by detecting a presence of the first user at a different location. In another example, the processing system detects the end to the interaction of the first user and the second user by detecting a termination of a collaboration session. In still another example, the end of the interaction may be detected when the second user logs out of a device, desktop, program, or other systems that are used to access the data set”)
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Bokare, Narasimhan, Vincent and Zavesky before them, to modify Bokare in view of Narasimhan and Vincent that teaches the computer-implemented method; to include access to the first user account and the at least one online service, by the second device, is conditioned upon continued login of the first device with the first user account. One would have been motivated to enhance security regarding protected data as taught by Zavesky (see Zavesky [0020]).
Regarding claim 11, the combination of Bokare, Narasimhan, Vincent and Zavesky teaches the method of claim 10.
Bokare further teaches:
with a GUI option (Bokare, Parag. [0005]; “In some examples, establishing the login session for the user account occurs in response to receiving a request to access the resources associated with the user account. In some examples, the computer-implemented method may further include applying an authentication policy before providing access to the resources associated with the user account, where the authentication policy may include (1) displaying, on the associated device, a notification that the request to access the resources associated with the user account has been received, (2) displaying, on the associated device, information identifying the client requesting access to the resources associated with the user account, (3) obtaining, via the associated device, permission to access the resources associated with the user account, and/or (4) authenticating the user account using authentication factors obtained via the associated device” … Parag. [0045]; “An authentication policy may, for example, specify that the associated device should display a notification that a request to access the resources associated with the user account has been received. In another example, an authentication policy may specify that the associated device should display information identifying the client requesting access to the resources associated with the user account, such as the client's location or IP address. An authentication policy may also direct the associated device to obtain permission to access the resources associated with the user account or obtain additional authentication factors that may be used to authenticate the client to the user account” … Parag. [0058]; “For example, in certain embodiments I/O controller 520 may control or facilitate transfer of data between one or more elements of computing system 510, such as processor 514, system memory 516, communication interface 522, display adapter 526, input interface 530, and storage interface 534.” … Parag. [0061]; “As illustrated in FIG. 5, computing system 510 may also include at least one display device 524 coupled to communication infrastructure 512 via a display adapter 526. Display device 524 generally represents any type or form of device capable of visually displaying information forwarded by display adapter 526. Similarly, display adapter 526 generally represents any type or form of device configured to forward graphics, text, and other data from communication infrastructure 512 (or from a frame buffer, as known in the art) for display on display device 524.),
In addition, Zavesky teaches:
upon ending a login session of the first device with the first user account, providing the first device with a [GUI] option to continue allowing the second device to the first user account or to terminate access (Zavesky, Parag. [0018]; “However, in another example, the collective authorization may be maintained based upon the continued presence of the two or more authorized users” … Parag. [0040]; “At step 270, the processing system detects an end to the interaction of the first user and the second user. In one example, the processing system detects the end to the interaction of the first user and the second user by detecting a presence of the first user at a different location. In another example, the processing system detects the end to the interaction of the first user and the second user by detecting a termination of a collaboration session. In still another example, the end of the interaction may be detected when the second user logs out of a device, desktop, program, or other systems that are used to access the data set” … Parag. [0013]; “In one example, a temporary authorization can be recorded and maintained with an expiration time. In addition, in one example, a temporary authorization can be periodically re-verified with a polling technique. For example, an expiration can be bound to a single task, a predetermined period of time, or an access of a certain type or quantity of data. In one example, continued access can be revoked by detecting that the two users are no longer proximate, e.g., separated by a predefined distance (e.g., separated by a distance greater than 30 feet, 40 feet, 50 feet, and so on). In still another example, temporary access may be revoked by an explicit instruction from the authorized user, e.g., prior to a default expiration time of the temporary authorization that was set when initially granted”).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Mahurkar et al. (US 10,834,594) relates to a first device may discover, using a short-range wireless communication protocol, an authentication service advertised by a second device, and may establish, with the second device, a connection using the short-range wireless communication protocol. The first device may display, after establishing the connection with the second device, a first identifier, and may provide to the second device a confirmation request including the first identifier to permit the second device to determine whether a second identifier, input by a user into the second device, matches the first identifier. The first device may receive, from the second device, encrypted credentials to authenticate the user to access a service based on the second device determining whether the second identifier matches the first identifier. The first device may decrypt the encrypted credentials to obtain credentials, and may authenticate, using the credentials, the user to access the service.
Alexander (US 9,336,378) relates to a credential can be shared by one user with other users when sharing conditions are met. Sharing conditions can include a time, time range, date, date range and the geographic location of a user with whom the credential is to be shared. The credential can be shared so that it is not visible or accessible in plaintext to the shared-with user. Sharing conditions can include conditions that, when met, result in the revocation of a shared credential.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ALEX D CARRASQUILLO whose telephone number is (571)270-5045. The examiner can normally be reached Monday - Friday 9:00 am - 6:00 pm.
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, Yin-Chen Shaw can be reached at 571-272-8878. 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.
/A.D.C./Examiner, Art Unit 2498
/YIN CHEN SHAW/Supervisory Patent Examiner, Art Unit 2498
Prosecution Insights