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 .
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 03/24/2026 has been entered.
This Office action is in response to the RCE filed on 03/24/2026. Claims 2 and 4 have been canceled.
Claims 1, 3 and 5-20 are presented for examination.
Claim Rejections - 35 USC § 102
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 (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 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 11-12, 17-18 and 20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Kommula et al. (US 8,798,059 B1).
As to claim 11, Kommula discloses a method of operating a private virtual local area network (VLAN) (Fig. 1, 100; col. 3, lines 42-58, “network 100 may form a private VLAN that includes primary VLAN 140, secondary community VLAN 150 and secondary isolated VLAN 160. Network device 110-2 and client devices 130-1 through 130-3 may be provided in primary VLAN 140”), comprising:
receiving a data packet at an ingress port (Fig. 2, 210; Fig. 4, 310-330; col. 1, lines 59-65, “receiving, by the network device, a first packet on one of a plurality of private VLAN ports of the network device”; col. 8, lines 12-28, “promiscuous port 310 may receive a packet 410 (e.g., that includes a source MAC address and a destination MAC address)”; col. 8, lines 29-44, “isolated port 320 may receive a packet 440 (e.g., that includes a source MAC address and a destination MAC address)”);
performing a VLAN mapping lookup operation to identify a private VLAN domain of the private VLAN based on the ingress port and an ingress subdomain associated with a primary VLAN (Fig. 1, 140; Fig. 5, 530) or a secondary VLAN (Fig. 1, 150, 160; Fig. 5, 540) in the private VLAN (Fig. 3, 300; col. 3, lines 2-12, “classify packets received by private VLAN ports based on the types of ports (e.g., promiscuous, community, or isolated) receiving the packets. The systems and/or methods may also apply MAC address learning to all private VLAN ports, and may store the learned MAC addresses in a single primary VLAN MAC address table”; col. 4, lines 30-45, “a packet received on a promiscuous port may be classified to be associated with primary VLAN 140, and a MAC address learned on a promiscuous port may be installed in multiple MAC address tables associated with primary VLAN 140, secondary community VLAN 150, and secondary isolated VLAN 160”; col. 4, lines 46-60, “a packet received on a community port may be classified to be associated with secondary community VLAN 150, and a MAC address learned on a community port may be installed in multiple MAC address tables associated with primary VLAN 140 and secondary community VLAN 150”; col. 6, lines 36-55, “a packet may be classified to be associated with primary VLAN 140 (e.g., if the packet is received on promiscuous port 310), secondary community VLAN 150 (e.g., if the packet is received on one of community ports 330), and secondary isolated VLAN 160 (e.g., if the packet is received on isolated port 320)”); and
subsequent to performing the VLAN mapping lookup operation, performing learning and forwarding lookup operations using the private VLAN domain (Fig. 7, 710-780; col. 3, lines 1-12, “The systems and/or methods may also apply MAC address learning to all private VLAN ports, and may store the learned MAC addresses in a single primary VLAN MAC address table (e.g., rather than in multiple tables). The systems and/or methods may also utilize a destination MAC lookup (e.g., of the primary VLAN MAC address table) to determine whether to forward a packet to a located MAC address or to treat the packet as unknown unicast traffic”; col. 6, lines 36-55, “perform destination MAC address lookup for a packet (e.g., so that network device 110-2 can forward the packet to the appropriate device in network 100). For example, primary VLAN MAC address table 300 may include every MAC address learned on any of the private VLAN ports (e.g., promiscuous port 310, isolated port 320, community ports 330, and/or trunk port 340)”; col. 10, lines 9-29, “If lookup component 600 finds an entry (e.g., in MAC address field 500) of primary VLAN MAC address table 300 that matches the destination MAC address of the packet, lookup component 600 may deem the entry qualified (e.g., for forwarding the packet) if the MAC address signature (e.g., provided in MAC address signature field 510) of the entry is the same as the packet's classified VLAN signature”).
As to claim 12, Kommula discloses the method of claim 11, further comprising: setting a forwarding domain of the data packet from the ingress subdomain to the private VLAN domain (col. 1, lines 22-36, “the primary VLAN and can communicate with all interfaces, including community and isolated ports that belong to the secondary VLANs associated with the primary VLAN…Traffic received from an isolated port may be forwarded only to promiscuous ports”; col. 7, lines 1-12, “Network device 110-2 may forward traffic, received from isolated port 320, only to promiscuous port 310”).
As to claim 17, Kommula discloses a system (Figs. 1-2) comprising:
an ingress port (Fig. 2, 210; Fig. 4, 310-330) configured to receive a data packet (col. 1, lines 59-65, “receiving, by the network device, a first packet on one of a plurality of private VLAN ports of the network device”; col. 8, lines 12-28, “promiscuous port 310 may receive a packet 410 (e.g., that includes a source MAC address and a destination MAC address)”; col. 8, lines 29-44, “isolated port 320 may receive a packet 440 (e.g., that includes a source MAC address and a destination MAC address)”);;
a virtual local area network (VLAN) mapping stage configured to perform a VLAN mapping lookup to identify a private VLAN domain using an ingress subdomain of a primary VLAN or a secondary VLAN in the private VLAN domain (Fig. 3, 300; col. 3, lines 2-12, “classify packets received by private VLAN ports based on the types of ports (e.g., promiscuous, community, or isolated) receiving the packets. The systems and/or methods may also apply MAC address learning to all private VLAN ports, and may store the learned MAC addresses in a single primary VLAN MAC address table”; col. 4, lines 30-45, “a packet received on a promiscuous port may be classified to be associated with primary VLAN 140, and a MAC address learned on a promiscuous port may be installed in multiple MAC address tables associated with primary VLAN 140, secondary community VLAN 150, and secondary isolated VLAN 160”; col. 4, lines 46-60, “a packet received on a community port may be classified to be associated with secondary community VLAN 150, and a MAC address learned on a community port may be installed in multiple MAC address tables associated with primary VLAN 140 and secondary community VLAN 150”; col. 6, lines 36-55, “a packet may be classified to be associated with primary VLAN 140 (e.g., if the packet is received on promiscuous port 310), secondary community VLAN 150 (e.g., if the packet is received on one of community ports 330), and secondary isolated VLAN 160 (e.g., if the packet is received on isolated port 320)”); and
a learning and forwarding stage configured to perform, subsequent to the VLAN mapping lookup, learning and forwarding lookups using the private VLAN domain (Fig. 7, 710-780; col. 3, lines 1-12, “The systems and/or methods may also apply MAC address learning to all private VLAN ports, and may store the learned MAC addresses in a single primary VLAN MAC address table (e.g., rather than in multiple tables). The systems and/or methods may also utilize a destination MAC lookup (e.g., of the primary VLAN MAC address table) to determine whether to forward a packet to a located MAC address or to treat the packet as unknown unicast traffic”; col. 6, lines 36-55, “perform destination MAC address lookup for a packet (e.g., so that network device 110-2 can forward the packet to the appropriate device in network 100). For example, primary VLAN MAC address table 300 may include every MAC address learned on any of the private VLAN ports (e.g., promiscuous port 310, isolated port 320, community ports 330, and/or trunk port 340)”; col. 10, lines 9-29, “If lookup component 600 finds an entry (e.g., in MAC address field 500) of primary VLAN MAC address table 300 that matches the destination MAC address of the packet, lookup component 600 may deem the entry qualified (e.g., for forwarding the packet) if the MAC address signature (e.g., provided in MAC address signature field 510) of the entry is the same as the packet's classified VLAN signature”).
As to claim 18, Kommula discloses the system of claim 17, further comprising: a VLAN filtering stage configured to filter the data packet based on the ingress subdomain (col. 3, lines 2-12, “classify packets received by private VLAN ports based on the types of ports (e.g., promiscuous, community, or isolated) receiving the packets”; col. 4, lines 46-60, “a packet received on a community port may be classified to be associated with secondary community VLAN 150, and a MAC address learned on a community port may be installed in multiple MAC address tables associated with primary VLAN 140 and secondary community VLAN 150”; col. 4, line 61 – col. 5, line 8, “a packet received on an isolated port may be classified to be associated with secondary isolated VLAN 160, and a MAC address learned on an isolated port may be installed in multiple MAC address tables associated with primary VLAN 140 and isolated community VLAN 160”).
As to claim 20, Kommula discloses the system of claim 17, wherein the learning and forwarding stage is further configured to: perform the learning lookup by using the private VLAN domain and a source media access control (MAC) address of the data packet as keys to identify the ingress port; and perform the forwarding lookup by using the private VLAN domain and a destination MAC address of the data packet as keys to identify a corresponding egress port for the data packet (Fig. 7, 710-780; col. 3, lines 1-12, “The systems and/or methods may also apply MAC address learning to all private VLAN ports, and may store the learned MAC addresses in a single primary VLAN MAC address table (e.g., rather than in multiple tables). The systems and/or methods may also utilize a destination MAC lookup (e.g., of the primary VLAN MAC address table) to determine whether to forward a packet to a located MAC address or to treat the packet as unknown unicast traffic”; col. 6, lines 36-55, “perform destination MAC address lookup for a packet (e.g., so that network device 110-2 can forward the packet to the appropriate device in network 100). For example, primary VLAN MAC address table 300 may include every MAC address learned on any of the private VLAN ports (e.g., promiscuous port 310, isolated port 320, community ports 330, and/or trunk port 340)”; col. 10, lines 9-29, “If lookup component 600 finds an entry (e.g., in MAC address field 500) of primary VLAN MAC address table 300 that matches the destination MAC address of the packet, lookup component 600 may deem the entry qualified (e.g., for forwarding the packet) if the MAC address signature (e.g., provided in MAC address signature field 510) of the entry is the same as the packet's classified VLAN signature”).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) 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.
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, 5-10, 13-16 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Kommula et al. (US 8,798,059 B1), in view of Rajan et al. (US 2018/0159801 A1), CISCO (Configuring VLAN Mapping), November 7, 2016.
As to claim 1, Kommula discloses the invention as claimed, including a method of operating a network device, comprising:
receiving a packet (Fig. 4, 410-470) via an ingress port of the network device (Fig. 2, 210; Fig. 4, 310-330, col. 1, lines 59-65, “receiving, by the network device, a first packet on one of a plurality of private VLAN ports of the network device”; col. 8, lines 12-28, “promiscuous port 310 may receive a packet 410 (e.g., that includes a source MAC address and a destination MAC address)”; col. 8, lines 29-44, “isolated port 320 may receive a packet 440 (e.g., that includes a source MAC address and a destination MAC address)”);
performing a virtual local area network (VLAN) mapping lookup to identify a private VLAN domain based on the ingress port and an ingress subdomain associated with a primary VLAN (Fig. 1, 140; Fig. 5, 530) or a secondary VLAN (Fig. 1, 150, 160; Fig. 5, 540) in the private VLAN domain (Fig. 3, 300; col. 3, lines 2-12, “classify packets received by private VLAN ports based on the types of ports (e.g., promiscuous, community, or isolated) receiving the packets. The systems and/or methods may also apply MAC address learning to all private VLAN ports, and may store the learned MAC addresses in a single primary VLAN MAC address table”; col. 4, lines 30-45, “a packet received on a promiscuous port may be classified to be associated with primary VLAN 140, and a MAC address learned on a promiscuous port may be installed in multiple MAC address tables associated with primary VLAN 140, secondary community VLAN 150, and secondary isolated VLAN 160”; col. 4, lines 46-60, “a packet received on a community port may be classified to be associated with secondary community VLAN 150, and a MAC address learned on a community port may be installed in multiple MAC address tables associated with primary VLAN 140 and secondary community VLAN 150”; col. 6, lines 36-55, “a packet may be classified to be associated with primary VLAN 140 (e.g., if the packet is received on promiscuous port 310), secondary community VLAN 150 (e.g., if the packet is received on one of community ports 330), and secondary isolated VLAN 160 (e.g., if the packet is received on isolated port 320)”);
modifying a forwarding domain of the packet from the ingress subdomain to the private VLAN domain identified by the VLAN mapping lookup (Fig. 4, 420, 450, 480; col. 8, lines 12-28, “packet 410 may be converted to a modified packet 420 that includes the source MAC address, the destination MAC address, the classified VLAN signature, and the primary VLAN signature. Packet classifier 400 may populate primary VLAN MAC address table 300 with the source MAC address of modified packet 420 and with the classified VLAN signature of modified packet 420, as indicated by reference number 430”; col. 8, lines 29-44, “packet 440 may be converted to a modified packet 450 that includes the source MAC address, the destination MAC address, the classified VLAN signature, and the primary VLAN signature. Packet classifier 400 may populate primary VLAN MAC address table 300 with the source MAC address of modified packet 450 and with the classified VLAN signature of modified packet 450, as indicated by reference number 460”; col. 9, lines 14-30, “MAC address field 500 may include the source MAC address of modified packet 420 (e.g., received on promiscuous port 310), the source MAC address of modified packet 450 (e.g., received on isolated port 320), and/or the source MAC address of modified packet 480 (e.g., received on community port 330)”);
Kommula does not specifically disclose temporarily storing the ingress subdomain as metadata that is associated with the packet; extracting the stored ingress subdomain from the stored metadata; and resetting the forwarding domain of the packet to the extracted ingress subdomain.
However, Rajan discloses temporarily storing the ingress subdomain as metadata that is associated with the packet (¶0011, “receives the user packets and determines SFC Identifiers (IDs) and SFC metadata. The data classifier inserts the SFC IDs and metadata in Virtual Local Area Network (VLAN) ID data fields of the user data packets”; ¶0018, “For ingress user data packets, data classifiers 130 identify and insert SFC IDs and possibly metadata into the Virtual Local Area Network Identifier (VLAN ID) data fields of the user data packets…The data classifier then inserts the SFC ID and media format metadata in the VLAN ID data fields of these user data packets”; ¶0023, “Data classifiers 130 insert the SFC IDs and any SFC metadata into the VLAN ID data fields of the ingress user data packets”); extracting the stored ingress subdomain from the stored metadata (¶0011, “The data forwarder identifies the SFC IDs and metadata from the VLAN ID data fields. The data forwarder selects network functions based on the SFC IDs and metadata”; ¶0032, “Data forwarder 140 identifies the SFC ID and metadata from the VLAN ID data fields of the user data packet”). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Kommula to include temporarily storing the ingress subdomain as metadata that is associated with the packet; extracting the stored ingress subdomain from the stored metadata, as taught by Rajan because it would allow the ingress controller to efficiently route, secure, and manage traffic, thereby quickly routing traffic to the correct internal service (Rajan; ¶0025; ¶0045; ¶0051).
CISCO, on the other hand, discloses resetting the forwarding domain of the packet to the extracted ingress subdomain (Fig. 1; Page 2, section: About VLAN Mapping: “All forwarding operations on Catalyst 9000 series switch are performed using S-VLAN and not C-VLAN information because the VLAN ID is mapped to the S-VLAN on ingress…On an interface configured for VLAN mapping, the specified C-VLAN packets are mapped to the specified S-VLAN when they enter the port. Symmetrical mapping to the customer C-VLAN occurs when packets exit the port”; Page 3, section: One-to-One VLAN Mapping, “One-to-one VLAN mapping occurs at the ingress and egress of the port and maps the customer C-VLAN ID in the 802.1Q tag to the service-provider S-VLAN ID”; Page 3, section: Selective Q-in-Q, “At the egress, the S-VLAN ID is removed and the customer VLAN-ID is retained on the packet”; Page 7, section: Example, “In the previous example, at the ingress of the service-provider network, VLAN IDs 2 to 6 in the customer network are mapped to VLANs 101 to 105, in the service provider network. At the egress of the service provider network, VLANs 101 to 105 in the service provider network are mapped to VLAN IDs 2 to 6, in the customer network”; Page 9, section: Example, “This example shows how to configure selective QinQ mapping on the port so that traffic with a C-VLAN ID of 2 to 5 enters the switch with an S-VLAN ID of 100”). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Kommula to include resetting the forwarding domain of the packet to the extracted ingress subdomain, as taught by CISCO because it would enable the ingress controller to dynamically route traffic to specific internal services based on the subdomain, thereby improving the safety and speed of changes (CISCO; Pages 5-9).
As to claim 3, Kommula discloses the method of claim 1, further comprising: storing the private VLAN domain as part of the metadata (col. 1, line 59 – col. 2, line 36, “assigning, by the network device, a primary VLAN signature to the first packet, and storing, by the network device, a media access control (MAC) address and the classified VLAN signature of the first packet in a single MAC address table”; col. 2, line 66 – col. 3, line 12, “classify packets received by private VLAN ports based on the types of ports (e.g., promiscuous, community, or isolated) receiving the packets. The systems and/or methods may also apply MAC address learning to all private VLAN ports, and may store the learned MAC addresses in a single primary VLAN MAC address table”).
As to claim 5, Kommula discloses the method of claim 1, further comprising: subsequent to performing the VLAN mapping lookup, performing a learning lookup to identify the ingress port associated with the forwarding domain and a source media access control (MAC) address in the packet (Fig. 7, 710-760; col. 3, lines 1-12, “The systems and/or methods may also apply MAC address learning to all private VLAN ports, and may store the learned MAC addresses in a single primary VLAN MAC address table (e.g., rather than in multiple tables). The systems and/or methods may also utilize a destination MAC lookup (e.g., of the primary VLAN MAC address table) to determine whether to forward a packet to a located MAC address or to treat the packet as unknown unicast traffic”; col. 6, lines 36-55, “perform destination MAC address lookup for a packet (e.g., so that network device 110-2 can forward the packet to the appropriate device in network 100). For example, primary VLAN MAC address table 300 may include every MAC address learned on any of the private VLAN ports (e.g., promiscuous port 310, isolated port 320, community ports 330, and/or trunk port 340)”; col. 10, lines 9-29, “If lookup component 600 finds an entry (e.g., in MAC address field 500) of primary VLAN MAC address table 300 that matches the destination MAC address of the packet, lookup component 600 may deem the entry qualified (e.g., for forwarding the packet) if the MAC address signature (e.g., provided in MAC address signature field 510) of the entry is the same as the packet's classified VLAN signature”).
As to claim 6, Kommula discloses the method of claim 5, further comprising: performing a forwarding lookup to identify an egress port associated with the forwarding domain and a destination media access control (MAC) address in the packet (col. 3, lines 1-12, “The systems and/or methods may also apply MAC address learning to all private VLAN ports, and may store the learned MAC addresses in a single primary VLAN MAC address table (e.g., rather than in multiple tables). The systems and/or methods may also utilize a destination MAC lookup (e.g., of the primary VLAN MAC address table) to determine whether to forward a packet to a located MAC address or to treat the packet as unknown unicast traffic”; col. 6, lines 36-55, “perform destination MAC address lookup for a packet (e.g., so that network device 110-2 can forward the packet to the appropriate device in network 100). For example, primary VLAN MAC address table 300 may include every MAC address learned on any of the private VLAN ports (e.g., promiscuous port 310, isolated port 320, community ports 330, and/or trunk port 340)”; col. 10, lines 9-29, “If lookup component 600 finds an entry (e.g., in MAC address field 500) of primary VLAN MAC address table 300 that matches the destination MAC address of the packet, lookup component 600 may deem the entry qualified (e.g., for forwarding the packet) if the MAC address signature (e.g., provided in MAC address signature field 510) of the entry is the same as the packet's classified VLAN signature”).
As to claim 7, it is rejected for the same reasons set forth in claims 1 and 6 above.
As to claims 8 and 16, they are rejected for the same reasons set forth in claim 1 above. In addition, Kommula discloses a VLAN filtering stage configured to filter the data packet based on the ingress subdomain (col. 3, lines 2-12, “classify packets received by private VLAN ports based on the types of ports (e.g., promiscuous, community, or isolated) receiving the packets”; col. 4, lines 46-60, “a packet received on a community port may be classified to be associated with secondary community VLAN 150, and a MAC address learned on a community port may be installed in multiple MAC address tables associated with primary VLAN 140 and secondary community VLAN 150”; col. 4, line 61 – col. 5, line 8, “a packet received on an isolated port may be classified to be associated with secondary isolated VLAN 160, and a MAC address learned on an isolated port may be installed in multiple MAC address tables associated with primary VLAN 140 and isolated community VLAN 160”).
As to claim 9, Kommula discloses the method of claim 6, wherein the forwarding lookup is performed before or in parallel with the learning lookup (col. 3, lines 1-12, “The systems and/or methods may also apply MAC address learning to all private VLAN ports, and may store the learned MAC addresses in a single primary VLAN MAC address table (e.g., rather than in multiple tables). The systems and/or methods may also utilize a destination MAC lookup (e.g., of the primary VLAN MAC address table) to determine whether to forward a packet to a located MAC address or to treat the packet as unknown unicast traffic”; col. 6, lines 36-55, “perform destination MAC address lookup for a packet (e.g., so that network device 110-2 can forward the packet to the appropriate device in network 100). For example, primary VLAN MAC address table 300 may include every MAC address learned on any of the private VLAN ports (e.g., promiscuous port 310, isolated port 320, community ports 330, and/or trunk port 340)”; col. 10, lines 9-29, “If lookup component 600 finds an entry (e.g., in MAC address field 500) of primary VLAN MAC address table 300 that matches the destination MAC address of the packet, lookup component 600 may deem the entry qualified (e.g., for forwarding the packet) if the MAC address signature (e.g., provided in MAC address signature field 510) of the entry is the same as the packet's classified VLAN signature”).
As to claim 10, Kommula discloses the method of claim 5, further comprising: conveying the packet through one or more intermediate packet processing pipeline stages after performing the VLAN mapping lookup and before performing the learning lookup (Figs. 4 and 6-7; col. 13, line 11 – col. 14, line 3).
As to claim 13, it is rejected for the same reasons set forth in claim 1 above.
As to claim 14, it is rejected for the same reasons set forth in claims 1 and 11 above.
As to claim 15, Kommula discloses the method of claim 14, further comprising: performing the learning lookup operation to identify the ingress port based on the private VLAN domain and a source address of the data packet; and performing the forwarding lookup operation to identify an egress port based on the private VLAN domain and a destination address of the data packet (Fig. 7, 710-780; col. 3, lines 1-12, “The systems and/or methods may also apply MAC address learning to all private VLAN ports, and may store the learned MAC addresses in a single primary VLAN MAC address table (e.g., rather than in multiple tables). The systems and/or methods may also utilize a destination MAC lookup (e.g., of the primary VLAN MAC address table) to determine whether to forward a packet to a located MAC address or to treat the packet as unknown unicast traffic”; col. 6, lines 36-55, “perform destination MAC address lookup for a packet (e.g., so that network device 110-2 can forward the packet to the appropriate device in network 100). For example, primary VLAN MAC address table 300 may include every MAC address learned on any of the private VLAN ports (e.g., promiscuous port 310, isolated port 320, community ports 330, and/or trunk port 340)”; col. 10, lines 9-29, “If lookup component 600 finds an entry (e.g., in MAC address field 500) of primary VLAN MAC address table 300 that matches the destination MAC address of the packet, lookup component 600 may deem the entry qualified (e.g., for forwarding the packet) if the MAC address signature (e.g., provided in MAC address signature field 510) of the entry is the same as the packet's classified VLAN signature”).
As to claim 16, it is rejected for the same reasons set forth in claim 8 above.
As to claim 19, it is rejected for the same reasons set forth in claim 1 above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Biswas et al. (US 2012/0287936), EVANS et al. (US 2017/0195213), Fitzgerald et al. (US 2014/0355409) disclose method and apparatus for debugging private VLAN the method includes determining at a first network device in a Connectivity Fault Management (CFM) domain wherein a primary Virtual Local Area Network (VLAN) includes promiscuous ports and wherein a secondary VLAN includes isolated ports, whether a CFM packet is received on a primary VLAN or a secondary VLAN.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JUNGWON CHANG whose telephone number is (571)272-3960. The examiner can normally be reached 9AM-5:30PM.
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, GLENTON BURGESS can be reached at (571)272-3949. 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.
/JUNGWON CHANG/Primary Examiner, Art Unit 2454 May 7, 2026
Prosecution Insights