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/14/2026 have been fully considered, and are partially persuasive. Applicant’s amended claim language has overcome the clarity issues previously noted in the 5/15/2026 Non-Final Office Action. However, the amended claim language has also introduced new clarity issues, resulting in corresponding new rejections made under 35 USC 112.
Claim Rejections - 35 USC § 112
The following is a quotation 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 35 U.S.C. 112 (pre-AIA ), first paragraph:
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.
Claims 3 – 5 and 22 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph.
Regarding claim 3, said claim is rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, because the specification, while being enabling for processing and consideration of bytes and quantities of bytes, does not reasonably provide enablement for determination and use of a “byte atom”, “threshold-byte atom”, or “threshold-byte static byte atom”. The specification does not enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to use the invention commensurate in scope with these claims. In other words, the claimed scope of the invention and the disclosed scope of the invention differ to such an extent that issues are raised with regards to compliance under 35 USC 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph. While the term “byte atom” appears in the originally filed specification (e.g., in [8,13,58,118-120], etc.), it is not recited or utilized in a manner that enables a determination of the intended scope of what a “byte atom” may comprise, much less what may be considered a “threshold byte atom”. In other words, while consideration and use of “bytes” and quantity of “bytes” is provided, how these bytes may be evaluated such that they form a “byte atom”, a “threshold byte atom”, and a “threshold-byte static byte atom” is absent from the specification.
Regarding claims 4 and 5, said claim further limits the “threshold-byte atom” discussed above in parent claim 3, and inherit the issues noted above. Regarding claim 22, said claim additionally references “the threshold-byte atom”, and thus suffers from issues analogous to those in claims 3, 4, and 5.
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 – 5, 7 – 14, and 16 – 22 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.
Regarding claim 1, line 8 introduces “a dictionary for a malware family”. Lines 13 and 16 then references this via the recitation of “the dictionary”. Next, line 17 introduces “a dictionary associated with a second malware family”, and thus establishes antecedent basis for two distinct dictionaries, as well a two distinct malware families.
This results in clarity issues when lines 18 – 19 reference “the dictionary for the malware family”, given the presence of two dictionaries and two malware families. The same clarity issues exist when “the malware family” is referenced in line 23, and “the dictionary for the malware family”, referenced in lines 25 – 26 and again on line 27. As a result, the references to “the malware family” and “the dictionary for the malware family” on lines 18 – 19, line 23, lines 25-26, and line 27 are each rendered indefinite as it is unclear which of the previously introduced “dictionary” and “malware family” is being further limited in these noted recitations.
Regarding claim 2, said claim additionally references “the dictionary” in line 3, which suffers from clarity issues analogous to the recitations noted above in claim 1.
Regarding claim 3, said claim additionally references “the dictionary” in line 2, which suffers from clarity issues analogous to the recitations noted above in claim 1. Further regarding claim 3, said claim introduces “a threshold-byte atom” in line 4. As noted on pages 3 – 4 of the 5/15/2026 Non-Final Rejection, the specification does not reasonably provide enablement for determination and use of a “byte atom” or “threshold-byte atom”. The Examiner notes that claim 3 has been amended to include additional language establishing how a “byte atom” / “threshold-byte atom” should be interpreted. However, this amended language essentially provides a circular definition that itself relies on the word being defined, and thus provides little additional clarity regarding the above noted claim language. For example, lines 5 – 6 recite that “the threshold-byte atom comprises a threshold-byte static byte atom”. The presence of a “a threshold-byte static byte atom” cannot be said to clarify the scope of a “byte atom” or a “threshold-byte atom” when there is a clarity issues regarding the intended scope for both a “byte atom” and a “threshold-byte atom”. Claim 3 continues to rely on the interpretation of “at least one threshold-byte atom” in lines 9 – 10. The scope of each of these noted reference to a type of “byte atom” is unclear and indefinite. As noted in the 5/15/2026 Office Action, there is no well-understood definition of what a “byte atom” or “threshold byte atom” encompasses. Searching online on search engines such as Google fail to return any prior art use of this term that could be relevant to the present application. Search in the internal USPTO tools of patents and pre-grant publications similarly fail to locate any utilization of these terms. “Byte atom” and “threshold-byte atom” thus are not considered terms of art. Applicant’s specification has been reviewed in an effort to ascertain a broadest reasonable interpretation for byte atom” or “threshold byte atom”. While a “byte atom” is referenced in, e.g., [8,13,58,118-120] of Applicant’s originally filed specification, only non-limiting examples are provided utilizing the language “byte atom”, and these non-limiting examples fail to provide either an explicit definition or utilization in a context that facilitates determining a broadest reasonable interpretation of “byte atom”. Thus the references to a “byte atom” in Applicant’s specification are rendered unclear and indefinite.
Regarding claim 4, said claim further recites the “threshold-byte atom” of claim 3, and fails to clarify the issues noted above appearing in claim 3.
Regarding claim 5, said claim further recites the “threshold-byte atom” of claim 3, and fails to clarify the issues noted above appearing in claim 3. Said claim additionally references “a malware family of the dictionary”, which suffers from issues regarding which of the previously recited dictionaries is being further limited (as discussed above in the rejections of claims 1 and 2, e.g.,). Regarding claim 7, said claim recites a “third dictionary” on page 3 line 3 and again on page 2 line 2. However, there is a lack of antecedent basis for both a “first” and a “second” dictionary, and thus it is unclear what a “third” dictionary is intended to further specify. Claim 7 additionally references “the first dictionary” on page 4 lines 1 – 2; as noted above, there is no antecedent basis for “the first dictionary”.
Regarding claim 8, said claim additionally references “the dictionary” in line 4, which suffers from clarity issues analogous to the recitations noted above in claim 1.
Regarding claims 9 – 14, said claims depend on one of claims 1 and 8, and fail to clarify the issues appearing in their respective parent claims.
Regarding claim 16, line 4 introduces “a malware family dictionary”, line 7 references grouping “by malware family”, and line 8 subsequently introduces “a dictionary of at least another malware family”.
Line 8’s reference to “another malware family” is rendered unclear and indefinite by the lack of first establishing basis for something corresponding to “first” malware family, as reference to “another” malware family requires establishment of initial or first malware family for the “another” reference to be clear and definite. Note that a “malware family dictionary” provides antecedent basis for a dictionary rather than an family. Line 9 continues to reference “the malware family”, but as noted above, no antecedent basis has been provided that clearly establishes what would correspond to this “the malware family”. Line 9 also references “data corresponding to the byte sequences for the malware family”. This relies on antecedent basis that establish that a “malware family” contains “byte sequences”. While “byte sequences” are introduced in lines 1 – 8, that a “malware family” contains “byte sequences” has not been established, and thus the references to “the byte sequences for the malware family” is unclear and indefinite; in other words, the contents of the “malware family” has not been established and thus “byte sequences for the malware family” cannot be said to have been established. A similar issue exists in the recitations on lines 11 – 12 regarding a “removing” step be perform on “the malware family dictionary”. Without first establishing what a “malware family dictionary” contains, such a “removing” step cannot clearly and definitely be recited. In addition, the “removing” step in lines 11 – 12 claimed as part of the steps involved in “generating the malware family dictionary”. However, lines 1 – 12 of claim 16 have yet to establish what a “malware family dictionary” actually contains; the “generating” steps have not actually added any content to said dictionary or otherwise established what the contents of said dictionary are. Furthermore, it is unclear how this “removing” step can occur prior to the “generating” of said dictionary having been performed. The result of these issues noted above renders claim 16 as a whole indefinite in scope.
Regarding claim 17, said claim recites on page 6 line 1, claim 17 recites adding bytes “into a dictionary”. It is unclear if this “a dictionary” is intended to correspond to “the malware family dictionary” introduced in claim 16, the “a dictionary of at least another malware family”, or is introducing a separate and distinct dictionary. The reference in claim 17 lines 5 – 6 to “the dictionary” is similarly problematic, as by lines 5 – 6 of claim 17 there are three possibilities to which this “the dictionary” may refer.
Regarding claim 18, said claim references “the computing internal network”. There is no antecedent basis for this limitation.
Regarding claims 19 – 21, said claims depend on claim 16 and fail to clarify the issues noted above.
Regarding claim 22, said claim references “the threshold-byte atom”. There is no antecedent basis for this limitation. The reference to “the threshold-byte atom” contains the same issues noted above in the analysis of claim 3 (which also references a “threshold-byte atom”).
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 16, 18, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Lee (Lee, Jehyun, Suyeon Lee, and Heejo Lee. "Screening smartphone applications using malware family signatures." computers & security 52: 234-249. (Year: 2015)) in view of Yoo (US-20110314547-A1).
Regarding claim 1, Lee shows a method for monitoring network traffic, the method comprising: receiving a collection of malware signature samples (pg.1, Abstract, and pg. 6 Section 4.3.1, e.g., discussing “family classification information labeling from multiple AV vendors”), wherein each malware signature sample in the collection comprises one or more byte sequences (Fig.2 showing “Bytecode” entries and byte-representations of character strings, pg. 6 Section 4.3 discussing a “signature construction process extracts the binary patterns . . . from known malware”, pg. 7 Tabel 2 showing exemplary strings such as the “Method body” byte sequences visually representing some of the data illustrated in Fig. 2, and also Fig. 4 showing the use of “bytecode” as part of “Family signature construction”); generating a malware family dictionary based on analyzing data corresponding to the one or more byte sequences in the collection of malware signature samples (pg. 1, Abstract and pg. 6 detailing “Family signature construction” ), wherein generating the malware family dictionary comprises: grouping the malware signature samples by malware family (pg.2 , right column bottom 2 bullet points, pg. 3 Section 2 right column, pg. 6, left column), retrieving a dictionary of at least another malware family (pg. 2 right column 2nd bullet, pg. 6 Section 4.3.1), comparing data corresponding to the byte sequences for the malware family with data corresponding to byte sequences of the at least another malware family (pg. 2 right column 2nd bullet, discussing taking an input “family signature” and “estimating similarity to various known families” and pg. 5 Section 4.1 discussing to “estimate a similarity to a family” when evaluating “signature entries”; see also pg. 8 right column last paragraph – pg. 9 end of Section 4.3), and removing, from the malware family dictionary, data corresponding to a conflicting byte sequence that is identified based on the comparing (pg. 9 Section 4.3 discussing “removing patterns’ that have similarity in multiple families “exceeding a certain threshold”);
generating malware detection rules based on the malware family dictionary (pg. 2 right column bottom and pg. 3 Section 2 discussing the introduction of “our family signature generation and malware detection mechanism”). Lee does not show: receiving network traffic data; determining whether the network traffic data triggers one or more of the malware detection rules; and blocking network traffic associated with the network traffic data that triggers the one or more of the malware detection rules, wherein blocking the network traffic comprises preventing the network traffic from entering a computing network. Yoo shows receiving network traffic data ([43]); determining whether the network traffic data triggers one or more of the malware detection rules ([39,45,49]); and blocking network traffic associated with the network traffic data that triggers the one or more of the malware detection rules, wherein blocking the network traffic comprises preventing the network traffic from entering a computing network ([44-45]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the data processing and malware detection techniques of Lee with the traffic processing of Yoo in order to enable use of a protected network connection for endpoint devices utilizing the resultant disclosure.
Regarding claim 18, the above combination further shows herein the method further comprises transmitting a portion of the network traffic associated with the network traffic data that does not trigger the malware detection rules to the computing internal network (Yoo, Fig. 22 steps 407-411, [43-45]).
Regarding claim 19, the above combination further shows wherein the method further comprises generating and returning output, to a compute device, about the network traffic (Yoo, [50-52,63,65-66]).
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Lee in view of Yoo, as applied to claim 16 above, further in view of Griffin (Griffin, Kent, et al. "Automatic generation of string signatures for malware detection." International workshop on recent advances in intrusion detection. Berlin, Heidelberg: Springer Berlin Heidelberg. (Year: 2009)).
Regarding claim 17, the above combination shows claim 16. The above combination does not show wherein generating the malware family dictionary comprises, for each malware signature sample in the collection: identifying data corresponding to a threshold quantity of bytes of a byte sequence of the malware signature sample, adding the data corresponding to the threshold quantity of bytes into a dictionary based on identifying the data corresponding to the threshold quantity of bytes, identifying data corresponding to a next set of the threshold quantity of bytes of the byte sequence of the malware signature sample, and adding the data corresponding to the next set of the threshold quantity of bytes into the dictionary based on identifying the data corresponding to the next set of the threshold quantity of bytes. Griffin shows wherein generating the malware family dictionary comprises, for each malware signature sample in the collection: identifying data corresponding to a threshold quantity of bytes of a byte sequence of the malware signature sample (pg. 2 lines 25-33, discussing utilizing “N” bytes, where N can be set to 48, and pg. 11, Section 5 discussing additional options such as N/3, 4, or 5; see also pg. 16 lines 34-37 and pg. 18 lines 20-25), adding the data corresponding to the threshold quantity of bytes into a dictionary based on identifying the data corresponding to the threshold quantity of bytes (pg. 16 line 45 – pg. 17 line 17 suggesting formation of the claimed dictionary via the recitation of creating the “final signature set”), identifying data corresponding to a next set of the threshold quantity of bytes of the byte sequence of the malware signature sample (pg. 2 lines 25-29 and 41-42, suggesting repeating the identification processes mapped above for every byte sequence in the provided malware samples, and thus suggesting this “identifying the next” limitation), and adding the data corresponding to the next set of the threshold quantity of bytes into the dictionary based on identifying the data corresponding to the next set of the threshold quantity of bytes (pg. 2 lines 25-29 and 41-42, suggesting repeating the identification processes mapped above for every byte sequence in the provided malware samples, and thus suggesting this “adding the next” limitation).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention with the malware dictionary creation and maintenance techniques of Griffin in order to better ensure potential new malware identification data is reliably and consistently evaluated and recorded for further use.
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over Lee in view of Yoo as applied to claim 16 above, further in view of Sick (US-20130167236-A1).
Regarding claim 20, the above combination shows shows claim 16. The above combination shows does not show wherein the output comprises an indication of a quantity of the network traffic that triggered the one or more of the malware detection rules. Sick shows wherein the output comprises an indication of a quantity of the network traffic that triggered the one or more of the malware detection rules ([103]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the data processing and malware detection techniques of the above combination shows with the quantity tracking of Sick in order to enable creation of an overall picture of network health in relation to external communications, enabling more informed decisions regarding how to handle malicious inbound communications (e.g., decisions regarding when to completely isolate the internal network).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. This includes:
Schmugar (US-20190228151-A1) and Kovác (US-20230107209-A1).
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