DETAILED ACTION
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 .
Remarks
This action is in response to the application received on 9/4/26. Claims 1-20 are pending in the application. Applicants arguments have been carefully considered.
Claims 1-4, 6-12, and 14-20 are rejected under 35 U.S.C. 103 as being unpatentable over Araujo et al. (US 11,562,086), and further in view of Arikapudi et al. (US 11,436,363).
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Araujo in view of Arikapudi, and further in view of F. Engelhardt and M. Güneş, "A /sys Filesystem for the Internet of Things," NOMS 2022-2022 IEEE/IFIP Network Operations and Management Symposium, Budapest, Hungary, 2022, pp. 1-6, doi: 10.1109/NOMS54207.2022.9789849.
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over Araujo in view of Arikapudi, and further in view of H. Satou and K. Kourai, "Prevention of a DoS Attack with Copy-on-write in the Overlay Filesystem," 2021 IEEE Intl Conf on Dependable, Autonomic and Secure Computing, Intl Conf on Pervasive Intelligence and Computing, Intl Conf on Cloud and Big Data Computing, Intl Conf on Cyber Science and Technology Congress (DASC/PiCom/CBDCom/CyberSciTech), AB, Canada, 2021, pp. 76-83.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-4, 6-12, and 14-20 are rejected under 35 U.S.C. 103 as being unpatentable over Araujo et al. (US 11,562,086), and further in view of Arikapudi et al. (US 11,436,363).
With respect to claim 1, Araujo teaches a non-transitory machine-readable storage medium comprising instructions that upon execution cause a computer system to:
store, by a base filesystem layer, a file (Araujo, Col. 8 Li. 12-13, the base filesystem 400 is shown as comprising a set of base files);
as part of provisioning the computer system (Araujo, Col. 8 Li. 8-11, the approach configures a set of filesystem overlays 412 that are preferably deployed on a per-process basis, providing each process with a different view of the filesystem. & Col. 9 Li. 5-10, a preferred Linux-based implementation leverages a kernel modification deployed as a kernel hot patch 430 (patching the kernel while it is running), and the installation of a kernel module 432 implementing the monitoring, access control, and decoy creation and injection capabilities.):
create an upper filesystem layer that overlays the base filesystem layer (Araujo, Col. 7 Li. 66 – Col. 8 Li. 1, This architecture allows for different directory and file trees to be overlayed (i.e., superimposed) over the base filesystem 300.),
obscure the file to render at least a portion of the file inaccessible (Araujo, Col. 8 Li. 14-17, Within an overlay, however, and as indicated by the key, a base file may be hidden from a process (represented by hidden file 416), or redacted or replaced (represented by replaced file 418).), and
add the obscured file to the upper filesystem layer, wherein the obscured file in the upper filesystem layer in the file in the base filesystem layer share a first file identifier (Araujo, Col. 8 Li. 21-25, each overlay 412 thus has the ability to … modify the content of a base file by overlaying a different file (e.g., one that is redacted or replaced) with the same name);
receive an access request from a process targeting the file identified by the first file identifier, the process being without a privilege to access the file (Araujo, Col. 8 Li. 42-44, The monitoring module 424 transparently monitors and logs access to the files. Based on this monitoring, the system can determine whether a process 426 is trusted.);
determine whether the first file identifier is present in the upper filesystem layer (Araujo, Col. 8 Li. 65- Col. 9 Li. 3, a configuration also specifies which files and directories to show in the overlay, which ones to hide, and which ones to replace with another file. Using the access control module 421, trusted processes are then presented with a pristine (unaltered) view of the filesystem.).
Araujo discusses an access request, but doesn't expressly discuss based on determining that the first file identifier is present in the upper filesystem layer, return, from the upper filesystem layer, the obscured file to the process that issued the access request.
Arikapudi teaches receive an access request from a process targeting the file identified by the first file identifier, the process being without a privilege to access the file (Arikapudi, Col. 34 Li. 2-21, The secure document sharing manager 128 receives the secure view query 1204 and, at operation B, … At operation C, the UDF client 412 locates the data file 1208 in internal stage 126 of storage platform 104, and, at operation D, performs security functions 413 on data file 1208 (e.g., file A) to generate a modified data file 1210 (e.g., file A. S). In some embodiments, the security functions 413 include … an edit password lock (e.g., requiring a password for editing the modified data file 1210), or a read password lock ( e.g., requiring a password for reading the modified data file 1210).);
determine whether the first file identifier is present in the upper filesystem layer (Arikapudi, Col. 34 Li. 7-9, a determination that data file 1208 is responsive to secure view query 1204 is made by the execution platform 110 including the UDF client 412.); and
based on determining that the first file identifier is present in the upper filesystem layer, return, from the upper filesystem layer, the obscured file to the process that issued the access request (Arikapudi, Col. 34 Li. 44-62, the secure document sharing manager 128 performs the following functions … redirects the user to a short-lived ( e.g., with a duration of 60 seconds or several minutes) pre-signed URL of the modified data file 1210 stored in internal stage 126 of the storage platform 104.).
It would have been obvious at the effective filing date of the invention to a person having ordinary skill in the art to which said subject matter pertains to have modified Araujo with the teachings of Arikapudi because it addresses security concerns that data providers have about their data (Arikapudi, Col. 4 Li. 43-48).
With respect to claim 2, Araujo in view of Arikapudi teaches the non-transitory machine-readable storage medium of claim 1, wherein the access request is received at an overlay filesystem driver from the process, and wherein the determining and the returning of the obscured file are performed by the overlay filesystem driver (Arikapudi, Col. 34 Li. 2-21, The secure document sharing manager 128 receives the secure view query 1204 … Col. 34 Li. 48-62, the secure document sharing manager 128 detects that the data consumer has activated (or selected) the scoped URL 1212 and performs additional authentication functions before granting the client device 114 access to the modified data file 1210… the secure document sharing manager 128 performs the following functions:… redirects the user to a short-lived ( e.g., with a duration of 60 seconds or several minutes) pre-signed URL of the modified data file 1210 stored in internal stage 126 of the storage platform 104.)
With respect to claim 3, Araujo in view of Arikapudi teaches the non-transitory machine-readable storage medium of claim 1, wherein the file is part of a plurality of files stored by the base filesystem layer (Araujo, Col. 9 Li. 26-27, The base filesystem in this example includes a set of base files (file 1 through file 5)), wherein the instructions upon execution cause the computer system to:
obscure the plurality of files; and add the obscured plurality of files to the upper filesystem layer, the obscured plurality of files accessible to the process (Araujo, Fig. 5 & Col. 9 Li. 37-40, base file 4 is hidden in the overlay and thus not available in the union; base file 5 is redacted or replaced in the overlay and thus only made available in the redacted form in the union.).
With respect to claim 4, Araujo in view of Arikapudi teaches the non-transitory machine-readable storage medium of claim 1, wherein the access request comprises a system call from the process (Arikapudi, Col. 19 Li. 48-50, an operation from a UDF (e.g., JAVA-based UDF) can be performed by a user code runtime 424 executing within a sandbox process 420 & Col. 20 Li. 42-46, The sandbox process 420, in an example, is a program that reduces the risk of security breaches by restricting the running environment of untrusted applications using security mechanisms such as namespaces and secure computing modes ( e.g., using a system call filter)).
With respect to claim 6, Araujo in view of Arikapudi teaches the non-transitory machine-readable storage medium of claim 1, wherein the base filesystem layer and the upper filesystem layer form a layered filesystem, and wherein the first file identifier of the file is present in both the base filesystem layer and the upper filesystem layer (Araujo, Fig. 5, base files 500 including files 1-5 and overlay referencing files 2-5).
With respect to claim 7, Araujo in view of Arikapudi teaches the non-transitory machine-readable storage medium of claim 6, wherein the instructions upon execution cause the computer system to:
when starting the process in the computer system, configure the process to use the layered filesystem (Araujo, Col. 9 Li. 5-14, a preferred Linux-based implementation leverages a kernel modification deployed as a kernel hot patch 430 (patching the kernel while it is running), and the installation of a kernel module 432 implementing the monitoring, access control, and decoy creation and injection capabilities. As depicted in FIG. 4, the hot patch 430 modifies the kernel's exec family of functions 434 to drop newly-created processes into a new mount namespace protected by the decoy filesystem. The particular overlay is chosen based on the trust model).
With respect to claim 8, Araujo in view of Arikapudi teaches the non-transitory machine-readable storage medium of claim 7, wherein the file present in the base filesystem layer is hidden from the process (Araujo, Col. 13 Li. 59-65, Writes to base files are first copied up to the overlay layer before being written using copy-on-write. This has the desirable effect of preserving the base filesystem, such that changes made by untrusted processes do not affect the base, protecting legitimate users from seeing malicious changes as well as effectively keeping a pristine copy of the filesystem immediately before the malicious process started.).
With respect to claim 9, Araujo in view of Arikapudi teaches the non-transitory machine-readable storage medium of claim 1, wherein the process is executed at a virtual compute entity in the computer system (Araujo, Col. 16 Li. 32-33, applications run inside virtual servers, or so-called "virtual machines" (VMs)).
With respect to claim 10, Araujo in view of Arikapudi teaches the non-transitory machine-readable storage medium of claim 1, wherein the process is a user space process (Araujo, Col. 8 Li. 35-38, The access control module 421 controls access to the overlays 412 by the processes 426, which execute within one or more namespaces 428 configured in user space 408.).
With respect to claim 11, Araujo in view of Arikapudi teaches the non-transitory machine-readable storage medium of claim 1, wherein obscuring the file comprises anonymizing or pseudonymizing the file (Araujo, Col. 9 Li. 46-49, Decoy files are similarly placed in carefully-chosen locations inside the upper mount, and existing files can be replaced or redacted for attacker deception).
With respect to claim 12, Araujo in view of Arikapudi teaches the non-transitory machine-readable storage medium of claim 1, wherein obscuring the file comprises encrypting the file or replacing the file with a shell file (Araujo, Col. 9 Li. 46-49, Decoy files are similarly placed in carefully-chosen locations inside the upper mount, and existing files can be replaced or redacted for attacker deception).
With respect to claim 14, Araujo in view of Arikapudi teaches the non-transitory machine-readable storage medium of claim 1, wherein the provisioning of the computer system comprises initially setting up the computer system or updating a configuration of the computer system (Araujo, Col. 8 Li. 8-11, the approach configures a set of filesystem overlays 412 that are preferably deployed on a per-process basis, providing each process with a different view of the filesystem. & Col. 10 Li. 1-4, the filesystem can be easily installed without system restart by using the kernel hot-patch to configure it into the existing production environment.).
With respect to claim 15, Araujo teaches a computer system comprising:
a hardware processor (Araujo, Col. 16 Li. 40-41); and
a non-transitory storage medium storing instructions executable on the hardware processor (Araujo, Col. 17 Li. 33-41) to:
identify a file, in a base filesystem layer, to be protected from unauthorized access (Araujo, Col. 8 Li. 65 – Col. 9 Li. 1, a configuration also specifies which files and directories to show in the overlay, which ones to hide, and which ones to replace with another file.);
retrieve the file from the base filesystem layer (Araujo, Col. 9 Li. 45-49, To hide a base file or directory, the decoy filesystem simply marks it as deleted in the overlay. Decoy files are similarly placed in carefully-chosen locations inside the upper mount, and existing files can be replaced or redacted for attacker deception);
obscure the file and add the obscured file to an upper filesystem layer that overlays the base filesystem layer (Araujo, Col. 8 Li. 14-17, Within an overlay, however, and as indicated by the key, a base file may be hidden from a process (represented by hidden file 416), or redacted or replaced (represented by replaced file 418). & Col. 9 Li. 45-49, To hide a base file or directory, the decoy filesystem simply marks it as deleted in the overlay. Decoy files are similarly placed in carefully-chosen locations inside the upper mount, and existing files can be replaced or redacted for attacker deception as previously noted.) wherein the obscured file in the upper filesystem layer in the file in the base filesystem layer share a first file identifier (Araujo, Col. 8 Li. 21-25, each overlay 412 thus has the ability to … modify the content of a base file by overlaying a different file (e.g., one that is redacted or replaced) with the same name).
Araujo doesn't expressly discuss receive, from a process, a request to access a first requested file identified by the first file identifier; determine whether the first file identifier is present in the upper filesystem layer; and based on determining that the first file identifier is present in the upper filesystem layer, return an obscured version of the first requested file from the upper filesystem layer to the process.
Arikapudi teaches receive, from a process, a request to access a first requested file identified by the first file identifier, the process being without a privilege to access the file (Arikapudi, Col. 34 Li. 2-21, The secure document sharing manager 128 receives the secure view query 1204 and, at operation B, … At operation C, the UDF client 412 locates the data file 1208 in internal stage 126 of storage platform 104, and, at operation D, performs security functions 413 on data file 1208 (e.g., file A) to generate a modified data file 1210 (e.g., file A. S). In some embodiments, the security functions 413 include … an edit password lock (e.g., requiring a password for editing the modified data file 1210), or a read password lock ( e.g., requiring a password for reading the modified data file 1210).);
determine whether the first file identifier is present in the upper filesystem layer; and based on determining that the first file identifier is present in the upper filesystem layer, return an obscured version of the first requested file from the upper filesystem layer to the process that issued the request (Arikapudi, Col. 34 Li. 44-62, the secure document sharing manager 128 performs the following functions … redirects the user to a short-lived ( e.g., with a duration of 60 seconds or several minutes) pre-signed URL of the modified data file 1210 stored in internal stage 126 of the storage platform 104.).
It would have been obvious at the effective filing date of the invention to a person having ordinary skill in the art to which said subject matter pertains to have modified Araujo with the teachings of Arikapudi because it addresses security concerns that data providers have about their data (Arikapudi, Col. 4 Li. 43-48).
With respect to claim 16, Araujo in view of Arikapudi teaches the computer system of claim 15, wherein the instructions are executable on the hardware processor to: receive, from the process or a further process, a request to access a second requested file identified by a second file identifier; determine whether the second file identifier is present in the upper filesystem layer; and based on determining that the second file identifier is not present in the upper filesystem layer, access the second requested file from the base filesystem layer and return the second requested file to the process or the further process (Araujo, Col. 8 Li. 19-21, the "view" presented to a process in a particular overlay may vary and is computed as a "union" of the base filesystem 400 and the overlay 412 & Fig. 5, Base file 1 is made available in the union for read).
With respect to claim 17, Araujo in view of Arikapudi teaches the computer system of claim 15, wherein the instructions are executable on the hardware processor to: create the upper filesystem layer during provisioning of the computer system (Araujo, Col. 8 Li. 8-11, the approach configures a set of filesystem overlays 412 that are preferably deployed on a per-process basis, providing each process with a different view of the filesystem. & Col. 9 Li. 5-10, a preferred Linux-based implementation leverages a kernel modification deployed as a kernel hot patch 430 (patching the kernel while it is running), and the installation of a kernel module 432 implementing the monitoring, access control, and decoy creation and injection capabilities.).
With respect to claim 18, Araujo in view of Arikapudi teaches the computer system of claim 15, wherein obscuring the file comprises anonymizing or pseudonymizing the file (Araujo, Col. 9 Li. 46-49, Decoy files are similarly placed in carefully-chosen locations inside the upper mount, and existing files can be replaced or redacted for attacker deception).
With respect to claim 19, Araujo teaches a method comprising:
during provisioning of a computer system (Araujo, Col. 8 Li. 8-11, the approach configures a set of filesystem overlays 412 that are preferably deployed on a per-process basis, providing each process with a different view of the filesystem. & Col. 9 Li. 5-10, a preferred Linux-based implementation leverages a kernel modification deployed as a kernel hot patch 430 (patching the kernel while it is running), and the installation of a kernel module 432 implementing the monitoring, access control, and decoy creation and injection capabilities.), creating an upper filesystem layer that overlays a base filesystem layer to form a layered filesystem (Araujo, Col. 7 Li. 66 – Col. 8 Li. 1, This architecture allows for different directory and file trees to be overlayed (i.e., superimposed) over the base filesystem 300.);
identifying a file in the base filesystem layer to be protected against unauthorized access (Araujo, Col. 8 Li. 65 – Col. 9 Li. 1, a configuration also specifies which files and directories to show in the overlay, which ones to hide, and which ones to replace with another file.);
obscuring, by the computer system, the file to produce an obscured file (Araujo, Col. 8 Li. 14-17, Within an overlay, however, and as indicated by the key, a base file may be hidden from a process (represented by hidden file 416), or redacted or replaced (represented by replaced file 418).);
adding the obscured file to the upper filesystem layer (Araujo, Col. 9 Li. 45-49, To hide a base file or directory, the decoy filesystem simply marks it as deleted in the overlay. Decoy files are similarly placed in carefully-chosen locations inside the upper mount, and existing files can be replaced or redacted for attacker deception as previously noted.) wherein the obscured file in the upper filesystem layer in the file in the base filesystem layer share a first file identifier (Araujo, Col. 8 Li. 21-25, each overlay 412 thus has the ability to … modify the content of a base file by overlaying a different file (e.g., one that is redacted or replaced) with the same name).
Araujo doesn't expressly discuss based on receipt of a file access request to access a requested file, determining, by the computer system, whether an identifier of the requested file is present in the upper filesystem layer and based on a determination that the identifier of the requested file is present in the upper filesystem layer, sending, by the computer system, an obscured version of the requested file from the upper filesystem layer to a process that submitted the file access request.
Arikapudi teaches receive a file access request from a process to access the file, identified by the first file identifier, the process being without a privilege to access the file (Arikapudi, Col. 34 Li. 2-21, The secure document sharing manager 128 receives the secure view query 1204 and, at operation B, … At operation C, the UDF client 412 locates the data file 1208 in internal stage 126 of storage platform 104, and, at operation D, performs security functions 413 on data file 1208 (e.g., file A) to generate a modified data file 1210 (e.g., file A. S). In some embodiments, the security functions 413 include … an edit password lock (e.g., requiring a password for editing the modified data file 1210), or a read password lock ( e.g., requiring a password for reading the modified data file 1210).);
determining, by the computer system, whether the first file identifier is present in the upper filesystem layer (Arikapudi, Col. 34 Li. 7-9, a determination that data file 1208 is responsive to secure view query 1204 is made by the execution platform 110 including the UDF client 412.); and
based on a determination that the first file identifier is present in the upper filesystem layer, sending, by the computer system, the obscured file from the upper filesystem layer to the process that submitted the file access request (Arikapudi, Col. 34 Li. 44-62, the secure document sharing manager 128 performs the following functions … redirects the user to a short-lived ( e.g., with a duration of 60 seconds or several minutes) pre-signed URL of the modified data file 1210 stored in internal stage 126 of the storage platform 104.).
It would have been obvious at the effective filing date of the invention to a person having ordinary skill in the art to which said subject matter pertains to have modified Araujo with the teachings of Arikapudi because it addresses security concerns that data providers have about their data (Arikapudi, Col. 4 Li. 43-48).
With respect to claim 20, Araujo in view of Arikapudi teaches the method of claim 19, wherein the first file identifier is also present in the base filesystem layer (Araujo, Fig. 5, base files 500 including files 1-5 and overlay referencing files 2-5), and wherein the file in the base filesystem layer is hidden from the process (Col. 13 Li. 59-65, Writes to base files are first copied up to the overlay layer before being written using copy-on-write. This has the desirable effect of preserving the base filesystem, such that changes made by untrusted processes do not affect the base, protecting legitimate users from seeing malicious changes as well as effectively keeping a pristine copy of the filesystem immediately before the malicious process started.).
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Araujo in view of Arikapudi, and further in view of F. Engelhardt and M. Güneş, "A /sys Filesystem for the Internet of Things," NOMS 2022-2022 IEEE/IFIP Network Operations and Management Symposium, Budapest, Hungary, 2022, pp. 1-6, doi: 10.1109/NOMS54207.2022.9789849.
With respect to claim 5, Araujo in view of Arikapudi teaches the non-transitory machine-readable storage medium of claim 1, as discussed above. Araujo in view of Arikapudi doesn't expressly discuss wherein the access request is received through a /proc interface or a /sys interface.
Engelhardt teaches wherein the access request is received through a /proc interface or a /sys interface (Engelhardt, section I and II, /sys and /proc interfaces provide information to data).
It would have been obvious at the effective filing date of the invention to a person having ordinary skill in the art to which said subject matter pertains to have modified Araujo in view of Arikapudi because it is a common way to access data.
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over Araujo in view of Arikapudi, and further in view of H. Satou and K. Kourai, "Prevention of a DoS Attack with Copy-on-write in the Overlay Filesystem," 2021 IEEE Intl Conf on Dependable, Autonomic and Secure Computing, Intl Conf on Pervasive Intelligence and Computing, Intl Conf on Cloud and Big Data Computing, Intl Conf on Cyber Science and Technology Congress (DASC/PiCom/CBDCom/CyberSciTech), AB, Canada, 2021, pp. 76-83.
With respect to claim 13, Araujo in view of Arikapudi teaches the non-transitory machine-readable storage medium of claim 1, as discussed above.
Satou teaches wherein the file comprises a plurality of portions, and wherein the obscuring of the file comprises obscuring a first portion of the file without obscuring a second portion of the file (Satou, Fig. 6 & pg. 79, section 4.3, 3rd pa, TranslayFS needs a partial copy-up operation if a container modifies only part of a block like block 2 and 3. It copies an unmodified part from a block in the lower layer to the sparse file. When a container modifies the middle part like block 3, TranslayFS needs two copy-up operations. This partial copy-up operation is performed only to the first and last blocks per file write at most. The other intermediate blocks are never copied from the lower layer.), .
It would have been obvious at the effective filing date of the invention to a person having ordinary skill in the art to which said subject matter pertains to have modified Araujo in view of Arikapudi because the partial data copy does not suspend a container for a long time (Satou, Fig. 6 & pg. 79, section 4.3, 3rd pa).
Response to Arguments
35 U.S.C. 103
Applicant seems to argue a newly amended limitation. Applicant’s amendment has rendered the previous rejection moot. Upon further consideration of the amendment, a new grounds of rejection is made in view of Arikapudi et al. (US 11,436,363).
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 BRITTANY N ALLEN whose telephone number is (571)270-3566. The examiner can normally be reached M-F 9 am - 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, Sherief Badawi can be reached at 571-272-9782. 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.
/BRITTANY N ALLEN/Primary Examiner, Art Unit 2169
Prosecution Insights