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 .
This communication is in response to the amendment filed on 05/22/2026.
Claims 1-20 are pending and are rejected. Claims 1, 5, , 7-9, 11, 15, 17-20 have been amended.
Response to Arguments
Applicant’s arguments with respect to claims 1, 11, and 20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
The term “data packet” has been amended to PPDU. However, the PPDU is considered as the data packet.
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-8 and 10-20 are rejected under 35 U.S.C. 103 as being unpatentable over McKibben et al. (US 12375440 B1), hereafter McKibben in view of Kolekar (US 20250350454 A1).
Regarding claim 1, McKibben teaches a method, comprising:
generating, by a client device, an obfuscated vendor identifier (ID) by applying one or more transformation functions to a real vendor ID (col. 10, lines 24-26, the MAC address may be ciphered (obfuscated) for confidentiality and/or integrity protection in the response and to prevent the MAC address from being read over the air, wherein col. 9, lines 36-37 teaches that the MAC address of the user device can be one of a hardware address, a manufacturer provided address (vendor identifier));
wherein the encrypted message comprises obfuscation data, which, when used, converts the obfuscated vendor ID into the real vendor ID (col. 11, lines 7-9, fig. 4, the network server 135 or 140 decrypts the encrypted MAC address of the user device using a cryptographic key used to cipher an 802.11 layer);
transmitting, by the client device, the encrypted message to an access point (AP) (col. 9, lines 3-5, fig. 4, the network server 135 or 140 receives an encrypted MAC address of the user device 105 in the response message); and
transmitting, by the client device, a physical layer protocol data unit (PPDU) comprising the obfuscated vendor ID to the AP (col. 9, lines 64-66, the user device 105 transmits the Extensible Authentication Protocol (EAP) response directly to the requesting network server 135 or 140).
McKibben does not explicitly teach
[vendor ID] associated with a hardware vendor of the client device;
generating, by the client device, an encrypted message.
Kolekar teaches
[vendor ID] associated with a hardware vendor of the client device ([0061] A-IoT devices use an obfuscation algorithm to transform their identifiers into pseudo-random sequences before transmission; [0064] A-IoT devices transmit obfuscated identifiers (OIDs) instead of actual identifiers; [0086] device identifier (such as an IMSI, serial number, or unique device ID));
generating, by the client device, an encrypted message ([0060] The processes herein to obfuscate only the A-IoT device identifier is different from 3GPP communications such as 5G NR as device identifiers (such as the International Mobile Subscriber Identity (IMSI) or International Mobile Equipment Identity (IMEI)) are transformed at the device level before transmission. Instead, the communication channel is encrypted)..
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention made to include in the McKibben disclosure, generating an obfuscated identifier for a device ID and encrypting, by the client device, data relates to the provider, as taught by Kolekar. One would be motivated to do so to protect A-IoT device IDs and thereby prevent unauthorized tracking and identification while maintaining efficient communication.
Regarding claim 2, McKibben and Kolekar teach the method of claim 1, wherein Kolekar further teaches the obfuscated vendor ID was generated for a first epoch, the method further comprising generating a second obfuscated vendor ID for a second epoch ([0132] transmits multiple responses with distinct obfuscated identifiers, complicating attempts to infer device population or identity.).
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention made to include in the McKibben disclosure, generating obfuscated device ID, by the client device, data relates to the provider, as taught by Kolekar. One would be motivated to do so to protect A-IoT device IDs and thereby prevent unauthorized tracking and identification while maintaining efficient communication.
Regarding claims 3 and 13, McKibben and Kolekar teach all limitations of parent claims 1 and 11, wherein McKibben further teaches the AP and the client device belong to a first basic service set (BSS) that is part of an extended service set (ESS) (col. 6, lines 6-9, in private network 120, the user device 105 attempts to access the private network 120. The access point 110 receives the credentials of the user device 105 and routes the credentials to a network server 115).
Regarding claims 4 and 14, McKibben and Kolekar teach all limitations of parent claims 3 and 13, wherein McKibben further teaches the AP coordinates with other APs within the ESS to determine if the obfuscated vendor ID has been used by other client devices within the ESS (col. 10, lines 35-37, the EAP-RP can also be extended to include the real MAC cached for this session and then to be sent to a second access point).
Regarding claims 5 and 15, McKibben and Kolekar teach tall limitations of parent claims 4 and 14, McKibben further teaches:
transmitting, by the client device, the obfuscated vendor ID to the AP (col. 9, lines 3-5, fig. 4, the network server 135 or 140 receives an encrypted MAC address of the user device 105 in the response message);
receiving, by the client device, a confirmation from the AP, indicating that the obfuscated vendor ID has not been used (col. 9, lines 62-64, the EAP response includes the expanded new type, vendor specific information and the MAC address response); and
subsequent to receiving the confirmation, transmitting, by the client device, the PPDU comprising the obfuscated vendor ID to the AP (col. 10, lines 6-7, if the integrity check succeeds, the EAP authentication process continues).
Regarding claims 6 and 16, McKibben and Kolekar teach all limitations of parent claims 3 and 13, wherein McKibben further teaches the obfuscated vendor ID falls within a range of values allocated to the first BSS within the ESS (col 11, lines 61-64, the contents of the code field 505 for the EAP message is one byte long can include the following values: 1—Request, 2—Response, 3—Success, and 4—Failure).
Regarding claims 7 and 17, McKibben and Kolekar teach all limitations of parent claim 1 and 11, Kolekar further teaches:
generating, by the client device, a temporary address; embedding, by the client device, the temporary address in the PPDU comprising the obfuscated vendor ID ([0079] A-IoT devices are pre-configured with an initial TempID and TempID generation key during onboarding or registration);
transmitting, by the client device, the data PPDU to the AP ([0070] The A-IoT device then transmits this OID to the reader or network in place of its permanent identifier); and
subsequent to the transmission, disposing, by the client device, of the temporary address ([0080] both the A-IoT device and the core network generate a new TempID using a TempID derivation function, incorporating the freshness parameter).
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention made to include in the McKibben disclosure, generating obfuscated device ID, by the client device, data relates to the provider, as taught by Kolekar. One would be motivated to do so to protect A-IoT device IDs and thereby prevent unauthorized tracking and identification while maintaining efficient communication.
Regarding claims 8 and 18, McKibben and Kolekar teach all limitations of parent claims 1 and 11, wherein McKibben further teaches the obfuscated vendor ID is embedded within a vendor-specific physical layer (PHY) extension of the PPDU (co. 11, lines 56-61, the packet 500 also includes a type field 520 and a TypeData field 525. In the EAP packet format the type field 520 and the TypeData field 525 are both included in the data field 530 of the packet).
Regarding claims 10 and 12, McKibben and Kolekar teach all limitations of parent claims 1 and 11, wherein McKibben further teaches the obfuscation data comprises at least one of a cryptographic key or a mapping between the obfuscated vendor ID and the real vendor ID (col. 8, lines 26-29, the cryptographic keying materials used by the user device for protecting the MAC address can be preconfigured or transferred by the network).
Regarding claim 11, McKibben teaches a system of a client device, comprising:
one or more computer processors; and one or more memories collectively containing one or more programs, which, when executed by the one or more computer processors, perform operations (col. 1, lines 37-39, the network server includes at least one processor in communication with at least one memory device), the operations comprising:
generating an obfuscated vendor identifier (ID) by applying one or more transformation functions to a real vendor ID (col. 10, lines 24-26, the MAC address may be ciphered (obfuscated) for confidentiality and/or integrity protection in the response and to prevent the MAC address from being read over the air, wherein col. 9, lines 36-37 teaches that the MAC address of the user device can be one of a hardware address, a manufacturer provided address (vendor identifier));
wherein the encrypted message comprises obfuscation data, which, when used, converts the obfuscated vendor ID into the real vendor ID (col. 11, lines 7-9, fig. 4, the network server 135 or 140 decrypts the encrypted MAC address of the user device using a cryptographic key used to cipher an 802.11 layer);
transmitting the encrypted message to an access point (AP) (col. 9, lines 3-5, fig. 4, the network server 135 or 140 receives an encrypted MAC address of the user device 105 in the response message); and
transmitting, by the client device, a physical layer protocol data unit (PPDU) comprising the obfuscated vendor ID to the AP (col. 9, lines 64-66, the user device 105 transmits the Extensible Authentication Protocol (EAP) response directly to the requesting network server 135 or 140).
McKibben does not explicitly teach
[vendor ID] associated with a hardware vendor of the client device;
generating an encrypted message.
Kolekar teaches
[vendor ID] associated with a hardware vendor of the client device ([0061] A-IoT devices use an obfuscation algorithm to transform their identifiers into pseudo-random sequences before transmission; [0064] A-IoT devices transmit obfuscated identifiers (OIDs) instead of actual identifiers; [0086] device identifier (such as an IMSI, serial number, or unique device ID));
generating an encrypted message ([0060] The processes herein to obfuscate only the A-IoT device identifier is different from 3GPP communications such as 5G NR as device identifiers (such as the International Mobile Subscriber Identity (IMSI) or International Mobile Equipment Identity (IMEI)) are transformed at the device level before transmission. Instead, the communication channel is encrypted)..
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention made to include in the McKibben disclosure, generating an obfuscated identifier for a device ID and encrypting, by the client device, data relates to the provider, as taught by Kolekar. One would be motivated to do so to protect A-IoT device IDs and thereby prevent unauthorized tracking and identification while maintaining efficient communication.
Regarding claim 20, McKibben teaches one or more non-transitory computer-readable media containing, in any combination, computer program code that, when executed by operation of a computer system (col. 18, lines 1-2, computer-executable instructions stored on non-transitory computer-readable media or medium), performs operations comprising:
generating, by a client device, an obfuscated vendor identifier (ID) by applying one or more transformation functions to a real vendor ID (col. 10, lines 24-26, the MAC address may be ciphered (obfuscated) for confidentiality and/or integrity protection in the response and to prevent the MAC address from being read over the air, wherein col. 9, lines 36-37 teaches that the MAC address of the user device can be one of a hardware address, a manufacturer provided address (vendor identifier));
wherein the encrypted message comprises obfuscation data, which, when used, converts the obfuscated vendor ID into the real vendor ID (col. 11, lines 7-9, fig. 4, the network server 135 or 140 decrypts the encrypted MAC address of the user device using a cryptographic key used to cipher an 802.11 layer);
transmitting, by the client device, the encrypted message to an access point (AP) (col. 9, lines 3-5, fig. 4, the network server 135 or 140 receives an encrypted MAC address of the user device 105 in the response message); and
transmitting, by the client device, a physical layer protocol data unit (PPDU) comprising the obfuscated vendor ID to the AP (col. 9, lines 64-66, the user device 105 transmits the Extensible Authentication Protocol (EAP) response directly to the requesting network server 135 or 140).
McKibben does not explicitly teach
[vendor ID] associated with a hardware vendor of the client device;
generating, by the client device, an encrypted message.
Kolekar teaches
[vendor ID] associated with a hardware vendor of the client device ([0061] A-IoT devices use an obfuscation algorithm to transform their identifiers into pseudo-random sequences before transmission; [0064] A-IoT devices transmit obfuscated identifiers (OIDs) instead of actual identifiers; [0086] device identifier (such as an IMSI, serial number, or unique device ID));
generating, by the client device, an encrypted message ([0060] The processes herein to obfuscate only the A-IoT device identifier is different from 3GPP communications such as 5G NR as device identifiers (such as the International Mobile Subscriber Identity (IMSI) or International Mobile Equipment Identity (IMEI)) are transformed at the device level before transmission. Instead, the communication channel is encrypted)..
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention made to include in the McKibben disclosure, generating an obfuscated identifier for a device ID and encrypting, by the client device, data relates to the provider, as taught by Kolekar. One would be motivated to do so to protect A-IoT device IDs and thereby prevent unauthorized tracking and identification while maintaining efficient communication.
Claims 9 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over McKibben et al. (US 12375440 B1), hereafter McKibben in view of Kolekar (US 20250350454 A1)and further in view of Asterjadhi (US 20210345418 A1).
Regarding claims 9 and 19, McKibben and Kolekar teach all limitations of parent claims 8 and 18, McKibben does not explicitly teach
wherein the AP is assigned a first basic service set identifier (BSSID) and a second BSSID, the method further comprising:
embedding, by the client device, the first BSSID and a dynamic address in the PPDU when the vendor-specific physical layer (PHY) extension is not used; and
embedding, by the client device, the second BSSID and the dynamic address in the PPDU when the vendor-specific physical layer (PHY) extension is used.
Asterjadhi teaches
embedding, by the client device, the first BSSID and a dynamic address in the PPDU when the vendor-specific physical layer (PHY) extension is not used; and embedding, by the client device, the second BSSID and the dynamic address in the PPDU when the vendor-specific physical layer (PHY) extension is used ([0042] each of the BSSIDs assigned to the basic service sets BSS1-BSSn may be a unique identifier. The BSSIDs may be used as a filtering address, for example, so that only the wireless stations STAs associated with a given BSS may receive and decode frames or packets intended for reception by wireless devices belonging to or associated with the given BSS).
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention made to include in the McKibben disclosure, assign a different BSSID to the basic service sets, as taught by Asterjadhi. One would be motivated to do so to prioritize the Basic Service Set allocation of resources between multiple.
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 ANH NGUYEN whose telephone number is (571)270-0657. The examiner can normally be reached M-F.
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, Umar Cheema can be reached at 5712703037. 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.
/ANH NGUYEN/Primary Examiner, Art Unit 2458
Prosecution Insights