DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 06/12/2026 has been placed in record and considered by the examiner.
Status of the Claims
This office action considers claims 1-17 filed on 07/22/2026 are pending for prosecution.
Response to Arguments
Applicant’s arguments, with respect to claims 1-17, filed on 07/22/2026 have been fully considered but they are not persuasive.
The Applicant presented argument regarding claim 1 that Wang merely relates to forwarding TSN packet flows by the forwarding device .....and merely implements end-to-end packet transmission in the same deterministic network using the same scheduling mechanism. Wang is totally silent about transmitting packets with spanning two or more different deterministic networks using different scheduling mechanisms between the source terminal and the destination terminal. (REMARKS, Pages 8 of 11 – 9 of 11)
The Examiner respectfully disagrees. The Examiner presents that "A claim is anticipated only if each and every element as set forth in the claim is found, either expressly or inherently described, in a single prior art reference." The elements must be arranged as required by the claim, but this is not an ipsissimis verbis test, i.e., identity of terminology is not required. In re Bond, 910 F.2d 831, 15 USPQ2d 1566 (Fed. Cir. 1990). Note that, in some circumstances, it is permissible to use multiple references in a 35 U.S.C. 102 rejection. See MPEP § 2131.
In this case, Wang discloses –
Fig. 10, [0103] The following uses a specific example to describe a packet forwarding method in this embodiment of this application. FIG. 10 is a schematic diagram of a scenario of applying a packet forwarding method according to an embodiment of this application. FIG. 10 shows a scenario in which TSN packet flows are converged. A packet flow A1 and a packet flow B1 to a packet flow B4 are the TSN packet flows, that is, information sources of key data. A packet flow BG is with a low priority. All packet flows are converged on a forwarding device A, and an output port bandwidth of the forwarding device A is 100 megabits per second (Mbps). The packet flow A1 is a high-rate packet flow, and a bandwidth of 50 Mbps is required, and the packet flow B1 to the packet flow B4 each require a bandwidth of 10 Mbps.
From the above it is construed that the networks in upstream generating packet flows A1, B1-B4 belongs input or first network having slower speeds of 10/50 Mbps and downstream network to which the outport port in interfaces is a different or second network having higher speed of 100 Mbps, similar to user side local area network - LAN and backbone side or wide area network - WAN as well known in the art, e.g. BORDER (US 20020010792 A1 Fig. 1) or instant application’s Fig. 4.
Therefore WANG teaches the first network at the input of the packet forwarding device or gateway and the second network at the output of the packet forwarding device or gateway are different deterministic TSN networks having different speeds.
Further Wang discloses
Fig. 1, [0072] FIG. 1 is a schematic diagram of a packet forwarding method according to an embodiment of this application. A forwarding device has M input ports. ….. the TSN packet flows received on the port #1, the port #2, and the port #3 are a packet flow #1, a packet flow #2, and a packet flow #3, respectively. Each TSN packet flow (the packet flow #1, the packet flow #2, and the packet flow #3) corresponds to a constraint condition. For example, duration of a single cycle of the packet flow #1 is T1 …... Duration of a single cycle of the packet flow #2 is T2 …... Duration of a single cycle of the packet flow #3 is T3 …..
[0074] The forwarding device has at least one output port, which is configured to forward a received packet flow. For example, the output port may be a port #5 in FIG. 1. The forwarding device may forward the N TSN packet flows as one new packet flow based on a new constraint condition. …..
[0082] In a specific example, duration of a single cycle of an output port (duration of a long cycle) may be an LCM of the duration of a single cycle of the N TSN packet flows, that is, Tout=LCM (T1, T2, . . . , TN). That is, the duration of a single cycle in the new constraint condition is the LCM of the duration of a single cycle in constraint conditions corresponding to N TSN packet flows.
See also Fig. 10, input flows A1 and B1-B4 requires 50 Mbps and 10 Mbps bandwidth which can be mapped to T1 and T2 respectively, and output of 100 Mbps which can be mapped to Tout, and time slice scheduling of input flows A1 and B1-B4 of output port as described in [0106] and TABLE 1, illustrated by Fig. 11.
For the above, it is construed that the first network at the input and the second network at the output of the of the packet forwarding device or gateway use different scheduling mechanisms due to different constraints.
Accordingly amended claim 1, and similarly claims 6 and 11 with substantially similar features, are rejected.
Dependent claims 2-5, 7-10 and 12-17, being dependent on claims 1, 6 and 11, are also rejected for the same reason as above.
NOTICE for all US Patent Applications filed on or after March 16, 2013
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.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of AIA 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless -
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1, 4, 6, 9, 11, 14 and 16-17 are rejected under 35 U.S.C. 102 (a)(1) as being anticipated by Wang et al. (US 20220131809 A1, of IDS, hereinafter ‘WANG’) with evidence by Border et al. (US 20020010792 A1, hereinafter ‘BORDER’).
Regarding claim 1, WANG teaches a method for packet transmission (Fig. 1,
[0072] FIG. 1 is a schematic diagram of a packet forwarding method), wherein the method is applied to a gateway (Fig. 1 Forwarding Device,
Fig. 9, [0098] As shown in FIG. 9, the forwarding device has m cache queues: Q1, Q2, . . . , Qm−1, and Qm. Each cache queue has a gating control switch that controls packet output……
See also Fig. 15 Forwarding Device 100,
[0120] FIG. 15 is a schematic block diagram of a forwarding device 100 according to an embodiment of this application. The forwarding device 100 may be configured to perform the method described in the embodiment corresponding to FIG. 1. As shown in FIG. 15, the forwarding device 100 may include a processor 110 and a memory 120. The processor 110 may be connected to the memory 120 using a bus 130. The memory 120 is configured to store an instruction. When the processor 110 executes the instruction stored in the memory 120, the processor 110 is enabled to perform
(Construed that the forwarding device with gating control switches is also a Gateway)) and comprises:
receiving a first packet from an upstream network device in a first network (
Fig. 1, [0072] A forwarding device has M input ports. For example, FIG. 1 shows four input ports: a port #1, a port #2, a port #3, and a port #4. N input ports in the M input ports are configured to receive N TSN packet flows.
See also Fig. 10 illustrating packets received by forwarding device A are being forwarded to forwarding device B which in turn forwarding the packets to forwarding device C
Fig. 11 illustrating packets received by forwarding device A are being forwarded,
Fig. 14 illustrating packets received by forwarding device B are being forwarded,
[0113] It should be understood that input and output of a forwarding device B and a forwarding device C in this embodiment may be similar to those of the forwarding device A. FIG. 14 is a schematic diagram of forwarding a packet flow by a forwarding device B according to an embodiment of this application. In the example in FIG. 13, a plurality of packet flows is converged into one new packet flow on an output port of the forwarding device A, and the new packet flow is used as input of a port #1 of the forwarding device B in FIG. 14. The new packet flow is referred to as a packet flow M.
(Construed that a first packet from an upstream network device in a first network on the left hand side of the forwarding device is implicit));
caching the first packet into a scheduling queue of a deterministic flow to which the first packet belongs (
Fig. 1, [0072] Each TSN packet flow (the packet flow #1, the packet flow #2, and the packet flow #3) corresponds to a constraint condition. For example, duration of a single cycle of the packet flow #1 is T1, and a constraint condition of the packet flow #1 further includes a maximum length of a single packet and a maximum quantity of packets that are allowed to be transmitted in a single cycle. Duration of a single cycle of the packet flow #2 is T2, and a constraint condition of the packet flow #2 further includes a maximum length of a single packet and a maximum quantity of packets that are allowed to be transmitted in a single cycle. Duration of a single cycle of the packet flow #3 is T3, and a constraint condition of the packet flow #3 further includes a maximum length of a single packet and a maximum quantity of packets that are allowed to be transmitted in a single cycle.
[0093] After the TSN packet flow enters the forwarding device from an input port, the forwarding device caches the packet, and then outputs the packet from an output port based on the new constraint condition. Further, the forwarding device may store the packet flow in at least one cache queue after identifying the packet flow based on a constraint condition corresponding to the received packet flow and/or a flow ID of the packet flow. There is a plurality of cache queue allocation manners. For example, the cache queue may be allocated based on the flow ID of the packet flow, the cache queue may be allocated based on a cycle (for example, a cycle ID) of the output port, or the cache queue may be allocated based on a combination of the flow ID and the cycle ID.
[0095] After entering a forwarding device, a packet flow may enter at least one cache queue based on the different allocation manners described above. In a caching solution, the forwarding device respectively stores N TSN packet flows in N cache queues, and the N TSN packet flows are in a one-to-one correspondence with the N cache queues.);
sending the packet in the scheduling queue to a downstream network device in a second network according to a scheduling cycle of the scheduling queue (
Fig. 9, [0098] A forwarding device performs scheduling at an output port based on a new constraint condition, and extracts a packet from each cache queue for output. FIG. 9 is a schematic diagram of scheduling a packet from a cache queue according to an embodiment of this application. As shown in FIG. 9, the forwarding device has m cache queues: Q1, Q2, . . . , Qm−1, and Qm. Each cache queue has a gating control switch that controls packet output, and the gating control switches are G1, G2, . . . , Gm−1, and Gm, respectively. The forwarding device turns on or turns off a corresponding gating control switch at a corresponding moment based on a preconfigured gating control list. To be specific, the forwarding device controls output of packets in N cache queues by controlling the gating control switch based on a gating control list corresponding to the new constraint condition.),
wherein the first network and the second network are different deterministic networks (
Fig. 10, [0103] The following uses a specific example to describe a packet forwarding method in this embodiment of this application. FIG. 10 is a schematic diagram of a scenario of applying a packet forwarding method according to an embodiment of this application. FIG. 10 shows a scenario in which TSN packet flows are converged. A packet flow A1 and a packet flow B1 to a packet flow B4 are the TSN packet flows, that is, information sources of key data. A packet flow BG is with a low priority. All packet flows are converged on a forwarding device A, and an output port bandwidth of the forwarding device A is 100 megabits per second (Mbps). The packet flow A1 is a high-rate packet flow, and a bandwidth of 50 Mbps is required, and the packet flow B1 to the packet flow B4 each require a bandwidth of 10 Mbps.
(Construed that the networks in upstream generating packet flows A1, B1-B4 belongs input or first network having slower speeds of 10/50 Mbps and downstream network to which the outport port in interfaces is a different or second network having higher speed of 100 Mbps, similar to user side local area network - LAN and backbone side or wide area network - WAN as well known in the art, as evident from BORDER Fig. 1 or instant application’s Fig. 4.)), and the first network and the second network use different scheduling mechanisms (
Fig. 1, [0072] FIG. 1 is a schematic diagram of a packet forwarding method according to an embodiment of this application. A forwarding device has M input ports. ….. the TSN packet flows received on the port #1, the port #2, and the port #3 are a packet flow #1, a packet flow #2, and a packet flow #3, respectively. Each TSN packet flow (the packet flow #1, the packet flow #2, and the packet flow #3) corresponds to a constraint condition. For example, duration of a single cycle of the packet flow #1 is T1 …... Duration of a single cycle of the packet flow #2 is T2 …... Duration of a single cycle of the packet flow #3 is T3 …..
[0074] The forwarding device has at least one output port, which is configured to forward a received packet flow. For example, the output port may be a port #5 in FIG. 1. The forwarding device may forward the N TSN packet flows as one new packet flow based on a new constraint condition. …..
[0082] In a specific example, duration of a single cycle of an output port (duration of a long cycle) may be an LCM of the duration of a single cycle of the N TSN packet flows, that is, Tout=LCM (T1, T2, . . . , TN). That is, the duration of a single cycle in the new constraint condition is the LCM of the duration of a single cycle in constraint conditions corresponding to N TSN packet flows.
See also Fig. 10, input flows A1 and B1-B4 requires 50 Mbps and 10 Mbps bandwidth which can be mapped to T1 and T2 respectively, and output of 100 Mbps which can be mapped to Tout, and time slice scheduling of input flows A1 and B1-B4 of output port as described in [0106] and TABLE 1 as illustrated by Fig. 11.
(Construed that the first network at the input and the second network at the output of the of the packet forwarding device or gateway use different scheduling mechanisms due to different constraints.)).
Regarding claim 4, WANG, with evidence by BORDER, teaches the method according to claim 1, wherein receiving the first packet from the upstream network device in the first network comprises:
receive the first packet from the upstream network device in the first network through a plurality of entrances (
Fig. 1, [0072] FIG. 1 is a schematic diagram of a packet forwarding method according to an embodiment of this application. A forwarding device has M input ports. For example, FIG. 1 shows four input ports: a port #1, a port #2, a port #3, and a port #4. N input ports in the M input ports are configured to receive N TSN packet flows.
[0075] … the forwarding device may add an ID of the new packet flow to the new packet flow that is obtained by converging the N TSN packet flows. That is, each packet in the new packet flow may carry the ID of the new packet flow. In this way, when the forwarding device forwards the new packet flow to a next-hop device, the next-hop device may process a received packet based on the ID of the new packet flow carried in the received packet. To be specific, the next-hop device may consider a packet in the packet flow #1, a packet in the packet flow #2, and a packet in the packet flow #3 as packets in a same packet flow based on the ID of the new packet flow carried in the packet.)
(Construed that first packets from upstream network entering through a plurality of entrances at the first forwarding device belong to same flow ID are output through same port)).
Regarding claim 6, the claim is interpreted mutatis mutandis of claim 1 and rejected for the same reason as set forth for claim 1.
Regarding claim 9, the claim is interpreted and rejected for the same reason as set forth for claim 4.
Regarding claim 11, the claim is interpreted mutatis mutandis of claim 1 and rejected for the same reason as set forth for claim 1.
Regarding claim 14, the claim is interpreted and rejected for the same reason as set forth for claim 4.
Regarding claim 16, the claim is interpreted and rejected for the same reason as set forth for claim 1.
Regarding claim 17, the claim is interpreted and rejected for the same reason as set forth for claim 1.
Claims 2-3, 5, 7-8, 10, 12-13 and 15 are rejected under 35 U.S.C. 102 (a)(1) as anticipated by Wang et al. (US 20220131809 A1, of IDS, hereinafter ‘WANG’) with evidence by Border et al. (US 20020010792 A1, hereinafter ‘BORDER’) and with further evidence by Open Networking Foundation (OpenFlow Switch Specification Version 1.3.1, of record, hereinafter ‘ONF’).
Regarding claim 2, WANG, with evidence by BORDER, teaches the method according to claim 1, wherein caching the first packet into the scheduling queue of the deterministic flow to which the first packet belongs comprises:
matching the first packet with a local flow table, caching, if there is a first flow table matching the first packet locally, the first packet into a scheduling queue corresponding to the first flow table (
[0075] … the forwarding device may add an ID of the new packet flow to the new packet flow that is obtained by converging the N TSN packet flows. That is, each packet in the new packet flow may carry the ID of the new packet flow. In this way, when the forwarding device forwards the new packet flow to a next-hop device, the next-hop device may process a received packet based on the ID of the new packet flow carried in the received packet. To be specific, the next-hop device may consider a packet in the packet flow #1, a packet in the packet flow #2, and a packet in the packet flow #3 as packets in a same packet flow based on the ID of the new packet flow carried in the packet.);
creating a second flow table based on a preset flow characteristic information if there is no flow table matching the first packet locally and the first packet matches the preset flow characteristic information, wherein the second flow table is used to instruct the gateway to cache a packet matching the preset flow characteristic information into a scheduling queue corresponding to the second flow table, caching the first packet into the scheduling queue corresponding to the second flow table (
[0075] Assuming that the new packet flow does not carry the ID of the new packet flow, the next-hop device may consider the packet in the packet flow #1 and the packet in the packet flow #2 as packets in different packet flows, and perform a related operation on the new packet flow, for example, configure a gating control list or a time slice forwarding table to forward the new packet flow. The gating control list and the time slice forwarding table are described in detail below.
[0093] the forwarding device may store the packet flow in at least one cache queue after identifying the packet flow based on a constraint condition corresponding to the received packet flow and/or a flow ID of the packet flow…
See also Fig. 19 forwarding device 1902 may be an OPENFLOW switch with a controller,
[0141] FIG. 19 is a schematic block diagram of a system 1900 according to an embodiment of this application. Referring to FIG. 19, the system 1900 includes a controller 1901 and a forwarding device 1902. For example, the controller 1901 may perform the method shown in FIG. 18, and the forwarding device 1902 may perform the method shown in FIG. 17. The controller 1901 may be a software-defined networking (SDN) controller. The forwarding device 1902 may be an OPENFLOW switch. The controller 1901 may communicate with the forwarding device 1902 using a control channel. The controller 1901 may obtain constraint conditions of N TSN packet flows from the forwarding device 1902 by executing OPENFLOW Switch Specification 1.3.1. The controller 1901 may perform S1801 based on the constraint conditions of the N TSN packet flows from the forwarding device 1902. After determining a new constraint condition by performing S1802, the controller 1901 may send the new constraint condition to the forwarding device 1902 using the control channel.
It is well known from OPENFLOW Switch Specification 1.3.1, cited in WANG, that a ingress packet is first match with existing flow entries Table in a OpenFlow Switch, if matched, the packet is forwarded by the OpenFlow switch, and if not matched a flow entry is added in the flow entry table by a controller of the OpenFlow switch according to existing policy for forwarding to discarding, as evident from ONF. See below).
ONF teaches –
Pages 14, Paragraph: 1-3:
Pipeline processing always starts at the first flow table: the packet is first matched against flow entries of flow table 0. Other flow tables may be used depending on the outcome of the match in the first table.
When processed by a flow table, the packet is matched against the flow entries of the flow table to select a flow entry (see 5.3). If a flow entry is found, the instruction set included in that flow entry is executed ….. If the matching flow entry does not direct packets to another flow table, pipeline processing stops at this table. When pipeline processing stops, the packet is processed with its associated action set and usually forwarded (see 5.10).
If a packet does not match a flow entry in a flow table, this is a table miss. The behavior on a table miss depends on the table configuration (see 5.4). A table-miss flow entry in the flow table can specify how to process unmatched packets: options include dropping them, passing them to another table or sending them to the controller over the control channel via packet-in messages (see 6.1.2).
5.2 Flow Table
A flow table consists of flow entries.
PNG
media_image1.png
200
400
media_image1.png
Greyscale
Page 15 Figure 3 Flowchart detailing packet flow through an OpenFlow switch,
PNG
media_image2.png
200
400
media_image2.png
Greyscale
5.3 Matching
On receipt of a packet, an OpenFlow Switch performs the functions shown in Figure 3. The switch starts by performing a table lookup in the first flow table, and based on pipeline processing ….
Packet match fields are extracted from the packet. Packet match fields used for table lookups depend on the packet type, and typically include various packet header fields, such as Ethernet source address or IPv4 destination address (see A.2.3) ….
A packet matches a flow table entry if the values in the packet match fields used for the lookup match those defined in the flow table entry …..
The packet is matched against the table and only the highest priority flow entry that matches the packet must be selected… The counters associated with the selected flow entry must be updated and the instruction set included in the selected flow entry must be applied ….
Section 5.4 Table-miss
Every flow table must support a table-miss flow entry to process table misses. The table-miss flow entry specifies how to process packets unmatched by other flow entries in the flow table (see 5.1), and may, for example, send packets to the controller, drop packets or direct packets to a subsequent table.
5.10 Action Set
An action set is associated with each packet.
The actions in an action set are applied in the order specified below …..
9. qos: apply all QoS actions, such as set_queue to the packet
10. group: if a group action is specified, apply the actions of the relevant group bucket(s) in the order specified by this list
11. output: if no group action is specified, forward the packet on the port specified by the output action
The output action in the action set is executed last. ….. If no output action and no group action were specified in an action set, the packet is dropped.
Regarding claim 3, WANG, with evidence by BORDER and ONF, teaches the method according to claim 2, wherein the first flow table and the second flow table have a preset aging duration (
See [0141] The controller 1901 may be a software-defined networking (SDN) controller. The forwarding device 1902 may be an OPENFLOW switch. The controller 1901 may communicate with the forwarding device 1902 using a control channel. The controller 1901 may obtain constraint conditions of N TSN packet flows from the forwarding device 1902 by executing OPENFLOW Switch Specification 1.3.1.
ONF teaches –
Page 14, Table 1,
5.2 Flow Table
A flow table consists of flow entries.
PNG
media_image1.png
200
400
media_image1.png
Greyscale
timeouts: maximum amount of time or idle time before flow is expired by the switch.).
Regarding claim 5, WANG, with evidence by BORDER and ONF, teaches the method according to claim 2, wherein the preset flow characteristic information is a packet quintuple; or, the preset flow characteristic information is a flow identification of the deterministic flow to which the packet belongs (
[0064] TSN in this application may be a standard defined by the Task Group of the Institute of Electrical and Electronics Engineers (IEEE). For example, the TSN may be IEEE 802.1ASbt or IEEE 802.1Qcc. A TSN packet flow may be a packet flow that complies with the TSN. Different TSN packet flows may have different characteristics. For example, a 5-tuple of a TSN packet flow 1 is different from a 5-tuple of a TSN packet flow 2. The 5-tuple may include a source Internet Protocol (IP) address, a destination IP address, a source port, a destination port, and a protocol.
[0093] the forwarding device may store the packet flow in at least one cache queue after identifying the packet flow based on a constraint condition corresponding to the received packet flow and/or a flow ID of the packet flow.).
Regarding claim 7, the claim is interpreted and rejected for the same reason as set forth for claim 2.
Regarding claim 8, the claim is interpreted and rejected for the same reason as set forth for claim 3.
Regarding claim 10, the claim is interpreted and rejected for the same reason as set forth for claim 5.
Regarding claim 12, the claim is interpreted and rejected for the same reason as set forth for claim 2.
Regarding claim 13, the claim is interpreted and rejected for the same reason as set forth for claim 3.
Regarding claim 15, the claim is interpreted and rejected for the same reason as set forth for claim 5.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Li et al. (US 20200382426 A1), describing METHOD AND APPARATUS FOR CONTROLLING TRAFFIC IN PACKET-BASED NETWORK
Rae et al. (US 8000269 B1), describing Call Processing With Voice Over Internet Protocol Transmission
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 SHAH M RAHMAN whose telephone number is (571)272-8951. The examiner can normally be reached 9:30AM-5:30PM 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, UN C CHO can be reached at 571-272-7919. 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.
/SHAH M RAHMAN/Primary Examiner, Art Unit 2413
Prosecution Insights