Remarks
Claims 1-20 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 .
Response to Arguments
Applicant's arguments filed 7/9/2025 have been fully considered but they are not persuasive.
Applicant alleges “For example, Ezra fails to disclose” and copies in 4 of 6 limitations in claim 1, totaling 10 lines of the claim. 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, these 4 limitations are met by Ben Ezra as follows:
Based on determining that the event request warrants elevated client device interaction, generating, utilizing a security challenge platform of the internetwork 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);
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, 57, 58, 60-66, and associated figures; perhaps 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); and
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); 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).
Applicant then appears to quote a portion of Ben Ezra and provides the same block argument with respect to more than half of claim 1 as above, with no actual argument. 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.
Applicant then admits that Ben Ezra “describes determining that an AHBB challenge should be generated based on risk parameters (e.g., malicious clients, trusted client IP addresses) … also describes ‘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), and the entity to be protected.’” The Examiner thanks Applicant for such understanding.
Applicant then provides the same block argument with respect to more than half of claim 1 as above, with no actual argument. 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.
Applicant also appears to provide merely general allegations and block arguments for Korhonen. 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.
Claim Objections
Claim 5 is objected to because of the following informalities:
Claim 5 refers to “the elevated security challenge” in the first limitation. It is unclear which of the multiple elevated security challenges is attempting to be referenced.
Claim 5 refers to “a second security challenge workflow” in the second limitation. However, no first security challenge workflow is present. Thus, there cannot be a second workflow. Claims 12 and 19 have the same issue
Appropriate correction is required.
Claim Rejections - 35 USC § 112
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.
Claim 13 is 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 13 recites the limitation "the second security challenge platform" in the final limitation. There is insufficient antecedent basis for this limitation in the claim.
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, and 18-20 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 internetwork 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);
Determining, utilizing a logic platform of the internetwork 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);
Based on determining that the event request warrants elevated client device interaction, generating, utilizing a security challenge platform of the internetwork 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);
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, 57, 58, 60-66, and associated figures; perhaps 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); and
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); 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).
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 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 20,
Claim 20 is a medium 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; perhaps 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); 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).
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
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 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