Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
2. EXAMINER’S NOTE: The claims have been reviewed and considered under the new guidance pursuant to the 2019 Revised Patent Subject Matter Eligibility Guidance (PEG 2019) issued January 7, 2019.
3. This communication is in response to Applicant’s RCE Amendment filed on 17 March 2026. Claims 1, 6, 8, 13, 15, and 20 have been amended. Claims 1-20 remain pending.
Continued Examination Under 37 CFR 1.114
4. A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 17 March 2026 has been entered.
Response to Arguments
5. Applicant’s arguments, see pages 8-10, filed 17 March 2026, with respect to the rejection of claims 1-20 in view of Jiang et al. in view of Ho et al. in further view of Wentink et al. have been fully considered, but are moot in view of the new grounds of rejection.
6. A new ground of rejection is hereby presented in view of Batra et al. (Pub No. 2005/0078598) for teaching newly added claim limitations “wherein the service field extension value is located after a service field value to extend a scrambler seed”.
Claim Rejections - 35 USC § 103
7. 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.
8. 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.
9. Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Jiang et al. (Pub No. 2022/0132306) in view of Seok et al. (Pub No. 2014/0286226) and in further view of Batra et al. (Pub No. 2005/0078598).
Referring to the rejection of claim 1, Jiang et al. discloses a method, comprising:
by a first communication device: (See Jiang et al., para. 65-66, i.e., first electronic device is disclosed as the access point, item 112)
encrypting a payload to be included in a physical layer protocol data unit (PPDU) frame; (See Jiang et al., para. 66, 93, and 96, i.e., the first electronic device, disclosed as the access point, item 112 may encrypt an A-control subfield and provide a frame addressed to the second electronic device disclosed as the electronic device, item 110-1. The A-control subfield is encrypted with the payload data and EHT stations may always encrypt the A-control subfield in a EHT PPDU or a legacy PPDU)
determining a PPDU frame type based at least in part on an association with a second communication device; (See Jiang et al., para. 66-68, i.e., the PPDU frame associated with the second electronic device comprises a MAC header and the MAC header includes the A-control subfield that is encrypted and the frame may include a preamble that indicates whether the A-control subfield is encrypted)
However, Jiang et al. fail to disclose selecting a PPDU number for obfuscation of a field of a medium access control (MAC) header of the PPDU frame.
Seok et al. discloses a method for transmitting and receiving a frame in a wireless local area network system.
Seok et al. discloses selecting a PPDU number for obfuscation of a field of a medium access control (MAC) header of the PPDU frame; (See Seok et al., para. 94, i.e., a scrambler can use seven scrambler initialization bits to generate a scrambler seed and use the seven bits (i.e., short PPDU number) for obfuscating the MAC header in the payload)
Seok et al. discloses obfuscating the field of the MAC header; (See Seok et al., para. 94, i.e., the seven bits can be used for obfuscating the MAC header in the payload)
Seok et al. discloses and transmitting the PPDU frame to the second communication device. (See Seok et al., para. 71 and 97, i.e., transmitting the PPDU to the second communication device disclosed as mobile STA)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date the claimed invention was made to combine Jiang et al.’s wireless communication for protecting a high-throughput (HT) control subfield modified with Seok et al.’s method for transmitting and receiving a frame in a wireless local area network system.
Motivation for such an implementation would enable obfuscation of a service field of MAC header by using bit sequence for initializing a scrambler. (See Seok et al., paragraph 70)
The combination of Jiang et al. and Seok et al. fail to disclose selecting a service field extension value based at least in part on the PPDU frame type, wherein the service field extension value is located after a service field value to extend a scrambler seed and generating the scrambler seed for the PPDU frame using the service field value and the service field extension value and scrambling the encrypted payload using the scrambler seed.
Batra et al. discloses a method and system for a new PLCP format with a band extension field that keeps the PLCP preamble and the PLCP header for both a 3-band and 7-band extension modes.
Batra et al. discloses selecting a service field extension value based at least in part on the PPDU frame type, wherein the service field extension value is located after a service field value to extend a scrambler seed; (See Batra et al., para. 41, 48-51, Tables 1-2 and Fig. 7 and 9, i.e., adding an extension bits field for various extensions of the MB-OFDM physical layer. The PLCP frame which is equivalent to the PPDU frame discloses a three bit field, called the extension field which indicates whether the device should stay in a 3-band mode or switch to a 7-band mode. By allocating three bits, we are also allowing for future expansion into more bands, such as an 11-band mode. The PLCP Length field shall be an unsigned 12-bit integer that indicates the number of octets in the frame payload. The bits S1-S2 shall be set according to the scrambler seed identifier value. This two-bit value corresponds to the seed value chosen for the data scrambler. The Extension field shall be set according to the values in Table 2. The Extension field located after the service field shows a 3-bit band extension and Bits 29-31 shall encode the extension field)
Batra et al. discloses generating the scrambler seed for the PPDU frame using the service field value and the service field extension value; (See Batra et al., para. 41, 48-51, Tables 1-2 and Fig. 7 and 9, i.e., the service field includes scrambler initialization bits (bits 2-6) and reserved bits (bits 0, 1, 8, 21, 22, 25, 28, and 32-39) wherein the reserved bits indicate a bandwidth value and the scrambler uses the scrambler initialization bits to generate the scrambler seed and then the scrambler seed is extended by increasing bits using the extension field (bits 29-31) shall encode the extension field and bits 23-24 shall encode the initial state of the scrambler)
Batra et al. discloses and scrambling the encrypted payload using the scrambler seed. (See Batra et al., para. 41, 48-51, Tables 1-2 and Fig. 7 and 9, the scrambler bits S1-S2 encodes the frame payload according to the scrambler seed and the two-bit value corresponds to the seed value chosen for the data scrambler)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date the claimed invention was made to combine Jiang et al.’s wireless communication for protecting a high-throughput (HT) control subfield and Seok et al.’s method for transmitting and receiving a frame in a wireless local area network system modified with Batra et al.’s method and system for a new PLCP format with a band extension field that keeps the PLCP preamble and the PLCP header for both a 3-band and 7-band extension modes.
Motivation for such an implementation would enable the information indicating if the packet is in the 3-band mode or the 7-band mode can be embedded in the PLCP header, thereby improving the decoding performance of this information and reducing the packet errors. (See Batra et al., paragraph 39)
Referring to the rejection of claims 2, 9, and 16, (Jiang et al. and Seok et al. modified with Batra et al.) discloses wherein the association comprises an exchange of one or more configuration parameters between the first communication device and the second communication device. (See Seok et al., para. 32-34 and 36, i.e., generating encryption keys by exchanging four extensible authentication protocol (EAP) over LAN (EAPoL) messages during a security protocol known as the four-way handshake for protecting the unencrypted information exchanged prior to association and for verifying the MAC addresses of the AP and the STA)
The rationale for combining Jiang et al. and Seok et al. in view of Batra et al. is the same as claim 1.
Referring to the rejection of claims 3, 10, and 17, (Jiang et al. and Seok et al. modified with Batra et al.) discloses wherein obfuscating the field of the MAC header comprises randomizing the payload using a hash function based on the service field value. (See Seok et al., para. 94, i.e., the scrambler can use the same seven bits (e.g., short PPDU number) as a salt for obfuscating the MAC header included in the payload and the salt is a value used as an input for a one-way hashing function and the seven bits can be randomized)
The rationale for combining Jiang et al. and Seok et al. in view of Batra et al. is the same as claim 1.
Referring to the rejection of claims 4, 11, and 18, (Jiang et al. and Seok et al. modified with Batra et al.) discloses further comprising signaling a scrambling capability to the second communication device. (See Seok et al., para. 116, 216, and 235, i.e., signaling a scrambling sequence within the transmitting address field of a MAC address of the STA (i.e., second communication device) transmitting the frame)
The rationale for combining Jiang et al. and Seok et al. in view of Batra et al. is the same as claim 1.
Referring to the rejection of claims 5, 12, and 19, (Jiang et al. and Seok et al. modified with Batra et al.) discloses wherein the method further comprises: receiving a MAC service data unit (MSDU) comprising the payload; and adding a sequence number (SN) and a packet number (PN) to the payload. (See Jiang et al., para. 93, 99, and 102-103, i.e., receiving a MAC service data unit (MSDU) comprising a payload and adding a sequence number (SN) and packet number (PN) to the encrypted payload)
The rationale for combining Jiang et al. and Seok et al. in view of Batra et al. is the same as claim 1.
Referring to the rejection of claims 6, 13, and 20, (Jiang et al. and Seok et al. modified with Batra et al.) discloses wherein the method further comprises applying an offset to the MAC header based on a selected key. (See Seok et al., para. 76 and 116-117, i.e., applying an offset to the MAC header based on the sequence number and the fragment numbers assigned to the MAC header frame)
The rationale for combining Jiang et al. and Seok et al. in view of Batra et al. is the same as claim 1.
Referring to the rejection of claims 7 and 14, (Jiang et al. and Seok et al. modified with Batra et al.) discloses wherein the service field value comprises at least two octets. (See Seok et al., para. 238, 241, and 244, i.e., the service field value comprises two octets)
The rationale for combining Jiang et al. and Seok et al. in view of Batra et al. is the same as claim 1.
Referring to the rejection of claim 8, (Jiang et al. and Seok et al. modified with Batra et al.) discloses a first communication device, comprising:
one or more processors; (See Jiang et al., para. 52, i.e., processor, item 1510)
and one or more non-transitory computer-readable media including instructions that, when executed by the one or more processors, cause the one or more processors to: (See Jiang et al., para. 52, i.e., memory, item 1512)
encrypt a payload to be included in a physical layer protocol data unit (PPDU) frame; (See Jiang et al., para. 66, 93, and 96, i.e., the first electronic device, disclosed as the access point, item 112 may encrypt an A-control subfield and provide a frame addressed to the second electronic device disclosed as the electronic device, item 110-1. The A-control subfield is encrypted with the payload data and EHT stations may always encrypt the A-control subfield in a EHT PPDU or a legacy PPDU)
determine a PPDU frame type based at least in part on an association with a second communication device; (See Jiang et al., para. 66-68, i.e., the PPDU frame associated with the second electronic device comprises a MAC header and the MAC header includes the A-control subfield that is encrypted and the frame may include a preamble that indicates whether the A-control subfield is encrypted)
However, Jiang et al. fail to disclose selecting a PPDU number for obfuscation of a field of a medium access control (MAC) header of the PPDU frame.
Seok et al. discloses a method for transmitting and receiving a frame in a wireless local area network system.
Seok et al. discloses select a PPDU number for obfuscation of a field of a medium access control (MAC) header of the PPDU frame; (See Seok et al., para. 94, i.e., a scrambler can use seven scrambler initialization bits to generate a scrambler seed and use the seven bits (i.e., short PPDU number) for obfuscating the MAC header in the payload)
Seok et al. discloses obfuscate the field of the MAC header; (See Seok et al., para. 94, i.e., the seven bits can be used for obfuscating the MAC header in the payload)
Seok et al. discloses and transmit the PPDU frame to the second communication device. (See Seok et al., para. 71 and 97, i.e., transmitting the PPDU to the second communication device disclosed as mobile STA)
The combination of Jiang et al. and Seok et al. fail to disclose select a service field extension value based at least in part on the PPDU frame type, wherein the service field extension value is located after a service field value to extend a scrambler seed and generate the scrambler seed for the PPDU frame using the service field value and the service field extension value and scramble the encrypted payload using the scrambler seed.
Batra et al. discloses a method and system for a new PLCP format with a band extension field that keeps the PLCP preamble and the PLCP header for both a 3-band and 7-band extension modes.
Batra et al. discloses select a service field extension value based at least in part on the PPDU frame type, wherein the service field extension value is located after a service field value to extend a scrambler seed; (See Batra et al., para. 41, 48-51, Tables 1-2 and Fig. 7 and 9, i.e., adding an extension bits field for various extensions of the MB-OFDM physical layer. The PLCP frame which is equivalent to the PPDU frame discloses a three bit field, called the extension field which indicates whether the device should stay in a 3-band mode or switch to a 7-band mode. By allocating three bits, we are also allowing for future expansion into more bands, such as an 11-band mode. The PLCP Length field shall be an unsigned 12-bit integer that indicates the number of octets in the frame payload. The bits S1-S2 shall be set according to the scrambler seed identifier value. This two-bit value corresponds to the seed value chosen for the data scrambler. The Extension field shall be set according to the values in Table 2. The Extension field located after the service field shows a 3-bit band extension and Bits 29-31 shall encode the extension field)
Batra et al. discloses generate the scrambler seed for the PPDU frame using the service field value and the service field extension value; (See Batra et al., para. 41, 48-51, Tables 1-2 and Fig. 7 and 9, i.e., the service field includes scrambler initialization bits (bits 2-6) and reserved bits (bits 0, 1, 8, 21, 22, 25, 28, and 32-39) wherein the reserved bits indicate a bandwidth value and the scrambler uses the scrambler initialization bits to generate the scrambler seed and then the scrambler seed is extended by increasing bits using the extension field (bits 29-31) shall encode the extension field and bits 23-24 shall encode the initial state of the scrambler)
Batra et al. discloses and scramble the encrypted payload using the scrambler seed. (See Batra et al., para. 41, 48-51, Tables 1-2 and Fig. 7 and 9, the scrambler bits S1-S2 encodes the frame payload according to the scrambler seed and the two-bit value corresponds to the seed value chosen for the data scrambler)
The rationale for combining Jiang et al. and Seok et al. in view of Batra et al. is the same as claim 1.
Referring to the rejection of claim 15, (Jiang et al. and Seok et al. modified with Batra et al.) discloses one or more non-transitory, computer-readable media having stored thereon a sequence of instructions which, when executed, cause one or more processors to:
encrypt a payload to be included in a physical layer protocol data unit (PPDU) frame; (See Jiang et al., para. 66, 93, and 96, i.e., the first electronic device, disclosed as the access point, item 112 may encrypt an A-control subfield and provide a frame addressed to the second electronic device disclosed as the electronic device, item 110-1. The A-control subfield is encrypted with the payload data and EHT stations may always encrypt the A-control subfield in a EHT PPDU or a legacy PPDU)
determine a PPDU frame type based at least in part on an association with a second communication device; (See Jiang et al., para. 66-68, i.e., the PPDU frame associated with the second electronic device comprises a MAC header and the MAC header includes the A-control subfield that is encrypted and the frame may include a preamble that indicates whether the A-control subfield is encrypted)
However, Jiang et al. fail to disclose selecting a PPDU number for obfuscation of a field of a medium access control (MAC) header of the PPDU frame.
Seok et al. discloses a method for transmitting and receiving a frame in a wireless local area network system.
Seok et al. discloses select a PPDU number for obfuscation of a field of a medium access control (MAC) header of the PPDU frame; (See Seok et al., para. 94, i.e., a scrambler can use seven scrambler initialization bits to generate a scrambler seed and use the seven bits (i.e., short PPDU number) for obfuscating the MAC header in the payload)
Seok et al. discloses obfuscate the field of the MAC header; (See Seok et al., para. 94, i.e., the seven bits can be used for obfuscating the MAC header in the payload)
Seok et al. discloses and transmit the PPDU frame to the second communication device. (See Seok et al., para. 71 and 97, i.e., transmitting the PPDU to the second communication device disclosed as mobile STA)
The combination of Jiang et al. and Seok et al. fail to disclose select a service field extension value based at least in part on the PPDU frame type, wherein the service field extension value is located after a service field value to extend a scrambler seed and generate the scrambler seed for the PPDU frame using the service field value and the service field extension value and scramble the encrypted payload using the scrambler seed.
Batra et al. discloses a method and system for a new PLCP format with a band extension field that keeps the PLCP preamble and the PLCP header for both a 3-band and 7-band extension modes.
Batra et al. discloses select a service field extension value based at least in part on the PPDU frame type, wherein the service field extension value is located after a service field value to extend a scrambler seed; (See Batra et al., para. 41, 48-51, Tables 1-2 and Fig. 7 and 9, i.e., adding an extension bits field for various extensions of the MB-OFDM physical layer. The PLCP frame which is equivalent to the PPDU frame discloses a three bit field, called the extension field which indicates whether the device should stay in a 3-band mode or switch to a 7-band mode. By allocating three bits, we are also allowing for future expansion into more bands, such as an 11-band mode. The PLCP Length field shall be an unsigned 12-bit integer that indicates the number of octets in the frame payload. The bits S1-S2 shall be set according to the scrambler seed identifier value. This two-bit value corresponds to the seed value chosen for the data scrambler. The Extension field shall be set according to the values in Table 2. The Extension field located after the service field shows a 3-bit band extension and Bits 29-31 shall encode the extension field)
Batra et al. discloses generate the scrambler seed for the PPDU frame using the service field value and the service field extension value; (See Batra et al., para. 41, 48-51, Tables 1-2 and Fig. 7 and 9, i.e., the service field includes scrambler initialization bits (bits 2-6) and reserved bits (bits 0, 1, 8, 21, 22, 25, 28, and 32-39) wherein the reserved bits indicate a bandwidth value and the scrambler uses the scrambler initialization bits to generate the scrambler seed and then the scrambler seed is extended by increasing bits using the extension field (bits 29-31) shall encode the extension field and bits 23-24 shall encode the initial state of the scrambler)
Batra et al. discloses and scramble the encrypted payload using the scrambler seed. (See Batra et al., para. 41, 48-51, Tables 1-2 and Fig. 7 and 9, the scrambler bits S1-S2 encodes the frame payload according to the scrambler seed and the two-bit value corresponds to the seed value chosen for the data scrambler)
The rationale for combining Jiang et al. and Seok et al. in view of Batra et al. is the same as claim 1.
Conclusion
10. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
11. Chen et al. (Pub No. 2021/0329642) discloses systems and methods for wireless communications and, more particularly, to a data scrambler logic circuitry to determine a scrambler initialization bit sequence, or scrambler initialization bits, to transmit a clear to send (CTS) frame in response to receipt of a multi-user request to send (MU-RTS).
12. Chen et al. (Pub No. 2021/0266204) discloses systems, methods, and apparatuses for wireless communication that can be used to reduce the peak-to-average power ratio (PAPR) of data transmissions by increasing the degree of randomness with which data is scrambled for transmission over a wireless medium. In some implementations, a transmitting device may determine a set of scrambling initialization bits, and may generate a scrambling sequence based on the set of scrambling initialization bits and an 11.sup.th-order polynomial.
13. Chu et al. (Pub No. 2021/0336720) discloses systems and method for bandwidth indication, TXOP protection, and bandwidth negotiation in wireless networks.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to COURTNEY D FIELDS whose telephone number is (571)272-3871. The examiner can normally be reached IFP M-F 8am-4:30pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, SHEWAYE GELAGAY can be reached at (571)272-4219. 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.
/COURTNEY D FIELDS/Examiner, Art Unit 2436 April 2, 2026
/SHEWAYE GELAGAY/Supervisory Patent Examiner, Art Unit 2436
Prosecution Insights