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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on December 15, 2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
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 15 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 15 recites the limitation "the requested task" in line 5. There is insufficient antecedent basis for this limitation in the claim. As such, claim 15 will be interpreted as best understood.
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)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1, 3-7, 9, 11, 12, 15-18 and 20 is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Jeong et al. (Jeong), U.S. Patent Pub. No. 2022/0141256.
The applied reference has a common inventor with the instant application. Based upon the earlier effectively filed date of the reference, it constitutes prior art under 35 U.S.C. 102(a)(2). This rejection under 35 U.S.C. 102(a)(2) might be overcome by: (1) a showing under 37 CFR 1.130(a) that the subject matter disclosed in the reference was obtained directly or indirectly from the inventor or a joint inventor of this application and is thus not prior art in accordance with 35 U.S.C. 102(b)(2)(A); (2) a showing under 37 CFR 1.130(b) of a prior public disclosure under 35 U.S.C. 102(b)(2)(B) if the same invention is not being claimed; or (3) a statement pursuant to 35 U.S.C. 102(b)(2)(C) establishing that, not later than the effective filing date of the claimed invention, the subject matter disclosed in the reference and the claimed invention were either owned by the same person or subject to an obligation of assignment to the same person or subject to a joint research agreement.
Regarding claim 1, Jeong discloses a device for providing an intent-based network management automation (performing a security management automation in an Interface to Network Security Functions (I2NSF) system) (0006) in an intent-based networking (IBN) framework (The present disclosure also provides a feedback structure applied to a security service system by applying a security policy to a security service virtual machine according to a security service user's intention using an intent-based networking (IBN) technology) (0005), the device comprising: an IBN controller (security controller 200; figure 4) configured to control and manage system components including network service functions (NSFs) (The NSF may provide suitable network service functions according to the security policy (or intent) of the I2NSF user 100.) (0172) (Further, the network operator management system (or security controller) may monitor an NSF(s) that is being in driven in a system, and may maintain various items of information (e.g., network access information and a workload state) about each NSF(s).) (0048), wherein the IBN controller is further configured to translate a high-level network policy into a corresponding low-level network policy, select an appropriate NSF for the translated low-level network policy, and induce the selected NSF to execute network rules of the low-level network policy (One of the important functions of the…security controller is to translate a high-level security policy (or policy rule) from the I2NSF user into a low-level security policy rule for a specific NSF(s). The …security controller may receive a high-level security policy from the I2NSF user and determine the type of an NSF(s) required to enforce a policy requested first by the I2NSF user. Further, the network operator management system (security controller) may create a low-level security policy for each requested NSF(s). As a result, the network operator management system (or security controller) may set the created low-level security policy to each NSF(s).) (0047).
Regarding claim 3, Jeong discloses the device of claim 1, wherein the IBN controller is further configured to remotely configure a network policy to the appropriate NSF using the low-level network policy via an NSF-facing interface in order to enforce a commanded intent in a target network (The NSF-facing interface connects the security controller 200 to the NSFs included in the security network layer. The NSF-facing interface delivers, to the appropriate NSF, a configuration intent that is the low-level security policy translated by the security controller 200.) (0175).
Regarding claim 4, Jeong discloses the device of claim 1, wherein the NSFs are at least one of a virtual network function (VNF), a physical network function (PNF), or a container network function (CNF) (The NSF provides a virtual network function (VNF) for a specific network security service such as firewall, web filter, deep packet inspection, DDoS-attack mitigation, and anti-virus.) (0195).
Regarding claim 5, Jeong discloses the device of claim 1, wherein the IBN controller is further configured to: receive a registration of an NSF's capability and access information from a vendor's management system (VMS) via a registration interface, or transmit and receive an NSF query to and from the vendor's management system for an NSF search, which will service the required low-level network policy, via the registration interface (NSFs provided by different vendors may have different capabilities. Accordingly, in order to automate a process that uses various types of security capabilities provided by different vendors, the vendors need to have an exclusive interface for determining the capabilities of their NSFs. These exclusive interfaces may be referred to as I2NSF registration interface (RI).) (0068).
Regarding claim 6, Jeong discloses the device of claim 1, wherein the IBN controller is further configured to receive a report of the network rules via an analytics interface from an IBN analyzer that analyzes monitoring data for the NSFs and checks activity and performance of the NSFs using a machine learning technique (The SMA may monitor and analyze the activity and performance of the NSFs through the monitoring of the NSFs. The SMA may augment the security rules of the low-level security policy or generate new security rules to configure them to appropriate NSFs, if needed.) (0185); (The I2NSF analyzer 400 may collect monitoring data from NSFs and analyze the data for checking the activity and performance of the NSFs using machine learning techniques (e.g., deep learning). If there is a suspicious attack activity for the target network or NSF, the I2NSF analyzer 400 may deliver a report of the augmentation or generation of security rules to the security controller 200.) (0196).
Regarding claim 7, Jeong discloses the device of claim 6, wherein if a suspicious problem for a target network or the NSFs is detected based on the monitoring data collected via a monitoring interface, the IBN controller is further configured to receive a report of augmentation or generation of the network rules from the IBN analyzer and apply the report to a network policy management (The I2NSF analyzer 400 may collect monitoring data from NSFs and analyze the data for checking the activity and performance of the NSFs using machine learning techniques (e.g., deep learning). If there is a suspicious attack activity for the target network or NSF, the I2NSF analyzer 400 may deliver a report of the augmentation or generation of security rules to the security controller 200.) (0196).
Regarding claim 9, Jeong discloses a method/CRM of providing an intent-based network management automation in an intent-based networking (IBN) framework (The present disclosure also provides a feedback structure applied to a security service system by applying a security policy to a security service virtual machine according to a security service user's intention using an intent-based networking (IBN) technology) (0005), the method performed by an IBN controller (security controller 200; figure 4) comprising steps of: (a) receiving a high-level network policy; (b) translating the high-level network policy into a corresponding low-level network policy; and (c) selecting an appropriate network service function (NSF) for the translated low-level network policy and inducing the selected NSF to execute network rules of the low-level network policy (One of the important functions of the…security controller is to translate a high-level security policy (or policy rule) from the I2NSF user into a low-level security policy rule for a specific NSF(s). The …security controller may receive a high-level security policy from the I2NSF user and determine the type of an NSF(s) required to enforce a policy requested first by the I2NSF user. Further, the network operator management system (security controller) may create a low-level security policy for each requested NSF(s). As a result, the network operator management system (or security controller) may set the created low-level security policy to each NSF(s).) (0047).
Regarding claim 11, Jeong discloses the method of claim 9, wherein the step (b) comprises steps of: (b1) using a translator to extract policy-related attribute data from the high-level network policy; (b2) using the translator to convert the attribute data into attribute data of a corresponding low-level policy based on mapping information between attributes of the high-level network policy and attributes of the low-level network policy; and (b3) using the translator to generate the low-level network policy based on the converted attribute data of the low-level policy (The translating comprises extracting attribute information related to the security policy from the high-level security policy; mapping the attribute information of the high-level security policy to corresponding attribute information of the low-level security policy; and creating the low-level security policy based on a result of mapping.[0008] The mapping comprises converting a high-level YANG data model and a low-level YANG data model into a tree graph; converting the tree graph into a non-branch tree; calculating a tree edit distance between a high-level graph and a low-level graph based on Zhang-Shasha algorithm; obtaining a minimum value of the tree edit distance; and creating the automatic mapping model from the tree edit distance.[0009] The mapping comprises constructing a mapping table that associates data attributes or variables of a high-level YANG data module with corresponding data attributes or variables of a low-level YANG data module. A set of production rules for context free grammar for construction of rules of the low-level security policy is generated based on the mapping table) (0007-0009).
Regarding claim 12, Jeong discloses the method of claim 11, wherein the step (b) further comprises a step of: (b4) using the translator to identify an NSF for a requested network policy, wherein if the identified NSF for the requested network policy is available (inherently available because it has been registered), the method proceeds to the step of generating the low-level network policy (the security controller includes capability information of NSFs that are registered via Registration Interface by developer's management system. The security controller needs to generate a low-level policy in the form of security rules intended by the high-level policy, which can be understood by the corresponding NSFs.) (0147); see also (One of the important functions of the network operator management system (or security controller) is to translate a high-level security policy (or policy rule) from the I2NSF user into a low-level security policy rule for a specific NSF(s). The network operator management system (or security controller) may receive a high-level security policy from the I2NSF user and determine the type of an NSF(s) required to enforce a policy requested first by the I2NSF user. Further, the network operator management system (security controller) may create a low-level security policy for each requested NSF(s). As a result, the network operator management system (or security controller) may set the created low-level security policy to each NSF(s)) (0047).
Regarding claim 15, Jeong discloses the method of claim 9 wherein the step (c) comprises: based on network access information for an NSF (the security controller…may maintain various items of information (e.g., network access information and a workload state) about each NSF(s)) (0048)), sending a low-level network policy request to the appropriate NSF for the translated low-level network policy via an NSF-facing interface (transmitting the low-level security policy to a network security function (NSF) via an NSF-facing interface) to allow the NSF to remotely perform (cloud-based inherently provides remote functionality) (a security management automation applicable to a cloud-based security service system by collecting in real-time monitoring data from a virtual machine and a network switch performing cloud-based security services) (0004) a configuration for the given low-level network policy request (reconfiguring a security policy based on the monitoring data) (0006) for performing the requested task (The vendor management system performs tasks or functions such as enforcing specific policies (0041).
Regarding claim 16, Jeong discloses the method of claim 9, further comprising a step of: (d) receiving a report of the network rules from an IBN analyzer via an analytics interface (The I2NSF analyzer 400 may collect monitoring data from NSFs and analyze the data for checking the activity and performance of the NSFs using machine learning techniques (e.g., deep learning). If there is a suspicious attack activity for the target network or NSF, the I2NSF analyzer 400 may deliver a report of the augmentation or generation of security rules to the security controller 200) (0196).
Regarding claim 17, Jeong discloses the method of claim 16, wherein the step (d) comprises: receiving, from the IBN analyzer, a report generated based on a result of checking activity and performance of the NSF using a machine learning technique while analyzing monitoring data for the NSF collected from at least one NSF via a monitoring interface between the NSF and the IBN analyzer (The I2NSF analyzer 400 may collect monitoring data from NSFs and analyze the data for checking the activity and performance of the NSFs using machine learning techniques (e.g., deep learning). If there is a suspicious attack activity for the target network or NSF, the I2NSF analyzer 400 may deliver a report of the augmentation or generation of security rules to the security controller 200) (0196).
Regarding claim 18, Jeong discloses the method of claim 17, wherein the step (d) comprises: if a suspicious problem for a target network or the NSF is detected based on the monitoring data, receiving a report of augmentation or generation of the network rules from the IBN analyzer and applying the report to a network policy management (The I2NSF analyzer 400 may collect monitoring data from NSFs and analyze the data for checking the activity and performance of the NSFs using machine learning techniques (e.g., deep learning). If there is a suspicious attack activity for the target network or NSF, the I2NSF analyzer 400 may deliver a report of the augmentation or generation of security rules to the security controller 200) (0196).
Regarding claim 20, Jeong discloses one or more non-transitory computer readable mediums storing one or more instructions, wherein the one or more instructions executable by one or more processors (software code can be stored in a memory and can be driven by a processor. The memory is provided inside or outside the processor and can exchange data with the processor by various well-known means.) (0265) are configured to allow, in an intent-based networking (IBN) framework automation, an IBN controller (controller 200) to perform an operation of providing an intent-based network management automation (The present disclosure also provides a feedback structure applied to a security service system by applying a security policy to a security service virtual machine according to a security service user's intention using an intent-based networking (IBN) technology) (0005); (performing a security management automation in an Interface to Network Security Functions (I2NSF) system) (0006), wherein the IBN controller is configured to: receive a high-level network policy; translate the high-level network policy into a corresponding low-level network policy; and select an appropriate network service function (NSF) for the translated low-level network policy and inducing the selected NSF to execute network rules of the low-level network policy (One of the important functions of the…security controller is to translate a high-level security policy (or policy rule) from the I2NSF user into a low-level security policy rule for a specific NSF(s). The …security controller may receive a high-level security policy from the I2NSF user and determine the type of an NSF(s) required to enforce a policy requested first by the I2NSF user. Further, the network operator management system (security controller) may create a low-level security policy for each requested NSF(s). As a result, the network operator management system (or security controller) may set the created low-level security policy to each NSF(s).) (0047).
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 2 and 10 is/are rejected under 35 U.S.C. 103 as being obvious over Jeong in view of Chinthakunta et al. (Chinthakunta), U.S. Patent Pub. No. 2022/0329691.
The applied reference has a common inventor with the instant application. Based upon the earlier effectively filed date of the reference, it constitutes prior art under 35 U.S.C. 102(a)(2).
Regarding claims 2 and 10, Jeong discloses the device/method of claims 1 and 9 as described above, wherein the IBN controller is further configured to translate an intent from a network operator or a user into the high-level network policy and receive it via a consumer-facing interface (An I2NSF user specifies the high-level policy in the I2NSF framework and delivers it to the security controller via the consumer-facing interface. This may be translated into the low-level policy by the policy translator of the security controller, delivered to a suitable NSF via the NSF-facing interface and the suitable NSF may execute a rule corresponding to the low-level policy.) (0145).
Jeong, however, fails to specifically disclose wherein the IBN controller is configured to translate an intent expressed in a natural language input from a network operator or a user into the high-level network policy through a natural language processing (NLP) technique and receive it via a consumer-facing interface.
In a similar field of endeavor, Chinthakunta discloses digital assistant integration with telephony. Chinthakunta further discloses a controller that is configured to translate an intent expressed in a natural language input from a network operator or a user through a natural language processing (NLP) technique and receive it via a consumer-facing interface (One or more processing modules 114 utilize data and models 116 to process speech input and determine the user's intent based on natural language input. Further, one or more processing modules 114 perform task execution based on inferred user intent. In some examples, DA server 106 communicates with external services 120 through network(s) 110 for task completion or information acquisition. I/O interface to external services 118 facilitates such communications) (0034; see also 0229).
Therefore, before the effective filing date, it would have been obvious to a person of ordinary skill in the art to modify Jeong with the teachings of Chinthakunta. The motivation for this modification would have been to combine prior art elements according to known methods to yield predictable results.
This rejection under 35 U.S.C. 103 might be overcome by: (1) a showing under 37 CFR 1.130(a) that the subject matter disclosed in the reference was obtained directly or indirectly from the inventor or a joint inventor of this application and is thus not prior art in accordance with 35 U.S.C.102(b)(2)(A); (2) a showing under 37 CFR 1.130(b) of a prior public disclosure under 35 U.S.C. 102(b)(2)(B); or (3) a statement pursuant to 35 U.S.C. 102(b)(2)(C) establishing that, not later than the effective filing date of the claimed invention, the subject matter disclosed and the claimed invention were either owned by the same person or subject to an obligation of assignment to the same person or subject to a joint research agreement. See generally MPEP § 717.02.
Claim 8 is/are rejected under 35 U.S.C. 103 as being obvious over Jeong in view of well-known prior art.
The applied reference has a common inventor with the instant application. Based upon the earlier effectively filed date of the reference, it constitutes prior art under 35 U.S.C. 102(a)(2).
Regarding claim 8, Jeong discloses the device of claim 6 as described above. Jeong, however, fails to specifically disclose wherein the IBN controller is a network data analytics function (NWDAF) in 5G networks.
The examiner contends, however, that the NWDAF is a well-known entity in telecommunications systems and therefore, takes official notice as such.
Therefore, before the effective filing date, it would have been obvious to a person of ordinary skill in the art to modify Jeong with the teachings of well-known prior art. The motivation for this modification would have been to combine prior art elements according to known methods to yield predictable results.
This rejection under 35 U.S.C. 103 might be overcome by: (1) a showing under 37 CFR 1.130(a) that the subject matter disclosed in the reference was obtained directly or indirectly from the inventor or a joint inventor of this application and is thus not prior art in accordance with 35 U.S.C.102(b)(2)(A); (2) a showing under 37 CFR 1.130(b) of a prior public disclosure under 35 U.S.C. 102(b)(2)(B); or (3) a statement pursuant to 35 U.S.C. 102(b)(2)(C) establishing that, not later than the effective filing date of the claimed invention, the subject matter disclosed and the claimed invention were either owned by the same person or subject to an obligation of assignment to the same person or subject to a joint research agreement. See generally MPEP § 717.02.
Claims 13, 14 and 19 is/are rejected under 35 U.S.C. 103 as being obvious over Jeong.
The applied reference has a common inventor with the instant application. Based upon the earlier effectively filed date of the reference, it constitutes prior art under 35 U.S.C. 102(a)(2).
Regarding claim 13, Jeong discloses the method of claim 11 as described above and further discloses wherein the step (b) further comprises steps of: (b4) using the translator to identify an NSF for a requested network policy (The network operator management system (or security controller) may receive a high-level security policy from the I2NSF user and determine the type of an NSF(s) required to enforce a policy requested first by the I2NSF user.) (0047).
Jeong, however, fails to specifically disclose wherein (b5) if the identified NSF for the requested network policy is unavailable, searching for an appropriate NSF for the requested network policy.
Jeong does disclose that the IBN controller monitors NSF’s within the system and maintains various types of information such network access information and a workload state about each NSF. The controller also dynamically manages the pool of an NSF instance (0048). Jeong, further teaches that the controller determines the type of an NSF(s) required to enforce a policy requested first by the I2NSF user.) (0047).
Therefore, before the effective filing date, it would have been obvious to a person of ordinary skill in the art to modify Jeong to search for an appropriate NSF for the requested network policy if the identified NSF for the requested network policy is unavailable to ensure that requested policies are enforced within the system.
This rejection under 35 U.S.C. 103 might be overcome by: (1) a showing under 37 CFR 1.130(a) that the subject matter disclosed in the reference was obtained directly or indirectly from the inventor or a joint inventor of this application and is thus not prior art in accordance with 35 U.S.C.102(b)(2)(A); (2) a showing under 37 CFR 1.130(b) of a prior public disclosure under 35 U.S.C. 102(b)(2)(B); or (3) a statement pursuant to 35 U.S.C. 102(b)(2)(C) establishing that, not later than the effective filing date of the claimed invention, the subject matter disclosed and the claimed invention were either owned by the same person or subject to an obligation of assignment to the same person or subject to a joint research agreement. See generally MPEP § 717.02.
Regarding claim 14, Jeong as modified discloses the method of claim 13 as described above. Jeong, however, fails to specifically disclose wherein the step (b5) comprises: sending an NSF query request to a vendor's management system (VMS) via a registration interface so as to find the appropriate NSF for the requested network policy; and receiving, from the vendor's management system, an NSF query response that tells the NSF its readiness to perform a task along with network access information for the NSF.
Jeong, however, discloses a registration interface that connects with a developer’s (vendor’s) management system to the controller. The interface is used to register capability and access information of the NSF with the security controller or to process queries of an NSF (0201). The vendor management system performs tasks or functions such as enforcing specific policies (0041).
Therefore, before the effective filing date, it would have been obvious to a person of ordinary skill in the art to modify Jeong to include sending an NSF query request to a vendor's management system (VMS) via a registration interface so as to find the appropriate NSF for the requested network policy; and receiving, from the vendor's management system, an NSF query response that tells the NSF its readiness to perform a task along with network access information for the NSF since Jeong provides some teaching or suggestion to make such a modification in order to arrive at the claimed invention.
This rejection under 35 U.S.C. 103 might be overcome by: (1) a showing under 37 CFR 1.130(a) that the subject matter disclosed in the reference was obtained directly or indirectly from the inventor or a joint inventor of this application and is thus not prior art in accordance with 35 U.S.C.102(b)(2)(A); (2) a showing under 37 CFR 1.130(b) of a prior public disclosure under 35 U.S.C. 102(b)(2)(B); or (3) a statement pursuant to 35 U.S.C. 102(b)(2)(C) establishing that, not later than the effective filing date of the claimed invention, the subject matter disclosed and the claimed invention were either owned by the same person or subject to an obligation of assignment to the same person or subject to a joint research agreement. See generally MPEP § 717.02.
Regarding claim 19, Jeong discloses the method of claim 18 as described above. Jeong, however, fails to specifically disclose, wherein the step (d) comprises: if the suspicious network problem is detected, sending an updated policy request or a new policy request based on the report to the appropriate NSF to induce the appropriate NSF to perform a reconfiguration or a configuration.
Jeong does disclose that when a suspicious attack has occurred, the attack is reported. (0196). Jeong further discloses that by analyzing the security event(s), the I2NSF user can recognize new attacks and can update (or create) a high-level security policy for dealing with the new attacks. As described above, the I2NSF user can define, manage, and monitor a security policy. (0044).
Therefore, before the effective filing date, it would have been obvious to a person of ordinary skill in the art to modify Jeong to send an updated policy request or a new policy request based on the report to the appropriate NSF to induce the appropriate NSF to perform a reconfiguration or a configuration if the suspicious network problem is detected since Jeong provides some teaching or suggestion to make such a modification in order to arrive at the claimed invention.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Wackerly et al. U.S. Patent Pub. No. 2018/0375802 discloses reduced orthogonal network policy set selection.
Prasad et al. U.S. Patent Pub. No. 2018/0278478 discloses a network agent for generating platform specific network policies.
Lucas et al. U.S. Patent Pub. No. 2016/0211988 discloses rendering network policy and monitoring compliance.
Tripathi et al. U.S. Patent Pub. No. 2022/0335223 discloses automated generation of chatbot.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TEMICA M. BEAMER whose telephone number is (571)272-7797. The examiner can normally be reached Monday thru Friday; 9:00 AM to 3:00 PM.
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, Matthew D. Anderson can be reached at 571-272-4177. 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.
/TEMICA M BEAMER/Primary Examiner, Art Unit 2646