DETAILED ACTION
This action is in response to communication filed on 2/26/2026.
Claims 1-24 are pending.
Claims 1, 19 and 20 have been amended.
Claims 21-24 have been added.
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 .
Response to Arguments
Applicant's arguments filed 2/26/2026 have been fully considered but they are not persuasive.
In the communication filed, applicant argues in substance that:
Neither Joshi nor Kim, individually or in combination, teaches or suggest “dynamically updating a destination network address (DNAT)…including dynamically updating the DNAT based at least in part on results from a most recent DNS re-resolution to indicate a set of application servers that are healthy among the plurality of application servers identified by a DNS server in response the DNS re-resolution”. Applicant interprets this limitation narrowly as requiring an internal DNAT table/rule update in a ZTN connector that is directly driven by and limited to the exact plurality of IP addresses returned in the most recent DNS response with health probing then filtering that specific DNS-identified set to produce only healthy servers in the DNAT pool.
Under the broadest reasonable interpretation, the limitation requires a system that (i) performs DNS re-resolution to obtain a plurality of backend IP addresses identified by a DNS server, (ii) performs health/probing checks, and (iii) dynamically updates DNAT rules so that the active DNAT pool reflects only healthy servers from that DNS identified plurality. The combination of Joshi and Kim teaches this interpretation.
Joshi discloses the DNS re-resolution and health-identification steps: the GSLB switch acts as a DNS proxy that performs re-resolution (or receives results) of an application FQDN, obtains the plurality of IP addresses from the authoritative DNS server, performs (distributed or centralized) periodic health checks probing on those servers, and dynamically uses the most recent health results to identify and select the healthy subset among the DNS-identified plurality (see Joshi, [0014-0016, 0024]).
Kim discloses the dynamic DNAT update step; the load balancer maintains versioned DNAT tables that map a virtual IP (VIP) to destination Ips (DIPs) of the current healthy compute-node pool; upon any change in node health/status (detected via failure or removal events that parallel the probing results), a new DNAT table is created for new flows that automatically reflects only the live/healthy DIPs, with resilient redirection of any affected flows to other healthy nodes (see Kim, [0010, 0039]).
Therefore, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed to combine the references by using Joshi’s DNS re-resolution results (the identified plurality of backend servers) as the input pool for Kim’s DNAT tables, then dynamically updating those DNAT rules based on the most recent DNS results and the latest probing/health data to ensure the DNAT only forwards to healthy servers from the DNS-identified set. This yields the predictable benefits of providing DNS-based load balancing internally (via DNAT) without exposing backend changes to clients or breaking NAT, a recognized need in gateway/connector-based load balancers. The motivation to combine is not hindsight but flows directly from the reference themselves. Both address load balancing across multiple application servers with health awareness (Joshi at the DNS layer for discovery and selection; Kim at the forwarding/NAT layer for resilience), and the art recognizes the benefit of integrating DNS discovery with internal NAT-based forwarding for efficient, failure-resilient traffic distribution in network appliances (see Joshi [0003] and Kim [0002]). Therefore, the rejection is maintained.
Claim Objections
Claim 1 is objected to because of the following informalities: Claim 1 appears to have omitted the element “a Zero Trust Network (ZTN) connector service” but this element appears in independent claim 19 and 20. Further, applicant references this element in the arguments and newly added claims 21 and 23 which depend on claim 1. Therefore examiner has interpreted this element is included in claim 1. Appropriate correction is required.
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 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 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-7, 9-20 are rejected under 35 U.S.C. 103 as being unpatentable over Joshi et al. (US 2010/0121932) in view of Kim et al. (US 2018/0337860) in view of Jain et al. (US 2024/0250929).
Regarding claim 1, Joshi discloses a system, comprising: one or more processors configured to:
perform a DNS re-resolution for resolving an application Fully Qualified Domain Name (FQDN) to obtain a plurality of IP addresses for a plurality of application servers (Joshi discloses a GSLB switch performing DNS resolution (re-resolution on TTL expiration) for a host name (FQDN) to obtain multiple IP addresses for host servers; see [0019] “this list of IP addresses is either retrieved from local DNS server's 30 cache, if the TTL of the responsive IP addresses in the cache has not expired, or obtained from GSLB switch 12, as a result of a recursive query”. This discloses the limitation because re-resolution via recursive query obtains plural Ips for application servers when cache/TTL expires);
perform periodic application server probing (Joshi discloses periodic health checks (probing) of host servers and applications by site switches; see [0054] “Periodic updates are sent at the block 210 periodically from the remote metric agent 407 to the metric collector to communicate to it the latest health information”. This discloses the limitation because periodic probing assesses server/application health); and
“to provide DNS load balancing for application traffic” and “wherein the ‘DNAT’ is updated based at least in part on one or more of the DNS re-resolution and the application server probing, including dynamically updating the DNAT based at least in part on results from a most recent DNS re-resolution to indicate a set of application servers that are healthy among the plurality of application servers identified by a DNS server in response to the DNS re-resolution (Joshi discloses the GSLB switch acts as a DNS proxy, receives the list of IP addresses from the authoritative DNS server (i.e., performs DNS re-resolution), receives periodic/distributed health-check/probing results from site switches, updates its internal records with the most recent DNS response and the latest health information, and them modifies/orders the DNS response to return only healthy servers from the DNS-identified plurality, thereby providing DNS load balancing of application traffic exclusively to those healthy application servers; [0014-0015] “When a client program requests a resolution of a host name, the GSLB switch, acting as a proxy of an authoritative DNS, returns one or more ordered IP addresses for the host name. The IP addresses are ordered using metrics that include the information collected from the site switches… One of these metrics includes health check information, which is indicative of the host servers' health…If a server fails one of these health checks, it is disqualified from being the "best" IP address.”, [0016] “The health checking may thus be performed independently of a request from the GSLB switch…The distributed health checking allows for reduction in GSLB processing load, reduction in health-check traffic, and increased scalability due to the distribution. Each metric agent generates a health status report, and provides this report to the GSLB switch… On receiving the health status report, the GSLB switch processes the health check information therein, updates its records accordingly, and uses the health information to evaluate or modify the DNS response”, [0024] “DNS proxy module 403 (a) receives incoming DNS requests, (b) provides the host names to be resolved to DNS server 16, (c) receives from DNS server 16 a list of responsive IP addresses, (d) orders the IP addresses on the list received from DNS server 16 according to an embodiment of the present invention, using the metrics collected by routing-metric collector 405 and metric collector 406… and (e) provides the ordered list of IP addresses to the requesting DNS server” ).
a memory coupled to the one or more processors and configured to provide the one or more processors with instructions.
However, the prior art does not explicitly disclose “dynamically update a destination network address translation (DNAT)”, “the DNAT is updated based at least in part on one or more of the DNS re-resolution and the application server probing”, and “dynamically updating the DNAT based at least in part on results from a most recent DNS re-resolution to indicate a set of application servers that are healthy among the plurality of application servers”
Kim in the field of the same endeavor discloses techniques for a load balancer to distribute packet flows addressed to a group of data compute nodes (DCNs) using multiple versioned destination network address translation (DNAT) tables, dynamically creating new tables upon DCN additions or removals to handle new flows while persevering existing ones. In particular, Kim teaches the following:
“dynamically update a destination network address translation (DNAT)”, “the DNAT is updated based at least in part on one or more of the DNS re-resolution and the application server probing”, and “dynamically updating the DNAT based at least in part on results from a most recent DNS re-resolution to indicate a set of application servers that are healthy among the plurality of application servers” (Kim discloses load balancer dynamically creates/updates versioned DNAT tables based on the most recent server-health/availability information (removal of failed servers) so that the DNAT indicates and load-balances new flows only across the live/healthy servers in the current pool; see [0010] “Even after a new DNAT table version is created, the load balancer continues to process all prior flows…while allowing the older flows…Older flows that were being directed to the removed DCN will have to be spread to other DCNs” and [0039] “each time a DCN is removed (e.g., fails or is shut off) from the group, and its DIP should no longer be used, the load balancer of some embodiments creates a new DNAT table to store the available DIPs for the new flows that it receives…each DNAT table is a resilient table that upon removal of one of the DIPs that is identified by its records, directs packet flows that map to the removed DIP to one of the live DIPs that is identified by another one of its records”).
Therefore, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed to combine the references by using Joshi’s DNS re-resolution results (the identified plurality of backend servers) as the input pool for Kim’s DNAT tables, then dynamically updating those DNAT rules based on the most recent DNS results and the latest probing/health data to ensure the DNAT only forwards to healthy servers from the DNS-identified set. This yields the predictable benefits of providing DNS-based load balancing internally (via DNAT) without exposing backend changes to clients or breaking NAT, a recognized need in gateway/connector-based load balancers. The motivation to combine is not hindsight but flows directly from the reference themselves. Both address load balancing across multiple application servers with health awareness (Joshi at the DNS layer for discovery and selection; Kim at the forwarding/NAT layer for resilience), and the art recognizes the benefit of integrating DNS discovery with internal NAT-based forwarding for efficient, failure-resilient traffic distribution in network appliances (see Joshi [0003] and Kim [0002]). Therefore, the rejection is maintained.
However the prior art does not explicitly disclose a Zero Trust Network (ZTN) connector service.
Jain in the field of the same endeavor discloses a zero-trust DNS resolution system that uses synthetic IP addresses to securely acquire and route application traffic via a zero-trust client and service. In particular, Jain teaches the following:
a Zero Trust Network (ZTN) connector service (Jain [0028-0029] “FIG. 1 illustrates an environment 100 where zero-trust domain name resolution may be performed…. The local machine 102 includes a zero-trust client 104. The zero-trust client 104 is a security application running on the local machine 102. As will be illustrated below, the zero-trust client 104 is configured to facilitate secure communications between the local machine 102 and company resources and/or other internet connected endpoints by using synthetic IP addresses generated by the zero-trust client 104”).
Therefore, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed to modify the prior art with the teaching of Jain in order to incorporate a zero-trust DNS resolution system that uses synthetic IP addresses to securely acquire and route application traffic. One would been motivated because integrating Jain’s zero-trust DNS resolution and secure connectors with polling for endpoint health into DNAT load balancing, predictably enhancing security and access control for private application.
Regarding claim 2, Joshi-Kim-Jain discloses the system of claim 1, wherein the DNAT is updated to indicate a set of application servers that are healthy among the plurality of application servers identified by a DNS server in response to the DNS re-resolution (see Kim [0039] each time a DCN is removed (e.g., fails or is shut off) from the group, and its DIP should no longer be used, the load balancer of some embodiments creates a new DNAT table to store the available DIPs for the new flows that it receives).
Regarding claim 3, Joshi-Kim-Jain discloses the system of claim 2, wherein an application server is deemed healthy in response to determining that the application server handles application traffic based at least in part on the periodic application server probing (see Joshi [0028] the health check module 402 can "ping" the real ports associated with a virtual port of a VIP to determine if they respond. If it finds at least one such responsive real port, it concludes that the virtual port of the VIP is healthy).
Regarding claim 4, Joshi-Kim-Jain discloses the system of claim 2, wherein the DNAT is dynamically and automatically updated based on results from a most recent DNS re-resolution and a most recent application server probing (see Kim [0054] the newly created DNAT table will also be used to process any flow that the load balancer was previously routing to the removed DIP and Joshi [0054] Periodic updates are sent at the block 210 periodically from the remote metric agent 407 to the metric collector to communicate to it the latest health information).
Regarding claim 5, Joshi-Kim-Jain discloses the system of claim 1, wherein the DNS re-resolution is performed periodically according to a predefined frequency (see Joshi [0054] the interval between periodic health check messages is user-configurable, and can range between 2-120 seconds).
Regarding claim 6, Joshi-Kim-Jain discloses the system of claim 1, wherein the DNS re-resolution is performed based on a time to live (TTL) indication (see Joshi [0054] Periodic updates are sent at the block 210 periodically from the remote metric agent 407 to the metric collector to communicate to it the latest health information).
Regarding claim 7, Joshi-Kim-Jain discloses the system of claim 1, wherein the application traffic is mapped to a virtual IP address that is used by a client device to access an application provided by the plurality of application servers (see Kim [0006] the load balancer distributes data packets that are addressed to a VIP address that is associated with a group of destination compute nodes (e.g., a group of webservers, application servers, or database servers), to different destination IP addresses (DIPs) of the different destination nodes).
Regarding claim 9, Joshi-Kim-Jain discloses the invention substantially, however the prior art does not explicitly disclose the system of claim 1, wherein the DNS proving is performed by a Zero Trust Network (ZTN) connector service that connects application traffic to a set of application servers in a DNAT pool.
Jain in the field of the same endeavor discloses a zero-trust DNS resolution system that uses synthetic IP addresses to securely acquire and route application traffic via a zero-trust client and service. In particular, Jain teaches the following:
wherein the DNS proving is performed by a Zero Trust Network (ZTN) connector service that connects application traffic to a set of application servers in a DNAT pool (see Jain [0024] connectors may be deployed in various networks with applications users can access through the managed client layer. Private access may piggyback on the outbound connection. For example, a flow may be established in the outbound connection for each application the user is authorized to and does access. A flow may encapsulate traffic in a tunnel. A connection may have multiple flows. Each flow may limit access to a respective resource (e.g., controlled access similar to a key limiting access to a specific room rather than a key to all rooms in an entire floor or building). Connectors may forward incoming traffic to intended applications).
Therefore, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed to modify the prior art with the teaching of Jain in order to incorporate a zero-trust DNS resolution system that uses synthetic IP addresses to securely acquire and route application traffic. One would been motivated because integrating Jain’s zero-trust DNS resolution and secure connectors with polling for endpoint health into DNAT load balancing, predictably enhancing security and access control for private application.
Regarding claim 10, Joshi-Kim-Jain discloses the system of claim 1, wherein the periodic application server probing is performed by a Zero Trust Network (ZTN) connector service that connects application traffic to a set of application servers in a DNAT pool (see Jain [0082] polling secure connection connectors implemented at a plurality of internet connected entities hosting internet connected endpoints for an IP address corresponding to the private internet connected endpoint. Rationale to combine is same as claim 9).
Regarding claim 11, Joshi-Kim-Jain discloses the system of claim 10, wherein a predefined time interval for the periodic application server probing is between one minute and five minutes (see Joshi [0054]; the interval between periodic health check messages is user-configurable, and can range between 2-120 seconds, for example. A default interval can be 5 seconds, for example).
Regarding claim 12, Joshi-Kim-Jain discloses the system of claim 11, wherein the ZTN connector service more frequently performs the application server probing with respect to a particular application server in response to a determination that the particular application server is not healthy (see Joshi [0054]; asynchronous updates are also sent at the block 210 whenever there is a change in VIP or port configuration at the site switch 18A).
Regarding claim 13, Joshi-Kim-Jain discloses the system of claim 1, wherein a set of DNAT rules are programmed in a connector path in a manner that each new session is automatically load balanced across healthy application servers from among the plurality of applications servers identified from a most recent DNS re-resolution (see Kim [0039] each time a DCN is removed (e.g., fails or is shut off) from the group, and its DIP should no longer be used, the load balancer of some embodiments creates a new DNAT table to store the available DIPs for the new flows that it receives).
Regarding claim 14, Joshi-Kim-Jain discloses the system of claim 1, wherein a DNS server provides a response to a query for the DNS re-resolution, and the response indicates the plurality of IP address for the plurality of applications across which application traffic is to be load balanced (see Joshi [0014] hen a client program requests a resolution of a host name, the GSLB switch, acting as a proxy of an authoritative DNS, returns one or more ordered IP addresses for the host name).
Regarding claim 15, Joshi-Kim-Jain discloses the system of claim 14, wherein in response to determining that the response does not indicate a particular load balancing to be implemented for application traffic to the plurality of application servers, a set of rules for the DNAT is configured to load balance equally across the plurality of application servers (see Kim [0039] A pseudo-random distribution of DIPs in a DNAT table in some embodiments entails distributing the DIPs that are available at the time of the creation of the DNAT table across the table's addressable locations).
Regarding claim 16, Joshi-Kim-Jain discloses the system of claim 14, wherein in response to determining that the response from the DNS server comprises an indication of application server weightings for distributing application traffic across the plurality of application servers, configuring a set of DNAT rules to load balance application traffic across the plurality of application servers in accordance with the application server weightings (see Joshi [0020] GSLB switch 12 determines which site switch would provide the best expected performance (e.g., response time) for client program 28 and returns the IP address list with a virtual IP address configured at that site switch placed at the top. (Within the scope of the present invention, other forms of ranking or weighting the IP addresses in the list can also be possible)).
Regarding claim 17, Joshi-Kim-Jain discloses the system of claim 1, wherein in response to a determination that an application server identified in a current DNAT pool is not available to handle at least a subset of the application traffic, the at least the subset of the application traffic is redistributed to other healthy application servers of the plurality of application servers (see Kim [0039] each DNAT table is a resilient table that upon removal of one of the DIPs that is identified by its records, directs packet flows that map to the removed DIP to one of the live DIPs that is identified by another one of its records).
Regarding claim 18, Joshi-Kim-Jain discloses the system of claim 1, wherein performing periodic application server probing comprises, for each of the plurality of application servers to a DNS server indicates application traffic is to be distributed across, individually configuring an application server probing timer for the particular application server (see Joshi [0055] the remote metric agent(s) 407 is responsible for periodically generating and sending health check information for all the VIPs configured at their respective site switch).
Regarding claim(s) 19 and 20, do(es) not teach or further define over the limitation in claim(s) 1 respectively. Therefore claim(s) 19 and 20 is/are rejected for the same rationale of rejection as set forth in claim(s) 1 respectively.
Regarding claim 21, Joshi-Kim-Jain discloses the system of claim 1, wherein the ZTN connector service dynamically updates the DNAT based on a most recent DNS re-resolution and application server probing to mimic DNS load balancing across healthy application servers identified from the most recent DNS re-resolution (Kim [0039] “the load balancer of some embodiments creates a new DNAT table to store the available DIPs for the new flows that it receives. Other embodiments do not create a new DNAT table when a DCN is removed from the group of DCNs. For instance, in some embodiments, each DNAT table is a resilient table that upon removal of one of the DIPs that is identified by its records, directs packet flows that map to the removed DIP to one of the live DIPs that is identified by another one of its records”).
Regarding claim 23, Joshi-Kim-Jain discloses the system of claim 1, wherein the DNS re-resolution is performed by the ZTN connector service based on a time to live (TTL) indication associated with a previous response to the DNS re-resolution (Joshi [0019] “The client program 28 receives from DNS server 30 a list of IP addresses corresponding to the resolved host name. This list of IP addresses is either retrieved from local DNS server's 30 cache, if the TTL of the responsive IP addresses in the cache has not expired, or obtained from GSLB switch 12, as a result of a recursive query”), and wherein the DNAT is updated to reflect changes in the plurality of IP addresses obtained from the DNS re-resolution (Kim [0039] “Each time a DCN is added (e.g., instantiated or allocated) to the group, and its DIP should be used, the load balancer of some embodiments creates a new DNAT table to store all the available DIPs for the new flows that it receives. Also, in some embodiments, each time a DCN is removed (e.g., fails or is shut off) from the group, and its DIP should no longer be used, the load balancer of some embodiments creates a new DNAT table to store the available DIPs for the new flows that it receives”).
Regarding claim 24, Joshi-Kim-Jain discloses the system of claim 1, wherein performing periodic application server probing comprises, for each of the plurality of application servers identified by the DNS server in response to the DNS re-resolution (Joshi [0022] “The health check module 402, in a distributed health check embodiment, is responsible for querying host servers and relevant applications hosted on the host servers being load balanced by the site switch 18A to determine the "health" of each host server and each relevant application”), individually configuring an independent application server probing timer for the particular application server (Joshi [0030] “In one embodiment of the centralized health check, the frequency of updating the health check information may be once every 5 seconds”).
Claim(s) 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Joshi et al. (US 2010/0121932) in view of Kim et al. (US 2018/0337860) in view of Jain et al. (US 2024/0250929) in view of Kwok et al. (US 2017/0063787).
Regarding claim 8, Joshi-Kim discloses the invention substantially, however the prior art does not explicitly disclose the system of claim 1, wherein the plurality of application servers are accessible by a client device via a security service gateway that is configured to authenticate the client device and mediate the application traffic.
Kwok in the field of the same endeavor discloses techniques for performing source network address translation (SNAT) and enforces policies on remote-device data message based on attributes from a remote device management (RDM) system to enhance security and routing efficiency. In particular, Kwok teaches the following:
wherein the plurality of application servers are accessible by a client device via a security service gateway that is configured to authenticate the client device and mediate the application traffic (see Kwok [0009] a VPN tunnel gateway is an example of a network element that can receive RDM-based policies or rules from the network controller set. Such a gateway establishes tunnels with remote devices that connect to the network through a VPN connection. In other words, a VPN gateway restricts a remote device's access to the resources (e.g., servers, etc.) of a network by requiring the remote device (1) to establish, through the gateway, a VPN tunnel connection with the network, (2) to encrypt packet payloads that the remote device sends through the VPN tunnel, and (3) to decrypt packet payloads that the remote device receives through the VPN tunnel. In some embodiments, the VPN gateway (1) encapsulates packets sent from the internal network to the remote device with a tunnel header, and (2) decapsulates tunnel headers from the packets that it receives from the remote device before forwarding the packets to network elements in the internal network).
Therefore, it would have been obvious of one of ordinary skill in the art at the time the invention was effectively filed to modify the prior art with the teaching of Kwok to incorporate techniques for performing source network address translation (SNAT) and enforces policies on remote-device data message. One would have been motivated because Kwok teachings would enhance authentication and traffic mediation in load-balanced environment, predictably improving security for private application access.
Allowable Subject Matter
Claim 22 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
THIS ACTION IS MADE FINAL. 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.
For the reason above, claims 1-21 and 23-24 have been rejected and remain pending.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JIMMY H TRAN whose telephone number is (571)270-5638. The examiner can normally be reached Monday-Friday 9am-5pm PST.
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, Chris Parry can be reached at 571-272-8328. 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.
JIMMY H TRAN
Primary Examiner
Art Unit 2451
/JIMMY H TRAN/Primary Examiner, Art Unit 2451
Prosecution Insights