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 .
Response to Arguments
Applicant’s arguments with respect to claim(s) are rejected under 103 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Applicant argued in the remark that Independent claim 1 has been amended to recite "generating, by the client device, a client security token that includes (i) a signature of a browser application of the client device based on a certificate issued to the browser application by the domain server and (ii) the confidence score, wherein the signature of the browser application is generated by signing a concatenated nonce and timestamp using the certificate issued to the browser application." For the reasons that follow, the combination of cited art fails to describe or suggest this feature in combination with the other features of amended claim 1.
Examiner respectfully disagrees. Sanin et al US 7500262, fig.7, col 8, lines 45-46 (50) The browser 115 passes the web site application identification, i.e. signature of browser, and the browser token, i.e. a client security token, to the CAW 170 (770), wherein an encrypted browser token, i.e. a client security toke, is generated by the CLC-enabled clients of the browser clients with the help of the CAW at step 762. Col 8, lines 45-55 he browser 115 passes the web site application identification and the browser token to the CAW 170 (770). Wherein the browser token includes a random number and timestamps, thus the CAW 170 would be able to check the browser token, random number, and time stamp (772). If any of the checks fail, the CAW 170 responds with an error message and a login form with which the user can manually enter login credentials (774). The checks performed by the CAW 170 include reading and decrypting the cookies, comparing the passed values, confidence score of the token, of the random number to ensure they match, and checking the timestamp in the browser token to ensure the token has not expired.
col 3, lines 65-68 CLC-enabled clients can be browser clients, the browser clients generates discloses , fig.7 discloses numeral 770 the browser 115 sends the wed site ID and , col 6, lines 4-15 (30) After the user's credentials and the application identification are validated, the CAW 170 generates a CLC master authentication token and an application token (350). The CAW 170 then passes these tokens to the CLC 165 (355). The CLC 165 stores the CLC master token (360) and sends the application token to the client 120 (365). The client 120 sends the application token to the server 130 that supports the client 120 (370). The server 130 decrypts the application token to decrypt and validate the credential information (i.e., the user authentication data) necessary to access the client 120 (375). The server 130 then establishes an authenticated session to permit the user to access the client 120 (380).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-3,6-7, 8-10,13-14,15-17 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Sanin et al US 7,500262 in view of Benishti et L US 9,294,502 in view of Williams US 2003/0005118.
As per claim 8. Sanin discloses a system comprising:
one or more computer processors; and a memory device connected to the one or more computer processors (col 3, lines 19-20 the access device 105 with processor and memory), wherein the one or more computer processors are configured to perform operations comprising:
visiting one or more web pages of a domain server (col 3, lines 19-20 the access device 105 communicates with the servers 130, 135, 150 , i.e. domain);
storing a security token in the memory device based on the visiting of the one or more web pages of the domain server ( col 6, lines 55-58 The browser stores the browser master token (470) and forwards the web site application token to the server 150 supporting the selected web site 140),
wherein: the security token includes a confidence score indicating a likelihood ( Col 8, lines 45-55 he browser 115 passes the web site application identification and the browser token to the CAW 170 (770). Wherein the browser token includes a random number and timestamps, thus the CAW 170 would be able to check the browser token, random number, and time stamp (772). If any of the checks fail, the CAW 170 responds with an error message and a login form with which the user can manually enter login credentials (774). The checks performed by the CAW 170 include reading and decrypting the cookies, comparing the passed values, confidence score of the token, of the random number to ensure they match, and checking the timestamp in the browser token to ensure the token has not expired), and the security token is signed using a certificate of the web server ( col 6, lines 25-30 The user then clicks on the login button of the web site to sign into the web site (415));
generating a client security token that includes (i) a signature of a browser application of the system based on a certificate issued to the browser application by the web server (col 7, lines 24-28 If the CLC master authentication token and the application identification are valid, the CAW 170 generates an encrypted application token (535) and passes the application token to the CLC 165 (540). The CLC 165 passes the encrypted application token to the non-browser client 125 (545). The non-browser client 125 passes the encrypted application token to its associated server 135 (550). The associated server 135 decrypts the application token to extract user authentication data (555), and uses this data to establish an authenticated session for the user (560). Thus, the session is established without requiring the user to enter credentials to establish the session )and (ii) the confidence score, wherein the signature of the browser application is generated by signing a concatenated nonce and timestamp using the certificate issued to the browser application;( fig.7, col 8, lines 45-46 (50) The browser 115 passes the web site application identification, i.e. signature of browser, and the browser token, i.e. a client security token, to the CAW 170 (770), wherein an encrypted browser token, i.e. a client security toke, is generated by the CLC-enabled clients of the browser clients with the help of the CAW at step 762. Col 8, lines 45-55 he browser 115 passes the web site application identification and the browser token to the CAW 170 (770). Wherein the browser token includes a random number and timestamps, thus the CAW 170 would be able to check the browser token, random number, and time stamp (772). If any of the checks fail, the CAW 170 responds with an error message and a login form with which the user can manually enter login credentials (774). The checks performed by the CAW 170 include reading and decrypting the cookies, comparing the passed values, confidence score of the token, of the random number to ensure they match, and checking the timestamp in the browser token to ensure the token has not expired)
transmitting, to a content server that differs from the domain server, the client security token with a request for content(col 3, lines 65-68 CLC-enabled clients can be browser clients, the browser clients generates discloses , fig.7 discloses numeral 770 the browser 115 sends the wed site ID and , col 6, lines 4-15 (30) After the user's credentials and the application identification are validated, the CAW 170 generates a CLC master authentication token and an application token (350). The CAW 170 then passes these tokens to the CLC 165 (355). The CLC 165 stores the CLC master token (360) and sends the application token to the client 120 (365). The client 120 sends the application token to the server 130 that supports the client 120 (370). ); and
receiving, from the content server, a response to the request for content based on an authentication of information included with the request for content and an evaluation of the confidence score by the content server ( col 3, lines 65-68 CLC-enabled clients can be browser clients, the browser clients generates discloses , fig.7 discloses numeral 770 the browser 115 sends the wed site ID and , col 6, lines 4-15 (30) After the user's credentials and the application identification are validated, the CAW 170 generates a CLC master authentication token and an application token (350). The CAW 170 then passes these tokens to the CLC 165 (355). The CLC 165 stores the CLC master token (360) and sends the application token to the client 120 (365). The client 120 sends the application token to the server 130 that supports the client 120 (370). The server 130 decrypts the application token to decrypt and validate the credential information (i.e., the user authentication data) necessary to access the client 120 (375). The server 130 then establishes an authenticated session to permit the user to access the client 120 (380)).
Sanin does not disclose visiting to domain sever, providing the domain toke to client; the wherein: the security token includes indicating a likelihood of the system being associated with a malicious entity.
However, Benishti discloses the wherein: the security token includes indicating a likelihood of the system being associated with a malicious entity( col 2, lines 40-50 receive a token from the client machine in response to the polymorphic script code challenge; compare contents of the received token to the secret in its unscrambled form; and determine the client machine to be a malicious bot in an event including any one of the token does not match the secret and a token has not been received, wherein a new polymorphic script code challenge containing a new scrambled secret is generated for each new request received from a client machine).
Sanin and Benishti are both considered to be analogous to the claimed invention because they are in the same field of token verification. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Sanin to incorporate the teachings of Benishti and provide token verification. Doing so would verify the machine, thereby increasing machine protection in the network.
The combination does not explicitly disclose visiting to domain sever (0008 When a user of a client machine visits a Web server, the server may return a cookie to the user's browser to be stored in a client-side cookie cache. 0018 [0018] A client attempts to login to a domain through a first server, which challenges the client to provide authentication data for identifying the client or the user of the client. After the first server has authenticated the client or the user of the client, the first server generates a single-use domain token that is associated with the client or the user of the client and returns the single-use domain token to the client. The login request may have originated as a redirect response from a second server; if so, then the first server redirects the client to the second server. And 0069 CDC generates a domain token for the client or user (step 330), which might include registering the domain token within a database. The CDC then sends the domain token to the client (step 332), and the process is complete).
Sanin and Benishti and Williams are both considered to be analogous to the claimed invention because they are in the same field of token verification. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Sanin to incorporate the teachings of Benishti and including the teaching of Williams, and provide token verification. Doing so would verify the machine, thereby increasing machine protection in the network.
As per claim 9. Sanin and Benishti and Williams discloses The system of claim 8, the security token is signed using a group signature of a group of servers that includes the domain server (Sanin col 3, lines 19-20 the access device 105 communicates with the servers 130, 135, 150 , i.e. domain and col 3, lines 65-68 CLC-enabled clients can be browser clients, the browser clients generates discloses , fig.7 discloses numeral 770 the browser 115 sends the wed site ID and , col 6, lines 4-15 (30) After the user's credentials and the application identification are validated, the CAW 170 generates a CLC master authentication token and an application token (350). The CAW 170 then passes these tokens to the CLC 165 (355). The CLC 165 stores the CLC master token (360) and sends the application token to the client 120 (365). The client 120 sends the application token to the server 130 that supports the client 120 (370)).
As per claim 10. Sanin and Benishti and Williams discloses The system of claim 9, wherein group signature includes an encrypted authentication string that identifies the group of servers upon decryption(Sanin col 7, lines 24-35 (37) If the CLC master authentication token and the application identification are valid, the CAW 170 generates an encrypted application token (535) and passes the application token to the CLC 165 (540). The CLC 165 passes the encrypted application token to the non-browser client 125 (545). The non-browser client 125 passes the encrypted application token to its associated server 135 (550). The associated server 135 decrypts the application token to extract user authentication data (555), and uses this data to establish an authenticated session for the user (560). Thus, the session is established without requiring the user to enter credentials to establish the session).
As per claim 13. Sanin and Benishti and Williams discloses The system of claim 8, wherein receiving the response to the request for content based on the authentication of information included with the request and the evaluation of the confidence score comprises receiving a first response to the request for content when the confidence score is below a specified threshold level ( Sanin fig.7, col 8, lines 45-46 (50) The browser 115 passes the web site application identification, i.e. signature of browser, and the browser token, i.e. a client security token, to the CAW 170 (770), wherein an encrypted browser token, i.e. a client security toke, is generated by the CLC-enabled clients of the browser clients with the help of the CAW at step 762. Col 8, lines 45-55 he browser 115 passes the web site application identification and the browser token to the CAW 170 (770). Wherein the browser token includes a random number and timestamps, thus the CAW 170 would be able to check the browser token, random number, and time stamp (772). If any of the checks fail, the CAW 170 responds with an error message and a login form with which the user can manually enter login credentials (774). The checks performed by the CAW 170 include reading and decrypting the cookies, comparing the passed values, confidence score of the token, of the random number to ensure they match, and checking the timestamp in the browser token to ensure the token has not expired).
As per claim 14. Sanin and Benishti and Williams discloses The system of claim 8, wherein receiving the response to the request for content based on the authentication of information included with the request and the evaluation of the confidence score comprises receiving content selected based on the client security token when the confidence score is above a specified threshold level (Sanin fig.7, col 8, lines 45-46 (50) The browser 115 passes the web site application identification, i.e. signature of browser, and the browser token, i.e. a client security token, to the CAW 170 (770), wherein an encrypted browser token, i.e. a client security toke, is generated by the CLC-enabled clients of the browser clients with the help of the CAW at step 762. Col 8, lines 45-55 he browser 115 passes the web site application identification and the browser token to the CAW 170 (770). Wherein the browser token includes a random number and timestamps, thus the CAW 170 would be able to check the browser token, random number, and time stamp (772). If any of the checks fail, the CAW 170 responds with an error message and a login form with which the user can manually enter login credentials (774). The checks performed by the CAW 170 include reading and decrypting the cookies, comparing the passed values, confidence score of the token, of the random number to ensure they match, and checking the timestamp in the browser token to ensure the token has not expired ).
As per claims 1-3, and 6-7, those method claims are rejected based on the same rational set forth in the claims 8-10 and 13-14 respectively.
As per claims 15-17 and 20, those medium claims are rejected based on the same rational set forth in the claims 8-10, and 13 respectively.
Claim(s) 4-5,11-12, and 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over Sanin et al US 7,500262 in view of Benishti et L US 9,294,502 in view of Williams US 2003/0005118 in view of Yonezawa et al US 2009/0089575.
As per claim 11. Sanin and Benishti and Williams discloses The system of claim 9, the combination fails to disclose wherein the one or more computer processors are configured to perform operations further comprising: receiving a group certificate corresponding to a subgroup of servers among the group of servers; and anonymously signing the request for content using the group certificate.
However, Yonezawa discloses receiving a group certificate corresponding to a subgroup of servers among the group of servers ([0024] Preferably, the user apparatus generates a group signature key based on the public information, converting the group signature key into converted data, and providing the converted data to the entrustor apparatus, the entrustor apparatus generates a digital signature using the converted data provided by the user apparatus and the member registration key, thereby generating a member certificate as the signature key, and the user apparatus generates the group signature data using the request for the predetermined service, the member certificate, the group signature key, and the public information); and anonymously signing the request for content using the group certificate (0092] The member certificate is a digital signature generated by calculations for converting converted data of the group signature key using a member registration key (secret key)).
Sanin and Benishti and Williams and Yonezawa are both considered to be analogous to the claimed invention because they are in the same field of token verification. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Sanin to incorporate the teachings of Benishti and including the teaching of Williams, including the teaching of Yonezawa and provide token verification. Doing so would verify the machine, thereby increasing machine protection in the network.
As per claim 12. Sanin and Benishti and Williams and Yonezawa discloses The system of claim 11, Yonezawa discloses wherein transmitting the client security token with the request for content comprises transmitting the client security token with the request for content and the group certificate( [0093] For generating group signature data for a message, the signature apparatus encrypts the member certificate with a public key corresponding to an open key. The encrypted member certificate is referred to as encrypted data. The signature apparatus then calculates converted data of the member certificate.).
As per claims 4-5, those method claims are rejected based on the same rational set forth in the claims 11-12 respectively.
As per claims 18-19, those medium claims are rejected based on the same rational set forth in the claims 11-12 respectively.
Conclusion
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 ABU S SHOLEMAN whose telephone number is (571)270-7314. The examiner can normally be reached EST: 9am-5pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, JORGE ORTIZ CRIADO can be reached at 571-272-7624. 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.
/ABU S SHOLEMAN/Primary Examiner, Art Unit 2496
Prosecution Insights