DETAILED ACTION
Response to Amendment
In response to amendment filed on 6/15/2026, claims 1- 41 were cancelled and claim 42, 44, 48, 54- 55 are amended. Claims 42- 61 are pending for examinations.
Response to Arguments
Applicant’s arguments with respect to claim(s) filed in the remarks on 6/15/2026 for claim 42 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 has amended the claim language hence examiner believes that the scope has been changed. Therefore examiner has considered new reference Wijnands et al. (US Pat. No. 8422364 B2). Wijnands teaches about the processor circuitry is to add or insert data packet information indicating one or more of: link protecting alternative path information: and/or node protecting alternative path information; see abstract .. receiving at a router, a multicast label distribution protocol message comprising local node information for a protected node and one or more leaf nodes downstream of the protected node in a primary label switched path, creating one or more backup label switched paths to the one or more leaf nodes, detecting a failure at the protected node, and forwarding at the router, traffic for the one or more leaf nodes to the one or more backup label switched paths; further see claim 2 (in context with claim 1…creating one or more backup label switched paths to said one or more leaf nodes, wherein said one or more backup label switched paths do not pass through the protected node; detecting a failure at the protected node; and forwarding at the router, traffic for said one or more leaf nodes to said one or more backup label switched paths.) about inserting local node information for the router into a multicast label distribution protocol message containing said local node information for the protected node; and transmitting said multicast label distribution protocol message to an upstream node (i.e. router adds information identifying nodes into protocol messages that govern protection behavior (i.e. backup paths)).
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 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) 42, 45- 46, 53 are rejected under 35 U.S.C. 103 as being unpatentable over Chunduri et al. “Preferred Path Routing (PPR) in IS-IS draft-chunduri-lsr-isis-preferred-path-routing-06”, published in sept 30th 2020; see IDS filed on 1/19/2024, page 2 #2; hereafter Uma in view of “SD-Fabric: open source full stack programmable leaf-spine network fabric”; Jun 2021; see IDS filed on 2/19/2024 page 2 #1; hereafter SD-fabric and further in view of Wijnands et al. (US Pat. No. 8422364 B2).
Regarding claim 42, Uma teaches a compute node, comprising: memory circuitry to store a traffic engineering (TE) policy; and processor circuitry connected to the memory circuitry, wherein the processor circuitry (see section 2 of page 4… A PPR (Preferred Path Routing) could be an SR path, a traffic engineered path computed based on some constraints, an explicitly provisioned Fast Re-Route (FRR) path or a service chained path. A PPR can be signaled by any node, computed by a central controller, or manually configured by an operator. PPR extends the source routing and path steering capabilities to native IP (IPv4 and IPv6) data planes ….) is to:
determine a first subset of links including a first number of links in a set of links to be designated as TE links between a first subset of network nodes in a set of network nodes and a second subset of network nodes in the set of network nodes according to a set of conditions (see page 4 section 2 …A PPR could be an SR (segment routing) path, a traffic engineered path computed based on some constraints, an explicitly provisioned Fast Re-Route (FRR) path (i.e. TE path) or a service chained path. A PPR can be signaled by any node, computed by a central controller, or manually configured by an operator; further refer to section 2.3 PPR inherently supports Equal Cost Multi Path (ECMP) for both strict and loose paths. If a path is described using nodes, would have ECMP NHs established for PPR-ID along the path..; now refer to section 2.4 In a network of N nodes O(N^2) total (unidirectional) paths are necessary to establish any-to-any connectivity, and multiple (k) such path sets may be desirable (i.e. first/second subset of links for TE path in a first/second subset of network nodes in a set of network nodes accordingly) if multiple path policies are to be supported (lowest latency, highest throughput etc.) (i.e. here second subset of links can be “non-TE” paths (example SR paths or links using ECMP and second subset of network nodes can be ECMP nodes (i.e. see procedure example of section 4 Fig.5 wherein PPR-ID value based paths and nodes can be “TE paths” and nodes while considering only shortest path between R4 and R1(example R2, R3, R8, R9) can be “non-TE” related paths and nodes accordingly.);
determine a second subset of links including a second number links between the first subset of network nodes and the second subset of network nodes, wherein the second subset of links are non-TE links (already discussed above see page 4 section 2 …A PPR could be an SR path (i.e. non-TE path), a traffic engineered path computed based on some constraints, an explicitly provisioned Fast Re-Route (FRR) path (i.e. TE path) or a service chained path. A PPR can be signaled by any node, computed by a central controller, or manually configured by an operator; further refer to section 2.3 PPR inherently supports Equal Cost Multi Path (ECMP) for both strict and loose paths (i.e. ECMP related paths are non-TE paths). If a path is described using nodes, would have ECMP NHs established for PPR-ID along the path..; now refer to section 2.4 In a network of N nodes O(N^2) total (unidirectional) paths are necessary to establish any-to-any connectivity, and multiple (k) such path sets may be desirable (i.e. first/second subset of links for TE path in a first/second subset of network nodes in a set of network nodes accordingly) if multiple path policies are to be supported (lowest latency, highest throughput etc.) (i.e. here second subset of links can be “non-TE” paths (example SR paths or links using ECMP and second subset of network nodes can be ECMP nodes (i.e. see procedure example of section 4 Fig.5 wherein PPR-ID value based paths and nodes can be “TE paths” and nodes while considering only shortest path between R4 and R1(example R2, R3, R8, R9) can be “non-TE” related paths and nodes accordingly);
cause advertisement of the first subset of links to the set of network nodes (see section 3 page 6 first three lines Multiple instances of this TLV MAY be advertised in IS-IS LSPs with different PPR-ID Type (data plane) and with corresponding PDE Sub-TLVS.);
cause configuration of the TE policy in the set of network nodes, wherein the TE policy defines when data packets are to be routed over one or more paths including the TE links according to a preferred path routing (PPR) protocol (already stated above in context with section 2 please refer to section 2.4 first and third paragraph.. In a network of N nodes O(N^2) total (unidirectional) paths are necessary to establish any-to-any connectivity, and multiple (k) such path sets may be desirable if multiple path policies are to be supported (lowest latency, highest throughput etc.)……. to address the scale needed when a larger number of PPR paths are required, the PPR TREE structure can be used [I-D.draft-ce-ppr-graph-00]. Each PPR Tree uses one label/SID and defines paths from any set of nodes to one destination, thus reduces the number of entries needed in SRGB at each node (for SR-MPLS data plane Section 5.1). These paths form a tree rooted in the destination. In other word, PPR Tree identifiers are destination identifiers and PPR Treed are path engineered destination routes (like IP routes) and it scaling simplifies to linear in N i.e., O(k*N)); and
after the configuration, cause signaling to the set of network nodes to begin routing data packets according to the configured TE policy (already stated above in context with section 2 please refer to section 2.4 third paragraph discussed above; further see above discussed procedure example of section 4 shown in Fig.5).
But Uma is silent about the determination regarding determine a third subset of links including a third number links between the second subset of network nodes and a set of servers; however SD-fabric teaches in Fig. 2 page 5 last 4 lines regarding … SD-Fabric is a L3 fabric where both IPv4 and IPv6 packets are routed across server racks using multiple equal-cost paths via spine switches. L2 bridging and VLANs are also supported within each server rack, and compute nodes can be dual-homed to two Top-of-Rack (ToR) switches in an active-active configuration (M-LAG)….; further see page 6 first paragraph… SD-Fabric supports a number of other router features like static routes, multicast, DHCP L3 Relay and the use of ACLs based on layer 2/3/4 options to drop traffic at ingress or redirect traffic via Policy Based Routing; further see page 10 last two lines to page 11 first ten lines regarding four major categories for SD-fabric APIs like configurations, information, control and OAM; now refer to Fig. 2 again wherein third subset of links can be links between spine/leaf nodes to routers (i.e. servers). It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claimed invention was made to consider the teachings of Sd-fabric with the teachings of Uma to make system more standardized. Having a mechanism wherein having a third subset of links including a third number links between the second subset of network nodes and a set of servers; greater way more standardized end to end multi-link communication can be carried in the communication system.
But Uma is silent about the processor circuitry is to add or insert data packet information indicating one or more of: link protecting alternative path information: and/or node protecting alternative path information; however Wijnands states in abstract .. receiving at a router, a multicast label distribution protocol message comprising local node information for a protected node and one or more leaf nodes downstream of the protected node in a primary label switched path, creating one or more backup label switched paths to the one or more leaf nodes, detecting a failure at the protected node, and forwarding at the router, traffic for the one or more leaf nodes to the one or more backup label switched paths; further see claim 2 (in context with claim 1…creating one or more backup label switched paths to said one or more leaf nodes, wherein said one or more backup label switched paths do not pass through the protected node; detecting a failure at the protected node; and forwarding at the router, traffic for said one or more leaf nodes to said one or more backup label switched paths.) about inserting local node information for the router into a multicast label distribution protocol message containing said local node information for the protected node; and transmitting said multicast label distribution protocol message to an upstream node (i.e. router adds information identifying nodes into protocol messages that govern protection behavior (i.e. backup paths)).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claimed invention was made to consider the teachings of Wijnands with the teachings of Uma in view of SD-fabric to make system more reliable. Having a mechanism wherein adding or inserting data packet information indicating one or more of: link protecting alternative path information: and/or node protecting alternative path information; greater way more reliable communication can be carried out in the communication system.
Regarding claim 45, Uma in view of SD-fabric and Wijnands teaches as per claim 42, wherein the set of network nodes includes a combination of one or more network elements, and wherein the network elements include one or more of routers, switches, hubs, gateways, access points, radio access network nodes, firewall appliances, network controllers, and fabric controllers; Uma see section 2 any node, controller, operator; further see Sd-fabric page 3 overview regarding fabric controller.
Regarding claim 46, Uma in view of SD-fabric and Wijnands teaches as per claim 42, further Uma teaches wherein the processor circuitry is to:
add or insert a path description element (PDE) to one or more data packets belonging to the traffic flow to implement the TE for the traffic flow (see section 2 PPR mitigates the issues described in Appendix A.1, while continuing to allow the direction of traffic along an engineered path through the network by replacing the label stack with a PPR-ID. The PPR-ID can either be a single label or a native destination address. To facilitate the use of a single label to describe an entire path, a new TLV is added to IS-IS…; now refer to section 2.2 .. The path identified by the PPR-ID is described as a set of Path Description Elements (PDEs), each of which represents a segment of the path. Each node determines its location in the path as described, and forwards to the next segment/hop or label of the path description (see the Forwarding Procedure Example later in this document); further see Fig. 1 (TLV as a Type-Length-Value)) ;
add or insert a Preferred Path Routing (PPR) identifier (ID) into the one or more data packets belonging to the traffic flow to implement the TE for the traffic flow (already described above see section 2 PPR mitigates the issues described in Appendix A.1, while continuing to allow the direction of traffic along an engineered path through the network by replacing the label stack with a PPR-ID. The PPR-ID can either be a single label or a native destination address. To facilitate the use of a single label to describe an entire path, a new TLV is added to IS-IS…; further see Fig. 1); and
add or insert a PPR-PDE path advertisement into the one or more data packets belonging to the traffic flow to implement the TE for the traffic flow; see section 3 Fig. 1 regarding Multiple instances of this TLV (Type length value) MAY be advertised in IS-IS LSPs with different PPR-ID Type (data plane) and with corresponding PDE Sub-TLVS. The PPR TLV has Type TBD (suggested value xxx), and has the following format:. PPR-PDE Sub-TLVs (variable); further see page 7 first four lines PPR-PDE: Variable number of ordered PDE Sub-TLVs which represents the path.
Regarding claim 53, Uma in view of SD-fabric and Wijnands teaches as per claim 42, wherein the network topology is a CLOS network topology or a leaf-and-spine network topology, and the compute node is a PPR control plane entity, a Segment Routing IPv6 (SRv6) data plane entity, a network switch, a cloud compute node, an edge compute node, a radio access network (RAN) node, or a compute node that operates one or more network functions in a cellular core network; SD-fabric Fig. 5.2 leaf-and-spine network topology and see page 5 regarding L3 fabric where both IPv4 and IPv6 packets are routed…compute node can be switch.
Claim(s) 43 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chunduri et al. “Preferred Path Routing (PPR) in IS-IS draft-chunduri-lsr-isis-preferred-path-routing-06”, published in sept 30th 2020; see IDS filed on 1/19/2024, page 2 #2; hereafter Uma in view of “SD-Fabric: open source full stack programmable leaf-spine network fabric”; Jun 2021; see IDS filed on 2/19/2024 page 2 #1; hereafter SD-fabric and further in view of Wijnands et al. (US Pat. No. 8422364 B2) and in further view of Wang (CN109660461A); see machine translated copy.
Regarding claim 43, Uma in view of SD-fabric and Wijnands teaches as per claim 42, wherein:
the set of network nodes are part of a network topology; (see Uma section 2.4 discussed above regarding network of N nodes O(N^2) total (unidirectional) paths are necessary to establish any-to-any connectivity, and multiple (k) such path sets may be desirable if multiple path policies are to be supported (lowest latency, highest throughput etc.). In many solutions and topologies, N may be small enough and/or only a small set of paths need to be preferred paths, for example for high value traffic (DetNet, some of the defined 5G slices), and then the technology specified in this document can support these deployments.); further secondary reference Sd-fabric discuss about the network topology includes a leaf layer and a spine layer, wherein the first subset of network nodes belongs to the spine layer and the second subset of network nodes belongs to the leaf layer (see Fig. 2 for leaf and spine switches; further see page 17).
But Uma in view of Sd-fabric fails to teach regarding the network topology is shared among best effort traffic flows and high priority traffic flows, and the TE policy defines the best effort traffic flows to be routed over one or more paths including links in the second subset of links and defines the high priority traffic flows to be routed over TE paths including TE links in the first subset of links; however Wang teaches on page 2 under back ground of technology teaches about Fig. 1…. HQoS tree hierarchical scheduling model. in the model, the lowest layer is the leaf node, the middle layer is a branch node, the topmost is root node. the interface receives the message, the message HQoS scheduling. each leaf node corresponds to a system predefined FC (Forwarding Class type), the system predefined FC is one scheduling queue, such as picture in effect, service BE (Best effort), AF (Default, the transmission quality of service) and NC (Network Control, service of the highest priority). interface after received the message, according to the user message priority value of searching the priority level mapping table, putting the message into a predefined corresponding to the FC. each branch node respectively corresponding to one FG (Forwarding Group, forwards the group), a forwarding group nesting multiple forwarding or predefined forwarding class. in the forwarding set of nested, nesting of forwarding group is called a parent branch node, forwarded by nested group called sub-branch node. the root node is SP (Scheduler Policy, scheduling policy), a scheduling policy more forwarding group. scheduling policy SP applied to the interface, it can according to the embedding relation from leaf nodes to root node of hierarchical scheduling flow interface; further see Fig. 1.
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claimed invention was made to consider the teachings of Wang with the teachings of Uma in view of SD-fabric and Wijnands to make system more effective. Having a mechanism wherein the network topology is shared among best effort traffic flows and high priority traffic flows, and the TE policy defines the best effort traffic flows to be routed over one or more paths including links in the second subset of links and defines the high priority traffic flows to be routed over TE paths including TE links in the first subset of links; greater way application/usage specific traffic flows can be carried out in the communication system.
Claim(s) 44 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chunduri et al. “Preferred Path Routing (PPR) in IS-IS draft-chunduri-lsr-isis-preferred-path-routing-06”, published in sept 30th 2020; see IDS filed on 1/19/2024, page 2 #2; hereafter Uma in view of “SD-Fabric: open source full stack programmable leaf-spine network fabric”; Jun 2021; see IDS filed on 2/19/2024 page 2 #1; hereafter SD-fabric and further in view of Wijnands et al. (US Pat. No. 8422364 B2) and in further view of Dhesikan et al. (US Pub. No. 2018/0062930 A1), hereafter Subh.
Regarding claim 44, Uma in view of SD-fabric and Wijnands teaches as per claim 42, but Uma is silent about wherein the set of conditions includes one or more of:
a difference between the second number and the first number is at least a threshold number of links;
a difference between the second number and the first number being greater than or equal to the third number a difference between the second number and the first number is equal to or more than a downstream-port-bandwidth threshold;
metrics of links in the first subset of links being higher than metrics of links in the second subset of links;
the first number being same as a number of switches in the network topology;
an over-subscription ratio of the third number to the difference between the second number and the first number; or
a total capacity of the first subset of links being managed centrally for traffic steering into one or more network nodes in the set of spine nodes, the set of leaf nodes, or one or more network switches in the network topology; however Subh teaches in abstract regarding .. discovering at a network controller, a topology and link capacities for a network, the network controller in communication with a plurality of spine nodes and leaf nodes, the link capacities comprising capacities for links between the spine nodes and the leaf nodes, identifying at the network controller, a flow received from a source at one of the leaf nodes, selecting at the network controller, one of the spine nodes to receive the flow from the leaf node based, at least in part, on the link capacities, and programming the network to transmit the flow from the spine node to one of the leaf nodes in communication with a receiver requesting the flow..
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claimed invention was made to consider the teachings of Subh with the teachings of Uma in view of SD-fabric and Wijnands to make system more effective. Having a mechanism wherein a difference between the second number and the first number is at least a threshold number of links;
a difference between the second number and the first number being greater than or equal to the third number a difference between the second number and the first number same or more than a downstream-port-bandwidth threshold;
metrics of links in the first subset of links being higher than metrics of links in the second subset of links;
the first number being same as a number of switches in the network topology;
an over-subscription ratio of the third number to the difference between the second number and the first number; or
a total capacity of the first subset of links being managed centrally for traffic steering into one or more network nodes in the set of spine nodes, the set of leaf nodes, or one or more network switches in the network topology; greater way resources can be managed/utilized to carry out more reliable communication in the communication system.
Claim(s) 52 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chunduri et al. “Preferred Path Routing (PPR) in IS-IS draft-chunduri-lsr-isis-preferred-path-routing-06”, published in sept 30th 2020; see IDS filed on 1/19/2024, page 2 #2; hereafter Uma in view of “SD-Fabric: open source full stack programmable leaf-spine network fabric”; Jun 2021; see IDS filed on 2/19/2024 page 2 #1; hereafter SD-fabric and further in view of Wijnands et al. (US Pat. No. 8422364 B2) and in further view of Previdi et al. (US Pat. No. 7496650 B1).
Regarding claim 52, Uma in view of SD-fabric and Wijnands teaches as per claim 42, but Uma is silent about wherein, to cause advertisement, the processor circuitry is to: increase metric values for respective links of the first subset of links based on a set of required resources, a set of traffic characteristics, and a set of service level parameters based on capabilities of each network node in the set of network nodes and links along a preferred path; however Previdi states in lines 30- 33 of col. 15 about FIG. 9B is a flow diagram illustrating a process used in one embodiment advertising a link cost (i.e. metric value) on a data network; now refer to lines 38- 55 of col. 15 about …process block 912, a link cost increment is computed, based on the minimum link cost in the network, the number of links for which a state change was detected in process block 910, and the number of nodes in the network. In one embodiment, the link cost increment is computed such that for a change of state of m links and n nodes an incremental value i meets a condition (m+2n) i<2L, where L is a minimum link cost on the network. In process block 914, the link costs are varied for links associated with components for which a state change was detected in process block 902. Varying the link cost value may include incrementing (increasing) the link cost value, decrementing (decreasing) the link cost value, modifying the link cost value by a multiplier or other factor, etc. Most commonly, when the detected state change (i.e. as per resources as well parameter and traffic conditions (i.e. failure) and service) for a component indicates deactivation or failure, the associated link cost is incremented by the computed link cost increment value, and when a detected state change indicates re-activation, the link cost is decremented by the link cost increment value. It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claimed invention was made to consider the teachings of Previdi with the teachings of Uma in view of SD-fabric and Wijnands to make system more standardized. Having a mechanism wherein, to cause advertisement, the processor circuitry is to: increase metric values for respective links of the first subset of links based on a set of required resources, a set of traffic characteristics, and a set of service level parameters based on capabilities of each network node in the set of network nodes and links along a preferred path; greater way standardized approach can be carried out in the communication system.
Allowable Subject Matter
Claims 54- 60 are allowed.
Claims 47- 51 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Note: reason for allowance for claims will be provided in the next office action.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Please see PTO-892 form for considered prior arts for record.
Reference Nadas et al. (US Pub. No. 20150063121) teaches method in a transmitting node for redirecting a flow of data packets to a path of alternative paths, where each data packet is marked with a value indicating the importance of the data packet, the method comprising: directing one or more flows of data packets for the alternative paths, wherein data packets marked with a higher value indicating the importance of the data packets are prioritized over data packets marked with a lower value; receiving feedback information comprising a metric of congestion for each alternative path, wherein the metric of congestion is based on the values indicating the importance of the data packets transmitted on each alternative path; and redirecting a flow of data packets from a first path of the alternative paths, to a second path of the alternative paths, in response to determining that the metric of congestion of the first path indicates a higher congestion than the one of the second path; see claim 1.
Reference Gredler et al. (US Pub. No. 20120224506 A1) teaches in claim 1 about receiving, with a router logically located within a first routing protocol domain, traffic engineering information for a traffic engineering link; encoding the traffic engineering information to an exterior gateway routing protocol advertisement; and sending the exterior gateway routing protocol advertisement from the router to a network device logically located within a second routing protocol domain; now refer to claim 4 , wherein encoding the traffic engineering information for the traffic engineering link comprises: determining one or more router identifiers for each of two anchor nodes of the traffic engineering link; and encoding the router identifiers within the exterior gateway routing protocol advertisement; further see claim 5….wherein one of the router identifiers for a first one of the anchor nodes of the traffic engineering link comprises a combination of an autonomous system identifier for an autonomous system in which the first anchor node is logically located and a network address for the first anchor node, and wherein the combination comprises a globally unique router identifier.
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 PARTH PATEL whose telephone number is (571)270-1970. The examiner can normally be reached 7 a.m. -7 p.m. 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, Jae Y. Lee can be reached at 5712703936. 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.
PARTH PATEL
Primary Examiner
Art Unit 2479
/PARTH PATEL/ Primary Examiner, Art Unit 2479