Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 1/31/2024 and 1/06/2026 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-3, 5-9, and 14 are rejected under 35 U.S.C. 102 (a)(2) as being anticipated by Hsu et al. (US 20240098492 A1, hereinafter, Hsu).
Regarding Claim 1, Hsu discloses, a non-transitory machine-readable storage medium ("...The passphrase may be preinstalled or preconfigured on electronic device 110-1 and may be stored in memory that is accessible by AAA server 130..."[¶0084]) comprising instructions that upon execution ("...The dataplane may be implemented using virtual machines that are executed by multiple cores in one or more processors (which is sometimes referred to as a ‘virtual dataplane’), which allows the dataplane to be flexibly scaled and dynamically reconfigured..." [¶0095]) cause a system to:
initiate an authentication procedure for a client device ("FIG. 13 presents a flow diagram illustrating an example of a method 1300 for selectively providing secure access, which may be performed by an electronic device, such as AAA server 130 in FIG. 1. During operation, the electronic device may receive an access request (operation 1310) associated with a computer, where the access request includes one or more authentication parameters associated with a user..." [¶0242]);
determine a group of client devices including the client device based on information associated with the client devices ("In order to identify which electronic devices should form a single PAN, each hotel guest may be provided with a passphrase (such as a PSK, a DPSK or another type of digital certificate). For example, the passphrase may include a group DPSK passphrase or a group passphrase. Note that each device having a DPSK passphrase (or a group of electronic devices sharing a group DPSK passphrase) may be uniquely authenticated. Because they can be authenticated, the network can apply a policy (e.g., a VLAN assignment) suitable for that electronic device (or group of electronic devices, as the case may be)..." [¶0172]); and
assign, to the client device, a community identifier as part of the authentication procedure, wherein the community identifier identifies the group of client devices that are able to communicate with one another over a virtual network ("In order to further illustrate operation of a guest's PAN, end device 620-3, which belongs to the guest assigned to location 622-2, may connect to or associate with access point 618-2. As a result of the DPSK authentication, access point 618-2 may be informed that end device 620-3 is in group identifier 1, which is the group assigned to the guest staying in location 622-1..." [¶0157], see also, "In some embodiments, access points 618 in the network may be configured to use IEEE 802.1ad (which is sometimes referred to as QinQ). Notably, an outer VLAN or a service VLAN (S-VLAN) may be configured to have the same VLAN identifier as the Ethernet-switching network. AAA server 612 may dynamically assign the inner VLAN or C-VLAN. Each PAN may have an assigned unique C-VLAN identifier. " [¶0165], see also, "The AAA server may also return the group identifier. The group identifier may be the PAN identifier to which the guest's end devices are assigned..."[ ¶0207]).
Regarding Claim 2, Hsu discloses the non-transitory machine-readable storage medium of claim 1.
Hsu also discloses, wherein the community identifier comprises a personal area network (PAN) identifier that identifies a PAN including the group of client devices ("In order to further illustrate operation of a guest's PAN, end device 620-3, which belongs to the guest assigned to location 622-2, may connect to or associate with access point 618-2. As a result of the DPSK authentication, access point 618-2 may be informed that end device 620-3 is in group identifier 1, which is the group assigned to the guest staying in location 622-1..." [¶0157], see also, "The AAA server may also return the group identifier. The group identifier may be the PAN identifier to which the guest's end devices are assigned. The network may forward frames from a group member only to other group members or toward the Internet...[ ¶0207]).
Regarding Claim 3, Hsu discloses the non-transitory machine-readable storage medium of claim 1.
Hsu also teaches, wherein the instructions upon execution cause the system to:
determine the community identifier based on a shared secret assigned to the group of client devices, the shared secret for use in secure communications between the client devices of the group of client devices and a network device ("...This access acceptance message may be intended for electronic device 110-1 and may include information for establishing secure access of electronic device 110-1. For example, the access acceptance message may include: an identifier of electronic device 110-1, a tunnel type, a tunnel medium type, a tunnel privilege group identifier, a filter identifier, and the username." [¶0091], see also, "In some embodiments, the secure access may be implemented using a virtual network associated with the location (such as a virtual network for the PAN), and the information in the access acceptance message may allow electronic device 110-1 to establish secure communication with the virtual network..." [¶0093]).
Regarding Claim 5, Hsu discloses, the non-transitory machine-readable storage medium of claim 3,
Hsu also teaches, wherein the instructions upon execution cause the system to determine the community identifier based on accessing mapping information that correlates different shared secrets to corresponding different community identifiers ("During the association process, the access point may learn the MAC addresses for the first end device and the second end device. In this alternative, when the access point to which a guest's end device is associated (the access point in room 1) receives a frame from a guest's end device, before forwarding the frame it may replace the MAC address of the end device (the source MAC address in the Ethernet frame) with a different MAC address, which may include, in part, the group identifier and the device identifier. Having thus mapped (or replaced or modified) the MAC address, the frame may be forwarded in the wired network where it is bridged or routed as usual." [¶0215]).
Regarding Claim 6, Hsu discloses the non-transitory machine-readable storage medium of claim 1.
Hsu also discloses, wherein the instructions upon execution cause the system to: receive, from the client device, an authentication message as part of the authentication procedure, the authentication message comprising user information of a user of the client device ("...As a result of the DPSK authentication, access point 618-1 may be informed by AAA server 612 that access point 618-1 is the home hub and that both end devices 620-1 and 620-2 are members of group identifier 1. Access point 618-1 may locally forward frames between 620-1 and 620-2. End device 620-3, belonging to an end user assigned to location 622-2..."[ ¶0150], see also, "... the temporal criterion may include a time interval when the one or more authentication parameters may be valid for the network, and at other times the one or more authentication parameters may be valid for a second network. Furthermore, the information associated with the user may include an identifier of the user (such as a username) or a group that includes the user..."[ ¶0248]); and
determine the community identifier based on the user information ("...Access point 618-1 may locally forward frames between 620-1 and 620-2. End device 620-3, belonging to an end user assigned to location 622-2, may connect to or associate with access point 618-2. Through DPSK authentication, access point 618-2 may be informed that end device 620-3 is in group identifier 1 and that the home hub is access point 618-1..."[ ¶0150])
Regarding Claim 7, Hsu disclose, the non-transitory machine-readable storage medium of claim 6.
Hsu also teaches, wherein the user information comprises a username of the user of the client device ("... the temporal criterion may include a time interval when the one or more authentication parameters may be valid for the network, and at other times the one or more authentication parameters may be valid for a second network. Furthermore, the information associated with the user may include an identifier of the user (such as a username) or a group that includes the user..." [¶0248]).
Regarding Claim 8, Hsu disclose, the non-transitory machine-readable storage medium of claim 6.
Hsu also teaches, wherein the instructions upon execution cause the system to: determine the community identifier based on accessing mapping information that correlates different user information to corresponding different community identifiers ("...In this alternative, when the access point to which a guest's end device is associated (the access point in room 1) receives a frame from a guest's end device, before forwarding the frame it may replace the MAC address of the end device (the source MAC address in the Ethernet frame) with a different MAC address, which may include, in part, the group identifier and the device identifier. Having thus mapped (or replaced or modified) the MAC address, the frame may be forwarded in the wired network where it is bridged or routed as usual." [¶0215], see also, "As shown in Table 1, the mapped MAC address may include a MAC organizationally unique identifier, the group identifier and the device identifier. Note that the MAC organizationally unique identifier has a range of 2.sup.24 MAC addresses. In order to assure there is no conflict with any other MAC addresses present on the network in a hotel, a new MAC organizationally unique identifier may be obtained (e.g., from the IEEE) and used for MAC-mapping purposes." [¶0216]).
Regarding Claim 9, Hsu disclose, the non-transitory machine-readable storage medium of claim 6.
Hsu also teaches, wherein the authentication message comprises a Remote Authentication Dial-In User Service (RADIUS) message ("As part of the authentication exchange, the access point, which has been configured to provide DPSK authentication for this WLAN, may send an authentication request to a DPSK server. Note that, while the communication techniques may use a RADIUS protocol, it should be understood that other protocols may be used for the authentication request as well, e.g., DIAMETER or hypertext transfer protocol or HTTP (e.g., a REST protocol). The authentication request message in RADIUS may be referred to as an access-request message and the response may be referred to as an access-accept (permit) or access-reject (deny) message..." [¶0193]), and
wherein the user information is included in a vendor-specific attribute (VSA) of the RADIUS message ("Furthermore, the access request may include a RADIUS access request and the access acceptance message may include a RADIUS access acceptance message. Note that the one or more authentication parameters may be included in a RADIUS attribute, such as a VSA. Alternatively, in some embodiments, an HTTP or HTTP-based protocol (such as HTTPv2, websockets or gRPC) may be used." [¶0257]).
Regarding Claim 14, Hsu discloses the non-transitory machine-readable storage medium of claim 1.
Hsu also discloses, wherein the system comprises an authentication server or an access point (AP) of a wireless local area network (WLAN) ("...In these embodiments, PM server 614 may maintain a mapping between the location and the VLAN identifier assigned to that location, or another networking device (such as AAA server 612 or a WLAN controller) may maintain the mapping between the location and the VLAN identifier assigned to that location. End device 620-1 may be assigned to a VLAN after successfully authenticating to AAA server 612..."[ ¶0145]).
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.
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.
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Hsu in view of Madappa; Savitha Ponjanda (US 20240349052 A1, hereinafter, Madappa).
Regarding Claim 4, Hsu discloses the non-transitory machine-readable storage medium of claim 3.
Hsu doesn’t explicitly disclose, wherein the shared secret comprises a Multi Pre-Shared Key (MPSK).
Madappa, in related art discloses, wherein the shared secret comprises a Multi Pre-Shared Key (MPSK) ("The machine-readable instructions in the storage medium 504 include MPSK portal reference representation output instructions 514 to output a representation of the reference to share with the wireless devices to obtain the respective PSKs by the wireless devices for connecting to the WLAN. In some examples, the representation of the reference is output in a QR code, in a message, and so forth." [¶0084]).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to combine the teaching of Hsu with the idea of using shared secret comprises a Multi Pre-Shared Key (MPSK) as disclosed by Madappa. The rationale for using this MPSK is that it offers superior bandwidth efficiency compared to standard Binary PSK.
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Hsu in view of Shen et al. (US 20170163536 A1, hereinafter, Shen).
Regarding Claim 10, Hsu discloses the non-transitory machine-readable storage medium of claim 1.
Hsu doesn’t explicitly disclose, wherein the instructions upon execution cause the system to: receive a first packet from the client device; determine whether a destination network address in the first packet matches a gateway network address of a gateway; based on determining that the destination network address in the first packet does not match the gateway network address, encapsulate the first packet with a header containing the community identifier; and forward the encapsulated first packet from the system to a destination device.
Shen in related art relates, wherein the instructions upon execution cause the system to: receive a first packet from the client device ("FIG. 6 illustrates the sending of a first return packet 600 from the VM 355 on the second host machine 350, over two stages 605 and 610. This packet has a source address of VM2 and a destination address of VM1..." [¶0063]);
determine whether a destination network address in the first packet matches a gateway network address of a gateway ("As described above, the VM 355 may not send out a packet with a destination MAC address of VM1, if the two VMs are not on the same logical switch, but once the MFE has performed its first-hop logical network processing (and prior to the encapsulation of the packet 400), the destination MAC address will have been modified to that of VM2."[¶0063]);
based on determining that the destination network address in the first packet does not match the gateway network address, encapsulate the first packet with a header containing the community identifier ("In the second stage 610, the MFE has encapsulated the packet 600 and sent the encapsulated packet 615 onto the physical network 335. In this case, the outer header source IP address is that of VTEP4 and the destination IP address is that of VTEP2. As with the first packet, the outer header source MAC address will be that of VTEP4, while the destination MAC address may be that of an intervening router in the physical network 335, if the VTEPs are not on the same physical network switch." [¶0066]); and
forward the encapsulated first packet from the system to a destination device ("Having selected the source and destination tunnel endpoints, the process 900 encapsulates (at 950) the packet using the selected source and destination VTEPs. In some embodiments, the encapsulation includes the source and destination network addresses (e.g., IP addresses) of the selected VTEPs, as well as the source MAC address of the selected VTEP and an appropriate destination MAC address (that of the destination VTEP if on the same physical network switch as the source VTEP, or that of a default gateway port for the VTEP). The encapsulation may also include logical network context information (e.g., a determined logical egress port of a logical forwarding element, a logical forwarding element or logical network identifier, etc.)..."[¶0086]).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to combine the teaching of Hsu with the idea of encapsulating the original packet with a new header that includes a specific community identifier, which classifies the traffic, as disclosed by Shen. The rationale for using this teaching is to handle traffic orchestration, policy-based routing, or tunneling between different network domains, ensuring that packets with specific community tags are treated according to the rules defined in the network management system.
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Hsu in view of Shen, further in view of Wang; Feng (US 9992106 B2, hereinafter, Wang).
Regarding Claim 11, combination of Hsu and Shen disclose, the non-transitory machine-readable storage medium of claim 10.
Combination of Hsu and Shen don’t explicitly disclose, wherein the instructions upon execution cause the system to: receive a second packet from the client device;
determine whether a destination network address in the second packet matches the gateway network address; and
based on determining that the destination network address in the second packet matches the gateway network address, forward the second packet from the system to the gateway without encapsulating the second packet with a header including the community identifier.
Wang in analogous art discloses, wherein the instructions upon execution cause the system to: receive a second packet from the client device ("When receiving a IP packet, the router 341 may search the route table for a host route entry matching with the destination IP address 10.1.1.1 according to the longest prefix match principle, and send the IP packet according to the next-top tunnel 1 in the host route entry..." [Col 6, Row 42-48]);
determine whether a destination network address in the second packet matches the gateway network address ("When receiving the GRE tunnel packet, and determining that the destination IP address of the outer tunnel IP header is the IP address of the router 321, the router 321 may remove the GRE encapsulation (including the outer tunnel IP header and GER header), and find a host route entry matching with the destination IP address 10.1.1.1 from the local route table according to the longest prefix match principle..." [Col 6, Row 65 -Col 7, Row 1-5]); and
based on determining that the destination network address in the second packet matches the gateway network address, forward the second packet from the system to the gateway without encapsulating the second packet with a header including the community identifier ("... The router 321 may forward the received IP packet to the next-hop 10.1.1.1 in the host route entry. For instance, the router 321 may find a matching ARP entry according to the next-hop 10.1.1.1 from an ARP table, and encapsulate the IP packet into an Ethernet packet according to the matching ARP entry, and send the Ethernet packet via a port of the matching ARP entry." [Col 7, Row 5-11]).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to combine the teaching of Hsu and Shen with the idea of a system which compares the packet's destination address against the configured IP address of the local gateway to execute conditional forwarding, as disclosed by Wang. The rationale for using this teaching is to allow a network system to optimize traffic handling by distinguishing between traffic destined for the local gateway and traffic destined for external, encapsulated networks.
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Hsu in view of Shen further in view of Sharma et al. (US 20240223544 A1, hereinafter, Sharma).
Regarding Claim 12, combination of Hsu and Shen disclose the non-transitory machine-readable storage medium of claim 10.
Combination of Hsu and Shen don’t teach, wherein the encapsulating of the first packet comprises a Virtual eXtensible LAN (VXLAN) encapsulation of the first packet, and the header comprises a VXLAN header.
Sharma in related art relates, wherein the encapsulating of the first packet comprises a Virtual eXtensible LAN (VXLAN) encapsulation of the first packet, and the header comprises a VXLAN header ("In examples, when the VxLAN encapsulated packet 118 is received at an endpoint of the VxLAN tunnel 108, e.g., one of the spine switches 112(a)-112(c), the encrypt logic 202 may retrieve a destination IP (DIP) address 206 from the IP header (VTEPs) of the VxLAN encapsulated packet 118. The encrypt logic 202 may search the TxSA database 204 using the DIP 206 and obtain the information of the SA assigned to the VxLAN encapsulated packet 118, for instance, the SAK 208, the next packet number (PN) 210, and the SCI 212. The encrypt logic 202 may determine the per-packet unique initialization vector (IV) for the VxLAN encapsulated packet 108 based on the PN 210. The encrypt logic 202 may further encrypt the user data 214 (e.g., the tenant payload and the VxLAN header) based at least in part on the IV, the SAK 208, and the SCI 212 to generate the encrypted user data 216." [¶0039]).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to combine the teaching of Hsu and Shen with the idea of encapsulating the original packet and the header with Virtual eXtensible LAN (VXLAN) encapsulation, as disclosed by Sharma. The rationale for using this Virtual eXtensible LAN (VXLAN) encapsulation on the data packet and header is to allows for Layer 2 connectivity over Layer 3 boundaries.
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over Hsu, Shen, Sharma further in view of Joshi et al. (US 20230111305 A1, hereinafter, Joshi).
Regarding Claim 13, combination of Hsu, Shen and Sharma disclose the non-transitory machine-readable storage medium of claim 12.
Combination of Hsu, Shen and Sharma don’t explicitly disclose, however Joshi discloses wherein the community identifier is included in a group policy identifier (GPI) field of the VXLAN header, and wherein the community identifier in the GPI field comprises a personal area network (PAN) identifier ("FIG. 3C illustrates an example of incorporating a loop indicator in a tunnel header using a set of reserved flag bits, in accordance with an aspect of the present application. A VXLAN header 340, which can be a VXLAN-GPO header, can include a set of flags 342, a group policy identifier field 344, a VNI field 346, and a reserved field 348. Since VXLAN-GPO header 340 may not support an additional header, one of the fields of VXLAN-GPO header 340 may carry a unique loop indicator 350. For example, VXLAN-GPO header 340 can carry unique indicator 350 in a set of reserved bits in flags 342 (denoted with bold lines)." [¶0070]).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to combine the teaching of Hsu, Shen, and Sharma with the idea of utilizing the 16-bit Group Policy Identifier (GPI) field network devices can carry context-aware security information from the source to the destination, as disclosed by Joshi. The rationale for using this mechanism for modern data center microsegmentation is to ensure that policies follow workloads and users regardless of their physical location in the network.
Claims 15-20 are rejected under 35 U.S.C. 103 as being unpatentable over Hsu in view of Divvi et al. (US 20240298176 A1, hereinafter, Divvi).
Regarding Claim 15, Hsu discloses, a method comprising:
initiating, by a network device, an authentication procedure for a first client device ("FIG. 13 presents a flow diagram illustrating an example of a method 1300 for selectively providing secure access, which may be performed by an electronic device, such as AAA server 130 in FIG. 1. During operation, the electronic device may receive an access request (operation 1310) associated with a computer, where the access request includes one or more authentication parameters associated with a user..." [¶0242]);
as part of the authentication procedure, obtaining, by the network device, a community identifier for a group of client devices in a virtual network ("In order to identify which electronic devices should form a single PAN, each hotel guest may be provided with a passphrase (such as a PSK, a DPSK or another type of digital certificate). For example, the passphrase may include a group DPSK passphrase or a group passphrase. Note that each device having a DPSK passphrase (or a group of electronic devices sharing a group DPSK passphrase) may be uniquely authenticated. Because they can be authenticated, the network can apply a policy (e.g., a VLAN assignment) suitable for that electronic device (or group of electronic devices, as the case may be)..." [¶0172]), the group of client devices comprising the first client device, and the first client device being assigned the community identifier in the authentication procedure ("With group-passphrases, one or more electronic devices (the group) may be provisioned with the exact same passphrase. All the electronic devices that authenticate to a WLAN using the same group passphrase may receive the same services from the network..." [¶0173]);
determining whether the extracted community identifier matches the community identifier assigned to the first client device ("Moreover, if end device 620-1 has a frame to send to end device 620-2, access point 618-1 may receive the frame, map the source MAC address of the frame as described previously and, by inspecting the destination MAC address in the frame, determine that the frame is destined end device 620-2. Because access point 618-1 knows, from the DPSK authentication, that end device 620-1 is a member of group identifier 1, and because the mapped source MAC address has a matching group identifier..." [¶0156], see also,"...The access point may receive the frame, may map the source MAC address of the frame as described previously and, by inspecting the destination MAC address in the frame, may determine that the frame is destined to the second end device. Because the access point knows (from DPSK authentication) that end device is a member of group identifier 1..." [¶0217]);
based on determining that the extracted community identifier matches the community identifier assigned to the first client device, forward a decapsulated version of the encapsulated packet to the first client device ("...Because access point 618-1 knows, from the DPSK authentication, that end device 620-1 is a member of group identifier 1, and because the mapped source MAC address has a matching group identifier, access point 618-1 may forward the frame to end device 620-1. However, if the group identifier in the mapped MAC address did not match the group identifier of the destination device, access point 618-1 would filter, or drop, the frame." [¶0156], see also, "...and because the mapped source MAC address has a matching group identifier, the access point may forward the frame to the second end device. However, if the group identifier in the mapped MAC address did not match the group identifier of the destination device, the access point would filter (or drop) the frame." [¶0217]).
Hsu doesn’t explicitly disclose, receiving, by the network device, an encapsulated packet sent from a source device and targeted to the first client device;
extracting, by the network device, a community identifier associated with the source device from a header of the encapsulated packet;
Divvi, in analogous art discloses, receiving, by the network device, an encapsulated packet sent from a source device and targeted to the first client device ("...For upstream traffic received from the client device 1 5004, AP N 5006 encapsulates L2 frames with the dynamically assigned S-VLAN and C-VLAN information (e.g., S-VLAN ID and C-VLAN ID and optionally included policy information). The modified frames will then be encapsulated in tunneling protocols such as Soft GRE (Ethernet over GRE). S-VLAN ID and C-VLAN ID will be used by the AP-N 5006 to identify information and/or data communicated to the client device 1 5004 from the wired network..." [¶0257]);
extracting, by the network device, a community identifier associated with the source device from a header of the encapsulated packet ("...extracting, by the first network edge device (e.g., first Access Point), the first S-VLAN ID from the first Tunnel-Private-Group-ID attribute of the third message: extracting, by the first network edge device (e.g., first Access Point), the first C-VLAN ID from the second Tunnel-Private-Group-ID attribute of the third message..."[ ¶0022], see also, "In sub-step 1064, the first Access Point extracts the dynamically assigned first S-VLAN ID from the first tunnel-private group-ID attribute of the third message." [¶0544]);
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to combine the teaching of Hsu with the teaching of processes the incoming traffic by reading specialized header information, implement policy enforcement, and steering the traffic as disclosed by Divvi. The rationale for using this technique is to allows the network to apply consistent security and forwarding policies based on the source's group, even if the source device moves across the network.
Regarding Claim 16, Combination of Hsu and Divvi disclose the method of claim 15.
Hsu also discloses, wherein the community identifier assigned to the first client device comprises a personal area network (PAN) identifier, the method comprising:
including, by the network device, the PAN identifier in a field of a header of a given packet as part of encapsulating the given packet ("Notably, the virtual network may be specified using at least a 24-bit identifier, e.g., in a GRE header (which is sometimes referred to as a VNI). This may be useful in embodiments or applications where there are a large number of users, such as in university housing. When there are more students, there may be more VLANs..."[¶0233]).
Regarding Claim 17, combination of Hsu and Divvi disclose the method of claim 16.
Hsu also discloses, further comprising: responsive to the first client device transitioning from the network device to a further network device, transmitting, as part of a transition procedure to transition the first client device from the network device to the further network device, the community identifier assigned to the first client device ("...For example, the access acceptance message may include: an identifier of electronic device 110-1, a tunnel type, a tunnel medium type, a tunnel privilege group identifier, a filter identifier, and the username." [¶0091], see also, "...At this point, access point 116-1 may establish secure access to the WLAN for electronic device 110-1 (and, more generally, secure access to network 120 and/or network 122, such as an intranet or the Internet). Notably, the secure access may be in a PAN in the WLAN, which is independent of traffic associated with other PANs in the WLAN."[¶0092]).
Regarding Claim 18, combination of Hsu and Divvi disclose the method of claim 16.
Hsu also teaches, further comprising: determining the group of client devices based on information associated with the client devices, wherein the information comprises one or more of:
a user or collection of users that the client devices are associated with,
a type of the client devices,
locations of the client devices, or
an organization that the client devices are associated with ("Then, when one or more criteria associated with the policy are met, AAA server 130 may selectively provide an access acceptance message to computer 112 (such as a RADIUS access acceptance message). This access acceptance message may be intended for electronic device 110-1 and may include information for establishing secure access of electronic device 110-1. For example, the access acceptance message may include: an identifier of electronic device 110-1, a tunnel type, a tunnel medium type, a tunnel privilege group identifier, a filter identifier, and the username." [¶0091]).
Regarding claim 19 “network device”, is rejected under the same reasoning as claim 15 “method”, where Hsu and Divvi teach method/“network device”.
Regarding Claim 20, combination of Hsu and Divvi disclose the network device of claim 19.
Hsu also discloses, wherein the community identifier comprises a personal area network (PAN) identifier of a PAN that the first client device is part of ("In order to further illustrate operation of a guest's PAN, end device 620-3, which belongs to the guest assigned to location 622-2, may connect to or associate with access point 618-2. As a result of the DPSK authentication, access point 618-2 may be informed that end device 620-3 is in group identifier 1, which is the group assigned to the guest staying in location 622-1..." [¶0157], see also, "The AAA server may also return the group identifier. The group identifier may be the PAN identifier to which the guest's end devices are assigned. The network may forward frames from a group member only to other group members or toward the Internet...”[¶0207]).
Conclusion
References cited but not used: Malarouthu et al. (US 20240381458 A1) can be used for independent claims 1, 15 and 19 in addition to the one used.
References cited but not used: Li; Qing (US 10880265 B1) can be used for dependent claims 10-11 in addition to the one used.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MUHAMMAD AINUL HUDA whose telephone number is (703)756-1594. The examiner can normally be reached M-F 8:30 - 6:30 ET.
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, HASSAN PHILLIPS can be reached on (571)272-3940. 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.
/MUHAMMAD AINUL HUDA/Examiner, Art Unit 2467
/HASSAN A PHILLIPS/Supervisory Patent Examiner, Art Unit 2467
Prosecution Insights