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 .
Response to Amendment
This Action is in response to communications filed on 07/28/2026.
Claims 1 and 4 are amended. Claims 2-3 and 5-6 are cancelled. Claims 9-10 are new.
Claims 1, 4 and 7-10 are presented for examination.
Claims 1, 4 and 7-10 remain pending in this application.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 09/08/2026 was filed after the mailing date of the non-final office action on 06/02/2026. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Response to Arguments Regarding Claim Objections
In the non-final office Action mailed on 06/02/2026, claims 4-6 were objected to due to minor informalities. In the response filed on 07/28/2026, applicant amended claim 4 to include limitations from claim 5-6 (now canceled) and to obviate the objections. These amendments are acceptable, and as a result, the respective claim objections made in the non-final Office Action have been withdrawn.
Response to Arguments Regarding Claim Rejections - 35 USC § 103
Applicant’s arguments with respect to new limitation “wherein (ii) the different, unique payloads avoid any hop employing a duplicate-packet-dropping protocol from dropping any of the TCP data packets in the set” in the independent claim(s) 1 and 4 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
The Applicant's remaining amendment/ arguments, see page 4-5 of REMARKS, filed 07/28/2026, with respect to Claim Rejections - 35 USC § 103 have been fully considered but they are not persuasive. In the response filed on 07/28/2026, applicant puts forth in substance that:
“Chhabra does not teach or even suggest such a combination of features as recited in currently amended claim 1.
In rejecting previously pending claim 1, the Examiner argued on page 4 that Chhabra teaches a client creating a series of packets with different payloads, citing paragraphs [0102], [0104], and [0124].
In paragraphs [0102] and [0104], Chhabra teaches a client (i.e., a source node) including a signature (i.e., Signature-A) in the payload of the trace packets in order to detect a transparent proxy with an overlay tunnel to it from the client. According to paragraph [0104], the signature can be encrypted using a shared key that can be "rotated constantly." Presumably, the proxy uses the shared key to decrypt the encrypted signature to determine that "the signature matches," in which case the proxy determines that the trace packet is a probe from a trusted source.
Significantly, Chhabra does not explain what "rotated constantly" means. There is no indication that "rotated constantly" means that the shared key is rotated for each and every trace packet such that the payloads of all of the trace packets are uniquely different. For example, there is no teaching or even suggestion in Chhabra of a mechanism for the client and each different transparent proxy to update their shared keys. Furthermore, the term "rotate" implies a finite sequence of keys that repeat, which would not result in all of the payloads being uniquely different.
Paragraph [0124] teaches the use of a second signature (i.e., Signature-B) different from Signature-A in order to detect trace packets that follow the wrong network path.
None of these disclosures in Chhabra teach or even suggest transmitting a set of packets having uniquely different payloads in order to avoid any hop employing a duplicate-packet-dropping protocol from dropping any of the packets in the set.” (See page 4-5 of REMARKS, filed 07/28/2026).
As set forth above, examiner first reiterates that the applicant’s arguments with respect to new limitation “wherein (ii) the different, unique payloads avoid any hop employing a duplicate-packet-dropping protocol from dropping any of the TCP data packets in the set” in the independent claim(s) 1 and 4 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Applicant also argues that there is no teaching or even suggestion in Chhabra of a mechanism for the client and each different transparent proxy to update their shared keys. In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., a mechanism for the client and each different transparent proxy to update their shared keys) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Examiner however notes that Chhabra is still relevant in teaching “transmitting a set of TCP data packets having … uniquely different payloads towards the destination node along the path” as currently amended. As taught in Chhabra’s paragraph [0124], the client can be configured to insert another signature, Signature-B, in the trace packet, and notes that the use of the terms Signature-A and Signature-B is solely meant to differentiate these as different signatures. Sending trace packets with Signature-A and another signature, Signature-B reads on the claimed language “transmitting a set of TCP data packets having … uniquely different payloads towards the destination node along the path”.
Applicant highlights that the signature can be encrypted using a shared key that can be "rotated constantly" and argues that Chhabra does not explain what "rotated constantly" means. However, the concepts of encryption (encrypting signature using a shared key) and/or a shared key that can be "rotated constantly" are optional embodiments disclosed by Chhabra. So long as different signatures (Signature-A and Signature-B) are used to send traceroute probes with a signature in the payload, it meets the claimed limitation “a set of TCP data packets having … uniquely different payloads”.
“Furthermore, according to currently amended claim 1, the packets in the set are TCP data packets that are not TCP Synchronize Sequence Number (SYN) packets. In paragraphs [0136]-[0137], Chhabra teaches an approach that "avoids using TCP SYN packets, but this is to avoid cases where firewall rules would flag issues thinking of it as an attack." Significantly, this approach uses "a protocol other than TCP." See paragraph [0136].
Thus, Chhabra fails to teach or even suggest the combination of features recited in currently amended claim 1. As such, the Applicant submits that currently amended claim 1 is allowable over Chhabra.” (See page 5 of REMARKS, filed 07/28/2026).
Applicant cited paragraphs [0136]-[0137] of Chhabra and admits that this embodiment teaches an approach that “avoids using TCP SYN packets” but this approach uses "a protocol other than TCP”. Examiner concurs. However, examiner articulates that this is just one of many alternative embodiments disclosed by Chhabra. Examiner did not cite this alternative embodiment, nor does the examiner currently rely on teachings of these paragraphs as it does not use TCP. Instead, examiner contends that paragraphs [0100], [0165], [0104], [0224]-[0234] sufficiently teach using TCP data packets that are not TCP SYN packets. For e.g. paragraph [0104] teaches that the client sends traceroute probes with a signature in the payload. Similarly, [0224]-[0234] teaches allowing the ability to map out the journey of data packets as they traverse from one device connected to a network to another. Solutions include utilizing an IPV6 sub-option within a destination option header or a random bytes portion in the TLS Client Hello message for encoding trace information; By encoding the trace information (H, P) into either the IPV6 destination option header or the random bytes portion of the TLS Client Hello, the systems can still keep track of which router is responding with a TTL Time Expired message by extracting the trace information from the response. This is clearly not using TCP SYN packets.
“According to new claims 9 and 10, the uniquely different payloads of the TCP data packets in the set are not encrypted. Support for new claims 9 and 10 is found in the complete absence of any teaching or even suggestion that those payloads are encrypted.
In Chhabra, the only reason any of the payloads are different is because different shared keys are used to encrypt at least some of them. Absent that encryption, the payloads of all of Chhabra's trace packets would be identical.
The Applicant submits that this provides additional reasons for the allowability of new claims 9 and 10 over Chhabra.” (See page 5 of REMARKS, filed 07/28/2026).
In response to the applicant’s arguments, and as set forth above, Examiner notes that Chhabra is still relevant in teaching “transmitting a set of TCP data packets having … uniquely different payloads towards the destination node along the path” as currently recited in claims 1, 4 and 9-10. As taught in Chhabra’s paragraph [0124], the client can be configured to insert another signature, Signature-B, in the trace packet, and notes that the use of the terms Signature-A and Signature-B is solely meant to differentiate these as different signatures. Sending trace packets with Signature-A and another signature, Signature-B reads on the claimed language “transmitting a set of TCP data packets having … uniquely different payloads towards the destination node along the path”.
Chhabra discloses that the signature can be encrypted using a shared key that can be "rotated constantly", but applicant argues that the only reason any of the payloads are different because different shared keys are used to encrypt at least some of them. However, the examiner disagrees that the shared keys are used to encrypt payload, or that encrypting is mandatory in Chhabra. Rather, the concepts of encryption (i.e., encrypting signature using a shared key) and/or a shared key that can be "rotated constantly" are optional embodiments disclosed by Chhabra. So long as different signatures (Signature-A and Signature-B) are used to send traceroute probes with a signature in the payload, it meets the claimed limitation “a set of TCP data packets having … uniquely different payloads”. And since encryption (i.e., encrypting signature using a shared key) is optional embodiments disclosed by Chhabra, Chhabra also supports payload with signature, but without encrypting signature. Therefore, examiner disagrees that Chhabra does not teach that the uniquely different payloads of the TCP data packets in the set are not encrypted.
Applicant's arguments for independent claim 4 appear to stem from the applicant's assertion that the combination of cited references fails to disclose the similarly recited limitations of claim 1. However, as set forth above, this assertion does not hold ground, and therefore, the current rejection of record for the independent claim persists.
Applicant's arguments for the dependent claims 7-8 appear to stem from the applicant's assertion that the combination of cited references fails to disclose all the limitations of respective independent claims. However, as set forth above, this assertion does not hold ground, and therefore, the current rejections of record for the dependent claims persist.
Claim Rejections - 35 USC § 112
Claims 9-10 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Newly added dependent claims 9 and 10 recite that “the uniquely different payloads of the TCP data packets in the set are not encrypted”. In the REMARKS filed on 07/28/2026, applicant adds that “support for new claims 9 and 10 is found in the complete absence of any teaching or even suggestion that those payloads are encrypted” (see page 5 of REMARKS, filed 07/28/2026).
The applicant tended to define the invention in terms of what it was not, rather than pointing out the invention. This is an attempt to claim the invention by excluding what the inventors did not invent rather than distinctly and particularly pointing out what they did invent. In re Schechter, 205 F.2d 185, 98 USPQ 144 (CCPA 1953). This creates a problem when an applicant tries to narrow down the scope of the invention by simply adding what it was not based on what is/are found in the cited prior arts because there may be infinite variations by which an inventive concept(s) could have been modified that are taught by prior arts, but were not envisaged or adopted by the applicant.
This is improper, because MPEP 2173.05(i) clearly says that any negative limitation or exclusionary proviso must have basis in the original disclosure. If alternative elements are positively recited in the specification, they may be explicitly excluded in the claims. See In re Johnson, 558 F.2d 1008, 1019, 194 USPQ 187, 196 (CCPA 1977). The mere absence of a positive recitation is not basis for an exclusion. As per MPEP 2173.05(i), any claim containing a negative limitation which does not have basis in the original disclosure should be rejected under 35 U.S.C. 112(a) or pre-AIA 35 U.S.C. 112, first paragraph, as failing to comply with the written description requirement. See MPEP §2163 - §2163.07(b) for a discussion of the written description requirement of 35 U.S.C. 112(a).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1, 4, and 7-10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chhabra (US 20240291744 A1) in view of Liu et al. (hereinafter, Liu, US 20080244739 A1).
Regarding claim 1, Chhabra discloses a method for determining a traceroute of a path from a source node (see Fig.11-12:300) via a set of one or more hops (see Fig.11-12:602A-C) to a destination node (see Fig.11-12:640) in a communication network (see [0099]; traceroute the destination to show the latency, packet loss, and hop information between an initiator and destination; also see [0224]-[0225]; performing a trace is an essential diagnostic capability in the realm of networking allowing the ability to map out the journey of data packets as they traverse from one device connected to a network to another) that supports Transport Control Protocol (TCP) (see [0097]-[0100]; Traceroute can be based on ICMP, TCP, UDP, etc.; also see [0165]; sending a plurality of TCP packets via a raw socket to perform a trace to a destination), the method comprising the source node:
transmitting a set of TCP data packets (see Abstract; sending a plurality of trace packets between a client and a destination in a service path; also see [0100]; For TCP, one raw socket is created to send TCP probes; also see [0165]; sending a plurality of TCP packets via a raw socket to perform a trace to a destination) having different time-to-live (TTL) values (see [0099]; Traceroute includes a series of packets that are exchanged from a probe initiator along a path. Each trace packet includes an increasing TTL value; also see [0159]; for a description of a TCP traceroute from the client (user device 300) to the destination (node 150), the client creates a series of packets with increasing TTL values) and uniquely different payloads towards the destination node along the path (see [0102]; The process includes the client sending a trace packet for the destination (e.g., the node 150 with an address of a.b.c.d) with a Signature-A; also see [0104]; the client sends traceroute probes with a signature... signature in the payload, which can be encrypted using a shared key that can be rotated constantly; also see [0124]; the client can be configured to insert another signature, Signature-B, in the trace packet... for a response; the terms Signature-A and Signature-B is solely meant to differentiate these as different signatures; also see [0225]; the origin device sends out a series of packets with progressively increasing TTL values), wherein (i) the TCP data packets are not TCP Synchronize Sequence Number (SYN) packets (see [0100]; For TCP, one raw socket is created to send TCP probes; also see [0165]; sending a plurality of TCP packets via a raw socket to perform a trace to a destination; also see [0104]; the client sends traceroute probes with a signature... signature in the payload, which can be encrypted using a shared key that can be rotated constantly; also see [0224]-[0234]; allowing the ability to map out the journey of data packets as they traverse from one device connected to a network to another; solutions include utilizing an IPV6 sub-option within a destination option header or a random bytes portion in the TLS Client Hello message for encoding trace information; By encoding the trace information (H, P) into either the IPV6 destination option header or the random bytes portion of the TLS Client Hello, the systems can still keep track of which router is responding with a TTL Time Expired message by extracting the trace information from the response);
receiving, from each hop in the path, an Internet Control Message Protocol (ICMP) timeout packet (see [0099]; When a node along the path receives a trace packet where the TTL expires, it sends a response; also see [0143]; probe or probe traffic means traceroute packets. As the packet makes its way through the tunnel the packet's TTL would expire triggering an ICMP “Time Exceeded” error. This error is propagated by the tunnel to the probe initiator such as the client; also see [0225]; The moment the TTL value is reduced to zero, indicating that the packet has traversed the maximum number of hops it was allowed, the router currently holding the packet discards it, effectively preventing it from proceeding any further. By doing so, the router generates an ICMP Time Exceeded message. This message is then sent back to the original source device that transmitted the packet) identifying the hop (see [0099]; Based on all of the responses, it is possible for the probe initiator (e.g., the client) to determine the network hops, the latency at each hop, packet loss, and other details. Again, the traceroute can be an MTR, which also includes PING functionality. Again, MTR is used to traceroute the destination to show the latency, packet loss, and hop information between an initiator and destination; also see [0143]; As the packet makes its way through the tunnel the packet's TTL would expire triggering an ICMP “Time Exceeded” error. This error is propagated by the tunnel to the probe initiator (such as the client) spoofing the IP address of the router that generated the error) and a corresponding TCP data packet (see [0231]; when a router responds with an ICMPV6 TTL Expired message, it includes the original packet. Thus, the present systems can extract the hop, packet, and protocol from the TCP destination option header and use it to identify the responding route);
receiving, from the destination node, at least one TCP acknowledgment (ACK) packet identifying the destination node (see [0100]; For TCP, one raw socket is created to send TCP probes, and one ICMP socket is created to receive ICMP error messages, and the TCP socket is also used to receive SYN-ACK/RST from the destination... ACK=Acknowledgment; also see [0166] in view of Fig.22:712; the responses include TCP SYN-Acknowledgement (ACK) or Reset (RST) messages) and a corresponding TCP data packet (see [0147]; analyzing a Time-to-Live (TTL) value in the packet, and sending a response to a probe initiator based on the TTL value; also see [0234]; the systems can still keep track of which router is responding with a TTL Time Expired message by extracting the trace information from the response; also see [0159]-[0160]; the present disclosure includes determining the reachability of the destination by peeking into the response packets for a SYN-ACK or an RST sent by the destination; as set forth in [0165]-[0166], the responses include TCP SYN-ACK; examiner articulates that identifying a corresponding TCP data packet by the source node based on received ACK packet is obvious as the systems can keep track of TTL value, and also track/ extract the trace information from the responses. Furthermore, Chhabra at [0231] already discloses receiving a response message that includes the original packet; Therefore given the teachings in Chhabra that the responses include TCP SYN-Acknowledgement (ACK), and that the received response message includes the original packet, examiner articulates that using combination of these teachings, it would be obvious to one of ordinary skill in the art to use the response ACK packet and identify a corresponding TCP data packet to arrive at claimed invention); and
determining the traceroute from each ICMP timeout packet (see [0231]; when a router responds with an ICMPV6 TTL Expired message, it includes the original packet. Thus, the present systems can extract the hop, packet, and protocol from the TCP destination option header and use it to identify the responding route) and the at least one TCP ACK packet (see [0165]-[0166]; The process includes sending a plurality of TCP packets via a raw socket to perform a trace to a destination; receiving responses to the plurality of TCP packets – the responses include TCP SYN-Acknowledgement (ACK); detecting the responses in the TCP stack and diverting the responses to the raw socket; and aggregating the responses by the traceroute application to determine details of a service path from the processing device to the destination; also see [0224]-[0225]; methods for performing traces meticulously record each hop that a packet makes on its journey, providing valuable insights into the routers or intermediate devices it encounters along the way).
Although, and as set forth above, Chhabra discloses that communication network supports TCP, wherein (i) the TCP data packets are not TCP Synchronize Sequence Number (SYN) packets (see [0137] and [0165]) Chhabra does not explicitly disclose wherein (ii) the different, unique payloads avoid any hop employing a duplicate-packet-dropping protocol from dropping any of the TCP data packets in the set.
However, in an analogous art, Liu discloses wherein (ii) the different, unique payloads avoid any hop employing a duplicate-packet-dropping protocol from dropping any of the data packets in the set (see [0069]-[0070] in view of Fig.3 that shows a chain of 7 forwarding nodes (41-47) between a source mole S 32 and the sink 38; A source mole S 32 injects bogus reports that conform to a legitimate format. Each report (message or packet) M includes an event E, location L and timestamp T (i.e., M=E/L/T, where "/", denotes concatenation). Reports cannot all include exactly the same content, otherwise they are considered redundant and be dropped by legitimate forwarding nodes; also see [0083]-[0087]; node Vi uses an anonymous ID i' in the packet; The anonymous ID i' is bound to M such that it changes for each distinct message that Vi forwards).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Liu with Chhabra so that the different, unique payloads avoid any hop employing a duplicate-packet-dropping protocol from dropping any of the TCP data packets in the set.
One of ordinary skill in the art would have been motivated to avoid (message or packet) being considered as redundant copies and dropped (Liu: [0070] and [0087]).
As for Claim 4, the claims list all the same elements of claim 1, but in an apparatus (in Chhabra, see [0038]; the present disclosure relates to systems and methods for optimized tracing in IPV6 environments; also see claim 15 directed to an apparatus) comprising a source node (see Chhabra: Fig.11-12:300) comprising: a memory (see Fig.3:210 and/or Fig.4:310); and at least one processor (see Fig.3:202 and/or Fig.4:302) form to carry out the steps of claim 1, rather than the method form. Therefore, the supporting rationale of the rejection to claim 1 applies equally as well to claim 4.
Regarding claim 7, Chhabra (modified by Liu) discloses the apparatus of claim 4, as set forth above. In addition, Chhabra further discloses the apparatus further comprising the one or more hops (see Fig.11-12:602A-C; also see [0097]-[0098]; The traceroute includes transmitting a request packet from the user 102 to destination 640 (with an address of a.b.c.d) via the access point 600, the routers 602, and the switch 604; also see [0224]-[0225]; methods for performing traces meticulously record each hop that a packet makes on its journey, providing valuable insights into the routers or intermediate devices it encounters along the way).
Regarding claim 8, Chhabra (modified by Liu) discloses the apparatus of claim 7, as set forth above. In addition, Chhabra further discloses the apparatus further comprising the destination node (see Fig.11-12:640 in view of [0097]-[0098]; The traceroute includes transmitting a request packet from the user 102 to the destination 640 (with an address of a.b.c.d) via the access point 600, the routers 602, and the switch 604).
Regarding claim 9, Chhabra (modified by Liu) discloses the apparatus of claim 4, as set forth above. In addition, Chhabra further discloses wherein the uniquely different payloads of the TCP data packets in the set are not encrypted (see [0102]; The process includes the client sending a trace packet for the destination (e.g., the node 150 with an address of a.b.c.d) with a Signature-A; The Signature-A can be any encrypted data for security; also see [0104]; the client sends traceroute probes with a signature... signature in the payload, which can be encrypted using a shared key that can be rotated constantly; also see [0124]; the client can be configured to insert another signature, Signature-B, in the trace packet; the terms Signature-A and Signature-B is solely meant to differentiate these as different signatures; examiner articulates that “signature can be encrypted” indicates an option to encrypt signature in the payload, and that such optional embodiment to encrypt signature does not necessarily mean the payload is encrypted).
As for Claim 10, the claim depends on claim 1, but does not teach or further define over the limitations in claim 9. Therefore, claim 10 is rejected for the same reasons as set forth in claim 9.
Additional References
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Nataraj et al. (US 20200204448 A1) identifies network segments affecting application performance using ACK packets to trace the layer-3 path in reverse from the receiving server toward the load balancer, with TTL values from 1 to ‘n’ until reaching the load balancer.
Booth et al. (US 20030153328 A1) discloses traceroute forces routers to progressively report their addresses by manipulating the time-to-live field within the TCP/IP packet.
Nemirovsky et al. (US 20170366445 A1) teaches modified traceroute technique that simulates actual traffic flows without using well known or random ports for the probes, where Packets are forged to have a 5-tuple equal to the one of the connection flow packets plus a random payload which is fingerprinted to match the routers replies with specific probes.
HURLEY et al. (WO 2010051020 A1) teaches upon expiry of the TTL, the remote router reports a failure to the sender through Internet Control Message Protocol (ICMP) "time exceeded" or "destination unreachable" control packets.
GILSON et al. (EP 3136651 A1) teaches utilizing a trace-route to determine a plurality of potential network communication paths for one or more data packets to traverse when traveling across the network from a source network to an end point.
Kaminsky et al. (US 20080212484 A1) teaches other packets or protocols such as TCP keep-alive packets may be used instead of SYN and SYN/ACK packets to trace a connection path in a communication network.
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 SANDARVA KHANAL whose telephone number is (571)272-8107. The examiner can normally be reached MON-FRI, 0800-1700.
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, Kamal B Divecha can be reached at 571-272-5863. 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.
/SANDARVA KHANAL/Primary Examiner, Art Unit 2453
Prosecution Insights