DETAILED ACTION
713.09 Interviews Between Final Rejection and Notice of Appeal [R-08.2017]
Normally, one interview after final rejection is permitted in order to place the application in condition for allowance or to resolve issues prior to appeal. However, prior to the interview, the intended purpose and content of the interview should be presented briefly, preferably in writing. Such an interview may be granted if the examiner is convinced that disposal or clarification for appeal may be accomplished with only nominal further consideration. Interviews merely to restate arguments of record or to discuss new limitations which would require more than nominal reconsideration or new search should be denied. See MPEP § 714.13.
Interviews may be held after the expiration of the shortened statutory period and prior to the maximum permitted statutory period of 6 months without an extension of time. See MPEP § 706.07(f).
A second or further interview after a final rejection may be held if the examiner is convinced that it will expedite the issues for appeal or disposal of the application.
For interviews after notice of appeal, see MPEP § 1204.03.
Authorization for Internet Communications
The examiner encourages Applicant to submit an authorization to communicate with the examiner via the Internet by making the following statement (from MPEP 502.03):
“Recognizing that Internet communications are not secure, I hereby authorize the USPTO to communicate with the undersigned and practitioners in accordance with 37 CFR 1.33 and 37 CFR 1.34 concerning any subject matter of this application by video conferencing, instant messaging, or electronic mail. I understand that a copy of these communications will be made of record in the application file.”
Please note that the above statement can only be submitted via Central Fax (not Examiner's Fax), Regular postal mail, or EFS Web using PTO/SB/439.
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 .
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.
Claim(s) 1 – 7, 9, 11 – 15 and 21 - 24 are rejected under 35 U.S.C. 103 as being unpatentable over the prior art of record, Brucker et al., (US 2017/0169229 A1) (hereinafter “Brucker”) in view of the prior art of record, Zlatnik (US 9,626,283 B1) (hereinafter “Zlatnik”) and NOEL et al., (US 2017/0289187 A1) (hereinafter “NOEL”).
Regarding claim 1, Brucker discloses; a method of identifying an attack surface of a cloud deployment, the method comprising:
identifying a security threat of the cloud deployment ([0037] “the deployment analysis can be integrated into the deployment process for cloud-based application”);
gathering, from one or more components in a software development pipeline, information associated with the cloud deployment ([0038] “monitor the security of application components and track updates to application components”);
identifying, based on the information associated with the cloud deployment, a portion of code enabling the security threat ([0060] “determine if the application exposes a vulnerability in a component”);
generating an alert based on the security threat and the identified portion of code ([0063] “the vulnerability analysis module generates a vulnerability report that based on the vulnerability analysis results for an application”); and
presenting the alert to indicate the identified portion of code that enables the security threat ([0005] providing a report indicating which of the plurality of software component in the list have vulnerabilities [0063] the vulnerability report can be categorized [0059] vulnerabilities are detected at the level of “source or byte-code” of code in a source code repository), to provide a type of security threat ([0057 and 0063] parsing/categorizing vulnerability information from database and then generates a categorized report).
Brucker does not disclose;
Identifying a user that added the portion of code to the cloud deployment enabling the security threat; and presenting the alert to provide a visual representation of an exploit path for the security threat and to indicate the user that added the portion of code to the cloud deployment enabling the security threat.
However, Zlatnik discloses;
Identifying a user that added a portion of code to a cloud deployment [i.e., determines which developer was the last developer to have modified the file or class associated with the detected error (col. 8, lines 51 – 53), (col. 7, lines 48 – 51) i.e., in a cloud computing environment (col. 3, lines 25 – 27)]; and
presenting an alert to indicate the user that added the portion of code to the cloud deployment enabling the security threat [i.e., the device then notifies the responsible developer (col. 9, lines 43 – 44), (see reference 84 of figure 5) i.e., notifies the identified developer via any means known in the art (col. 7, lines 64 – 65)].
Before the effective filing date of the claimed invention it would have been obvious to a person of ordinary skill in the art to modify the teachings of Brucker by adapting the teachings of Zlatnik for automatically assigning bugs or errors associated with a software application to one or more developers that are best suited to correct the bugs (See Zlatnik; col. 1, lines 37 – 40).
Brucker and Zlatnik do not disclose;
presenting the alert to provide a visual representation of an exploit path for the security threat.
However, NOEL discloses;
presenting an alert [i.e., an intrusion detection system i.e., SNORT platform generate an alert indicating (emphasis added) the detection of a buffer overflow attack against a network client machine (page 4, para 0040)] to provide a visual representation of an exploit path for a security threat [i.e., to understand the context for this alert, an analyst submits a query in the domain-specific language that in plan term asks for the alert, shows whether this alert is a detection of exploitation against a vulnerability…graphical sub-graph 400 is generated in response to the query…node 406 represent the specific alert…the edge 404 can denote the relationship between node 402 and 406…(page 4, para 0040 - 0041), (see figure 4) i.e., provide a graphical user interface to a user of the system that allows for the input of queries to the system and visualizing query results (page 6, para 0057), (see figure 8) i.e., the query can find “exploit paths,” i.e., sequences of vulnerabilities that an adversary could exploit for step-by-step lateral movement to a network (page 6, para 0061)].
Before the effective filing date of the claimed invention it would have been obvious to a person of ordinary skill in the art to modify the teachings of Brucker and Zlatnik by adapting the teachings of NOEL to maximize the analysis ability to discover potential threats and mission impacts, while minimizing the amount of time it takes to organize multiple and disparate data sources into meaningful relationship (See NOEL; page 1, para 0004).
Regarding claim 2, Brucker discloses; the method of claim 1, wherein identifying the portion of code comprises identifying a repository storing the portion of code, and wherein the alert indicates the identified repository ([0059] vulnerabilities are detected at the level of “source or byte-code” of code in a source code repository).
Regarding claim 3, Brucker discloses; the method of claim 1, wherein identifying the portion of code comprises identifying a particular one or more lines of code enabling the security threat, and wherein the alert indicates the particular one or more lines of code ([0059] vulnerabilities are detected at the level of “source or byte-code” of code in a source code repository).
Regarding claim 4, Brucker discloses; the method of claim 1, wherein the alert indicates a type of security threat to the cloud deployment including a policy violation, an anomaly, or configuration drift of the cloud deployment ([0063] “the vulnerability analysis module generates a vulnerability report that based on the vulnerability analysis results for an application”).
Regarding claim 5, Brucker discloses; the method of claim 1, wherein gathering the information associated with the cloud deployment comprises gathering runtime information associated with the cloud deployment, and wherein the alert identifies at least a portion of the runtime information for the cloud deployment ([0050], [see figure 1] a “deployment sensor” gathers runtime information that is used in the analysis).
Regarding claim 6, Brucker discloses; the method of claim 1, wherein the security threat comprises a detected vulnerability ([0063] “the vulnerability analysis module generates a vulnerability report that based on the vulnerability analysis results for an application” and [(0065)] “analyses of the application’s source code, build configuration, binary code, and/or deployment configuration”. Note; it is interpreted that the behavior of exploited vulnerable code is an “anomaly”. ([0062]) “vulnerabilities are known to have been exploited”).
Regarding claim 7, Brucker discloses; the method of claim 1, wherein the security threat comprises an identified configuration drift ([0063] “the vulnerability analysis module generates a vulnerability report that based on the vulnerability analysis results for an application” and [(0065)] “analyses of the application’s source code, build configuration, binary code, and/or deployment configuration”. Note; it is interpreted that the behavior of exploited vulnerable code is an “anomaly”. ([0062]) “vulnerabilities are known to have been exploited”).
Regarding claim 9, Brucker discloses; the method of claim 1, wherein the security threat comprises a detected anomaly ([0063] “the vulnerability analysis module generates a vulnerability report that based on the vulnerability analysis results for an application” and [(0065)] “analyses of the application’s source code, build configuration, binary code, and/or deployment configuration”. Note; it is interpreted that the behavior of exploited vulnerable code is an “anomaly”. ([0062]) “vulnerabilities are known to have been exploited”).
Regarding claim 11, Brucker discloses; a non-transitory computer readable storage medium, storing instructions which, when executed, cause one or more processing devices to: ([see figure 20]) ([see figure 20]):
identify a security threat of a cloud deployment ([0037] “the deployment analysis can be integrated into the deployment process for cloud-based application”);
gather, from one or more components in a software development pipeline, information associated with the cloud deployment enabling the security threat ([0038] “monitor the security of application components and track updates to application components”);
identify, based on the information associated with the cloud deployment, a portion of code enabling the security threat ([0060] “determine if the application exposes a vulnerability in a component”);
generate an alert based on the security threat and the identified portion of code ([0063] “the vulnerability analysis module generates a vulnerability report that based on the vulnerability analysis results for an application”); and
present the alert to indicate the identified portion of code that enables the security threat ([0005] providing a report indicating which of the plurality of software component in the list have vulnerabilities [0063] the vulnerability report can be categorized [0059] vulnerabilities are detected at the level of “source or byte-code” of code in a source code repository), to provide a type of security threat ([0057 and 0063] parsing/categorizing vulnerability information from database and then generates a categorized report).
Brucker does not disclose;
Identify a user that added the portion of code to the cloud deployment enabling the security threat; and present the alert to provide a visual representation of an exploit path for the security threat and to indicate the user that added the portion of code to the cloud deployment enabling the security threat.
However, Zlatnik discloses;
Identify a user that added a portion of code to a cloud deployment [i.e., determines which developer was the last developer to have modified the file or class associated with the detected error (col. 8, lines 51 – 53), (col. 7, lines 48 – 51) i.e., in a cloud computing environment (col. 3, lines 25 – 27)]; and
present an alert to indicate the user that added the portion of code to the cloud deployment enabling the security threat [i.e., the device then notifies the responsible developer (col. 9, lines 43 – 44), (see reference 84 of figure 5) i.e., notifies the identified developer via any means known in the art (col. 7, lines 64 – 65)].
Before the effective filing date of the claimed invention it would have been obvious to a person of ordinary skill in the art to modify the teachings of Brucker by adapting the teachings of Zlatnik for automatically assigning bugs or errors associated with a software application to one or more developers that are best suited to correct the bugs (See Zlatnik; col. 1, lines 37 – 40).
Brucker and Zlatnik do not disclose;
present the alert to provide a visual representation of an exploit path for the security threat.
However, NOEL discloses;
present an alert [i.e., an intrusion detection system i.e., SNORT platform generate an alert indicating (emphasis added) the detection of a buffer overflow attack against a network client machine (page 4, para 0040)] to provide a visual representation of an exploit path for a security threat [i.e., to understand the context for this alert, an analyst submits a query in the domain-specific language that in plan term asks for the alert, shows whether this alert is a detection of exploitation against a vulnerability…graphical sub-graph 400 is generated in response to the query…node 406 represent the specific alert…the edge 404 can denote the relationship between node 402 and 406…(page 4, para 0040 - 0041), (see figure 4) i.e., provide a graphical user interface to a user of the system that allows for the input of queries to the system and visualizing query results (page 6, para 0057), (see figure 8) i.e., the query can find “exploit paths,” i.e., sequences of vulnerabilities that an adversary could exploit for step-by-step lateral movement to a network (page 6, para 0061)].
Before the effective filing date of the claimed invention it would have been obvious to a person of ordinary skill in the art to modify the teachings of Brucker and Zlatnik by adapting the teachings of NOEL to maximize the analysis ability to discover potential threats and mission impacts, while minimizing the amount of time it takes to organize multiple and disparate data sources into meaningful relationship (See NOEL; page 1, para 0004).
Regarding claim 12, Brucker discloses; the non-transitory computer readable storage medium of claim 11, wherein identifying the portion of code comprises identifying a repository storing the portion of code, and wherein the alert indicates the identified repository ([0059] vulnerabilities are detected at the level of “source or byte-code” of code in a source code repository).
Regarding claim 13, Brucker discloses; the non-transitory computer readable storage medium of claim 11, wherein identifying the portion of code comprises identifying a particular one or more lines of code enabling the security threat, and wherein the alert indicates the particular one or more lines of code ([0059] vulnerabilities are detected at the level of “source or byte-code” of code in a source code repository).
Regarding claim 14, Brucker discloses; the non-transitory computer readable storage medium of claim 11, wherein the alert indicates a type of security threat to the cloud deployment including a policy violation, an anomaly, or configuration drift of the cloud deployment ([0063] “the vulnerability analysis module generates a vulnerability report that based on the vulnerability analysis results for an application”)..
Regarding claim 15, Brucker discloses; the non-transitory computer readable storage medium of claim 11, wherein gathering the information associated with the cloud deployment comprises gathering runtime information associated with the cloud deployment, and wherein the alert identifies at least a portion of the runtime information for the cloud deployment ([0050], [see figure 1] a “deployment sensor” gathers runtime information that is used in the analysis), wherein the security threat comprises a detected vulnerability ([0063] “the vulnerability analysis module generates a vulnerability report that based on the vulnerability analysis results for an application” and [(0065)] “analyses of the application’s source code, build configuration, binary code, and/or deployment configuration”. Note; it is interpreted that the behavior of exploited vulnerable code is an “anomaly”. ([0062]) “vulnerabilities are known to have been exploited”).
Regarding claim 21, Brucker discloses; a system comprising:
a memory; and
a processing device operatively coupled to the memory, the processing device comprising at least one hardware processor and configured to: ([see figure 20]) ([see figure 20]):
identify a security threat of a cloud deployment ([0037] “the deployment analysis can be integrated into the deployment process for cloud-based application”);
gather, from one or more components in a software development pipeline, information associated with the cloud deployment ([0038] “monitor the security of application components and track updates to application components”);
identify, based on the information associated with the cloud deployment, a portion of code enabling the security threat ([0060] “determine if the application exposes a vulnerability in a component”);
generate an alert based on the security threat and the identified portion of code ([0063] “the vulnerability analysis module generates a vulnerability report that based on the vulnerability analysis results for an application”); and
present the alert to indicate the identified portion of code that enables the security threat ([0005] providing a report indicating which of the plurality of software component in the list have vulnerabilities [0063] the vulnerability report can be categorized [0059] vulnerabilities are detected at the level of “source or byte-code” of code in a source code repository), to provide a type of security threat ([0057 and 0063] parsing/categorizing vulnerability information from database and then generates a categorized report).
Brucker does not disclose;
Identify a user that added the portion of code to the cloud deployment enabling the security threat; and present the alert to provide a visual representation of an exploit path for the security threat and to indicate the user that added the portion of code to the cloud deployment enabling the security threat.
However, Zlatnik discloses;
Identify a user that added a portion of code to a cloud deployment [i.e., determines which developer was the last developer to have modified the file or class associated with the detected error (col. 8, lines 51 – 53), (col. 7, lines 48 – 51) i.e., in a cloud computing environment (col. 3, lines 25 – 27)]; and
present an alert to indicate the user that added the portion of code to the cloud deployment enabling the security threat [i.e., the device then notifies the responsible developer (col. 9, lines 43 – 44), (see reference 84 of figure 5) i.e., notifies the identified developer via any means known in the art (col. 7, lines 64 – 65)].
Before the effective filing date of the claimed invention it would have been obvious to a person of ordinary skill in the art to modify the teachings of Brucker by adapting the teachings of Zlatnik for automatically assigning bugs or errors associated with a software application to one or more developers that are best suited to correct the bugs (See Zlatnik; col. 1, lines 37 – 40).
Brucker and Zlatnik do not disclose;
present the alert to provide a visual representation of an exploit path for the security threat.
However, NOEL discloses;
present an alert [i.e., an intrusion detection system i.e., SNORT platform generate an alert indicating (emphasis added) the detection of a buffer overflow attack against a network client machine (page 4, para 0040)] to provide a visual representation of an exploit path for a security threat [i.e., to understand the context for this alert, an analyst submits a query in the domain-specific language that in plan term asks for the alert, shows whether this alert is a detection of exploitation against a vulnerability…graphical sub-graph 400 is generated in response to the query…node 406 represent the specific alert…the edge 404 can denote the relationship between node 402 and 406…(page 4, para 0040 - 0041), (see figure 4) i.e., provide a graphical user interface to a user of the system that allows for the input of queries to the system and visualizing query results (page 6, para 0057), (see figure 8) i.e., the query can find “exploit paths,” i.e., sequences of vulnerabilities that an adversary could exploit for step-by-step lateral movement to a network (page 6, para 0061)].
Before the effective filing date of the claimed invention it would have been obvious to a person of ordinary skill in the art to modify the teachings of Brucker and Zlatnik by adapting the teachings of NOEL to maximize the analysis ability to discover potential threats and mission impacts, while minimizing the amount of time it takes to organize multiple and disparate data sources into meaningful relationship (See NOEL; page 1, para 0004).
Regarding claim 22, Brucker discloses; the system of claim 21, wherein identifying the portion of code comprises identifying a repository storing the portion of code, and wherein the alert indicates the identified repository ([0059] vulnerabilities are detected at the level of “source or byte-code” of code in a source code repository).
Regarding claim 23, Brucker discloses; the system of claim 21, wherein identifying the portion of code comprises identifying a particular one or more lines of code enabling the security threat, and wherein the alert indicates the particular one or more lines of code ([0059] vulnerabilities are detected at the level of “source or byte-code” of code in a source code repository).
Regarding claim 24, Brucker discloses; the system of claim 21, wherein gathering the information associated with the cloud deployment comprises gathering runtime information associated with the cloud deployment, and wherein the alert identifies at least a portion of the runtime information for the cloud deployment ([0050], [see figure 1] a “deployment sensor” gathers runtime information that is used in the analysis), wherein the security threat comprises a detected vulnerability ([0063] “the vulnerability analysis module generates a vulnerability report that based on the vulnerability analysis results for an application” and [(0065)] “analyses of the application’s source code, build configuration, binary code, and/or deployment configuration”. Note; it is interpreted that the behavior of exploited vulnerable code is an “anomaly”. ([0062]) “vulnerabilities are known to have been exploited”).
Claim(s) 8, 10 and 25 are rejected under 35 U.S.C. 103 as being unpatentable over Brucker in view of Zlatnik and NOEL as applied to claims 1 and 21 above, and further in view of the prior art of record, Williams et al., (US 2014/0165204 A1) (hereinafter “Williams”).
Regarding claim 8, Brucker discloses; the method of claim 1 [i.e., (see claim 1 above)].
Brucker, Zlatnik and NOEL do not disclose;
wherein the security threat comprises a detected risk level.
However, Williams discloses;
wherein the security threat comprises a detected risk level ([0092] “the GUI includes fields that specify the category of the rule, the severity of the vulnerability identified by the rule, the risk associated with the vulnerability, the recommendation for fixing the vulnerability” ([0099]) “generate remediation guidance that includes corrected code to replace the vulnerable code as detected”).
Before the effective filing date of the claimed invention it would have been obvious to a person or ordinary skill in the art to modify the teachings of Brucker, Zlatnik and NOEL by adapting the teaching of Williams to avoid complex and dynamic software tracking and security monitoring policies (See Williams; page 1, para 0002).
Regarding claim 10, Brucker discloses; the method of claim 1 [i.e., (see claim 1 above)].
Brucker, Zlatnik and NOEL do not disclose;
presenting a user interface comprising a selectable element that, when selected, modifies the identified portion of code to remediate the security threat.
However, Williams discloses;
presenting a user interface comprising a selectable element that, when selected, modifies the identified portion of code to remediate the security threat ([0092] “the GUI includes fields that specify the category of the rule, the severity of the vulnerability identified by the rule, the risk associated with the vulnerability, the recommendation for fixing the vulnerability” ([0099]) “generate remediation guidance that includes corrected code to replace the vulnerable code as detected”).
Before the effective filing date of the claimed invention it would have been obvious to a person or ordinary skill in the art to modify the teachings of Brucker, Zlatnik and NOEL by adapting the teaching of Williams to avoid complex and dynamic software tracking and security monitoring policies (See Williams; page 1, para 0002).
Regarding claim 25, Brucker discloses; the system of claim 21 [i.e., (see claim 21 above)].
Brucker, Zlatnik and NOEL do not disclose;
one or more processing devices is further configured to: present a user interface comprising a selectable element that, when selected, modifies the identified portion of code to remediate the security threat.
However, Williams discloses;
present a user interface comprising a selectable element that, when selected, modifies the identified portion of code to remediate the security threat ([0092] “the GUI includes fields that specify the category of the rule, the severity of the vulnerability identified by the rule, the risk associated with the vulnerability, the recommendation for fixing the vulnerability” ([0099]) “generate remediation guidance that includes corrected code to replace the vulnerable code as detected”).
Before the effective filing date of the claimed invention it would have been obvious to a person or ordinary skill in the art to modify the teachings of Brucker, Zlatnik and NOEL by adapting the teaching of Williams to avoid complex and dynamic software tracking and security monitoring policies (See Williams; page 1, para 0002).
Response to Arguments
Applicant's arguments in the Remarks filed 11/12/2025 have been fully considered but they are not persuasive because of the following;
Applicant argued that “Modifying Brucker with the notification of last developer to have modified the package, file, or class of Zlatnik would send a notification to the last developer. This combination does not result in indicating the user that added the portion of code to the cloud deployment enabling the security threat. Thus, the combination of Brucker with Zlatnik would not be pursued by one of ordinary skill in the art. Therefore, it would be impermissible hindsight to combine Brucker with Zlatnik based on applicants’ own disclosure” (See Remarks; page 10).
The Examiner respectfully disagrees with this argument because unlike the applicant’s argument that Zlatnik merely teaches notifying the last developer who have modified the package, file or class, Zlatnik actually teaches notifying the last developer who have modified the package, file or class that causes the detected error (col. 7, lines 48 – 51), (col. 8, lines 51 – 54) (See the Office Action above). Thus, Zlatnik does not merely notifies any developer who have modified some code, it notifies a developer that modifies a code that causes an error or bugs i.e., security threat.
Applicant’s remaining arguments with respect to pending claim(s) have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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 SYED A RONI whose telephone number is (571)270-7806. The examiner can normally be reached M-F 9:00-5:00 pm (EST).
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 L 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.
/SYED A RONI/Primary Examiner, Art Unit 2432