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 .
Detailed Action
This Office Action is in response to communications filed 1/20/2026.
Claims 1-3, 5-10, 12-17 and 19-20 are pending.
Claims 4, 11, 18 were cancelled previously.
Continued Examination Under 37 CFR 1.114
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 01/20/26 has been entered.
Response to Arguments
Applicant's arguments filed 01/20/26 have been fully considered but they are not persuasive.
In the response filed, applicant argues in substance that:
In the combined system, the behavior would be: When a packet with a VLAN tag that is not yet provisioned on a server-facing port arrives at access switch 40, packet forwarding engine 52A maps the VLAN tag to shared VLAN, creates an entry in MAC table 56A keyed by shared VLAN, the source MAC address, and the ingress port, and notifies control unit 42. If control unit 42 determines that this VLAN is allowed on that port, it installs an entry for that VLAN in VLAN table 55A (or VLAN table 60) so that subsequent packets with that VLAN tag on that port are associated with a real VLAN index and forwarded based on entries in MAC tables 56A and 56B, as described in the cited portions of PINNAMRAJU. If ZHANG's techniques are also implemented, a component like AP 112 can observe ARP and DHCP packets on a VLAN, extract device IP addresses and subnet masks from those packets, and store per-device entries in a discovery VLAN table that include a VLAN identifier, IP address, subnet mask, MAC address, and status fields, as described in 18, 19, 33, 34, 35, 46, and 47 of ZHANG.
In the purported combination, the IP address and subnet mask values obtained in the manner of ZHANG remain per-device entries in a discovery VLAN table associated with AP 112. They do not become "an Internet protocol (IP) address and a subnet mask of the new VLAN" itself, and they are not stored as part of any "new VLAN interface" object that is configured and deployed by the processor in response to the first packet for the new VLAN. What is configured on the VLAN side remains VLAN membership and forwarding information in VLAN table 55A and MAC tables 56A and 56B of access switch 40. What is configured on the IP/subnet side remains per-device records in a discovery VLAN table of AP 112. There is no step in the combined teachings where the processor, in response to receipt of a packet for a VLAN that is not yet provisioned on a port, identifies an IP address and subnet mask "of the new VLAN" from that packet and then configures and deploys "a new VLAN interface, including the IP address and the subnet mask for the new VLAN within the memory; and deploys the new VLAN interface on the network connection port," as claim 1 expressly requires.
Stated differently, ZHANG teaches identifying a device's IP address and subnet mask and storing those values in entries that also include a VLAN identifier and MAC address, for use by AP 112 in controlling device communications. PINNAMRAJU teaches that when access switch 40 detects that a VLAN is not yet configured on a port, packet forwarding engines 52 and control unit 42 add VLAN and MAC information to VLAN table 55A and MAC tables 56A and 56B. Combining these teachings yields a device that both auto-provisions VLAN/MAC entries (using access switch 40, packet forwarding engines 52A and 52B, control unit 42, VLAN table 55A, and MAC tables 56A, 56B) and maintains a per-device discovery VLAN table (using AP 112 and its discovery table). That is materially different from the claim, in which the processor identifies "an Internet protocol (IP) address and a subnet mask of the new VLAN from a header of the packet" and uses those values to "automatically configure a new VLAN interface, including the IP address and the subnet mask for the new VLAN within the memory; and deploy the new VLAN interface on the network connection port."
Furthermore, Applicant amends claim 1 to recite "automatically configure a new VLAN interface, including the IP address and the subnet mask for the new VLAN, wherein the new VLAN interface is based on a VLAN identifier of the new VLAN obtained from a VLAN identifier field of a header of the packet and on the IP address and the subnet mask of the new VLAN obtained from an Internet protocol (IP) header of the packet, and is stored in the memory as an entry for the new VLAN in a table that stores VLAN data including at least the IP address and the subnet mask of the new VLAN ." Applicant submits that neither PINNAMRAJU nor ZHANG, nor the combination thereof, discloses or suggests this feature (remarks, pg. 10-12).
In response to arguments above, examiner respectfully disagrees.
In the response filed, it appears that applicant is addressing the prima facie case of obviousness [based on the combination of references] by attacking the references individually and/or separately.
MPEP 2145 (IV) dearly sets forth: One cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., Inc., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
The examiner recognizes that obviousness may be established by combining or modifying the teachings of the prior art to produce the claimed invention where there is some teaching, suggestion, or motivation to do so found either in the references themselves or in the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988), In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992), and KSR International Co. v. Teleflex, Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007).
In this case, Pinnamraju explicitly discloses a technique for automatically provisioning of virtual local area networks (VLANs) on server facing ports of access switches include in a data center network. The technique includes the steps of receiving data packet with unknown or new VLAN tag or ID and source MAC address on port of access switch, determining whether the VLAN is provisioned on port based on VLAN table, and if VLAN IS NOT provisioned (i.e. configured) for the received unknown/new VLAN (i.e. new VLAN), then the switch provisions (i.e. configures or implements) the new VLAN on port, i.e. implements new VLAN interface and deploys the new VLAN interface for data traffic filtering.
For example: See fig. 6.
PNG
media_image1.png
722
536
media_image1.png
Greyscale
More specifically, upon receiving the data packet on the port on IFC 58A of PFE 52A, the PFE 52 A first looks up the VLAN tag of the received data packet in VLAN table 55A to determine whether the VLAN is provisioned or not. Based on VLAN table having no entries for the VLAN tag and port number, PFE may classify the VLAN as not being provisioned. If the VLAN is not provisioned on the receiving port, then PFE triggers the VLAN auto-provisioning operation in access switch 40. During the auto-provisioning, PFE 52 A maps the VLAN tag to a shared VLAN index for all UNKNOWN VLANS on port, and INSTALLS AN ENTRY INTO VLAN table 55A that includes VLAN TAG, the port number of the receiving port and the shared VLAN index, see col. 10 L5-38, and thereafter sends authorization request.
After successful authorization of provisioning VLAN, the control unit 42 provisions the VLAN on the receiving port on IFCs 58A of PFE 52A. For example, control unit programs forwarding information for the VLAN on the receiving port into FIB 54A of PFE (VLAN Interface is configured or programmed) and further updates the entry in VLAN table 55A with the actual VLAN index. In this way, subsequent data packet received for the same VLAN on the same port will be classified using VLAN table 55A as being known with an assigned VLAN index, see col. 11 L18-37.
Thus, it is clear that Pinnamraju teaches automatically configuring a new VLAN interface based on VLAN identifier of the new VLAN that is obtained from a VLAN identifier field of a header of the packet and is stored in VLAN table (table is inherently stored on memory of access switch) that stores VLAN data. The provisioned VLAN is then deployed for use, e.g. see step 88 of fig. 6.
PNG
media_image2.png
318
438
media_image2.png
Greyscale
Examiner agrees that in this technique, Pinnamraju does not teach obtaining IP address and subnet mask for the unknown or new VLAN during auto-provisioning from the Internet Protocol (IP) header of the packet and storing this information in VLAN table that is stored in a memory, which stores VLAN data, thus configuring a new VLAN interface including the IP address and the subnet mask for the new VLAN in a memory.
However, even without secondary reference of Zhang, it is well within the level of ordinary skill in the art to modify Pinnamraju and incorporate adding entries and information such as IP addresses, subnet mask, TTL, size limit, etc. into a VLAN table that is stored in a memory of the switch.
Zhang is relied upon to show that obtaining an IP address and subnet mask from the fields of the IP packet, regardless whether for new or unknown or known or existing VLAN and establishing a discovery/VLAN table , is a well-known functionality.
Therefore, it would have been obvious to a person of ordinary skilled in the art to modify Pinnamraju in view of Zhang to obtain IP address, subnet mask, MAC address, port information, etc. from the received data packet in addition to obtaining VLAN ID or tag (as in Pinnamraju) and auto-provision the VLAN interface by programming these set of information in a VLAN table which is stored in a memory.
The combination does result in auto-provisioning of a new VLAN interface on an access switch which includes programming the entries in a VLAN table including IP address, subnet mask, VLAN ID or tag, for the new or unknown VLAN indicated in the received data packet.
Furthermore, Zhang teaches establishing discovery/whitelist/VLAN table by auto learning the IP addresses of a set of essential devices of the VLAN from the initial data packets. The AP when it receives the packets, the AP identifies the packets based on the header, and learns IP addresses and its corresponding subnets from the fields of the header, e.g. [0018, 0027]. The AP then stores these IP addresses and subnet information in corresponding entries in a local data structure, which can operate as whitelist of IP addresses that are allowed to exchange intra-VLAN traffic. The data structure is referred to as discovery table, e.g. [0033].
PNG
media_image3.png
646
468
media_image3.png
Greyscale
PNG
media_image4.png
476
670
media_image4.png
Greyscale
In other words, Zhang teaches a technique of learning IP addresses, VLANs associated with client, subnet, mac address, etc. and configuring the discovery/whitelist/VLAN table which stores entries for storing VLAN data including IP address and the subnet mask of the VLAN.
Therefore, it would have been obvious to a person of ordinary skilled in the art to modify Pinnamraju in view of Zhang to employ the technique taught by Zhang to obtain IP address, subnet mask, MAC address, port information, etc. from the received data packet and generate and/or complete VLAN table with additional information such as IP address, subnet mask, etc. The motivation for doing so is set forth below in the rejection.
Thus, the combination will result in auto-provisioning a new VLAN interface on an access switch which includes programming the entries in a VLAN table including IP address, subnet mask, VLAN ID or tag, for the new or unknown VLAN indicated in the received data packet based on Pinnamraju and Zhang.
For the at least these reasons, the rejection is maintained.
Claim Interpretations
The term “processor” in claim 1 is interpreted to cover central processing unit (CPU), e.g. see specification [0028]. As such, the claim 1 is interpreted to cover physical apparatus comprising physical processor such as CPU and is not interpreted as software per se. However, applicant is advised to include components such as memory or CPU to clearly set forth the statutory category of claim 1.
Claim Rejections - 35 USC § 103
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 1-2, 5, 8-9, 12, 15-16 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Pinnamraju et al. (Hereinafter Pinnamraju, US 9,838,337 B1) in view of Zhang et al. (hereinafter Zhang, US 2024/0223532 A1).
As per claim 1, Pinnamraju discloses an apparatus (fig. 3) comprising:
a memory (col. 7 L65 to col. 8 L5);
a plurality of network connection ports (fig. 2-3: Access Switch with routing, col. 7 L41-65); and
a processor configured to (col. 7 L65 to col. 8 L5):
establish a connection with a local area network (LAN) network via the plurality of network connection ports (col. 7 L41-65, fig. 2),
receive a packet via a network connection port from among the plurality of network connection ports (col. 7 L16-31, col. 9 L43-44-61),
detect that the packet is of a new virtual local area network (VLAN) (col. 9 L43-58: detect data packets of unknown vlan on the port, col. 9 L59 to col. 10 L44), and
automatically configure a new VLAN interface including the source MAC address, VLAN tag and port number of receiving port for the new VLAN in a memory, wherein the new VLAN interface is based on a VLAN identifier of the new VLAN obtained from a VLAN identifier field of a header of the packet (data packet inherently comprises header and payload, wherein the header includes various fields such as source address, destination address, etc.) and is stored in the memory as an entry for the new VLAN in a table that stores VLAN data including at least the VLAN tag and port number and deploy the new VLAN interface on the network connection port (fig. 6 step #80-88, col. 9L43 to col. 10 L44: VLAN auto-provisioning at the access switch by installing entries in the VLAN table including VLAN tag which is stored in the memory, col. 11 L18-37: subsequent packets processing using provisioned/new VLAN. Fig. 3: VLAN table 55A stored in an access switch 40, fig. 6: receiving data packet comprising VLAN tag).
However, Pinnamraju does not explicitly teach identifying an Internet protocol (IP) address and a subnet mask of the new VLAN from a header of the packet and automatically configuring a new VLAN interface including the IP address and the subnet mask for the new VLAN, wherein the new VLAN interface is based on the IP address and the subnet mask of the new VLAN obtained from an Internet Protocol (IP) header of the packet (i.e. automatically configuring VLAN table by adding this information from the data packet).
Zhang, from the same field of endeavor, explicitly teaches identifying an Internet protocol (IP) address and a subnet mask of a VLAN from a header of the packet (fig. 4A: step #410, fig. 4B: step #460, [0018-0019]: AP learns IP addresses from the fields of the packet, [0033]: Auto learn IP addresses to efficiently populate discovery/vlan table, fig. 2A, [0034-0035]: obtain IP addresses and subnet mask from the set of fields of a packet and store them in respective entries of the discovery table, [0046-0047]), and automatically configuring the VLAN interface including the IP address and the subnet mask for the VLAN, wherein the VLAN interface is based on the IP address and the subnet mask of the VLAN obtained from an Internet protocol (IP) header of the packet and is stored in the memory as an entry in a table that stores VLAN data including at least the IP address and the subnet mask of the VLAN (Fig. 4A: 408, 410, [0033-0035], [0046-0047]: To efficiently populate discovery/vlan table, auto learn IP addresses and store them in the discovery table comprising VLAN entry, IP address entries, subnet mask entries, MAC address entries, age entries and flags).
Therefore, it would have been obvious to a person of ordinary skilled in the art before the effective filing date of the claimed invention to modify Pinnamraju in view of Zhang in order to identify an Internet protocol (IP) address and a subnet mask of the new VLAN from a header of the packet and automatically configure a new vlan interface including the IP address and the subnet mask for the new vlan within the memory.
One of ordinary skilled in the art would have been motivated in order to auto-provision virtual area networks (VLANs) (Pinnamraju: col. 1 L40-67) and efficiently filter traffic within a virtual area network (VLAN) (Zhang: [0020, 0033]).
As per claim 2, Pinnamraju discloses the apparatus of claim 1 as set forth above, wherein the processor is configured to detect that an Institute of Electrical and Electronics Engineers (IEEE) 802.1q header within the packet contains a new VLAN identifier based on a list of existing VLAN identifiers stored in the memory (col. 9 L59 to col. 10 L44: VLAN tag in the header is used to check the VLAN table for entry. Note: The IEEE 802.1Q protocol is the standard for VLAN tagging in Ethernet networks. As such, the use of VLAN tags in the prior art is by inherently using the IEEE 802.1Q protocol).
As per claim 5, Pinnamraju discloses the apparatus of claim 1 as set forth above, wherein the processor is configured to assign the new VLAN to a media access control (MAC) address (col. 10 L30-44: Entry created in MAC table, fig. 5).
As per claim 8, Pinnamraju discloses a method comprising:
establishing a connection with a local area network (LAN) network via a routing apparatus comprising a plurality of network connection ports (col. 7 L41-65, fig. 2-3: Access Switch with routing function connected to servers in data center);
receiving a packet via a network connection port from among the plurality of network connections ports of the routing apparatus (col. 7 L16-31, col. 9 L43-44-61);
detecting that the packet is of a new virtual local area network (VLAN) (col. 9 L43-58: detect data packets of unknown vlan on the port, col. 9 L59 to col. 10 L44); and
automatically configuring a new VLAN interface including a MAC address and a vlan tag for new VLAN in a memory by in response to detecting that the packet is of the new virtual local area network (VLAN), obtaining, a VLAN identifier of the new VLAN from a VLAN identifier field of a header of the packet and creating an entry in the memory for the new VLAN in a table that stores VLAN data including at least the VLAN tag, mac address (fig. 6 step #80-88, col. 9L43 to col. 10 L44: VLAN auto-provisioning at the access switch by installing entries in the VLAN table including VLAN tag which is stored in the memory, col. 11 L18-37: subsequent packets processing using provisioned/new VLAN. Fig. 3: VLAN table 55A stored in an access switch 40, fig. 6: receiving data packet comprising VLAN tag);
and deploying the new VLAN interface at the network connection port (fig. 6 step #86, col. 9L43 to col. 10 L44: VLAN auto-provisioning at the access switch, col. 11 L18-37: subsequent packets processing using provisioned VLAN).
However, Pinnamraju does not explicitly teach identifying an Internet protocol (IP) address and a subnet mask of the new VLAN from a header of the packet and automatically configuring a new VLAN interface including the IP address and the subnet mask for the new VLAN, obtaining the IP address and the subnet mask of the VLAN from an IP header of the packet and creating an entry in the memory for the new VLAN in a table that stores VLAN data including at least the IP address and the subnet mask of the VLAN.
Zhang, from the same field of endeavor, explicitly teaches identifying an Internet protocol (IP) address and a subnet mask of a VLAN from a header of the packet [fig. 4A: step #410, fig. 4B: step #460, [0018-0019], [0033]: Auto learn IP addresses to efficiently populate discovery/vlan table, fig. 2A, [0034-0035]: obtain IP addresses and subnet mask from the set of fields of a packet and store them in respective entries of the discovery table, [0046-0047]], and automatically configuring a VLAN interface including the IP address and the subnet mask for the VLAN, obtaining the IP address and the subnet mask of the VLAN from an IP header of the packet and creating an entry in the memory for the VLAN in a table that stores VLAN data including at least the IP address and the subnet mask of the VLAN [Fig. 4A: 408, 410, [0033-0035], [0046-0047]: To efficiently populate discovery/vlan table, auto learn IP addresses and store them in the discovery table comprising VLAN entry, IP address entries, subnet mask entries, MAC address entries, age entries and flags, fig. 6, fig. 3].
Therefore, it would have been obvious to a person of ordinary skilled in the art before the effective filing date of the claimed invention to modify Pinnamraju in view of Zhang in order to identify an Internet protocol (IP) address and a subnet mask of the new VLAN from a header of the packet and automatically configure a new vlan interface including the IP address and the subnet mask for the new vlan within the memory that stores the vlan table.
One of ordinary skilled in the art would have been motivated in order to auto-provision virtual area networks (VLANs) (Pinnamraju: col. 1 L40-67) and efficiently filter traffic within a virtual area network (VLAN) (Zhang: [0020, 0033]).
As per claims 9, 12, 15-16 and 19, they do not teach or further define over the limitations in claims 1-2, 5 and 8. Therefore, claims 9, 12, 15-16 and 19 are rejected for the same reasons as set forth in claims 1-2, 5 and 8.
Claim(s) 3, 10 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Pinnamraju et al. (Hereinafter Pinnamraju, US 9,838,337 B1) in view of Zhang et al. (hereinafter Zhang, US 2024/0223532 A1) and further in view of Squire et al. (hereinafter Squire, US 2013/0144998 A1).
As per claim 3, Pinnamraju-Zhang discloses the apparatus of claim 1 as set forth above.
However, Pinnamraju-Zhang does not teach the processor being further configured to verify that the network connection port is enabled for automatic VLAN configuration prior to automatically configuring the VLAN interface for the new VLAN.
Squire, from a same field of endeavor, teaches a process of verifying that a network port is enabled for one of the various functions prior to configuring the port to perform the one or more functions ([0094-95]: acfg register port for learning, [0098], [26], [54-60], [0073-0076]: enabling ports for various function including autoconfig process, [0044]: test to see if the new device is configured to support or enabled for the Autoconfig MIB, [0094-0095]: enabling and disabling protocols on ports).
Therefore, it would have been obvious to a person of ordinary skilled in the art before the effective filing date of the claimed invention to modify Pinnamraju-Zhang in view of Squire in order to verify that the network connection port is enabled to perform the automatic VLAN configuration prior to performing autoconfig process.
One of ordinary skilled in the art would have been motivated in order to ensure proper port configuration and void delays.
As per claims 10 and 17, they do not teach or further define over the limitations in claim 7. Therefore, claims 10 and 17 are rejected for the same reasons as set forth in claim 7.
Claim(s) 6, 13 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Pinnamraju et al. (Hereinafter Pinnamraju, US 9,838,337 B1) in view of Zhang et al. (hereinafter Zhang, US 2024/0223532 A1) and further in view of O’Riordan (US 7,227,838 B1).
As per claim 6, Pinnamraju-Zhang discloses the apparatus of claim 1 as set forth above.
However, Pinnamraju-Zhang does not teach the processor being configured to select a primary link and a secondary link from among a plurality of links and assign the primary link and the secondary link to the new VLAN.
O’Riordan, from the same field of endeavor, teaches processor being configured to select a primary link and a secondary link from among a plurality of links and assign the primary link and the secondary link to the new VLAN (col. 4 L16-33: redundant links including from designated router [primary] and non-designated router [secondary], fig. 2b: Each VLAN is associated with link from designated router and non-designated router forming pairs, col. 9 L41-56, col. 10 L35-67).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of claimed invention to modify Pinnamraju in vies of O’Riordan in order to assign primary link and secondary link to the new VLAN.
One of ordinary skilled in the art would have been motivated because it would have provided redundant data forwarding or routing capabilities in an event of failures (O’Riordan: col. 2 L29-50).
As per claims 13 and 20, they do not teach or further define over the limitations in claims 6. Therefore, claims 13 and 20 are rejected for the same reasons as set forth in claims 6.
Claim(s) 7 and 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Pinnamraju et al. (Hereinafter Pinnamraju, US 9,838,337 B1) in view of Zhang et al. (hereinafter Zhang, US 2024/0223532 A1) in view of Perlman (US 5,844,902) and further in view of Squire et al. (hereinafter Squire, US 2013/0144998 A1).
As per claim 7, Pinnamraju-Zhang discloses the apparatus of claim 1 as set forth above.
However, Pinnamraju-Zhang does not teach the processor being further configured determine that a different network connection port from among the plurality of network connection ports is connected to a LAN and disable automatic VLAN configuration at the different network connection port in response.
Perlman, from the same field of endeavor, teaches the process of determining whether two or more ports of a bridge having three or more ports are connected to the same LAN (col. 1 L63-65, col. 18 L55-56).
Therefore, it would have been obvious to a person of ordinary skilled in the art before the effective date of the claimed invention to modify Pinnamraju in view of Perlman in order to determine that a different network connection port from the ports of a bridge or switch or router is connected to a same LAN.
One of ordinary skilled in the art would have been motivated to ensure that one or more ports that are connected to a same LAN are configured correctly and/or avoid misconfigurations.
However, Pinnamraju-Zhang-Perlman does not teach the process of disabling automatic VLAN configuration at the different network connection port in response.
Squire, from the same field of endeavor, teaches the process of disabling autoconfig feature or one or more protocols on the particular port ([0094-0095]: enabling and disabling protocols on ports, [0073, 0076]: enabling ports for various function including Autoconfig process).
Therefore, it would have been obvious to a person of ordinary skilled in the art before the effective filing date of the claimed invention to modify Pinnamraju-Zhang-Perlman in view of Squire in order to disable automatic vlan configuration at the different network connection of a same LAN.
One of ordinary skilled in the art would have been motivated in order to avoid VLAN configuration conflicts or misconfigurations for the same LAN network.
As per claim 14, it does not teach or further define over the limitations in claim 7. Therefore, claim 14 is rejected for the same reasons as set forth in claim 7.
Pertinent Prior Arts
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 11,863,983 – Provisioning of VLAN IDS in 5G Systems.
US 10,990,784 B2 - Context-Aware Security Self-Assessment.
US 10,666,461 B2 – VLAN Reflection
US 2015/0023349 A1 – Packet Discovery and Learning for VLAN Provisioning.
US 2011/0126278 A1 - Local Area Networks
US 7,606,232 B1 – Dynamic VLAN Interface Configuration
US 7,554,994 B1 – Integrated Router Switch for auto creating IEEE 802.1Q VLAN trunks
US 7,546,458 B1 – Method for organizing virtual networks while optimizing security
US 7,356,841 B2 – Server and Method for providing specific network services [IEEE 802.1Q standards].
US 7,286,491 B1 – VLAN membership registration protocol [Discloses Auto Config at the bridge]
US 2007/0071017 A1 – Automatically detecting, creating and configuring VLANs
US 7,188,364 B2 – Personal Virtual Bridged LANs.
CN 105684355 A – Automatically Configuring Virtual Router
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KAMAL B DIVECHA whose telephone number is 571-272-5863. The examiner can normally be reached IFP Normal Hours M-F: 8am-4.30pm 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, Colleen Fauz can be reached at 5712721667. 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.
KAMAL B. DIVECHA
Primary Patent Examiner
Art Unit 2453
/KAMAL B DIVECHA/Supervisory Patent Examiner, Art Unit 2453
Prosecution Insights