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 .
Priority
This application claims the benefit of priority under 35 U.S.C. § 119(e) from Portugal Patent Application No. 118078, filed on Jul. 1, 2022, which is hereby incorporated by reference as if set forth in its entirety herein.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 02/20/2026 has been entered.
DETAILED ACTION
This Office Action is in response to a Request for Continued Examination (RCE) application received on 02/20/2026. In the RCE, claims 1, and 19 have been amended. Claims 2-18 remain original. No claim has been added and no claim has been cancelled.
For this Office Action, claims 1-19 have been received for consideration and have been examined.
Response to Arguments
Claim Rejections – 35 USC § 102
Applicant’s remarks in light of the amended claims have been reviewed, however, remarks are not found to be persuasive. After review, the remarks have been summarized as follows:
1. McDonald does not disclose that the countermeasure request is client-initiated; the counter measure request in McDonald is server-initiated and not client-initiated (Page # 7-13).
Examiner’s Response
Regarding above remark that McDonald counter measure request is server-initiated and not client-initiated, to which examiner respectfully disagree. McDonald extensively teaches the initiation of counter-measure by the client itself in response to identification of an unexpected event. McDonald discloses this concept in light of Figure. 10 in which an unexpected event has been identified by a mobile device and a user of the mobile device is prompted by the mobile device to provide some sort of verification of the unexpected event ([0267] FIG. 10 shows an example display of a mobile device according to an implementation. The mobile device 1000 may be configured for protection against malware as described herein; [0269] These steps may include monitoring a plurality of events executed on the mobile device such as any of the events described above, and detecting a first event in the plurality of events. The first event may be an unexpected event generated by an application executing on the mobile device 1000 while a user of the mobile device 1000 is not interacting with the application. The steps for securing the mobile device 1000 against malware may further include evaluating the first event in a context of the mobile device 1000 to determine whether the first event is potentially unauthorized. When the first event is a potentially unauthorized event, the steps for securing the mobile device 1000 against malware may include presenting a warning to the user that the potentially unauthorized event has occurred; [0270] The display 1002 may include a touch screen or other device for receiving user input that can be used to detect user presence or user interaction as contemplated herein. The camera 1010 or microphone 1012 may also be configured to detect and identify the user and receive user input indicating of user presence and/or interaction. In another aspect, the mobile device 1000 may include one or more buttons 1014 for receiving manual user input that can be used to generate user interaction events indicative of user interaction and presence; [0271] As shown in the exemplary display, security functionality has identified an unexpected event, in this case a request by application “BaddApp” to access the web site: ‘www.baddsite.com.’ The exemplary display requests user confirmation that the unexpected event be permitted to continue. In this way, the device can determine whether a user is aware of the activity and whether the activity is authorized; [0272] Another device, such as a gateway or another endpoint, identifies a potential or actual security threat. Using a heartbeat functionality on the mobile device, an instruction to the mobile device is communicated securely to request user the confirmation of activity on the mobile, device, another device or recognized by the another device (e.g., a gateway). In an aspect, the display may require authentication, or submission of authentication data such as a PIN, password, biometric information, etc. to confirm authorization).
Based on above explanation and citation, McDonald still teaches the amended claim language of where client device carries out the indicated particular countermeasure, to capture at the client device reaction data solving the challenge of the predetermined session-security challenge-response pair which corresponds to execution of the countermeasure at the client device, and send the reaction data to the server device during the online session.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 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.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1-19 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by McDonald., (US20190268302A1).
Regarding claim 1, McDonald discloses:
A method for securing an online client-server session between a client device (i.e., endpoint 602) and a server device (i.e., Gateway) by application (i.e., a remote health monitor 630) of at least a countermeasure comprising a predetermined session-security challenge-response pair (i.e., evaluate the status of the endpoint based on a preset procedures) ([0009] a method of operating a gateway includes connecting an endpoint to a data network through the gateway, detecting a network request by a process executing on the endpoint to a remote resource that presents a potential security risk, evaluating a status of the endpoint to determine whether a user is present at the endpoint, and executing a security measure in response to the network request when no user is detected at the endpoint [0188] FIG. 8 shows a process for verifying user presence on an endpoint. In general, a gateway or other network device may be configured to monitor endpoint behavior, and to determine user presence at the endpoint. The endpoint behavior may suggest compromise, e.g., malware or other endpoint compromise … The network device may request a verification of user presence at the endpoint. The network device may request authentication of the user at the endpoint. The network device may receive reports of user presence at the endpoint. The network device may access a record of events that took place at the endpoint to determine user presence. User verification may be implicit, based on local behavior such as keyboard or mouse activity, or application or operating system events, or the user verification may be explicit, such as where a notification is presented on a display of the endpoint requesting user confirmation to proceed; [0198] In some implementations, a response to the network request may be monitored and included in a determination of potential or actual security risk. For example, if a network request is an authentication request to another device, and the response to the authentication request is that the authentication request is determined to have failed, for example by monitoring a response to the request, the activity may be determined to be indicative of a potential or actual security risk), the method comprising the steps of:
the server device having a processor and being configured by code executing therein to collect client behavior pattern during the online session ([0006] In general, in an aspect, a gateway or other network device is configured to monitor endpoint behavior; [0189] As shown in step 802, the method 800 may include connecting an endpoint to a data network through a gateway; [0190] As shown in step 804, the method 800 may include detecting a network request at the gateway, the network request initiated by a process executing on the endpoint. The network request may, for example, include any of the network messages described herein, or any other network request. By way of non-limiting example, the network request may include a request for a download of an executable from a data network, a data upload, a text message, an instant message, an HTTP GET, an HTTP PUT request or other request to an address contained in a Uniform Resource Locator entered, e.g., in a browser or similar application, an FTP file transfer request, a request to login to another device on the same network or a different network, or any other manually or automatically generated network request);
the server device processor being further configured by code executing therein to mark[0006] In general, in an aspect, a gateway or other network device is configured to monitor endpoint behavior, and to request a verification of user presence at the endpoint under certain conditions suggesting, e.g., malware or other endpoint compromise; [0191] In some implementations, step 804 may refer specifically to the detection or other identification of potential or actual compromise. For example, an unusual network request, or a request that may be prohibited or restricted by policy may be detected. A network request may be identified in combination with other network activity or other events; [0198] In some implementations, a response to the network request may be monitored and included in a determination of potential or actual security risk. For example, if a network request is an authentication request to another device, and the response to the authentication request is that the authentication request is determined to have failed, for example by monitoring a response to the request, the activity may be determined to be indicative of a potential or actual security risk);
the client device having a processor and being configured by code executing therein to request a client-initiated countermeasure (i.e., client is asked by the mobile device to provide user confirmation) according to the pre-agreed client-server protocol ([0015] The method may also include evaluating the first event in a context of the mobile device to determine whether the first event is potentially unauthorized, and when the first event is a potentially unauthorized event, presenting a warning to the user on the mobile device that the potentially unauthorized event has occurred, and requesting user confirmation that the potentially unauthorized event be allowed to continue; [0269] The first event may be an unexpected event generated by an application executing on the mobile device 1000 while a user of the mobile device 1000 is not interacting with the application. The steps for securing the mobile device 1000 against malware may further include evaluating the first event in a context of the mobile device 1000 to determine whether the first event is potentially unauthorized.);
the server device processor being further configured by code executing therein to respond with an indication of a particular countermeasure to be carried out by the client device ([0201] For example, a request for user input may be presented as a pop-up window or other notification with text requesting a response. This may include a simple request such as “click here to continue,” or a more instructive narrative such as: “A potential security issue has been detected. Please click here to confirm that you requested the following network activity.”; [0269] The first event may be an unexpected event generated by an application executing on the mobile device 1000 while a user of the mobile device 1000 is not interacting with the application. The steps for securing the mobile device 1000 against malware may further include evaluating the first event in a context of the mobile device 1000 to determine whether the first event is potentially unauthorized);
the client device processor being further configured by code executing therein to carry out the indicated particular countermeasure, to capture at the client device reaction data solving the challenge of the predetermined session-security challenge-response pair which corresponds to execution of the countermeasure at the client device, and send the reaction data to the server device during the online session ([0267] FIG. 10 shows an example display of a mobile device according to an implementation. The mobile device 1000 may be configured for protection against malware as described herein; [0269] These steps may include monitoring a plurality of events executed on the mobile device such as any of the events described above, and detecting a first event in the plurality of events. The first event may be an unexpected event generated by an application executing on the mobile device 1000 while a user of the mobile device 1000 is not interacting with the application. The steps for securing the mobile device 1000 against malware may further include evaluating the first event in a context of the mobile device 1000 to determine whether the first event is potentially unauthorized. When the first event is a potentially unauthorized event, the steps for securing the mobile device 1000 against malware may include presenting a warning to the user that the potentially unauthorized event has occurred; [0270] The display 1002 may include a touch screen or other device for receiving user input that can be used to detect user presence or user interaction as contemplated herein. The camera 1010 or microphone 1012 may also be configured to detect and identify the user and receive user input indicating of user presence and/or interaction. In another aspect, the mobile device 1000 may include one or more buttons 1014 for receiving manual user input that can be used to generate user interaction events indicative of user interaction and presence; [0271] As shown in the exemplary display, security functionality has identified an unexpected event, in this case a request by application “BaddApp” to access the web site: ‘www.baddsite.com.’ The exemplary display requests user confirmation that the unexpected event be permitted to continue. In this way, the device can determine whether a user is aware of the activity and whether the activity is authorized; [0272] Another device, such as a gateway or another endpoint, identifies a potential or actual security threat. Using a heartbeat functionality on the mobile device, an instruction to the mobile device is communicated securely to request user the confirmation of activity on the mobile, device, another device or recognized by the another device (e.g., a gateway). In an aspect, the display may require authentication, or submission of authentication data such as a PIN, password, biometric information, etc. to confirm authorization); and
the server device processor being further configured to verify in real time the client device reaction data to the execution of the countermeasure, and if verified, to mark the online session as non-affected during the online session ([0208] As shown in step 808, when a user is determined to be present in step 806, other processing may be performed. This may include returning to step 804 where additional network requests may be detected; [0255] It will be understood that a variety of techniques are available for detecting user interaction, or more generally determining whether a user is currently using or interacting with a mobile device. In one aspect, user interaction may be directly detected or measured based on, e.g., button pushes, touch events or other touch screen interactions, and so forth. In another aspect, user interaction may be inferred based on whether a mobile device is screen locked or active … In another aspect, where media such as a video is playing, user interaction may be inferred even during prolonged periods without a user input. These or any other techniques suitable for explicitly or implicitly determining whether a user is interacting with a mobile device may be usefully employed to identify user interaction as contemplated herein. Thus in general, detection of user interaction may be based on time, input events, device status, or some combination of these. Where user interaction is uncertain and highly relevant, user presence may be confirmed, such as by presenting a window requesting confirmation of active use (e.g., “Your device is trying to transmit an unexpected SMS message. Can you confirm that you wish to send this?”) or by using a camera for facial recognition or tracking of eye movements; [0270] The display 1002 may include a touch screen or other device for receiving user input that can be used to detect user presence or user interaction as contemplated herein. The camera 1010 or microphone 1012 may also be configured to detect and identify the user and receive user input indicating of user presence and/or interaction. In another aspect, the mobile device 1000 may include one or more buttons 1014 for receiving manual user input that can be used to generate user interaction events indicative of user interaction and presence).
Regarding claim 18, it is a non-transitory computer-readable medium claim and recites similar subject matter as claim 1 and therefore rejected under similar ground of rejection.
Regarding claim 19, it is a system claim and recites similar subject matter as claim 1 and therefore rejected under similar ground of rejection.
Regarding claim 2, McDonald discloses:
The method according to claim 1, further comprising the steps of:
if the client reaction to a countermeasure is not verified, the client device requesting an additional client-initiated countermeasure according to the pre-agreed client-server protocol; the server device responding with an indication of a particular additional countermeasure to be carried out by the client device; the client device carrying out the indicated particular additional countermeasure and sending to the server device a reaction to the additional countermeasure; and the server device verifying the client reaction to the additional countermeasure, and if verified, marking the online session as non-affected ([0006], [0009], [0188-0191], [0200-0208]).
Regarding claim 3, McDonald discloses:
The method according to claim 1, wherein the pre-agreed client-server protocol comprises triggering the steps of marking and requesting a countermeasure when: a particular client behaviour pattern occurs during the online session ([0006] & [0014]); and/or a periodic time period occurs during the online session.
Regarding claim 4, McDonald discloses:
The method according to claim 3, wherein the client behaviour pattern includes at least one selection from the group consisting of: an estimated security risk of illicit account takeover above a predetermined threshold; a particular device characteristic or characteristics; a particular user journey; a particular user interaction; a particular set of user interactions; and a lack of a particular user interaction ([0006] & [0014]).
Regarding claim 5, McDonald discloses:
The method according to claim 1, wherein the client device requesting a client-initiated countermeasure according to the pre-agreed client-server protocol is synchronized with predetermined online session events comprising login of the online session or window focus loss of the online session, or combination thereof ([0190]).
Regarding claim 6, McDonald discloses:
The method according to claim 1, wherein the particular countermeasure to be carried out by the client device is selected from a list consisting of: blackening screen capture by adjusting screen capture permissions; completing a challenge response, in particular comprising text-completion challenge, mouse movement challenge and/or image classification challenge ([0200-0201]); carrying out a two-factor authentication challenge; and logging out the online session.
Regarding claim 7, McDonald discloses:
The method according to claim 1, wherein the online client-server session is pre-authenticated ([0171]).
Regarding claim 8, McDonald discloses:
The method according to claim 1, wherein the server device marks the online session as an affected session according to a pre-agreed client-server protocol, without sending an indication of the affected status to the client ([0258]).
Regarding claim 9, McDonald discloses:
The method according to claim 1, wherein the online session is a client-server web session and the client device runs a web browser arranged to carry out the client device side of the method ([0190]).
Regarding claim 10, McDonald discloses:
The method according to claim 9, wherein the server-device is arranged to serve a web page comprising computer program instructions that, when run on the client device, cause it to carry out the client device side of the method ([0190]).
Regarding claim 11, McDonald discloses:
The method according to claim 1, wherein the online session is a client-server application session and the client device runs an application comprising an application library arranged to carry out the client device side of the method ([0190]).
Regarding claim 12, McDonald discloses:
The method according to claim 1, wherein an indication of sessions marked as affected are stored in a dynamic cache with a time-limited read period, or in a queue, or in a database ([0062], [0082], [0152], [0240]).
Regarding claim 13, McDonald discloses:
The method according to claim 12, further comprising providing a countermeasure service for the server device to respond with an indication of a particular countermeasure or countermeasures to be carried out by the client device, wherein said countermeasure service is a client-initiated polling service ([0062], [0168], [0209]).
Regarding claim 14, McDonald discloses:
The method according to claim 1, wherein a session marked as affected has a corresponding countermeasure or countermeasures stored in a countermeasure database ([0209]).
Regarding claim 15, McDonald discloses:
The method according to claim 14, wherein the countermeasure or countermeasures available for a session marked as affected are determined by one or more triggers at the server device when the online session is marked as an affected session according to the pre-agreed client-server protocol ([0062], [0168], [0209]).
Regarding claim 16, McDonald discloses:
The method according to claim 15, wherein one or more triggers are contained in a rule database where, for each rule, a corresponding countermeasure is enabled or disabled according to a predetermined condition or conditions ([0076-0080]).
Regarding claim 17, McDonald discloses:
The method according to claim 1, wherein communications between server device and client device are encrypted ([0124-0125]).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SYED M AHSAN whose telephone number is (571)272-5018. The examiner can normally be reached 8:30 AM - 6:00 PM.
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, William Korzuch can be reached at 571-272-7589. 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.
/SYED M AHSAN/Primary Examiner, Art Unit 2491