Remarks
Claims 1-19 and 21 are pending.
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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 5/18/2026 has been entered.
Response to Arguments
Applicant's arguments filed 5/18/2026 have been fully considered but they are not persuasive.
Applicant, under a heading reading “Completeness and Clarity of Examiner’s Action” alleges that the previous office action was deficient (i.e. “As this was not done in the first Office Action on the merits…”). However, there is no requirement in the MPEP that there are allowable claims or even allowable subject matter in any given application, let alone that the Examiner has to tell Applicant how to make non-allowable claims allowable. Applicant is respectfully requested to refrain from making erroneous statements that may lead one to incorrectly infer that the office action is deficient.
The Examiner suggests that, since the previous claims were rejected, Applicant amend the claims to include additional subject matter that Applicant believes would make the claims allowable. Instead, claim 1 has been amended solely to remove subject matter. This is still not allowable and no claim currently pending is allowable.
With respect to the last paragraph on page 9 of the response dated 5/18/2025, Applicant fails to define what being unavailable even means. The closest Applicant gets is by arguing “Ben Ezra’s situation is fundamentally different from a situation where an available challenge is successfully provided and executed, but the user device simply fails to pass the security test.” This appears to mean that Applicant believes that “a situation where an available challenge is successfully provided and executed, but the user device simply fails to pass the security test” is within the scope of a challenge being unavailable for a client device, since Applicant is arguing that the 102 reference is “fundamentally different” from this. To the contrary, in at least some embodiments, Ben Ezra discloses exactly this. For example, paragraph 58 discloses generating a challenge. Paragraph 59 then describes the client failing the challenge. Paragraph 60 then describes generating a new challenge and/or escalating through a series of challenges. Therefore, Ben Ezra discloses that which Applicant argues Ben Ezra is fundamentally different from.
Moreover, claim 1, for example, does not actually provide any more narrowing scope for being unavailable than just that: “detecting that the first elevated security challenge is unavailable for the client device”. Thus, any detecting of the challenge being unavailable for the client device is within the scope of this, including the device failing a challenge (i.e. the challenge cannot be used for authenticating the device and is, thus, unavailable to the device), having an expired previous challenge, having a previous challenge that has been updated, and the like. Other than the above (“Ben Ezra’s situation is fundamentally different from a situation where an available challenge is successfully provided and executed, but the user device simply fails to pass the security test”), Applicant never appears to even attempt to define what this detection actually entails or how any specific form of detection is different from that which is within Ben Ezra. Thus, it is clear that Ben Ezra discloses the detecting limitation as noted above.
In the first paragraph on page 10 of the response dated 5/18/2026, Applicant appears to take issue with the Examiner’s use of the word “perhaps” in the rejection of the detecting limitation, even going so far as to erroneously allege that “the Examiner’s rationale relies on impermissible speculation … The Examiner’s use of the word ‘perhaps’ and the presentation of hypothetical scenarios constitute an admission that Ben Ezra does not explicitly disclose detecting that a challenge is unavailable”. The word “perhaps” in the rejection is used to identify examples of how the subject matter is met by the reference. The Examiner notes that Applicant is blatantly wrong in alleging that “use of the word ‘perhaps’ and the presentation of hypothetical scenarios constitute an admission that Ben Ezra does not explicitly disclose detecting that a challenge is unavailable”. No hypothetical scenarios were describes, but rather, explicit disclosures from the references. The Examiner has added more examples of how this subject matter is met by the reference in the below rejections. The word “perhaps” has been removed as well so as to allow Applicant to avoid Applicant’s erroneous interpretation.
With respect to the end of this paragraph and the next paragraph, Applicant fails to provide any actual argument here and, rather, just provides general allegations. Applicant's arguments fail to comply with 37 CFR 1.111(b) because they amount to a general allegation that the claims define a patentable invention without specifically pointing out how the language of the claims patentably distinguishes them from the references. To the contrary,
Ben Ezra discloses …
…
Detecting that the first elevated security challenge is unavailable for the client device (Exemplary Citations: for example, Abstract, Paragraphs 31-41, 44, 46, 50-53, 55, 57, 58, 59-66, and associated figures; as examples, device fails first challenge (e.g., paragraph 59) or it is determined to overlook certain challenge types because they would not work for the particulars of the device (e.g., paragraph 57 discusses a variety of parameters that can be used to determine appropriate challenges to issue), as examples. Other examples include a challenge and its corresponding authentication no longer being available to a client after the expiration of a timer (e.g., the aging mechanism described in paragraphs 55 and 61), thus requiring a new challenge, since the old one is no longer available, paragraph 59-60 discussion of failing the challenge if no response is received from the client (thus the challenge was unavailable for the client) and moving on to another challenge in relation to an escalation policy, and paragraph 50’s discussion of updating challenges, meaning previous challenges are no longer available, for example. Any generating of a new challenge is performed due to the previous challenge being unavailable, and the claim does not provide anything more narrow than the challenge being unavailable for the client device. As one easy to follow example, paragraph 59 states At S450, a message (or a token) is received from the client machine in response to the script code. At S460, the content of the message (or a token) is analyzed to determine if the challenged passed or failed. In a non-limiting implementation, the received message explicitly designates if the message failed or passed. It should be noted that, if no message is received during a predefined time interval, the challenged is considered failed. The waiting time for receiving a message may be preconfigured and can be set to a typical round trip time (RTT) between the protected server and security system);
Based on detecting that the first elevated security challenge is unavailable for the client device, selecting, for the event request, a second elevated security challenge that is different from the first elevated security challenge (Exemplary Citations: for example, Abstract, Paragraphs 31-41, 44, 46, 50-53, 57, 58, 60-66, and associated figures; moving on to a second challenge (e.g., in an escalation policy) or simply generating another kind of challenge, for example. Please see above for additional discussion, including specific exemplary paragraphs for different options, for example. As one easy to follow example, paragraph 60 states If the received message indicates a passed challenge, execution continues with S470; otherwise, execution proceeds to S480, where the received request is determined to be malicious and the received request is terminated or suspended. Optionally at S485, a new challenge may be generated and send to the client machine according to a predefined escalation policy. An escalation policy defines a certain order in which to perform a set of different challenges based on an attack's type, properties of the client (attacker), the entity to be protected, and so on. As a non-limiting example, such an escalation scenario may define a first challenge as a zero-window size challenge, a second challenge is a special object type of AHBB challenge, and the third challenge would require an input from the user. In an embodiment, S485 may also include gathering and reporting details about the client machine sending the malicious request. Such details include, but are not limited to, an IP address, a geographical location, type of the machine, request type, and the like); and
Redirecting network communications of the client device (to the security challenge platform) to cause the client device to display the second elevated security challenge (Exemplary Citations: for example, Abstract, Paragraphs 31-41, 45-54, 58, 60, and associated figures; redirecting to challenge machine for challenging the client via a variety of challenges, such as zero window size challenges, user input challenges, or the like, for example. As one easy to follow example, paragraph 53 states the verification circuit 155 in the security system 150 is configured to send a redirect script to the client 110 and/or to the attack tool 140 redirecting the client's browser to one of the challenge machines 370. A redirect script may be realized as an AJAX call. In an embodiment, the redirect script includes a set of parameters required to generate an authentication object by the challenge machine 370 to which the client is directed to. The set of parameters may include, for example, an IP address of the client, a time stamp, a current port number, and the like. The authentication object may be, but is not limited to, a cookie, a token, or any other type of data structure that can carry the information discussed in greater above).
Examiner’s Note
For the below rejections, parentheses are used to designate subject matter that is within some claims but has been explicitly removed from others via the amendment dated 5/18/2026. This subject matter is still being rejected for at least any claims that it is relevant to. For any subject matter that was present previously but removed from any claims, the previous rejection(s) also provide rejections of such subject matter and such rejections are carried through here.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claim 13 is rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claim 13 states “decrypting the encrypted logic string using the second security challenge to determine parameters for defining the second elevated security challenge”. The application as originally filed does not provide basis for decrypting the encrypted logic string using the second security challenge to determine parameters for defining the second elevated security challenge. In particular, no decrypting of the encrypted logic string using a second challenge that has yet to be defined until after such decryption is found in the application as originally filed.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-7 and 21 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 1 recites the limitation "the client device" in the detecting limitation. There is insufficient antecedent basis for this limitation in the claim. Claims 2-7 and 21 are rejected at least based on their dependencies.
Claim 13 states “decrypting the encrypted logic string using the second security challenge to determine parameters for defining the second elevated security challenge”. However, it is unclear how the logic string can be decrypted using the second challenge in order to define the second challenge, since the second challenge has not been defined yet in order to provide for any information useful in decryption.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1, 2, 4-16, 18, 19, and 21 are rejected under 35 U.S.C. 102(a)(1) and/or 102(a)(2) as being anticipated by Ben Ezra (U.S. Patent Application Publication 2016/0359904).
Regarding Claim 1,
Ben Ezra discloses a method comprising:
Receiving (from a client device) an event request indicating a requested network event from among a plurality of network events (hosted by an inter network facilitation system) (Exemplary Citations: for example, Abstract, Paragraphs 30, 45, 53, 57, 61, and associated figures; request from client device for protected server, for example. As one easy to follow example, paragraph 57 states that a request to access a resource of a protected server is received from a client machine);
Determining (utilizing a logic platform of the inter network facilitation system that) the event request warrants elevated client device interaction to maintain data security (Exemplary Citations: for example, Abstract, Paragraphs 31, 38, 44, 53, 57, 61, and associated figures; determining whether to generate a challenge and/or what type of challenge, to generate, for example. As one easy to follow example, paragraph 57 states a check is made to determine if an AHBB challenge should be generated. The determination is based on a plurality of risk parameters and/or load parameters that can be gathered by the security system or received from external systems. The risk parameters include, for example, a black list of known malicious clients (identified by P addresses, fingerprints, etc.), a list of trusted clients per IP address, a reputation scores per IP address or geographical region, application layer parameters (e.g., clients' cookies), a client unique identification (ID) token, an affiliation of a client (e.g., a client belongs to a trusted company or is an internal client of the organization), parameters collected from external and internal client authentication services, geo analysis (e.g., the origin of a client's traffic in comparison to other clients), a type of content and/or application accessed by the client, ongoing attack indications, and so on. The load parameters relate to the protected server, for example, current load, available computing and/or networking resources, and the like. If S420 results with a “Yes” answer, execution continues with S430; otherwise, execution ends. If S420 is not performed, execution proceeds S430);
Based on determining that the event request warrants elevated client device interaction, generating (utilizing a security challenge platform of the inter network facilitation system) a first elevated security challenge that is adapted to security data associated with the event request based on data (from the logic platform) (Exemplary Citations: for example, Abstract, Paragraphs 31-41, 44, 46, 50-53, 57, 58, 60-66, and associated figures; generating a challenge based on the above, for example. As one easy to follow example, paragraph 58 states At S430, at least one AHBB challenge is generated to detect a headless browser. The AHBB challenge is coded or encapsulated in a script code, such as, but not limited to JavaScript. The execution of S430 is described in detail above. At S440, the generated script is sent to the client machine);
Detecting that the first elevated security challenge is unavailable for the client device (Exemplary Citations: for example, Abstract, Paragraphs 31-41, 44, 46, 50-53, 55, 57, 58, 59-66, and associated figures; as examples, device fails first challenge (e.g., paragraph 59) or it is determined to overlook certain challenge types because they would not work for the particulars of the device (e.g., paragraph 57 discusses a variety of parameters that can be used to determine appropriate challenges to issue), as examples. Other examples include a challenge and its corresponding authentication no longer being available to a client after the expiration of a timer (e.g., the aging mechanism described in paragraphs 55 and 61), thus requiring a new challenge, since the old one is no longer available, paragraph 59-60 discussion of failing the challenge if no response is received from the client (thus the challenge was unavailable for the client) and moving on to another challenge in relation to an escalation policy, and paragraph 50’s discussion of updating challenges, meaning previous challenges are no longer available, for example. Any generating of a new challenge is performed due to the previous challenge being unavailable, and the claim does not provide anything more narrow than the challenge being unavailable for the client device. As one easy to follow example, paragraph 59 states At S450, a message (or a token) is received from the client machine in response to the script code. At S460, the content of the message (or a token) is analyzed to determine if the challenged passed or failed. In a non-limiting implementation, the received message explicitly designates if the message failed or passed. It should be noted that, if no message is received during a predefined time interval, the challenged is considered failed. The waiting time for receiving a message may be preconfigured and can be set to a typical round trip time (RTT) between the protected server and security system);
Based on detecting that the first elevated security challenge is unavailable for the client device, selecting, for the event request, a second elevated security challenge that is different from the first elevated security challenge (Exemplary Citations: for example, Abstract, Paragraphs 31-41, 44, 46, 50-53, 57, 58, 60-66, and associated figures; moving on to a second challenge (e.g., in an escalation policy) or simply generating another kind of challenge, for example. Please see above for additional discussion, including specific exemplary paragraphs for different options, for example. As one easy to follow example, paragraph 60 states If the received message indicates a passed challenge, execution continues with S470; otherwise, execution proceeds to S480, where the received request is determined to be malicious and the received request is terminated or suspended. Optionally at S485, a new challenge may be generated and send to the client machine according to a predefined escalation policy. An escalation policy defines a certain order in which to perform a set of different challenges based on an attack's type, properties of the client (attacker), the entity to be protected, and so on. As a non-limiting example, such an escalation scenario may define a first challenge as a zero-window size challenge, a second challenge is a special object type of AHBB challenge, and the third challenge would require an input from the user. In an embodiment, S485 may also include gathering and reporting details about the client machine sending the malicious request. Such details include, but are not limited to, an IP address, a geographical location, type of the machine, request type, and the like); and
Redirecting network communications of the client device (to the security challenge platform) to cause the client device to display the second elevated security challenge (Exemplary Citations: for example, Abstract, Paragraphs 31-41, 45-54, 58, 60, and associated figures; redirecting to challenge machine for challenging the client via a variety of challenges, such as zero window size challenges, user input challenges, or the like, for example. As one easy to follow example, paragraph 53 states the verification circuit 155 in the security system 150 is configured to send a redirect script to the client 110 and/or to the attack tool 140 redirecting the client's browser to one of the challenge machines 370. A redirect script may be realized as an AJAX call. In an embodiment, the redirect script includes a set of parameters required to generate an authentication object by the challenge machine 370 to which the client is directed to. The set of parameters may include, for example, an IP address of the client, a time stamp, a current port number, and the like. The authentication object may be, but is not limited to, a cookie, a token, or any other type of data structure that can carry the information discussed in greater above).
Regarding Claim 8,
Claim 8 is a system claim that corresponds to method claim 1 and is rejected for the same reasons.
Regarding Claim 15,
Claim 15 is a medium claim that corresponds to method claim 1 and is rejected for the same reasons.
Regarding Claim 2,
Ben Ezra discloses that determining that the event warrants elevated client device interaction comprises (utilizing the logic platform) to determine a security category for the event request from among a plurality of security categories comprising an allow category, a deny category, and an elevate category (Exemplary Citations: for example, Abstract, Paragraphs 31, 38, 44, 53, 55, 57, 61, and associated figures; white list, black list, permanently blocked entities, client from which future requests will be allowed for a period of time, requests for which challenges are required, etc., as examples).
Regarding Claim 9,
Claim 9 is a system claim that corresponds to method claim 2 and is rejected for the same reasons.
Regarding Claim 16,
Claim 16 is a medium claim that corresponds to method claim 2 and is rejected for the same reasons.
Regarding Claim 4,
Ben Ezra discloses selecting the second elevated security challenge by utilizing client device characteristics of the client device to determine a capability of the client device to operate the second elevated security challenge (Exemplary Citations: for example, Abstract, Paragraphs 31-41, 44, 46, 50-53, 57, 58, 60-66, and associated figures; challenge based on client characteristics, such as IP address, fingerprint, reputation score, geographical region, cookies, IDs, tokens, etc., as examples).
Regarding Claim 11,
Claim 11 is a system claim that corresponds to method claim 4 and is rejected for the same reasons.
Regarding Claim 18,
Claim 18 is a medium claim that corresponds to method claim 4 and is rejected for the same reasons.
Regarding Claim 5,
Ben Ezra discloses that providing the second elevated security challenge for display comprises:
Redirecting network communications of the client device from an event workflow comprising a series of user interfaces associated with the event request to a (second) security challenge workflow comprising one or more user interfaces associated with the second elevated security challenge (Exemplary Citations: for example, Abstract, Paragraphs 5, 11, 13, 31-41, 45-54, 58, 60, 61, and associated figures; redirecting to challenge from the normal stream of requests (where a client can send multiple requests for multiple webpages, for example), for example); and
Upon detecting completion of the second security challenge workflow, returning network communications of the client device to the event workflow for the event request (Exemplary Citations: for example, Abstract, Paragraphs 42, 43, 54, 55, 59-61, and associated figures; after challenge complete, relaying request to the intended server or having client re-request, or having additional requests authorized without additional challenges, as examples).
Regarding Claim 12,
Claim 12 is a system claim that corresponds to method claim 5 and is rejected for the same reasons.
Regarding Claim 19,
Claim 19 is a medium claim that corresponds to method claim 5 and is rejected for the same reasons.
Regarding Claim 6,
Ben Ezra discloses that determining that the event request warrants elevated client device interaction comprises:
Generating (using the logic platform) an encrypted logic string comprising event request data indicating a user account information, a challenge type for the second elevated security challenge, and an event identification for the event request (Exemplary Citations: for example, Abstract, Paragraphs 31-41, 44, 46, 50-53, 57, 58, 60-66, and associated figures; redirect to certain server for challenge type with parameters, such as IP address, fingerprint of client, any identification of event, such as timestamp, redirect script, request itself, etc.; please see cited sections as well as incorporated application #14/520,955 (incorporated by reference in paragraph 51 of Ben Ezra), issued as U.S. Patent 9,825,928 (Exemplary Citations: for example, Abstract, Column 7, lines 29-63; Column 8, lines 20-52; Column 9, lines 9-29; Column 10, lines 3-25; Column 10, lines 53-61; and associated figures; showing a variety of parameters corresponding to the above, as noted above, being encrypted in the redirect script to the challenge machine, decrypted by the challenge machine, and used in generation of the challenge, for example), for example); and
Decrypting the encrypted logic string using a second security challenge platform to determine parameters for defining the second elevated security challenge (Exemplary Citations: for example, Abstract, Paragraphs 31-41, 44, 46, 50-53, 57, 58, 60-66, and associated figures; as just explained, for example).
Regarding Claim 13,
Claim 13 is a system claim that corresponds to method claim 6 and is rejected for the same reasons.
Regarding Claim 7,
Ben Ezra discloses detecting completion of the second elevated security challenge via the client device (Exemplary Citations: for example, Abstract, Paragraphs 42, 43, 54, 55, 59-61, and associated figures; response, for example); and
Based on completion of the second elevated security challenge, executing the requested network event associated with the event request (Exemplary Citations: for example, Abstract, Paragraphs 42, 43, 54, 55, 59-61, and associated figures; allowing communication with the intended server, for example).
Regarding Claim 14,
Claim 14 is a system claim that corresponds to method claim 7 and is rejected for the same reasons.
Regarding Claim 10,
Ben Ezra discloses determine a challenge type for the first elevated security challenge based on data (from the logic platform) (Exemplary Citations: for example, Abstract, Paragraphs 31-41, 44, 46, 50-53, 57, 58, 60-66, and associated figures);
Detect that the client device is incapable of operating the challenge type (Exemplary Citations: for example, Abstract, Paragraphs 31-41, 44, 46, 50-53, 57, 58, 60-66, and associated figures; as examples device fails first challenge or it is determined to overlook certain challenge types because they would not work for the particulars of the device, as examples (as well as other examples above)); and
Based on detecting that the client device is incapable of operating the challenge type, select the second elevated security challenge for the event request (Exemplary Citations: for example, Abstract, Paragraphs 31-41, 44, 46, 50-53, 57, 58, 60-66, and associated figures; moving on to a second challenge (e.g., in an escalation policy) or simply generating another kind of challenge, for example).
Regarding Claim 21,
Ben Ezra discloses that the event request is one of a transfer of assets from one digital account to another, a deposit into a digital account, a withdrawal from a digital account, a credit check on a digital account, a purchase made by a digital account, or other recordable occurrence (Exemplary Citations: for example, Abstract, Paragraphs 30, 45, 53, 57, 61, and associated figures; any event is a recordable occurrence, for example).
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 3 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Ben Ezra in view of Korhonen (U.S. Patent Application Publication 2012/0005523).
Regarding Claim 3,
Ben Ezra discloses determining a challenge type for the first elevated security challenge based on data (from the logic platform) (Exemplary Citations: for example, Abstract, Paragraphs 31-41, 44, 46, 50-53, 57, 58, 60-66, and associated figures; determining any of the challenge types, for example);
Detecting that an authentication entity associated with the challenge type is unable to communicate with the client device (Exemplary Citations: for example, Abstract, Paragraphs 31-41, 44, 46, 50-53, 57, 58, 60-66, and associated figures; if authentication fails or if one authentication mechanism has been hot swapped or updated or the like, for example); and
Based on detecting that the authentication entity is unable to communicate with the client device, selecting the second elevated security challenge for the event request (Exemplary Citations: for example, Abstract, Paragraphs 31-41, 44, 46, 50-53, 57, 58, 60-66, and associated figures; using another challenge type based on those that are available and/or the escalation policy, for example);
But does not explicitly disclose that the authentication entity comprises a vendor network.
Korhonen, however, discloses that the authentication entity comprises a vendor network (Exemplary Citations: for example, Abstract, Paragraphs 11-22, 24-35, 87, and associated figures; sub-realm and corresponding authentication server not available, for example);
Detecting that a vendor network associated with the challenge type is unable to communicate with the client device (Exemplary Citations: for example, Abstract, Paragraphs 11-22, 24-35, 87, and associated figures; sub-realm and corresponding authentication server not available, for example); and
Based on detecting that the vendor network is unable to communicate with the client device, selecting the second elevated security challenge for the event request (Exemplary Citations: for example, Abstract, Paragraphs 11-22, 24-35, 87, and associated figures; falling back to another, for example). It would have been obvious to one of ordinary skill in the art at the time of applicant’s invention, which is before any effective filing date of the claimed invention, to incorporate the authentication fallback techniques of Korhonen into the challenge response system of Ben Ezra in order to allow the system to automatically detect failures and properly fallback to another authentication/challenge mechanism, to ensure that even with device and network failures, authentications can still occur, and/or to increased security in the system.
Regarding Claim 17,
Claim 17 is a medium claim that corresponds to method claim 3 and is rejected for the same reasons.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Jeffrey D Popham whose telephone number is (571)272-7215. The examiner can normally be reached Monday through Friday 9:00-5:30.
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, Jeffrey Nickerson can be reached at (469) 295-9235. 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.
/Jeffrey D. Popham/Primary Examiner, Art Unit 2432
Prosecution Insights