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
Status of Claims
Claims 1-13, 15-21 are subject to examination. Claim 14 is cancelled.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-13, 15-21 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Amended claim 1 contains following:
PNG
media_image1.png
456
758
media_image1.png
Greyscale
Claims 8 and 15 also contain above amended limitations.
The specification does not implement, “selecting a key for de-obfuscating the obfuscated TSF of the MAC header based at least in part on information associated with the beacon frame, wherein the key for de- obfuscating the obfuscated TSF of the MAC header is changed periodically; de-obfuscating the obfuscated TSF of the MAC header based at least in part on the selected key to determine the TSF value”. As claimed, the key is already selected by the selecting step (for de-obfuscating the obfuscated TSF of the MAC header based at least in part on information associated with the beacon frame). Hence, after the key is selected, the key is changed periodically, the key is no longer based on information associated with the beacon frame. The third step “de-obfuscating …” relies upon “selected key”, however, the key is already changed periodically, after the selection of the key, which is no longer based on information associated with the beacon frame after the periodic change.
The first step contains receiving of a MAC header. Hence, the MAC header is already available and not changed. Hence, the TSF / TSF value of the MAC header also does not change. The specification does not implement periodically changing when the TSF / TSF value of the MAC header also does not change.
The specification does implement “beyond”/ “at least” TSP value and an offset, (for example IP address, etc. as the “at least” means everything else) included in “at least in part on a TSP value and an offset”. The specification does not limit what all is included in “at least in part on a TSP value and an offset”.
The specification does implement “beyond” information, (for example IP address, etc. as the “at least” means everything else) included in “at least in part on information”. The specification also does not limit what all is included in “obfuscated TSP based at least in part on information”.
The specification does implement “beyond” selected key, (for example IP address, etc. as the “at least” means everything else) included in “at least in part on the selected key”. The specification also does not limit what all is included in “obfuscated TSP based at least in part on the selected key”.
Similarly, the specification also does not limit what all is included in “at least in part on a TSP value”.
Removal of “at least” is suggested.
Claim 21 contains, the key is configured to protect the privacy of the offset. However, the specification does not implement the key that is selected (claim 1, second step, selecting …) in which only MAC header with TSF is received (claim 1, receiving step …) and the key is merely selected but does not contain the offset; protects the privacy of the offset.
Claims 2-7 depend upon claim 1, claims 9-13 depend upon claim 8 and claims 16-21 depend upon claim 15 and hence subject to the same rejections.
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 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 of this title, 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.
Claim(s) 1, 8, 15, is/are rejected under 35 U.S.C. 103 as being unpatentable over Mooney et al., US 20220247726 A1 in view of ABRAHAM et al., CN 105706505 A (Filed 2014-11-06), KASSLIN et al., WO 2019139627 A1, and LIU, CN 112825520 A.
Referring to claim(s) 1, 8, 15, Mooney discloses one or more computer-readable media having stored thereon a sequence of instructions that, when executed, cause the processor to: A first communication device, comprising: processor; and one or more computer-readable media having stored thereon a sequence of instructions which, when executed, cause the processor to: A method, comprising: by a first communication device: receiving, from a second communication device, a beacon frame comprising ( a beacon packet that includes obfuscation parameter(s) 195, and send the synchronization packet to network device, para 19)
PNG
media_image2.png
520
616
media_image2.png
Greyscale
obtaining the obfuscation parameter from the controller and based on the obfuscation parameter, de-obfuscating the one or more of the obfuscated personally identifiable information of the first network device or the obfuscated personally identifiable information of the second network device, wherein generating the report includes generating a report that includes one or more of the personally identifiable information of the first network device or the personally identifiable information of the second network device, para 90
an encrypted beacon frame field
[0075] Communications in a network environment can be referred to herein as ‘messages’, ‘messaging’, ‘signaling’, ‘data’, ‘content’, ‘objects’, ‘requests’, ‘queries’, ‘responses’, ‘replies’, etc. which may be inclusive of packets. As referred to herein and in the claims, the term ‘packet’ may be used in a generic sense to include packets, frames, segments, datagrams, and/or any other generic units that may be used to transmit communications in a network environment. Generally, a packet is a formatted unit of data that can contain control or routing information (e.g., source and destination address, source and destination port, etc.) and data, which is also sometimes referred to as a ‘payload’, ‘data payload’, and variations thereof In some embodiments, control or routing information, management information, or the like can be included in packet fields, such as within header(s) and/or trailer(s) of packets. Internet Protocol (IP) addresses discussed herein and in the claims can include any IP version 4 (IPv4) and/or IP version 6 (IPv6) addresses.
selecting a key for de-obfuscating the obfuscated field based at least in part on information associated with the beacon frame, de-obfuscating the obfuscated field based at least in part on the key, and decrypting the encrypted beacon frame field of the beacon frame based at least in part on the field.
[0017] Master controller 140 may be configured to store obfuscation parameter(s) 195 (e.g., salt, network address transformation range, etc.). Obfuscation parameter(s) 195 may include customer-specific credential(s). For example, if a given customer is associated with enterprise network 110, obfuscation parameter(s) 195 may apply to all network devices in enterprise network 110 (e.g., network devices 160(1)-160(4)). The customer may have authority over generation of obfuscation parameter(s) 195, and obfuscation parameter(s) 195 may be exchanged within enterprise network 110 in a covert/hidden/encrypted manner.
[0018] Obfuscation parameter(s) 195 may include any suitable secure hashing mechanism used for encrypted hashing of PII 175(1)-175(4). In one specific example, obfuscation parameter(s) 195 may include a salt that causes multiple network devices to generate the same text output given the same text input for each of the network devices. Obfuscation parameter(s) 195 may further include a network address transformation range (e.g., an IP address transformation range). The network address transformation range may prompt network device 160(1) to anonymize any IP addresses that might be present on network device 160(1), including but not necessarily limited to the IP address used by master controller 140 to communicate with network device 160(1).
Mooney does not specifically mention about, which ABRAHAM discloses, the TSF value and timing synchronization field (TSF) that is based on a TSF value and an offset, determine the TSF value (indicating the timing synchronization function and the global time from the second access point indicating the offset field, indicating the second access point receives the message by the wireless station function of timing synchronization field; indicating by the second access point for determining reliability of the anchor point equipment indicated by the global time of last known GPS time of field, field indicating that the anchor point device and indicates that the anchor point device media access control (MAC) address field, claim 11
According to the first method, each AP in its beacon comprises an information element, the information element comprises an indication about the global time of the timing synchronization function (TSF) offset field, and a field indicative of the actual TSF value. the operation frame 302 may include AP (e.g., AP104a) from the second access point (AP) (e.g., AP104b) receiving a global time indication message. In some implementations, the global time indication may include a TSF offset on a global time. For example, AP104a can be configured to determine or calculate the global time based on the TSF value and TSF offset with the global time. In this way, since the TSF offset associated with the global time, so TSF offset can comprise a global time indication, second para, page 7
the operation frame 304, AP104a can be received from the global time indicated by the second AP (e.g., AP104b) is compared with its own global time value stored. if the global time from the second AP (e.g., AP104b) indicating a later than AP104a storage time of global time value, the method can move to the operation frame 306, 3rd para, page 7
T offset = global time and APTSF (which may be based on the MAC address of the AP) are needed (and final) static shift. can then TSF value is updated, second para, page 8
In operation, STA106a can receive beacons from AP104b, offset of the TSF of the beacon comprises: the AP of the AP with the global time, anchor metric (i.e., anchor weight) recently used with the AP updates its global time associated with the anchor point, the MAC address of the anchor point, and a last known global time received from the anchor. recording the TSF and filled in the value field 506 STA106a can receive the beacon. In addition, the STA can be the information element is sent including the TSF counter. additionally, the information allows the recipient to AP (i.e., AP104a) from STA106a and AP104b receiving the beacon and STA106a transmit any delay between IE500 to AP104a. STA106a can additionally use the received TSF with the global time of the AP of the AP offset and filled in the value field 508. Similarly, STA106a can use the TSF value received by the AP and filled in the value field 510. STA106a can use the anchor metrics with the transmitting AP last anchor point for updating the global time associated with the received global time and MACID, and respectively comparing the values filled in fields 512, 514 and 516. STA106a may then transmit IE500 to AP104a, and AP104a can use the above information to synchronize the global time, last para, page 10).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Mooney to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing the message and timing synchronization field (TSF). The message would enable the data fields added at the beginning of a network packet in order to turn it into a frame to be transmitted across a network for a remote device. In IEEE 802.11 wireless networks, the Timing Synchronization Function (TSF) is a 64-bit microsecond counter and would enable synchronizing the timers of all stations within the same Basic Service Set (BSS).
Mooney and ABRAHAM do not specifically mention about, MAC header, which KASSLIN discloses, (MAC entity of a wireless device transmits a beacon, the beacon’s MAC -header may contain device’s current TSF value, para 103).
One of ordinary skilled in the art would readily know what MAC header is and what it is used for.
In networking, the MAC header (or MAC header field) is the first part of a data link layer frame that contains control information about the frame itself. It is part of the MAC (Media Access Control) sublayer and is used to manage how frames are transmitted and received over a shared medium.
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Mooney to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing the MAC header. The MAC header would enable carry a value of a parameter that would be received and used for further processing and perform an action.
Mooney, KASSLIN and ABRAHAM do not specifically mention about, Changed periodically, which LIU discloses, last para, page 6. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Mooney to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing periodically updating the key. This would improve the privacy of the privacy data associated with the key, first para, page 7).
Referring to claim(s) 21, the offset is cited in claim 1. LIU also disclose, which LIU discloses wherein the key that changes periodically is configured to protect the privacy of the information, last para, page 6.
Claim(s) 2, 9, 16, is/are rejected under 35 U.S.C. 103 as being unpatentable over Mooney et al., US 20220247726 A1 in view of ABRAHAM, GAO, KASSLIN and LIU.
Referring to claim(s) 2, 9, 16, Mooney, and ABRAHAM, GAO, KASSLIN and LIU does not disclose, which GAO discloses determining whether the beacon frame comprises a second communication device address; determining whether the first communication device is an intended recipient of the beacon frame based at least in part on whether the beacon frame comprises the second communication device address; determining whether to discard the beacon frame based at least in part on whether the second communication device is the intended recipient of the beacon frame; and determining whether to decrypt the encrypted beacon frame field based at least in part on determining whether to discard the beacon frame (
PNG
media_image3.png
614
460
media_image3.png
Greyscale
step 203: the intelligent device analyzes the beacon frame, judging whether the identification code obtaining and the identification code of the device match; step 204, if matching, intelligent device, continuing analyzing Beacon frame. The SSID of the wireless routing device obtaining, encrypting mode, wireless routing device password information, accessing wireless network; step 205, if not matched, an intelligent device ignoring the Beacon frame. in step 203, 204 and 205 of the intelligent device in the wireless network receiving the wireless routing device broadcast of the beacon frame, the beacon frame carries the identification code information comprises the smart device, wireless routing device of the SSID and the wireless routing device password Key key for encryption. intelligent device analyzes the beacon frame, judging whether there is identification code of intelligent device itself in the Beacon frame, if not, not processing the beacon frame, if an identification code of the intelligent device, continuously analyzing the Beacon frame, acquiring the wireless routing device SSID, Key key to decrypt the encryption mode and wireless routing device password information. The intelligent device SSID of the wireless routing device obtaining the encryption mode and wireless routing device password information, then directly access the wireless network, before the step 203, further comprising: judging whether intelligent device access to the wireless network; If the access wireless network, ignoring the Beacon frame sent by the wireless routing device; if there is no access to the wireless network, analyzing the Beacon frame of the wireless routing device, last paras, page 6.
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Mooney to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing content of the beacon frame. Based on the content the beacon frame it would be processed and provided to the intended device. In the event the beacon frame is not meant for the intended device(s), it is of no use. The removal of the unneeded beacon frame would free up space, last paras, page 6.
Claim(s) 3, 10, 17, is/are rejected under 35 U.S.C. 103 as being unpatentable over Mooney et al., US 20220247726 A1 in view of ABRAHAM, GAO, KASSLIN and LIU and Barrett et al., US 20220329510 A1.
Referring to claim(s) 3, 10, 17, Mooney, ABRAHAM, GAO, KASSLIN and LIU does not disclose, which Barrett discloses determining a beacon frame type based at least in part on the information associated with the beacon frame, wherein the key is selected based at least in part on the beacon frame type, para 58, 61, 71. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Mooney to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing type of the beacon frame. Based on the type of the beacon frame it would be processed and provided to the intended device, para 58, 61, 71.
Claim(s) 4, 11, 18, is/are rejected under 35 U.S.C. 103 as being unpatentable over Mooney et al., US 20220247726 A1 in view of ABRAHAM, GAO, KASSLIN and LIU and Bernsen et al., 20150271667.
Referring to claim(s) 4, 11, 18, Mooney and ABRAHAM, GAO, KASSLIN and LIU does not disclose, which Bernsen discloses identifying the second communication device based at least in part on information associated with the beacon frame, wherein the key is selected based at least in part on an identity of the second communication device, para 197, 205, 196. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Mooney to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing information of the beacon frame. Based on the identity information carried by the beacon frame it would be processed and provided to the intended device, para 197, 205, 196.
Claim(s) 5, 12, 19, is/are rejected under 35 U.S.C. 103 as being unpatentable over Mooney et al., US 20220247726 A1 in view of ABRAHAM, GAO, KASSLIN and LIU, Liu et al., 20140105097 and SEOK et al., 20160337783.
Referring to claim(s) 5, 12, 19, Mooney, ABRAHAM, GAO, KASSLIN and LIU does not disclose, which Liu discloses determining a size of the encrypted beacon frame field based at least in part on information associated with the beacon frame, para 34. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Mooney to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing size information of the beacon frame. Based on the size information carried by the beacon frame it would be processed and provided to the intended device for further processing, para 34. Mooney, ABRAHAM and Liu do not disclose, which Seok discloses determining a size of the MAC header based at least on information associated with the beacon frame, wherein the encrypted beacon frame field is decrypted based at least in part on the size of the encrypted beacon frame field and a size of the MAC header, para 169, 254-259. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Mooney to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing MAC header information with encryption of the beacon frame. ). MAC header would enable the data fields added at the beginning of a network packet in order to turn it into a frame to be transmitted across a network for a remote device. The encryption/decryption would enable securing the beacon information during the transmission of the information across network, para 169, 254-259.
Claim(s) 6, 13, 20, is/are rejected under 35 U.S.C. 103 as being unpatentable over Mooney et al., US 20220247726 A1 in view of ABRAHAM, GAO, KASSLIN and LIU, and Kil et al., 7801095.
Referring to claim(s) 6, 13, 20, Mooney and ABRAHAM, GAO, KASSLIN and LIU does not disclose, which Kil discloses generating an acknowledgement of receipt of the beacon frame based at least in part on information associated with the beacon frame; and transmitting the acknowledgment to the second communication device, claim 3. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Mooney to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing acknowledgement regarding information of the beacon frame. Based on the receiving of the information carried by the beacon frame it would be processed. The acknowledgement regarding information of the beacon frame would be provided to the sender device to enable further processing, claim 3.
Claim(s) 7, is/are rejected under 35 U.S.C. 103 as being unpatentable over Mooney et al., US 20220247726 A1 in view of ABRAHAM, GAO, KASSLIN and LIU, and AGARDH et al., 20200169977.
Referring to claim(s) 7, Mooney and ABRAHAM, GAO, KASSLIN and LIU does not disclose, which AGARDH discloses wherein the obfuscated TSF is obfuscated based on an offset associated with the TSF, para 69. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Mooney to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing modified timing synchronization field (TSF). In IEEE 802.11 wireless networks, the Timing Synchronization Function (TSF) is a 64-bit microsecond counter and the modified TSF would enable synchronizing the timers of all stations within the same Basic Service Set (BSS), para 69.
Claim(s) 7, is/are rejected under 35 U.S.C. 103 as being unpatentable over Mooney et al., US 20220247726 A1 in view of ABRAHAM, GAO, KASSLIN and LIU, and AKKARAKARAN et al., 20210105579.
Referring to claim(s) 7, Mooney and ABRAHAM, GAO, KASSLIN and LIU does not disclose, which AKKARAKARAN discloses wherein the obfuscated TSF is obfuscated based on an offset associated with the TSF, para 125, claim 4. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Mooney to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing modified timing synchronization field (TSF). In IEEE 802.11 wireless networks, the Timing Synchronization Function (TSF) is a 64-bit microsecond counter and would the modified TSP would enable synchronizing the timers of all stations within the same Basic Service Set (BSS), para 125, claim 4.
Response to Arguments
Applicant’s remarks/arguments dated 2/26/26 with respect to amended claim(s) dated 1-13, 15-21 have been considered. It is noted that the Applicant has amended the claims in response to the prior office action. Accordingly, the above rejections in this office action (over prior rejections) are applied in order to address the claim amendments, and also the arguments that are made in view of the amended claims.
The remarks for the claims rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, are noted. Accordingly, the rejections are updated.
Amended claim 1 contains following:
PNG
media_image1.png
456
758
media_image1.png
Greyscale
The specification does not implement, “selecting a key for de-obfuscating the obfuscated TSF of the MAC header based at least in part on information associated with the beacon frame, wherein the key for de- obfuscating the obfuscated TSF of the MAC header is changed periodically; de-obfuscating the obfuscated TSF of the MAC header based at least in part on the selected key to determine the TSF value”. As claimed, the key is already selected by the selecting step (for de-obfuscating the obfuscated TSF of the MAC header based at least in part on information associated with the beacon frame). Hence, after the key is selected, the key is changed periodically, the key is no longer based on information associated with the beacon frame. The third step “de-obfuscating …” relies upon “selected key”, however, the key is already changed periodically, after the selection of the key, which is no longer based on information associated with the beacon frame after the periodic change.
The first step contains receiving of a MAC header. Hence, the MAC header is already available and not changed. Hence, the TSF / TSF value of the MAC header also does not change. The specification does not implement periodically changing when the TSF / TSF value of the MAC header also does not change.
The specification does implement “beyond”/ “at least” TSP value and an offset, (for example IP address, etc. as the “at least” means everything else) included in “at least in part on a TSP value and an offset”. The specification does not limit what all is included in “at least in part on a TSP value and an offset”.
The specification does implement “beyond” information, (for example IP address, etc. as the “at least” means everything else) included in “at least in part on information”. The specification also does not limit what all is included in “obfuscated TSP based at least in part on information”.
The specification does implement “beyond” selected key, (for example IP address, etc. as the “at least” means everything else) included in “at least in part on the selected key”. The specification also does not limit what all is included in “obfuscated TSP based at least in part on the selected key”.
Similarly, the specification also does not limit what all is included in “at least in part on a TSP value”.
Removal of “at least” is suggested.
Mooney discloses by a first communication device: receiving, from a second communication device, a beacon frame comprising ( a beacon packet that includes obfuscation parameter(s) 195, and send the synchronization packet to network device, para 19)
obtaining the obfuscation parameter from the controller and based on the obfuscation parameter, de-obfuscating the one or more of the obfuscated personally identifiable information of the first network device or the obfuscated personally identifiable information of the second network device, wherein generating the report includes generating a report that includes one or more of the personally identifiable information of the first network device or the personally identifiable information of the second network device, para 90
an encrypted beacon frame field
[0075] Communications in a network environment can be referred to herein as ‘messages’, ‘messaging’, ‘signaling’, ‘data’, ‘content’, ‘objects’, ‘requests’, ‘queries’, ‘responses’, ‘replies’, etc. which may be inclusive of packets. As referred to herein and in the claims, the term ‘packet’ may be used in a generic sense to include packets, frames, segments, datagrams, and/or any other generic units that may be used to transmit communications in a network environment. Generally, a packet is a formatted unit of data that can contain control or routing information (e.g., source and destination address, source and destination port, etc.) and data, which is also sometimes referred to as a ‘payload’, ‘data payload’, and variations thereof In some embodiments, control or routing information, management information, or the like can be included in packet fields, such as within header(s) and/or trailer(s) of packets. Internet Protocol (IP) addresses discussed herein and in the claims can include any IP version 4 (IPv4) and/or IP version 6 (IPv6) addresses.
selecting a key for de-obfuscating the obfuscated field based at least in part on information associated with the beacon frame, de-obfuscating the obfuscated field based at least in part on the key, and decrypting the encrypted beacon frame field of the beacon frame based at least in part on the field.
[0017] Master controller 140 may be configured to store obfuscation parameter(s) 195 (e.g., salt, network address transformation range, etc.). Obfuscation parameter(s) 195 may include customer-specific credential(s). For example, if a given customer is associated with enterprise network 110, obfuscation parameter(s) 195 may apply to all network devices in enterprise network 110 (e.g., network devices 160(1)-160(4)). The customer may have authority over generation of obfuscation parameter(s) 195, and obfuscation parameter(s) 195 may be exchanged within enterprise network 110 in a covert/hidden/encrypted manner.
[0018] Obfuscation parameter(s) 195 may include any suitable secure hashing mechanism used for encrypted hashing of PII 175(1)-175(4). In one specific example, obfuscation parameter(s) 195 may include a salt that causes multiple network devices to generate the same text output given the same text input for each of the network devices. Obfuscation parameter(s) 195 may further include a network address transformation range (e.g., an IP address transformation range). The network address transformation range may prompt network device 160(1) to anonymize any IP addresses that might be present on network device 160(1), including but not necessarily limited to the IP address used by master controller 140 to communicate with network device 160(1).
Mooney does not specifically mention about, which ABRAHAM discloses, the TSF value and timing synchronization field (TSF) that is based on a TSF value and an offset, determine the TSF value (indicating the timing synchronization function and the global time from the second access point indicating the offset field, indicating the second access point receives the message by the wireless station function of timing synchronization field; indicating by the second access point for determining reliability of the anchor point equipment indicated by the global time of last known GPS time of field, field indicating that the anchor point device and indicates that the anchor point device media access control (MAC) address field, claim 11
According to the first method, each AP in its beacon comprises an information element, the information element comprises an indication about the global time of the timing synchronization function (TSF) offset field, and a field indicative of the actual TSF value. the operation frame 302 may include AP (e.g., AP104a) from the second access point (AP) (e.g., AP104b) receiving a global time indication message. In some implementations, the global time indication may include a TSF offset on a global time. For example, AP104a can be configured to determine or calculate the global time based on the TSF value and TSF offset with the global time. In this way, since the TSF offset associated with the global time, so TSF offset can comprise a global time indication, second para, page 7
the operation frame 304, AP104a can be received from the global time indicated by the second AP (e.g., AP104b) is compared with its own global time value stored. if the global time from the second AP (e.g., AP104b) indicating a later than AP104a storage time of global time value, the method can move to the operation frame 306, 3rd para, page 7
T offset = global time and APTSF (which may be based on the MAC address of the AP) are needed (and final) static shift. can then TSF value is updated, second para, page 8
In operation, STA106a can receive beacons from AP104b, offset of the TSF of the beacon comprises: the AP of the AP with the global time, anchor metric (i.e., anchor weight) recently used with the AP updates its global time associated with the anchor point, the MAC address of the anchor point, and a last known global time received from the anchor. recording the TSF and filled in the value field 506 STA106a can receive the beacon. In addition, the STA can be the information element is sent including the TSF counter. additionally, the information allows the recipient to AP (i.e., AP104a) from STA106a and AP104b receiving the beacon and STA106a transmit any delay between IE500 to AP104a. STA106a can additionally use the received TSF with the global time of the AP of the AP offset and filled in the value field 508. Similarly, STA106a can use the TSF value received by the AP and filled in the value field 510. STA106a can use the anchor metrics with the transmitting AP last anchor point for updating the global time associated with the received global time and MACID, and respectively comparing the values filled in fields 512, 514 and 516. STA106a may then transmit IE500 to AP104a, and AP104a can use the above information to synchronize the global time, last para, page 10).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Mooney to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing the message and timing synchronization field (TSF). The message would enable the data fields added at the beginning of a network packet in order to turn it into a frame to be transmitted across a network for a remote device. In IEEE 802.11 wireless networks, the Timing Synchronization Function (TSF) is a 64-bit microsecond counter and would enable synchronizing the timers of all stations within the same Basic Service Set (BSS).
Mooney and ABRAHAM do not specifically mention about, MAC header, which KASSLIN discloses, (MAC entity of a wireless device transmits a beacon, the beacon’s MAC -header may contain device’s current TSF value, para 103).
One of ordinary skilled in the art would readily know what MAC header is and what it is used for.
In networking, the MAC header (or MAC header field) is the first part of a data link layer frame that contains control information about the frame itself. It is part of the MAC (Media Access Control) sublayer and is used to manage how frames are transmitted and received over a shared medium.
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Mooney to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing the MAC header. The MAC header would enable carry a value of a parameter that would be received and used for further processing and perform an action.
Mooney, KASSLIN and ABRAHAM do not specifically mention about, Changed periodically, which LIU discloses, last para, page 6. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date of the claimed invention to modify the invention disclosed by Mooney to implement these limitations and also one of ordinary skill in the art would have been motivated to do so because it could provide utilizing periodically updating the key. This would improve the privacy of the privacy data associated with the key, first para, page 7).
For claim 21, the offset is cited in claim 1. LIU also disclose, which LIU discloses wherein the key that changes periodically is configured to protect the privacy of the information, last para, page 6.
Conclusion
Pertinent references, regarding claims 1, 8, 15:
OBFUSCATION IN PRIVACY BEACON, Lu et al., 20080219452 para 22, 20110178862,
Daigle, para 34, HAWKES et al., 20230098093, para 227;
Lou et al., 20170164387, para 105,
Reial et al., 20170142604, para 47,
MASUDA et al., 20160029377, para 123,
Segev et al., 20130294232, para 30.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HARESH PATEL whose telephone number is (571)272-3973. The examiner can normally be reached on M-F 9-5:30.
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, Jorge L. Ortiz-Criado, can be reached at (571) 272-7624. The fax phone number for the organization where this application or proceeding is assigned is (571) 273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/HARESH N PATEL/Primary Examiner, Art Unit 2496
Prosecution Insights