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 .
Examiner’s Note
The prior art rejection below cites particular paragraphs, columns, and/or line numbers in the references for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art.
Claims 1 – 22 are pending. Claims 1, 8, 15, and 21 - 22 are amended; claims 19 – 20 have been previously canceled.
References were cited in previous office action.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1 – 4, 8 – 11, 15 - 18 and 21 – 22 are rejected under 35 U.S.C. 103 as being unpatentable over Zhao et al., (US PAT 10,698,925 hereinafter Zhao) in view of Vaidya et a., (US PUB 2020/0076685 hereinafter Vaidya), and further in view of Xiao et al., (US PAT 10,103,946 hereinafter Xiao).
As to claim 1, Zhao teaches a system for supporting dynamically partitioned multi-tenant namespaces, comprising:
a computer including one or more microprocessors (“…at least one processor coupled to a memory” col. 3 lines 5 – 8);
a cloud infrastructure environment (“…cloud computing environments.” Col. 2 lines 55 - 60); and
a containerized application provider within the cloud infrastructure environment (“FIG. 1 shows an information processing system 100 configured to implement functionality for grouping-based container management and data services in cloud infrastructure.” Figure 1 and col. 2 lines 60 - 66); and
[a runtime leasing service that operates with a mapping table comprising a mapping of service instances to partitions, wherein the runtime leasing service accesses the mapping table to determine which namespace each service instance should be mapped];
wherein a plurality of partitions are defined by the containerized application provider (“…the grouping-based container management action illustratively comprises implementing a particular type of host caching partition for each of the containers of the first container group. A different type of host caching partition is implemented for each of the containers of the second group.” Col. 5 lines 5 - 12), for use by a plurality of tenants (“…For example, in other embodiments, the containers may be separated into at least first and second distinct container groups based at least in part on results of comparisons of tenants associated with the containers.” Col. 5 lines 25 - 32) and service instances associated with the tenants (“…grouping-based container management and associated data services in an illustrative embodiment. The techniques 300 in this embodiment include container grouping methods and policy 320 that are illustratively based on grouping parameters including layer structure, tenants and data flows....” col. 9 lines 1 - 35);
[wherein collections of pods are grouped into collections of partitions, including that one or more pods of a plurality of pods are populated, by the containerized application provider, within each of the plurality of partitions], wherein each partition of the plurality of partitions:
includes a group of service instances (“…The grouping modules 112 provide at least a portion of the container grouping functionality of their respective corresponding ones of the nodes 102, and the services modules 114…” col. 3 lines 52 – 60) and (“…the grouping-based container management action illustratively comprises implementing a particular type of host caching partition for each of the containers of the first container group. A different type of host caching partition is implemented for each of the containers of the second group.” Col. 5 lines 5 - 12);
[is assigned a group of the pods; and
is assigned a uniquely addressable namespace; and
wherein the collections of pods provide runtimes for the service instances, and wherein respective pods are utilized only by those service instances that are mapped to respective partitions]
wherein each tenant of the plurality of tenants is assigned, respectively, to a partition of the plurality of partitions (”With regard to detection of tenant-related similarities, containers that are subject to the same tenant-specified security or isolation policy may be considered sufficiently similar for container grouping purposes…Containers owned by the same tenant based on a user identifier (“UserID”) or other information can be automatically grouped if the containers meet the particular grouping policies…” col. 10 lines 5 - 14), for use during a period of time (“Changes in layer structure, tenants, data flows and other container grouping parameters are tracked by the grouping modules 112 in the system 100 and comparisons between the containers for grouping purposes are repeat
ed periodically or under other conditions. As a result, the particular containers assigned to certain container groups can vary dynamically over time based on changes in the layer structures, tenants, data flows or other container grouping
parameters associated with those containers.” Col. 6 lines 12 – 20. Note: used during a period of time while tenants associated with container group only for certain period of time and until it is dynamically changed) by the service instances associated with and deployed (“…grouping-based container management and data services in cloud infrastructure. Such arrangements can provide highly efficient container management in dense container deployments….” Col. 1 lines 30 – 35) to a tenancy of that tenant (“The containers of the container groups are illustratively configured for executing applications on behalf of one or more tenants of cloud infrastructure of the system 100…” col. 4 lines 1 – 5 and col. 6 lines 58 - 61), [as indicated by the mapping table].
Zhao does not but Vaidya teaches wherein collections of pods are grouped into collections of partitions (e.g., pods of containers)…” para. 0036), including that one or more pods of a plurality of pods are populated, by the containerized application provider, within each of the plurality of partitions (“…Often short-lived, containers can be created and moved more efficiently than VMs, and they can also be managed as groups of logically-related elements (sometimes referred to as “pods” for some orchestration platforms, e.g., Kubernetes)…” para. 0007);
is assigned a group of the pods (“…(e.g., pods of containers)…” para. 0036) and (“…a set of one or more containers (e.g., a pod),…” para. 0041); and
is assigned a uniquely addressable namespace (“…in some cases using namespace isolation functionality that allows complete isolation of an application's (e.g., a given container)…” para. 0039) and (“…Additionally, each user, team of users, or application may be isolated within a namespace from every other user of the cluster…” para. 0052);
wherein the collections of pods provide runtimes for the service instances (“Service proxy 211 monitors for the addition and removal of service and endpoints objects, and it maintains the network configuration of the computing device 200 to ensure communication among pods and containers, e.g., using services. Service proxy 211 may also manage iptables to capture traffic to a service's virtual IP address and port and redirect the traffic to the proxy port that proxies a backed pod...” para. 0122) and (“...A service may be an abstraction that defines a logical set of pods and the policy used to access the pods. The set of pods implementing a service are selected based on the service definition....” para. 0137), and wherein respective pods are utilized only by those service instances that are mapped to respective partitions (“...Often short-lived, containers can be created and moved more efficiently than VMs, and they can also be managed as groups of logically-related elements (sometimes referred to as “pods” for some orchestration platforms, e.g., Kubernetes)...” para. 0007 and 0073).
It 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 was made to modify Zhao by applying the teachings of Vaidya because Vaidya teaches the same field of the invention of managing containerized applications (para. 0007) and Vaidya would provide namespace isolation to maintain complete isolation of an application for multi-tenancy platform (para. 0039).
Zhao and Vaidya do not but Xiao teaches a runtime leasing service that operates with a mapping table comprising a mapping of service instances to partitions (“…a foreign JMS server feature which maps remotely hosted JMS connection factories and JMS destinations into a local partition's Java naming and directory interface (JNDI), so that bridges and applications in turn gain access to these resources by looking them up in this name-space. “ col. 2 lines 5 – 15 and col. 17 lines 62 – col. 18 lines 3. Note: the specification (para. 0124) defines “mapping stored in external store to determine which namespace each service instance should be mapped to. Such lookup could be performed…”. Xiao’s foreign JMS server with the mapping is claimed runtime leasing service that operates with a mapping. Bridges and applications are service instances) and (“…customizing the foreign JMS server URLs, usernames, passwords, and mapped remote queue names of a resource group template or resource group on a per partition basis.” Col. 18 lines 24 – 29. Note: mapping per partition basis, and there are a plurality of partitions) and (“…in order to support foreign JMS servers in a partitionable, multi-tenant environment, in a partition, the data source JNDI name that is configured in an foreign JMS server can be used to lookup a data source and obtain a connection for the partition's PDB, and on a client, the JMS connection factory that is returned contains a URL that is specific to the PDB for the JNDI name-space of the partition that client is communicating with….” Col. 18 lines 53 – 67. Note: mapping to namespace is mapping to partition since partition has namespace), wherein the runtime leasing service accesses the mapping table to determine which namespace each service instance should be mapped and as indicated by the mapping table (“… a foreign JMS server feature which maps remotely hosted JMS connection factories and JMS destinations into a local partition's Java naming and directory interface (JNDI), so that bridges and applications in turn gain access to these resources by looking them up in this name-space.” col. 2 lines 6 – 15. Note: the specification (para. 0124) defines “mapping stored in external store to determine which namespace each service instance should be mapped to. Such lookup could be performed…”. Xiao teaches a foreign JMS server with the mapping to map remotely into a local partitions by look them up would comprise determining which namespace when looking up. Applications are service instances).and (“In accordance with an embodiment, JMS relies on a JNDI service to provide JNDI entry isolation among partitions. The entities that the JMS binds into JNDI on behalf of JMS module deployment include connection factories, destinations, and foreign JMS servers. The partition ID is on the thread when JMS is called upon from deployment runtime and JMS creates the initial context and binds these entities using the thread in order to ensure that these entities are bound into the correct JNDI name-space. …” col. 13 lines 27 – 37).
It 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 was made to modify Zhao and Vaidya by applying the teachings of Xiao because Xiao’s lookup would provide and determine which namespace to map to (col. 13 lines 27 - 37).
As to claim 2, Zhao modified by Vaidya and Xiao teaches the system of claim 1, Zhao teaches wherein a deployment is defined within each of the plurality of partitions, each deployment managing at least one [pod] (“…grouping-based container management and data services in cloud infrastructure. Such arrangements can provide highly efficient container management in dense container deployments….” Col. 1 lines 30 – 35)
Zhao and Xiao do not but Vaidya teaches pod (“…Often short-lived, containers can be created and moved more efficiently than VMs, and they can also be managed as groups of logically-related elements (sometimes referred to as “pods” for some orchestration platforms, e.g., Kubernetes)…” para. 0007) and (“…a set of one or more containers (e.g., a pod),…” para. 0041).
It 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 was made to modify Zhao and Xiao by applying the teachings of Vaidya because Vaidya teaches the same field of the invention of managing containerized applications (para. 0007) and Vaidya would provide namespace isolation to maintain complete isolation of an application for multi-tenancy platform (para. 0039).
As to claim 3, Zhao modified by Vaidya and Xiao teaches the system of claim 2, Zhao teaches wherein each deployment provides a replica of a software application (“…grouping-based container management and data services in cloud infrastructure. Such arrangements can provide highly efficient container management in dense container deployments….” Col. 1 lines 30 – 35) and (“…Such techniques provide significant improvements in the processing of large numbers of potentially complex container image layer structures with a given dense container deployment.” Col. 8 lines 55 - 56).
As to claim 4, Zhao modified by Vaidya and Xiao teaches the system of claim 3, Zhao teaches wherein each replication of the software application is run, respectively, on each of the [pods] managed by each deployment (“…grouping-based container management and data services in cloud infrastructure. Such arrangements can provide highly efficient container management in dense container deployments….” Col. 1 lines 30 – 35) and (“…Such techniques provide significant improvements in the processing of large numbers of potentially complex container image layer structures with a given dense container deployment.” Col. 8 lines 55 - 56).
Zhao and Xiao do not but Vaidya teaches pods (“…Often short-lived, containers can be created and moved more efficiently than VMs, and they can also be managed as groups of logically-related elements (sometimes referred to as “pods” for some orchestration platforms, e.g., Kubernetes)…” para. 0007) and (“…a set of one or more containers (e.g., a pod),…” para. 0041).
It 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 was made to modify Zhao and Xiao by applying the teachings of Vaidya because Vaidya teaches the same field of the invention of managing containerized applications (para. 0007) and Vaidya would provide namespace isolation to maintain complete isolation of an application for multi-tenancy platform (para. 0039).
As to claim 8, this is a method of claim 1. See rejection for claim 1 above.
As to claims 9 - 11, these claims recite similar scope of claims 2 – 4. See rejection for claims 2 - 4 above.
As to claim 15, this is a non-transitory computer readable storage medium claim of claim 1. See rejection for claim 1 above. Further, Zhao teaches non-transitory computer readable storage medium (“processor-readable storage medium.” Col. 14 lines 32 - 34).
As to claims 16 - 18, see rejection for claims 2 - 4 above.
As to claim 21, Zhao modified by Vaidya and Xiao teaches The system of claim 1,
Zhao and Xiao do not but Vaidya teaches and is assigned a group of one or more runtime pods (“…Often short-lived, containers can be created and moved more efficiently than VMs, and they can also be managed as groups of logically-related elements (sometimes referred to as “pods” for some orchestration platforms, e.g., Kubernetes)…” para. 0007) and (“…a set of one or more containers (e.g., a pod),…” para. 0041).
It 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 was made to modify Zhao and Xiao by applying the teachings of Vaidya because Vaidya teaches the same field of the invention of managing containerized applications (para. 0007) and Vaidya would provide namespace isolation to maintain complete isolation of an application for multi-tenancy platform (para. 0039).
Zhao and Vaidya do not but Xiao teaches wherein each service instance includes a collection of resources that run in the context of a tenant (“…The container host devices implement a plurality of containers for executing applications on behalf of one or more tenants of cloud infrastructure…” abstract), wherein a runtime environment includes a containerized application provider (“FIG. 1 shows an information processing system 100 configured to implement functionality for grouping-based container management and data services in cloud infrastructure.” Figure 1 and col. 2 lines 60 - 66), and wherein a partition is associated with a group of service instances (“…foreign JMS server feature which maps remotely hosted JMS connection factories and JMS destinations into a local partition's JNDI, so that bridges and applications in turn gain access to these resources by looking them up in this name-space.” Abstract) [and is assigned a group of one or more runtime pods].
It 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 was made to modify Zhao and Vaidya by applying the teachings of Xiao because Xiao’s lookup would provide and determine which namespace to map to (col. 13 lines 27 - 37).
As to claim 22, see rejection for claim 21 above.
Claims 5 – 7 and 12 – 14 are rejected under 35 U.S.C. 103 as being unpatentable over Zhao in view of Vaidya and Xiao as applied to claims 4, 11, and 18 and further in view of Cal et al., (US PUB 2011/0213870 hereinafter Cal).
Cal reference was cited in previous office action.
As to claim 5, Zhao modified by Vaidya and Xiao teaches the system of claim 4, further comprising: Zhao does not but Vaidya teaches
a plurality of service instances, each of the plurality of service instances being associated with a different tenant of the plurality of tenants (“…Each tenant is assigned its own logical resources (virtual machines, containers, or other form of virtual execution elements; virtual storage; virtual networks). These logical resources are isolated from each other, unless specifically allowed by security policies…” para. 0143);
Zhao, Vaidya and Xiao do not but Cal teaches
a mapping table, the mapping table comprising a mapping of each of the plurality of tenants to an assigned partition of the plurality of partitions (“Tenant-partition map: it refers to a relational map from each tenant to its corresponding group with respect to a multi-tenant application. In runtime, a partition may have an address, so the tenant-partition map may be a mapping relationship between a leased identifier and the partition's address…” para 0035 and figure 4).
It 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 was made to modify Zhao, Vaidya and Xiao by adopt the teachings of Cal because Cal would provide a map stores tenant-partition relationship for the tenant and used for queries (para. 0042).
As to claim 6, Zhao modified by Vaidya and Xiao teaches the system of claim 5, Zhao and Vaidya do not but Cal teaches wherein the mapping table is stored at a database external to the containerized application provider (“Tenant-partition map: it refers to a relational map from each tenant to its corresponding group with respect to a multi-tenant application…” para. 0035).
It 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 was made to modify Zhao, Vaidya and Xiao by adopt the teachings of Cal because Cal would provide a map stores tenant-partition relationship for the tenant and used for queries (para. 0042).
As to claim 7, Zhao modified by Vaidya, Xiao and Cal teaches the system of claim 6, Zhao teaches wherein the containerized application provider comprises a Kubernetes cluster (“…container management technologies such as SWARM and Kubernetes.” Col. 13 lines 64 - 67).
As to claims 12 - 14, see rejection for claims 5 - 7 above.
Response to Arguments
IV. Claim Objections (page 7 of remark)
Applicant’s arguments, have been fully considered and are persuasive. The Claim objection has been withdrawn.
V. Claim Rejections under 35 U.S.C. § 103 (pages 8 - 12 of remark)
Applicant's arguments have been fully considered but they are not persuasive.
Applicant argued that
“...However, Applicant respectfully submits that, although Zhao appears to describe wherein a plurality of container host devices implement a plurality of containers for executing applications on behalf of one or more tenants of a cloud infrastructure; while Vaidya appears to describe wherein containers can be managed as groups of logically-related elements or pods; and Xiao appears to describe providing a messaging service in a multitenant application server environment wherein a foreign JMS server feature maps remotely hosted JMS connection factories and JMS destinations into a local partition's JNDI; neither Zhao, Vaidya, nor Zhao, when considered alone or in combination, appears to describe or render obvious, for example, wherein collections of pods are grouped into collections of partitions, including that one or more pods of a plurality of pods are populated, by the containerized application provider, wherein each partition includes a group of service instances is assigned a group of the pods, and is assigned a uniquely addressable namespace; wherein the collections of pods provide runtimes for the service instances, and wherein respective pods are utilized only by those service instances that are mapped to respective partitions.
For example, as described in Applicant's Specification, in accordance with an embodiment, collections of pods 411, 421, and 431 can be logically grouped in to partitions, such as partition 1 410, partition 2 420, and partition 3 430. In accordance with an embodiment, the collections of pods can provide complete runtimes for complete, or partial versions of software or other programs. For example, each collection of pods can provide an instance of an integration runtime environment 263, as described above. Each instance of the software or other program can be made available to users authorized to access and use the computer resources within each respective partition. In accordance with an embodiment, as show, each service instance, service instance 1 505, service instance 2 510, service instance 3 515, service instance 4 520, and service instance 5 525 can be associated with a partition of the plurality of partitions. In accordance with an embodiment, the respective pods can then be utilized only by those service instances mapped to the respective partitions. That is, put another way, service instances 1 and 2 can utilize the resources and instances of applications provided by pods 411, but cannot access or utilize the resources and instances of applications (e.g., Integration Cloud Service) provided by the pods 421 of partition 2 420. (Applicant's Specification, at Paragraphs [0100]-[0103]).
As described in Applicant's Specification, in accordance with various embodiments, the described approach can be used, for example, to provide support for limited isolation in runtime by ensuring that a subset of service instances is accessing a particular runtime container at a time (Paragraph [0089]); or to provide for flexibility in service level, such as an on-demand increase in service level for any given service instance (Paragraph [0093]).
To further recite the embodiment therein, Claim 1 has been amended as shown above to recite that, in accordance with an embodiment, a plurality of partitions are defined by the containerized application provider, for use by a plurality of tenants and service instances associated with the tenants; wherein collections of pods are grouped into collections of partitions, including that one or more pods of a plurality of pods are populated, by the containerized application provider, within each of the plurality of partitions, wherein each partition of the plurality of partitions: includes a group of service instances; is assigned a group of the pods; and is assigned a uniquely addressable namespace; wherein the collections of pods provide runtimes for the service instances, and wherein respective pods are utilized only by those service instances that are mapped to respective partitions; and wherein each tenant, of the plurality of tenants, is assigned, respectively, to a partition of the plurality of partitions, for use during a period of time by the service instances associated with and deployed to a tenancy of that tenant, as indicated by the mapping table.
In view of the above remarks, Applicant respectfully submits that Claim 1, as currently amended, is neither anticipated by, nor obvious in view of the cited references, when considered alone or in combination. Reconsideration thereof is respectfully requested.” (pages 8 – 12 of remark).
In response,
The combination of Zhao, Vaidya, and Xiao, not any alone, teaches amended claim 1.
Zhao teaches the invention of dynamically partitioned multi-tenant namespaces wherein each claimed partition is a group of service instances corresponding nodes managed as grouping-based container (col. 3 lines 52 – 60 and col. 5 lines 5 – 12).
Zhao does not but Vaidya teaches the concept of containers are grouped as pods in Kubernetes platform, called pods of containers (para. 0007 and 0036); each user of Kubernetes cluster, team of users, and container may be isolated within a namespace (para. 0039 and 0052); a group of pods created within an isolated namespace have same services (para. 0056). A service may be an abstraction that defines a logical set of pods and the policy used to access the pods. The set of pods implementing a service are selected based on the service definition (para. 0137 and 0148).
It 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 was made to modify Zhao by applying the teachings of Vaidya because Vaidya teaches the same field of the invention of managing containerized applications (para. 0007) and Vaidya would provide namespace isolation to maintain complete isolation of an application for multi-tenancy platform (para. 0039).
Therefore, Zhao does not but Vaidya teaches limitations wherein collections of pods are grouped into collections of partitions, including that one or more pods of a plurality of pods are populated, by the containerized application provider, wherein each partition includes a group of service instances is assigned a group of the pods, and is assigned a uniquely addressable namespace; wherein the collections of pods provide runtimes for the service instances, and wherein respective pods are utilized only by those service instances that are mapped to respective partitions.
Claims 8 and 15
Applicant argued that
“The remarks provided above with regard to Claim 1 are herein incorporated by reference. For similar reasons as provided above, Applicant respectfully submits that Claims 8 and 15, as currently amended, are likewise neither anticipated by, nor obvious in view of the cited references, when considered alone or in combination. Reconsideration thereof is respectfully requested.” (page 12 of remark).
In response,
Examiner refers to response for claim 1 above.
Claims 2-7, 9-14, and 16-17, and 21-22
Applicant argued that
“Claims 2-7, 9-14, 16-18, and 21-22 depend from and include all of the features of one of Claims 1, 8, or 15. Applicant respectfully submits that these claims are allowable at least as depending from an allowable independent claim, and further in view of the remarks provided above. Reconsideration thereof is respectfully requested” (page 12 of remark).
In response,
Dependent claims 2-7, 9-14, 16-18, and 21-22 are rejected as their independent claims.
Conclusion
The prior art made of record but not relied upon request is considered to be pertinent to applicant’s disclosure.
Navalie, (US PUB 2022/0350675), discloses a method for executing a set of microservices in containers organized into multi-container pods (title, abstract and figures 1 – 8).
Zahid, (US PUB 2017/0104817), discloses a mapping table for mapping class of service to virtual lanes of virtual network to support tenants associated with partitions (title, abstract and figures 1 – 13).
Patel, (US PUB 2021/0243246), discloses a method of assigning cluster node work for tenants in multi-tenant system (title, abstract and figures 1 – 5).
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to PHUONG N HOANG whose telephone number is (571)272-3763. The examiner can normally be reached 9:5-30.
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, KEVIN YOUNG can be reached on 571-270-3180. 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.
/PHUONG N HOANG/Examiner, Art Unit 2194
/KEVIN L YOUNG/Supervisory Patent Examiner, Art Unit 2194