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 .
Information Disclosure Statement
The information disclosure statement submitted on 09/05/2024 has been considered by the Examiner and made of record in the application file.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-5, 8-11, 13-17, and 20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Elliot et al. (US 2021/0345112 A1 herein Elliot).
Regarding claim 1, Elliot teaches an access point (AP) (read as AP 104/trusted AP 1600) (Elliot – Figure 1, Figure 16, [0076], [0153]) comprising:
at least one processor (read as processor 1602) (Elliot – Figure 16, and [0153]); and
a memory coupled to the at least one processor (read as memory 1624) (Elliot – Figure 16, and [0153]), the memory storing instructions to cause the at least one processor to:
receive a mapping of a wireless device and a further AP (read as database 158 in which various security information is stored such as protected client list, a list of AP connected to the network (e.g., rough APs), whitelisted Aps, a group secret, a list or protected SSIDs and AP RSA key pair; automatic cloud mapping 1306, devices that are configured to implement the security measures herein may automatically obtain network cloud mapping information to enable the devices to communicate with cloud 1302, as collectively illustrated by communications 1308; the devices include trusted AP 902, protected clients 910 and snifer AP 914) (Elliot – Figure 1a, [0086], [0143]) from a server (read as servers) (Elliot – [0064] and [0083]),
the mapping indicating that the further AP is a provision AP for the wireless device (read as under cloud provisioning 1310, the cloud-hosted service provisions security data comprising appropriate sets of data to trusted AP 902, protected clients 910 and snifer 914 by respective messages 1312, 1314, 1316, and 1318) (Elliot – [0144]);
receive presence announcement information from the wireless device (read as wireless AP broadcasts a service set identifier SSID identifying the presence of a wireless network) (Elliot – [0004]);
transmit, based on the received mapping, the received presence announcement information to the further AP (read as IEEE 802.11 Aps periodically transmit a management frame called a beacon frame; beacons contain information about the network including capabilities and configuration information, serve to announce the presence of a wireless LAN and are used to synchronize the members of a service set) (Elliot – [0090]);
receive response information for the wireless device from the further AP, the response information including an authentication request for the wireless device (read as use of secure tokens implemented in trusted beacons 300a, 300b, and 300c can be applied to other types of management frames, including probe request, probe responses, authentication frames, and associated requests and responses) (Elliot – [0098] and [0126]); and
transmit the response information to the wireless device (read as secure tokens may be included in other management frames to validate/authenticate a communicating endpoint such as an authorized AP or trusted client these include probe request and trusted probe responses; trusted probe responses 800a, 800b, and 800c) (Elliot – Figures 8a, 8b, and 8c, and [0126]-[0127]).
Regarding claim 2 as applied to claim 1, Elliot further teaches wherein the memory further stores instructions to cause the at least one processor to: after receiving the presence announcement information from the wireless device, determine that a mapping of the wireless device and the further AP does not exist; and transmit, to the server, a request to be a provision AP for the wireless device (read as trusted probe responses without TEPA correspond to a probe request/response sequence where the probe request is sent to a client device without a TEPA (trusted endpoint agent)) (Elliot – [0133]).
Regarding claim 3 as applied to claim 2, Elliot further teaches wherein the memory further stores instructions to cause the at least one processor to: receive the mapping of the wireless device and the further AP from the server without being selected as a provision AP for the wireless device (read as automatic cloud mapping 1306, devices that are configured to implement the security measures herein may automatically obtain network cloud mapping information to enable the devices to communicate with cloud 1302, as collectively illustrated by communications 1308; the devices include trusted AP 902, protected clients 910 and snifer AP 914) (Elliot – [0143]); and transmit, based on the received mapping, the received presence announcement information to a switch connected to the further AP (read as switch 148) (Elliot – [0079]).
Regarding claim 4 as applied to claim 1, Elliot further teaches wherein the wireless device is a first wireless device, the presence announcement information is first presence announcement information, and the memory further stores instructions to cause the at least one processor to: receive second presence announcement information from a second wireless device (read as wireless AP broadcasts a service set identifier SSID identifying the presence of a wireless network) (Elliot – [0004]); determine that a mapping of the second wireless device and a provision AP for the second wireless device does not exist (read as under cloud provisioning 1310, the cloud-hosted service provisions security data comprising appropriate sets of data to trusted AP 902, protected clients 910 and snifer 914 by respective messages 1312, 1314, 1316, and 1318) (Elliot – [0144]); and transmit, to the server, a request to be the provision AP for the second wireless device (read as trusted probe responses without TEPA correspond to a probe request/response sequence where the probe request is sent to a client device without a TEPA (trusted endpoint agent)) (Elliot – [0133]).
Regarding claim 5 as applied to claim 4, Elliot further teaches wherein the memory further stores instructions to cause the at least one processor to: receive, from the server, provision data for provisioning the second wireless device; and cache the received provision data (read as provisioning of security-related data; UMT cloud controller maintains a database 158 in which various security information is stored by a protected client list, a list of Aps connected to the network, whitelisted APs, a group secret, a list or protected SSIDs and AP RSA key pair) (Elliot – [0086]).
Regarding claim 8 as applied to claim 1, Elliot further teaches wherein the wireless device accesses a network via a Device Provisioning Protocol, and the presence announcement information is DPP presence announcement information (read as wireless AP broadcasts a service set identifier (SSID) identifying the presence of a wireless network; beacons contain information about the network including capabilities and configuration information, serve to announce the presence of a wireless LAN and are used to synchronize the members of a service set) (Elliot – [0004] and [0090]).
Regarding claim 9, Elliot teaches a server (read as servers) (Elliot – [0064] and [0083]) comprising:
at least one processor (read as processor 1602) (Elliot – Figure 16, and [0153]); and
a memory coupled to the at least one processor (read as memory 1624) (Elliot – Figure 16, and [0153]), the memory storing instructions to cause the at least one processor to:
receive, from a first access point (AP) (read as AP 104/trusted AP 1600) (Elliot – Figure 1, Figure 16, [0076], [0153]), a request to be a provision AP for a wireless device (read as trusted probe request adds security information) (Elliott – [0049]-[0055], [0098], [0133]-[0134]);
determine that the wireless device does not have a provision AP (read as an AP that shares at least some RF space with a protected network, yet the neighbor is not part of the protected network and does not share the same SSID as the protected network) (Elliott – [0054]);
select the first AP as the provision AP for the wireless device (read as under cloud provisioning 1310, the cloud-hosted service provisions security data comprising appropriate sets of data to trusted AP 902, protected clients 910 and snifer 914 by respective messages 1312, 1314, 1316, and 1318) (Elliot – [0144]);
generate a mapping of the wireless device and the first AP (read as database 158 in which various security information is stored such as protected client list, a list of AP connected to the network (e.g., rough APs), whitelisted Aps, a group secret, a list or protected SSIDs and AP RSA key pair; automatic cloud mapping 1306, devices that are configured to implement the security measures herein may automatically obtain network cloud mapping information to enable the devices to communicate with cloud 1302, as collectively illustrated by communications 1308; the devices include trusted AP 902, protected clients 910 and snifer AP 914) (Elliot – Figure 1a, [0086], [0143]); and
transmit the mapping of the wireless device and the first AP to a second AP, the mapping being used by the second AP for authenticating the wireless device through the first AP (read as under cloud provisioning 1310, the cloud-hosted service provisions security data comprising appropriate sets of data, keys, lists, certs, etc. to trusted AP 902, protected clients 910 and snifer AP 914 as depicted by respective messages 1312, 1314, 1316, and 1318) (Elliot – [0144]).
Regarding claim 10 as applied to claim 9, Elliot further teaches wherein the memory further stores instructions to cause the at least one processor to: transmit provision data for provisioning the wireless device to the first AP (read as under cloud provisioning 1310, the cloud-hosted service provisions security data comprising appropriate sets of data, keys, lists, certs, etc. to trusted AP 902, protected clients 910 and snifer AP 914 by respective messages 1312, 1314, 1316, and 1318) (Elliot – [0144]).
Regarding claim 11 as applied to claim 10, Elliot further teaches wherein the instructions to transmit the mapping of the wireless device and the first AP to the second AP comprise instructions to cause the at least one processor to: obtain a neighbor AP list for the first AP; and transmit the mapping of the wireless device and the first AP based on the neighbor AP list (read as trusted wireless environment TWE 100 includes a neighbor AP 108; if a neighbor AP is present, the neighbor AP will also periodically broadcast beacons) (Elliot – [0076], [0082], and [0113]).
Regarding claim 13, Elliot teaches a method comprising:
receiving, by an access point (AP) (read as AP 104/trusted AP 1600) (Elliot – Figure 1, Figure 16, [0076], [0153]), a mapping of a wireless device and a further AP from a server, the mapping indicating that the further AP is a provision AP for the wireless device (read as database 158 in which various security information is stored such as protected client list, a list of AP connected to the network (e.g., rough APs), whitelisted Aps, a group secret, a list or protected SSIDs and AP RSA key pair; automatic cloud mapping 1306, devices that are configured to implement the security measures herein may automatically obtain network cloud mapping information to enable the devices to communicate with cloud 1302, as collectively illustrated by communications 1308; the devices include trusted AP 902, protected clients 910 and snifer AP 914) (Elliot – Figure 1a, [0086], [0143]);
receiving, by the AP, presence announcement information from the wireless device (read as wireless AP broadcasts a service set identifier SSID identifying the presence of a wireless network) (Elliot – [0004]);
transmitting, by the AP and based on the received mapping, the received presence announcement information to the further AP (read as IEEE 802.11 Aps periodically transmit a management frame called a beacon frame; beacons contain information about the network including capabilities and configuration information, serve to announce the presence of a wireless LAN and are used to synchronize the members of a service set) (Elliot – [0090]);
receiving, by the AP, response information for the wireless device from the further AP, the response information including an authentication request for the wireless device (read as use of secure tokens implemented in trusted beacons 300a, 300b, and 300c can be applied to other types of management frames, including probe request, probe responses, authentication frames, and associated requests and responses) (Elliot – [0098] and [0126]); and
transmitting, by the AP, the response information to the wireless device (read as secure tokens may be included in other management frames to validate/authenticate a communicating endpoint such as an authorized AP or trusted client these include probe request and trusted probe responses; trusted probe responses 800a, 800b, and 800c) (Elliot – Figures 8a, 8b, and 8c, and [0126]-[0127]).
Regarding claim 14 as applied to claim 13, Elliot further teaches wherein the method further comprises: determining, by the AP, that a mapping of the wireless device and the further AP does not exist; and transmitting, by the AP and to the server, a request to be a provision AP for the wireless device (read as trusted probe responses without TEPA correspond to a probe request/response sequence where the probe request is sent to a client device without a TEPA (trusted endpoint agent)) (Elliot – [0133]).
Regarding claim 15 as applied to claim 14, Elliot further teaches wherein the method further comprises: receiving, by the AP, the mapping of the wireless device and the further AP from the server without being selected as a provision AP for the wireless device (read as automatic cloud mapping 1306, devices that are configured to implement the security measures herein may automatically obtain network cloud mapping information to enable the devices to communicate with cloud 1302, as collectively illustrated by communications 1308; the devices include trusted AP 902, protected clients 910 and snifer AP 914) (Elliot – [0143]); and transmitting, by the AP, based on the received mapping, the received presence announcement information to a switch connected to the further AP (read as switch 148) (Elliot – [0079]).
Regarding claim 16 as applied to claim 13, Elliot further teaches wherein the wireless device is a first wireless device, the presence announcement information is first presence announcement information, and the method further comprises: receiving, by the AP, second presence announcement information from a second wireless device (read as wireless AP broadcasts a service set identifier SSID identifying the presence of a wireless network) (Elliot – [0004]); determining, by the AP, that a mapping of the second wireless device and a provision AP for the second wireless device does not exist (read as under cloud provisioning 1310, the cloud-hosted service provisions security data comprising appropriate sets of data to trusted AP 902, protected clients 910 and snifer 914 by respective messages 1312, 1314, 1316, and 1318) (Elliot – [0144]); and transmitting, by the AP and to the server, a request to be the provision AP for the second wireless device (read as trusted probe responses without TEPA correspond to a probe request/response sequence where the probe request is sent to a client device without a TEPA (trusted endpoint agent)) (Elliot – [0133]).
Regarding claim 17 as applied to claim 16, Elliot further teaches wherein the method further comprises: receiving, by the AP and from the server, provision data for provisioning the second wireless device; and caching, by the AP, the received provision data (read as provisioning of security-related data; UMT cloud controller maintains a database 158 in which various security information is stored by a protected client list, a list of Aps connected to the network, whitelisted APs, a group secret, a list or protected SSIDs and AP RSA key pair) (Elliot – [0086]).
Regarding claim 20 as applied to claim 13, Elliot further teaches wherein the wireless device accesses a network via a Device Provisioning Protocol, and the presence announcement information is DPP presence announcement information (read as wireless AP broadcasts a service set identifier (SSID) identifying the presence of a wireless network; beacons contain information about the network including capabilities and configuration information, serve to announce the presence of a wireless LAN and are used to synchronize the members of a service set) (Elliot – [0004] and [0090]).
Allowable Subject Matter
Claims 6-7, 12, and 18-19 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to APRIL GUZMAN GONZALES whose telephone number is (571)270-1101. The examiner can normally be reached Monday - Friday 8:00 am to 4:00 pm EST. The examiner’s email address is April.guzman@uspto.gov.
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, Wesley L. Kim can be reached at (571) 272-7867. 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.
/APRIL G GONZALES/Primary Examiner, Art Unit 2648