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 .
Claims 1-18 are pending per amendment.
Response to Arguments
Claim 17 objection: Applicants’ amendments to overcome objection are persuasive. The objection is withdrawn.
Double Patenting rejection: Applicants’ 6/25/26 terminal disclaimer was disapproved because signee is not the applicant, patentee and/or an attorney of record. See 37 CFR 1.321(a) and (b).
103 rejection: Applicants’ arguments filed have been fully considered but they are not persuasive. Applicants allege Chang-Watt combination fails to teach newly-presented limitation “wherein the extended subnet comprises a shared IP address range between the public cloud network and the on-premises network such that an IP address assigned to the software component prior to migration is preserved after migration to the public cloud network”.
Watt explicitly discloses a created/fused network that extends across data center environments 120, 130, and 140. Moreover, servers among the various data center environments “are all connected to the overlay network OVNET 10, share a subnet, and communicate as if they were connected to the same local LAN” (par. 0050 and 0051). A generally accepted definition of subnet is a logical subdivision of an IP network. As such, the Chang-Watt combination necessarily teaches a subnet with a range (i.e., two or more) of addresses among the entities residing on the on-premises and public cloud networks connected the ICX and ICS network entities of Chang (par. 0031 and 0032). Moreover, Chang teaches “The L2 network extension 170 allows VMs migrated to public cloud to preserve their enterprise IP addresses and MAC addresses as well as their network and security (e.g. ACL, Firewall) policies (par. 0037).
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-17 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-16 of U.S. Patent No. 12192279 (hereinafter ‘279), in view of Chang US 20160352682, in view of Watt US 20150096011. All instant, enumerated limitations in following table are anticipated by a correspondingly mapped ‘279 claim except for
“wherein the extended subnet comprises a shared IP address range between the public cloud network and the on-premises network such that an IP address assigned to the software component prior to migration is preserved after migration to the public cloud network”
However, in a related field, Chang is relied upon for its teachings of VMs migrated to public cloud to preserve their enterprise IP addresses and MAC addresses and an extended subnet (par. 0037).
It would have been obvious to one of ordinary skill before effective filing date of instant application to have introduced Chang’s teachings alongside ‘279. The motivation to combine would have been to avoid reconfiguration required with VM migration where a different IP address is assigned to VM (Chang, par. 0037)
‘279-Chang combination fails to explicitly disclose “wherein the extended subnet comprises a shared IP address range”
However, in a related field, Watt discloses an overlay network that extends across data center environments 120, 130, and 140. Servers among the various data center environments “are all connected to the overlay network OVNET 10, share a subnet, and communicate as if they were connected to the same local LAN” (par. 0050 and 0051).
It would have been obvious to one of ordinary skill before effective filing date of instant application to have introduced Watt’s teachings alongside ‘279-Chang. The motivation to combine would have been to facilitate migration of complex computer applications/workloads between servers in a hybrid cloud environment without modification to th.e applications/workloads (Watt, abstract & par. 0051)
Instant claims
‘279 claims
1. A system supporting transferring content between an on-premises network and a public cloud network, comprising: a first gateway associated with the on-premises network, the first gateway comprising hardware and software, the first gateway further comprising
a first address control logic configured to resolve linked layer addressing of a host of the cloud;
a second gateway associated with the public cloud network, the second gateway comprising a second address control logic configured to resolve linked layer addressing of a host of the on-premises network;
a secure communication path between the first and second gateways that extends subnet of the on-premises network to the public cloud network, wherein the extended subnet comprises a shared IP address range between the public cloud network and the on-premises network; and
data control logic deployed within the first and second gateways configured to route messages from hosts of the subnet so that an on-premises network logic may communicate with a software component that was migrated from the on-premises network to the public cloud network.
wherein the extended subnet comprises a shared IP address range between the public cloud network and the on-premises network such that an IP address assigned to the software component prior to migration is preserved after migration to the public cloud network
2. The system of claim 1, wherein the secured connection path is a tunnel over DX or IPSec.
3. The system of claim 1, wherein the link layer address comprises a MAC address assigned to the host of the on-premises network.
4. The system of claim 1, wherein the first gateway is virtualized and is comprised of software.
5. The system of claim 1, wherein the hardware comprises a processor and a communication interface.
6. The system of claim 5, wherein in the hardware comprises a non-transitory computer-readable storage medium that stores a tunneling logic, a MAC address resolution logic, and a NAT logic.
7. The system of claim 6, wherein the non-transitory computer-readable storage medium includes a data store that maintains information associated with the first software instance.
9. The system of claim 7, wherein the MAC address resolution logic, upon execution by the processor, is configured to detect an ARP request and accesses content of the non-transitory computer-readable storage medium to determine if the ARP request is directed to first software instance.
10. The system of claim 9, wherein the MAC address resolution logic is configured to generate an ARP reply including a MAC address of the second gateway.
11. The system of claim 6, wherein the NAT logic, upon execution by the processor, is configured to perform translation of an IP address for data packets transmitted between the host of the on-premises network and a host of the cloud computing network using a phantom subnet.
12. The system of claim 11, wherein the NAT logic creates a destination NAT entry to translate the first IP address from a real IP address associated with the subnet into a temporary IP address associated with the phantom subnet.
13. The system of claim 11, wherein an inverse translation is conducted where the temporary IP address associated with the phantom subnet is returned back to the real IP address associated with the subnet.
14. The system of claim 7, wherein the second gateway comprises a MAC address resolution logic configured as a proxy interface.
15. The system of claim 14, wherein the proxy interface enables the public cloud network to identify the host of the on-premises network targeted by an ARP request message initiated by the host of the public cloud network and issue an ARP reply message.
16. The system of claim 15, wherein the proxy interface forwards traffic to and from the host of the on-premises network.
8. The system of claim 6, wherein: the processor and the communication interface are coupled together via a transmission medium; and the secure communication path is established by the communication interface.
17. The system of claim 1, a proxy network interface for each host in the subnet of the on-premises network to allow the public cloud network to be aware of hosts of the on-premises network (maps to ‘279, claim 1).
1. A system supporting transferring content between an on-premises network and a public cloud network, comprising: a first gateway associated with the on-premises network, the first gateway comprising hardware and software, the first gateway further comprising
a first address control logic configured to resolve linked layer addressing of a host of the cloud;
a second gateway associated with the public cloud network, the second gateway comprising: a second address control logic configured to resolve linked layer addressing of a host of the on-premises network, and
a proxy network interface for each host in a subnet of the on-premises network to allow the public cloud network to be aware of hosts of the on-premises network;
a secure communication path between the first and second gateways that extends the subnet of the on-premises network to the public cloud network, wherein the extended subnet comprises a shared IP address range between the public cloud network and the on-premises network; and
data control logic deployed within the first and second gateways configured to route messages from hosts of the subnet so that an on-premises network logic may communicate with a software component that was migrated from the on-premises network to the public cloud network.
2. The system of claim 1, wherein the secured connection path is a tunnel over DX or IPSec.
3. The system of claim 1, wherein the link layer address comprises a MAC address assigned to the host of the on-premises network.
4. The system of claim 1, wherein the first gateway is virtualized and is comprised of software.
5. The system of claim 1, wherein the hardware comprises a processor and a communication interface.
6. The system of claim 5, wherein in the hardware comprises a non-transitory computer-readable storage medium that stores a tunneling logic, a MAC address resolution logic, and a NAT logic.
7. The system of claim 6, wherein the non-transitory computer-readable storage medium includes a data store that maintains information associated with the first software instance.
8. The system of claim 7, wherein the MAC address resolution logic, upon execution by the processor, is configured to detect an ARP request and accesses content of the non-transitory computer-readable storage medium to determine if the ARP request is directed to first software instance.
9. The system of claim 8, wherein the MAC address resolution logic is configured to generate an ARP reply including a MAC address of the second gateway.
14. The system of claim 6, wherein the NAT logic, upon execution by the processor, is configured to perform translation of an IP address for data packets transmitted between the host of the on-premises network and a host of the cloud computing network using a phantom subnet.
15. The system of claim 14, wherein the NAT logic creates a destination NAT entry to translate the first IP address from a real IP address associated with the subnet into a temporary IP address associated with the phantom subnet.
16. The system of claim 14, wherein an inverse translation is conducted where the temporary IP address associated with the phantom subnet is returned back to the real IP address associated with the subnet.
10. The system of claim 7, wherein the second gateway comprises a MAC address resolution logic configured as a proxy interface.
11. The system of claim 10, wherein the proxy interface enables the public cloud network to identify the host of the on-premises network targeted by an ARP request message initiated by the host of the public cloud network and issue an ARP reply message.
12. The system of claim 11, wherein the proxy interface forwards traffic to and from the host of the on-premises network.
13. The system of claim 6, wherein: the processor and the communication interface are coupled together via a transmission medium; and the secure communication path is established by the communication interface.
Claim 1 limitation “a proxy network interface for each host in a subnet of the on-premises network to allow the public cloud network to be aware of hosts of the on-premises network”
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.
Claims 1-5 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Chang US 20160352682, in view of Watt US 20150096011.
For claim 1, Chang discloses:
A system supporting transferring content between an on-premises network and a public cloud network, comprising:
a first gateway associated with the on-premises network (par. 0031: InterCloud Extender (ICX) performs functions of cloud gateway 125 and provides a layer 2 secure extension which stretches enterprise VLAN segments to public cloud with TLS/DTLS overlay tunnels), the first gateway comprising hardware and software (par. 0047: “Computer system 750 is an example of computer hardware, software, and firmware that can be used to implement the disclosed technology.”), the first gateway further comprising a first address control logic configured to resolve linked layer addressing of a host of the cloud (par. 0045: Enterprise router 404 of private cloud responds to ARP request of VM operating on private cloud attempting to communicate with VM operating on public cloud);
a second gateway associated with the public cloud network (par. 0032: “ICX 408 located on private cloud 402 and InterCloud Switch (ICS) 414 located on the public cloud 403 can be responsible for establishing a secure tunnel (L2 network extension) 170 between private cloud 402 and public cloud 403.”), the second gateway comprising a second address control logic configured to resolve linked layer addressing of a host of the on-premises network (par. 0038: “…all inter-VM and external network access network traffic can be forwarded through ICS 415. The present technology utilizes a Default Gateway Extension Module 415 to have ICS 414 to intercept any ARP request for resolving the MAC address of a given default gateway IP address.”);
a secure communication path between the first and second gateways (par. 0032: Secure tunnel established between ICX 408 and ICS 414); and
data control logic deployed within the first and second gateways configured to route messages from hosts of the subnet so that an on-premises network logic may communicate with a software component that was migrated from the on-premises network to the public cloud network (par. 0037: “The L2 network extension 170 allows VMs migrated to public cloud to preserve their enterprise IP addresses and MAC addresses as well as their network and security (e.g. ACL, Firewall) policies. This can be accomplished by encapsulating L2 data within a secure transport layer (e.g., Layer 4) tunnel that bridges the two clouds.” Par. 0024, 0031, 0032 & Fig 4: Cloud gateways 125 disclosed).
wherein the extended subnet comprises a IP address range between the public cloud network and the on-premises network such that an IP address assigned to the software component prior to migration is preserved after migration to the public cloud network (par. 0037: VMs migrated to public cloud to preserve their enterprise IP addresses and MAC addresses”).
Chang fails to explicitly disclose “[a path] that extends subnet of the on-premises network to the public cloud network, wherein the extended subnet comprises a shared IP address range between the public cloud network and the on-premises network; wherein the extended subnet comprises a shared IP address range between the public cloud network and the on-premises network”
However, in a related field, Watt discloses an overlay network that extends across data center environments 120, 130, and 140. Servers among the various data center environments “are all connected to the overlay network OVNET 10, share a subnet, and communicate as if they were connected to the same local LAN” (par. 0050 and 0051).
It would have been obvious to one of ordinary skill before effective filing date of instant application to have introduced Watt’s teachings alongside Chang. The motivation to combine would have been to facilitate migration of complex computer applications/workloads between servers in a hybrid cloud environment without modification to the applications/workloads (Watt, abstract & par. 0051)
For claim 2, Chang-Watt discloses:
The system of claim 1, wherein the secured connection path is a tunnel over DX or IPSec (Chang, par. 0022: IPSEC VPN).
For claim 3, Chang-Watt discloses:
The system of claim 1, wherein the link layer address comprises a MAC address assigned to the host of the on-premises network (Chang, par. 0037: VM/server MAC address disclosed).
For claim 4, Chang-Watt discloses:
The system of claim 1, wherein the first gateway is virtualized and is comprised of software (Chang, par. 0019: “The cloud gateway 125 at the private cloud can be configured as a VM running in the private cloud (enterprise datacenter) that is responsible to establish a communication link 170 for interconnecting the components in the public cloud with the private cloud.”).
For claim 5, Chang-Watt discloses:
The system of claim 1, wherein the hardware comprises a processor and a communication interface (Chang, Fig 7, communication interface 740 & processor 710).
For claim 17, Chang-Watt discloses:
The system of claim 1, a proxy network interface for each host in the subnet of the on-premises network to allow the public cloud network to be aware of hosts of the on-premises network (Chang, par. 0023 & 0038: L2 network extension between private and public cloud provides for communication/discovery among devices dispersed across public and private clouds.).
Claims 6-16 are rejected under 35 U.S.C. 103 as being unpatentable over Applicant disclosed Chang US 20160352682, in view of Applicant disclosed Watt US 20150096011, in view of Applicant disclosed Purushotham (US 20160380832).
For claim 6, Chang-Watt discloses:
The system of claim 5, wherein in the hardware comprises a non-transitory computer-readable storage medium that stores a tunneling logic, a MAC address resolution logic (par. 0022: Tunnel communication link & MAC address network identities disclosed).
The combination fails to disclose “and a NAT logic”. In a related field, Purushotham discloses par. 0023: “Gateway 124 may manage external public IP addresses for VMs 120 and route traffic incoming to and outgoing from private cloud system 102 and provide networking services, such as firewalls, network address translation (NAT), dynamic host configuration protocol (DHCP), load balancing, and virtual private network (VPN) connectivity over a network 140.”; par. 0030: Communication between on-premise and cloud-side gateways disclosed)
It would have been obvious to one of ordinary skill before effective filing date of claimed invention to have introduced Purushotham’s teachings alongside Chang-Watt. The motivation to combine would have been to manage internal and external traffic routing among VMs operating in private and public clouds (Purushotham, par. 0029 and 0030).
For claim 7, Chang-Watt-Purushotham discloses:
The system of claim 6, wherein the non-transitory computer-readable storage medium includes a data store that maintains information associated with the first software instance (Chang, par. 0026: “FIG. 2 illustrates VM1 150 on private cloud 105 being migrated to public cloud 110, where it is illustrated as VM1 150.sub.1. Migration is managed using virtual supervisor module 130 to take VM1 150 offline, and migrated using hybrid cloud manager 175 to copy the VM1 150 disk image to public cloud 110, and instantiate it in the public cloud.”).
For claim 8, Chang-Watt-Purushotham discloses:
The system of claim 6, wherein: the processor and the communication interface are coupled together via a transmission medium (Chang, Fig. 7, comm. interface 740 and processor 710 connected by bus 705); and the secure communication path is established by the communication interface (Chang, par. 0031: “…an InterCloud Extender (ICX) 408 can perform functions of a cloud gateway 125 and provide a Layer 2 Secure Extension 170 which stretches enterprise VLAN segments to public cloud with TLS/DTLS overlay tunnels).
For claim 9, Chang-Watt-Purushotham discloses:
The system of claim 7, wherein the MAC address resolution logic, upon execution by the processor, is configured to detect an ARP request and accesses content of the non-transitory computer-readable storage medium to determine if the ARP request is directed to first software instance (Chang, par. 0038: “The present technology utilizes a Default Gateway Extension Module 415 to have ICS 414 to intercept any ARP request for resolving the MAC address of a given default gateway IP address. ICS 414 can then fabricate an ARP response, which contains ICF router 416's MAC address and send the fabricated response to the requesting VM.”).
For claim 10, Chang-Watt-Purushotham discloses:
The system of claim 9, wherein the MAC address resolution logic is configured to generate an ARP reply including a MAC address of the second gateway (Chang, par. 0043: “Further, various VMs from various clouds might be configured to look for IP addresses for various routers; default gateway extension module 415 can intercept ARP requests for these IP addresses and return a fabricated response with the MAC address of the local router.”).
For claim 11, Chang-Watt-Purushotham discloses:
The system of claim 6, wherein the NAT logic, upon execution by the processor, is configured to perform translation of an IP address for data packets transmitted between the host of the on-premises network and a host of the cloud computing network using a phantom subnet (Purushotham, par. 0023: network address translation (NAT) disclosure; Chang, par. 0024: “The L2 network is thus further extended and connected to each of the cloud VMs…through the cloud gateway 135 deployed at the public cloud 110. With an L2 network overlay, all instances of a particular private application VM, e.g., VM3 154 can be seamlessly migrated to the overlay network dynamically created at the public cloud, without any impacts to the existing corporate infrastructure.” Same rationale to combine as applied in claim 6).
For claim 12, Chang-Watt-Purushotham discloses:
The system of claim 11, wherein the NAT logic creates a destination NAT entry to translate the first IP address from a real IP address associated with the subnet into a temporary IP address associated with the phantom subnet (Purushotham, par. 0023: network address translation (NAT) disclosure. Same rationale to combine as applied in claim 6).
For claim 13, Chang-Watt-Purushotham discloses:
The system of claim 11, wherein an inverse translation is conducted where the temporary IP address associated with the phantom subnet is returned back to the real IP address associated with the subnet (Purushotham, par. 0023. Same rationale to combine as applied in claim 6).
For claim 14, Chang-Watt-Purushotham discloses:
The system of claim 7, wherein the second gateway comprises a MAC address resolution logic configured as a proxy interface (Chang, par. 0038: “The present technology utilizes a Default Gateway Extension Module 415 to have ICS 414 to intercept any ARP request for resolving the MAC address of a given default gateway IP address. ICS 414 can then fabricate an ARP response, which contains ICF router 416's MAC address and send the fabricated response to the requesting VM.”).
For claim 15, Chang-Watt-Purushotham discloses:
The system of claim 14, wherein the proxy interface enables the public cloud network to identify the host of the on-premises network targeted by an ARP request message initiated by the host of the public cloud network and issue an ARP reply message (Chang, par. 0037: “The L2 network extension 170 allows VMs migrated to public cloud to preserve their enterprise IP addresses and MAC addresses as well as their network and security (e.g. ACL, Firewall) policies. This can be accomplished by encapsulating L2 data within a secure transport layer (e.g., Layer 4) tunnel that bridges the two clouds.”; par. 0038: “The present technology utilizes a Default Gateway Extension Module 415 to have ICS 414 to intercept any ARP request for resolving the MAC address of a given default gateway IP address.”).
For claim 16, Chang-Watt-Purushotham discloses:
The system of claim 15, wherein the proxy interface forwards traffic to and from the host of the on-premises network (Chang, par. 0032: “ICX 408 located on private cloud 402 and InterCloud Switch (ICS) 414 located on the public cloud 403 can be responsible for establishing a secure tunnel (L2 network extension) 170 between private cloud 402 and public cloud 403. All inter-VM and provider network access network traffic can be forwarded through ICS 414.”).
Allowable Subject Matter
Claim 18 is 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.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CLAYTON R WILLIAMS whose telephone number is (571)270-3801. The examiner can normally be reached M-F 10:00am - 6:00pm.
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, Nicholas Taylor can be reached at 571-272-3889. 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.
/CLAYTON R WILLIAMS/Primary Examiner, Art Unit 2443
Prosecution Insights