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 .
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.
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.
Claims 1-3, 7, 14-16, 20 are rejected under 35 U.S.C. 103 as being un-patentable by Dale et al. (“Dale”, US 20170099187 A1) hereinafter Dale, in view of Lofti et al. (“Lofti”, US 20190068456 A1) hereinafter Lofti
Regarding claim 1, Dale teaches method of network topology-based verification ([0005, 0084] verifying resources, verify that any existing, previously configured services are still in operation and adjust the network configuration to disable re-direction for non-operational services.)([0087-0088, 0090, 0138-0139, 0144-0145]), comprising:
obtaining a network verification request, wherein the network verification request comprises device change information for a physical network ([0069] The DSI agent also periodically validates that the service network configuration is still applied to the network elements 606A-C.)(Fig. 12, [0084] The dynamic service insertion logic 1200 includes can verify the availability of the resources (e.g., VLANs, VNIs, ACLs/DirectFlow) that will be used to perform dynamic service insertion for a service device)([0095] Monitoring the detected service device can enable the service device policy logic 1400 to response to any changes in policies that may be implemented by service device administrators or that may be automatically implemented by a service device based on automated control logic.) ([0073] configuration change or update on network elements), the physical network comprises a plurality of hierarchical layers (Fig.3, Fig. 4, Spine tier, Leaf Tier, Server groups attached to the leaf tiers), and each of the hierarchical layers comprises a plurality of network devices ([0103] the network configuration logic 1600 can determine the configuration changes the network elements coupled to network hosts, clients, and/or VMs that are affected by the service device policies that will be required to implement the intent of the network service policy. Once those changes are determined, the network configuration logic 1600 can push configuration changes to the various network elements and cause the network element to direct network traffic from service device clients to the service device at block 1606. The nature of the configuration changes to the network elements can vary based on the service device and the specific service device policies that are implemented.)([0147] implement the policies includes generating a set of network configuration changes to insert the service device into the network and distributing the set of network configuration changes to one or more network elements on the network)
determining a target network device changed in the physical network using the device change information ([0073] configuration change or update on network elements)([0091] FIG. 9 assist in the propagation of network configuration changes (e.g., to the network elements of the network element layer 908) based on service device policies. Such propagation can include pushing configuration changes to each network element to enable the network elements to re-direct and/or modify the flow of network data across the network, such that network data to or from client devices identified by the policies of the service device is automatically re-directed to the service device.), and obtaining extended network devices from network devices in each of the hierarchical layers in the physical network ([0100] push configuration changes out to network elements that are impacted by the service device policies.), wherein the extended network devices obtained in each of the hierarchical layers correspond to different providers ([0032] Different network device manufacturers)([0103] the network configuration logic 1600 can determine the configuration changes the network elements coupled to network hosts, clients, and/or VMs that are affected by the service device policies that will be required to implement the intent of the network service policy. Once those changes are determined, the network configuration logic 1600 can push configuration changes to the various network elements and cause the network element to direct network traffic from service device clients to the service device at block 1606. The nature of the configuration changes to the network elements can vary based on the service device and the specific service device policies that are implemented.)([0147] implement the policies includes generating a set of network configuration changes to insert the service device into the network and distributing the set of network configuration changes to one or more network elements on the network) ([0076, 0082, 0088] different device vendors )([0052][0093] propagation can include pushing configuration changes to each network element to enable the network elements to re-direct and/or modify the flow of network data across the network, such that network data to or from client devices identified by the policies of the service device is automatically re-directed to the service device.)([0076-0081, 0091, 0093] topology discover to monitor policies);
Dale does not explicitly teach, but Lofti teaches
constructing an emulated network topology based on the target network device and the extended network devices ([0027] The distributed set of hardware resources execute emulated network devices that collectively recreate the functionality and operation of the hardware network devices of the target physical network)([0056] Fig. 3, step 360 instantiates (at 360) an emulated network device on each cloud instance.); and
establishing an emulation runtime environment corresponding to the emulated network topology, and performing emulation verification on the emulated network topology based on the emulation runtime environment to obtain an emulation verification result ([0029] replicating the topology, direct connectivity, and native communication of a target physical network in the cloud, some embodiments are then able to holistically and comprehensively validate configuration changes and their impact to the end state of the target physical network in the cloud without impacting the existing steady state of the target physical network. The validation allows network administrators to detect through the replicated network)([0103] replicated network may also be created in the cloud for planning, testing, and/or validating a target physical network before the target physical network is built)([0104-0112] network validation).
It would have been obvious to a person skilled in the art, before the effective filing date of the invention, to modify Dale in view of Lofti in order to create an emulation environment before making configuration changes in the real physical network because it will identify a modified end state of a network resulting from one or more changes to configurations of the hardware or physical network devices without modifying the running configurations on the network devices and knowing full scope of these changes without having risk of outages, blackholes, lost traffic on the real physical network (Lofti [0007-0008]).
Regarding claim 2, Dale and Lofti teach the method of claim 1,
Dales teaches wherein the obtaining extended network devices from network devices in each of the hierarchical layers in the physical network comprises ([0103] the network configuration logic 1600 can determine the configuration changes the network elements coupled to network hosts, clients, and/or VMs that are affected by the service device policies that will be required to implement the intent of the network service policy. Once those changes are determined, the network configuration logic 1600 can push configuration changes to the various network elements and cause the network element to direct network traffic from service device clients to the service device at block 1606. The nature of the configuration changes to the network elements can vary based on the service device and the specific service device policies that are implemented.)([0147] implement the policies includes generating a set of network configuration changes to insert the service device into the network and distributing the set of network configuration changes to one or more network elements on the network) ([0076, 0082, 0088] different device vendors )([0052][0093] propagation can include pushing configuration changes to each network element to enable the network elements to re-direct and/or modify the flow of network data across the network, such that network data to or from client devices identified by the policies of the service device is automatically re-directed to the service device.)([0076-0081, 0091, 0093] topology discover to monitor policies);
traversing the physical network to obtain a set of upstream network devices and a set of downstream network devices associated with the target network device, wherein the set of upstream network devices comprise target upstream network devices at the plurality of hierarchical layers, and the set of downstream network devices comprise target downstream network devices at the plurality of hierarchical layers ([0103] the network configuration logic 1600 can determine the configuration changes the network elements coupled to network hosts, clients, and/or VMs that are affected by the service device policies that will be required to implement the intent of the network service policy. Once those changes are determined, the network configuration logic 1600 can push configuration changes to the various network elements and cause the network element to direct network traffic from service device clients to the service device at block 1606. The nature of the configuration changes to the network elements can vary based on the service device and the specific service device policies that are implemented.)([0147] implement the policies includes generating a set of network configuration changes to insert the service device into the network and distributing the set of network configuration changes to one or more network elements on the network) ([0076, 0082, 0088] different device vendors )([0052][0093] propagation can include pushing configuration changes to each network element to enable the network elements to re-direct and/or modify the flow of network data across the network, such that network data to or from client devices identified by the policies of the service device is automatically re-directed to the service device.)([0076-0081, 0091, 0093] topology discover to monitor policies);
traversing the physical network to obtain a target neighboring device at a same hierarchical layer as the target network device ([0103] the network configuration logic 1600 can determine the configuration changes the network elements coupled to network hosts, clients, and/or VMs that are affected by the service device policies that will be required to implement the intent of the network service policy. Once those changes are determined, the network configuration logic 1600 can push configuration changes to the various network elements and cause the network element to direct network traffic from service device clients to the service device at block 1606. The nature of the configuration changes to the network elements can vary based on the service device and the specific service device policies that are implemented.)([0147] implement the policies includes generating a set of network configuration changes to insert the service device into the network and distributing the set of network configuration changes to one or more network elements on the network) ([0076, 0082, 0088] different device vendors )([0052][0093] propagation can include pushing configuration changes to each network element to enable the network elements to re-direct and/or modify the flow of network data across the network, such that network data to or from client devices identified by the policies of the service device is automatically re-directed to the service device.)([0076-0081, 0091, 0093] topology discover to monitor policies); and
determining the target upstream network devices, the target downstream network devices, and the target neighboring device as the extended network devices ([0103] the network configuration logic 1600 can determine the configuration changes the network elements coupled to network hosts, clients, and/or VMs that are affected by the service device policies that will be required to implement the intent of the network service policy. Once those changes are determined, the network configuration logic 1600 can push configuration changes to the various network elements and cause the network element to direct network traffic from service device clients to the service device at block 1606. The nature of the configuration changes to the network elements can vary based on the service device and the specific service device policies that are implemented.)([0147] implement the policies includes generating a set of network configuration changes to insert the service device into the network and distributing the set of network configuration changes to one or more network elements on the network) ([0076, 0082, 0088] different device vendors )([0052][0093] propagation can include pushing configuration changes to each network element to enable the network elements to re-direct and/or modify the flow of network data across the network, such that network data to or from client devices identified by the policies of the service device is automatically re-directed to the service device.)([0076-0081, 0091, 0093] topology discover to monitor policies).
Regarding claim 3, Dale and Lofti teach the method of claim 2,
Dales teaches wherein the traversing the physical network to obtain an set of upstream network devices and a set of downstream network devices associated with the target network device comprises ([0103] the network configuration logic 1600 can determine the configuration changes the network elements coupled to network hosts, clients, and/or VMs that are affected by the service device policies that will be required to implement the intent of the network service policy. Once those changes are determined, the network configuration logic 1600 can push configuration changes to the various network elements and cause the network element to direct network traffic from service device clients to the service device at block 1606. The nature of the configuration changes to the network elements can vary based on the service device and the specific service device policies that are implemented.)([0147] implement the policies includes generating a set of network configuration changes to insert the service device into the network and distributing the set of network configuration changes to one or more network elements on the network) ([0076, 0082, 0088] different device vendors )([0052][0093] propagation can include pushing configuration changes to each network element to enable the network elements to re-direct and/or modify the flow of network data across the network, such that network data to or from client devices identified by the policies of the service device is automatically re-directed to the service device.)([0076-0081, 0091, 0093] topology discover to monitor policies).
traversing the physical network to obtain a first set of devices at an upper hierarchical layer than that of the target network device and a second set of devices at a lower hierarchical layer than that of the target network device, wherein the first set of devices comprises a plurality of upstream network devices, and the second set of devices comprises a plurality of downstream network devices ([0103] the network configuration logic 1600 can determine the configuration changes the network elements coupled to network hosts, clients, and/or VMs that are affected by the service device policies that will be required to implement the intent of the network service policy. Once those changes are determined, the network configuration logic 1600 can push configuration changes to the various network elements and cause the network element to direct network traffic from service device clients to the service device at block 1606. The nature of the configuration changes to the network elements can vary based on the service device and the specific service device policies that are implemented.)([0147] implement the policies includes generating a set of network configuration changes to insert the service device into the network and distributing the set of network configuration changes to one or more network elements on the network) ([0076, 0082, 0088] different device vendors )([0052][0093] propagation can include pushing configuration changes to each network element to enable the network elements to re-direct and/or modify the flow of network data across the network, such that network data to or from client devices identified by the policies of the service device is automatically re-directed to the service device.)([0076-0081, 0091, 0093] topology discover to monitor policies).
determining a set of first providers corresponding to the first set of devices and a set of second providers corresponding to the second set of devices, wherein the set of first providers comprises a plurality of different first providers, and the set of second providers comprises a plurality of different second providers ([0103] the network configuration logic 1600 can determine the configuration changes the network elements coupled to network hosts, clients, and/or VMs that are affected by the service device policies that will be required to implement the intent of the network service policy. Once those changes are determined, the network configuration logic 1600 can push configuration changes to the various network elements and cause the network element to direct network traffic from service device clients to the service device at block 1606. The nature of the configuration changes to the network elements can vary based on the service device and the specific service device policies that are implemented.)([0147] implement the policies includes generating a set of network configuration changes to insert the service device into the network and distributing the set of network configuration changes to one or more network elements on the network) ([0076, 0082, 0088] different device vendors )([0052][0093] propagation can include pushing configuration changes to each network element to enable the network elements to re-direct and/or modify the flow of network data across the network, such that network data to or from client devices identified by the policies of the service device is automatically re-directed to the service device.)([0076-0081, 0091, 0093] topology discover to monitor policies).
selecting an upstream network device corresponding to each of the first providers from the first set of devices as the target upstream network device, and adding the target upstream network device to the set of upstream network devices ([0103] the network configuration logic 1600 can determine the configuration changes the network elements coupled to network hosts, clients, and/or VMs that are affected by the service device policies that will be required to implement the intent of the network service policy. Once those changes are determined, the network configuration logic 1600 can push configuration changes to the various network elements and cause the network element to direct network traffic from service device clients to the service device at block 1606. The nature of the configuration changes to the network elements can vary based on the service device and the specific service device policies that are implemented.)([0147] implement the policies includes generating a set of network configuration changes to insert the service device into the network and distributing the set of network configuration changes to one or more network elements on the network) ([0076, 0082, 0088] different device vendors )([0052][0093] propagation can include pushing configuration changes to each network element to enable the network elements to re-direct and/or modify the flow of network data across the network, such that network data to or from client devices identified by the policies of the service device is automatically re-directed to the service device.)([0076-0081, 0091, 0093] topology discover to monitor policies); and
selecting a downstream network device corresponding to each of the second providers from the second set of devices as the target downstream network device, and adding the target downstream network device to the set of downstream network devices ([0103] the network configuration logic 1600 can determine the configuration changes the network elements coupled to network hosts, clients, and/or VMs that are affected by the service device policies that will be required to implement the intent of the network service policy. Once those changes are determined, the network configuration logic 1600 can push configuration changes to the various network elements and cause the network element to direct network traffic from service device clients to the service device at block 1606. The nature of the configuration changes to the network elements can vary based on the service device and the specific service device policies that are implemented.)([0147] implement the policies includes generating a set of network configuration changes to insert the service device into the network and distributing the set of network configuration changes to one or more network elements on the network) ([0076, 0082, 0088] different device vendors )([0052][0093] propagation can include pushing configuration changes to each network element to enable the network elements to re-direct and/or modify the flow of network data across the network, such that network data to or from client devices identified by the policies of the service device is automatically re-directed to the service device.)([0076-0081, 0091, 0093] topology discover to monitor policies).
Regarding claim 7, Dale and Lofti teach the method of claim 1,
Dales does not explicitly teach, but Lofti teaches
wherein the establishing an emulated network topology based on the target network device and the extended network devices comprises ([0027] The distributed set of hardware resources execute emulated network devices that collectively recreate the functionality and operation of the hardware network devices of the target physical network)([0056] Fig. 3, step 360 instantiates (at 360) an emulated network device on each cloud instance) ([0029] replicating the topology, direct connectivity, and native communication of a target physical network in the cloud, some embodiments are then able to holistically and comprehensively validate configuration changes and their impact to the end state of the target physical network in the cloud without impacting the existing steady state of the target physical network. The validation allows network administrators to detect through the replicated network)([0103] replicated network may also be created in the cloud for planning, testing, and/or validating a target physical network before the target physical network is built)([0104-0112] network validation),
determining a first connection relationship between the target network device and the extended network devices, and second connection relationships between respective ones of the extended network devices ([0065-0073] Fig. 10, create ethernet interface on each emulated network drive)([0082-0090] Fig. 12, create topology bridge in the emulated network matching every device and connection with the physical network); and
establishing the emulated network topology based on the target network device, the extended network devices, the first connection relationship, and the second connection relationships ([0065-0073] Fig. 10, create ethernet interface on each emulated network drive)([0082-0090] Fig. 12, create topology bridge in the emulated network matching every device and connection with the physical network).
It would have been obvious to a person skilled in the art, before the effective filing date of the invention, to modify Dale in view of Lofti in order to create an emulation environment before making configuration changes in the real physical network because it will identify a modified end state of a network resulting from one or more changes to configurations of the hardware or physical network devices without modifying the running configurations on the network devices and knowing full scope of these changes without having risk of outages, blackholes, lost traffic on the real physical network (Lofti [0007-0008]).
Regarding claim 14, Dale and Lofti teach the method of claim 1,
Dales does not teach, but Lofti teaches
wherein the performing emulation verification on the emulated network topology based on the emulation runtime environment to obtain an emulation verification result ([0027] The distributed set of hardware resources execute emulated network devices that collectively recreate the functionality and operation of the hardware network devices of the target physical network)([0056] Fig. 3, step 360 instantiates (at 360) an emulated network device on each cloud instance.); ([0029] replicating the topology, direct connectivity, and native communication of a target physical network in the cloud, some embodiments are then able to holistically and comprehensively validate configuration changes and their impact to the end state of the target physical network in the cloud without impacting the existing steady state of the target physical network. The validation allows network administrators to detect through the replicated network)([0103] replicated network may also be created in the cloud for planning, testing, and/or validating a target physical network before the target physical network is built)([0104-0112] network validation), comprising:
obtaining a network verification task from the network verification request ([0031] network replication, instantiating and executing an emulated network device on a different set of hardware resources allocated from a different cloud machine. In some embodiments, the emulated network device executes a network device image);
obtaining, using the network verification task, a network verification strategy and a verification metric (Fig. 12, Create a topology VXLAN for each direct link)([0138] Fig. 1, The process creates (at 140) a host virtual machine on each provisioned set of hardware resources,)([0033-0040] Fig. 1, steps in Fig. 1 show strategy to create emulated network)([0106] This initial validation scans the steady state for any pre-existing errors including loops, blackholes, and other errors from improper addressing or connectivity. Pre-existing errors can void or otherwise compromise the end state resulting from a configuration change. In other words, the true end state resulting from a configuration change may not be reached because pre-existing errors prevent the configuration change from having the desired effect on the network or alter the effect the configuration change has on the network.);
performing, in the emulation runtime environment, emulation verification on the emulated network topology based on the network verification strategy, to obtain verification data corresponding to the verification metric ([0105-0120] Fig. 12, validation is successful, The process monitors (at 1650) the end state of the replicated network. In some embodiments, the monitoring involves detecting black holes (i.e., connectivity issues) or loops that form anywhere in the replicated network as a result of the applied changes. In some embodiments, the monitoring involves taking snapshots of the emulated network device routing and addressing tables and comparing the snapshots against routing and addressing table snapshots taken from the emulated network devices at the steady state prior to applying the configuration changes at step 1620. In some embodiments, the monitoring involves running a series of scripts, test cases, pings, traceroutes, etc. to detect connectivity issues or observe the routing or forwarding behavior of the emulated network devices. From such monitoring, erroneous or anomalous behavior including improper forwarding or routing of packets, packet loss, and improper modification of packets can be detected.); and
generating the emulation verification result based on the verification metric and the verification data ([0105-0120] Fig. 12, validation is successful, The process monitors (at 1650) the end state of the replicated network. In some embodiments, the monitoring involves detecting black holes (i.e., connectivity issues) or loops that form anywhere in the replicated network as a result of the applied changes. In some embodiments, the monitoring involves taking snapshots of the emulated network device routing and addressing tables and comparing the snapshots against routing and addressing table snapshots taken from the emulated network devices at the steady state prior to applying the configuration changes at step 1620. In some embodiments, the monitoring involves running a series of scripts, test cases, pings, traceroutes, etc. to detect connectivity issues or observe the routing or forwarding behavior of the emulated network devices. From such monitoring, erroneous or anomalous behavior including improper forwarding or routing of packets, packet loss, and improper modification of packets can be detected).
It would have been obvious to a person skilled in the art, before the effective filing date of the invention, to modify Dale in view of Lofti in order to create an emulation environment before making configuration changes in the real physical network because it will identify a modified end state of a network resulting from one or more changes to configurations of the hardware or physical network devices without modifying the running configurations on the network devices and knowing full scope of these changes without having risk of outages, blackholes, lost traffic on the real physical network (Lofti [0007-0008]).
Regarding claim 15, claim 15 is rejected with the same reasoning as claim 1.
Regarding claim 16, claim 16 is rejected with the same reasoning as claim 2.
Regarding claim 17, claim 17 is rejected with the same reasoning as claim 3.
Regarding claim 20, claim 20 is rejected with the same reasoning as claim 1.
Allowable Subject Matter
Claims 4-6, 8-13, 18-19 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
The following is the reason for allowable subject matter in claims 4 and 18.
The prior arts (“Dale”, US 20170099187 A1) and (“Lofti”, US 20190068456 A1) fail to teach or suggest fairly detecting whether respective upstream network devices in the first set of devices belong to a root node, to obtain a first detection result; determining an upstream network device with the first detection result of not belonging to a vertex as a reference upstream network device, and traversing the physical network to obtain a third set of devices of an upper hierarchical layer of the reference upstream network device, wherein the third set of devices comprises a plurality of upstream network devices; determining a set of third providers corresponding to the third set of devices, wherein the set of third providers comprises a plurality of different third providers; and selecting an upstream network device corresponding to each of the third providers from the third set of devices as the target upstream network device, and adding the target upstream network device to the set of upstream network devices until the upstream network devices belonging to the root node have been traversed.
The following is the reason for allowable subject matter in claim 6.
The prior arts (“Dale”, US 20170099187 A1) and (“Lofti”, US 20190068456 A1) fail to teach or suggest fairly wherein the traversing the physical network to obtain a target neighboring device at a same hierarchical layer as the target network device comprises: traversing the physical network to obtain candidate neighboring devices at a same hierarchical layer as the target network device; and determining a candidate neighboring device with no device change as the target neighboring device.
The following is the reason for allowable subject matter in claim 8.
The prior arts (“Dale”, US 20170099187 A1) and (“Lofti”, US 20190068456 A1) fail to teach or suggest fairly obtaining a set of links between every two network devices in the emulated network topology, wherein the set of links comprises at least an original link for connecting two network devices; pruning the original link in the set of links to obtain a pruned target link; and updating the set of links based on the target link.
The following is the reason for allowable subject matter in claim 11.
The prior arts (“Dale”, US 20170099187 A1) and (“Lofti”, US 20190068456 A1) fail to teach or suggest fairly wherein the establishing an emulation runtime environment corresponding to the emulated network topology comprises: obtaining a hierarchical layer number of the emulated network topology; determining a corresponding number of target hosts based on the hierarchical layer number, and determining a container number in the target hosts based on a device number of network devices at each hierarchical layer; deploying the container number of containers in the target hosts; and establishing a connection relationship between respective containers in the target hosts and a connection relationship between containers in different target hosts, to obtain the emulation runtime environment.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FADI HAJ SAID whose telephone number is (571)272-2833. The examiner can normally be reached on 8:00 AM - 5:00 PM EST. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, John Follansbee can be reached on 571-272-3964. 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 https://ppair-my.uspto.gov/pair/PrivatePair. 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.
/FADI HAJ SAID/Primary Examiner, Art Unit 2444