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 .
Response to Amendment
This office action is in response to the applicant’s filing on 04/16/2026. Claims 1-20 are pending. Claims 1, 8, and 15 are independent.
Response to Arguments
Applicant’s arguments, on pages 1-3 of Applicant’s Remarks, filed 04/16/2026 (hereinafter “REMARKS”), with respect to the rejection of the claims under 35 U.S.C. § 103 have been fully considered and are persuasive. Specifically, applicant argues the prior art of record does not teach the amended independent claim limitations. However, in view of the amended independent claims and upon further consideration, a new ground(s) of rejection under 35 U.S.C. § 103 is made over Meier et al. (US PGPub No. 2005/0025160; hereinafter “Meier”) in view of Zeh et al. (US PGPub No. 2026/0046259; hereinafter “Zeh”) in view of PERI et al. (US PGPub No. 2023/0155988; hereinafter “PERI”).
Meier teaches an access point which upon receipt of an Ethernet frame may wirelessly transmit the frame to associated stations and encrypts the frame using a group key before doing so (Meier ¶ 0017, ¶ 0031, ¶ 0037, ¶ 0053, Fig. 1). An identification element may be added to the header of the message transmitted to the stations (Meier ¶ 0019, ¶ 0054).
PERI teaches encrypting packets while it traverses a VXLAN, and a switch at the edge of a network may perform security association identification on an ethernet frame and packet encryption (PERI ¶ 0013, ¶ 0014). When a packet is received at the edge of the network a switch can decapsulate a payload, perform SA identification, and decrypt the packet (PERI ¶ 0014).
Therefore, the combination of Meier in view of Zeh in view of PERI disclose all the limitations of the independent claims.
Regarding applicant’s arguments with respect to the dependent claims, the amendments to the independent claims have necessitated a new ground of rejection with respect to the independent claims from which the dependent claims depend, thereby requiring new grounds of rejection for the dependent claims.
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.
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.
Claims 1-4, 6-11, 13-18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Meier et al. (US PGPub No. 2005/0025160; hereinafter “Meier”) in view of Zeh et al. (US PGPub No. 2026/0046259; hereinafter “Zeh”) in view of PERI et al. (US PGPub No. 2023/0155988; hereinafter “PERI”).
As per claim 1: Meier discloses a method comprising:
establishing a group encryption key among a group of nodes in a wired network (establish a multicast key for signing and encrypting the multicast message transmitted on the network [Meier ¶ 0019]; group multiple VLANs into a single 802.11 multicast domain whereby a single multicast message may be sent to the subscribers of the multicast domain [Meier ¶ 0029]; a trust relationship between an access point (AP) and a defined multicast group of clients or stations [Meier ¶ 0031]; an AP 145 may be configured to provide the communicative transition point between the dedicated wired network 160 and the wireless clients [Meier ¶ 0034, ¶ 0033]; group multiple VLANs into a single IP Multicast Domain 180 [Meier ¶ 0040]; If a Multicast Domain contains a single VLAN and that single VLAN is also the designated Multicast VLAN, then it will be appreciated that a single group key can function both as a broadcast key and as a multicast group key [Meier ¶ 0045]; a parent AP 145 may be configured to deliver an IP multicast group key containing a first key ID … to each multicast domain associated client [Meier ¶ 0050]; The IP multicast group key may be used to encrypt/decrypt 802.11 frames that belong to the station’s IP Multicast Domain 180 [Meier ¶ 0051]; the parent AP 145 may maintain group membership information for each Multicast Domain 180 [Meier ¶ 0057]), [wherein the group of nodes is configured as a ring network];
encoding a Ring Encryption Tag (RET) in a header of a frame (a multicast key identification element corresponding to the multicast key may be established. This multicast identification element may assist a recipient of the multicast message to select the appropriate multicast key to decrypt the received multicast message. Prior to transmission, the multicast key identification element may be added to a header of a multicast message transmitted to a station [Meier ¶ 0019]; Correspondingly, the IP multicast group key ID may be entered into the 802.11 header prior to transmitting the frame via the 802.11 link by the AP 145 to the wireless stations [Meier ¶ 0054]), the RET communicating to nodes within the ring network that the frame is part of an encryption group (This multicast identification element may assist a recipient of the multicast message to select the appropriate multicast key to decrypt the received multicast message [Meier ¶ 0019]; The present system and method may be adapted to encrypt the frame utilizing the IP multicast group key for the domain [Meier ¶ 0053]) and [that the frame does not need to be decrypted until the frame] is transmitted out of [the ring] network (It will be appreciated that this multicast group key ID and corresponding cryptology may prohibit non-member stations (e.g. 130, 135) from decrypting the frame [Meier ¶ 0054]);
encrypting a payload of the frame using the group encryption key (The present system and method may be adapted to encrypt the frame utilizing the IP multicast group key for the domain [Meier ¶ 0053]; Correspondingly, the IP multicast group key ID may be entered into the 802.11 header prior to transmitting the frame via the 802.11 link by the AP 145 to the wireless stations [Meier ¶ 0054]); and
transmitting the frame through the ring network (transmitting the frame via the 802.11 link by the AP to the wireless stations [Meier ¶ 0054]; the frame may be encrypted using the previously delivered multicast key and relayed to the appropriate stations [Meier ¶ 0065]);
wherein the frame enters [the ring network] at a boundary node that is a first point of entry for the frame into [the ring] network (upon receipt of an Ethernet IP multicast frame via a multicast VLAN, a parent AP 145 may be configured to wirelessly transmit the frame to 802.11 stations (110, 115, 120, 125) in the corresponding IP Multicast Domain 180. The present system and method may be adapted to encrypt the frame utilizing the IP multicast group key for the domain [Meier ¶ 0053]), the boundary node encodes the RET in the header of the frame when the frame enters [the ring] network (the IP multicast group key ID may be entered into the 802.11 header prior to transmitting the frame via the 802.11 link by the AP 145 to the wireless stations (e.g. 110, 115, 120, 125) [Meier ¶ 0054]), [the frame stays encrypted along an entire path through] [the ring network], [and the frame is decrypted when the frame exits] [the ring network].
Meier discloses the claimed subject matter as discussed above but does not explicitly disclose wherein the group of nodes is configured as a ring network; that the frame does not need to be decrypted until the frame; the ring; the ring network. However, Zeh teaches wherein the group of nodes is configured as a ring network (a conventional High-availability Seamless Redundancy (HSR) ring topology [Zeh ¶ 0199]); that the frame does not need to be decrypted until the frame (For authentication only secured messages, the ICV is computed without encrypted data, and for authenticated and encrypted secured messages the ICV is computed in parallel with the encrypted data. Authentication only messages may be particularly useful, for example, in scenarios in which a message needs to be read first to quickly perform a specific control or execute a command without first decrypting the payload of the secured message. The embodiments as discussed herein may implement any suitable algorithms to compute the ICVs, including known techniques. In accordance with these cryptographic functions used to generate the ICV, the inputs typically comprise a key (e.g. the session key), a counter value (e.g. the key counter value) , the plaintext of the message (when present), and a current freshness value (FV) that is transmitted in the secured message [Zeh ¶ 0068]); the ring (a conventional High-availability Seamless Redundancy (HSR) ring topology [Zeh ¶ 0199]); the ring network (a conventional High-availability Seamless Redundancy (HSR) ring topology [Zeh ¶ 0199]). Meier and Zeh are analogous art because they are from the same field of endeavor of secure communication. Therefore, based on Meier in view of Zeh, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Zeh to the system of Meier in order to efficiently perform a control or command without first decrypting the payload for increased processing speed. Hence, it would have been obvious to combine the references above to obtain the invention as specified in the instant claim.
Meier in view of Zeh discloses the claimed subject matter as discussed above but does not explicitly disclose the frame stays encrypted along an entire path through the network; and the frame is decrypted when the frame exits the network. However, PERI teaches the frame stays encrypted along an entire path through the network (MACsec security may be extended over Layer 3 networks by tunneling MACsec encrypted packets over Layer 3 overlays, e.g., Virtual Extensible LAN (VXLAN or VxLAN) [PERI ¶ 0013, Examiner’s Note: packet is encrypted while it traverses network]; For example, for L3 VPN origination of an out-bound packet, a switch can perform one or more of: security association (SA) identification on an Ethernet frame, packet encryption, append an L3 VPN header, access an L3 forwarding database to determine next hop or next network interface device to receive the packet, and send the packet in an external network to another switch, router, or endpoint [PERI ¶ 0014, Examiner’s Note: encrypted and passed along network]); and the frame is decrypted when the frame exits the network (for L3 L3VPN termination of an inbound packet, the switch can perform one or more of: decapsulate a payload, perform SA identification, decrypt the packet and transmit the decrypted packet to an endpoint (e.g., server or host) [PERI ¶ 0014, Examiner’s Note: packet decrypted when exiting the network]). Meier in view of Zeh and PERI are analogous art because they are from the same field of endeavor of secure communication. Therefore, based on Meier in view of Zeh in view of PERI, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of PERI to the system of Meier in view of Zeh in order to ensure improved security through efficient encryption without the need for additional layer 3 cryptographic circuitry and accompanying cost increase, power increase, and increase in use of silicon space (Meier ¶ 0013). Hence, it would have been obvious to combine the references above to obtain the invention as specified in the instant claim.
As per claim 2: Meier in view of Zeh in view PERI teach all the limitations of claim 1. Furthermore, Meier and Zeh disclose wherein the nodes of the ring network include a boundary node (An access point [Meier ¶ 0017, Fig. 1]; a trust relationship between an access point (AP) and a defined multicast group of clients or stations [Meier ¶ 0031]), the boundary node being a first point of entry for the frames as it enters the ring network (a conventional High-availability Seamless Redundancy (HSR) ring topology [Zeh ¶ 0199]; ), and wherein the boundary node encodes the RET (upon receipt of an Ethernet IP multicast frame via a multicast VLAN, a parent AP 145 may be configured to wirelessly transmit the frame to 802.11 stations (110, 115, 120, 125) in the corresponding IP Multicast Domain 180. The present system and method may be adapted to encrypt the frame utilizing the IP multicast group key for the domain [Meier ¶ 0053, ¶ 0037]).
As per claim 3: Meier in view of Zeh in view PERI teach all the limitations of claim 1. Furthermore, Zeh discloses wherein the RET includes an EtherType (then the acknowledgement field may be part of an Ethertype field of an Ethernet communication frame, which may contain protocol information. The data contained in such an Ethertype field may, for example, function to “chain” a message to other Ethertypes, such as MACsec for example [Zeh ¶ 0222]).
As per claim 4: Meier in view of Zeh in view PERI teach all the limitations of claim 1. Furthermore, Meier discloses wherein the ring network includes one or more virtual local area networks (one or more VLANs) (individually defined VLANs 165, 170, 175 may be configured to group wireless clients 110, 115, 120, 125, 130, 135. As shown, a first VLAN1165 may virtually include multiple wireless clients 110, 115. Likewise, a second VLAN2170 may virtually include mul-tiple wireless clients 120, 125. And finally, a third VLAN3175 may virtually include multiple wireless clients 130,135 [Meier ¶ 0038, Fig. 1]; a conventional High-availability Seamless Redundancy (HSR) ring topology [Zeh ¶ 0199]), and wherein the RET applies to at least one of the one or more VLANs (any number of VLANs configured to receive multicast or broadcast transmission from a single AP [Meier ¶ 0039]; group multiple VLANs into a single 802.11 multicast domain whereby a single multicast message may be sent to the subscribers of the multicast domain [Meier ¶ 0029, ¶ 0040]; If a Multicast Domain contains a single VLAN and that single VLAN is also the designated Multicast VLAN, then it will be appreciated that a single group key can function both as a broadcast group key and as a multicast group key [Meier ¶ 0045]; deliver an IP multicast group key containing a first key ID … to each multicast domain associated client [Meier ¶ 0050]).
As per claim 6: Meier in view of Zeh in view PERI teach all the limitations of claim 1. Furthermore, Meier and Zeh discloses wherein the payload of the frame (enters the Key ID of the key used to encrypt a transmitted 802.11 multicast frame into a Key ID field in the 802.11 frame header [Meier ¶ 0008]; The IP multicast group key may be used to encrypt/decrypt 802.11 frames that belong to the station’s IP Multicast Domain 180 [Meier ¶ 0051]; based upon the particular cryptographic algorithm that is used to compute the ICV, the ICV may be generated using the same key as that used for the encryption of data (i.e. the encrypted payload) or a different key [Zeh ¶ 0069, Fig. 4A]) is encrypted at a Layer 2 level (a "Layer 2 Broadcast Domain" architecture may be configured to correspond to a single Internet Protocol (IP) subnet or VLAN [Meier ¶ 0009]).
As per claim 7: Meier in view of Zeh in view PERI teach all the limitations of claim 1. Furthermore, Meier discloses further comprising encoding a destination address in the header of the frame (it only forwards the packet onto other subnets where there are members of the IP multicast group identified by the destination IP multicast address [¶ 0006]; Correspondingly, the IP multicast group key ID may be entered into the 802.11 header prior to transmitting the frame via the 802.11 link by the AP 145 to the wireless stations [Meier ¶ 0054]), the destination address requiring transmission of the frame past a plurality of the nodes in the ring network (message must be received by stations in the multicast domain if there is at least one station that is participating in the multicast group identified by the message's destination multicast address [Meier ¶ 0021]; For an HSR ring implementation, outgoing frames are duplicated and sent to two ports [Zeh, ¶ 0199, Fig. 10, see nodes it travels past]).
As per claim 8: Meier in view of Zeh in view PERI teach all the limitations of claim 1. Furthermore, Meier and Zeh disclose a network device comprising: a storage configured to store instructions (“processing blocks” and represent computer software instructions or groups of instructions that cause a computer or processor to perform an action(s) and/or to make decisions [Meier ¶ 0059]; The program memory 208.3 may comprise any suitable type of non-transitory computer readable medium such as volatile memory, non-volatile memory, or combinations of these. To the extent that the node 200 implements software-based solutions to perform the various functions as discussed herein, this may be achieved, for instance, via the processor circuitry 208.2 executing instructions stored in the program memory 208.3. [Zeh ¶ 0056]); and at least one processor configured to execute the instructions and cause the at least one processor to (“processing blocks” and represent computer software instructions or groups of instructions that cause a computer or processor to perform an action(s) and/or to make decisions [Meier ¶ 0059]): The limitations of claim 8 are substantially similar to claim 1 above, and therefore the claim is likewise rejected.
As per claim 9: Meier in view of Zeh in view PERI teach all the limitations of claim 8. The limitations of claim 9 are substantially similar to claim 2 above, and therefore the claim is likewise rejected.
As per claim 10: Meier in view of Zeh in view PERI teach all the limitations of claim 8. The limitations of claim 10 are substantially similar to claim 3 above, and therefore the claim is likewise rejected.
As per claim 11: Meier in view of Zeh in view PERI teach all the limitations of claim 8. The limitations of claim 11 are substantially similar to claim 4 above, and therefore the claim is likewise rejected.
As per claim 13: Meier in view of Zeh in view PERI teach all the limitations of claim 8. The limitations of claim 13 are substantially similar to claim 6 above, and therefore the claim is likewise rejected.
As per claim 14: Meier in view of Zeh in view PERI teach all the limitations of claim 8. The limitations of claim 14 are substantially similar to claim 7 above, and therefore the claim is likewise rejected.
As per claim 15: Meier in view of Zeh in view PERI teach all the limitations of claim 1. Furthermore, Meier and Zeh disclose a non-transitory computer-readable medium including instructions that, when executed by at least one processor, cause the at least one processor to (“processing blocks” and represent computer software instructions or groups of instructions that cause a computer or processor to perform an action(s) and/or to make decisions [Meier ¶ 0059]; The program memory 208.3 may comprise any suitable type of non-transitory computer readable medium such as volatile memory, non-volatile memory, or combinations of these. To the extent that the node 200 implements software-based solutions to perform the various functions as discussed herein, this may be achieved, for instance, via the processor circuitry 208.2 executing instructions stored in the program memory 208.3. [Zeh ¶ 0056]): The limitations of claim 15 are substantially similar to claim 1 above, and therefore the claim is likewise rejected.
As per claim 16: Meier in view of Zeh in view PERI teach all the limitations of claim 15. The limitations of claim 16 are substantially similar to claim 2 above, and therefore the claim is likewise rejected.
As per claim 17: Meier in view of Zeh in view PERI teach all the limitations of claim 15. The limitations of claim 17 are substantially similar to claim 3 above, and therefore the claim is likewise rejected.
As per claim 18: Meier in view of Zeh in view PERI teach all the limitations of claim 15. The limitations of claim 18 are substantially similar to claim 4 above, and therefore the claim is likewise rejected.
As per claim 20: Meier in view of Zeh in view PERI teach all the limitations of claim 15. The limitations of claim 20 are substantially similar to claim 6 above, and therefore the claim is likewise rejected.
Claims 5, 12 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Meier in view of Zeh in view of PERI in view of SUBRAMANIAM et al. (US PGPub No. 2017/0180153; hereinafter “SUBRAMANIAM”).
As per claim 5: Meier in view of Zeh in view PERI teach all the limitations of claim 1. Furthermore, Zeh discloses further comprising [blocking a port of one of the nodes to prevent a loop ] within the ring network in which the frame travels entirely around the ring network (a conventional High-availability Seamless Redundancy (HSR) ring topology [Zeh ¶ 0199]; For an HSR ring implementation, outgoing frames are duplicated and sent to two ports. Ingress ports pass through frames to an opposite egress port, discarding duplicates. However, HSR ring implementations require a specific topology, the use of a duplicate message transmission scheme, and the atomicity achieved is vulnerable to the robustness of the interconnections between each of the ports, with a failure of any port connection resulting in a loss of atomicity for the entire system [Zeh ¶ 0199]).
Meier in view of Zeh in view PERI discloses the claimed subject matter as discussed above but does not explicitly disclose blocking a port of one of the nodes to prevent a loop within the ring network. However, SUBRAMANIAM teaches blocking a port of one of the nodes to prevent a loop within the ring network (When a loop is detected, the RPL can be put into a standard forced switch condition which solves the immediate problem. An alarm is raised to alert the user to the loop and forced switch condition. This action does not adversely affect traffic on the ring since the result is a single blocked ring port as the G.8032 standard requires [¶ 0021]). SUBRAMANIAM and the instant application are analogous art because they are from the same field of endeavor of ring networks. Therefore, based on Meier in view of Zeh in view PERI in view of SUBRAMANIAM, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of SUBRAMANIAM to the system of Meier in view of Zeh in view PERI in order to prevent excess traffic through a loop as a remediation to its identification. Hence, it would have been obvious to combine the references above to obtain the invention as specified in the instant claim.
As per claim 12: Meier in view of Zeh in view PERI teach all the limitations of claim 8. The limitations of claim 12 are substantially similar to claim 5 above, and therefore the claim is likewise rejected.
As per claim 19: Meier in view of Zeh in view PERI teach all the limitations of claim 15. The limitations of claim 19 are substantially similar to claim 5 above, and therefore the claim is likewise rejected.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAMES P MOLES whose telephone number is (703)756-1043. The examiner can normally be reached M-F 8:00am-5:00pm.
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, Jung Kim can be reached at (571) 272-3804. 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.
/JAMES P MOLES/Examiner, Art Unit 2494
/KAVEH ABRISHAMKAR/Primary Examiner, Art Unit 2494
Prosecution Insights