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
Claims 1 – 20 are pending.
Any references to applicant’s specification are made by way of applicant’s U.S. pre-grant printed patent publication.
This action is in response to the communication filed on 5/11/26.
All objections and rejections not set forth below have been withdrawn.
Drawings
The drawings are objected to under 37 CFR 1.83(a). The drawings must show every feature of the invention specified in the claims. Therefore, the features of a “…multi-class obfuscation classifier…”; “…selected from a plurality of obfuscation classifications…” (i.e. selecting from a plurality of obfuscation classifications); and “…a plurality of types of obfuscation…” must be shown or the feature(s) canceled from the claim(s). No new matter should be entered. The examiner notes that the applicant’s drawings only illustrate a binary malware classifier (e.g. Fig. 3:341; Fig. 441).
Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
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.
Claims 1 – 20 are 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.
Regarding claims 1 – 20, the applicant’s specification fails to describe the features of a “…multi-class obfuscation classifier…”; “…selected from a plurality of obfuscation classifications…”; and “… a plurality of types of obfuscation…” (e.g. see claims 1, 11).
Notably, the term “multi-class obfuscation classifier” is not even used within the applicant’s specification. Additionally noted is that the term “multi-class obfuscation classifier” is not a standard term within the art. Furthermore, the applicant’s specification never describes a plurality of types of obfuscation and the selection from a plurality of obfuscation classifications.
While the applicant’s specification does use the term “multi-class classification” (e.g. see Specification, par. 27), the applicant fails to ever address the features of a plurality of different or distinct classes of obfuscation. Rather than illustrating different types of obfuscation, the applicant instead clearly and explicitly describes throughout the applicant’s disclosure the performance of a binary classification of obfuscation and the additional classification of other malware.
Finally, while it is noted that the applicant’s disclosure comprise the sentence stating “…an obfuscation machine learning model to determine … what type of obfuscation is present in the script…” (e.g. Specification, par. 27), this singular and solitary notion of “a type of obfuscation” is left without any explanation by the applicant’ throughout the entirety of applicant’s disclosure. As stated above, the applicant’s disclosure teaches only the binary classification of obfuscation (i.e. is obfuscation present or not). The applicant never explains what may be considered to be different “types” of obfuscation, how any such types of obfuscation may be identified and classified, or any form of a selection from a plurality of obfuscation classifications.
Regarding claims 1 – 20, the applicant’s specification further fails to describe the claimed feature of a “…wherein each obfuscation classification of the plurality of obfuscation classifications is associated a type of obfuscation of a plurality of types of obfuscation …” (e.g. see claims 1, 11). Similar to the rejection above, it is noted that the applicant’s specification fails to teach a plurality of classifications that are associated with “a plurality of types of obfuscation”.
Depending claims are rejected by virtue of dependency.
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 – 20 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 claims 1 and 11 (see also claims 7-9 and 17-19), the term “…multi-class obfuscation classifier…” renders the scope of the claims indefinite. Specifically, this is not a term of the art and fails to comprise any standard meaning within the art. Also notable is that the term “multi-class obfuscation classifier” is not even used within the applicant’s own specification. Rather than teaching multiple classifications of obfuscation, the applicant’s specification instead disclosed only the binary classification of obfuscation using a “binary obfuscation machine learning model”, wherein the binary classifications of ‘obfuscation is present’ or ‘obfuscation is absent’ is determined.
Thus, it is not clear as to what subject matter is intended to fall within or outside the scope of a “multi-class obfuscation classifier”.
Regarding claims 1 and 11, the recitation of “…wherein each obfuscation classification of the plurality of obfuscation classifications is associated a type of obfuscation of a plurality of types of obfuscation …” renders the scope of the claims indefinite.
Specifically, the examiner notes that it is unclear as to what are the “types” of obfuscation such that they may be associated with distinct “classifications” of a plurality of obfuscation classifications. As noted above, the applicant fails to ever explain the notion of distinct “types” of obfuscation. Furthermore, the applicant appears only to ever teach obfuscation in the context of the binary classification of existing obfuscation or non-existing obfuscation within a program script. Outside of the binary classification of obfuscation, the applicant additionally teaches the classification of other malware. However, the applicant never clearly associates the classification of other malware as a form of “obfuscation classification”. Furthermore, the applicant’s original disclosure never describes a plurality of different types of obfuscation. Thus, it is not clear as to what subject matter falls within or outside of “obfuscation classifications …” that are associated with “…a type of obfuscation of a plurality of types of obfuscation…”.
Depending claims are rejected by virtue of dependency.
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.
Claims 1 – 3, 8, 10 – 13, 18, and 20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Zeppenfeld et al. (Zeppenfeld), US 2023/0153434 A1.
Regarding claim 1, as best determined in view of the above noted deficiencies of clarity, Zeppenfeld discloses:
A method (e.g. Zeppenfeld, Abstract) comprising:
extracting (e.g. Zeppenfeld, fig. 1:162), by the at least one processor (e.g. Zeppenfeld, fig. 1:160; par. 29), at least one symbol feature (e.g. Zeppenfeld, Abstract; par. 42 – i.e. “output file” which comprises one or more features of parsed code/text/data – i.e. “symbols”, found within computer code) from a script text of a software programming script by recognizing symbols of a symbol set (e.g. Zeppenfeld, par. 43, 44, 45 – processed computer code – i.e. “script text” of a programming script). Herein, software files are parsed and features, such as script sequences, words, characters, etc.. (i.e. “symbols of a symbol set” ) are recognized and extracted for analysis by an ensemble of machine learning classifiers.
utilizing, by the at least one processor, an obfuscation classification machine learning model comprising at least one multi-class obfuscation classifier (e.g. Zeppenfeld, Abstract; par. 55, 56, 59; fig. 1:167 – a plurality of classification models, i.e. “multi-class” classifier are used to classify the features according to indicators of obfuscation) to produce a predicted obfuscation classification selected from a plurality of obfuscation classifications for the software programming script based at least in part on the at least one symbol feature (e.g. Zeppenfeld, Abstract; par.59, 78 – the output of the classifiers comprise a ranking or score of how confident the extracted features can be classified to be obfuscated malware – i.e. a “predicted obfuscation classification”);
wherein each obfuscation classification of the plurality of obfuscation classifications is associated a type of obfuscation of a plurality of types of obfuscation (e.g. Zeppenfeld, par. 49-53, 55, 80 – each classifier is trained to recognize a different type of obfuscation corresponding to different types of files and/or features of files – e.g. PDF obfuscation vs. VBA
obfuscation vs. multimedia obfuscation; also see text obfuscation vs. image obfuscation vs. embedded link obfuscation vs. etc.);
and causing to execute, by the at least one processor, at least one operation to mitigate execution of the obfuscated software programming script based at least in part on the predicted obfuscation classification for the software programming script (e.g. Zeppenfeld, par. 39 – detected malware is modified, blocked, delayed, etc.).
Regarding claim 2, Zeppenfeld discloses:
determining, by the at least one processor, a frequency of each symbol of the symbol set (e.g. Zeppenfeld, par. 21); and determining, by the at least one processor, the at least one symbol feature based at least in part on the frequency of each symbol (e.g. Zeppenfeld, par. 21, 48, 49). Herein, the output file, i.e. “at least one symbol feature”, may be based upon a detected frequency of words, bytes, characters, etc.
Regarding claim 3, Zeppenfeld discloses:
determining, by the at least one processor, a score of each symbol of the symbol set based at least in part on a frequency of each symbol (e.g. Zeppenfeld, par. 21, 48, 49, 104 – an identified frequency of any event/thing, e.g. a word or byte or line etc, comprises a numerical value, i.e. “score”, such as a largest or average frequency value; see also par. 64 – the identified features are converted into a floating point vectors, i.e. “score”) and an average frequency for the symbols in the symbol set (e.g. Zeppenfeld, par. 21, 48, 49 – an average frequency, e.g. number of lines per script, is also determined);
determining, by the at least one processor, the at least one symbol feature based at least in part on the score of each symbol of the symbol set (e.g. Zeppenfeld, par. 47, 48, 64 – the output file, i.e. “symbol feature”, is determined based upon the identified numerical values and/or floating point vectors, i.e. “scores”, of the frequencies of symbols).
Regarding claim 8, Zeppenfeld discloses:
wherein the at least one multi-class obfuscation classifier comprises a plurality of different classification models (e.g. fig. 1:167; par. 55, 58, 59, 66 – herein the machine learning model may comprise a plurality of different classification models).
Regarding claim 10, Zeppenfeld discloses:
further comprising logging, by the at least one processor, the software programming script in an obfuscation log comprising a list of entries of obfuscated scripts (e.g. Zeppenfeld, par. 56, 60 – previously identified malware samples are stored, i.e. “logged”, so they may be later used as training data).
Regarding claims 11 – 13, 18, and 20, they are system claims, essentially corresponding to the above method, and they are rejected, at least, for the same reasons.
Furthermore, regarding claim 11, Zeppenfeld discloses:
A system comprising: at least one processor in communication with at least one non-transitory computer-readable medium having software instructions stored thereon … (e.g. Zeppenfeld, par. 84-87).
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 (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 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 4, 5, 14, and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Zeppenfeld et al. (Zeppenfeld), US 2023/0153434 A1 in view of Masud et al., (Masud), US 2012/0054184 A1.
Regarding claim 4, Zeppenfeld discloses the classification of a plurality of malware scripts by analyzing features associated with data streams (e.g. Zeppenfeld, par. 44, 51, 102). However, Zeppenfeld does not appear to explicitly teach that use of a buffer to receive streaming data.
However, like Zeppenfeld, Masud teaches the classification of a plurality of malware scripts, wherein, the malware is found within data streams (e.g. Masud, Abstract). Furthermore, Masud teaches that when performing classification of data streams, a FIFO queue, i.e. “buffer”, should be used (e.g. Masud, par. 110, 111, 194).
It would have been obvious to one of ordinary skill in the art to employ the data stream classification teachings of Masud for using a FIFO buffer within the system of Zeppenfeld. This would have been obvious because one of ordinary skill in the art would have been motivated by the teachings that the need to perform malware classification upon data streams is increasingly necessary (e.g. Masud, Abstract, par. 4).
Thus the combination enables:
receiving, by the at least one processor, the software programming script from a plurality of software programming scripts as a stream into a buffer (e.g. Masud, Abstract; par. 110, 111, 194; e.g. Zeppenfeld, par. 19-21).
Regarding claim 5, the combination enables:
wherein the buffer comprises a first-in, first-out (FIFO) buffer (e.g. Masud, Abstract; par. 110, 111, 194; e.g. Zeppenfeld, par. 19-21).
.
Regarding claims 14 and 15, they are system claims, essentially corresponding to the claims above, and they are rejected, at least, for the same reasons.
Claims 6, 7, 16, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Zeppenfeld et al. (Zeppenfeld), US 2023/0153434 A1 in view of Hegde et al., (Hegde), US 11,620,379 B1.
Regarding claims 6 and 7, Zeppenfeld discloses using a plurality of machine learning models for the detection of obfuscation within computer code (e.g. Zeppenfeld, Abstract; fig. 1:167; par. 55). However, Zeppenfeld does not appear to explicitly disclose using the plurality of models as an “ensemble”.
However, Hegde, like Zeppenfeld also teaches using a plurality of machine learning models for the detection of obfuscation within computer code (e.g. Hegde, Abstract) and furthermore teaches using the plurality of models as an ensemble (e.g. Hegde, 6:26-35).
It would have been obvious to one of ordinary skill in the art to utilize the “ensemble” approach of using models, as taught by Hegde, within the system of Zeppenfeld, because one of ordinary skill in the art would have been motivated by the teachings that using an ensemble of models creates more accurate predictions by aggregating the collection of outputs from each model (e.g. Hegde, 6:35-46).
Thus, regarding claim 6, the combination enables:
wherein the obfuscation classification machine learning model comprises an ensemble model of neural networks (e.g. Zeppenfeld, fig. 1:167; par. 55, 58, 59, 66; Hegde, 6:25-46 – herein the machine learning model may comprise a plurality of models, arranged as an “ensemble”, where each model of the plurality may employ a neural network).
Regarding claim 7, the combination enables:
wherein the at least one multi-class obfuscation classifier comprises an ensemble model of decision trees (e.g. Zeppenfeld, fig. 1:167; par. 55, 58, 59, 66; Hegde, 6:25-46 – herein the machine learning model may comprise a plurality of models, arranged as an “ensemble”, where each model of the plurality may employ a decision tree).
Regarding claims 16 and 17, they are system claims, essentially corresponding to the claims above, and they are rejected, at least, for the same reasons.
Claims 9 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Zeppenfeld et al. (Zeppenfeld), US 2023/0153434 A1, in view of Hegde et al., (Hegde), US 11,620,379 B1, in view of Kurama, “Introduction to Bagging and Ensemble Methods”.
Regarding claim 9, it is rejected, at least, for the same rationale as noted regarding claim 6, and furthermore because the combination of Zeppenfeld and Hegde teaches machine learning using an ensemble classifier comprising multiple classifiers (Zeppenfeld, fig. 1:167; par. 55, 58, 59, 66; Hegde, 6:25-46). However, the combination does not appear to explicitly teach that the ensemble learning utilizes “bootstrap aggregation”.
However, Kurama teaches that machine learning using ensembles should also employ “bagging”, i.e. “bootstrap aggregation” (e.g. Kurama, pg. 3, 5). It would have been obvious to one of ordinary skill in the art to employ “bootstrap aggregation” teachings as taught by Kurama within the combination of Zeppenfeld and Hedge for employing ensemble learning. This would have been obvious because one of ordinary skill in the art would have been motivated by the teachings that “bootstrap aggregation” advantageously helps the machine learning to avoid the problems of overfitting (e.g. Kurama, pg. 6).
Thus, the combination enables:
wherein the at least one multi-class obfuscation classifier comprises bootstrap aggregation (Zeppenfeld, fig. 1:167; par. 55, 58, 59, 66; Hegde, 6:25-46; Kurama, pg. 3, 5, 6).
Regarding claims 19, it is a system claim, essentially corresponding to the claims above, and it is -rejected, at least, for the same reasons.
Response to Arguments
Applicant's arguments filed 5/11/26 have been fully considered but they are not persuasive.
Applicant argues or alleges essentially that:
…
The drawings depict the multi-class obfuscation classifier by depicting, in FIG. 1 (reproduced below), the script scanning model 140, which as detailed above, can include multi- class obfuscation classifier (a model that can create a multi-class classification for obfuscations in scripts).
…
Therefore, the drawings as filed show the "multi-class obfuscation classifier" recited in the claims by depicting the script scanning model 140.
…
(Remarks, pg. 6 – 8)
Examiner respectfully responds:
The examiner respectfully disagrees. Specifically because a script scanning module is not the equivalent to a multiclass classifier module. Thus, the illustration of a “script scanning module 140” of Figure 1 does not illustrate a “multi-class obfuscation classifier” or the selection from a plurality of obfuscation classifications associated with a plurality of types of obfuscation as is claimed.
Furthermore, the applicant’s remaining figures of Fig. 3 and Fig. 4 each illustrate a “Binary Malware Classifier” and the specific operation of the “Binary Malware Classifier”. However, the illustration of a “Binary Malware Classifier” and it’s associated operation fails to illustrate a “multi-class obfuscation classifier” or the selection from a plurality of obfuscation classifications associated with a plurality of types of obfuscation as is claimed.
Applicant argues or alleges essentially that:
…
Thus, the Specification as filed describes the script scanning model 140 that can create a multi-class classification, such as a determination of what type of obfuscation is present. Thus, the script canning model 140 can be a multi-class obfuscation classifier (a model that can create a multi-class classification for obfuscations in scripts).
Therefore, the specification as filed describes the "multi-class obfuscation classifier" recited in the claims.
…
(Remarks, pg. 8, 9)
Examiner respectfully responds:
The examiner respectfully disagrees. Specifically because a script scanning module is not the equivalent to a multiclass classifier module. Thus, the disclosure of a “script scanning module 140” of Figure 1 does not disclose a “multi-class obfuscation classifier” or the selection from a plurality of obfuscation classifications associated with a plurality of types of obfuscation as is claimed.
Furthermore, the applicant’s remaining portions of applicant’s specification disclose a “Binary Malware Classifier” and the specific operation of the “Binary Malware Classifier”. However, the disclosure of a “Binary Malware Classifier” and it’s associated operation fails to disclose a “multi-class obfuscation classifier” or the selection from a plurality of obfuscation classifications associated with a plurality of types of obfuscation as is claimed.
Applicant argues or alleges essentially that:
…
Thus, the Specification as filed describes the script scanning model 140 that can create a multi-class classification, such as a determination of what type of obfuscation is present. Thus, one of ordinary skill in the art would understand, in light of the Specification, that the script canning model 140 can be a multi-class obfuscation classifier (a model that can create a multi-class classification for obfuscations in scripts).
…
(Remarks, pg. 9, 10)
Examiner respectfully responds:
The examiner respectfully disagrees, at least, for the reason that the applicant fails to provide any evidence or rationale for explaining the scope of a plurality of types of obfuscation or of a plurality of different classifications of obfuscation.
Thus, there does not appear to be any reasonable basis of support to the allegation that one of ordinary skill in the art would have understood how a “script scanning module 140” clearly discloses a “multi-class obfuscation classifier” and the claimed operation of selecting a obfuscation classification from a plurality of obfuscation classifications, each classification associated with a type of obfuscation of a plurality of types of obfuscation.
Applicant argues or alleges essentially that:
…
The Specification confirms this understanding. Paragraph 24 explains that "the feature extractor 120 analyzes the characters and symbols in each script to produce symbol features" and that those features are "designed for recognizing obfuscation in the script code." Paragraphs 25- 27 then describe preparing those symbol features as a feature map or feature vector and communicating the feature vector to a script scanning model, where "the script scanning model 140 employs machine learning techniques to ingest the feature vector for a script and correlate a classification to the script." Paragraph 27 expressly states that "the classification can include, e.g., a binary classification or a multi-class classification" and further explains that the obfuscation machine learning model may determine "whether or not a script is obfuscated, or what type of obfuscation is present in the script." These passages provide concrete context for the claimed classifier, the claimed plurality of classifications, and the association between an obfuscation classification and a type of obfuscation.
A person of ordinary skill would understand that the claimed multi-class obfuscation classifier is a machine-learning classifier operating in the obfuscation-classification domain and outputting one of multiple obfuscation classifications, each corresponding to a type of obfuscation. …
…
(Remarks, pg. 10, 11)
Examiner respectfully responds:
The examiner respectfully disagrees, at least, for the reason that none of the cited portions of applicant’s original disclosure comprise an explanation as to the different types of obfuscation or the different classifications of obfuscation. Thus, the applicant’s original disclosure fails to adequately explain the claimed “multi-class obfuscation classifier” and it’s claimed operation.
Applicant argues or alleges essentially that:
…
Accordingly, unlike amended claim 1, Zeppenfeld' s classifier output is "malware classification data" indicating "whether the electronic file does or does not contain malware," where that output is generated in response to the classifier determining whether features "are or are not indicators of obfuscation." Zeppenfeld 77, 101. A file format, document type, or feature set such as VBA, PDF, image, stream, URL, or metadata is not itself an "obfuscation classification" associated with a "type of obfuscation" as claimed.
…
(Remarks, pg. 11, 12)
Examiner respectfully responds:
The examiner respectfully disagrees, at least, for the reason that obfuscation, such as PDF obfuscation, VBA obfuscation, multimedia obfuscation, text obfuscation, image obfuscation, embedded link obfuscation, etc. appear to be types of obfuscation. Thus, Zeppenfeld selection of an obfuscation classification based upon such obfuscation types anticipates the claims.
The balance of Applicant’s arguments are based upon the unpersuasive arguments above, and are found to be unpersuasive, at least, for the same reasons.
Conclusion
THIS ACTION IS MADE FINAL. 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 JEFFERY L WILLIAMS whose telephone number is (571)272-7965. The examiner can normally be reached on 7:30 am - 4:00 pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Farid Homayounmehr can be reached on 571-272-3739. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/JEFFERY L WILLIAMS/Primary Examiner, Art Unit 2495
Prosecution Insights