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 application filed on 08/15/2024.
Claims 1-20 are pending and are rejected.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 11/06/24 and 12/15/25 were filed. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 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 Gao (US 20210336937 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 data packet containing the obfuscated vendor ID to the AP (col. 9, lines 64-66, the user device 105 transmits the Extensible Authentication Protocol (EAP) (a data packet containing the obfuscated vendor ID) response directly to the requesting network server 135 or 140).
McKibben does not explicitly teach
generating, by the client device, an encrypted message.
Gao teaches
generating, by the client device, an encrypted message ([0030] These content provider-specific identifiers may be generated by the client device and encrypted with a public key of the content provider, preventing third parties from indirectly identifying matches).
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 and encrypting, by the client device, data relates to the provider, as taught by Gao. One would be motivated to do so for cookie matching also increases efficiency and better protects user privacy, allowing the client browser or application to render pages faster, with less battery and processor utilization.
Regarding claim 2, McKibben and Gao teach the method of claim 1, wherein Gao 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 ([0032] the content provider-specific identifier or read only cookie (ROC) may be a randomly generated value stored in a lookup table keyed by the domain of the content provider).
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, by the client device, data relates to the provider, as taught by Gao. One would be motivated to do so for cookie matching also increases efficiency and better protects user privacy, allowing the client browser or application to render pages faster, with less battery and processor utilization.
Regarding claims 3 and 13, McKibben and Gao 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 Gao 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 Gao 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 data packet containing 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 Gao 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 Gao teach all limitations of parent claim 1 and 11, Gao further teaches:
generating, by the client device, a temporary address; embedding, by the client device, the temporary address in the data packet containing the obfuscated vendor ID ([0005] the hash input may include a creation time or expiration time for the content provider-specific identifier, which may be concatenated with either input value);
transmitting, by the client device, the data packet to an access point (AP) ([0076] the client device may transmit the set of encrypted ROCs (eROCs) to the intermediary device); and
subsequent to the transmission, disposing, by the client device, of the temporary address ([0039] the client device may retrieve or create a unique identifier specific to each content provider, but repeatable, in that the client device may retrieve or create the same identifier for further requests for a cookie for the content provider).
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, transmit encrypted message to the intermediary server until time is expired, as taught by Gao. One would be motivated to do so for cookie matching also increases efficiency and better protects user privacy, allowing the client browser or application to render pages faster, with less battery and processor utilization.
Regarding claims 8 and 18, McKibben and Gao 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 data packet (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 Gao 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 data packet containing the obfuscated vendor ID to the AP (col. 9, lines 64-66, the user device 105 transmits the Extensible Authentication Protocol (EAP) (a data packet containing the obfuscated vendor ID) response directly to the requesting network server 135 or 140).
McKibben does not explicitly teach
generating an encrypted message.
Gao teaches
generating an encrypted message ([0030] These content provider-specific identifiers may be generated by the client device and encrypted with a public key of the content provider, preventing third parties from indirectly identifying matches).
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 data packet containing the obfuscated vendor ID to the AP (col. 9, lines 64-66, the user device 105 transmits the Extensible Authentication Protocol (EAP) (a data packet containing the obfuscated vendor ID) response directly to the requesting network server 135 or 140).
McKibben does not explicitly teach
generating, by the client device, an encrypted message.
Gao teaches
generating, by the client device, an encrypted message ([0030] These content provider-specific identifiers may be generated by the client device and encrypted with a public key of the content provider, preventing third parties from indirectly identifying matches).
Claims 9 and 19are rejected under 35 U.S.C. 103 as being unpatentable over McKibben et al. (US 12375440 B1), hereafter McKibben in view of Gao (US 20210336937 A1) and further in view of Asterjadhi (US 20210345418 A1).
Regarding claims 9 and 19, McKibben and Gao 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 data packet 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 data packet 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 data packet 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 data packet 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 Gao. One would be motivated to do so to prioritize the Basic Service Set allocation of resources between multiple.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Lal; Raghav (US-20190205936-A1t) and Pandurangan; Senthil (US-20230032814-A1).
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