Prosecution Insights
Last updated: April 19, 2026
Application No. 15/032,898

METHOD FOR SETTING UP, VIA AN INTERMEDIATE ENTITY, A SECURE SESSION BETWEEN A FIRST AND A SECOND ENTITY, AND CORRESPONDING ENTITIES AND COMPUTER PROGRAM PRODUCTS

Final Rejection §103
Filed
Apr 28, 2016
Examiner
ALMEIDA, DEVIN E
Art Unit
2492
Tech Center
2400 — Computer Networks
Assignee
UBIQU B.V.
OA Round
12 (Final)
71%
Grant Probability
Favorable
13-14
OA Rounds
3y 9m
To Grant
82%
With Interview

Examiner Intelligence

Grants 71% — above average
71%
Career Allow Rate
421 granted / 592 resolved
+13.1% vs TC avg
Moderate +11% lift
Without
With
+11.4%
Interview Lift
resolved cases with interview
Typical timeline
3y 9m
Avg Prosecution
35 currently pending
Career history
627
Total Applications
across all art units

Statute-Specific Performance

§101
7.7%
-32.3% vs TC avg
§103
53.4%
+13.4% vs TC avg
§102
24.6%
-15.4% vs TC avg
§112
8.1%
-31.9% vs TC avg
Black line = Tech Center average estimate • Based on career data from 592 resolved cases

Office Action

§103
DETAILED ACTION This action is in response to amendments filed 12/5/2025. Claims 1-10, 12-23 and 26-30 are pending with claim 1 having been amended. Priority Acknowledgment is made of applicant's claim for foreign priority under 35 U.S.C. 119(a)-(d). The certified copy has been received. Response to Arguments Applicant's arguments filed 4/29/2025 have been fully considered. A) Applicant's arguments with respect to the 103 rejection of Kalinichenko et al in view of Zhu et al in view of Mizrah does not teaching “that the authorization dialog is preformed after forwarding the persistent instruction to the platform application” have been fully considered but they are not persuasive (see response page 12). Regarding A) Kalinichenko teaches “that the authorization dialog is preformed after forwarding the persistent instruction to the platform application” in figure 3 steps 142 and 152-154 and column 7 lines 36-50 i.e. In operation, business processing server 104 receives (142), from a client device, a request to perform an action, e.g., request 130 (FIG. 2). The received request includes information identifying a user associated with the client device (e.g., login credentials of the user, a user name of the user, and so forth) and column 7 line 51 – column 8 line 3 i.e. The authentication token includes the device identifier of the mobile device, e.g., to promote using a presence of the mobile device specified by the device identifier as secondary factor authentication information. Business processing server 104 also generates (148), in a data repository, an association among the authentication token and the user profile. Business processing server 104 receives (150), from an authentication server, a decrypted version of an authentication token and a device identifier of a mobile device that is in proximity to the client device. Business processing server 104 identifies (152) a match between the authentication token that is generated for the user and the decrypted version of the authentication token. Business processing server 104 also identifies (153) a match between the received device identifier and the device identifier included in the user profile. In response to the identified matches, business processing server 104 performs (154) the requested action)). This clearly teaches forwarding the persistent instruction (i.e. request 130) to the platform application is done first in step 142. Next, performing an authorization dialog is done at step 146-153 between the platform application and the user authentication device and executing the persistent instruction only when the authorization dialog has successfully finished is done after at step 154. B) Applicant's arguments with respect to the 103 rejection of Kalinichenko et al in view of Zhu et al in view of Mizrah does not teaching “that the authorization dialog determines a successful or unsuccessful user’s consent of the persistent instruction” have been fully considered but they are not persuasive (see response page 12). Regarding B) Kalinichenko teaches “that the consent/authorization dialog determines a successful or unsuccessful user’s consent/authorization of the persistent instruction” in figure 3 steps 146-154 and column 7 line 51 – column 8 line 3 i.e. Using the device identifier of the mobile device 116, business processing server 104 generates (146) an authentication token for confirming that the user is authorized to perform the action. The authentication token includes the device identifier of the mobile device, e.g., to promote using a presence of the mobile device specified by the device identifier as secondary factor authentication information. Business processing server 104 also generates (148), in a data repository, an association among the authentication token and the user profile. Business processing server 104 receives (150), from an authentication server, a decrypted version of an authentication token and a device identifier of a mobile device that is in proximity to the client device. Business processing server 104 identifies (152) a match between the authentication token that is generated for the user and the decrypted version of the authentication token. Business processing server 104 also identifies (153) a match between the received device identifier and the device identifier included in the user profile. In response to the identified matches, business processing server 104 performs (154) the requested action)). Therefore Kalinichenko clearly teaches successful or unsuccessful user’s authorization of the persistent instruction by matching the authentication token that is generated for the user and the decrypted version of the authentication token and matching the received device identifier and the device identifier included in the user profile. 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. Claims 1-10, 14-23 and 26-30 are rejected under 35 U.S.C. 103 as being unpatentable over Kalinichenko et al (US 9,124,582) in view of Zhu et al (US 8,209,744) in view of Mizrah (US 2008/0098464). With respect to claim 1, Kalinichenko teaches a method for performing an instruction on a platform application, comprising the steps of: preparing a persistent instruction on a user workplace application that is remotely connected to the platform application (See Kalinichenko figure 2 step 130 and column 5 lines 53-61 i.e. Client device 102 is a primary factor authentication device. Client device 102 generates request 130 to perform an action, e.g., to access a resource hosted by business processing server 104. For example, request 130 includes a request to access financial account information of a user of client device 102. Request 130 includes primary factor authentication information, e.g., a user name and a password for accessing the financial account information); forwarding the persistent instruction to the platform application (See Kalinichenko figure 3 step 142 and column 7 lines 36-41 i.e. In operation, business processing server 104 receives (142), from a client device, a request to perform an action, e.g., request 130 (FIG. 2). The received request includes information identifying a user associated with the client device (e.g., login credentials of the user, a user name of the user, and so forth)); setting up connection between the platform application and a user authentication device (See Kalinichenko column 6 lines 15-65 i.e. Mobile device 116 transmits information 134 to authentication server 114, e.g., via network 124 and through firewall 106. System 100 also includes network 136, which is a private network of authentication server 114 that bypasses firewall. Examples of network 136 include a LAN and a WAN. Based on mobile device 116 being authenticated by authentication server 114, authentication server 114 enables mobile device 116 to access network 136 in transmitting information to authentication server 114. Mobile device 116 can also send information to authentication server 114 via network 136…. Authentication server 114 transmits to business processing server 104 decrypted version 136 of authentication token 132 to business processing server 104, along with device ID 128 of mobile device 116); after forwarding the persistent instruction to the platform application performing an authorization dialog, wherein the authorization dialog determines a successful or unsuccessful user’s authorization of the persistent instruction (See Kalinichenko figure 3 step 152 and column 7 line 51 – column 8 line 3 i.e. The authentication token includes the device identifier of the mobile device, e.g., to promote using a presence of the mobile device specified by the device identifier as secondary factor authentication information. Business processing server 104 also generates (148), in a data repository, an association among the authentication token and the user profile. Business processing server 104 receives (150), from an authentication server, a decrypted version of an authentication token and a device identifier of a mobile device that is in proximity to the client device. Business processing server 104 identifies (152) a match between the authentication token that is generated for the user and the decrypted version of the authentication token. Business processing server 104 also identifies (153) a match between the received device identifier and the device identifier included in the user profile); and executing the persistent instruction only when the authorization dialog has successfully finished (See Kalinichenko figure 3 step 154 and column 7 line 51 – column 8 line 3 i.e. The authentication token includes the device identifier of the mobile device, e.g., to promote using a presence of the mobile device specified by the device identifier as secondary factor authentication information. Business processing server 104 also generates (148), in a data repository, an association among the authentication token and the user profile. Business processing server 104 receives (150), from an authentication server, a decrypted version of an authentication token and a device identifier of a mobile device that is in proximity to the client device. Business processing server 104 identifies (152) a match between the authentication token that is generated for the user and the decrypted version of the authentication token. Business processing server 104 also identifies (153) a match between the received device identifier and the device identifier included in the user profile. In response to the identified matches, business processing server 104 performs (154) the requested action), While Kalinichenko teaches performing a consent dialog between the platform application and the user authentication device, the consent dialog code is transmitted to the user workplace application where it is returned to the platform application by the user authentication device to be verified through a connection between the platform application and a user authentication device. Kalinichenko does not teach setting up a secure connection between the platform application and a user authentication device. Zhu teaches setting up a secure connection between the platform application and a user authentication device (see Zhu column 1 lines 12-23 i.e. Web services often require proper user authentication to identify a user and establish secure channels with a client computer, such as a user's personal computer (PC). A Web site associated with this type of Web service is sometimes referred to as a secure site. Although many secure authentication schemes have been proposed, a password is still dominantly used in Web applications due to its convenience, and ease in use and deployment. In password-based user authentication, a user is required to input an account identification (often referred to as a user ID) and a password. A Secure Sockets Layer (SSL) connection may be used to secure communications during user authentication and column 6 lines 27-29). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Kalinichenko in view of Zhu to have shared random numbers used be both the first device and the second device to use to calculate a session key that can be used to create a secure channel between the first and second device (see Zhu column 8 lines 37-47). Therefore one would have been motivated to have shared random numbers that are used be both the first device and the second device to use to calculate a session key. Kalinichenko in view of Zhu does not teach performing an authorization dialog between the platform application and the user authentication device. Mizrah teaches performing an authorization dialog between the platform application and the user authentication device (see Mizrah paragraph 0134-0135 i.e. At the same time, one time authentication challenge OTAC 5020 is delivered as a SMS text message to user's 4090 personal mobile phone 5010 (i.e. claimed user authentication device). Now, user 4090 follows the simple instructions of RPPPR protocol in FIG. 2 and generates a one time authentication response OTAR by clicking on cells with appropriate alphanumeric character or special mark content along the highlighted graphical password in menu 4070 (i.e. gui of claimed user workplace application), and eventually enters OTAR into field 4040. Then, user 4090 closes menu 4070 by clicking on the upper left cell with a triangle mark, or anywhere outside of the menu, and indicating LOGIN button 3020, one time authentication response OTAC is sent to server 1030 (FIG. 1) which compares received and expected OTAR and signals back to user 4090 a positive or negative authentication result). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Kalinichenko in view of Mizrah to have use Mizrah’s the two-factor authentication in which the code is transmitted to the mobile phone (i.e. claimed user authentication device) to be enter code at the user terminal (i.e. claimed user workplace application) were it is transmitted to the server to be verified as a more secure login because an intruder without the password (or PIN) cannot initiate the authentication session and invoke the second authentication factor. At the same time, an intruder without user's personal mobile phone where the one time authentication challenge OTAC is arriving cannot fulfill the second authentication factor even having obtained access to the GUI in a browser or on a screen where the session authentication credential SAC is highlighted, rendering the authentication session failed (see Mizrah paragraph 0140). Therefore one would have been motivated to have used Mizrah’s the two-factor authentication. With respect to claim 2, Kalinichenko, Zhu et al and Mizrah teach the method according to claim 1. Zhu further teaches wherein the secure connection between the platform application and the user authentication device is set up by providing a secure session between a first entity and a second entity, the first entity and the second entity being the user authentication device and an application running on a platform, respectively, or vice versa, the method being performed by the first entity and comprising the steps of: generating a first random number (see Zhu figure 3B step 306 and column 5 lines 61-64 i.e. The server then generates a server challenge number (306). This challenge number can take several forms, two of which will be described shortly); exporting a first string derived from said first random number, to a user for entering the first string into the second entity (see Zhu figure 3A step 318 and column 6 line 7-10 i.e. The mobile device receives the identifications and number (318), and then generates the aforementioned secret value ( 320) and Kalinichenko column 4 lines 16-25); applying a one-way function to the first string or to a derivative thereof, obtaining an encoded string; transmitting the encoded string to an intermediate node that is in connection to the first entity and the second entity (see Zhu column 5 lines 5-15 i.e. In one embodiment, the combination is accomplished by concatenating the numbers and then computing a cryptographic hash of the concatenation using a prescribed cryptographic hash function (e.g., SHA-256 specified in Federal Information Processing Standards Publications (FIPS PUBS) 180-2 Secure Hash Standard), which is known to the mobile phone and the server associated with the Web site of interest. The resulting combined value is designated as the secret value (208) and is transmitted to the server associated with the Web site via a secure channel (210)); the method further comprising the steps of: generating a second random number, deriving a second string from said second random number and transmitting the second string to the second entity if a verifying step of comparing encoded strings transmitted by the first entity and the second entity has a positive result, or receiving from the second entity the second string being derived from the second random number generated by the second entity (see Zhu figure 3B step 322-326 and column 6 lines 7-13 i.e. The mobile device receives the identifications and number (318), and then generates the aforementioned secret value ( 320), a mobile device challenge number (322) and a representation of the secret value (324). Next, the mobile device forwards the mobile device challenge number and secret value representation to the client computer (326)), the method further comprising the step of: deriving a secret key from the first string and the second string (see Zhu figure 3B step 336 and column 6 lines 27-29 i.e. The serve receives these numbers (334) and computes a session key from them (336)). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Kalinichenko in view of Zhu to have shared random numbers used be both the first device and the second device to use to calculate a session key that can be used to create a secure channel between the first and second device (see Zhu column 8 lines 37-47). Therefore one would have been motivated to have shared random numbers that are used be both the first device and the second device to use to calculate a session key. With respect to claim 3, Kalinichenko, Zhu et al and Mizrah teach the method according to claim 1. Zhu further teaches teaches wherein the secure connection between the platform application and the user authentication device is set up by providing a secure session between a first entity and a second entity, the first and second entity being the user authentication device and an application running on a platform, respectively, or vice versa, the method being performed by the second entity and comprising the steps of: receiving, via an I/O interface, a first string derived from a first random number generated by the first entity (see Zhu figure 3B step 306 and column 5 lines 61-64 i.e. The server then generates a server challenge number (306). This challenge number can take several forms, two of which will be described shortly); applying a one-way function to the first string or to a derivative thereof, obtaining an encoded string; transmitting the encoded string to an intermediate node that is in connection to the first and the second entity (see Zhu column 5 lines 5-15 i.e. In one embodiment, the combination is accomplished by concatenating the numbers and then computing a cryptographic hash of the concatenation using a prescribed cryptographic hash function (e.g., SHA-256 specified in Federal Information Processing Standards Publications (FIPS PUBS) 180-2 Secure Hash Standard), which is known to the mobile phone and the server associated with the Web site of interest. The resulting combined value is designated as the secret value (208) and is transmitted to the server associated with the Web site via a secure channel (210)); the method further comprising the steps of: generating a second random number, deriving a second string from said second random number and transmitting the second string to the first entity if a verifying step of comparing encoded strings transmitted by the first entity and the second entity has a positive result, or receiving from the first entity the second string being derived from the second random number generated by the first entity (see Zhu figure 3B step 322-326 and column 6 lines 7-13 i.e. The mobile device receives the identifications and number (318), and then generates the aforementioned secret value ( 320), a mobile device challenge number (322) and a representation of the secret value (324). Next, the mobile device forwards the mobile device challenge number and secret value representation to the client computer (326)), the method further comprising the step of: deriving a secret key from the first string and the second string (see Zhu figure 3B step 336 and column 6 lines 27-29 i.e. The serve receives these numbers (334) and computes a session key from them (336)). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Kalinichenko in view of Zhu to have shared random numbers used be both the first device and the second device to use to calculate a session key that can be used to create a secure channel between the first and second device (see Zhu column 8 lines 37-47). Therefore one would have been motivated to have shared random numbers that are used be both the first device and the second device to use to calculate a session key. With respect to claim 4, Kalinichenko, Zhu et al and Mizrah teach the method according to claim 1. Zhu further teaches wherein the secure connection between the platform application and the user authentication device is set up by providing a secure session between a first entity and a second entity, the first and second entity being the user authentication device and an application running on a platform, respectively, or vice versa, the method being performed by an intermediate node that is in connection to the first entity and the second entity, the method comprising the steps of: receiving an encoded string from the first entity and the second entity, the encoded string being obtained by applying a one-way function to a first string or to a derivative thereof, the first string being derived from a first random number generated by the first entity; verifying whether the encoded strings received from the first entity and second entity are the same; if the verifying step has a positive result, authorizing the first entity and second entity to share a second string being derived from a second random number generated by the first entity or the second entity, respectively (see Zhu column 6 lines 23-47 i.e. The client computer receives the mobile device challenge number and secret value representation (328), and combines the secret value representation and the password to produce a combined representation (330). The client computer then transmits the user identification, mobile device challenge number and combined representation to the server (332). The serve receives these numbers (334) and computes a session key from them (336) as will be described in more detail later. The server then computes a server version of the secret value representation as a combination including the session key, the user identification and the server identification (338). The server then computes a server version of the combined representation using the user identification, the server identification, the server version of the secret value representation, and the password known to the server (340). The server then compares the server version of the combined representation to the combined representation received from the client computer (342) and determines if the password and secret value known to the server were used to generate the combined representation received from the client computer (344). If so, the server generates a notice granting access (346). If not, the server generates a notice denying access (348). The server transmits the generated notice to the client computer (350). The client computer receives the notice from the server (352) and informs the user as to whether access to the network site has been granted or not (354)). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Kalinichenko in view of Zhu to have the server then computes a server version of the combined representation using the user identification, the server identification, the server version of the secret value representation, and the password known to the server (340). The server then compares the server version of the combined representation to the combined representation received from the client computer (342) and determines if the password and secret value known to the server were used to generate the combined representation received from the client computer (see Zhu column 6 lines 23-47). Therefore one would have been motivated to have compares the server version of the combined representation to the combined representation received from the client computer (342) and determines if the password and secret value known to the server were used to generate the combined representation received from the client computer. With respect to claim 5, Kalinichenko, Zhu et al and Mizrah teach the method according to claim 1, wherein the platform application is a user workplace application, a cloud application, an authentication provider application, or a transaction system application (see Kalinichenko column 3 lines 33-44 i.e. Business processing server 104). With respect to claim 6, Kalinichenko, Zhu et al and Mizrah teach the method according to claim 2. Zhu further teaches wherein the first string is first random number or a random message produced from said first random number (see Zhu column 5 lines 1-15 i.e. The procedure continues with action 206 by combining the hidden number R.sub.m, the mobile device's hardware identification number, optionally the SIM card identification number, and finally a unique number identifying the secure Web site of interest (e.g., the Web site's URL). In one embodiment, the combination is accomplished by concatenating the numbers and then computing a cryptographic hash of the concatenation using a prescribed cryptographic hash function (e.g., SHA-256 specified in Federal Information Processing Standards Publications (FIPS PUBS) 180-2 Secure Hash Standard), which is known to the mobile phone and the server associated with the Web site of interest. The resulting combined value is designated as the secret value (208) and is transmitted to the server associated with the Web site via a secure channel (210)). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Kalinichenko in view of Zhu to have the server then computes a server version of the combined representation using the user identification, the server identification, the server version of the secret value representation, and the password known to the server (340). The server then compares the server version of the combined representation to the combined representation received from the client computer (342) and determines if the password and secret value known to the server were used to generate the combined representation received from the client computer (see Zhu column 6 lines 23-47). Therefore one would have been motivated to have shared random numbers that are used be both the first device and the second device to use to calculate a session key. With respect to claim 7, Kalinichenko, Zhu et al and Mizrah teach the method according to claim 2. Zhu further teaches wherein, in the step of applying a one-way function, the derivative of the first string is obtained by performing a hash function to the first string (see Zhu column 5 lines 5-15 i.e. In one embodiment, the combination is accomplished by concatenating the numbers and then computing a cryptographic hash of the concatenation using a prescribed cryptographic hash function (e.g., SHA-256 specified in Federal Information Processing Standards Publications (FIPS PUBS) 180-2 Secure Hash Standard), which is known to the mobile phone and the server associated with the Web site of interest. The resulting combined value is designated as the secret value (208) and is transmitted to the server associated with the Web site via a secure channel (210)). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Kalinichenko in view of Zhu to have the server then computes a server version of the combined representation using the user identification, the server identification, the server version of the secret value representation, and the password known to the server (340). The server then compares the server version of the combined representation to the combined representation received from the client computer (342) and determines if the password and secret value known to the server were used to generate the combined representation received from the client computer (see Zhu column 6 lines 23-47). Therefore one would have been motivated to have compares the server version of the combined representation to the combined representation received from the client computer (342) and determines if the password and secret value known to the server were used to generate the combined representation received from the client computer. With respect to claim 8, Kalinichenko, Zhu et al and Mizrah teach the method according to claim 2, wherein the second string is transmitted in an encrypted manner (see Kalinichenko column 6 lines 15-24 i.e. Mobile device 116 transmits information 134 to authentication server 114, e.g., via network 124 and through firewall 106. System 100 also includes network 136, which is a private network of authentication server 114 that bypasses firewall…Authentication server 114 receives information 134. Authentication server 114 detects device ID 128 in information 134. Using device ID 128, authentication server 114 identifies, in data repository 112, association 129 among device ID 128 and key 127. Based on association 129, authentication server 114 determines that key 127 is used in decrypting information associated with device ID 128). With respect to claim 9, Kalinichenko, Zhu et al and Mizrah teach the method according to claim 2, wherein the intermediate node is an authentication provider securely connected to the user authentication device (see Kalinichenko column 6 lines 15-24 i.e. Mobile device 116 transmits information 134 to authentication server 114, e.g., via network 124 and through firewall 106. System 100 also includes network 136, which is a private network of authentication server 114 that bypasses firewall…Authentication server 114 receives information 134. Authentication server 114 detects device ID 128 in information 134. Using device ID 128, authentication server 114 identifies, in data repository 112, association 129 among device ID 128 and key 127. Based on association 129, authentication server 114 determines that key 127 is used in decrypting information associated with device ID 128). With respect to claim 10, Kalinichenko, Zhu et al and Mizrah teach the method according to claim 1, wherein the secure session is used to support secure one-way or two-way data transfer, such as transfer of a message, a decryption and/or encryption key, or an authorization dialog (see Kalinichenko column 6 lines 15-24 i.e. Mobile device 116 transmits information 134 to authentication server 114, e.g., via network 124 and through firewall 106. System 100 also includes network 136, which is a private network of authentication server 114 that bypasses firewall. Examples of network 136 include a LAN and a WAN). With respect to claim 14, Kalinichenko, Zhu et al and Mizrah teach the method according to claim 1, wherein the user authentication device includes a cellular phone, PDA, smart card, token or electronic key (see Kalinichenko figure 2 element 116 and column 7 line 51- column 8 line 3 i.e. mobile device 116). With respect to claim 15 Kalinichenko a computer system that is remotely connected to a user workplace application and that has a secure connection with a user authentication device, the computer system comprising a processor and a memory storing computer-readable instructions that when executed by the processor cause the processor to: receive a persistent instruction prepared on the user workplace application (see Kalinichenko figure 3 step 142 and column 7 lines 36-41 i.e. In operation, business processing server 104 receives (142), from a client device, a request to perform an action, e.g., request 130 (FIG. 2). The received request includes information identifying a user associated with the client device (e.g., login credentials of the user, a user name of the user, and so forth)); perform an authorization dialog with the user authentication device, via the secure connection (See Kalinichenko figure 3 step 154 and column 7 line 51 – column 8 line 3 i.e. The authentication token includes the device identifier of the mobile device, e.g., to promote using a presence of the mobile device specified by the device identifier as secondary factor authentication information. Business processing server 104 also generates (148), in a data repository, an association among the authentication token and the user profile. Business processing server 104 receives (150), from an authentication server, a decrypted version of an authentication token and a device identifier of a mobile device that is in proximity to the client device. Business processing server 104 identifies (152) a match between the authentication token that is generated for the user and the decrypted version of the authentication token. Business processing server 104 also identifies (153) a match between the received device identifier and the device identifier included in the user profile); and executing the persistent instruction only when the authorization dialog has successfully finished (see Kalinichenko figure 3 step 154 and column 7 line 51 – column 8 line 3 i.e. The authentication token includes the device identifier of the mobile device, e.g., to promote using a presence of the mobile device specified by the device identifier as secondary factor authentication information. Business processing server 104 also generates (148), in a data repository, an association among the authentication token and the user profile. Business processing server 104 receives (150), from an authentication server, a decrypted version of an authentication token and a device identifier of a mobile device that is in proximity to the client device. Business processing server 104 identifies (152) a match between the authentication token that is generated for the user and the decrypted version of the authentication token. Business processing server 104 also identifies (153) a match between the received device identifier and the device identifier included in the user profile. In response to the identified matches, business processing server 104 performs (154) the requested action). While Kalinichenko teaches performing an authorization dialog between the platform application and the authentication device, the authorization dialog code is transmitted to the user workplace application where it is returned to the platform application by the user authentication device to be verified. Kalinichenko does not teaches setting up a secure connection between the platform application and a user authentication device. Zhu teaches setting up a secure connection between the platform application and a user authentication device (see Zhu and column 1 lines 12-23 i.e. Web services often require proper user authentication to identify a user and establish secure channels with a client computer, such as a user's personal computer (PC). A Web site associated with this type of Web service is sometimes referred to as a secure site. Although many secure authentication schemes have been proposed, a password is still dominantly used in Web applications due to its convenience, and ease in use and deployment. In password-based user authentication, a user is required to input an account identification (often referred to as a user ID) and a password. A Secure Sockets Layer (SSL) connection may be used to secure communications during user authentication and column 6 lines 27-29). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Kalinichenko in view of Zhu to have shared random numbers used be both the first device and the second device to use to calculate a session key that can be used to create a secure channel between the first and second device (see Zhu column 8 lines 37-47). Therefore one would have been motivated to have shared random numbers that are used be both the first device and the second device to use to calculate a session key. Kalinichenko in view of Zhu does not teach performing an authorization dialog between the platform application and the user authentication device. Mizrah teaches performing an authorization dialog between the platform application and the user authentication device (see Mizrah paragraph 0134-0135 i.e. At the same time, one time authentication challenge OTAC 5020 is delivered as a SMS text message to user's 4090 personal mobile phone 5010 (i.e. claimed user authentication device). Now, user 4090 follows the simple instructions of RPPPR protocol in FIG. 2 and generates a one time authentication response OTAR by clicking on cells with appropriate alphanumeric character or special mark content along the highlighted graphical password in menu 4070 (i.e. gui of claimed user workplace application), and eventually enters OTAR into field 4040. Then, user 4090 closes menu 4070 by clicking on the upper left cell with a triangle mark, or anywhere outside of the menu, and indicating LOGIN button 3020, one time authentication response OTAC is sent to server 1030 (FIG. 1) which compares received and expected OTAR and signals back to user 4090 a positive or negative authentication result). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Kalinichenko in view of Mizrah to have use Mizrah’s the two-factor authentication in which the code is transmitted to the mobile phone (i.e. claimed user authentication device) to be enter code at the user terminal (i.e. claimed user workplace application) were it is transmitted to the server to be verified as a more secure login because an intruder without the password (or PIN) cannot initiate the authentication session and invoke the second authentication factor. At the same time, an intruder without user's personal mobile phone where the one time authentication challenge OTAC is arriving cannot fulfill the second authentication factor even having obtained access to the GUI in a browser or on a screen where the session authentication credential SAC is highlighted, rendering the authentication session failed (see Mizrah paragraph 0140). Therefore one would have been motivated to have used Mizrah’s the two-factor authentication. With respect to claim 16 Kalinichenko, Zhu et al and Mizrah teach the computer system according to claim 15. Zhu teaches a first entity arranged for setting up a secure session with the user authentication device being a second entity, the first entity comprising: a first random generator for generating a first random number generating a first random number (see Zhu figure 3B step 306 and column 5 lines 61-64 i.e. The server then generates a server challenge number (306). This challenge number can take several forms, two of which will be described shortly); an I/O interface for exporting a first string derived from said first random number, to a user for entering the first string into the second entity (see Zhu figure 3A step 318 and column 6 line 7-10 i.e. The mobile device receives the identifications and number (318), and then generates the aforementioned secret value (320) and Kalinichenko column 4 lines 16-25); a processor and a memory storing computer-readable instructions that when executed by the processor cause the processor to apply a one-way function to the first string or to a derivative thereof and obtain an encoded string; a transmitting unit for transmitting the encoded string to an intermediate node that is in connection to the first entity and the second entity (see Zhu column 5 lines 5-15 i.e. In one embodiment, the combination is accomplished by concatenating the numbers and then computing a cryptographic hash of the concatenation using a prescribed cryptographic hash function (e.g., SHA-256 specified in Federal Information Processing Standards Publications (FIPS PUBS) 180-2 Secure Hash Standard), which is known to the mobile phone and the server associated with the Web site of interest. The resulting combined value is designated as the secret value (208) and is transmitted to the server associated with the Web site via a secure channel (210)); the first entity further comprising: a second random generator for generating a second random number, wherein the processor is further arranged for deriving a second string from said second random number and for transmitting the second string to the second entity if a verifying step of comparing encoded strings transmitted by the first entity and the second entity has a positive result, or a receiver unit for receiving from the second entity the second string being derived from the second random number (see Zhu figure 3B step 322-326 and column 6 lines 7-13 i.e. The mobile device receives the identifications and number (318), and then generates the aforementioned secret value ( 320), a mobile device challenge number (322) and a representation of the secret value (324). Next, the mobile device forwards the mobile device challenge number and secret value representation to the client computer (326)), and wherein the processor is further configured to derive a secret key from the first string and the second string (see Zhu figure 3B step 336 and column 6 lines 27-29 i.e. The serve receives these numbers (334) and computes a session key from them (336)). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Kalinichenko in view of Zhu to have shared random numbers used be both the first device and the second device to use to calculate a session key that can be used to create a secure channel between the first and second device (see Zhu column 8 lines 37-47). Therefore one would have been motivated to have shared random numbers that are used be both the first device and the second device to use to calculate a session key. With respect to claim 17 Kalinichenko, Zhu et al and Mizrah teach a user authentication device being a second entity arranged for setting up the secure session with a platform application according to claim 15. Zhu teaches the second entity comprising: an I/O interface for receiving a first string derived from a first random number generated by a first entity (see Zhu figure 3A step 318 and column 6 line 7-10 i.e. The mobile device receives the identifications and number (318), and then generates the aforementioned secret value (320) and Kalinichenko column 4 lines 16-25); a processor and a memory storing computer-readable instructions that when executed by the processor cause the processor to apply a one-way function to the first string or to a derivative thereof and obtain an encoded string; a transmitting unit for transmitting the encoded string to an intermediate node that is in connection to the first entity and the second entity (see Zhu column 5 lines 5-15 i.e. In one embodiment, the combination is accomplished by concatenating the numbers and then computing a cryptographic hash of the concatenation using a prescribed cryptographic hash function (e.g., SHA-256 specified in Federal Information Processing Standards Publications (FIPS PUBS) 180-2 Secure Hash Standard), which is known to the mobile phone and the server associated with the Web site of interest. The resulting combined value is designated as the secret value (208) and is transmitted to the server associated with the Web site via a secure channel (210)); the second entity further comprising: a second random generator for generating a second random number, wherein the processor is arranged for deriving a second string from said second random number and for transmitting the second string to the first entity if a verifying step of comparing encoded strings transmitted by the first entity and the second entity has a positive result, or a receiver unit for receiving from the first entity the second string being derived from the second random number, and wherein the processor is further configured to derive a secret key from the first string and the second string (see Zhu figure 3B step 322-326 and column 6 lines 7-13 i.e. The mobile device receives the identifications and number (318), and then generates the aforementioned secret value ( 320), a mobile device challenge number (322) and a representation of the secret value (324). Next, the mobile device forwards the mobile device challenge number and secret value representation to the client computer (326)), and wherein the processor is further configured to derive a secret key from the first and the second string (see Zhu figure 3B step 336 and column 6 lines 27-29 i.e. The serve receives these numbers (334) and computes a session key from them (336)). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Kalinichenko in view of Zhu to have shared random numbers used be both the first device and the second device to use to calculate a session key that can be used to create a secure channel between the first and second device (see Zhu column 8 lines 37-47). Therefore one would have been motivated to have shared random numbers that are used be both the first device and the second device to use to calculate a session key. With respect to claim 18 Kalinichenko, Zhu et al and Mizrah teach the computer system according to claim 15. Zhu teaches an intermediate node that is in connection to a computer system, and to a user authentication device for setting up the secure connection, said secure connection being between the first entity and a second entity, the intermediate node comprising: a receiving unit for receiving an encoded string from the first entity and the second entity, the encoded string being obtained by applying a one-way function to a first string or to a derivative thereof, the first string being derived from a first random number generated by the first entity; a processor and a memory storing computer-readable instructions that when executed by the processor cause the processor to verify whether the encoded strings received from the first entity and the second entity are the same, wherein the processor is further arranged for authorizing the first entity and the second entity to share a second string being derived from a second random number generated by the first entity or the second entity, respectively, if the verifying step has a positive result (see Zhu column 6 lines 23-47). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Kalinichenko in view of Zhu to have The server then computes a server version of the combined representation using the user identification, the server identification, the server version of the secret value representation, and the password known to the server (340). The server then compares the server version of the combined representation to the combined representation received from the client computer (342) and determines if the password and secret value known to the server were used to generate the combined representation received from the client computer (see Zhu column 6 lines 23-47). Therefore one would have been motivated to have compares the server version of the combined representation to the combined representation received from the client computer (342) and determines if the password and secret value known to the server were used to generate the combined representation received from the client computer. With respect to claim 19 Kalinichenko, Zhu et al and Mizrah teach network, comprising the computer system according to claim 15, an user authentication device, and an intermediate node (see Kalinichenko figure 2 element 116 element 102 and column 3 lines 19-23 i.e. the system 100 includes a client device 102, a mobile device 116, a business processing server 104, data repositories 110, 112, an authentication server 114, and a firewall 106 coupled via a network). With respect to claim 20 Kalinichenko a non-transitory computer-readable medium having a computer embodied thereon program product for performing an instruction on a platform application, the computer program comprising computer readable code for facilitating a processing unit to perform the steps of: preparing a persistent instruction on a user workplace application that is remotely connected to the platform application (See Kalinichenko figure 2 step 130 and column 5 lines 53-61 i.e. Client device 102 is a primary factor authentication device. Client device 102 generates request 130 to perform an action, e.g., to access a resource hosted by business processing server 104. For example, request 130 includes a request to access financial account information of a user of client device 102. Request 130 includes primary factor authentication information, e.g., a user name and a password for accessing the financial account information); forwarding the persistent instruction to the platform application (See Kalinichenko figure 3 step 142 and column 7 lines 36-41 i.e. In operation, business processing server 104 receives (142), from a client device, a request to perform an action, e.g., request 130 (FIG. 2). The received request includes information identifying a user associated with the client device (e.g., login credentials of the user, a user name of the user, and so forth)); setting up connection between the platform application and a user authentication device (See Kalinichenko column 6 lines 15-65 i.e. Mobile device 116 transmits information 134 to authentication server 114, e.g., via network 124 and through firewall 106. System 100 also includes network 136, which is a private network of authentication server 114 that bypasses firewall. Examples of network 136 include a LAN and a WAN. Based on mobile device 116 being authenticated by authentication server 114, authentication server 114 enables mobile device 116 to access network 136 in transmitting information to authentication server 114. Mobile device 116 can also send information to authentication server 114 via network 136…. Authentication server 114 transmits to business processing server 104 decrypted version 136 of authentication token 132 to business processing server 104, along with device ID 128 of mobile device 116); performing an authorization dialog (See Kalinichenko figure 3 step 154 and column 7 line 51 – column 8 line 3 i.e. The authentication token includes the device identifier of the mobile device, e.g., to promote using a presence of the mobile device specified by the device identifier as secondary factor authentication information. Business processing server 104 also generates (148), in a data repository, an association among the authentication token and the user profile. Business processing server 104 receives (150), from an authentication server, a decrypted version of an authentication token and a device identifier of a mobile device that is in proximity to the client device. Business processing server 104 identifies (152) a match between the authentication token that is generated for the user and the decrypted version of the authentication token. Business processing server 104 also identifies (153) a match between the received device identifier and the device identifier included in the user profile); and executing the persistent instruction only when the authorization dialog has successfully finished (See Kalinichenko figure 3 step 154 and column 7 line 51 – column 8 line 3 i.e. The authentication token includes the device identifier of the mobile device, e.g., to promote using a presence of the mobile device specified by the device identifier as secondary factor authentication information. Business processing server 104 also generates (148), in a data repository, an association among the authentication token and the user profile. Business processing server 104 receives (150), from an authentication server, a decrypted version of an authentication token and a device identifier of a mobile device that is in proximity to the client device. Business processing server 104 identifies (152) a match between the authentication token that is generated for the user and the decrypted version of the authentication token. Business processing server 104 also identifies (153) a match between the received device identifier and the device identifier included in the user profile. In response to the identified matches, business processing server 104 performs (154) the requested action). While Kalinichenko teaches performing an authorization dialog between the platform application and the authentication device, the authorization dialog code is transmitted to the user workplace application where it is returned to the platform application by the user authentication device to be verified through a connection between the platform application and a user authentication device. Kalinichenko does not teaches setting up a secure connection between the platform application and a user authentication device. Zhu teaches setting up a secure connection between the platform application and a user authentication device (see Zhu and column 1 lines 12-23 i.e. Web services often require proper user authentication to identify a user and establish secure channels with a client computer, such as a user's personal computer (PC). A Web site associated with this type of Web service is sometimes referred to as a secure site. Although many secure authentication schemes have been proposed, a password is still dominantly used in Web applications due to its convenience, and ease in use and deployment. In password-based user authentication, a user is required to input an account identification (often referred to as a user ID) and a password. A Secure Sockets Layer (SSL) connection may be used to secure communications during user authentication and column 6 lines 27-29). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Kalinichenko in view of Zhu to have shared random numbers used be both the first device and the second device to use to calculate a session key that can be used to create a secure channel between the first and second device (see Zhu column 8 lines 37-47). Therefore one would have been motivated to have shared random numbers that are used be both the first device and the second device to use to calculate a session key. Kalinichenko in view of Zhu does not teach performing an authorization dialog between the platform application and the user authentication device. Mizrah teaches performing an authorization dialog between the platform application and the user authentication device (see Mizrah paragraph 0134-0135 i.e. At the same time, one time authentication challenge OTAC 5020 is delivered as a SMS text message to user's 4090 personal mobile phone 5010 (i.e. claimed user authentication device). Now, user 4090 follows the simple instructions of RPPPR protocol in FIG. 2 and generates a one time authentication response OTAR by clicking on cells with appropriate alphanumeric character or special mark content along the highlighted graphical password in menu 4070 (i.e. gui of claimed user workplace application), and eventually enters OTAR into field 4040. Then, user 4090 closes menu 4070 by clicking on the upper left cell with a triangle mark, or anywhere outside of the menu, and indicating LOGIN button 3020, one time authentication response OTAC is sent to server 1030 (FIG. 1) which compares received and expected OTAR and signals back to user 4090 a positive or negative authentication result). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Kalinichenko in view of Mizrah to have use Mizrah’s the two-factor authentication in which the code is transmitted to the mobile phone (i.e. claimed user authentication device) to be enter code at the user terminal (i.e. claimed user workplace application) were it is transmitted to the server to be verified as a more secure login because an intruder without the password (or PIN) cannot initiate the authentication session and invoke the second authentication factor. At the same time, an intruder without user's personal mobile phone where the one time authentication challenge OTAC is arriving cannot fulfill the second authentication factor even having obtained access to the GUI in a browser or on a screen where the session authentication credential SAC is highlighted, rendering the authentication session failed (see Mizrah paragraph 0140). Therefore one would have been motivated to have used Mizrah’s the two-factor authentication. With respect to claim 21 Kalinichenko, Zhu et al and Mizrah teach the non-transitory computer-readable medium according to claim 20. Zhu teaches wherein the secure session between the platform application and the authentication device is set up by performing the steps of: generating a first random number (see Zhu figure 3B step 306 and column 5 lines 61-64 i.e. The server then generates a server challenge number (306). This challenge number can take several forms, two of which will be described shortly); exporting a first string derived from said first random number, to a user for entering the first string into the second entity (see Zhu figure 3A step 318 and column 6 line 7-10 i.e. The mobile device receives the identifications and number (318), and then generates the aforementioned secret value ( 320) and Kalinichenko column 4 lines 16-25) applying a one-way function to the first string or to a derivative thereof, obtaining an encoded string; transmitting the encoded string to an intermediate node that is in connection to a first entity and the second entity (see Zhu column 5 lines 5-15 i.e. In one embodiment, the combination is accomplished by concatenating the numbers and then computing a cryptographic hash of the concatenation using a prescribed cryptographic hash function (e.g., SHA-256 specified in Federal Information Processing Standards Publications (FIPS PUBS) 180-2 Secure Hash Standard), which is known to the mobile phone and the server associated with the Web site of interest. The resulting combined value is designated as the secret value (208) and is transmitted to the server associated with the Web site via a secure channel (210)); further comprising the steps of: generating a second random number, deriving a second string from said second random number and transmitting the second string to the second entity if a verifying step of comparing encoded strings transmitted by the first entity and the second entity has a positive result, or receiving from the second entity the second string being derived from a second random (see Zhu figure 3B step 322-326 and column 6 lines 7-13 i.e. The mobile device receives the identifications and number (318), and then generates the aforementioned secret value ( 320), a mobile device challenge number (322) and a representation of the secret value (324). Next, the mobile device forwards the mobile device challenge number and secret value representation to the client computer (326)), and further comprising the step of: deriving a secret key from the first string and the second string (see Zhu figure 3B step 336 and column 6 lines 27-29 i.e. The serve receives these numbers (334) and computes a session key from them (336)). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Kalinichenko in view of Zhu to have shared random numbers used be both the first device and the second device to use to calculate a session key that can be used to create a secure channel between the first and second device (see Zhu column 8 lines 37-47). Therefore one would have been motivated to have shared random numbers that are used be both the first device and the second device to use to calculate a session key. With respect to claim 22, Kalinichenko, Zhu et al and Mizrah teach the non-transitory computer-readable medium according to claim 20. Zhu teaches wherein the secure session between the platform application and the authentication device is set up by performing the steps of: receiving, via an I/O interface, a first string derived from a first random number generated by the first entity (see Zhu figure 3B step 306 and column 5 lines 61-64 i.e. The server then generates a server challenge number (306). This challenge number can take several forms, two of which will be described shortly); applying a one-way function to the first string or to a derivative thereof, obtaining an encoded string; transmitting the encoded string to an intermediate node that is in connection to the first and a second entity (see Zhu column 5 lines 5-15 i.e. In one embodiment, the combination is accomplished by concatenating the numbers and then computing a cryptographic hash of the concatenation using a prescribed cryptographic hash function (e.g., SHA-256 specified in Federal Information Processing Standards Publications (FIPS PUBS) 180-2 Secure Hash Standard), which is known to the mobile phone and the server associated with the Web site of interest. The resulting combined value is designated as the secret value (208) and is transmitted to the server associated with the Web site via a secure channel (210)); further comprising the steps of: generating a second random number, deriving a second string from said second random number and transmitting the second string to the first entity if a verifying step of comparing encoded strings transmitted by the first entity and the second entity has a positive result, or receiving from the first entity the second string being derived from the second random number (see Zhu figure 3B step 322-326 and column 6 lines 7-13 i.e. The mobile device receives the identifications and number (318), and then generates the aforementioned secret value ( 320), a mobile device challenge number (322) and a representation of the secret value (324). Next, the mobile device forwards the mobile device challenge number and secret value representation to the client computer (326)), and further comprising the step of: deriving a secret key from the first string and the second string (see Zhu figure 3B step 336 and column 6 lines 27-29 i.e. The serve receives these numbers (334) and computes a session key from them (336)). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Kalinichenko in view of Zhu to have shared random numbers used be both the first device and the second device to use to calculate a session key that can be used to create a secure channel between the first and second device (see Zhu column 8 lines 37-47). Therefore one would have been motivated to have shared random numbers that are used be both the first device and the second device to use to calculate a session key. With respect to claim 23 Kalinichenko, Zhu et al and Mizrah teach the non-transitory computer-readable medium according to claim 20. Zhu teaches wherein the secure session between the platform application and the authentication device is set up by performing the steps of: receiving an encoded string from a first entity and a second entity, the encoded string being obtained by applying a one-way function to a first string or to a derivative thereof, the first string being derived from a first random number generated by the first entity; verifying whether the encoded strings received from the first entity and second entity are the same; if the verifying step has a positive result, authorizing the first entity and the second entity to share a second string being derived from a second random number generated by the first entity or second entity, respectively (see Zhu column 6 lines 23-47). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Kalinichenko in view of Zhu to have The server then computes a server version of the combined representation using the user identification, the server identification, the server version of the secret value representation, and the password known to the server (340). The server then compares the server version of the combined representation to the combined representation received from the client computer (342) and determines if the password and secret value known to the server were used to generate the combined representation received from the client computer (see Zhu column 6 lines 23-47). Therefore one would have been motivated to have compares the server version of the combined representation to the combined representation received from the client computer (342) and determines if the password and secret value known to the server were used to generate the combined representation received from the client computer . With respect to claim 26, Kalinichenko, Zhu et al and Mizrah teach the computer system of claim 15, wherein the computer-readable instructions cause the processor to perform the authorization dialog after receiving the persistent instruction (see Kalinichenko figure 3 step 142 and step 154, column 7 lines 36-50 i.e. In operation, business processing server 104 receives (142), from a client device, a request to perform an action, e.g., request 130 (FIG. 2). The received request includes information identifying a user associated with the client device (e.g., login credentials of the user, a user name of the user, and so forth) and column 7 line 51 – column 8 line 3 i.e. The authentication token includes the device identifier of the mobile device, e.g., to promote using a presence of the mobile device specified by the device identifier as secondary factor authentication information. Business processing server 104 also generates (148), in a data repository, an association among the authentication token and the user profile. Business processing server 104 receives (150), from an authentication server, a decrypted version of an authentication token and a device identifier of a mobile device that is in proximity to the client device. Business processing server 104 identifies (152) a match between the authentication token that is generated for the user and the decrypted version of the authentication token. Business processing server 104 also identifies (153) a match between the received device identifier and the device identifier included in the user profile. In response to the identified matches, business processing server 104 performs (154) the requested action)). With respect to claim 27, Kalinichenko, Zhu et al and Mizrah teach the computer system of claim 15, wherein the authorization dialog determines a successful or unsuccessful user’s authorization of the persistent instruction (see Kalinichenko figure 3 steps 153-154 and column 7 line 51 – column 8 line 3 i.e. The authentication token includes the device identifier of the mobile device, e.g., to promote using a presence of the mobile device specified by the device identifier as secondary factor authentication information. Business processing server 104 also generates (148), in a data repository, an association among the authentication token and the user profile. Business processing server 104 receives (150), from an authentication server, a decrypted version of an authentication token and a device identifier of a mobile device that is in proximity to the client device. Business processing server 104 identifies (152) a match between the authentication token that is generated for the user and the decrypted version of the authentication token. Business processing server 104 also identifies (153) a match between the received device identifier and the device identifier included in the user profile. In response to the identified matches, business processing server 104 performs (154) the requested action)). With respect to claim 28, Kalinichenko, Zhu et al and Mizrah teach the non-transitory computer-readable medium of claim 20, wherein the computer readable code causes the processing unit to perform the authorization dialog after forwarding the persistent instruction to the platform application (see Kalinichenko figure 3 step 142 and step 154, column 7 lines 36-50 i.e. In operation, business processing server 104 receives (142), from a client device, a request to perform an action, e.g., request 130 (FIG. 2). The received request includes information identifying a user associated with the client device (e.g., login credentials of the user, a user name of the user, and so forth) and column 7 line 51 – column 8 line 3 i.e. The authentication token includes the device identifier of the mobile device, e.g., to promote using a presence of the mobile device specified by the device identifier as secondary factor authentication information. Business processing server 104 also generates (148), in a data repository, an association among the authentication token and the user profile. Business processing server 104 receives (150), from an authentication server, a decrypted version of an authentication token and a device identifier of a mobile device that is in proximity to the client device. Business processing server 104 identifies (152) a match between the authentication token that is generated for the user and the decrypted version of the authentication token. Business processing server 104 also identifies (153) a match between the received device identifier and the device identifier included in the user profile. In response to the identified matches, business processing server 104 performs (154) the requested action)). With respect to claim 29, Kalinichenko, Zhu et al and Mizrah teach the non-transitory computer-readable medium of claim 20, wherein the authorization dialog determines a successful or unsuccessful user’s authorization of the persistent instruction (see Kalinichenko figure 3 steps 153-154 and column 7 line 51 – column 8 line 3 i.e. The authentication token includes the device identifier of the mobile device, e.g., to promote using a presence of the mobile device specified by the device identifier as secondary factor authentication information. Business processing server 104 also generates (148), in a data repository, an association among the authentication token and the user profile. Business processing server 104 receives (150), from an authentication server, a decrypted version of an authentication token and a device identifier of a mobile device that is in proximity to the client device. Business processing server 104 identifies (152) a match between the authentication token that is generated for the user and the decrypted version of the authentication token. Business processing server 104 also identifies (153) a match between the received device identifier and the device identifier included in the user profile. In response to the identified matches, business processing server 104 performs (154) the requested action)). With respect to claim 30, Kalinichenko, Zhu et al and Mizrah teach the method of claim 1, wherein the connection between the platform application and the user authentication device is set up via an authentication provider securely connected to the user authentication device (See Kalinichenko column 6 lines 1-37 i.e. In response to receiving authentication token 132, client device 102 executes a pairing process with mobile device 116, e.g., to automatically establish a connection with mobile device 116. Following establishment of the connection between client device 102 and mobile device 116, client device 116 transmits authentication token 132 to mobile device 116. Authentication application 117 receives authentication token 132. In response, authentication application 117 uses key 127 to encrypt authentication token 132. As previously described, mobile device 116 is configured to generate and to store key 127. Authentication application 117 also generates information 134, which includes the encrypted version of authentication token 132 and device ID 128 for mobile device 116.), and to an authentication server associated with the platform application (See Kalinichenko column 6 lines 15-65 i.e. Mobile device 116 transmits information 134 to authentication server 114 (i.e. claimed authentication server associated with the platform application), e.g., via network 124 and through firewall 106. System 100 also includes network 136, which is a private network of authentication server 114 that bypasses firewall. Examples of network 136 include a LAN and a WAN. Based on mobile device 116 being authenticated by authentication server 114, authentication server 114 enables mobile device 116 to access network 136 in transmitting information to authentication server 114. Mobile device 116 can also send information to authentication server 114 via network 136…. Authentication server 114 transmits to business processing server 104 decrypted version 136 of authentication token 132 to business processing server 104, along with device ID 128 of mobile device 116)). Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over Kalinichenko et al (US 9,124,582) in view of Zhu et al (US 8,209,744) in view of Mizrah (US 2008/0098464) in view of Maidl et al (US 2014/0208409). With respect to claim 13 Kalinichenko, Zhu et al and Mizrah teach a method according to claim 1, but does not disclose further including a step of authorizing a document in a cloud application. Maidl teaches further including a step of authorizing a document in a cloud application (see Maidl paragraph 0035 i.e. With respect to the cloud application, documents can be stored with EDRM protection, with the result that these documents can be locally processed only by authorized users). It would have been obvious at the time the invention was filed to a person having ordinary skill in the art to which said subject matter pertains to have authorizing a document in a cloud application to users that can locally process the document if that are authorized users (see Maidl paragraph 0035). Therefore one would have been motivated to have authorizing a document in a cloud application. Allowable Subject Matter Claim 12 is objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims. The prior art does not disclose with respect to claim 12, wherein the step of transmitting the second string is implemented by exporting the second string to a user, via an I/O interface of one entity, for manually entering the second string into an I/O interface of the other entity. Prior Art Niejadlik (US 8,219,542) titled “Systems And Methods To Provide Access Control Via Mobile Phones”. Conclusion THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action. Any inquiry concerning this communication or earlier communications from the examiner should be directed to DEVIN E ALMEIDA whose telephone number is (571)270-1018. The examiner can normally be reached on Monday-Thursday from 7:30 A.M. to 5:00 P.M. The examiner can also be reached on alternate Fridays from 7:30 A.M. to 4:00 P.M. If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, Rupal Dharia, can be reached on 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 an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). /DEVIN E ALMEIDA/Examiner, Art Unit 2492 /RUPAL DHARIA/Supervisory Patent Examiner, Art Unit 2492
Read full office action

Prosecution Timeline

Apr 28, 2016
Application Filed
Apr 28, 2016
Response after Non-Final Action
Jan 22, 2018
Non-Final Rejection — §103
Jun 26, 2018
Response Filed
Oct 19, 2018
Final Rejection — §103
Apr 24, 2019
Request for Continued Examination
May 02, 2019
Response after Non-Final Action
Aug 02, 2019
Non-Final Rejection — §103
Feb 07, 2020
Response Filed
May 07, 2020
Final Rejection — §103
Nov 12, 2020
Request for Continued Examination
Nov 17, 2020
Response after Non-Final Action
May 20, 2021
Non-Final Rejection — §103
Nov 26, 2021
Response Filed
Mar 08, 2022
Final Rejection — §103
Aug 15, 2022
Request for Continued Examination
Aug 23, 2022
Response after Non-Final Action
Sep 12, 2022
Non-Final Rejection — §103
Feb 21, 2023
Response Filed
Jun 08, 2023
Final Rejection — §103
Dec 20, 2023
Request for Continued Examination
Dec 28, 2023
Response after Non-Final Action
Jan 05, 2024
Non-Final Rejection — §103
Jul 12, 2024
Response Filed
Oct 24, 2024
Final Rejection — §103
Apr 29, 2025
Request for Continued Examination
May 11, 2025
Response after Non-Final Action
May 14, 2025
Non-Final Rejection — §103
Dec 05, 2025
Response Filed
Dec 31, 2025
Final Rejection — §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12580763
USE OF TENSILE SPHERES FOR EXTENDED SYMMETRIC CRYPTOGRAPHY
2y 5m to grant Granted Mar 17, 2026
Patent 12562886
Fast Polynomial Evaluation Under Fully Homomorphic Encryption by Products of Differences from Roots Using Rotations
2y 5m to grant Granted Feb 24, 2026
Patent 12556512
METHODS, SYSTEMS, AND COMPUTER READABLE MEDIA FOR AUTOMATIC CATEGORY 1 MESSAGE FILTERING RULES CONFIGURATION BY LEARNING TOPOLOGY INFORMATION FROM NETWORK FUNCTION (NF) REPOSITORY FUNCTION (NRF)
2y 5m to grant Granted Feb 17, 2026
Patent 12556393
SYSTEMS AND METHODS FOR REAL-TIME TRACEABILITY USING AN OBFUSCATION ARCHITECTURE
2y 5m to grant Granted Feb 17, 2026
Patent 12542682
AUTHENTICATING PACKAGED PRODUCTS
2y 5m to grant Granted Feb 03, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

13-14
Expected OA Rounds
71%
Grant Probability
82%
With Interview (+11.4%)
3y 9m
Median Time to Grant
High
PTA Risk
Based on 592 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month