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 .
DETAILED ACTION
Response to Arguments
Applicant's arguments filed 4/8/2026 have been fully considered, and are persuasive, and the previously pending rejections have been withdrawn responsive to the above noted arguments and accompanying amendments. However, after further search and consideration, a new grounds of rejection has been made based on the teachings and suggestions of extract_hashes (extract_hashes. https://github.com/BRDumps/extract-hashes. (Year: 2014)) in view of Park (Park, Jun-U., et al. "Softregex: Generating regex from natural language descriptions using softened regex equivalence." Proceedings of the 2019 conference on empirical methods in natural language processing and the 9th international joint conference on natural language processing (EMNLP-IJCNLP). (Year: 2019)).
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.
Claims 1, 4, 8, 9, 11, 14, 18, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over extract_hashes (extract_hashes. https://github.com/BRDumps/extract-hashes. (Year: 2014)) in view of Park (Park, Jun-U., et al. "Softregex: Generating regex from natural language descriptions using softened regex equivalence." Proceedings of the 2019 conference on empirical methods in natural language processing and the 9th international joint conference on natural language processing (EMNLP-IJCNLP). (Year: 2019)) and Vandanapu (US-11550949-B2).
Regarding claim 1, extract_hashes shows a method comprising:
determining whether text data includes a string with potentially hashed information (pg. 2 lines 9-12, pg. 2 lines 48-73, discussing an input file’s contents all being placed into the string “source_file_contents”) based on non-hashed information in the text (pg. 2 lines 9-11 and lines 62-73 where all the text data, including non-hashed data, is evaluated and hashes (all of which are merely ‘potential’ hashes given confirming data is a hash requires visibility into creation of the hash (i.e., seeing the hashing process performed) which is lacking when only provided text data like the input file of extract_hashes)), include hashed strings or non-hashed strings based in part on a context that includes non-hashed data (pg. 2 lines 9-11 and lines 62-73; the hashed data is extracted and identified based on the evaluation of the entire file contents, where pg. 2 lines 9-11 and pg. 2 lines 69-73 implies the input file contains non-hashed content and hashed content, and the hashed content alone is subject to the “extract” process); applying a filter, in response to determining that the string includes potentially hashed information, to the string to remove data from the string that cannot be a result of hashes (pg. 2 lines 9-12 and 70-73; where the determined hash results are extracted from an input file, leaving the non-hashed data in said input file, and the hash-only data is then stored in an output file; the filters are shown in the regex_list of pg. 2 lines 47 - 58), sending the string, after the filter is applied, to a repository (pg. 2 lines 9-12 and 70-73, the results file storage location acting as the repository).
extract_hashes does not show where the determining is using a machine learning trained model, the machine learning trained model being a natural language model trained using training data including labels indicating respective portions of the training data and using the trained model. Park shows where the determining is using a machine learning trained model, the machine learning trained model being a natural language model trained using training data including labels indicating respective portions of the training data (pg. 1 L34-L58, pg. 1 R24 – pg. 2 L11), and using the trained model (pg. 3, R3-R8).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the text analysis and hash-aware matching of extract_hashes with the ML utilization of Park in order to leverage the well-known advantages, including automation capability, of ML while also ensuring the ML training time is kept at a reduced level (Park, Abstract). The above combination does not show: receiving, at a processor, the text data,
sending the string to a repository to request data that matches or partially matches the string; comparing the string to hashed strings in the requested data; determining, from the comparison, whether the string corresponds to a stored hashed string of the repository; and outputting from the processor, in response from having determined that the string corresponds to the stored hashed string, an indication that the stored hashed string is in the text data.
Vandanapu shows: receiving, at a processor (Fig. 5 and col. 11 lines 25-44), the text data (col. 2 lines 37-56), sending the string to a repository to request data that matches or partially matches the string (col. 2 lines 49-65); comparing the string to hashed strings in the requested data (col. 2 lines 52-53 and 57-60); determining, from the comparison, whether the string corresponds to a stored hashed string of the repository (col. 2 lines 60-63); and outputting from the processor, in response from having determined that the string corresponds to the stored hashed string, an indication that the stored hashed string is in the text data (col. 2 lines 62-63, col. 3 lines 7-14).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the text comparison and hash-aware matching of brassbound with the data analysis and comparison techniques of Vandanapu in order to avoid exposing the processed and compared information, thus better protecting potentially sensitive details.
Regarding claim 4, the above combination shows wherein comparing the string to the repository of hashed strings (Vandanapu, Figs. 1, 2, and 4), includes using an edit distance, a hamming distance, a Locality Sensitive Hash, or a Bloom Filter (Vandanapu, Figs. 3 and 4)
Regarding claim 8, the above combination further shows wherein the text data includes at least one of an API key, a password, a PIN, a passphase, a credit card number, a bank account number, or personal health information (Vandanapu, col. 2 lines 27-32 and Fig. 2).
Regarding claim 9, the above combination further shows wherein the repository is an active directory, a hashed password database, or an internet password repository (Vandanapu, Fig. 1 item 110, col. 1 lines 20-32, col. 2 lines 27-37). Regarding claim 11, the limitations of said claim are addressed in the analysis of claim 1.
Regarding claim 14, the limitations of said claim are addressed in the analysis of claim 4.
Regarding claim 18, the limitations of said claim are addressed in the analysis of claim 8.
Regarding claim 19, the limitations of said claim are addressed in the analysis of claim 9.
Claims 2 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over extract_hashes in view of Park and Vandanapu, as applied to claim 1 above, further in view of Thomas (Thomas, Kurt, et al. "Data breaches, phishing, or malware? Understanding the risks of stolen credentials." Proceedings of the 2017 ACM SIGSAC conference on computer and communications security. (Year: 2017)).
Regarding claim 2, the above combination shows wherein receiving the text data includes extracting the text data (extract_hashes, pg. 2 lines 9 – 11 and lines 62-63). The above combination does not show: from monitored emails or traffic over a network. Thomas shows: from monitored emails or traffic over a network (pg. 5 L48-L50, R26-R60, pg. 6 L43-L45).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination in order to improve the detection capabilities of the resultant disclosure and the types of data sets that can be analyzed. Regarding claim 12, the limitations of said claim are addressed in the analysis of claim 2.
Claims 3 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over extract_hashes in view of Park, Vandanapu, and Thomas, as applied to claim 2 above, further in view of Jakobsson (US-20210234870-A1).
Regarding claim 3, the above combination shows detecting an email corresponding to the extracted text data based on an identified hashed password corresponding to the string (Thomas, Sections 3.2 and 3.3). The above combination does not show blocking the email. Jakobsson shows blocking ([28])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the blocking action of Jakobsson in order to prevent the dissemination of shared passwords, further improving the overall security posture of the monitored system.
Regarding claim 13, the limitations of said claim are addressed in the analysis of claim 3.
Claims 5 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over extract_hashes in view of Park and Vandanapu, as applied to claim 1 above, further in view of Krylov (Krylov et al. English translation of CN 109583201 B. August (Year: 2023)).
Regarding claim 5, the above combination shows comparing the string to the repository of hashed strings (Vandanapu, Figs. 1, 2, and 4). The above combination does not show using a bit-wise comparison. Krylov shows using a bit-wise comparison (pg. 6 lines 1 – 10).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the comparison techniques of Krylov in order to utilize prior art mechanisms for detecting the differences between data items for the intended purpose, and thus better understand the data compared in the above combination.
Regarding claim 15, the limitations of said claim are addressed in the analysis of claim 5.
Claims 6 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over extract_hashes in view of Park and Vandanapu, as applied to claim 1 above, further in view of Mahone (US-20050243984-A1).
Regarding claim 6, the above combination shows claim 1. The above combination does not show disabling a password corresponding to the string. Mahone shows disabling a password corresponding to the string ([42]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the password management of Mahone in order to prevent use of compromised passwords, improving the security posture of the monitored network.
Regarding claim 16, the limitations of said claim are addressed in the analysis of claim 6.
Claims 7 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over extract_hashes in view of Park and Vandanapu, as applied to claim 1 above, further in view of Laine (US-20180198601-A1).
Regarding claim 7, the above combination shows the string and the stored hash string (Vandanapu, Fig. 1, item 110 and Figs. 2, and 4). The above combination does not show where the string is encrypted. Laine shows where the string is encrypted (Abstract).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the encrypted data management of Laine in order to facilitate additional comparisons and thus a broader range of managed and monitored data.
Regarding claim 17, the limitations of said claim are addressed in the analysis of claim 7.
Claims 10 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over extract_hashes in view of Park and Vandanapu, as applied to claim 1 above, further in view of Low (US-8966645-B2).
Regarding claim 10, the above combination shows claim 1. The above combination does not show wherein the filter is based on a set of password requirements. Low shows filtering the text data based on a set of password requirements (col. 14 lines 10-20).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the comparison pre-processing of Low in order to improve the operational efficiency of the resultant invention.
Regarding claim 20, the limitations of said claim are addressed in the analysis of claim 10.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. This includes:
Saves (Saves, J. "Hash Identification Using ML & 3 Tools". https://blog.jcharistech.com/2021/12/30/hash-identification-using-machine-learning-and-3-tools/. December 30. (Year: 2021)).
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 JOHN M MACILWINEN whose telephone number is (571)272-9686. The examiner can normally be reached Monday - Friday, 9:00 - 5:00.
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, Glenton B Burgess can be reached at (571) 272 - 3949. 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.
JOHN MACILWINEN
Primary Examiner
Art Unit 2442
/JOHN M MACILWINEN/Primary Examiner, Art Unit 2454
Prosecution Insights