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 .
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-3 and 7-20 are rejected under 35 U.S.C. 103 as being unpatentable over Elizabeth et al (US 20210099400) in view of Grammel et al (EP 3525367) and in further view of Hu et al. (CN 112866076).
With regards to claims 1 and 20, Elizabeth teaches A network device, comprising: one or more ports; a processor; and a memory communicatively coupled to the processor ((fig. 9 (block diagram of an example processor-based system that may be used to execute the example methods and/or to store information (i.e., memory) used and/or generated by such example methods), [61], Elizabeth))
wherein the memory comprises a port property synchronizing logic (port synchronization for multicast on an Ethernet Segment (ES) for multihomed device; [55] and fig 3 (method for providing port synchronization for multicast on an Ethernet segment (ES) in which a first device is multihomed to at least two devices of a VLAN), Elizabeth)
that is configured to receive, via a port of the one or more ports (fig 10B (port 220 and PE1), Elizabeth),
a multicast query message from a host device (fig 10A (query message 210 and PE1), Elizabeth),
wherein the host device is coupled to a multi-homing set including the network device and a peer network device (detecting/receiving multicast query message from a multihomed host device on an Ethernet virtual private network (EVPN), including network device and peer network device; fig 3, 10A (Host, network device (CE1), peer network device (PE1, PE2)), [44], [55], Elizabeth)
update at least one port property of the port based on the multicast query message at the port ((a) detecting (i.e., receiving), on a first interface of the first device, from the third device via the ES, a multicast query message, wherein the multicast query message is not detected by the second device via the ES; (b) marking the first interface (marking interface constitutes as updating port property) of the first device as a multicast router port (i.e., updating at least one port property (multicast router port designation) based on the multicast message received at the port); fig 3 (310 & 320), [44], Elizabeth);
generate a notification message including an Ethernet Segment Identifier (ESI)
associated with the port (generating a message identifying the ES (ESI) associated with port including information encoding that the multicast query message was detected on the ES; fig 3 (320, 330), [44], Elizabeth);
and transmit the generated notification message to the peer network device (sending/transmitting the generated message via EVPN to a network device; fig 3 (340), fig 10B (1010), [44], Elizabeth).
Elizabeth does not teach “generate a notification message including … and the updated at least one port property of the port.”
In the same field of endeavor, Grammel teaches how the notification message may include the updated at least one port property of the port (transmitting a second Ethernet signal to the first network device and the second Ethernet signal rep-25 resents a status of the router. For example, the status of the router can include the status of port usage in the router and/or the timing and synchronization of the router (i.e., message including updated port property information); column 6, lines 23-27, Grammel).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date, to have combined the teachings of Elizabeth and Grammel to improve communication efficiency to ensure the peer network devices are operating as desired (column 1, line 20, Grammel).
Elizabeth in view of Grammel does not teach the multicast query message includes a source address indicating a multicast source and a timeout parameter indicating a time interval within which a response to the multicast query message is expected.
However in the same field of endeavor, Hu teaches the multicast query message includes a source address indicating a multicast source and a timeout parameter indicating a time interval within which a response to the multicast query message is expected (Hu discloses that an IGMP query message (i.e., multicast query message) includes a maximum response time field indicating the longest time before a response report is sent, thereby teaching that the multicast query message includes a timeout parameter specifying the time interval within which a response to the query message is expected; [page 3, paragraph starting with "Illustratively, the IGMP message includes…"], Hu. Hu further teaches an IGMPv3 query message associated with (S,G) multicast communication, where S represents the specific multicast source address, thereby teaching that the multicast query message includes a source address indicating a multicast source; [page 4, paragraph starting with "For example, the IGMP inquiry message is an IGMP V3…"], Hu)
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date, to incorporate Hu's IGMP query message fields into teachings of Elizabeth and Grammel to provide a timeout parameter for expected responses and a multicast source address, thereby facilitating standardized multicast group membership maintenance and source-specific multicast operation.
With regards to claim 2, Elizabeth teaches through Grammel and Hu, wherein the ESI indicates an Ethernet Segment (ES) associated with the port on which the multicast query message is received (the first device (PE1) also generates a message identifying the ES (e.g., using the ESI) and including information encoding that the multicast query message was detected on the ES; fig 3 (320, 330) [65], Elizabeth).
With regards to claim 3, Elizabeth teaches through Grammel and Hu, wherein the notification message further includes an Ethernet Virtual private network Instance (EVI) identifier indicating an EVI on which the multicast query message is received (generating a message identifying the ES and including information encoding that the multicast query message was detected on the ES (inclusion of such EVPN-related identifiers constitutes including information identifying an EVPN instance. Both ESI an EVI are identifiers used within EVPN to convey service and forwarding context); [44], Elizabeth. An EVPN instance (EVI) is an EVPN routing and forwarding instance spanning all the PEs participating in that VPN. An EVI may be configured on the PEs on a per-customer basis. Each EVI has a unique route distinguisher and one or more route targets. Referring to FIG. 1, an EVI is configured on Routers PE1 (where query message is received and generates a message identifying the ES, fig 1, 10A, 10B), PE2, and PE3; [15], Elizabeth).
With regards to claim 7, Elizabeth teaches through Grammel and Hu, wherein the notification message is configured to synchronize the updated at least one port property with another port of the peer network device that is associated with the ESI (the first device (PE1) sends, via the EVPN, the message generated to the second device (PE2) so that the second device (PE2) will mark an interface, which is on the ES, and which is with the third device (CE), as a multicast router (mrouter) port. In this way, first and second devices (PE1 and PE2) have interfaces on the ES, with the third device (CE) synchronized, such that they are both marked as a multicast router (mrouter) port (i.e., synchronize the updated at least one port property with another port of the peer network device that is associated with the ESI); [65], Elizabeth).
With regards to claim 8, Elizabeth teaches through Grammel and Hu, wherein the updated at least one port property indicates the port as a Multicast router (Mrouter) port (…The first device (PE1) then marks (i.e., updates) the first interface as a multicast router (mrouter) port; [65], Elizabeth).
With regards to claim 9, Elizabeth teaches through Grammel and Hu, wherein the multicast query message corresponds to an Internet Group Management Protocol (IGMP) query message (the multicast query message is an Internet Group Management Protocol (IGMP) message…; [49], Elizabeth).
With regards to claim 10, Elizabeth teaches through Grammel and Hu, wherein the multicast query message corresponds to a Protocol Independent Multicast (PIM) hello message (the multicast query message is an Internet Group Management Protocol (IGMP) message (multicast query message may correspond to an Internet Group Management Protocol (IGMP) query message, a Protocol Independent Multicast (PIM) hello message, or the like); [49], Elizabeth. For multicast forwarding between bridge domains or VLANs in this environment, PEs can use Protocol Independent Multicast (PIM) in distributed designated router (DDR) mode on IRB interfaces. The IRB interfaces on PEs route multicast traffic between bridge domains or VLANs as follows. Upon receiving multicast traffic on an IRB interface from a multicast source, the PE routes the traffic to any IRBs that have PIM enabled and are configured for bridge domains or VLANs with interested local receivers for the multicast group; [0037], Elizabeth)
With regards to claim 11, Elizabeth teaches, a network device, comprising: one or more ports; a processor; and a memory communicatively coupled to the processor, wherein the memory comprises a port property synchronizing logic that is configured to: receive, from a peer network device, a notification message including an Ethernet Segment Identifier (ESI) and …, wherein the network device and the peer network device belong to a multi-homing set coupled to a host device, wherein the at least one port property included in the notification message is an updated port property generated by the peer network device based on reception of a multicast query message … identify, from the one or more ports, a port associated with the ESI; and associate the identified port with the at least one port property (Referring to FIG. 10B (Host, network device (CE1), peer network device (PE1, PE2)), PE1 detects the IGMP query 210, and in response, PE1 marks the interface towards CE1 as an multicast router (mrouter) port 220. (Recall, e.g., 320 of FIG. 3 (method for providing port synchronization for multicast on an Ethernet segment (ES) in which a first device is multihomed to at least two devices of a VLAN).) (i.e., the network device and the peer network device belong to a multi-homing set coupled to a host device) Further, PE1 will originate a Type-7 (*,*) route for the ES in a BGP message 1010 (i.e., notification message). Although this message 1010 may be provided to any PEs in the EVPN (e.g., PE2 and PE3) (not all shown in FIG. 10B), since the message 1010 carries an identifier of the ES (ESI), only those PEs belonging to the ES (e.g., PE2, but not PE3) will import the Type-7 (*,*) route. Referring to FIG. 10C, when PE2 receives the Type-7 (*,*) route for the ES (i.e., receives notification message including an ESI from a peer network device (PE1)), it will mark its L2 interface 1020 on the ES as an mrouter port and install appropriate routing and/or forwarding information (i.e., identify port associated with ESI and associated identified port with at least one port property). Finally, referring to FIG. 10D, suppose that CE1 wants to pull multicast traffic from within the VLAN fabric. For example, a host (multicast receiver) 280 coupled with CE1 may want to receive multicast packets from a host (multicast source) 290 coupled with CE2. Consequently, assume that CE1 sends a PIM (S,G) Join 240. Assume that the PIM (S,G) Join 240 is sent over the link to PE2. PE2 will add in its L3-multicast forwarding outgoing interface (OIF), the IRB-MVLAN interface 1030. Since the PE2's L2-interface towards CE1 was previously marked as an mrouter port 1020, PE2 will forward multicast group (G) traffic to CE1. Note that there can be multiple MVLANs where the PEs will connect with an external multicast. Sometimes the PEs are also multihomed to firewall devices running PIM. In the absence of synchronization of the mrouter port (such as provided by example method 300), multicast traffic will not flow properly; [0101] and [0102], Elizabeth. Elizabeth further teaches detecting (i.e., receiving), on a first interface of the first device, from the third device via the ES, a multicast query message, wherein the multicast query message is not detected by the second device via the ES; (b) marking the first interface (marking interface constitutes as updating port property) of the first device as a multicast router port (i.e., updating at least one port property (multicast router port designation) based on the multicast message received at the port); fig 3 (310 & 320), [44], Elizabeth).
Elizabeth does not teach “a notification message including … at least one port property.”
However, in the same field of endeavor, Grammel teaches how the notification message may include at least one port property (transmitting a second Ethernet signal to the first network device and the second Ethernet signal rep-25 resents a status of the router. For example, the status of the router can include the status of port usage in the router and/or the timing and synchronization of the router (i.e., message including updated port property information); column 6, lines 23-27, Grammel).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date, to have combined the teachings of Elizabeth and Grammel to improve communication efficiency to ensure the peer network devices are operating as desired (column 1, line 20, Grammel).
Elizabeth in view of Grammel does not teach the multicast query message includes a source address indicating a multicast source and a timeout parameter indicating a time interval within which a response to the multicast query message is expected.
However, in the same field of endeavor, Hu teaches the multicast query message includes a source address indicating a multicast source and a timeout parameter indicating a time interval within which a response to the multicast query message is expected (Hu discloses that an IGMP query message (i.e., multicast query message) includes a maximum response time field indicating the longest time before a response report is sent, thereby teaching that the multicast query message includes a timeout parameter specifying the time interval within which a response to the query message is expected; [page 3, paragraph starting with "Illustratively, the IGMP message includes…"], Hu. Hu further teaches an IGMPv3 query message associated with (S,G) multicast communication, where S represents the specific multicast source address, thereby teaching that the multicast query message includes a source address indicating a multicast source; [page 4, paragraph starting with "For example, the IGMP inquiry message is an IGMP V3…"], Hu)
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date, to incorporate Hu's IGMP query message fields into teachings of Elizabeth and Grammel to provide a timeout parameter for expected responses and a multicast source address, thereby facilitating standardized multicast group membership maintenance and source-specific multicast operation.
With regards to claim 12, Elizabeth teaches through Grammel and Hu, wherein the at least one port property corresponds to a Multicast router (Mrouter) port property (Referring to FIG. 10B (Host, network device (CE1), peer network device (PE1, PE2)), PE1 detects the IGMP query 210, and in response, PE1 marks the interface towards CE1 as a multicast router (mrouter) port 220. (Recall, e.g., 320 of FIG. 3. Further, PE1 will originate a Type-7 (*,*) route for the ES in a BGP message 1010 (i.e., notification message; fig 10D (220), [0101], Elizabeth).
With regards to claim 13, Elizabeth teaches through Grammel and Hu, wherein to associate the identified port with the at least one port property, the port property synchronizing logic is further configured to mark the identified port as an Mrouter port (Referring to FIG. 10C, when PE2 receives the Type-7 (*,*) route for the ES, it will mark its L2 interface 1020 on the ES (i.e., port property synchronization) as an mrouter port and install appropriate routing and/or forwarding information; fig 10D (1020), [0101], Elizabeth).
With regards to claim 14, Elizabeth teaches through Grammel and Hu, wherein the port property synchronizing logic is further configured to: receive a multicast join synch message from the peer network device; and transmit, via the Mrouter port to the host device, a proxy report based on the multicast join synch message (a host (multicast receiver) 280 coupled with CE1 may want to receive multicast packets from a host (multicast source) 290 coupled with CE2. Consequently, assume that CE1 sends a PIM (S,G) Join 240 (i.e., join synch message). Assume that the PIM (S,G) Join 240 is sent over the link to PE2 (i.e., PE2 receiving join synch from a peer network device). PE2 will add in its L3-multicast forwarding outgoing interface (OIF), the IRB-MVLAN interface 1030. Since the PE2's L2-interface towards CE1 was previously marked as an mrouter port 1020, PE2 will forward multicast group (G) traffic to CE1 (i.e., transmit proxy report based on multicast join synch to host via mrouter to host device (the act of forwarding multicast traffic to CE1 reflects that PE2 has accepted and representing multicast membership for the group on behalf of CE1, which constitutes proxy reporting behavior)); fig 10D (host, CE1, PE2, 1020), [0101], Elizabeth).
With regards to claim 15, Elizabeth teaches through Grammel and Hu, wherein the port property synchronizing logic is further configured to: determine that a state of the Mrouter port corresponds to a designated forwarder (DF) state; and transmit, via the Mrouter port, the proxy report to the host device based on the determination that the state of the Mrouter port corresponds to the DF state (Recall from FIG. 1 that CE1 is multihomed to PE1 and PE2. In this way, CE2 has (at least) two potential paths to reach CE1. Depending on the multihoming mode of redundancy (described later), only one path or both the paths (or all paths if there are more than two) are active at any time. The multihoming mode of operation also determines a designated forwarder (DF) PE(s) for forward traffic to the CE. The DF PE may use MPLS LSP or GRE tunnels to forward traffic. If a failure occurs over this path, a new DF PE is elected to forward the traffic to CE1; [0011], Elizabeth. Fig 10D (mrouter port corresponds to PE(s) transmit proxy report to host), [0101], Elizabeth).
With regards to claim 16, Elizabeth teaches through Grammel and Hu, wherein the port property synchronizing logic is further configured to receive, from the host device via the Mrouter port, a multicast traffic flow based on the transmitted proxy report (Referring to FIG. 10C, when PE2 receives the Type-7 (*,*) route for the ES (i.e., proxy report/ multicast membership advertisement), it will mark its L2 interface 1020 on the ES as an mrouter port and install appropriate routing and/or forwarding information. Finally, referring to FIG. 10D, suppose that CE1 wants to pull multicast traffic from within the VLAN fabric. For example, a host (multicast receiver) 280 coupled with CE1 may want to receive multicast packets from a host (multicast source) 290 coupled with CE2. Consequently, assume that CE1 sends a PIM (S,G) Join 240. Assume that the PIM (S,G) Join 240 is sent over the link to PE2. PE2 will add in its L3-multicast forwarding outgoing interface (OIF), the IRB-MVLAN interface 1030. Since the PE2's L2-interface towards CE1 was previously marked as an mrouter port 1020, PE2 will forward multicast group (G) traffic (i.e., multicast traffic flow based on transmitted proxy report, type-7 route generated by PE1 and/or PIM join from CE1 (connected to host) collectively function as proxy flow. PE1 and PE2 are marked as mrouter. Also, in IGMP snooping network devices act as proxies for host) to CE1; [0101], Elizabeth).
With regards to claim 17, Elizabeth teaches through Grammel and Hu, wherein the port property synchronizing logic is further configured to update a snooping table based on receiving the multicast join synch message (…the third device being multihomed to the first device and the second device via the ES, and the first and second devices having snooping enabled for multicast group messages (i.e., updating snooping table based on receiving the multicast join synch message - it listens to multicast group membership messages ("join" messages) to dynamically update a table)…; [0044], Elizabeth).
With regards to claim 18, Elizabeth teaches through Grammel and Hu, wherein to associate the identified port with the at least one port property, the port property synchronizing logic is further configured to mark the identified port as a non-Mrouter port (Finally, note that when a PE detects that an ES-facing interface is no longer an mrouter port (e.g., due to the CE stopping multicast queries, e.g., for a predetermined time), the PE may withdraw the Type-7 (*,*) route (or otherwise communicate to the other PE(s) on the EVPN and the ES that it is withdrawing its mrouter port, so the other PE(s) should withdraw theirs too) (i.e., the interface is no longer classified as mrouter port. Updating a classification of the interface from mrouter port to a not being an mrouter port corresponds to marking the identified port as a non-mrouter port. Withdrawal of type-7 route shows the interface no longer treated as participating in multicast routing); [0108], Elizabeth).
With regards to claim 19, Elizabeth teaches through Grammel and Hu, wherein the ESI indicates an Ethernet Segment (ES) on which a multicast query message is received from the host device (…a message identifying the ES (ESI) associated with port including information encoding that the multicast query message was detected on the ES; fig 3 (320, 330), [44], Elizabeth. …detecting/receiving multicast query message from a multihomed host device on an Ethernet virtual private network (EVPN), including network device and peer network device; fig 3, 10A (Host, CE1, PE1, PE2), [44], [55], Elizabeth.)
Claims 4-6 are rejected under 35 U.S.C. 103 as being unpatentable over Elizabeth in view of Grammel, further in view of Hu, and further in view of Nagarajan et al (US 2018/0287946).
With regards to claim 4, Elizabeth teaches through Grammel and Hu the limitations of claim 4 as applied to claim 1 except for wherein the port property synchronizing logic is further configured to: receive a multicast join message from a new host device; generate a multicast join synch message based on the multicast join message; and transmit the generated multicast join synch message to the peer network device.
However, in the same field of endeavor, Nagarajan teaches techniques for load-balancing responsibility for forwarding multicast traffic into an active-active Ethernet segment (ES) between two or more multi-homed provider edge (PE) routers and a customer edge (CE) router in an Ethernet Virtual Private Network (EVPN) ([0005], Nagarajan). Nagarajan further teaches wherein the port property synchronizing logic is further configured to: receive a multicast join message from a new host device; generate a multicast join synch message based on the multicast join message; and transmit the generated multicast join synch message to the peer network device (PE routers 10A-10C of Ethernet segment 14 may use the IGMP protocol to receive Join messages from hosts. Upon receiving, from the hosts, a notification to subscribe in the membership of a specific multicast group (i.e., generate a join synch), one of PE routers 10A-10C forwards this information to the other PE routers (i.e., transmit the join synch to other peer network devices); fig 1, [30], Nagarajan. PE router 10A may send a Type-7 BGP join synch route to other PE routers 10 to synchronize the join state (504). For example, in response to receiving the IGMP join report, PE router 10A may install a Type-7 BGP route, e.g., a BGP join synch route, in routing information 206 and may advertise the Type-7 BGP route via any of outbound links 230 to other PE routers 10, e.g., PE routers 10B and 10C, on Ethernet segment 14. PE router 10A may issue the BGP join synch route to all PE routers attached to Ethernet segment 14 (i.e., generate and transmit multicast join synch message) such that each of the PE routers attached to Ethernet segment 14 may receive the BGP join synch route and to instantiate its IGMP join state in its multicast state table with the information included in the BGP join synch route. Although not shown, PE router 10A may also receive Type-7 BGP join synch routes from other PE routers 10 such that PE router 10A may instantiate its IGMP join state with the information included in the received BGP join synch routes; [0088], Nagarajan).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date, to have combined the teachings of Elizabeth and Nagarajan to improve access to EVPN provided by service provider network as well as to prevent duplicate join processing and duplicate multicast forwarding state creation.
With regards to claim 5, Elizabeth, Grammel, Hu, and Nagarajan disclose the limitations of claim 4, including wherein the multicast join synch message includes at least one of a new ESI associated with the multicast join message or an Ethernet Virtual private network Instance (EVI) identifier associated with the multicast join message (Nagarajan teaches techniques for load-balancing responsibility for forwarding multicast traffic into an active-active Ethernet segment (ES) between two or more multi-homed provider edge (PE) routers and a customer edge (CE) router in an Ethernet Virtual Private Network (EVPN) ([0005], Nagarajan). Nagarajan further teaches If a PE router 200, either the DF or a non-DF PE router, receives, on a given multi-homed Ethernet segment operating in all-active redundancy mode, an IGMP join report for (x, G), it determines the EVI to which the IGMP join report belongs (i.e., join synch includes EVI). If PE router 200 does not already have a local IGMP Join (x, G) state for that EVI on that ES in the routing information 206 of PE router 200, PE router 200 instantiates a local IGMP Join (x, G) state in multicast state table 207, installs a BGP Type-7 route, e.g., a BGP join synch route, in routing information 206, and advertises the BGP Type-7 route for that [ES, EVI, BD] to other PE routers on the Ethernet segment (i.e., join synch includes ES identifier or EVI); [0068], Nagarajan). Motivation to combine is similar to that of claim 4.
With regards to claim 6, Elizabeth, Grammel, Hu, and Nagarajan disclose the limitations of claim 4, including wherein the port property synchronizing logic is further configured to: determine whether a state of the port corresponds to a non-designated forwarder (DF) state; and drop the received multicast join message based on the determination that the state of the port corresponds to the non-DF state (Nagarajan teaches techniques for load-balancing responsibility for forwarding multicast traffic into an active-active Ethernet segment (ES) between two or more multi-homed provider edge (PE) routers and a customer edge (CE) router in an Ethernet Virtual Private Network (EVPN) ([0005], Nagarajan). Nagarajan further teaches PE router 10A may determine it is not to be configured as an elected multicast forwarder. In this example, PE router 10Amay continue forwarding multicast traffic based on the designated forwarder calculation (414). For example, if PE router 10A is a non-designated forwarder and is not configured as an elected multicast forwarder, PE router 10A drops the multicast traffic received over the EVPN core; see column 17, lines 60-67, Nagarajan - [0085] US 20180287946 Nagarajan). Motivation to combine is similar to that of claim 4.
Response to Arguments
Applicant’s arguments with respect to claims 1, 11, and 20 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.
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 SAYEEM KAZI whose telephone number is (571)397-2559. The examiner can normally be reached Mon-Fri 8:00-5:00 EST.
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, Emmanuel Moise can be reached at 571-272-3865. 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.
/S.K./ Examiner, Art Unit 2455
/EMMANUEL L MOISE/Supervisory Patent Examiner, Art Unit 2455
Prosecution Insights