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
Claims 1, 4-8, 11, 13, 14, 15, 18, 19, and 20 have been amended
Claims 2, 3, 9, 10, 16, and 17 have been cancelled
Claims 21-26 are added new
Claims 1, 4-8, 11-15, and 18-26 are pending
Priority
This application claims priority to U.S. Application No. 63/618,965, filed Jan. 9, 2024. Therefore, the effective filing date of this application is Jan. 9, 2024.
Response to Arguments
Applicant’s arguments filed on 06/26/2026 have been fully considered.
With respect to the USC 112(b) rejection for claims 5, 9-12, 14, and 19. The rejection has been overcome for all claims except for claim 12. Examiner suggests amending claim 12 similar to the amendments of claims 5 and 19.
With respect to the USC 101 rejection Applicant has argued that the current amendments recite of a practical application. Examiner respectfully disagrees. The claims as currently amended still recite of performing an encryption operation to generate a MACsec frame and wirelessly transmitting the MACsec frame to the wireless client device. The claim is still being directed towards transmitting data. There is no limitation that states what is the outcome of the MACsec frame being transmitted. Examiner suggests incorporating features of figure 1 of multiple client devices performing operations to overcome the USC 101 abstract rejection. Examiner believes performing multiple operations by multiple client devices at the same time cannot be performed abstractly.
With respect to the USC 103 rejection Applicant has argued that KNECKT does not disclose or suggest “adding a [MACsec] header to the [MACsec] payload to generate a [MACsec] frame, the [MACsec] header including a source address corresponding to a wireless access point and a destination address corresponding to a wireless client device, the source address being different from the source MAC address and the destination address being different from the destination MAC address”, as recited in amended claim 1. Examiner respectfully disagrees. KNECKT teaches this limitation as seen in the following citations ([KNECKT, para.0041] “MAC frame 300 can be included in an aggregated MAC protocol data unit (A-MPDU) subframe, and can then be transmitted OTA to a receiver. Since the actual values of those certain MAC header fields in MAC header bits 330 are encrypted when MAC frame 300 is transmitted OTA, even if MAC frame 300 is intercepted (e.g., by an attacker), only the OTA values (e.g., all zeroes, dummy values, or randomized values) are visible obtained. Accordingly, the STA or AP cannot be fingerprinted or identified based on those certain MAC header fields.”) ([KNECKT, para.0034] “Some embodiments include encrypting actual values of the MAC header fields (e.g., PM, MD, EOSP) in the encrypted payload of a MAC frame. The MAC header fields that previously contained the actual values can be set to all zeroes (e.g., zeroed out), include a dummy value (e.g., a predetermined value), and/or include a randomized value.”) ([KNECKT, para.0067] “At 826, transmitter 820 randomizes fields in Frame Control field 310 and/or QoS Control field 320 that correspond to MAC header bits 330. Namely, the following fields may be populated with corresponding OTA values and/or patterns: … Other fields in the MAC header that can be randomized and replaced with an OTA value include transmitter address (TA), receiver address (RA), sequence number (SN), packet number (PN), and a Salt.”). KNECKT teaches of a MACsec frame being transmitted. The frame consists of a transmitter address and a receiver address that are replaced with an OTA value to preserve privacy. The OTA address values being different from the actual receiver and transmitter address teaches of the source address being different from the source MAC address and the destination address being different from the destination MAC address, as recited in amended claim 1. Furthermore, KNECKT teaches “a source address corresponding to a wireless access point and a destination address corresponding to a wireless client device” ([KNECKT, para.0063] “FIG. 8 illustrates example 800 of transmitter 820 and receiver 830 supporting encryption of MAC header fields for WLAN privacy enhancement, according to some embodiments of the disclosure. For explanation purposes and not a limitation, FIG. 8 may be described with reference to elements from other figures in the disclosure. For example, transmitter 820 can be AP MLD 110, AP 112, AP 114, AP 116, AP 110 that includes a single transceiver, non-AP MLD STA 120, STA 122, STA 124, STA 126, or STA 140 of FIG. 1 . For example, receiver 830 can be AP MLD 110, AP 112, AP 114, AP 116, AP 110 that includes a single transceiver, non-AP MLD STA 120, STA 122, STA 124, STA 126, or STA 140 of FIG. 1 .”). As seen from this citation, the source address corresponds to a transmitter access point (AP) and the destination address corresponds to a receiver wireless station (STA). KNECKT teaches that the station can be a client device ([KNECKT, para. 0004] “A client device (e.g., wireless station”). KNECKT does not teach of MACsec and as for the newly amended limitation of “wherein performing the encryption operation comprises performing a MAC security (MACsec) operation on the MPDU to encapsulate the data payload and at least the source MAC address and the destination MAC address of the MPDU within a MACsec payload” Examiner is relying on SANKARAN to teach this limitation and of MAC security. This limitation was originally recited similarly in now cancelled claim 3. Therefore, Examiner is now modifying the rejection of claim 1 from a USC 102 to a USC 103 rejection using both KNECKT and SANKARAN. Claims 8 and 15 are parallel to claim 1. Therefore, a similar response applies.
Additional arguments are moot in view of new grounds of rejection.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claim 12 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 12 recites the limitation “randomly generated values for a source address and a destination address”. However, claim 8 already recites of a source address and a destination address. It is unclear if the source address and destination address of claim 12 are the same as the one being recited in claim 8. For the purpose of examination Examiner is interpreting this limitation as “randomly generated values for the source address and the destination address”. Appropriate correction is required.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1, 4-8, 11-15, and 18-26 are rejected under 35 U.S.C. 101 because they directed to an abstract idea.
Claim 1 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claim recites of a method comprising: obtaining a Media Access Control (MAC) protocol data unit (MPDU) that includes a header and a data payload, the header including a source MAC address and a destination MAC address; performing an encryption operation on the MPDU to encapsulate the data payload and at least a portion of the header in an encrypted payload to obfuscate privacy related fields of the MPDU, wherein performing the encryption operation comprises performing a MAC security (MACsec) operation on the MPDU to encapsulate the data payload and at least the source MAC address and the destination MAC address of the MPDU within a MACsec payload, and adding a MACsec header to the MACsec payload to generate a MACsec frame, the MACsec header including a source address corresponding to a wireless access point and a destination address corresponding to a wireless client device, the source address being different from the source MAC address and the destination address being different from the destination MAC address; and wirelessly transmitting, by the wireless access point, the MACsec frame to the wireless client device over a network.
The limitation of obtaining a Media Access Control (MAC) protocol data unit (MPDU) that includes a header and a data payload, the header including a source MAC address and a destination MAC address, is a process that, under its broadest reasonable interpretation, covers steps that can be performed in the mind. A user can manually obtain Media Access Control (MAC) protocol data unit that includes a header and a data payload.
The limitation of performing an encryption operation on the MPDU to encapsulate the data payload and at least a portion of the header in an encrypted payload to obfuscate privacy related fields of the MPDU, wherein performing the encryption operation comprises performing a MAC security (MACsec) operation on the MPDU to encapsulate the data payload and at least the source MAC address and the destination MAC address of the MPDU within a MACsec payload, and adding a MACsec header to the MACsec payload to generate a MACsec frame, the MACsec header including a source address corresponding to a wireless access point and a destination address corresponding to a wireless client device, the source address being different from the source MAC address and the destination address being different from the destination MAC address, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can be performed in the mind. A user can manually perform an encryption operation on the MPDU by performing MAC security operation to encapsulate the data payload and at least the source MAC address and the destination MAC address of the MPDU within a MACsec payload, and adding a MACsec header to the MACsec payload to generate a MACsec frame.
The limitation of and wirelessly transmitting, by the wireless access point, the MACsec frame to the wireless client device over a network, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can be performed in the mind. A user can manually transmit wirelessly the MACsec frame.
This judicial exception is not integrated into a practical application. The claim recites of a limitation of “wirelessly transmitting, by the wireless access point, the MACsec frame”. This limitation is used to generally transmit the encrypted payload. The limitation does not place any limit on what is the purpose or outcome of transmitting the MACsec frame. Merely transmitting data wirelessly does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. The claim is not patent eligible.
Claim 4 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. This claim recites wherein the MACsec header includes an over-the-air MAC (otaMAC) address of the wireless client device as the destination address and an otaMAC address of [[a]] the wireless access point as the source address. Therefore, the limitations of this claim, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can also be performed in the mind. A user can manually add a MACsec header to the MACsec payload, the MACsec header including an over-the-air MAC (otaMAC) address of a wireless client device as a destination address and an otaMAC address of a wireless access point device as a source address.
Claim 5 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. This claim recites of wherein the MACsec header includes randomly generated values for the source address and the destination address. Therefore, the limitations of this claim, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can also be performed in the mind. A user can manually determine the MACsec header includes randomly generated values for a source address and a destination address.
Claim 6 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. This claim recites of wherein padding is added to the data payload so that a size of the MPDU is a predetermined size, wherein the predetermined size is determined by the wireless access point and wherein the padding is added by a second wireless client device that is a source of the MPDU. Therefore, the limitations of this claim, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can also be performed in the mind. A user can manually determine padding to be added to the data payload. Furthermore, the recitation of wireless client device amounts to no more than mere instructions to apply the exception using a generic device. Mere instructions to apply an exception using a generic device cannot provide an inventive concept.
Claim 7 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. This claim recites of wherein wirelessly transmitting comprises wirelessly transmitting the MACsec frame according to an IEEE 802.11 wireless networking protocol. Therefore, the limitations of this claim, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can also be performed in the mind. A user can manually transmit data in accordance to IEEE 802.11 wireless networking protocol.
Claim 8 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. Furthermore, this claim recites of an apparatus comprising a processor that perform the features of method claim 1. Therefore, claim 8 is rejected in a similar manner as in the rejection of claim 1.
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. In particular, the claim only recites one additional element of “a processor, wherein the processor is configured to perform operations comprising” recited at a high-level of generality (i.e., as a generic processor implementing the apparatus) such that it amounts no more than mere instructions to apply the exception using a generic processor. Mere instructions to apply an exception using a generic processor cannot provide an inventive concept. The claim is not patent eligible.
Claim 15 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. Furthermore, this claim recites of one or more non-transitory computer readable storage media encoded with instructions that, when executed by a processor, cause the processor to execute the method of claim 1. Therefore, claim 15 is rejected in a similar manner as in the rejection of claim 1.
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. In particular, the claim only recites one additional element of “one or more non-transitory computer readable storage media encoded with instructions that, when executed by a processor, cause the processor to execute” recited at a high-level of generality (i.e., as a generic processor implementing the system) such that it amounts no more than mere instructions to apply the exception using a generic processor. Mere instructions to apply an exception using a generic processor cannot provide an inventive concept. The claim is not patent eligible.
Claims 11-14, and 18-20 are parallel claims to claims 4-7. Therefore, claims 11-14, and 18-20 are rejected in a similar manner as in the rejection of claims 4-7.
Claim 21 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. This claim recites of wherein performing the encryption operation includes performing the encryption operation by the wireless access point.. Therefore, the limitations of this claim, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can also be performed in the mind. A user can manually determine the encryption operation is performed by a wireless access point.
Claim 22 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. This claim recites of wherein performing the encryption operation includes performing the encryption operation by a source wireless client device. Therefore, the limitations of this claim, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can also be performed in the mind. A user can manually determine the encryption operation is performed by a source wireless client device.
Claim 23 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. This claim recites of wherein the processor is associated with the wireless access point. Therefore, the limitations of this claim, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can also be performed in the mind. A user can manually determine a processor is associated with a wireless access point.
Claim 24 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. This claim recites of wherein the processor is associated with a source wireless client device. Therefore, the limitations of this claim, as drafted, is a process that, under its broadest reasonable interpretation, covers steps that can also be performed in the mind. A user can manually determine a processor is associated with a source wireless client device..
Claims 25 and 26 recite similar limitations as seen in claims 23 and 24. Therefore, claims 25 and 26 are rejected in a similar manner.
The dependent claims 4-7, 11-14, and 18-26 are directed to abstract ideas and do not include additional elements that are sufficient to amount to significantly more than the judicial exception. This judicial exception is not integrated into a practical application. Therefore, the claims are not patent eligible.
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.
Claims 1, 4, 5, 8, 11, 12, 15, 18, 19, and 21-26 are rejected under 35 U.S.C. 103 as being unpatentable over KNECKT (US-20230232218-A1) in view of SANKARAN (US-20190173860-A1), hereinafter KNECKT-SANKARAN.
Regarding claim 1, KNECKT teaches “A method comprising: obtaining a Media Access Control (MAC) protocol data unit (MPDU) that includes a header and a data payload, the header including a source MAC address and a destination MAC address; ([KNECKT, para.0004] “Some embodiments include an apparatus, method, and computer program product for encrypting media access control (MAC) Header fields for Wireless LAN (WLAN) privacy enhancement.”) ([KNECKT, para. 0063] “FIG. 8 illustrates example 800 of transmitter 820 and receiver 830 supporting encryption of MAC header fields for WLAN privacy enhancement, according to some embodiments of the disclosure … Example 800 includes transmitter 820 that receives one or more A-MPDU frames from internet/application 810, supports encryption of MAC header fields for WLAN privacy enhancement, and transmits the one or more A-MPDUs OTA with encrypted MAC header bits 330 of FIG. 3A to receiver 830. Receiver 830 supports decryption of MAC header fields for WLAN privacy enhancement”) ([KNECKT, para. 0039] “FIG. 3A illustrates MAC frame 300 supporting encryption of MAC header fields for WLAN privacy enhancement”) ([KNECKT, para.0040] “To improve privacy, some embodiments include identifying those certain MAC header fields, inserting the actual values of those certain MAC header fields in MAC header bits 330 as part of payload 340 that is then encrypted as shown in FIG. 3A.”) performing an encryption operation on the MPDU to encapsulate the data payload and at least a portion of the header in an encrypted payload to obfuscate privacy related fields of the MPDU … and adding a [MACsec] header to the [MACsec] payload to generate a [MACsec] frame, the [MACsec] header including a source address corresponding to a wireless access point and a destination address corresponding to a wireless client device, the source address being different from the source MAC address and the destination address being different from the destination MAC address; ([KNECKT, para.0041] “MAC frame 300 can be included in an aggregated MAC protocol data unit (A-MPDU) subframe, and can then be transmitted OTA to a receiver. Since the actual values of those certain MAC header fields in MAC header bits 330 are encrypted when MAC frame 300 is transmitted OTA, even if MAC frame 300 is intercepted (e.g., by an attacker), only the OTA values (e.g., all zeroes, dummy values, or randomized values) are visible obtained. Accordingly, the STA or AP cannot be fingerprinted or identified based on those certain MAC header fields.”) ([KNECKT, para.0063] “FIG. 8 illustrates example 800 of transmitter 820 and receiver 830 supporting encryption of MAC header fields for WLAN privacy enhancement, according to some embodiments of the disclosure. For explanation purposes and not a limitation, FIG. 8 may be described with reference to elements from other figures in the disclosure. For example, transmitter 820 can be AP MLD 110, AP 112, AP 114, AP 116, AP 110 that includes a single transceiver, non-AP MLD STA 120, STA 122, STA 124, STA 126, or STA 140 of FIG. 1 . For example, receiver 830 can be AP MLD 110, AP 112, AP 114, AP 116, AP 110 that includes a single transceiver, non-AP MLD STA 120, STA 122, STA 124, STA 126, or STA 140 of FIG. 1 .”) ([KNECKT, para. 0004] “A client device (e.g., wireless station”) ([KNECKT, para.0034] “Some embodiments include encrypting actual values of the MAC header fields (e.g., PM, MD, EOSP) in the encrypted payload of a MAC frame. The MAC header fields that previously contained the actual values can be set to all zeroes (e.g., zeroed out), include a dummy value (e.g., a predetermined value), and/or include a randomized value.”) ([KNECKT, para.0067] “transmitter 820 randomizes fields in Frame Control field 310 and/or QoS Control field 320 that correspond to MAC header bits 330. Namely, the following fields may be populated with corresponding OTA values and/or patterns: … Other fields in the MAC header that can be randomized and replaced with an OTA value include transmitter address (TA), receiver address (RA), sequence number (SN), packet number (PN), and a Salt.”) … and wirelessly transmitting, by the wireless access point, the [MACsec] frame to the wireless client device over a network. ([KNECKT, para. 0038] “Transceiver(s) 270 transmits and receives wireless communications signals including wireless communications supporting encryption of MAC header fields for WLAN privacy enhancement according to some embodiments, and may be coupled to one or more antennas 290 (e.g. 290a, 290b)”) ([KNECKT, para.0106] “At 1160, system 200 can transmit the A-MPDU subframe over the air.”) ([KNECKT, para.0063] “FIG. 8 illustrates example 800 of transmitter 820 and receiver 830 supporting encryption of MAC header fields for WLAN privacy enhancement, … For example, transmitter 820 can be AP MLD 110, AP 112, AP 114, AP 116, AP 110 that includes a single transceiver, non-AP MLD STA 120, STA 122, STA 124, STA 126, or STA 140 of FIG. 1 . For example, receiver 830 can be AP MLD 110, AP 112, AP 114, AP 116, AP 110 that includes a single transceiver, non-AP MLD STA 120, STA 122, STA 124, STA 126, or STA 140 of FIG. 1 .”)
However, KNECKT does not teach “wherein performing the encryption operation comprises performing a MAC security (MACsec) operation on the MPDU to encapsulate the data payload and at least the source MAC address and the destination MAC address of the MPDU within a MACsec payload”.
In analogous teaching SANKARAN teaches “wherein performing the encryption operation comprises performing a MAC security (MACsec) operation on the MPDU to encapsulate the data payload and at least the source MAC address and the destination MAC address of the MPDU within a MACsec payload” ([SANKARAN, para. 0014] “To address these issues, the present disclosure describes various examples for using MACsec to encrypt tunnel data packets. In an example, a Media Access Control (MAC) Security (MACsec) capable device may receive a data packet from a host device for tunneling to a controller in a network. The MACsec capable device may encapsulate the data packet with an encapsulation header to generate an encapsulated data packet.”) ([SANKARAN, para. 0026] “An example encapsulation header 200 along with a data packet 220 is illustrated in FIG. 2. The encapsulation header 200 may comprise a destination address field 202 that may include a destination MAC address, a source address field 204 that may include a source MAC address of the port on MACsec capable device 104 that receives the data packet, an Encaps length or type field 206 which may identify, for example, the protocol contained in the payload (for example, IPv4), a pad field 208 for byte alignment, a VLAN tag field 210, and a control byte field 212.”)
Thus, given the teaching of SANKARAN, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine the teaching of MACsec by SANKARAN into the teaching of a method of obtaining a data packet unit, encrypting the date packet unit, and wirelessly transmitting the data packet unit by KNECKT. One of ordinary skill in the art would have been motivated to do so because SANKARAN recognizes the benefits of MACsec ([SANKARAN, para. 0011] “Enterprises are increasingly focusing on securing networks from the inside, and MACsec as layer 2 security protocol may help fill this gap. To ensure the security of wired networks, it may be desirable to implement the MACsec functionality on newer generation of network infrastructure switches.”)
Regarding claim 8, this claim recites of a apparatus comprising: a memory; a network interface configured to enable network communication; and a processor, wherein the processor is configured to perform operations of method claim 1. Therefore, claim 8 is rejected in a similar manner as in the rejection of claim 1. KNECKT further teaches of “… a network interface configured to enable network communication; and a processor …” ([KNECKT, para.0038] “System 200 includes one or more processors 265, transceiver(s) 270, communication interface 275, communication infrastructure 280, memory 285, and antenna 290. Memory 285 may include random access memory (RAM) and/or cache, and may include control logic (e.g., computer instructions) and/or data. One or more processors 265 can execute the instructions stored in memory 285 to perform operations enabling wireless system 200 to transmit and receive wireless communications, including the functions for encryption of MAC header fields for WLAN privacy enhancement herein.”)
Regarding claim 15, this claim recites of one or more non-transitory computer readable storage media encoded with instructions that, when executed by a processor, cause the processor to execute the method of claim 1. Therefore, claim 15 is rejected in a similar manner as in the rejection of claim 1. KNECKT further teaches of “one or more non-transitory computer readable storage media encoded with instructions that, when executed by a processor, cause the processor to” ([KNECKT, para. 0038] “System 200 includes one or more processors 265, transceiver(s) 270, communication interface 275, communication infrastructure 280, memory 285, and antenna 290. Memory 285 may include random access memory (RAM) and/or cache, and may include control logic (e.g., computer instructions) and/or data. One or more processors 265 can execute the instructions stored in memory 285 to perform operations enabling wireless system 200 to transmit and receive wireless communications, including the functions for encryption of MAC header fields for WLAN privacy enhancement herein.”)
Regarding claims 4, 11, and 18, KNECKT-SANKARAN teaches all limitations of claims 1, 8, and 17. KNECKT further teaches “the … header includes an over-the-air MAC (otaMAC) address of the wireless client device as the destination address and an otaMAC address of the wireless access point device as the source address. ([KNECKT, para. 0005] “The processor of the STA and/or the AP can be configured to set a bit of real time Media Access Control (MAC) header in a payload of an aggregated MAC Protocol Data Unit (A-MPDU) subframe to an actual value associated with a power management (PM) field of a header of the A-MPDU subframe, and then encrypt the payload. After encrypting the payload, the processor can set the PM field in the header to an over the air (OTA) PM value, and transmit the A-MPDU subframe (e.g., over the air.) ”) ([KNECKT, para. 0067] “Namely, the following fields may be populated with corresponding OTA values and/or patterns: TID field 452, A-MSDU present field 458, retry field 412, PM field 414, MD field 416, EOSP field 454, ACK policy indicator 456, and/or +HTC field 418. Other fields in the MAC header that can be randomized and replaced with an OTA value include transmitter address (TA), receiver address (RA), sequence number (SN), packet number (PN), and a Salt.”) ([KNECKT, abstract] “For example, a transceiver of a station (STA) or an access point (AP) can set a real time Media Access Control (MAC) header bit in a payload of an aggregated MAC Protocol Data Unit (A-MPDU) subframe”) ([KNECKT, para. 0057] “For example, a transmitter may be AP MLD 110, AP 112”) ([KNECKT, para. 0063] “For example, receiver 830 can be AP MLD 110, AP 112, AP 114, AP 116, AP 110 that includes a single transceiver, non-AP MLD STA 120, STA 122, STA 124, STA 126, or STA 140 of FIG. 1. Transmitter 820 and/or receiver 830 can be system 200 of FIG. 2.”).
SANKARAN teaches of MACsec as seen in the rejection of claim 1. The same rejection and motivation apply.
Regarding claims 5, 12, and 19, KNECKT-SANKARAN teaches all limitations of claims 4, 11, and 18. KNECKT further teaches “wherein the … header includes randomly generated values for the source address and the destination address. ([KNECKT, para. 0054] “AP 510 can determine and set OTA values (e.g., zeroes, dummy value, or randomized value) for EOSP field 454 and/or MD field 416 in header 315 before transmission OTA.”) ([KNECKT, para. 0067] “Other fields in the MAC header that can be randomized and replaced with an OTA value include transmitter address (TA), receiver address (RA), sequence number (SN), packet number (PN), and a Salt.”)
SANKARAN teaches of MACsec as seen in the rejection of claim 3. The same rejection and motivation apply.
Regarding claim 21, KNECKT-SANKARAN teaches all limitations of claim 1. KNECKT further teaches “wherein performing the encryption operation includes performing the encryption operation by the wireless access point.” ([KNECKT, abstract] “The transceiver can encrypt the payload, set the PM field to an over the air (OTA) PM value, and transmit the A-MPDU subframe over the air.”) ([KNECKT, para.0063] “FIG. 8 illustrates example 800 of transmitter 820 and receiver 830 supporting encryption of MAC header fields for WLAN privacy enhancement, according to some embodiments of the disclosure. For explanation purposes and not a limitation, FIG. 8 may be described with reference to elements from other figures in the disclosure. For example, transmitter 820 can be AP MLD 110, AP 112, AP 114, AP 116, AP 110 that includes a single transceiver, non-AP MLD STA 120, STA 122, STA 124, STA 126, or STA 140 of FIG. 1 . For example, receiver 830 can be AP MLD 110, AP 112, AP 114, AP 116, AP 110 that includes a single transceiver, non-AP MLD STA 120, STA 122, STA 124, STA 126, or STA 140 of FIG. 1 .”)
Regarding claim 22, KNECKT-SANKARAN teaches all limitations of claim 1. KNECKT further teaches “wherein performing the encryption operation includes performing the encryption operation by a source wireless client device.” ([KNECKT, abstract] “The transceiver can encrypt the payload, set the PM field to an over the air (OTA) PM value, and transmit the A-MPDU subframe over the air.”) ([KNECKT, para.0063] “FIG. 8 illustrates example 800 of transmitter 820 and receiver 830 supporting encryption of MAC header fields for WLAN privacy enhancement, according to some embodiments of the disclosure. For explanation purposes and not a limitation, FIG. 8 may be described with reference to elements from other figures in the disclosure. For example, transmitter 820 can be AP MLD 110, AP 112, AP 114, AP 116, AP 110 that includes a single transceiver, non-AP MLD STA 120, STA 122, STA 124, STA 126, or STA 140 of FIG. 1 . For example, receiver 830 can be AP MLD 110, AP 112, AP 114, AP 116, AP 110 that includes a single transceiver, non-AP MLD STA 120, STA 122, STA 124, STA 126, or STA 140 of FIG. 1 .”)
Regarding claims 23 and 25, KNECKT-SANKARAN teaches all limitations of claims 8 and 15. KNECKT further teaches “wherein the processor is associated with the wireless access point.” ([KNECKT, para.0063] “FIG. 8 illustrates example 800 of transmitter 820 and receiver 830 supporting encryption of MAC header fields for WLAN privacy enhancement, according to some embodiments of the disclosure. For explanation purposes and not a limitation, FIG. 8 may be described with reference to elements from other figures in the disclosure. For example, transmitter 820 can be AP MLD 110, AP 112, AP 114, AP 116, AP 110 that includes a single transceiver, non-AP MLD STA 120, STA 122, STA 124, STA 126, or STA 140 of FIG. 1 . For example, receiver 830 can be AP MLD 110, AP 112, AP 114, AP 116, AP 110 that includes a single transceiver, non-AP MLD STA 120, STA 122, STA 124, STA 126, or STA 140 of FIG. 1 .”)
Regarding claims 24 and 26, KNECKT-SANKARAN teaches all limitations of claims 8 and 15. KNECKT further teaches “wherein the processor is associated with a source wireless client device.” ([KNECKT, para.0063] “FIG. 8 illustrates example 800 of transmitter 820 and receiver 830 supporting encryption of MAC header fields for WLAN privacy enhancement, according to some embodiments of the disclosure. For explanation purposes and not a limitation, FIG. 8 may be described with reference to elements from other figures in the disclosure. For example, transmitter 820 can be AP MLD 110, AP 112, AP 114, AP 116, AP 110 that includes a single transceiver, non-AP MLD STA 120, STA 122, STA 124, STA 126, or STA 140 of FIG. 1 . For example, receiver 830 can be AP MLD 110, AP 112, AP 114, AP 116, AP 110 that includes a single transceiver, non-AP MLD STA 120, STA 122, STA 124, STA 126, or STA 140 of FIG. 1 .”) ([KNECKT, para. 0004] “A client device (e.g., wireless station”).
Claims 6 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over KNECKT (US-20230232218-A1) in view of SINN (US-10826876-B1).
Regarding claims 6 and 13, KNECKT teaches all limitations of claims 1 and 8. However, KNECKT does not teach “wherein padding is added to the data payload so that a size of the MPDU is a predetermined size, wherein the predetermined size is determined by the wireless access point and wherein the padding is added by a second wireless client device that is a source of the MPDU.”
In analogous teaching SINN teaches “wherein padding is added to the data payload so that a size of the MPDU is a predetermined size, wherein the predetermined size is determined by the wireless access point and wherein the padding is added by a second wireless client device that is a source of the MPDU. ([SINN, col. 5 Lines 25-29] “another example, a packet can be padded out to a Maximum Transmission Unit (MTU) when the packet is followed by a relatively large gap before the next packet. The MTU can be the largest size packet that is allowed for a particular network protocol.”) ([SINN, col. 4 Lines 46-53] “The network devices 110 and 150 can communicate with physical transceiver devices (PHYs) 120 and 140, respectively. As one example, network device 110 can transmit and receive unencrypted link layer packets to and from the PHY 120; and the network device 150 can transmit and receive unencrypted link layer packets to and from the PHY 140”) ([SINN, col. 11 Lines 8-13] “The stream of packets 500 can be processed by the transmit data path of the physical transceiver device to generate the stream of packets 510. The stream of packets 510 has been padded and filled with filler packets so that the link utilization of the stream of packets 510 is closer to 100%”) ([SINN, col. 4 Lines 37-43] “types of network devices 110 and 150 can include … wireless network interface controllers, modems, ISDN terminal adapters, line drivers, wireless access points,”)
Thus, given the teaching of SINN, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine the teaching of padding being added to a data payload by SINN into the teaching of a method of obtaining a data packet unit, encrypting the date packet unit, and wirelessly transmitting the data packet unit by KNECKT. One of ordinary skill in the art would have been motivated to do so because SINN recognizes the need to improve security of computer systems ([SINN, col. 1 Lines 11-15] “As the complexity and ubiquity of distributed computer systems increases, however, maintaining information security can become more challenging even as users of the distributed computer systems place a higher value on the security of their information.”) ([SINN, col. 2 Lines 58-63] “As described herein, the characteristics of network traffic can be encrypted or obscured. In particular, network traffic patterns can be obscured during transmission at the link level by adding padding to frames so that the size of the packets is hidden. The padding can be encrypted so that it appears as random bits to an outside observer.”)
Claims 7, 14, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over KNECKT (US-20230232218-A1) in view of LEE (US-20160285834-A1).
Regarding claims 7, 14, and 20, KNECKT teaches all limitations of claims 1, 8, and 15. However, KNECKT does not teach “wherein wirelessly transmitting comprises wirelessly transmitting the MACsec frame according to an IEEE 802.11 wireless networking protocol.”.
In analogous teaching LEE teaches “wherein wirelessly transmitting comprises wirelessly transmitting the MACsec frame according to an IEEE 802.11 wireless networking protocol. ([LEE, para. 0006] “A wireless network, for example a Wireless Local Area Network (WLAN), such as a Wi-Fi network (IEEE 802.11) may include an access point (AP) that may communicate with at least one station (STA) or mobile device.”) ([LEE, para. 0049] “The wireless stations 115 in these examples may communicate according to the WLAN radio and baseband protocol including physical and MAC layers from IEEE 802.11, and its various versions including, but not limited to, 802.11b, 802.11g, 802.11a, 802.11n, 802.11ac, 802.11ad, 802.11ah, and the like. In other implementations, other peer-to-peer connections and/or ad hoc networks may be implemented within WLAN network 100.”)
Thus, given the teaching of LEE, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention to combine the teaching of IEEE 802.11 wireless networking protocol by LEE into the teaching of a method of obtaining a data packet unit, encrypting the date packet unit, and wirelessly transmitting the data packet unit by KNECKT. One of ordinary skill in the art would have been motivated to do so because LEE recognizes the need to improve wireless systems ([LEE, para. 0008] “The described features generally relate to various improved systems, methods, or apparatuses for wireless communications. Such systems, methods, or apparatuses may provide for hiding source or destination addresses to improve privacy and prevent an observer from determining the source or destination of a data frame.”)
Pertinent Art
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
HUTCHISON (US-8250370-B1): This prior art teaches of a media access control (MAC) security apparatus including an encryption/decryption engine and an authentication engine. The encryption/decryption engine is configured to generate encrypted data based on received packets. The authentication engine is configured to perform authentication in response to the encrypted data. The encryption/decryption engine includes an advanced encryption standard (AES) engine configured to form cryptographic primitives. The AES engine is configured to enter a reduced power consumption state for part of a period during which the encryption/decryption engine is generating encrypted data based on the received packets.
LAVINIO (US-9646143-B2): This prior art teaches of methods for automatically maintaining the anonymity or privacy of a stream of data as it is transmitted over a network or provided for other use, by receiving a data stream in real-time from an original source and identifying a data subset of interest within the original data stream. The data subset of interest is segregated from the data stream for either obfuscating at least a portion of the data subset in accordance with certain criteria or encrypting it. The data subset is obfuscated or encrypted for purpose of transmission over the network or for testing and reunited at a target source with the remainder of the data stream.
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 AFAQ ALI whose telephone number is (571)272-1571. The examiner can normally be reached Mon - Fri 7:30am - 5: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, ALI SHAYANFAR can be reached at (571) 270-1050. 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.
/A.A./
09/27/2026
/AFAQ ALI/Examiner, Art Unit 2434
/NOURA ZOUBAIR/Primary Examiner, Art Unit 2434
