DETAILED ACTION
This Office Action is in response to claims filed on 07/15/2026.
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 arguments filed 07/15/2026 have been fully considered but they are not persuasive.
The applicant submits that the cited references do not teach or suggest the subject matter in the amended independent claims. Doshi is directed to transparent dynamic reassembly for resiliency in which a CLUB manager/microvisor arrangement enables “designed replaceability” so unstable, failing, degraded, or malfunctioning components may be substituted with stable components (e.g., see paras. [0022]-[0023]), rather than a microsvisor subsystem receiving an LCS request via an ePF and, in response, requesting resource functionality form a resource management system for satisfying that LCS request as recited by the independent claims. The discussion of the microvisor/CLUB-manager operations in Doshi further confirm this distinction: the microvisor controls active components and programmable routing in a logical composition, while the CLUB manager monitors health/failure events and determines whether reconfiguration is warranted (e.g., see paras [0109]-[0113]).
As described by Doshi at paras [0116] and [0125]-[0128], when a device D is identified with higher-than-normal failure/error signals, D is replaced by a primary backup device P, the system synchronizes D/P/S backup devices, freezes the server, takes D offline or places it into a degraded state, and remaps accesses targeting D to P Para. [0128] of Doshi then goes on to discuss how the process 1000 also applies when application running on a cluster/rack managed by CLUB A access remote resource (e.g., RDMA NIC/memory resources) managed by CLUB B, and if those remote resources experience an error, their local microvisor may detect the error and contact their CLUB B (i.e., their local manager) to find an alternative configuration. Thus, Doshi does not teach identifying a resource device for satisfying an LCS request received via an ePF or providing or causing provision of resource device identification information including connectivity details and an authentication token, or using that information to establish a communication channel and set up a work queue for performing the resource functionality requested by the LCS.
With regard to point (a), Examiner respectfully disagrees. In summary, Applicant argues that the combination of Doshi, Kakaiya, and Parthasarathy fail to teach the amended limitations, in particular to “identifying a resource device satisfying an LCS request received via an ePF”, or “providing or causing provision of resource device identification information include connectivity details and authenticated token, or using that information to establish a communication channel and set up a work queue for performing the resource functionality requested by the LCS” (Remarks, Pg. 12).
With regard to “identifying the at least one resource device for satisfying the LCS request, Examiner sets forth the combination of Doshi in view of Kakaiya reasonably teach the limitation. The instant specification describes the LCS generating a request for resource functionality presented to it by the ePF, and using the API subsystem to transmit the LCS request to the ePF (Specification, [0075]). Under broadest reasonable interpretation, the limitation necessitates a microvisor subsystem configured to receive a request for a resource functionality by the LCS and the microvisor transmitting the request to a resource management system to identify the resource device satisfying the requested resource functionality. The limitation additionally specifies that the request is received using an LCS API subsystem via the ePF. That is, the claimed limitations, in view of the specification, do not limit the conditions for prompting an LCS request. Even so, the Examiner does not rely on component failure-replacement context of Doshi to teach the claimed LCS request limitations.
The Examiner relies upon the combination of Doshi in view of Kakaiya to teach the amended limitations. Doshi is relied upon teaching a microvisor subsystem managing how resources are named and communicate with one another (Doshi, [0107]). The microvisor receives a signal with respect to a device “in need of attention” and transmits such signal to a resource management system, CLUB manager, in order to identify a device which provides the particular functionality (Doshi, [0122]). Kakaiya is relied upon teaching the communication configuration of an emulated physical function to an aggregated resource management system (Kakaiya, Col. 9-Col. 10). The motivation for applying Kakaiya teaching with Doshi teaching is to provide a system that allows for the allocation of resource functionality through device emulation such that enables flexible allocation of hardware resource capabilities. That is, the combination of Doshi in view of Kakaiya reasonably teaches the amended limitations with respect to handling an “LCS request” in an LCS ePF-enabled resource system.
With regard to newly amended limitations of “providing or causing provision of resource device identification information”, Examiner directs Applicant’s attention to the argument below.
Argument has not been found to be persuasive.
Applicant’s arguments with respect to claims 1, 7, and 14 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.
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, 7-11, and 14-18 are rejected under 35 U.S.C. 103 as being unpatentable over Doshi et al. Pub. No. US 2022/0114055 A1 (hereinafter Doshi) in view of Kakaiya et al. Patent No. US 11,055,147 B2 (hereinafter Kakaiya) in view of Lal et al. Pub. No. US 2021/0117246 A1 (hereinafter Lal).
With regard to claim 1, Doshi teaches a Logically Composed System (LCS) emulated Physical Function (ePF) [virtual device]-enabled resource system ([0022], The systems and techniques discussed herein enable designed replaceability so that alike components may absorb roles of each other and enable programmable (e.g. reconfigurable, etc.) communication meshes which interconnect the components to permit mapping; [0132], device virtualization through agency of operating system/virtual machine manager software by a cluster in a box manager for transparent dynamic reassembly of computing resource compositions), comprising:
a resource management system ([0022], A software agent is fully rusted and onboarded together with a CPU of a server and this software agent functions as a cluster-in-a-bx (CLUB) manager. The CLUB manager acts as a policy and control point for resiliency in the platform. The CLUB manager may assign resources or virtualize them (e.g., with help from the microvisor));
at least one resource device that is configured to provide resource functionality ([0104], The system 800 includes a server 805 and its organization pooled capabilities 810; [0105], The pooled capabilities 810 include various rack-level/sub-rack level resources that are available for dynamic course-grained allocation); and
a resource system that is coupled to the resource management system and the at least one resource device, where the resource system includes a microvisor subsystem ([0022],A hardware-based self-abstraction mechanism in the server, a microvisor, carries out reconfiguration as directed by a software agent (Examiner notes: the CLUB resource manager); [0107], A microvisor entity acts as a hardware embedded hypervisor from managing how resources are named and how they communicate with one another on the basis of those names) that is configured to:
provide, in response to LCS configuration operations by the resource management system ([0106], The devices and the meshes or collection of buses are that interconnect them are configurable dynamically. There are a set of configuration resources (such as registers) (not shown) that may be set or cleared in order to include or exclude a component and a link in a communication mesh into an active set), a Logically Composed System (LCS) ([0109], The microvisor controls which components of the server 805 and of the pooled entities 810 beyond the server 805 are active in a single logical composition) and an emulated Physical Function (ePF) [a virtual device] that is presented to the LCS as providing the resource functionality ([0132], FIG. 12, illustrates a flow chart of an example of a process 1200 for device virtualization through agency of operating system/virtual machine manager software by a cluster in a box manager for transparent dynamic reassembly of computing resource compositions … hardware virtualization enables creation of software virtual devices as backups.);
receive, from an LCS Application Programming Interface (API) subsystem in the LCS via the ePF, an LCS request for the resource functionality ([0120], The first error group 905 and the second error group 910 are evaluated by the microvisor. It applies a model 915 (e.g., a classic decision tree, etc.) to determine whether … to alert the CLUB manager (e.g., at operation 925).);
transmit, to the resource management system in response to receiving the LCS request, a microvisor request for the resource functionality ([0122], The microvisor notifies and shared with the CLUB manager various outlier behaviors indicating that a device is in need of attention due to high error rates, possible security compromise, or some other evidence of erratic behavior (e.g., at operation 1005).) that is configured to cause the resource management system to:
identify the at least one resource device for satisfying the LCS request ([0122], The CLUB manager initiates a background search to identify, a third backup device for the device in error (Examiner notes: resource device associated with a resource functionality).); and
provide or cause the at least one resource device to provide, to the microvisor subsystem, resource device identification information that identifies the at least one resource device and includes connectivity details for the at least one resource device and an authentication token for authenticating the use of the at least one resource device;
establish, with each of the at least one resource device using the resource device identification information, a respective communication channel ([0109], Components that are made active or inactive include buses or the links among them … the microvisor computes a new optimal path Q7 that connects D8 to E9 where Q7 contains other links and not link L10. The microvisor reconfigures the routing elements so that flows along P7 become routed to follow path Q7.) and set up a work queue for use in performing the resource functionality requested by the LCS; and
provide, to the LCS using the at least one resource device, the resource functionality via each respective communication channel ([0110], This programmability of active devices and which links carry communications between them allows the server 805 to be composable at the hardware level, out of the various devices, and it allows the communication methods at the hardware level to be programmed to route data and control signals between the various devices that constitute the server 805.), the ePF, and the LCS API subsystem by transferring work associated with the LCS request via the respective communication channel.
Doshi reasonably teaches the use of physical functions and a virtual device presented to a logical composition for providing a resource functionality (Doshi, [0106], [0132]). However, Doshi does not explicitly teach an emulated Physical Function, an LCS Application Programming Interface (API) subsystem, or provide the resource functionality via … the ePF, and the LCS API subsystem.
Kakaiya teaches an emulated Physical Function (ePF) (Col. 9, in some embodiments the Scalable IOV architecture 150 can define a smallest granularity of sharing of a device 152 as an “Assignable Interface” (“AI”). Conceptually, an AI is somewhat similar to a VF (From SR-IOV), although it can be much lighter-weight and can be aggregated and composed by software to form a virtual device (or “VDEV”).) …
receive, from an LCS Application Programming Interface (API) subsystem in the LCS via the ePF (Col. 10, In some embodiments, the system software composes a virtual device 220 and exposes a virtual configuration space to the guest 204. Access to this virtualized configuration space can be trapped using the second-level CPU address translation and emulated in the host software), an LCS request for the resource functionality (Col. 11, The VDCM 208 can request the VMM 212 to setup respective GPA-to-HPA mapping in the CPU second-level address translation, enabling direct access by a guest driver 210 to the backing AI MMIO); …
provide, …, the resource functionality via … the ePF, and the LCS API subsystem (Col. 13, The VDEV 220 can expose one or more system page size regions in virtual MMIO space that are set up as fully memory backed (e.g., mapped to memory with read and write access) that acts as a shared memory between Guest VM and Host VM … Similarly, a Host VM can use a virtual interrupt to notify the Guest VM about the availability of the data in this shared region.).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Kakaiya with the teachings of Doshi in order to provide a system that teaches receiving and providing a resource functionality through an emulated physical function to a logically composed system through an LCS application programming interface. The motivation for applying Kakaiya teaching with Doshi teaching is to provide a system that allows for the allocation of resource functionality through device emulation such that enables flexible allocation of hardware resource capabilities without modification of the physical device (Kakaiya, Col. 10). Doshi and Kakaiya are analogous art directed towards logical partitioning and allocation of resources. Therefore, it would have been obvious for one of ordinary skill in the art to combine Kakaiya with Doshi to teach the claimed invention in order to provide allocation of emulated physical function resources to logically composed systems through the use of system interfaces.
However, the combination does not explicitly teach establishing a communication channel and work queue with a resource device, associated with connectivity details and authentication tokens provided to a microvisor subsystem by the resource device, or transferring work via the established communication channel.
In a similar field of endeavor, Lal teaches provide or cause the at least one resource device to provide, to the microvisor subsystem resource device identification information that identifies the at least one resource device ([0651], FIG. 48 illustrates a network environment 4800 for an autonomous FPGA using an orchestration server to facilitate attestation and session setup in accordance with implementations of the disclosure.) and includes connectivity details for the at least one resource device and an authentication token for authenticating the use of the at least one resource device ([0658], In this model, the orchestration server 4810 determines which autonomous FPGAs 4830 are available and then, based on determined heuristics, determines which autonomous FPGA 4830 to assign to a given remote application 4820. The orchestration server 4810 provides the remote application 4820 with the IP address of the assigned autonomous FPGA 4830 along with the session key (token) for establishing secure communication channel as described in the flow above.);
establish, with each of the at least one resource device using the resource device identification information, a respective communication channel ([0653], (1) In a first step 4801, remote application 4820 requests orchestration server 4810 to attest the FPGA 4830 to which it has offloaded its bitstream to and request a session key; [0654], (2) In a second step 4802, the orchestration server 4810 uses standard attestation and key setup protocol, such as Diffie Hellman or SPDM 1.1 to verify the device, its configuration, and the bitstream loaded on the autonomous FPGA 4830 and establishes a shared secret key with the autonomous FPGA 4830; [0657], (5) In a fifth step 4805, the autonomous FPGA 4830 unwraps the data keys using the session keys it had stored at the end of Diffie Hellman protocol (e.g., at the second step 4802). These data keys are then used to protect all messages and data transferred between the remote application 4820 and the autonomous FPGA 4830.) and set up a work queue for use in performing the resource functionality requested by the LCS ([0197], The data structures for RDMA may include, but are not limited to, a physical buffer list (PBL) 1130, a translation and protection table (TPT) 1140, and a plurality of queues including queue pairs (QP) 1175, a shared receive queue (RxQ) 1150, and completion queue 1120. The QP 1175 may include, but is not limited to, a receive queue (Q) 1155 and send Q 1160. The QP 1175 may be communicably connected to an inbound read request queue 1165 and an outbound read request queue 1170 of an RNIC in NIC space 1180. NIC space 1180 may further be implemented as a protection domain 1180 that is established by a privileged consumer to associate one process to its resources; [0633], Network configuration: Facilitate session setup with the remote application by configuring network registers, such as programming FPGA’s RDMA interface); and
provide, to the LCS using the at least one resource device, the resource functionality via each respective communication channel, the ePF, and the LCS API subsystem by transferring work associated with the LCS request via the respective communication channel ([0185], The data, and sometimes commands, of an application running on a distributed system, are transferred between processing elements to cooperate in the computation. Computation resources (time and logic) used to transfer workloads are counted as overhead of distributed computation relative to processing the workload on processing elements on the same platform (directly connected components).).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Lal with the teachings of Doshi and Kakaiya in order to provide a system that teaches resource device communication channel establishment associated with connectivity details and authentication tokens for facilitating work transfer. The motivation for applying Lal teaching with Doshi and Kakaiya teaching is to provide a system that allows for secure allocation of resources to meet workload requirements (Lal, [0184]). Doshi and Kakaiya and Lal are analogous art directed towards logical partitioning and allocation of resources. Therefore, it would have been obvious for one of ordinary skill in the art to combine Lal with Doshi and Kakaiya to teach the claimed invention in order to provide authenticated transfer of work through a secure communication channel of a resource device.
With regard to claim 2, Doshi, Kakaiya, and Lal teach the system of claim 1
Doshi further teaches wherein the at least one resource device is an accelerator device ([0104], The system 800 inlcudes a server 805 and its organization, pooled capabilities 810; [0105], The pooled capabilities 810 include various rack-level/sub-rack level resources that are available for dynamic coarse-grained allocation and sharing among servers and may include … pooled fixed-function accelerator units).
With regard to claim 3, Doshi, Kakaiya, and Lal teach the system of clam 2
Doshi further teaches wherein the accelerator device is a graphics processing system ([0104], The server 805 includes XPUs 815 (e.g., CPUs, GPUs, etc.)).
With regard to claim 4, Doshi, Kakaiya, and Lal teach the system of claim 1
Doshi further teaches wherein the at least one resource device includes a local resource device ([0104], The server 805 includes XPU 815 (e.g., CPUs, GPUS, etc.), ethernet PF/VFs 820, memory modules 825 (e.g., DIMMs, non-volatile DIMMSs (NVDIMMs), etc.), and storage devices 830) that the resource management system identifies for satisfying the LCS request by instructing the microvisor subsystem to establish the respective communication channel with the local resource device ([0115], For the CLUB mechanisms hardware 840 level actions, it communicates (synchronously) with the microvisor; [0116], When a device D with higher than normal failure or error signals is identified, D is replaced by a primary backup device P, and a role of the primary backup may be given to a pre-identified secondary device S. A new secondary device is then identified).
With regard to claim 7, Doshi teaches an Information Handling System (IHS) ([0019], A modern networked computing node (e.g., server) comprises a multiplicity of alike physical units), comprising:
a microvisor processing system ([0022], A hardware-based self-abstraction mechanism in the server, a microvisor, carries out reconfiguration actions as directed by a software agent); and
a microvisor memory system that is coupled to the microvisor processing system and that includes instructions that, when executed by the microvisor processing system, cause the microvisor processing system to provide a microvisor engine ([0107], A microvisor entity acts as a hardware embedded hypervisor for managing how resources are named and how they communicate with one another on the basis of those names. The microvisor may be implemented in an infrastructure processing unit (IPU), may be within a platform CPUs as a hardware logic block, in a management controller such as a baseband management controller (BMC), or in an engine such as a management engine … The microvisor operations are of interest to platform hardware which is implementation specific, and to the CLUB manager 835) that is configured to:
Claim 7 is an information handling system having similar limitations as claim 1. Thus, claim 7 is rejected for the same rationale as applied to claim 1.
With regard to claim 8, it is an information handling system having similar limitations to claim 2. Thus, claim 8 is rejected for the same rationale as applied to claim 2.
With regard to claim 9, it is an information handling system having similar limitations to claim 3. Thus, claim 9 is rejected for the same rationale as applied to claim 3.
With regard to claim 10, it is an information handling system having similar limitations to claim 4. Thus, claim 10 is rejected for the same rationale as applied to claim 4.
Claims 5-6, 12-13, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Doshi in view of Kakaiya in view of Lal as applied to claim 1, 7, and 14 above, and further in view of Parthasarathy et al. Patent No. US 11,550,637 B2 (hereinafter Parthasarathy).
With regard to claim 5, Doshi, Kakaiya, and Lal teach the system of claim 1
Doshi further teaches wherein the at least one resource device includes a remote resource device ([0128], The process 1000 is also applicable where applications are running on a cluster/rack managed by a CLUB manager, CLUB A and access remote resources (e.g., memory read/write via remote diect memory access (RMDA) NIC) managed by another manager CLUB B.) that the resource management system identifies for satisfying the LCS request ([0128], If one or multiple remote resources (e.g., RDMA NIC and memory region, etc.) experience an error, their local microvisor may detect the error and may contact the local CLUB manager (CLUB B) to find an alternative configuration) by instructing the remote resource device to establish the respective communication channel with the microvisor subsystem ([0115], For the CLUB mechanisms hardware 840 level actions, it communicates (synchronously) with the microvisor).
Doshi and Kakaiya reasonably teaches logically composable systems comprising of remote resource managed independently. However, Doshi and Kakaiya does not explicitly teach the establishment of communication channel particularly of a remote device.
Parathasarathy teaches instructing the remote resource device to establish the respective communication channel (Col. 14, The resource manager 401 then, according to the data object, communicates with the computing racks 112-1 to 112-k to allocate resources from the resource pool 320 and to build the target composed-node; Col. 10, In certain configurations, the pod manager 178 may utilize a manageability FW API (firmware) … to access to the configurable computing resources at the computing racks 112-1 to 112-k. This access may include access to disaggregated physical elements maintained at racks … In particular, the manageability FW API 440 provides access to the RMM 120 and the PSME 232)
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Parathasarathy with the teachings of Doshi, Kakaiya, and Lal in order to provide a system that teaches remote resource device communication channel instruction establishment. The motivation for applying Parathasarathy teaching with Doshi, Kakaiya, and Lal teaching is to provide a system that allows for remote resource communication management structure to allocate resources to a system at the sub-composed node granularity level (Parathasarathy, Col. 8)). Doshi, Kakaiya, Lal and Parathasarathy are analogous art directed towards logically composed system resource allocation and management. Therefore, it would have been obvious for one of ordinary skill in the art to combine Parathasarathy with Doshi, Kakaiya, and Lal to teach the claimed invention in order to provide an interface that enable remote resource device communication.
With regard to claim 6, Doshi, Kakaiya, and Lal teach the system of claim 5
Doshi further teaches wherein the microvisor subsystem includes a microvisor agent ([0108], In an example, multiple distributed microvisors may form a microvisor cluster with full-mesh logical connectivity between them while exposing a single microvisor to the rest of the system 800 making the microvisor a full resilient component) that is configured to establish the respective communication channel with the remote resource device ([0105], The pooled capabilities 810 include various rack-level/sub-rack level resources that are available for dynamic course-grained allocation and sharing among servers … that may be interconnected with one another and with servers such as server 805 over compute express links (CXLs) and switches; [0106], There are a set of configuration resources … that may be set or cleared in order to include or exclude a component and a link in a communication mesh into an active set)
Doshi reasonably teaches remote resource incorporation. However, Doshi, Kakaiya, and Lal do not explicitly teach that the remote resource incorporation in accordance with a remote resource agent associated with the remote resource device.
via a remote resource agent (Col. 8, In certain configurations, each computing drawer 230 may include a PSME 232 (Examiner notes: Pooled System Management Engine); Col. 8, In particular, the pod manager 178 (Examiner notes: CLUB manager of Doshi) is responsible for discovery of resources in the computing pod 110, configuring the resources, and power and reset control, power management, fault management, monitoring resources usage. The pod manager 178 interacts with the RMM 120 and the PSME 232 to create presentation of the computing pod 110. The pod manager 178 allows composing a physical node to match the logical node requirements) provided for the remote resource device (The pod manager 178 may be connected to the RMM 222 and the PSME 232 through the network 108 (e.g., a private network). A management related activity such as reconfiguration may be performed after establishing a secure communication channel between the pod manager 178 and the PSME 232).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Parathasarathy with the teachings of Doshi, Kakaiya, and Lal in order to provide a system that teaches remote resource management engine establishing communication channel associated with a remote resource device. The motivation for applying Parathasarathy teaching with Doshi, Kakaiya, and Lal teaching is to provide a system that allows for remote resource device interface hardware enabling the provisioning of resource of individual nodes associated with individual resource modules (Parathasarathy, Col. 9). Doshi, Kakaiya, Lal and Parathasarathy are analogous art directed towards logically composed system resource allocation and management. Therefore, it would have been obvious for one of ordinary skill in the art to combine Parathasarathy with Doshi, Kakaiya, and Lal to teach the claimed invention in order to provide a remote management structure associated with a communication channel for obtaining remote resources for a logically composed system.
With regard to claim 12, it is an information handling system having similar limitations to claim 5. Thus, claim 12 is rejected for the same rationale as applied to claim 5.
With regard to claim 13, it is an information handling system having similar limitations to claim 6. Thus, claim 13 is rejected for the same rationale as applied to claim 6.
With regard to claim 19, it is a method having similar limitations to claim 5. Thus, claim 19 is rejected for the same rationale as applied to claim 5.
With regard to claim 20, it is a method having similar limitations to claim 6. Thus, claim 20 is rejected for the same rationale as applied to claim 6.
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 IVAN A CASTANEDA whose telephone number is (571)272-0465. The examiner can normally be reached Monday-Friday 9:30AM-5:30PM 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, Aimee Li can be reached at (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.
/I.A.C./Examiner, Art Unit 2195
/Aimee Li/Supervisory Patent Examiner, Art Unit 2195
