DETAILED ACTION
This Final Office Action is in response to amendment filed on 08/05/2026. Claims 21, 25, 29, 31, 33-34, and 38 have been amended. Claims 21-40 remain pending in the application.
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 .
Drawings
The drawings filed on 01/23/2025 are accepted.
Response to Amendment
Applicant’s claims amendments has overcome the objection previously set forth in the Non-Final Office Action mailed on 05/05/2026.
Response to Arguments
Applicant’s arguments in Pages 7-8 of the Remarks filed on 08/05/2026 are considered moot in light of he newly introduced prior arts. Please see detailed rejection below.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP §§ 706.02(l)(1) - 706.02(l)(3) for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 21-40 rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-3, 5, 7, 10, 13, 16, 17 of US Patent US 11558206 B2, hereinafter 206, in view of Wang (US 20140380418 A1) and Kaler et. al. (US 20040139152 A1).
Instant Application 19/034,722
US 11558206 B2
21. (Currently Amended) A method for dynamic browser challenge generation and verification comprising:
1. A method for dynamic browser challenge generation and verification comprising:
generating, at a verification device, a random number as an answer;
generating a random number in response to receiving the first request from the unverified client device… wherein the random number is an answer to the browser challenge problem
generating a problem comprising a set of expressions that evaluate to the answer;
defining a browser challenge problem with browser executable instructions comprising a set of expressions, wherein the set of expressions comprises two or more expressions, wherein each expression of the set of expressions evaluates to a value that is less than the random number
encrypting the answer within an answer token;
encrypting the answer within an answer token;
providing the problem as browser-executable code and the answer token with the encrypted answer to a client device;
defining a browser challenge problem with browser executable instructions comprising a set of expressions,…encrypting the answer within an answer token; providing the browser challenge problem with the answer token to the unverified client device;
receiving a request with a solution and the answer token from [[a]]the client device;
receiving a second request with a solution to the browser challenge problem and the answer token from the unverified client device;
decrypting [[an]]the answer from the answer token and comparing the solution to the answer; and when the answer is verified, responding to the request.
Claim 31 is similar to claim 31
and verifying the unverified client device in response to the solution matching the answer that is decrypted from the answer token provided with the second request.
22. (Original) The method of claim 21, wherein responding to the request includes providing a verification token.
10. The method of claim 1 further comprising: providing a verified token to the unverified client device in response to said verifying, wherein the verified token comprises an indication that the unverified client device has been successfully verified by one node of a distributed platform and that the unverified client device may subsequently access data from other nodes of the distributed platform without additional verification.
23. (Original) The method of claim 21, wherein responding to the request includes providing content.
7. The method of claim 1 further comprising: distributing content requested within the second request in response to verifying the unverified client device.
24. (Original) The method of claim 21, wherein responding to the request includes providing data.
10….access data from other nodes of the
25. (Currently Amended) The method of claim 21, further comprising: setting a time for expiration of the answer token; invalidating the request when the time for expiration has elapsed; and when the time for expiration has not elapsed, determining whether the answer token is valid
5. The method of claim 1 further comprising: entering a timestamp in the answer token; extracting the timestamp from the answer token provided with the second request; and invalidating the second request in response to the timestamp extracted from the answer token provided with the second request having expired.
26. (Original) The method of claim 21, wherein the request passes as one or more cookies.
16. The method of claim 1, wherein the browser executable instructions further comprise one or more instructions that cause the unverified client device to set a first cookie based on encrypted contents of the answer token, and to set a second cookie with the solution.
17. The method of claim 16, wherein verifying the unverified client device comprises: determining that the second request is issued with the first cookie and the second cookie; and invalidating the second request in response to the second request omitting one or more of the first cookie or the second cookie.
27. (Original) The method of claim 21, wherein the solution is embedded in a header of a request packet.
28. (Original) The method of claim 21, wherein the answer token is embedded in a header of a request packet.
29. (Currently Amended) The method of claim 21, wherein the further comprising processing [[of the]] a unique identifier of the client device for verification, wherein the processing of the unique identifier includes determining the unique identifier.
2. The method of claim 1 further comprising: identifying a unique identifier of the unverified client device from one or more header parameters of the first request; encrypting the unique identifier of the unverified client device within the answer token; and wherein providing the browser challenge problem with the answer token comprises sending the answer and the unique identifier to the unverified client device in an encrypted format.
3. The method of claim 2 further comprising: invalidating the second request in response to a unique identifier identified from one or more header parameters of the second request differing from the unique identifier that is decrypted from the answer token provided with the second request.
30. (Original) The method of claim 21, further comprising generating a verification token upon verify the client device.
10. The method of claim 1 further comprising: providing a verified token to the unverified client device in response to said verifying, wherein the verified token comprises an indication that the unverified client device has been successfully verified by one node of a distributed platform and that the unverified client device may subsequently access data from other nodes of the distributed platform without additional verification.
32. (Original) The system of claim 31, comprising at least one of a distribution platform that performs the verification of the answer.
7. The method of claim 1 further comprising: distributing content requested within the second request in response to verifying the unverified client device.
33. (Currently Amended) The system of claim 31, wherein the answer is encrypted using a private key.
…encrypt the answer within an answer token
34. (Currently Amended) The system of claim 33, wherein the system is configured such that the client device returns the encrypted answer along with a solution to a problem to any distribution platform that [[may]] is adapted to verify the client device based on the solution and the encrypted answer.
… verifying the unverified client device in response to the solution matching the answer that is decrypted from the answer token provided with the second request.
35. (Original) The system of claim 31, wherein new and different answers are generated for different client devices.
36. (Original) The system of claim 32, wherein the answer is not stored in any device of the distribution platform.
37. (Original) The system of claim 31, wherein the client device is a network-enabled device.
38. (Currently Amended) The system of claim 31, wherein the circuitry is further configured to: set a time for expiration of the answer token; invalidate the request when the time for expiration has elapsed; and when the time for expiration has not elapsed, determine whether the answer token is valid the client device is an Internet-of-Things device.
5. The method of claim 1 further comprising: entering a timestamp in the answer token; extracting the timestamp from the answer token provided with the second request; and invalidating the second request in response to the timestamp extracted from the answer token provided with the second request having expired.
39. (Original) The system of claim 31, wherein the request includes a Uniform Resource Locator.
13. The method of claim 1, wherein a Uniform Resource Locator (“URL”) of the first request matches a URL of the second request.
40. (Original) The system of claim 32, wherein the at least one distribution platform seeds a random number generator to avoid replication of an answer, and the answer is obfuscated by use of a private key.
Although the conflicting claims are not identical, they are not patentably distinct from each other because the above claims of 206 contains every element of claims 21-40 of the instant application except for the bolded limitations as seen in the above table. However,
Wang discloses generating a problem comprising a set of expressions that evaluate to the answer and responding to the request (Wang “[0018] 1. The server picks a pair of random numbers A and B, where A and B are two large positive integers with A<B. [0019] 2. The server generate two random large prime number Q and P, where P<Q and P is in the range from A to B. [0020] 3. The server calculate N=P*Q, to get a challenge number set (N, A, B) and corresponding solution number set (N, P). [0021] 4. The server searches in the database and deletes all expired solutions of challenges in the database. [0022] 5. Search for the solution. If the newly generated solution is already in the database, restart from step 1. If not, store the solution along with an expiry time assigned to it in the database. [0023] 6. The server sends the challenge to the client.”, where the server generates random number P, which is used to generate a challenge, and send the challenge for verification to the client device, where expressions can be construed as the challenge in plaintext/numbers/digits sent to the client, [0032] “Then inform the arbitration to the client”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified 206 to incorporate the teaching of Wang to utilize the above feature, with the motivation of preventing brute force attacks against passwords, as recognized by (Wang Abstract).
206 and Wang do not disclose the limitation below.
Kaler discloses the solution is embedded in a header of a request packet (Kaler Figure 5 510-520 532, further in [0089-0090]),
wherein the answer is encrypted using a private key, seeds a random number generator to avoid replication of an answer, and the answer is obfuscated by use of a private key (Kaler [0025] discloses using a challenge type of a random number problem, where a digest of a random number is generated and included in the challenge as disclosed in [0075] given as an answer as disclosed in [0094], [0084] discloses encrypted in the answer with a symmetric key “…An authentication token can contain an encrypted type of challenge, encrypted timestamp, and/or encrypted answer using a symmetric key for a service”, further in [0098] “When a response is received, message processor 208 may decrypt an included authentication token using an appropriate key (e.g., a symmetric key). ”, examiner notes that the answer in the authentication token is encrypted utilizing a symmetric/secret key, which enables the processor 208 to eventual decrypt and compare to the received answer/solution from the client, examiner further notes that the private key in the specification of the instant application is only referenced in publication paragraph [0043] without any indication as to what the private key entails, e.g. is it part of the private/public key pair? or is it just a private/secret key associated with the verifying entity to decrypt the encrypted answer?, and further stated within the same paragraph that the a key in one embodiment be used for encryption and decryption, therefore, given the broadest reasonable interpretation, the private key in the claim is interpreted as a private/secret key associated with the verifying entity, furthermore, the concept of using a binary selection of symmetric or asymmetric key is obvious to be used by one of ordinary skill in the art),
wherein new and different answers are generated for different client devices (Kaler [0013] discloses different types of challenges that can be used for different clients based on e.g. previously established context between the client and the server, which requires different types of answers, furthermore, the use of random value problem generates an random value as an answer for every verification as disclosed in [0025]),
wherein the answer is not stored in any device of the distribution platform (Kaler [0015] “… Thus, a server may include all the data for indicating a challenge to the client and all the data for determining if an appropriate response is received within an issued challenge. As such, there is no need to maintain this data at the server.”, [0016] “…the client may include all of the data for responding to a challenge within a formulated response. As such, there is no need to maintain this data at the client. ”),
wherein the client device is a network-enabled device Kaler [0021] “FIG. 2 illustrates an example of a network architecture that can facilitate the performance of a challenge.”, further in [0029 and 0032]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified 206 to incorporate the teaching of Kaler to utilize the above feature because it would be obvious to try in embedding the solution in any of the finite packet fields, and utilizing any one of the finite type of cryptographic keys, private/public or symmetric key for encryption, and using the process on network devices.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 21,23-28, 31-38 and 40 are rejected under 35 U.S.C. 103 as being unpatentable over Kaler et. al. (US 20040139152 A1), hereinafter Kaler, in view of Wang (US 20140380418 A1) and Shao (US 20170180373 A1).
Regarding claim 21 (Currently Amended), Kaler teaches a method for dynamic browser challenge generation and verification (Kaler [0013] “The foregoing problems with the prior state of the art are overcome by the principles of the present invention, which are directed towards methods, systems, computer program products, and data structures for performing generic challenges in a distributed system.” And Figure 2, [0062, 0071] discloses HTTP, XML and SOAP which is associated with and performed in a browser) comprising:
generating, at a verification device, a random number as an answer (Kaler [0080] “…A challenge implemented with the parameters in the Parameters sub-element can be used to challenge a message processor to find a random number between 1,000,000 and 1,100,000. A message processor attempting to find an answer to the challenge may calculate digest values of numbers between 1,000,000 and 1,100,000 until a digest value of "FEOIJF" is calculated.”, where the calculated digest FEOIJF is evaluated based on the random number answer);
generating a problem comprising a set of expressions [[that evaluate to the answer]] (Kaler [0013] “…The server may have access to any number of different types of challenges, such as, for example, random number problems, cryptographic problems, and digital signature problems. The server can identify one of the types of challenges based on, for example, data included in the request, a previously established context between the client and the server, or an intersection of supported challenges between the client and the server.”, [0015] "The server issues a challenge (e.g., in a second electronic message) in accordance with the identified type of challenge...if an identified type of challenge is a random number problem, the server may issue a challenge that includes a range of numbers, an indication of a message digest algorithm, and a message digest of a random number.", where the server generates a random number and the digest of the random number, and challenging the client to find the random number and its corresponding digest from a range of numbers as disclosed in [0080], where the challenge and its associated digest of the random number answer is issued in response to the request as illustrated in Figure 2 (230-241), where the generates the random number answer, a priori, in order to generate its corresponding digest in order to send the digest and the random number rage, e.g. between 1,000,000 and 1,100,000 to the client), expressions can be construed as elements of the challenge);
encrypting the answer within an answer token (Kaler [0015] “A challenge can also include an optional authentication token that includes, for example, an encrypted version of the answer to the random number problem. ”, where the answer is encrypted as further disclosed in [0084]);
providing the problem as browser-executable code and the answer token with the encrypted answer to a client device (Kaler [0015] “A challenge can also include an optional authentication token that includes, for example, an encrypted version of the answer to the random number problem.”);
receiving a request with a solution and the answer token from [[a]] the client device (Kaler [0015] “A challenge can also include an optional authentication token that includes, for example, an encrypted version of the answer to the random number problem.”, [0016] “…the client can formulate a response (i.e. request) that includes the answer to the random number problem. The client can also formulate a response that includes the original request and the authentication token. Thus, the client may include all of the data for responding to a challenge within a formulated response.”);
decrypting [[an]]the answer from the answer token and comparing the solution to the answer (Kaler [0098] “When a response is received, message processor 208 may decrypt an included authentication token using an appropriate key (e.g., a symmetric key). Decrypting an authentication token can reveal a type of challenge, an answer, and a time stamp (and thus there is little, if any, need to maintain these at message processor 208).”, [0099] “The revealed type of challenge and answer can be compared to the type of challenge and answer included in the response (e.g., included in response 251). When the results of the comparisons are appropriate, an associated request (e.g., request 231) can be processed.”); and
when the answer is verified, responding to the request (Kaler [0097] “When an appropriate response to an issued challenge is received, a message processor may process a request.”, [0099] “The revealed type of challenge and answer can be compared to the type of challenge and answer included in the response (e.g., included in response 251). When the results of the comparisons are appropriate, an associated request (e.g., request 231) can be processed.”).
Kaler does not explicitly disclose the limitation below.
Wang discloses generating a random number that corresponds to an answer then generating, at a verification device, generating a problem comprising a set of expressions that evaluate to the answer (Wang “[0018] 1. The server picks a pair of random numbers A and B, where A and B are two large positive integers with A<B. [0019] 2. The server generate two random large prime number Q and P, where P<Q and P is in the range from A to B. [0020] 3. The server calculate N=P*Q, to get a challenge number set (N, A, B) and corresponding solution number set (N, P). [0021] 4. The server searches in the database and deletes all expired solutions of challenges in the database. [0022] 5. Search for the solution. If the newly generated solution is already in the database, restart from step 1. If not, store the solution along with an expiry time assigned to it in the database. [0023] 6. The server sends the challenge to the client.”, where the server generates random number P, which is used to generate a challenge, and send the challenge for verification to the client device, where expressions can be construed as the challenge in plaintext/numbers/digits sent to the client).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Kaler to incorporate the teaching of Wang to utilize the above feature, with the motivation of preventing brute force attacks against passwords, as recognized by (Wang Abstract).
Kaler in view of Wang does not explicitly disclose providing the problem as browser-executable code.
Shao discloses providing the problem as browser-executable code (Shao [0031] “…the challenges can be browser task based challenges. For instance, a challenge can include a first set of data and can require a browser of requesting device 110 to perform a browser task with respect to the first set of data. The browser task can include a set of instructions that can, upon execution, cause requesting device 110 to generate a second set of data.”, where the challenge include a plurality of set of data/expressions as disclosed in e.g. [0005])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Kaler in view of Wang to incorporate the teaching of Shao to utilize the above feature, with the motivation of determining whether the browser is an authorized browser, as recognized by (Shao Abstract).
Regarding claim 31, claim 31 recites similar limitations to claim 21, therefore rejected with the same rationale/motivation applied to claim 21.
Regarding claim 23 (Original), Kaler in view of Wang and Shao teaches the method of claim 21, wherein responding to the request includes providing content (Kaler [0097] “When an appropriate response to an issued challenge is received, a message processor may process a request.”, [0089] “Step 310 also includes a corresponding act of issuing a second request that includes the formulated response (act 309). Act 309 can include issuing a second electronic request, which includes the formulated response, to access the service.” Further in [0031] where services/data/content are provided/accessed).
Regarding claim 24 (Original), Kaler in view of Wang and Shao teaches the method of claim 21, wherein responding to the request includes providing data (Kaler [0097] “When an appropriate response to an issued challenge is received, a message processor may process a request.”, [0089] “Step 310 also includes a corresponding act of issuing a second request that includes the formulated response (act 309). Act 309 can include issuing a second electronic request, which includes the formulated response, to access the service.” Further in [0031] where services/data/content are provided/accessed).
Regarding claim 25 (Currently Amended), Kaler in view of Wang and Shao teaches the method of claim 21, further comprising: setting a time for expiration of the answer token; invalidating the request when the time for expiration has elapsed; and when the time for expiration has not elapsed, determining whether the answer token is valid (Kaler [0098] “When a response is received, message processor 208 may decrypt an included authentication token using an appropriate key (e.g., a symmetric key). Decrypting an authentication token can reveal a type of challenge, an answer, and a time stamp (and thus there is little, if any, need to maintain these at message processor 208). A revealed time stamp may be compared to the current time to determine a length of time since a challenge was issued. If the length of time is within a specified threshold (e.g., 5 minutes) a request may be processed. If the length of time is not within the specified threshold a request may not be processed.”).
Regarding claim 26 (Original), Kaler in view of Wang and Shao teaches the method of claim 21, wherein the request passes as one or more cookies (Kaler [0016] “the client can formulate a response that includes the answer to the random number problem. The client can also formulate a response that includes the original request and the authentication token. Thus, the client may include all of the data for responding to a challenge within a formulated response.”, where the authentication token and the answer are interpreted as cookies, consistent with the interpretation in the instant application publication in [0025] “…with the first cookie corresponding to the answer token and the second cookie containing the generated (at 110) solution.”).
Regarding claim 27 (Original), Kaler in view of Wang and Shao teaches the method of claim 21, wherein the solution is embedded in a header of a request packet (Kaler Figure 5 510-520 532, further in [0089-0090]).
Regarding claim 28 (Original), Kaler in view of Wang and Shao teaches the method of claim 21, wherein the answer token is embedded in a header of a request packet (Kaler Figure 5 510-520 532, [0095] “An authentication token can be included along with the answer to increase the efficiency with which an answer can be verified. The authentication token can include state information for the issued challenge and/or the response.”, further in [0089-0090]).
Regarding claim 32 (Original), Kaler in view of Wang and Shao teaches the system of claim 31, comprising at least one of a distribution platform that performs the verification of the answer (Kaler [0015] “A challenge can also include an optional authentication token that includes, for example, an encrypted version of the answer to the random number problem.”, [0016] “the client can formulate a response that includes the answer to the random number problem. The client can also formulate a response that includes the original request and the authentication token. Thus, the client may include all of the data for responding to a challenge within a formulated response.”, [0098-0099] discloses the verification of the client device based on the answer and the revealed answer (from an authentication token), Figure 2 illustrates distributed environment where distributed application 208 perform the verification to the response).
Regarding claim 33 (Currently Amended), Kaler in view of Wang and Shao teaches the system of claim 31, wherein the answer is encrypted using aprivate key (Kaler [0015] “A challenge can also include an optional authentication token that includes, for example, an encrypted version of the answer, [0084] discloses encrypted in the answer with a symmetric key “…An authentication token can contain an encrypted type of challenge, encrypted timestamp, and/or encrypted answer using a symmetric key for a service”, further in [0098] “When a response is received, message processor 208 may decrypt an included authentication token using an appropriate key (e.g., a symmetric key). ”, examiner notes that the answer in the authentication token is encrypted utilizing a symmetric/secret key, which enables the processor 208 to eventual decrypt and compare to the received answer/solution from the client, examiner further notes that the private key in the specification of the instant application is only referenced in publication paragraph [0043] without any indication as to what the private key entails, e.g. is it part of the private/public key pair? or is it just a private/secret key associated with the verifying entity to decrypt the encrypted answer?, and further stated within the same paragraph that the a key in one embodiment be used for encryption and decryption, therefore, given the broadest reasonable interpretation, the private key in the claim is interpreted as a private/secret key associated with the verifying entity, furthermore, the concept of using a binary selection of symmetric or asymmetric key is obvious to be used by one of ordinary skill in the art).
Regarding claim 34 (Currently Amended), Kaler in view of Wang and Shao teaches the system of claim 33, wherein the system is configured such that the client device returns the encrypted answer along with a solution to a problem to any distribution platform that [[may]] is adapted to verify the client device based on the solution and the encrypted answer (Kaler [0015] “A challenge can also include an optional authentication token that includes, for example, an encrypted version of the answer to the random number problem.”, [0016] “the client can formulate a response that includes the answer to the random number problem. The client can also formulate a response that includes the original request and the authentication token. Thus, the client may include all of the data for responding to a challenge within a formulated response.”, [0098-0099] discloses the verification of the client device based on the answer and the revealed answer (from an authentication token), Figure 2 illustrates distributed environment where distributed application perform the verification to the response).
Regarding claim 35 (Original), Kaler in view of Wang and Shao teaches the system of claim 31, wherein new and different answers are generated for different client devices (Kaler [0013] discloses different types of challenges that can be used for different clients based on e.g. previously established context between the client and the server, which requires different types of answers, furthermore, the use of random value problem generates an random value as an answer for every verification as disclosed in [0025]).
Regarding claim 36 (Original), Kaler in view of Wang and Shao teaches the system of claim 32, wherein the answer is not stored in any device of the distribution platform (Kaler [0015] “… Thus, a server may include all the data for indicating a challenge to the client and all the data for determining if an appropriate response is received within an issued challenge. As such, there is no need to maintain this data at the server.”, [0016] “…the client may include all of the data for responding to a challenge within a formulated response. As such, there is no need to maintain this data at the client. ”).
Regarding claim 37 (Original), Kaler in view of Wang and Shao teaches the system of claim 31, wherein the client device is a network-enabled device (Kaler [0021] “FIG. 2 illustrates an example of a network architecture that can facilitate the performance of a challenge.”, further in [0029 and 0032]).
Regarding claim 38 (Currently Amended), Kaler in view of Wang and Shao teaches the system of claim 31, wherein the circuitry is further configured to: set a time for expiration of the answer token; invalidate the request when the time for expiration has elapsed; and when the time for expiration has not elapsed, determine whether the answer token is valid (Kaler [0098] “When a response is received, message processor 208 may decrypt an included authentication token using an appropriate key (e.g., a symmetric key). Decrypting an authentication token can reveal a type of challenge, an answer, and a time stamp (and thus there is little, if any, need to maintain these at message processor 208). A revealed time stamp may be compared to the current time to determine a length of time since a challenge was issued. If the length of time is within a specified threshold (e.g., 5 minutes) a request may be processed. If the length of time is not within the specified threshold a request may not be processed.”).
Regarding claim 40 (Original), Kaler in view of Wang and Shao teaches the system of claim 32, wherein the at least one distribution platform seeds a random number generator to avoid replication of an answer (Kaler [0025] discloses using a challenge type of a random number problem, where a digest of a random number is generated and included in the challenge as disclosed in [0075] given as an answer as disclosed in [0094]), and the answer is obfuscated by use of a private key (Kaler [0084] discloses encrypted in the answer with a symmetric key “…An authentication token can contain an encrypted type of challenge, encrypted timestamp, and/or encrypted answer using a symmetric key for a service”, further in [0098] “When a response is received, message processor 208 may decrypt an included authentication token using an appropriate key (e.g., a symmetric key). ”, examiner notes that the answer in the authentication token is encrypted utilizing a symmetric/secret key, which enables the processor 208 to eventual decrypt and compare to the received answer/solution from the client, examiner further notes that the private key in the specification of the instant application is only referenced in publication paragraph [0043] without any indication as to what the private key entails, e.g. is it part of the private/public key pair? or is it just a private/secret key associated with the verifying entity to decrypt the encrypted answer?, and further stated within the same paragraph that the a key in one embodiment be used for encryption and decryption, therefore, given the broadest reasonable interpretation, the private key in the claim is interpreted as a private/secret key associated with the verifying entity, furthermore, the concept of using a binary selection of symmetric or asymmetric key is obvious to be used by one of ordinary skill in the art).
Claims 22 and 30 are rejected under 35 U.S.C. 103 as being unpatentable over Kaler et. al. (US 20040139152 A1), hereinafter Kaler, in view of Wang (US 20140380418 A1) and Shao (US 20170180373 A1) and Saltz (US 7536722 B1).
Regarding claim 22 (Original), Kaler in view of Wang and Shao teaches the method of claim 21.
Kaler in view of Wang and Shao do not explicitly disclose the limitation below.
wherein responding to the request includes providing a verification token (Saltz discloses the user on a client device is authenticated once, and thereafter, the user’s SSO token enables the user client to access multiple servers/nodes without requiring authentication/verification, Col. 2 line 35-39 “…sending a username and password from a client to an authentication server for lightweight directory access protocol (LDAP) authentication wherein an authentication server sends a single sign-on (SSO) token to the client”, Col. 6 line 57-61 “SSO tokens allow a user to be authenticated once and access multiple servers that recognize and can confirm the validity of the SSO token, thereby allowing the user to avoid multiple authentication procedures across multiple servers.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Kaler in view of Wang and Shao to incorporate the teaching of Saltz to utilize the above feature, with the motivation of convenience and allowing the user to avoid multiple authentication procedures across multiple servers, as recognized by (Saltz Col. 6 line 57-61).
Regarding claim 30 (Original), Kaler in view of Wang and Shao teaches the method of claim 21.
Kaler in view of Wang and Shao does not explicitly disclose the verification token.
Saltz discloses further comprising generating a verification token upon verify the client device (Saltz discloses the user on a client device is authenticated once, and thereafter, the user’s SSO token enables the user client to access multiple servers/nodes without requiring authentication/verification, Col. 2 line 35-39 “…sending a username and password from a client to an authentication server for lightweight directory access protocol (LDAP) authentication wherein an authentication server sends a single sign-on (SSO) token to the client”, Col. 6 line 57-61 “SSO tokens allow a user to be authenticated once and access multiple servers that recognize and can confirm the validity of the SSO token, thereby allowing the user to avoid multiple authentication procedures across multiple servers.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Kaler in view of Wang and Shao to incorporate the teaching of Saltz to utilize the above feature, with the motivation of convenience and allowing the user to avoid multiple authentication procedures across multiple servers, as recognized by (Saltz Col. 6 line 57-61).
Claim 29 is rejected under 35 U.S.C. 103 as being unpatentable over Kaler et. al. (US 20040139152 A1), hereinafter Kaler, in view of Wang (US 20140380418 A1) and Shao (US 20170180373 A1) and Avetisov et. al. (US 20210044976 A1).
Regarding claim 29 (Currently Amended), Kaler in view of Wang and Shao teaches the method of claim 21.
Kaler in view of Wang and Shao does not explicitly disclose but Avetisov discloses processing [[of the]] a unique identifier of the client device for verification, wherein the processing of the unique identifier includes determining the unique identifier (Avetisov [0120] “As the identifier can uniquely identify the client device 135 from other client devices, the relying party server 145 can determine to grant the client device 135 access if the token presented by the client device matches a valid token in the repository 160 and an identifier determined for the client device matches the identifier associated with the valid token in the repository 160.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Kaler in view of Wang and Shao to incorporate the teaching of Avetisov to utilize the above feature, with the motivation of having users authenticating with mobile devices to a server, as recognized by (Avetisov Abstract ).
Claim 39 is rejected under 35 U.S.C. 103 as being unpatentable over Kaler et. al. (US 20040139152 A1), hereinafter Kaler, in view of Wang (US 20140380418 A1) and Shao (US 20170180373 A1) and Hauser (US 20210217106 A1).
Regarding claim 39 (Original), Kaler in view of Wang and Shao teaches the system of claim 31.
Kaler discloses [0062] “FIG. 2 may be SOAP messages that use any of a number of lower level protocols, such as, for example, HyperText Transfer Protocol ("HTTP") or Direct Internet Message Encapsulation ("DIME") as a transport.”, however, Kaler in view of Wang and Shao do not explicitly disclose URL.
Hauser discloses wherein the request includes a Uniform Resource Locator (Hauser [0244] “The platform 150 can accept various types of questions and/or answer formats. For example, the platform 150 can enable users to input one or more multiple-choice questions (e.g., a question having a question statement, followed by two or more discrete answers that can be selected by a user requesting access). As another example, the platform 150 can enable users to input one or more short answer or essay questions (e.g., a question having a question statement, followed by input box that accepts textual input from a user requesting access). As another example, the platform 150 can enable users to input one or more questions requiring a one-word response (e.g., a question having a question statement, followed by input box that accepts single-word textual input from a user requesting access). As another example, the platform can enable users to input a numeric answer. As another example, the platform can enable users to input an answer in the form of a date. As another example, the platform can enable users to input an answer in the form of “yes” or “no” response. As another example, the platform can enable users to input an answer in the form of a web address (e.g., a URL). As another example, the platform can enable users to input an answer in the form of a percentage.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Kaler in view of Wang and Shao to incorporate the teaching of Hauser to utilize the above feature, this enable different formats that can be used as a form of an answer/solution to a challenge/question, which would make it obvious to try, and further enable access based on certain requirements as recognized by Hauser [0243].
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Ambady (US 20070101358 A1) discloses in [0041-0042] and Figure 2 generating a random answer and follow with a question generation.
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 BASSAM A NOAMAN whose telephone number is (571)272-2705. The examiner can normally be reached Monday-Friday 8:30 AM-5:00PM.
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, Eleni A. Shiferaw can be reached at (571) 272-3867. 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.
/BASSAM A NOAMAN/Primary Examiner, Art Unit 2497
