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 .
2. EXAMINER’S NOTE: The claims have been reviewed and considered under the new guidance pursuant to the 2019 Revised Patent Subject Matter Eligibility Guidance (PEG 2019) issued January 7, 2019.
3. This communication is in response to Applicant’s claims filed on 26 June 2024. Claims 1-20 remain pending.
Information Disclosure Statement
4. The Information Disclosure Statements respectfully submitted on 26 June 2024 and 22 May 2025 have been considered by the Examiner.
Continued Prosecution Application
5. This application is a continuation-in-part of Serial No. 17/474,033 filed on 13 September 2021, which is now, US Patent No. 12,052,562, issued on 30 July 2024.
Double Patenting
6. The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Instant Application 18/755,137
Issued Application 12,052,652
1. A method, comprising: receiving a beacon from a network device, the beacon comprising a trust level of the network device, wherein the trust level of the network device indicates whether the network device is physically located in a space to which access is restricted; determining that the trust level of the network device satisfies a predetermined trust criterion; based on determining that the trust level of the network device satisfies the predetermined trust criterion, transmitting a connection request to the network device; and based on transmitting the connection request, receiving user data from the network device.
2. The method of claim 1, wherein the beacon comprises a service set identifier (SSID) of a network segment comprising the network device, the network segment comprising the network device and one or more additional network devices.
3. The method of claim 2, wherein the network segment is a first network segment, and wherein the beacon comprises a second trust level of a second network segment of a network, the network comprising the first network segment and the second network segment.
4. The method of claim 1, further comprising: determining the predetermined trust criterion based on an application operating on a user device, wherein the method is performed by the user device.
5. The method of claim 4, the predetermined trust criterion being a first predetermined trust criterion, the application being a first application, the method further comprising: determining a second predetermined trust criterion based on a second application operating on the user device; determining that the trust level of the network device does not satisfy the second predetermined trust criterion; and based on determining that the trust level of the network device does not satisfy the second predetermined trust criterion, deactivating the second application.
6. The method of claim 1, wherein the beacon is a first beacon, and the trust level of the network device is a first trust level of the network device at a first time, the method further comprising: based on receiving the user data, receiving a second beacon from the network device comprising a second trust level at a second time; determining that the second trust level does not satisfy the predetermined trust criterion; and based on determining that the second trust level does not satisfy the predetermined trust criterion, deactivating an application operating on a user device, and wherein the method is performed by the user device.
7. The method of claim 1, wherein the network device comprises a wireless access point (AP) or a base station, and the beacon is received over a wireless interface, or wherein the network device comprises a network switch, and the beacon is a single-hop message received from the network switch.
8. A system, comprising: at least one processor; and memory storing instructions that, when executed by the system, cause the system to perform operations comprising: generating a beacon comprising a trust level of a network device, the trust level indicating that physical access to the network device is restricted; transmitting the beacon; in response to transmitting the beacon, receiving, from a user device, a connection request; and based on receiving the connection request: transmitting user data to the user device; or receiving user data from the user device.
9. The system of claim 8, wherein the beacon comprises a service set identifier (SSID) of a network segment comprising the network device, the network segment further comprising one or more additional network devices.
10. The system of claim 8, wherein the beacon comprises a timestamp, and wherein the connection request is received within a threshold time of a time indicated by the timestamp.
11. The system of claim 8, wherein generating the beacon comprises: digitally signing the beacon by encrypting the trust level using a private key.
12. The system of claim 8, wherein transmitting the beacon comprises broadcasting the beacon into a coverage area of the network device.
13. The system of claim 8, wherein the network device comprises a wireless access point (AP) or a base station, and wherein the beacon is transmitted over a wireless interface.
14. The system of claim 8, wherein the network device comprises a network switch, and wherein the beacon is a single-hop message in a wired network.
15. The system of claim 8, wherein the operations further comprise: receiving an indication of the trust level from an administrator device.
16. The system of claim 8, wherein the beacon is a first beacon, the trust level is a first trust level of the network device at a first time, wherein the user data is first user data associated with a first application, and wherein the operations further comprise: generating a second beacon comprising a second trust level of the network device at a second time; transmitting the second beacon; in response to transmitting the second beacon, receiving, from the user device, a connection request; and based on receiving the connection request: transmitting second user data to the user device; or receiving second user data to the user device, and wherein the second user data is associated with a second application.
17. A system, comprising: a first network device comprising: at least one first processor; and first memory storing first instructions that, when executed by the first network device, cause the first network device to perform first operations comprising: generating a first beacon comprising a first service set identifier (SSID) and a trust level of the first network device, wherein the first network device is physically located in a space to which access is restricted; periodically transmitting the first beacon; receiving, from a user device, a connection request; and based on receiving the connection request: transmitting first user data to the user device; or receiving second user data from the user device; and a second network device comprising: at least one second processor; and second memory storing second instructions that, when executed by the second network device, cause the second network device to perform second operations comprising: generating a second beacon comprising a second SSID and a trust level of the second network device, wherein the second network device is physically located in a space to which physical access in unrestricted, the trust level of the second network device being lower than the trust level of the first network device; and periodically transmitting the second beacon.
18. The system of claim 17, wherein generating the first beacon comprises: digitally signing the first beacon by encrypting the first SSID and trust level of the first network device using a private key.
19. The system of claim 17, wherein the first SSID and the second SSID comprise a SSID of a network comprising a network segment, the network segment comprising the first network device and the second network device.
20. The system of claim 17, wherein the first beacon is periodically transmitted into a first coverage area, wherein the second beacon is periodically transmitted into a second coverage area, and wherein the first coverage area overlaps the second coverage area.
1. A method, comprising: receiving a beacon from a network device, the beacon comprising a trust level of the network device, wherein the trust level of the network device indicates whether the network device is physically located in a locked space to which access is restricted; determining that the trust level of the network device satisfies a predetermined trust criterion; based on determining that the trust level of the network device satisfies the predetermined trust criterion, transmitting a connection request to the network device; and based on transmitting the connection request, receiving user data from the network device.
2. The method of claim 1, wherein the beacon comprises a service set identifier (SSID) of a network segment comprising the network device, the network segment comprising the network device and one or more additional network devices.
3. The method of claim 1, wherein the beacon comprises a timestamp, and wherein the connection request is transmitted within a threshold time of a time indicated by the timestamp.
4. The method of claim 1, further comprising: determining the predetermined trust criterion based on an application operating on a user device, wherein the method is performed by the user device.
5. The method of claim 4, the predetermined trust criterion being a first predetermined trust criterion, the application being a first application, the method further comprising: determining a second predetermined trust criterion based on a second application operating on the user device; determining that the trust level of the network device does not satisfy the second predetermined trust criterion; and based on determining that the trust level of the network device does not satisfy the second predetermined trust criterion, deactivating the second application.
6. The method of claim 1, wherein the network device comprises a wireless access point (AP) or a base station, and the beacon is received over a wireless interface, or wherein the network device comprises a network switch, and the beacon is a single-hop message received from the network switch.
7. The method of claim 1, wherein access to the locked space is restricted to individuals that present at least one of a physical key, an identification badge, a biometric factor, or a code.
8. A system, comprising: at least one processor; and memory storing instructions that, when executed by the system, cause the system to perform operations comprising: generating a first beacon comprising a first trust level of a network device at a first time, the first trust level indicating that physical access to the network device is unrestricted at the first time; transmitting the first beacon; generating a second beacon comprising a second trust level of a network device at a second time, the second trust level indicating that physical access to the network device is restricted at the second time; transmitting the second beacon; in response to transmitting the second beacon, receiving, from a user device, a connection request from the network device; and based on receiving the connection request, transmitting user data to the user device or receiving user data from the user device.
9. The system of claim 8, wherein the first beacon comprises a service set identifier (SSID) of a network segment comprising the network device, the network segment further comprising one or more additional network devices.
10. The system of claim 8, wherein the first beacon comprises a timestamp, and wherein the connection request is received within a threshold time of a third time indicated by the timestamp.
11. The system of claim 8, wherein generating the first beacon comprises: digitally signing the first beacon by encrypting the first trust level using a private key.
12. The system of claim 8, wherein transmitting the first beacon comprises broadcasting the first beacon into a coverage area of the network device.
13. The system of claim 8, wherein the network device comprises a wireless access point (AP) or a base station, and wherein the first beacon is transmitted over a wireless interface.
14. The system of claim 8, wherein the network device comprises a network switch, and wherein the first beacon is a single-hop message in a wired network.
15. The system of claim 8, wherein the operations further comprise: receiving an indication of the first trust level from an administrator device.
16. The system of claim 8, wherein physical access to the network device at the second time is restricted to individuals that present at least one of a physical key, an identification badge, a biometric factor, or a code.
17. A system, comprising: a first network device comprising: at least one first processor; and first memory storing first instructions that, when executed by the first network device, cause the first network device to perform first operations comprising: generating a first beacon comprising a service set identifier (SSID) and a trust level of the first network device, wherein first network device is physically located in a locked space to which access is restricted to individuals that present at least one of a physical key, an identification badge, a biometric factor, or a code; periodically transmitting the first beacon; receiving, from a user device, a connection request; and based on receiving the connection request: transmitting first user data to the user device; and receiving second user data from the user device; and a second network device comprising: at least one second processor; and second memory storing second instructions that, when executed by the second network device, cause the second network device to perform second operations comprising: generating a second beacon comprising the SSID and a trust level of the second network device, wherein the second network device is located in a geographical region to which physical access in unrestricted, the trust level of the second network device being lower than the trust level of the first network device; and periodically transmitting the second beacon.
18. The system of claim 17, wherein generating the first beacon comprises: digitally signing the first beacon by encrypting the SSID and trust level of the first network device using a private key.
19. The system of claim 17, wherein the first beacon further comprises a timestamp, and wherein the connection request is received within a threshold time period of a time indicated by the timestamp.
20. The system of claim 17, wherein the first beacon is periodically transmitted into a first coverage area, wherein the second beacon is periodically transmitted into a second coverage area, and wherein the first coverage area overlaps the second coverage area.
7. Claims 1-20 is rejected on the ground of non-statutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No. 12,052,652. Although the claims at issue are not identical, they are not patentably distinct from each other because in both instances, the claims are drawn towards selective network access based on trust level. The omission of “wherein first network device is physically located in a locked space to which access is restricted to individuals that present at least one of a physical key, an identification badge, a biometric factor, or a code” does not change the scope of the claims for the instant application and the issued application. Similarly, in both instances, a similarity measure may be attained wherein advertise the trust levels for network devices and selectively connecting to network devices based on trust levels of the network devices is being performed.
Claim Rejections - 35 USC § 103
8. 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.
9. 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.
10. Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Weksler et al. (Pub No. 2018/0160307) in view of Walker (Pub No. 2020/0280541) and in further view of Nenov (Pub No. 2018/0115901).
Referring to the rejection of claim 1, Weksler et al. discloses a method, comprising:
receiving a beacon from a network device, the beacon comprising a trust level of the network device, (See Weksler et al., para. 30,74,and 80 a beacon is received from a requesting network device to establish a connection wherein the beacon comprises a trust level by using a public key to sign the data packet and a private key to verify the signature of the data packet comprising a hardware identifier which enables a beacon to determine whether the packet matches the identifier of the beacon for a secure connection)
However, Weksler et al. fail to explicitly disclose determining that the trust level of the network device satisfies a predetermined trust criterion; based on determining that the trust level of the network device satisfies the predetermined trust criterion, transmitting a connection request to the network device; based on transmitting the connection request, receiving user data from the network device.
Walker discloses a method for establishing a connection between a user device and an access zone.
Walker discloses determining that the trust level of the network device satisfies a predetermined trust criterion; (See Walker, para. 39-41, the VPN server obtains trust data of a user accessing a first network and determines a first trust level that satisfies the predetermined criteria based on the first correspondence comprising trust data and first trust level)
Walker discloses based on determining that the trust level of the network device satisfies the predetermined trust criterion, transmitting a connection request to the network device; (See Walker, para. 42-44, determining that the first access zone corresponds to the first trust level according to a second correspondence, transmit a connection request)
Walker discloses and based on transmitting the connection request, receiving user data from the network device. (See Walker, para. 44-46, transmitting the connection request and receiving user data wherein the user will have remote access after a first VPN connection is established between the user and the first access zone)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to combine Weksler et al.’s method and system for securing wireless mesh network connections modified with Walker’s method for establishing a connection between a user device and an access zone.
Motivation for such an implementation would enable a method for remote access and a server, which provides an adaptive security mechanism for a remote access based on trust levels corresponding to trust data. (See Walker, para. 5-6)
The combination of Weksler et al. and Walker fail to explicitly disclose wherein the trust level of the network device indicates a restrictiveness of physical access to the network device.
Nenov discloses a method and system for a network security and physical security into a single device providing enhanced protection against network threats to physical security systems and physical protection against network threats by anyone with physical access to the network device.
Nenov discloses wherein the trust level of the network device indicates whether the network device is physically located in a space to which access is restricted (See Nenov, para. 13, 17, 32, 43, and 46, a trust level of the network device indicates a restrictiveness of physical access to the network device is disclosed as NFC, radiofrequency (RF) signaling, geolocation, or geofencing, wherein certain applications may be operable on devices located in secure coverage areas and if the network device is not within the proximity of the secure coverage area, the network device may block access to the user and prevent physical attacks between the physical security device and the virtual network device)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to combine Weksler et al.’s method and system for securing wireless mesh network connections and Walker’s method for establishing a connection between a user device and an access zone modified with Nenov’s method and system for a network security and physical security into a single device providing enhanced protection against network threats to physical security systems and physical protection against network threats by anyone with physical access to the network device.
Motivation for such an implementation would enable enhanced protection against network threats to physical security systems, and physical protection against network threats by anyone with physical access to the network device. (See Nenov, para. 3)
Referring to the rejection of claims 2 and 9, (Weksler et al. and Walker modified by Nenov) discloses wherein the beacon comprises a service set identifier (SSID) of a network segment comprising the network device, the network segment comprising the network device and one or more additional network devices. (See Walker, para. 70, The trust data element for determining whether the access network is reliable comprises a WiFi Service Set Identifier (SSID) of a wireless access point in the access network carried in the remote access request)
The rationale for combining Weksler et al. and Walker in further view of Nenov is the same as claim 1.
Referring to the rejection of claim 3, (Weksler et al. and Walker modified by Nenov) discloses wherein the network segment is a first network segment, (See Walker, para. 70) and wherein the beacon comprises a second trust level of a second network segment of a network, the network comprising the first network segment and the second network segment. (See Walker, para. 57-58)
The rationale for combining Weksler et al. and Walker in further view of Nenov is the same as claim 1.
Referring to the rejection of claim 4, (Weksler et al. and Walker modified by Nenov) discloses further comprising: determining the predetermined trust criterion based on an application operating on a user device, wherein the method is performed by the user device. (See Weksler et al., para. 120)
Referring to the rejection of claim 5, (Weksler et al. and Walker modified by Nenov) discloses the predetermined trust criterion being a first predetermined trust criterion, the application being a first application, the method further comprising: (See Walker, para. 40-41)
determining a second predetermined trust criterion based on a second application operating on the user device; (See Walker, para. 42 and 45)
determining that the trust level of the network device does not satisfy the second predetermined trust criterion; (See Walker, para. 57-58)
and based on determining that the trust level of the network device does not satisfy the second predetermined trust criterion, deactivating the second application. (See Walker, para. 58 and 65)
The rationale for combining Weksler et al. and Walker in further view of Nenov is the same as claim 1.
Referring to the rejection of claims 6 and 16, (Weksler et al. and Walker modified by Nenov) discloses wherein the beacon is a first beacon, (See Weksler et al., para. 23) and the trust level of the network device is a first trust level of the network device at a first time, the method further comprising: (See Weksler et al., para. 30, 74, and 80) based on receiving the user data, receiving a second beacon from the network device comprising a second trust level at a second time; (See Weksler, para. 23) determining that the second trust level does not satisfy the predetermined trust criterion; (See Walker et al., para. 57-58) and based on determining that the second trust level does not satisfy the predetermined trust criterion, deactivating an application operating on a user device, and wherein the method is performed by the user device. (See Walker et al., para. 58 and 65)
The rationale for combining Weksler et al. and Walker in further view of Nenov is the same as claim 1.
Referring to the rejection of claims 7 and 14, (Weksler et al. and Walker modified by Nenov) discloses wherein the network device comprises a wireless access point (AP) or a base station, and the beacon is received over a wireless interface, or wherein the network device comprises a network switch, and the beacon is a single-hop message received from the network switch. (See Walker, para. 72, 103, and 133)
The rationale for combining Weksler et al. and Walker in further view of Nenov is the same as claim 1.
Referring to the rejection of claim 8, (Weksler et al. and Walker modified by Nenov) discloses a system, comprising:
at least one processor; (See Weksler et al., Fig. 11, processor, item 2010)
and memory storing instructions that, when executed by the system, cause the system to perform operations comprising: (See Weksler et al., Fig. 11, memory, item 2030 storing instructions and executed by the system)
generating a beacon comprising a trust level of a network device, (See Weksler et al., para. 30,74,and 80 a beacon is received from a requesting network device to establish a connection wherein the beacon comprises a trust level by using a public key to sign the data packet and a private key to verify the signature of the data packet comprising a hardware identifier which enables a beacon to determine whether the packet matches the identifier of the beacon for a secure connection)
transmitting the beacon; (See Weksler et al., para. 56, the hardware identifier enables a beacon device receiving a data packet to identify the transmitting beacon device and insert its hardware identifier into the availability data packet and retransmits the availability data packet)
However, Weksler et al. fail to explicitly disclose in response to transmitting the beacon, receiving, from a user device, a connection request; and based on receiving the connection request: transmitting user data to the user device; or receiving user data from the user device.
Walker discloses a method for establishing a connection between a user device and an access zone.
Walker discloses in response to transmitting the beacon, receiving, from a user device, a connection request; (See Walker, para. 42-44, determining that the first access zone corresponds to the first trust level according to a second correspondence, transmit a connection request)
Walker discloses and based on receiving the connection request: transmitting user data to the user device; (See Walker, para. 44-46, transmitting the connection request and receiving user data wherein the user will have remote access after a first VPN connection is established between the user and the first access zone)
Walker discloses or receiving user data from the user device. (See Walker, para. 53, receiving second user data from the user device)
The combination of Weksler et al. and Walker fail to explicitly disclose the trust level indicating that physical access to the network device is restricted.
Nenov discloses a method and system for a network security and physical security into a single device providing enhanced protection against network threats to physical security systems and physical protection against network threats by anyone with physical access to the network device.
Nenov discloses the trust level indicating that physical access to the network device is restricted (See Nenov, para. 13, 17, 32, 43, and 46, a trust level of the network device indicates a restrictiveness of physical access to the network device is disclosed as NFC, radiofrequency (RF) signaling, geolocation, or geofencing, wherein certain applications may be operable on devices located in secure coverage areas and if the network device is not within the proximity of the secure coverage area, the network device may block access to the user and prevent physical attacks between the physical security device and the virtual network device)
The rationale for combining Weksler et al. and Walker in further view of Nenov is the same as claim 1.
Referring to the rejection of claim 10, (Weksler et al. and Walker modified by Nenov) discloses wherein the beacon comprises a timestamp, and wherein the connection request is received within a threshold time of a time indicated by the timestamp. (See Weksler et al., para. 109-110 and 120)
Referring to the rejection of claim 11, (Weksler et al. and Walker modified by Nenov) discloses wherein generating the beacon comprises: digitally signing the beacon by encrypting the trust level using a private key. (See Weksler et al., para. 42 and 111)
Referring to the rejection of claim 12, (Weksler et al. and Walker modified by Nenov) discloses wherein transmitting the beacon comprises broadcasting the beacon into a coverage area of the network device. (See Walker, para. 88-89)
The rationale for combining Weksler et al. and Walker in further view of Nenov is the same as claim 1.
Referring to the rejection of claim 13, (Weksler et al. and Walker modified by Nenov) discloses wherein the network device comprises a wireless access point (AP) or a base station, and wherein the beacon is transmitted over a wireless interface. (See Walker, para. 70)
The rationale for combining Weksler et al. and Walker in further view of Nenov is the same as claim 1.
Referring to the rejection of claim 15, (Weksler et al. and Walker modified by Nenov) discloses wherein the operations further comprise: receiving an indication of the trust level from an administrator device. (See Walker, para. 107-109, the VPN server is disclosed as an administrator device wherein an indication of trust level can be determined whether certain devices are allowed or disallowed to connect to the enterprise network based upon access points that are more reliable or less reliable)
The rationale for combining Weksler et al. and Walker in further view of Nenov is the same as claim 1.
Referring to the rejection of claim 17, (Weksler et al. and Walker modified by Nenov) discloses a system, comprising:
a first network device comprising: (See Weksler et al., Fig. 1, network, item 120)
at least one first processor; (See Weksler et al., Fig. 11, processor, item 2010)
and first memory storing first instructions that, when executed by the first network device, cause the first network device to perform first operations comprising: (See Weksler et al., Fig. 11, memory, item 2030 storing instructions and executed by the system)
generating a first beacon comprising a first service set identifier (SSID) and a trust level of the first network device, (See Weksler et al., para. 30, 74, and 80 a beacon is received from a requesting network device to establish a connection wherein the beacon comprises a trust level by using a public key to sign the data packet and a private key to verify the signature of the data packet comprising a hardware identifier which enables a beacon to determine whether the packet matches the identifier of the beacon for a secure connection)
discloses periodically transmitting the first beacon; (See Weksler et al., para. 23, the master beacon periodically transmits the first beacon, item 110-a to determine the security for the mesh network)
discloses and periodically transmitting the second beacon. (See Weksler et al., para. 23, the master beacon periodically transmits the second beacon, item 110-b to receive survey data packets within a predetermined time period)
However, Weksler et al. fail to explicitly disclose receiving, from a user device, a connection request.
Walker discloses a method for establishing a connection between a user device and an access zone.
Walker discloses receiving, from a user device, a connection request; (See Walker, para. 42-44, determining that the first access zone corresponds to the first trust level according to a second correspondence, transmit a connection request)
Walker discloses and based on receiving the connection request: transmitting first user data to the user device; (See Walker, para. 44-46, transmitting the connection request and receiving user data wherein the user will have remote access after a first VPN connection is established between the user and the first access zone)
Walker discloses or receiving second user data from the user device; (See Walker, para. 53, receiving second user data from the user device)
Walker discloses and a second network device comprising: at least one second processor; (See Walker, para. 54 and Fig. 7, a second network and a second processor, item 710)
Walker discloses and second memory storing second instructions that, when executed by the second network device, cause the second network device to perform second operations comprising: (See Walker, Fig. 7, a second memory, item 720)
Walker discloses generating a second beacon comprising a second SSID and a trust level of the second network device, the trust level of the second network device being lower than the trust level of the first network device; (See Walker, para. 57-58 and 70, generating a second beacon based on the SSID and the trust level of the second network device being lower than the trust level of the first network device)
The combination of Weksler et al. and Walker fail to explicitly disclose wherein the first network device is physically located in a space to which access is restricted; and wherein the second network device is physically located in a space to which physical access in unrestricted.
Nenov discloses a method and system for a network security and physical security into a single device providing enhanced protection against network threats to physical security systems and physical protection against network threats by anyone with physical access to the network device.
Nenov discloses wherein the first network device is physically located in a space to which access is restricted (See Nenov, para. 13, 17, 32, 43, and 46, a trust level of the network device indicates a restrictiveness of physical access to the network device is disclosed as NFC, radiofrequency (RF) signaling, geolocation, or geofencing, wherein certain applications may be operable on devices located in secure coverage areas and if the network device is not within the proximity of the secure coverage area, the network device may block access to the user and prevent physical attacks between the physical security device and the virtual network device)
Nenov discloses the second network device is physically located in a space to which physical access in unrestricted. (See Nenov, para. 62, i.e., the second network device is disclosed as the network security devices is physically unrestricted wherein shared access is provided via the hypervisor which allows access to first and second user interfaces)
The rationale for combining Weksler et al. and Walker in further view of Nenov is the same as claim 1.
Referring to the rejection of claim 18, (Weksler et al. and Walker modified by Nenov) discloses wherein generating the first beacon comprises: digitally signing the first beacon by encrypting the first SSID and trust level of the first network device using a private key. (See Weksler et al., para. 42, 74, and 111)
Referring to the rejection of claim 19, (Weksler et al. and Walker modified by Nenov) discloses wherein the first SSID and the second SSID comprise a SSID of a network comprising a network segment, the network segment comprising the first network device and the second network device. (See Walker, para. 70)
The rationale for combining Weksler et al. and Walker in further view of Nenov is the same as claim 1.
Referring to the rejection of claim 20, (Weksler et al. and Walker modified by Nenov) discloses wherein the first beacon is periodically transmitted into a first coverage area, wherein the second beacon is periodically transmitted into a second coverage area, and wherein the first coverage area overlaps the second coverage area. (See Walker, para. 88-89 and 108-110)
The rationale for combining Weksler et al. and Walker in further view of Nenov is the same as claim 1.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to COURTNEY D FIELDS whose telephone number is (571)272-3871. The examiner can normally be reached IFP M-F 8am-4:30pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, SHEWAYE GELAGAY can be reached at (571)272-4219. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/COURTNEY D FIELDS/Examiner, Art Unit 2436 January 1, 2026
/SHEWAYE GELAGAY/Supervisory Patent Examiner, Art Unit 2436