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 .
Election/Restrictions
Applicant’s election without traverse of Group II (claims 8-14) in the reply filed on 29 July 2026 is acknowledged.
Claims 1-7 are withdrawn from further consideration pursuant to 37 CFR 1.142(b) as being drawn to a nonelected invention, there being no allowable generic or linking claim. Election was made without traverse in the reply filed on 29 July 2026.
Claim Interpretation
MPEP § 2111.01, subsection I, provides that, under a broadest reasonable interpretation (BRI), words of the claim must be given their plain meaning, unless such meaning is inconsistent with the specification. The plain meaning of a term means the ordinary and customary meaning given to the term by those of ordinary skill in the art at the relevant time. The ordinary and customary meaning of a term may be evidenced by a variety of sources, including the words of the claims themselves, the specification, drawings, and prior art. However, the best source for determining the meaning of a claim term is the specification.
In accordance therewith, Examiner will interpret the meaning of claim term "protectorate" found at paragraph [0033] on pp. 4-5 within the specification as “Protectorates in accordance with many embodiments of the invention can refer to a combination of various elements, such as (but not limited to) domains, management functions, data, business rules, applications, user roles, and/or groups, which can be provided for multiple separate organizations operating on a set of one or more instances of a multi-instance architecture”.
Examiner will interpret the meaning of claim term “multi-protectorate” found at paragraphs [0033] on pp. 4-5 as “Multi-protectorate systems in accordance with a variety of embodiments of the invention can provide for data separation using domains, which maintain boundaries between protectorates. In many embodiments, multiple different tenants (or companies) may each operate independently and securely within a protectorate of a multi-protectorate system”.
Examiner will interpret the meaning of claim term “prefix” found at paragraphs [0075-0076] on p. 16 as information “assigned” to a “record number” that “avoids duplication across instances”.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 13 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 13 recites “monitoring information”. It is unclear whether this refers to the previously recited “monitoring” of “information”. Examiner will assume that this is the case.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 8-13 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by US 20200007457 A1 to Greenstein et al. (“Greenstein”).
Regarding claim 8, Greenstein taught a method for creating multi-protectorate architectures on an instanced architecture, the method comprising:
receiving a request to provision a new protectorate; communicating with an instanced architecture to create the new protectorate; (consider paragraphs 0004-0006, specifically “Cloud services are provisioned on demand. When a customer orders a service, an order processing system receives the type of service being ordered and submits the request to a service provisioning system, which initiates service provisioning. Service provisioning involves creation, configuration, and startup of the instance… The cloud computing environment hosts various services (cloud services) that can be accessed remotely (by remote devices, programs, or people) over a network. As used herein, a remote device accessing the cloud computing environment may correspond to a program executing code, a user, etc. utilizing a remote device (hardware or software) to access the cloud computing environment over a network. Some cloud services are shared—where all users access the same instance of a service. Other cloud services require existence of a service instance per user or group of users. The latter, in order to be used by a particular party, need to be provisioned… A user will subscribe to the cloud computing environment by providing identifying information and an intent to utilize one or more services in the future. Once the subscriber is defined, the subscriber can request access to a service instance. When a request for access to the service is received from a remote device, an instance of the service is created on-demand and executed. On-demand creation and execution of the instance is triggered when the cloud computing environment receives the request for access to the service. A service instance (hereinafter “instance”) is a collection of one or more computing resource(s) interrelated in a way defined by the particular service and comprising an orderable and provisionable unit of the service. The instance can be hosted within a virtual machine that executes software of the service using processor, memory, and storage resources of the cloud computing environment. The instance can be comprised of a collection of virtual machines of diverse shapes.”) (consider further paragraph 0029, specifically “An instance of a service is provisioned by configuring one or more VM shapes (e.g., specifications of CPU, CPU cycles, a number of processors, memory resources, storage resources, and networking resources) to a computing environment based on the type of service requested. The computing environment (e.g., a virtual machine) is configured to execute the executable code of the service through the provisioned instance. That is, a provisioning system determines an appropriate VM shape and uses resources to create one or more virtual machines to execute a service instance being provisioned. In one embodiment, resources include instances of other services.”) (consider also paragraph 0030, “Zones are defined within the cloud computing environment for hosting instances. A zone comprises a pool of available resources such as processor, memory, storage, network, and/or other computing resources that can be used by instances assigned to that zone for execution. The zone is an elastic operational environment that is able to adapt to service workload changes by provisioning and de-provisioning computing resources used by instances in an autonomous manner. The zone can be defined as a logical or physical entity for hosting instances of services utilizing virtual machines and the computing resources of the zone. The cloud computing environment, including one or more data centers, can comprise a plurality of zones.”)
monitoring information about a plurality of protectorates operating on a set of one or more instances of the instanced architecture; (consider paragraph 0019, “Provider networks, and other systems that utilize or offer virtual computing resources, may take advantage of the ability operate a virtual compute instance at multiple different locations on different physicals resources, such as different server hosts. For example, provider networks may implement thin provisioning policies which places virtual computing resources in a way that potentially overpromises the resources available at a server. Typically, virtual compute instances do not utilize all of the physical resources promised or allocated to the virtual compute instance at a host at the same time. Therefore, overpromising resources at the server host does not typically create problems of insufficient resources. However, in some circumstances, such as when behavior or workload of an instance significantly changes, the thin provisioning of a particular server host for the instance may risk violating performance guarantees or other resource allocations to the instance or other instances at the server host. Instead, the instance (or another instance) may be migrated to a different server host in order to alleviate the change in resource utilization at the source server host.”) (consider further paragraph 0046, specifically “Control plane 220 as noted above may manage the deployment, migration, utilization, and other aspects of virtual compute instances hosted in a virtual computing service, such as service 210 in FIG. 2. In at least some embodiments, control plane 220 may implement resource management 310. Resource management 310 may make placement decisions for new instances and migration decisions for currently operating instances. For instance, resource management 310 may monitor resource utilization data collected by resource utilization reporting agents 332 located at virtualization hosts 330. Processing utilization, storage utilization, network utilization, or utilization of any other physical resource may be reported to resource management 310. Based on the utilization information, resource management 310 may identify migration operations for different instances currently operating at hosts 330. Different provisioning schemes, such as thin provisioning, may trigger migration operations for instances.”)
moving a protectorate from a first instance to a second instance based on the monitored information. (consider paragraph 0021, “Network-based storage resources are often used in conjunction with virtual computing resources, such as instances. For example, as discussed below in FIG. 2, network-based storage resources may provide virtual block-based data volumes (e.g., virtualized disk storage) to instances. Live migration of instances connected to network-based resources creates potential scenarios where data stored for an instance may be placed in an unexpected state. For example, if an instance sends requests to modify data at the network-based storage resource and then is subsequently migrated to the other host, the instance may rely upon the performance of the modifications, without having confirmed whether the modifications were completed. In various embodiments discussed below, live migration of resources that utilize network-based storage may be performed in order to provide an expected state of data in the network-based storage for the migrated resource.”) (consider further paragraph 0032, “In response to receiving a request to migrate an executing instance of a service, the pre-provisioned instance is provisioned by executing the executable code using the computing environment of computing resources of the zone. Because the pre-provisioned instance already comprises the computing environment of computing resources and the application stack, the pre-provisioned instance can be quickly and efficiently provisioned as a migrated instance of the executing instance. The executing instance can be decommissioned, and subsequent access requests for the service are routed to the migrated instance.”)
Regarding claim 9, Greenstein taught the method of claim 8, wherein:
the request to provision a new protectorate is from a user; (again, consider paragraphs 0004-0006, specifically “Cloud services are provisioned on demand. When a customer orders a service, an order processing system receives the type of service being ordered and submits the request to a service provisioning system, which initiates service provisioning. Service provisioning involves creation, configuration, and startup of the instance…On-demand creation and execution of the instance is triggered when the cloud computing environment receives the request for access to the service.”)
the method further comprising:
generating a user record for the user; (consider paragraph 0005, specifically “As used herein, a remote device accessing the cloud computing environment may correspond to a program executing code, a user, etc. utilizing a remote device (hardware or software) to access the cloud computing environment over a network. Some cloud services are shared—where all users access the same instance of a service. Other cloud services require existence of a service instance per user or group of users. The latter, in order to be used by a particular party, need to be provisioned.”) (consider further paragraph 0053, “The cloud computing environment comprises a data tier. The data tier comprises a plurality of storage devices, databases, and data access functionality. Client data of clients that utilize the services of the cloud computing environment is stored within the data tier. In this way, when a remote client computer invokes an instance of a service to execute, the instance will process client data that is stored within the data tier for that remote client computer. For example, a user of the remote client computer may log into the cloud computing environment through a user account. The user account may have access rights to certain storage within the data tier. Thus, client data of the user is stored within such storage.”) and
generating an onboarding record for the new protectorate. (consider further paragraph 0028, “In one embodiment, instances are assigned to pools and located by pointers and/or tags that identify an assignment relationship between an instance and a pool. A pool of instances is defined by a collection of pointers that belong to that pool. Assigning an instance to a pool involves adding a pointer of the instance to the collection of pointers of the pool. Moving an instance from one pool to another pool involves removing the pointer from a current pool and reassigning (by adding) the pointer of the instance to a different pointer collection associated with the other pool. In one embodiment, a list or collection of pointers is maintained for each pool that identifies the instances that belong to that pool.”) (consider further paragraph 0039, specifically “The migration module 105 maintains a pool 140 of pre-provisioned instances within the second zone 130. The pool 140 is defined by a collection of instance pointers that identify the instances that are assigned to the pool 140. For example, the migration module 105 constructs a pre-provisioned instance 145 of the service (B) within the pool 140 and adds a corresponding instance pointer of instance 145 to the collection of instance pointers (a pointer list) for the pool 140. The pre-provisioned instance 145 comprises a collection of computing resources of the second zone 130 as a computing environment that can be used to execute executable code of the service (B). The computing environment may comprise processor, memory, storage, network resources, a virtual machine, and/or other computing resources used to execute the executable code.”)
Regarding claim 10, Greenstein taught the method of claim 9, wherein the user record is created in an onboarding domain and creating the new protectorate comprises:
creating a new domain; creating a set of records in the new domain; and moving the user record for the user from the onboarding domain to the new domain. (again, consider paragraph 0005, specifically “As used herein, a remote device accessing the cloud computing environment may correspond to a program executing code, a user, etc. utilizing a remote device (hardware or software) to access the cloud computing environment over a network. Some cloud services are shared—where all users access the same instance of a service. Other cloud services require existence of a service instance per user or group of users. The latter, in order to be used by a particular party, need to be provisioned.”) (consider paragraphs 0027-0028, “A “pool” of instances, in one embodiment, is defined by a collection of instance pointers that identifies the instances that belong to the pool. For example, a data structure is created to maintain the collection of instance pointers for each pool. When an instance is assigned to a pool, its pointer is added to the corresponding collection of pointers for that pool (e.g., a pool pointer list). When an instance is removed from a pool, its pointer is removed from the corresponding collection of pointers. Moving an instance from pool 1 to pool 2 is a combination of removing the pointer from pool 1 and adding the pointer to the collection of pointers for pool 2. In one embodiment, instances are assigned to pools and located by pointers and/or tags that identify an assignment relationship between an instance and a pool. A pool of instances is defined by a collection of pointers that belong to that pool. Assigning an instance to a pool involves adding a pointer of the instance to the collection of pointers of the pool. Moving an instance from one pool to another pool involves removing the pointer from a current pool and reassigning (by adding) the pointer of the instance to a different pointer collection associated with the other pool. In one embodiment, a list or collection of pointers is maintained for each pool that identifies the instances that belong to that pool.”) (again, consider further paragraph 0039, specifically “The migration module 105 maintains a pool 140 of pre-provisioned instances within the second zone 130. The pool 140 is defined by a collection of instance pointers that identify the instances that are assigned to the pool 140. For example, the migration module 105 constructs a pre-provisioned instance 145 of the service (B) within the pool 140 and adds a corresponding instance pointer of instance 145 to the collection of instance pointers (a pointer list) for the pool 140. The pre-provisioned instance 145 comprises a collection of computing resources of the second zone 130 as a computing environment that can be used to execute executable code of the service (B). The computing environment may comprise processor, memory, storage, network resources, a virtual machine, and/or other computing resources used to execute the executable code.”)
Regarding claim 11, Greenstein taught the method of claim 10 further comprising updating the onboarding record when the domain is created. (again, consider paragraphs 0027-0028, “A “pool” of instances, in one embodiment, is defined by a collection of instance pointers that identifies the instances that belong to the pool. For example, a data structure is created to maintain the collection of instance pointers for each pool. When an instance is assigned to a pool, its pointer is added to the corresponding collection of pointers for that pool (e.g., a pool pointer list). When an instance is removed from a pool, its pointer is removed from the corresponding collection of pointers. Moving an instance from pool 1 to pool 2 is a combination of removing the pointer from pool 1 and adding the pointer to the collection of pointers for pool 2. In one embodiment, instances are assigned to pools and located by pointers and/or tags that identify an assignment relationship between an instance and a pool. A pool of instances is defined by a collection of pointers that belong to that pool. Assigning an instance to a pool involves adding a pointer of the instance to the collection of pointers of the pool. Moving an instance from one pool to another pool involves removing the pointer from a current pool and reassigning (by adding) the pointer of the instance to a different pointer collection associated with the other pool. In one embodiment, a list or collection of pointers is maintained for each pool that identifies the instances that belong to that pool.”)
Regarding claim 12, Greenstein taught the method of claim 8, wherein monitoring information comprises monitoring at least one selected from the group consisting of revenue, daily average users (DAU), number of transactions, and number of employees. (consider further paragraph 0046, specifically “Control plane 220 as noted above may manage the deployment, migration, utilization, and other aspects of virtual compute instances hosted in a virtual computing service, such as service 210 in FIG. 2. In at least some embodiments, control plane 220 may implement resource management 310. Resource management 310 may make placement decisions for new instances and migration decisions for currently operating instances. For instance, resource management 310 may monitor resource utilization data collected by resource utilization reporting agents 332 located at virtualization hosts 330. Processing utilization, storage utilization, network utilization, or utilization of any other physical resource may be reported to resource management 310. Based on the utilization information, resource management 310 may identify migration operations for different instances currently operating at hosts 330. Different provisioning schemes, such as thin provisioning, may trigger migration operations for instances.”)
Regarding claim 13, Greenstein taught the method of claim 8, wherein moving the protectorate comprises:
providing a pool of record numbers from a primary protectorate; and using the pool of record numbers to create new records for the protectorate. (consider paragraph 0025, “A “pointer” as used in one or more embodiments is a means of identifying and/or locating an instance. Pointers and/or tags are used to assign or add (hereinafter referred to as ‘assignment’) an instance to a selected pool of instances. Pointers are stored and maintained in a data structure stored in a memory. A service instance is typically identified and referred to by a pointer or tag in one of several ways. For example, (1) by an IP address of one of the elements of the instance (such as a front-end load balancer, but possibly one VM of the instance); (2) by a URL or URI of the instance (for example, pointing at the front-end load balancer, but may be directly at VM's Web destination or Web service end point, such as REST or SOAP); (3) by symbolic name translatable via DNS (domain name server) into an IP address (thus reduced to 1); (4) by symbolic name (or tag) translatable by an inventory system into the one of the examples 1-3 above; or (5) by variations of the previous examples. In another embodiment, even though an instance does not have to contain a pointer, the pointer contains the identification of that instance. Thus, if the instance is known, its pointer can be found in one of the pools by searching for the identification within the pointers. If the pointer is not found in a pool, then the instance has not been assigned to that pool.”) (again, consider paragraphs 0027-0028, “A “pool” of instances, in one embodiment, is defined by a collection of instance pointers that identifies the instances that belong to the pool. For example, a data structure is created to maintain the collection of instance pointers for each pool. When an instance is assigned to a pool, its pointer is added to the corresponding collection of pointers for that pool (e.g., a pool pointer list). When an instance is removed from a pool, its pointer is removed from the corresponding collection of pointers. Moving an instance from pool 1 to pool 2 is a combination of removing the pointer from pool 1 and adding the pointer to the collection of pointers for pool 2. In one embodiment, instances are assigned to pools and located by pointers and/or tags that identify an assignment relationship between an instance and a pool. A pool of instances is defined by a collection of pointers that belong to that pool. Assigning an instance to a pool involves adding a pointer of the instance to the collection of pointers of the pool. Moving an instance from one pool to another pool involves removing the pointer from a current pool and reassigning (by adding) the pointer of the instance to a different pointer collection associated with the other pool. In one embodiment, a list or collection of pointers is maintained for each pool that identifies the instances that belong to that pool.”)
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 text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over Greenstein in view of US 20230315626 A1 to Tavellaei et al. (“Tavellaei”).
Regarding claim 14, Greenstein taught the method of claim 8.
Greenstein may be interpreted as not expressly teaching wherein moving a protectorate comprises providing a prefix unique to each instance of a multi-instance architecture to each of a plurality of protectorates, wherein each protectorate of the plurality of protectorates utilizes the prefix for data within the protectorate, however, Greenstein did teach wherein moving a protectorate may comprise providing particular naming conventions unique to each instance of a multi-instance architecture to each of a plurality of protectorates, wherein each protectorate of the plurality of protectorates utilizes the naming convention for data within the protectorate. (consider paragraph 0025, specifically “A “pointer” as used in one or more embodiments is a means of identifying and/or locating an instance. Pointers and/or tags are used to assign or add (hereinafter referred to as ‘assignment’) an instance to a selected pool of instances. Pointers are stored and maintained in a data structure stored in a memory. A service instance is typically identified and referred to by a pointer or tag in one of several ways. For example, (1) by an IP address of one of the elements of the instance (such as a front-end load balancer, but possibly one VM of the instance); (2) by a URL or URI of the instance (for example, pointing at the front-end load balancer, but may be directly at VM's Web destination or Web service end point, such as REST or SOAP); (3) by symbolic name translatable via DNS (domain name server) into an IP address (thus reduced to 1); (4) by symbolic name (or tag) translatable by an inventory system into the one of the examples 1-3 above; or (5) by variations of the previous examples.”) (consider also paragraph 0039, specifically “The migration module 105 maintains a pool 140 of pre-provisioned instances within the second zone 130. The pool 140 is defined by a collection of instance pointers that identify the instances that are assigned to the pool 140. For example, the migration module 105 constructs a pre-provisioned instance 145 of the service (B) within the pool 140 and adds a corresponding instance pointer of instance 145 to the collection of instance pointers (a pointer list) for the pool 140. The pre-provisioned instance 145 comprises a collection of computing resources of the second zone 130 as a computing environment that can be used to execute executable code of the service (B). The computing environment may comprise processor, memory, storage, network resources, a virtual machine, and/or other computing resources used to execute the executable code.”)
In an analogous art relating to the use of protectorates and equivalents as disposed within instanced architectures (consider paragraphs 0011, 0027, 0030 and 0032-0033), Tavellaei taught wherein a prefix (“upper bits”) unique to each instance of a multi-instance architecture to each of a plurality of protectorates is provided, wherein each protectorate of the plurality of protectorates utilizes the prefix for data within the protectorate (consider paragraphs 0042-0044, specifically “Identification of a TAD for a DPA may be done based on a slice identifier included in the DPA and a slice-to-TAD index. This is schematically illustrated in FIG. 6, which shows an example DPA 600 including a slice identifier 602. The slice identifier is compared to a slice-to-TAD index 604, which lists a TAD identifier corresponding to the DPA, based on the slice identifier. [0043] The slice identifier may take any suitable form. In one example, the slice identifier may be encoded using some number of bits of the DPA. As discussed above, the disaggregated memory pool may in some cases be divided into 1024 different allocation slices. Thus, the slice identifier may be encoded using the 10 upper bits of the DPA, and thereby uniquely identify the allocation slice of the disaggregated memory pool that the DPA corresponds to. In other examples, however, different numbers of allocation slices may be used, and thus different numbers of bits may be used to encode the slice identifier. [0044] The slice-to-TAD index may take the form of any suitable data structure that include entries for each slice identifier, as well as an indication of a TAD to be used for each slice. In some cases, the slice identifier may additionally be referenced against a slice-to-node index, such as index 606 in FIG. 6. The slice-to-node index may include, for each slice identifier, an indication of which of the plurality of compute nodes that allocation slice has been allocated to. In other words, as the memory control system allocates different allocation slices of its available memory to different compute nodes of the plurality, it may maintain and update the slice-to-node index with entries indicating which slices have been allocated to which nodes.”)
It would have been obvious to one skilled in the art before the effective filing date of the claimed invention to combine the teachings of these references such that their combination includes every element as claimed. One skilled in the art could have combined the teachings by known methods such as integration of software routines with no changes to the operation of either reference such that, in combination, each element merely performs the same function as it does separately. Additionally, Examiner finds that, based on the references' analogous disclosure regarding protectorates and equivalents as disposed within instanced architectures and identifiers to associate resources with protectorates, further demonstrates that a combination of their features would have been known and obvious. Therefore, such a combination of the teachings of the references would have yielded nothing more than predictable results to one of ordinary skill in the art.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
With regards to protectorates and equivalents and their use within instanced architectures in conjunction with various resource allocation and migration of instances within, consider US 20170177401 A1 to Brouwer et al; US 20140373007 A1 to Donellan et al; US 20150373098 A1 to Mordani et al; and US 20160094624 A1 to Mordani et al.
With regards to the use of particular naming conventions including prefixes that associate resources with protectorates and equivalents, consider US 20150120792 A1 to Khandelwal et al; US 20230131270 A1 to Rashid et al; and US 20250077472 A1 to Rashid et al.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to G. C. Neurauter, Jr. whose telephone number is (571)272-3918. The examiner can normally be reached Monday-Friday 9am-5pm Eastern Time.
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, Tonia Dollinger, can be reached at 571-272-4170. 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.
/G. C. Neurauter, Jr./Primary Examiner, Art Unit 2459
Prosecution Insights