DETAILED ACTION
Claims 1-20 are pending.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant’s following arguments with respect to the 35 U.S.C. 102(a)(1)/103 rejections (Remarks pp. 6-7) are moot in view of the Examiner’s new ground of rejections based on added references to address applicant’s amendments.
Claim Interpretation
Claim 20 recites “A computer program product comprising a computer storage medium that stores computer-executable instructions that are executable by a processor system”. The specification states, “Computer storage media are physical storage media that store computer-executable instructions and/or data structures. Physical storage media include computer hardware, such as random access memory (RAM), read-only memory (ROM), electrically erasable programmable ROM (EEPROM), solid state drives (SSDs), flash memory, phase-change memory (PCM), optical disk storage, magnetic disk storage or other magnetic storage devices, or any other hardware storage device(s) which can be used to store program code in the form of computer-executable instructions or data structures, which can be accessed and executed by a general-purpose or special-purpose computer system to implement the disclosed functionality,” (⁋ 0050). Therefore, the claimed “computer storage medium” is interpreted as being non-transitory in light of the specification (⁋ 0050).
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-2, 5-6, 11-14, 16, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Milenkoski (Virtual Secure Mode: Architecture Overview) in view of Xia (ARCHITECTURE SUPPORT FOR GUEST-TRANSPARENT VM PROTECTION FROM UNTRUSTED HYPERVISOR AND PHYSICAL ATTACKS).
Regarding Claim 1, Milenkoski teaches a method, comprising:
intercepting, by a compatibility component within a first guest privilege context of a guest partition, an input/output (I/O) operation associated with a guest operating system (OS) that operates within a second guest privilege context of the guest partition (
PNG
media_image1.png
654
819
media_image1.png
Greyscale
The claimed “guest partition” is mapped to the “Root partition” in Fig. 3. This mapping is consistent with the present application’s abstract, which states “A guest partition, corresponding to a virtual machine, is divided into a first guest privilege context and a second guest privilege context.” The “Root partition” disclosed by Milenkoski is a virtual machine, because Milenkoski states that “The Hyper-V hypervisor virtualizes hardware and hosts one or multiple virtual machines, also known as partitions (Partition A and Partition B in Figure 1),” Page 2.
The claimed “first guest privilege context” is mapped to “VTL 1: Secure environment” in Fig. 3.
The claimed “second guest privilege context” is mapped to “VTL 0: Normal environment” in Fig. 3.
Milenkoski further discloses, “At the time of the analysis, Hyper-V implements two VTLs [(Virtual Trust Level)]: VTL 0 and VTL 1. VTL 0 hosts the traditional Windows environment consisting of the operating system parts: system support processes, services, applications, the Windows subsystem, ntdll.dll, drivers, and the kernel… This work refers to this environment as the normal environment and to the kernel running in it as the normal kernel… VTL 1 hosts a Windows environment for performing security-critical functionalities. We refer to this environment as the secure environment,” Page 4-5.
Milenkoski further discloses “When VSM is enabled, the local security authority process running in the normal environment does not perform the actual credential verification. This task is delegated to the secure, isolated counterpart of this process running in the secure environment – the IUM application lsaIso.exe. Lsass.exe and lsaIso.exe communicate over encrypted IPC channels. The isolation of the security-critical functionalities of the LSA prevents abuses of the local security authority for the purpose of accessing user credentials in an unauthorized manner,” Page 5.
The claimed “compatibility component” is mapped to the software component that checks a requested operation’s compatibility with security trust level, including credential verification.
The claimed “input/output (I/O) operation associated with a guest operating system (OS)” is mapped to the disclosed “credential verification” function calls that are sent from the normal environment VTL 0 to the secure environment VTL 1 to be received by lsaIso.exe. The “credential verification” requires reading protected credential information, which is an output operation.);
and processing, by the compatibility component, the I/O operation using a virtualization feature that is unsupported by the guest OS (
Milenkoski discloses, “VSM uses virtualization as a basis,” Page 2, and “Sample VSM features are HVCI and Credential Guard. HVCI provides code integrity verification functionalities and is implemented as part of the skci.dll module of the secure kernel. Credential Guard manages user credentials and is implemented in the lsaIso.exe trustlet,” Page 6.
The claimed “virtualization feature” is mapped to the disclosed “Credential Guard”, a VSM feature which is not supported by the normal Windows environment, but rather only the secure Windows environment.).
Milenkoski does not teach wherein the compatibility component executes transparently underneath the guest OS and emulates and/or translates I/O behavior on behalf of the guest OS to provide hardware access and/or hardware protocol functionality not implemented by the guest OS.
However, Xia teaches wherein the compatibility component executes transparently underneath the guest OS and emulates and/or translates I/O behavior on behalf of the guest OS to provide hardware access and/or hardware protocol functionality not implemented by the guest OS (
Xia discloses, “To retain OS transparency and only reveal necessary information of VM to the hypervisor, HyperCoffer provides a mechanism called VM-Shim, which consists of two components: 1) hardware support to enable control interposition between the hypervisor and VMs, as stated in section 4.6 and 2) a specification of interactive data between the hypervisor and VMs, which contains CPU context, I/O data and auxiliary information, as stated in section 5. The hypervisor and VM-Shim instance use the specification to communicate with each other,” Page 5,
“The software implementation of VM-Shim only depends on the specification. Unlike OS-specific drivers in paravirtualization system, VM-Shim is OS-independent and can run without any awareness of the guest OS. Thus, the VM-Shim mechanism enables HyperCoffer to retain OS transparency in requiring no changes to guest OS, which is crucial to current multi-tenant cloud. It is also highly scalable in supporting an arbitrary number of VMs,” Page 5,
PNG
media_image2.png
533
1050
media_image2.png
Greyscale
“Figure 6 shows the hardware and software components of HyperCoffer. The secure processor substrate includes AISE encryption engine Ⓐ and BMT engineⒷ. Counter data is accessed through split counter cache Ⓒ, while hash data shares cache with ordinary data. Each cache line is tagged with VMID Ⓓ Ⓔ of the owner VM, and data in a cache line can be accessed only by its owner. Since both counters and hashes are indexed by GPA, a g-TLB Ⓕ is added to optimize address translation from GPA to HPA,” Page 7,
“In order to support the VM-Shim mechanism, the logic of mode switching L is changed to enable VM-Shim running in-between the hypervisor and a VM. In addition, two new instructions are added to switch mode from VM-Shim to host or guest, by shim_to_host and shim_to_guest, respectively. VMShim M is responsible to exchange data between the hypervisor and VMs, by using two new instructions: raw_ld and raw_st. Meanwhile, the hypervisor N needs to be modified to access guest’s data through the interface provided by VMShim. Thus the guest OS can remain unchanged,” Page 8,
and “The VM-Shim interposes the above process and exchange the data with the hypervisor. VM-Shim avoids the need of guest page table walking for decoding the I/O instruction by fetching the opcode in the VM context during the trap. On interposing the VM trap, VM-Shim proactively translates the mem-addr from GVA to GPA by walking the VM's page table. It then puts the plain-text version of addresses to memory using st_raw,” Page 9.
The claimed “emulates and/or translates I/O behavior” is mapped to the disclosed translation of I/O between the guest OS and the hypervisor being done by VM-Shim.
The claimed “on behalf of the guest OS” is mapped to the translation of I/O being done by VM-Shim for the guest OS.
The claimed “hardware access and/or hardware protocol functionality not implemented by the guest OS” is mapped to the disclosed hardware access provided by the hardware components of the HyperCoffer system, with new instructions that don’t require support by the guest OS (e.g. raw_ld, raw_st).
The claimed “executes transparently underneath the guest OS” is mapped to the disclosed execution of the VM-Shim, which is transparent to the guest OS.
After the combination of Milenkoski with Xia, the compatibility component as disclosed by the primary reference resides in a virtual machine with similar features from the VM-Shim of Xia.).
Milenkoski and Xia are both considered to be analogous to the claimed invention because they are in the same field of computer architecture. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Milenkoski to incorporate the teachings of Xia and provide wherein the compatibility component executes transparently underneath the guest OS and emulates and/or translates I/O behavior on behalf of the guest OS to provide hardware access and/or hardware protocol functionality not implemented by the guest OS. Doing so would help provide extra security for the guest OS (Xia discloses, “Further, as one reason for the success of virtualization is backward compatibility with existing OSes, it is demanding that HyperCoffer should not sacrifice backward compatibility in requiring changes to guest OSes,” Page 4.).
Claim 13 and Claim 20 are a computer system claim and a computer program product claim, respectively, corresponding to the method Claim 1. Therefore, Claim 13 and Claim 20 are rejected for the same reason set forth in the rejection of Claim 1.
Regarding Claim 2, Milenkoski in view of Xia teaches the method of claim 1, wherein the second guest privilege context is restricted from accessing memory associated with the first guest privilege context. (
Milenkoski discloses, “Figure 4 depicts the contents of a memory region beginning at the address 0x2779cbb0000. This region is part of a memory dump of a VSM-enabled Windows environment and is mapped to the lsaIso.exe trustlet. The memory dump is a snapshot of the memory allocated to the root partition hosting the normal and the secure environment, generated after a controlled system crash was triggered. The question mark characters (‘?’) denote unreadable memory. The memory is unreadable since it cannot be accessed outside of the isolation boundaries implemented by VTL 1, in which lsaIso.exe operates. This demonstrates the VTL-based memory access protections enforced by Hyper-V,” Page 6.
This means that the normal environment VTL 0 cannot access the memory in VTL 1).
Regarding Claim 5, Milenkoski in view of Xia teaches the method of claim 1, wherein the virtualization feature is providing access to a device via hardware protocol translation (
Milenkoski discloses, “Each partition hosts an operating system environment. If Windows-based, this environment has an architecture consisting of the Windows parts: system support processes, services, applications, the Windows subsystem, ntdll.dll, drivers, kernel, and the hardware abstraction layer,” Page 3.
The disclosed “hardware abstraction layer” acts as an intermediary or translator between the software and the hardware.).
Claim 16 is a computer system claim corresponding to the method Claim 5. Therefore, Claim 16 is rejected for the same reason set forth in the rejection of Claim 5.
Regarding Claim 6, Milenkoski in view of Xia teaches the method of claim 1, wherein the virtualization feature is virtual machine guest confidentiality (
Milenkoski discloses, “Figure 3 depicts the architecture of a VSM-enabled Windows environment. Hyper-V hosts the root partition. This partition hosts two kernel- and user-mode environments. Each kernel- and user-mode environment operates within an isolation domain, referred to as Virtual Trust Level (VTL). The concept of VTLs enforces isolation at multiple aspects…,” Page 4.
This is guest confidentiality because having different isolation domains for each environment helps restrict access to a guest environment from outside sources.).
Regarding Claim 11, Milenkoski in view of Xia teaches the method of claim 1, further comprising configuring a first virtualized bus connection within the first guest privilege context to interface with a second virtualized bus connection within the second guest privilege context (
Milenkoski discloses, “lsaIso.exe: This trustlet implements functionalities of the Local Security Authority (LSA) support process (lsass.exe). This process manages user authentication. When VSM is enabled, the local security authority process running in the normal environment does not perform the actual credential verification. This task is delegated to the secure, isolated counterpart of this process running in the secure environment – the IUM application lsaIso.exe. lsass.exe and lsaIso.exe communicate over encrypted IPC channels,” Page 5.
The claimed configuration of the “virtualized bus connections” to interface with each other is mapped to the disclosed communication of the two programs lsass.exe and 1saIso.exe – each in different environments/VTLs – over the encrypted IPC channels.).
Regarding Claim 12, Milenkoski in view of Xia teaches the method of claim 11, further comprising configuring the compatibility component to intercept I/O operations associated with the guest OS (
Milenkoski discloses, “When VSM is enabled, the local security authority process running in the normal environment does not perform the actual credential verification. This task is delegated to the secure, isolated counterpart of this process running in the secure environment – the IUM application lsaIso.exe,” Page 5.
See the above rejection of Claim 1.),
including configuring the compatibility component to listen for I/O operations at the first virtualized bus connection (
Milenkoski discloses, “lsass.exe and lsaIso.exe communicate over encrypted IPC channels,” Page 5.
1saIso.exe listens for a credential verification request, containing I/O operations relating to stored credentials, to be sent to it from lsass.exe via an encrypted IPC channel.).
Regarding Claim 14, Milenkoski in view of Xia teaches the method of claim 13, wherein configuring the compatibility component to intercept I/O operations associated with the guest OS includes configuring the compatibility component to listen for I/O operations at a first virtualized bus connection, within the first guest privilege context, that interfaces with a second virtualized bus connection within the second guest privilege context (
Milenkoski discloses, “lsaIso.exe: This trustlet implements functionalities of the Local Security Authority (LSA) support process (lsass.exe). This process manages user authentication. When VSM is enabled, the local security authority process running in the normal environment does not perform the actual credential verification. This task is delegated to the secure, isolated counterpart of this process running in the secure environment – the IUM application lsaIso.exe. lsass.exe and lsaIso.exe communicate over encrypted IPC channels,” Page 5.
See the above rejections of Claims 1, 11, and 12.).
Claims 3-4, and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Milenkoski (Virtual Secure Mode: Architecture Overview) in view of Xia (ARCHITECTURE SUPPORT FOR GUEST-TRANSPARENT VM PROTECTION FROM UNTRUSTED HYPERVISOR AND PHYSICAL ATTACKS) and Zhou (US 20210064438 A1).
Regarding Claim 3, Milenkoski in view of Xia teaches the method of claim 1. Milenkoski in view of Xia does not teach wherein the virtualization feature is accelerated access to a hardware device.
However, Zhou teaches wherein the virtualization feature is accelerated access to a hardware device (
Zhou discloses, “The foregoing content describes the structure and the management manner of the resource pool system provided in this application. The following further describes, with reference to the accompanying drawings, how to implement a message transmission method for a virtual hardware device of a single communications device on the communications device, to improve a method for accelerating, by an access component of the communications device, access to a hardware device of another hardware device in a resource pool, and reduce an access delay of hardware access performed by the communications device in the resource pool on another communications device,” ¶ 0137).
Milenkoski in view of Xia, and Zhou are both considered to be analogous to the claimed invention because they are in the same field of operating systems. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Milenkoski in view of Xia to incorporate the teachings of Zhou and provide wherein the virtualization feature is accelerated access to a hardware device. Doing so would help increase the efficiency of hardware access (Zhou discloses, “…reduce an access delay of hardware access performed by the communications device in the resource pool on another communications device,” ¶ 0137.).
Regarding Claim 4, Milenkoski in view of Xia and Zhou teaches the method of claim 3, wherein processing the I/O operation comprises processing the I/O operation with a virtual service provider for the hardware device, the virtual service provider executing within the first guest privilege context (
Milenkoski discloses, “This trustlet implements functionalities of the Local Security Authority (LSA) support process (lsass.exe). This process manages user authentication. When VSM is enabled, the local security authority process running in the normal environment does not perform the actual credential verification. This task is delegated to the secure, isolated counterpart of this process running in the secure environment – the IUM application lsaIso.exe,” Page 5.
As seen in Page 5, lsaIso.exe is a trustlet that runs in the user-mode environment that exists on VTL 1, which is the secure environment that the claimed “first guest privilege context” is mapped to.).
Claim 15 is a computer system claim corresponding to the method Claims 3 and 4. Therefore, Claim 15 is rejected for the same reason set forth in the rejection of Claims 3 and 4.
Claims 7 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Milenkoski (Virtual Secure Mode: Architecture Overview) in view of Xia (ARCHITECTURE SUPPORT FOR GUEST-TRANSPARENT VM PROTECTION FROM UNTRUSTED HYPERVISOR AND PHYSICAL ATTACKS) and Bardhan (US 9430330 B1).
Regarding Claim 7, Milenkoski in view of Xia teaches the method of claim 6. Milenkoski in view of Xia does not teach wherein processing the I/O operation comprises managing a page visibility flag for a memory page used to store a payload of the I/O operation.
However, Bardhan teaches wherein processing the I/O operation comprises managing a page visibility flag for a memory page used to store a payload of the I/O operation (
Bardhan discloses, “Further, an entry representing a data or metadata block/file may contain a visibility field 840 for storing one or more visibility flags 840. In some embodiments, even if a user is properly credentialed (e.g. is authenticated, and has one or more defined permissions), some modes of operation enforce a combination of permission and visibility indicators,” Col 20, Lines 56-62.).
Milenkoski in view of Xia, and Bardhan are both considered to be analogous to the claimed invention because they are in the same field of operating systems. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Milenkoski in view of Xia to incorporate the teachings of Bardhan and provide wherein processing the I/O operation comprises managing a page visibility flag for a memory page used to store a payload of the I/O operation. Doing so would help provide greater security (Bardhan discloses, “In some embodiments, even if a user is properly credentialed (e.g. is authenticated, and has one or more defined permissions), some modes of operation enforce a combination of permission and visibility indicators,” Col 20, Lines 59-62.).
Claim 17 is a computer system claim corresponding to the method Claim 7. Therefore, Claim 17 is rejected for the same reason set forth in the rejection of Claim 7.
Claims 8-9 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Milenkoski (Virtual Secure Mode: Architecture Overview) in view of Xia (ARCHITECTURE SUPPORT FOR GUEST-TRANSPARENT VM PROTECTION FROM UNTRUSTED HYPERVISOR AND PHYSICAL ATTACKS) and Morris (US 20100313150 A1).
Regarding Claim 8, Milenkoski in view of Xia teaches the method of claim 6. Milenkoski in view of Xia does not teach wherein processing the I/O operation comprises copying a payload of the I/O operation from a guest-private memory page to a host-visible memory page.
However, Morris teaches wherein processing the I/O operation comprises copying a payload of the I/O operation from a guest-private memory page to a host-visible memory page (
Morris discloses, “Likewise, synchronization component 202 can facilitate a transfer of data between private memory 118 and public memory 120 for a single computing node 106,” ¶ 0045.
The broadest reasonable interpretation of the claimed “payload” is the actual data that is being transmitted or delivered.).
Milenkoski in view of Xia, and Morris are both considered to be analogous to the claimed invention because they are in the same field of operating systems. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Milenkoski in view of Xia to incorporate the teachings of Morris and provide wherein processing the I/O operation comprises copying a payload of the I/O operation from a guest-private memory page to a host-visible memory page. Doing so would help allow for controlling what data should be accessed versus what data should not be accessed. (Morris discloses, “however, upon decoupling, in some cases it can be desired that decoupled computing nodes 106 not have access to certain data,” ¶ 0045.).
Regarding Claim 9, Milenkoski in view of Xia teaches the method of claim 6. Milenkoski in view of Xia does not teach wherein processing the I/O operation comprises copying a payload of the I/O operation from a host-visible memory page to a guest-private memory page.
However, Morris teaches wherein processing the I/O operation comprises copying a payload of the I/O operation from a host-visible memory page to a guest-private memory page (
Morris discloses, “Likewise, synchronization component 202 can facilitate a transfer of data between private memory 118 and public memory 120 for a single computing node 106,” ¶ 0045).
Milenkoski in view of Xia, and Morris are both considered to be analogous to the claimed invention because they are in the same field of operating systems. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Milenkoski in view of Xia to incorporate the teachings of Morris and provide wherein processing the I/O operation comprises copying a payload of the I/O operation from a host-visible memory page to a guest-private memory page. Doing so would help allow for controlling what data should be accessed versus what data should not be accessed. (Morris discloses, “however, upon decoupling, in some cases it can be desired that decoupled computing nodes 106 not have access to certain data,” ¶ 0045.).
Claim 18 is a computer system claim corresponding to the method Claims 6, 8, and 9. Therefore, Claim 18 is rejected for the same reason set forth in the rejection of Claims 6, 8, and 9.
Claims 10 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Milenkoski (Virtual Secure Mode: Architecture Overview) in view of Xia (ARCHITECTURE SUPPORT FOR GUEST-TRANSPARENT VM PROTECTION FROM UNTRUSTED HYPERVISOR AND PHYSICAL ATTACKS) and Chanoch (US 20160323297 A1).
Regarding Claim 10, Milenkoski in view of Xia teaches the method of claim 6. Milenkoski in view of Xia does not teach wherein processing the I/O operation comprises handling a hardware-triggered exception associated with the I/O operation.
However, Chanoch teaches wherein processing the I/O operation comprises handling a hardware-triggered exception associated with the I/O operation (
Chanoch discloses, “For example, the instruction set architecture of a processor may support hardware capabilities to detect security violations,” ¶ 0020, and “For example, the exception handler may receive an indication that a security exception occurred. In such circumstances, the exception handler may send information associated with the security exception to the security module instead of the program. Without limiting the claims in any way, at least one technical advantage of such interaction is that programs do not need to comprise instructions for reacting to such security exceptions. Therefore, such an advantage allows for more simple programs that may rely on services provided by a security module without the added complexity associated with the activities that the security module performs,” ¶ 0031.
After Milenkoski in view of Xia, and Chanoch are combined, the security exception being handled from Chanoch is now associated with the I/O operation related to the credential validation from Milenkoski in view of Xia, and the credential validation is one type of security operation.).
Milenkoski in view of Xia, and Chanoch are both considered to be analogous to the claimed invention because they are in the same field of operating systems. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Milenkoski in view of Xia to incorporate the teachings of Chanoch and provide wherein processing the I/O operation comprises handling a hardware-triggered exception associated with the I/O operation. Doing so would help reduce the risk of a higher-level program crashing due to being unable to handle the exception (Chanoch discloses, “Without limiting the claims in any way, at least one technical advantage of such interaction is that programs do not need to comprise instructions for reacting to such security exceptions. Therefore, such an advantage allows for more simple programs that may rely on services provided by a security module without the added complexity associated with the activities that the security module performs,” ¶ 0031.).
Claim 19 is a computer system claim corresponding to the method Claims 6 and 10. Therefore, Claim 19 is rejected for the same reason set forth in the rejection of Claims 6 and 10.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Falls et al. (US 20120311572 A1): Method and Apparatus for Implementing Virtual Proxy to Support Heterogenous Systems Management
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 ANDREW SUN whose telephone number is (571)272-6735. The examiner can normally be reached Monday-Friday 8:00-5:00.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Aimee Li can be reached on (571) 272-4169. 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.
/ANDREW NMN SUN/Examiner, Art Unit 2195
/Aimee Li/Supervisory Patent Examiner, Art Unit 2195