DETAILED ACTION
Claims 1-20 are presented on 10/18/2024 for examination on merits. Claims 1, 13, and 20 are independent base claims.
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 Instructions for filing Response to this Office Action
When the Applicant submits amendments regarding to the claims in response the Office Action, the Examiner would appreciate Applicant if a clean copy of the claims is provided to facilitate the prosecution which otherwise requires extra time for editing the marked-up claims from OCR.
Please submit two sets of claims:
Set #1 as in a typical filing which includes indicators for the status of claim and all marked amendments to the claims; and
Set #2 as an appendix to the Arguments/Remarks for a clean version of the claims which has all the markups removed for entry by the Examiner.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent Application # 18/919856 (hereinafter APP 856) in view of Parry (US 20230011588 A1).
Although the claims at issue are not identical, they are not patentably distinct from each other as they claim the same subject matter of determining and configuring rules or policies for traffic control in the cloud computing environment.
Regarding claim 1, APP 856 discloses:
A method for managing a network segmentation policy in a cloud computing environment (APP 856, CLM. 1: A method for managing security rules in a cloud computing environment; identifying a segmentation policy), the method comprising:
collecting cloud metadata associated with cloud resources, the cloud resources protected by a plurality of segmentation policies (APP 856, CLM. 1: obtaining metadata associated with the new cloud account; comparing metadata associated with the new cloud account with metadata);
determining relationships between different cloud resources associated with the segmentation policies based on the collected cloud metadata (APP 856, CLM. 1: comparing metadata associated with the new cloud account with metadata associated with existing cloud accounts in the cloud computing environment to identify an existing cloud account that is similar to the new cloud account);
recording the determined relationships in a database (APP 856, CLMS. 1 and 4: identifying and storing in a metadata storage [the information] that an existing cloud account is similar to the new cloud account);
automatically configuring a network segmentation policy based on the determined relationships, the network segmentation policy causing network traffic between cloud resources to be allowed or denied (APP 856, CLM. 1: identifying a segmentation policy; automatically configuring a new set of security rules associated with the new cloud account based on the identified set of security rule based on the segmentation policy associated with the existing cloud account); and
performing one of allowing passage of network traffic or blocking network traffic to or from cloud resources based on the configured network segmentation policies (APP 856, CLM. 1: automatically configuring a new set of security rules associated with the new cloud account; CLM. 7: allow or deny network traffic from a source resource [based on] the new security rule).
However, APP 856 does not explicitly disclose a GUI for visualizing the relationships. This aspect of the claim is identified as a further difference.
In a related art, Parry teaches:
visualizing the relationships on a Graphical User Interface (GUI) (Parry, par. 0051: FIG. 5 shows an example screen 500 of a graphical user interface showing nodes and relationships between the nodes; see also par. 0039-0043 for Parry’s relationship-based search system 120 that determines the node relationship based on the metadata 310-M, 315-M, 320-M, 325-M, 330-M, and 335-M).
Parry is analogous art to the claimed invention in the same field of endeavor as the claimed invention, or reasonably pertinent to the problem faced by the inventor, which may be in a different field. Thus, it would have been obvious to one of ordinary in the art, before the effective filing date of the claimed invention, to modify the system of APP 856 with Parry’s teachings of “GUI” being used for showing nodes and relationships between the resources. For this combination, the motivation would have been to improve user experience of the policy generation system.
Independent claims 13 and 20 are rejected for the same reason as claim 1, because they each recite similar limitations.
Regarding dependent claims 2-12 and 14-19 of the present application, they are obvious variants of the same subject matter as found in the reference application, and thereby rejected under the judicially created doctrine of obviousness-type double patenting.
Secondly,
Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent Application # 18/919851 (hereinafter APP 851) in view of Parry (US 20230011588 A1).
Although the claims at issue are not identical, they are not patentably distinct from each other as they claim the same subject matter of determining and configuring rules or policies for traffic control in the cloud computing environment.
Regarding claim 1, APP 851 anticipates:
A method for managing a network segmentation policy in a cloud computing environment (APP 851, CLM. 1: A method for managing new cloud resources … updating the security rule … to control network traffic from or to the new cloud resource), the method comprising:
collecting cloud metadata associated with cloud resources, the cloud resources protected by a plurality of segmentation policies (APP 851, CLM. 1: obtaining metadata of the new cloud resource);
determining relationships between different cloud resources associated with the segmentation policies based on the collected cloud metadata (APP 851, CLM. 1: comparing metadata of the new cloud resource with metadata of existing cloud resources in the cloud computing environment to identify an existing cloud resource that is same as or similar to the new cloud resource);
recording the determined relationships in a database (APP 851, CLMs. 2-3: storing metadata of resources associated with existing cloud accounts … in a metadata storage [as] a similarity is identified; CLM. 1);
automatically configuring a network segmentation policy based on the determined relationships, the network segmentation policy causing network traffic between cloud resources to be allowed or denied (APP 851, CLMs. 1 and 6: generating a new security rule that controls network traffic from or to the new cloud resource, wherein updating the security rule causes the security rule to also control network traffic from or to the new cloud resource); and
performing one of allowing passage of network traffic or blocking network traffic to or from cloud resources based on the configured network segmentation policies (APP 856, CLMs. 1 and 6: the updated security rule or the new security rule allowing or denying the new cloud resource to communicate with one or more other cloud resources).
However, APP 851 does not explicitly disclose a GUI for visualizing the relationships. This aspect of the claim is identified as a further difference.
In a related art, Parry teaches:
visualizing the relationships on a Graphical User Interface (GUI) (Parry, par. 0051: FIG. 5 shows an example screen 500 of a graphical user interface showing nodes and relationships between the nodes; see also par. 0039-0043 for Parry’s relationship-based search system 120 that determines the node relationship based on the metadata 310-M, 315-M, 320-M, 325-M, 330-M, and 335-M).
Parry is analogous art to the claimed invention in the same field of endeavor as the claimed invention, or reasonably pertinent to the problem faced by the inventor, which may be in a different field. Thus, it would have been obvious to one of ordinary in the art, before the effective filing date of the claimed invention, to modify the system of APP 851 with Parry’s teachings of “GUI” being used for showing nodes and relationships between the resources. For this combination, the motivation would have been to improve user experience of the policy generation system.
Independent claims 13 and 20 are rejected for the same reason as claim 1, because they each recite similar limitations.
Regarding dependent claims 2-12 and 14-19 of the present application, they are obvious variants of the same subject matter as found in the reference application, and thereby rejected under the judicially created doctrine of obviousness-type double patenting.
Claim Objections
Claims 4-5 and 16-17 are objected to because of the following informalities:
Claims 4 and 16 each recite “the plurality of controls” deficiently. As understood in the context, it should have been “the plurality of levels of control.”
Claims 5 and 17 each recite “the determined level” deficiently. As understood in the context, it should have been “the determined control level.”
Appropriate correction is required. deficiently.
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.
Claims 1-20 are 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 pre-AIA the applicant regards as the invention.
The rejection(s) under 35 U.S.C. 112(b) is/are determined by the following reasons:
Claims 1, 13, and 20 each recite multiple instances of “cloud resources” unclearly or lacking sufficient antecedent basis. For example, in claim 1, the collecting step recites the first instance of “cloud resources” with which cloud metadata is collected and associated. Further in the claim, the automatically configuring step contains another instance of “cloud resources” without linking to the first instance. A third instance of “cloud resources” is then recited in the performing step. It is unclear whether these instances of “cloud resources” are the same or not.
Claim 1 recites two instances of “a network segmentation policy”, one in the preamble and the other in the automatically configuring step. It is unclear whether the two instances are the same or not.
Claim 11 recites another instance of “a network segmentation policy” without linking to the network segmentation policy in claim 1.
Claims 2-12 and 14-19 are also rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, because they depend from the rejected base claims 1 and 13, respectively.
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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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.
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 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.
Claims 1-3, 9-15, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Keiser, Jr (US 20230239325 A1; hereinafter “Keiser”) in view of in view of Parry (US 20230011588 A1).
As per claim 1, Keiser teaches a method for managing a network segmentation policy in a cloud computing environment (par. 0035 and 0043-0044: generating network application security policies [in] a cloud-based system 100; a micro-segmentation system. An example of the system 50 is the Zscaler Workload Segmentation (ZWS) system), the method comprising:
collecting cloud metadata associated with cloud resources, the cloud resources protected by a plurality of segmentation policies (Keiser, par. 0154 and 0158: collect metadata about the packet's headers, and [thus] constructing a graph of all application software communicating via datagram protocols over a network);
determining relationships between different cloud resources associated with the segmentation policies based on the collected cloud metadata (Keiser, par. 0170-0172: determining whether the network policies in place [] should allow the connection; the determination can be based on … for example, packet metadata from one or both sides of the connection; see also par. 0165: analyzing can include correlating and merging related telemetry into a single event describing one or more datagram protocol packets that flowed along a virtual circuit defined by a source Internet Protocol (IP) address, destination IP address, IP protocol number, and information required to uniquely identify a flow. The analyzing can include constructing a graph of all application software communicating via datagram protocols over the network);
recording the determined relationships in a database (Keiser, par. 0093-0094: inspecting traffic and applying policies as recorded in database; database updates. In particular, the central authority 152 hosts all customer (tenant) policy and configuration settings. It monitors the cloud and provides a central location for software and database updates and threat intelligence; see also par. 0028-0029: micro-segmentation, databases 14, and firewalls 16 wherein policies as stored in database must be continually updated as applications and devices move);
automatically configuring a network segmentation policy based on the determined relationships, the network segmentation policy causing network traffic between cloud resources to be allowed or denied (Keiser, par. 0140-0141: The system 100 also includes a microsegment generation module … automatically generates a set of policies 132 as output based on the flow matches in the network information (step 403)); and
performing one of allowing passage of network traffic or blocking network traffic to or from cloud resources based on the configured network segmentation policies (Keiser, par. 0080 and 0086: identify existing policies that govern (e.g., allow and/or disallow) inbound connections (i.e., connections into the microsegment, for which hosts in the microsegment are destinations) and/or existing policies that govern (e.g., allow and/or disallow) for outbound connections).
However, Keiser does not explicitly disclose a GUI for visualizing the relationships. This aspect of the claim is identified as a further difference.
In a related art, Parry teaches:
visualizing the relationships on a Graphical User Interface (GUI) (Parry, par. 0051: FIG. 5 shows an example screen 500 of a graphical user interface showing nodes and relationships between the nodes; see also par. 0039-0043 for Parry’s relationship-based search system 120 that determines the node relationship based on the metadata 310-M, 315-M, 320-M, 325-M, 330-M, and 335-M).
Parry is analogous art to the claimed invention in the same field of endeavor as the claimed invention, or reasonably pertinent to the problem faced by the inventor, which may be in a different field. Thus, it would have been obvious to one of ordinary in the art, before the effective filing date of the claimed invention, to modify the system of Keiser with Parry’s teachings of “GUI” being used for showing nodes and relationships between the resources. For this combination, the motivation would have been to improve user experience of the policy generation system.
As per claim 2, the references of Keiser and Parry as combined above teach the method of claim 1, and Keiser teaches: wherein the determined relationships are represented as a graph (Keiser, par. 0158: constructing a graph of all application software communicating via datagram protocols over a network). In the combination, Parry also teaches: the database is a graph database (Parry, the Abstract and par. 0030: the graph database 425)
As per claim 3, the references of Keiser and Parry as combined above teach the method of claim 1, wherein the segmentation policies are enforced at a plurality of levels of control, a lowest level of control being enforced at a level associated with a resource, and a higher level of control being enforced on top of a previous level of control (Keiser, par. 0122-0125: policies may then be enforced at the application and host level within the network [wherein] a low level of control is automatic enforcement of policies, and the a high level of control is manual involving human intervention).
As per claim 9, the references of Keiser and Parry as combined above teach the method of claim 1, further comprising:
receiving a new security rule or a modification of an existing security rule indicating allow or deny network traffic from a first cloud resource to a second cloud resource (Keiser, par. 0007: consistently needs to update the local security agents to address vulnerabilities, add new functionality, etc. par. 0028 and 0131-0134: identifying updated network application security policies and applying those updated policies to existing or updated microsegments: [receiving] updated or new [rules] as applications and devices move; par. 0083 and 0131: If micro-segmentation policies are not updated over time, those new requirements cannot be satisfied); and
configuring the network segmentation policy based on the received new security rule or modified security rule (Keiser, par. 0087: automatically configuring and applying rules for each of the desired behaviors; see also par. 0131-0134).
As per claim 10, the references of Keiser and Parry as combined above teach the method of claim 1, further comprising: tagging a resource with associated metadata (Keiser, par. 0107-0108: automatically naming resources and segments; par. 0110-0111: segment naming process 300; see par. 0036, 0038, and 0057: resources being labelled).
As per claim 11, the references of Keiser and Parry as combined above teach the method of claim 1, further comprising:
responsive to receiving a query associated with metadata of resource, outputting a network segmentation policy associated with the resource (Keiser, par. 0140-0141: generates a set of policies 132 as output based on the flow matches in the network information (step 403)… For example, a first subset of the policies 132 may control access to a first one of the proposed microsegments, while a second, different, subset of the policies 132 may control access to a second one of the proposed microsegments. Note that the output of policy is in response of input including user inputs; see par. 0141-0142).
As per claim 12, the references of Keiser and Parry as combined above teach the method of claim 1, further comprising:
identifying vulnerability in network configuration between two resources in the cloud computing environment based on the determined relationships (Keiser, par. 0007: vulnerabilities; update the local security agents to address vulnerabilities, add new functionality); and
configuring the network segmentation policy to mitigate the vulnerability (Keiser, par. 0195-0196: to mitigate the effects of certain classes; allows the security software vendor to mitigate the effects of changes within software environments [by] configuring the network segmentation policy; par. 0087 and 0127).
Regarding base claims 13 and 20, they are similar to claim 1 in terms of recited features, respectively; and thus, claims 13 and 20 are rejected using the same rationale.
Regarding claims 14-15, they are similar to claims 2-3, respectively, in terms of the recited features; and thus, claims 14-15 are rejected using the same rationale.
Claims 4-7 and 16-19 are rejected under 35 U.S.C. 103 as being unpatentable over Keiser and Parry, as applied to claim 1, and further in view of Deb (US 20220321471 A1).
As per claim 4, the references of Keiser and Parry as combined above teach the method of claim 3, but do not explicitly disclose that the plurality of controls includes a first level associated with a resource directly, a second level associated with an associated subnet, and a third level associated with a virtual private cloud. This aspect of the claim is identified as a further difference.
In a related art, Deb teaches:
wherein the plurality of controls includes a first level associated with a resource directly, a second level associated with an associated subnet, and a third level associated with a virtual private cloud (Deb, par. 0093-0096: one or more policy-based routing (PBR) rules, which [are] specified for the traffic to be processed using the VR, aka, a virtual router. Deb discloses policies to be implemented for packet forwarding/routing; par. 0068-0069. These policies are configured for a variety of controls including a direct resource control and a subnet control. See par. 0087).
Deb is analogous art to the claimed invention in the same field of endeavor as the claimed invention, or reasonably pertinent to the problem faced by the inventor, which may be in a different field. Thus, it would have been obvious to one of ordinary in the art, before the effective filing date of the claimed invention, to modify the system of Keiser and Parry with Deb’s teachings of other types of controls that may be directly associated with resources or indirectly associated with the subnet of the network. For this combination, the motivation would have been to improve flexibility of the policy generation.
As per claim 5, the references of Keiser and Parry as combined above teach the method of claim 4, wherein configuring the network segmentation policy comprises:
determining a control level at which the network segmentation policy is to be applied based on an associated resource (Deb, par. 0081-0083: The EN 522D may determine, e.g., based on a client-supplied policy indicating that a multicast operation is to be performed, and based on forwarding/routing metadata provided by the client, that … the policies require the auxiliary task offloader(s) 577 may be implemented within another isolated network 510Y (e.g., an isolated virtual network of a virtualized computing service) set up specifically for handling such auxiliary tasks); and
configuring the network segmentation policy based on the determined level (Deb, par. 0082-0083: Software updates may be applied to nodes of one IPPC…implementing set up specifically for handling such auxiliary tasks).
As per claim 6, the references of Keiser and Parry as combined above teach the method of claim 4, further comprising:
responsive to determining that the associated resource is a virtual machine, determining that the control level is the first level (Deb, par. 0085: IVN 810B may include resources used for an auxiliary task offloading cell (ATOC) associated with VR-A. IVN resources, it is [determined] the resources including, for example, virtual machines); and
configuring the network segmentation policy as a security group (Deb, par. 0085: virtual network interfaces may be set up … to enable connectivity as specified groups of resources; par. 0086: he resources of the VCS 605, such as the hosts on which various compute instances are run, may be distributed among a plurality of availability containers 650, such as 650A and 650B).
As per claim 7, the references of Keiser and Parry as combined above teach the method of claim 4, further comprising:
responsive to determining that the associated resources include all resources in a subnet, determining that the control level is the second level (Deb, par. 0087-0088: at least two control plane subnets 642A and 642B [are] determined. One data plane subnet and one control plane subnet may be implemented in each of at least two availability containers 650—e.g., subnets 640A and 642A may be configured …[for] a level of control. A control plane subnet 642 may comprise one or more ANs 629 at respective CIs 620); and
configuring the network segmentation policy in one or more of a network access control list, a network security group, or a security list (Deb, par. 0081 and 0087-0088: configuring the network policy [for] subnets 642A and 642B. The EN 522D may determine, e.g., based on a client-supplied policy indicating that a multicast operation is to be performed, and based on forwarding/routing metadata provided by the client, that the contents of the packet are to be transmitted at e.g., subnets 640A and 642A which may be configured …[for] a level of control).
Regarding claims 16-19, they are similar to claims 4-7 in view of the features recited thereof, respectively; and thus, claims 16-19 are rejected for the same reasons discussed above.
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Keiser, Parry, and Deb, as applied to claim 4, and further in view of Park (US 20200228486 A1).
As per claim 8, the references of Keiser, Parry, and Deb as combined above teach the method of claim 4. In the combination, Deb also discloses: further comprising:
responsive to determining that the associated resource include all resources in a virtual private cloud, determining that the control level is the second level (Deb, par. 0039-0040: a virtual private cloud or VPC, or a virtual network) which includes some number of compute instances of a virtualized computing service (VPC) of the provider network; par. 0054: The traffic and operations of the cloud provider network includes a control plane generally comprising one or more control plane components distributed across and implemented by one or more control servers).
However, Deb and the combination do not explicitly disclose a firewall being used for a network segmentation policy. This aspect of the claim is identified as a further difference.
In a related art, Park teaches:
configuring the network segmentation policy as a firewall (Park, par. 0018-0019: enforcing the segmentation policy …by low level firewall rules that can be enforced by the firewall 134).
Park is analogous art to the claimed invention in the same field of endeavor in improving segmentation policies as the claimed invention, or reasonably pertinent to the problem faced by the inventor, which may be in a different field. Thus, it would have been obvious to one of ordinary in the art, before the effective filing date of the claimed invention, to combine them and to modify the system of Keiser, Parry, and Deb with Park’s teachings of “a firewall” being configured to function as a network segmentation policy. For this combination, the motivation would have been to improve the level of security with lower cost for implementing network segmentation policy.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure as the prior art additionally discloses certain parts of the claim features (See “PTO-892 Notice of Reference Cited”).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DON ZHAO whose telephone number is (571)272.9953. The examiner can normally be reached on Monday to Friday, 7:30 A.M to 5:00 P.M EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Carl G Colin can be reached on 571.272.3862. The fax phone number for the organization where this application or proceeding is assigned is 571.273.8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866.217.9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800.786.9199 (IN USA OR CANADA) or 571.272.1000.
/Don G Zhao/Primary Examiner, Art Unit 2493 01/09/2026