DETAILED ACTION
Claims 1-4 are presented for examination.
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 12/03/2025 has been entered.
Priority
Applicant has not complied with one or more conditions for receiving the benefit of an earlier filing date under 35 U.S.C. 119(e) as follows:
The later-filed application must be an application for a patent for an invention which is also disclosed in the prior application (the parent or original non-provisional application or provisional application); the disclosure of the invention in the parent application and in the later- filed application must be sufficient to comply with the requirements of the first paragraph of 35' U.S.C. 112. See Transco Products, Inc. v. Performance Contracting, Inc., 38 F.3d 551,32 USPQ2d 1077 (Fed. Cir. 1994). In the present application, support for the following limitations is lacking in the provisional applications:
The limitations e.g. host agent, virtual machine, storage data object, tier level, reservation repository etc are not supported by current spec, therefore, examiner will consider the priority date back to provisional application (62/596,105) dated: 12/07/2017.
Terminal Disclaimer
The terminal disclaimer filed on 06/12/2025 has been reviewed and is accepted. The terminal disclaimer has been recorded.
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 .
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.
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.
The factual inquiries 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.
Claims1-4 are rejected under 35 U.S.C. 103 as being unpatentable over Kuperman et al. (US Patent Application No. 20180278624) (Hereinafter Kuperman) in view of Challener et al. (US Patent Application No. 20030041254) (Hereinafter Challener).
As per claim 1, Kuperman discloses a system for detecting and mitigating forged authentication attacks, comprising:
a memory storing instruction to be executed by one or more hardware processors (fig 4); and
one or more hardware processors configured to execute the instructions stored in a memory wherein the instructions, when executed by the one or more processors, cause the system to (fig 4):
receive a plurality of first authentication attributes associated with a network request (fig 2, para 16, API request with the token (e.g., attributes of the token which may be represented by one or more values) to include (e.g., present) the token with the API request; 5A-6 fig 1, claims 2,5,6, para 85, future requests processing 532. verifying the presented token based on attributes of the presented token comprises: generating, by the proxy, a first hash from one or more first attributes of the presented token; comparing the first hash to a second attribute of the presented token of the second API request; and verifying the token if the first hash generated by the proxy matches the second attribute, where the second attribute is a second hash generated by the client device);
calculate a cryptographic hash of each first authentication attribute (para 77, token attributes may include a UID, timestamp, and hash of the UID and timestamp.);
store the cryptographic hashes of the first authentication attributes in a database of hashes object (fig 5B, para 85, may store the verified token 531 for an authenticated client to simplify future requests processing);
receive a request for access to a service accompanied by a plurality of second authentication attributes (5A-6 fig 1, claims 2,5,6, para 85, future requests processing 532. verifying the presented token based on attributes of the presented token comprises: generating, by the proxy, a first hash from one or more first attributes of the presented token; comparing the first hash to a second attribute of the presented token of the second API request; and verifying the token if the first hash generated by the proxy matches the second attribute, where the second attribute is a second hash generated by the client device);
select a subset of the plurality of the second authentication attributes (5A-6 fig 1, claims 2,5,6, para 85, future requests processing 532. verifying the presented token based on attributes of the presented token comprises: generating, by the proxy, a first hash from one or more first attributes of the presented token; comparing the first hash to a second attribute of the presented token of the second API request; and verifying the token if the first hash generated by the proxy matches the second attribute, where the second attribute is a second hash generated by the client device);
calculate a cryptographic hash of each of the selected second authentication attributes (5A-6 fig 1, claims 2,5,6, para 85, future requests processing 532. verifying the presented token based on attributes of the presented token comprises: generating, by the proxy, a first hash from one or more first attributes of the presented token; comparing the first hash to a second attribute of the presented token of the second API request; and verifying the token if the first hash generated by the proxy matches the second attribute, where the second attribute is a second hash generated by the client device);
determine whether the request for access [is forged] by comparing the cryptographic hashes of the selected second authentication attributes with the cryptographic hashes of the first authentication attributes stored in the database of hashes to determine whether each cryptographic hash of the selected second authentication attribute already exists in the database (5A-6 fig 1, claims 2,5,6, para 85, future requests processing 532. verifying the presented token based on attributes of the presented token comprises: generating, by the proxy, a first hash from one or more first attributes of the presented token; comparing the first hash to a second attribute of the presented token of the second API request; and verifying the token if the first hash generated by the proxy matches the second attribute, where the second attribute is a second hash generated by the client device); and
where a cryptographic hash of a second authentication attribute does not exist in the database (5A-6 fig 1, claims 2,5,6, para 85, future requests processing 532. verifying the presented token based on attributes of the presented token comprises: generating, by the proxy, a first hash from one or more first attributes of the presented token; comparing the first hash to a second attribute of the presented token of the second API request; and verifying the token if the first hash generated by the proxy matches the second attribute, where the second attribute is a second hash generated by the client device).
Kuperman does not explicitly disclose generate a notification that the request for access may be forged. However, Challener discloses generate a notification that the request for access may be forged (para 4, If the Hash values do not compare, a tampering notification is issued).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Kuperman and Challener. The motivation would have been to build the network that provide endpoint security solutions (both hardware and software based).
As per claim 2, claim is rejected for the same reasons and motivation as claim 1, above. In addition, Kuperman discloses, wherein the instructions, when executed by the one or more hardware processors, cause the system to:
retrieve a plurality of predefined rules from a data store upon detection of a forged request for access (para 50, token store 219 may include one or more rules; para 56, the verification of a presented token fails interpreted as forged request); and
execute commands as dictated in each retrieved predefined rule (para 50, challenge/response rule provides a first line of defense against unauthorized applications ).
As per claims 3-4, claims are rejected for the same reasons and motivations as claim 1-2, above.
Response to Arguments
Applicant’s arguments with respect to amended claims have been considered but are moot because of the new ground of rejection. Please see the rejection above.
Conclusion
Please see the attached PTO-892 for the prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MOHAMMAD A SIDDIQI whose telephone number is (571)272-3976. The examiner can normally be reached Monday-Friday.
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, Carl G Colin can be reached at 571-272-3862. 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.
/MOHAMMAD A SIDDIQI/Primary Examiner, Art Unit 2493