Notice of Pre-AIA or AIA Status
1. 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 amendment filed on 07 April 2026. Claims 4 and 18 have been canceled. Claims 21-22 have been added. Claims 1 and 8 have been amended. Claims 1-3, 5-17, and 19-22 remain pending.
Response to Arguments
4. Applicant’s arguments, see pages 9-13, filed on 07 April 2026, with respect to the 103 rejection in view of Weksler et al., Walker, and Nenov has been fully considered, but are moot in view of the new grounds of rejection. In light of the newly added claim limitations, a new ground of rejection is hereby presented in view of Robison et al. (Pub No. 2019/0116173).
5. In light of the previous double patenting rejection, the Applicant has filed an eTD to overcome the rejection, therefore, the rejection has been withdrawn.
6. In light of the Applicant’s arguments for claims 1, 8, and 17, the Applicant traverses that the prior art, Weskler et al., Walker, and Nenov fails to disclose, suggest, or teach the claimed limitations “based on determining that the trust level of the network device satisfies the predetermined trust criterion, transmitting a connection request to the network device” because none of the references disclose trust levels of a network device.
The Examiner respectfully disagrees and asserts that Walker discloses a method and system for establishing a connection between a user device and an access zone via a VPN server. A first trust level corresponding to the trust data according to the first correspondence, wherein the first correspondence comprises the trust data and the first trust level as shown in the Abstract of the Walker reference.
Walker discloses in paragraphs 39-46, a method performed by a remote access server for example, a VPN server obtains the trust data of a user accessing a first network. The first network may be an enterprise network or the other network to which the user wants to have remote access. The trust data may include a trust element for determining whether the user is reliable. In addition, the trust data may further include a trust element for determining whether a device used by the user is reliable and/or a trust data element for determining whether a second network which connects the device to the first network is reliable. The VPN server determines a first trust level corresponding to the trust data according to a first correspondence, wherein the first correspondence comprises the trust data and the first trust level. The VPN server determines a first access zone of the first network corresponding to the first trust level according to a second correspondence, wherein the second correspondence comprises the first trust level and the first access zone. The first trust level is one of a plurality of trust levels, the first access zone is one of a plurality of access zones, and the plurality of trust levels and the plurality of access zones have a one-to-to correspondence. The VPN server establishes a first VPN connection between a device used by the user and the first access zone. the first network which provides the protected applications, services and/or data in the first network may be divided into a plurality of access zones for each user according to a trust policy. The trust policy is used for indicating the first corresponding correspondence and the second correspondence, i.e., what trust level shall be assigned to the remote access of the user according to the trust data related to the remote access of the user, or, how the trust data related to the remote access of the user affects a trust level (also called trust degree) of the remote access of the user. Each access zone may correspond to a certain level of trust in the remote access of the user and each trust level indicates one access privilege of the user. The VPN server may provide a plurality of layers (or depths) of access to the plurality of zones adaptively according to the trust data related to the remote access of the user, which are currently collected from for example the user and the device or a network on the VPN connection to be established between the user and the first network, or other data resources. When a user wants to have remote access to the first network from the outside, the user may run a VPN client in an end device, and the end device sends a remote access request to the VPN server for remote access to the first network after the VPN client is run. The VPN server collects trust data related to the remote access, and determines a trust level of the remote access according the currently collected trust data and a preset trust policy or rule. Finally, the VPN server establishes a VPN connection between the user's device and an access zone which corresponds to the determined trust level.
Walker further discloses in paragraphs 52-60, the user may be an employee or role in the enterprise. For example, an accountant or a network administrator is a role in the enterprise, includes monitoring, by the VPN server, a change of the trust data; determining, by the VPN server, a second trust level corresponding to changed trust data according to a third correspondence if the VPN server obtains the changed trust data, wherein the third correspondence comprises the changed trust data and the second trust level; determining, by the VPN server, a second access zone of the first network corresponding to the second trust level according to a fourth correspondence, wherein the fourth correspondence comprises the second trust level and the second access zone; and establishing, by the VPN server, a second VPN connection between the device and the second access zone. The VPN server may dynamically monitor the VPN connection between the user's device and the first network for changes in trust data. The VPN server may change the depth (height) of remote access of the user according to the change in the trust data. In other words, a dynamic connection is established from the user's device or network attach point to a multi-layered set of networks, depending on role, user, and trust in the device used by the user, in a second network which connects the device to the first network, and in the identity of the user. Each user or set of users or roles can have a different and dynamic level of remote access, with the depth of remote access to enterprise applications, data, and services dependent on the currently determined trust level. The depth of the remote access is determined by the VPN server as a computed trust level based on a variety of configurable and extensible data elements using an established set of scoring policies. Changes in the contributors of trust for a given user or set of users can cause the depth of access and visibility of network services to be dynamically changed. The VPN server may dynamically adjust or change the trust level of the remote access according to the varying trust data related to the remote access of the user, thus providing a real-time adaptive security capability with the VPN.
In another embodiment, comparing, by the VPN server, the second trust level with the first trust level; and keeping, by the VPN server, the first VPN connection alive if the second trust level is higher than the first trust level, when the VPN server determines that the trust level of the remote access of the user may be increased according to the currently collected trust data, the VPN server shall allow the user to have remote access an access zone corresponding to the previous trust level and another access zone corresponding to the increased trust level simultaneously. In another embodiment, closing, by the VPN server, the first VPN connection if the second trust level is lower than the first trust level, when the trust level of the remote access of the user is decreased according to the currently collected trust data, the VPN Server shall allow the user to merely have remote access to the access zone corresponding to the currently decreased trust level. The remote access to the access zone corresponding to the previous trust level will be disabled due to the decreased trust level.
In another embodiment, monitoring, by the VPN server, a change of the trust data; determining, by the VPN server, a second trust level corresponding to changed trust data according to a third correspondence if the VPN server obtains the changed trust data, wherein the third correspondence comprises the changed trust data and the second trust level; determining, by the VPN server, a second access zone of the first network corresponding to the second trust level according to a fourth correspondence, wherein the fourth correspondence comprises the second trust level and the second access zone; modifying, by the VPN server, configuration of the first VPN connection so that the first VPN connection is changed into a second VPN connection between the device and the second access zone, when the trust data varies, the VPN is modified to include or exclude the appropriate access zones. For example, when the VPN server determines that the trust level is level 1, the VPN enable the VPN to include the first access zone, while when the VPN server determines that the trust level is level 2, the configuration of the first VPN connection is modified to enable the VPN to include the second access zone and/or exclude the first access zone.
Claim Objections
7. Claim 5 is objected to because of the following informalities: Claim 5 depends upon canceled claim 4. Appropriate correction is required.
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-3, 5-17, and 19-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, at a user device, a beacon from a network device, the beacon comprising a trust level of the network device, (See Weksler et al., para. 30, 74, 80, and 120-121, i.e., at a user device (i.e., computing device/servant beacon device) a beacon is received from a requesting network device (i.e. master beacon 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, at the user device, 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 at the user device (i.e., computing device/servant beacon 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 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 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 from the user device (i.e., computing device/servant beacon device)
Walker discloses and based on receiving the connection request: transmitting, from the network device, user data to the user device; (See Walker, para. 44-46, transmitting, from the network device (i.e., master beacon device) the connection request and receiving user data to the user device (i.e., computing device/servant beacon device) 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, at the network device, user data from the user device. (See Walker, para. 53, receiving, at the network device (i.e., master beacon device) second user data from the user device (i.e., computing device/servant beacon 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 from a user device (i.e., computing device/servant beacon device)
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 to the user device (i.e., computing device/servant beacon device)
Walker discloses or receiving second user data from the user device; (See Walker, para. 53, receiving second user data from the user device (i.e., computing device/servant beacon 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 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.
11. Claims 21-22 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).
The combination of Weskler et al., Walker, and Nenov discloses the invention as described above, however, none of the references disclose, teach, or suggest wherein the beacon further comprises a timestamp indicating a time point, the method further comprising: based on determining that the trust level of the network device satisfies the predetermined trust criterion, determining that the beacon is active by: determining that beacon is received, at the user device, within a threshold time period after the time point indicated by the timestamp, wherein the connection request is transmitted to the network device in response to determining that the beacon is active.
Robison et al. discloses a method and system for context and device state driven authorization for devices.
Referring to the rejection of claim 21, (Weksler et al., Walker, and Nenov modified by Robison et al.) discloses wherein the beacon further comprises a timestamp indicating a time point, the method further comprising: based on determining that the trust level of the network device satisfies the predetermined trust criterion, determining that the beacon is active by: determining that beacon is received, at the user device, within a threshold time period after the time point indicated by the timestamp, wherein the connection request is transmitted to the network device in response to determining that the beacon is active. (See Robison et al., para. 40, 43, 47, and 95)
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, Walker’s method for establishing a connection between a user device and an access zone, and 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 modified with Robison et al.’s method and system for context and device state driven authorization for devices.
Motivation for such an implementation would provide the capability to detect and evaluate the status of devices connected to a network environment and determine authorization levels based on context. (See Robison et al., para. 37)
Referring to the rejection of claim 22, (Weksler et al., Walker, and Nenov modified by Robison et al.) discloses wherein the first beacon further comprises a timestamp indicating a time point, and wherein the first beacon is active within a threshold time period after the time point. (See Robison et al., para. 40, 43, 60-64, 70-73, and 77-80)
The rationale for combining Weksler et al., Walker, Nenov in further view of Robison et al. is the same as claim 21.
Conclusion
12. Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to 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 August 6, 2026
/FATOUMATA TRAORE/Primary Examiner, Art Unit 2436
Prosecution Insights