Detailed Action
1. This Office Action is responsive to the Amendment filed 07/17/2026. Claims 1-20 are presented for examination. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Information Disclosure Statement
2. The information disclosure statement (IDS) submitted on 07/07/2026 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 103
3. 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 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.
4. Claims 1-2 and 11-12 are rejected under 35 U.S.C. 103 as being unpatentable over DEL OJO ELLIAS et al. (WO 2013/079113 A1), in view of Jenkins et al. (US 9,009,334), hereinafter “ELLIAS” and “Jenkins”, correspondingly.
5. As to claim 1, ELLIAS discloses a method performed by at least one processor, said method comprising:
receiving a request for a remote browsing session, the request received from a first browser running on a client device ([0052] and [0122]: the user introduces the web page URL in his local (first) browser … In response to the client device is prompted to formally request an instance of a container in a Secure Browsing Server, which creates a Secure (remote) Browsing Instance);
allocating a remote browsing server based on the request ([0096]: when receiving the mentioned request, the Connection Manager chooses one of the Secure Browsing Servers to host the new environment and instructs it to create a new Secure Browsing Instance), the remote browsing server comprising a remote browsing connector and a second browser ([0052]: the request is routed to the Access Manager, which will deliver a Client Access Tool 220, being customized for one specific session, to the user’s device 110. At the same time, the Secure Browsing Server 320 hosted in the Secure Server System 210 creates one Secure Browsing Instance 330 (comprising Secure Remote Browser 335) assigned to the user as a browsing environment for the session and interacts with its corresponding Client Access Tool 220), and causing the first browser to connect to the second browser via the remote browsing connector such that a video stream of renderings of the second browser are displayed on the first browser ([0052]: A Secure Browser 335, executed inside the Secure Browsing Instance 330, fetches, retrieves and renders, the contents of the destination web site following the usual process, as if it were hosted in the end user’s computing device 110. Once rendered, the web page contents are sent to the Client Access Tool 220 as images, for display on the user’s device display) and user input from the first browser is transmitted to the second browser ([0132]: Keyboard and mouse events are transmitted to the Secure Remote Browser to process them and update the display).
ELLIAS does not explicitly disclose “determining whether an internet protocol address associated with the request is whitelisted; if the internet protocol address associated with the request is not on a whitelist of internet protocol addresses, allocating a remote browsing server based on the request; if the internet protocol address associated with the request is on the whitelist of internet protocol addresses, causing the first browser to open a webpage associated with the internet protocol address”.
In an analogous art, Jenkins discloses “determining whether an internet protocol address associated with the request is whitelisted” (col. 33, lines 19-20: determine whether the requested network resource has been blacklisted); if the internet protocol address associated with the request is not on a whitelist of internet protocol addresses, allocating a remote browsing server based on the request (col. 32, line 66 – col. 33, line 3: the blacklist includes instructions regarding how a particular blacklisted site is to be handled. For example, each time an email provider is accessed, the browse session is to enter remote browsing mode in order to avoid common email related high risk operation); if the internet protocol address associated with the request is on the whitelist of internet protocol addresses, causing the first browser to open a webpage associated with the internet protocol address” (col. 33, lines 27-31: if the web site has not been blacklisted, retrieving the resource and then proceeds to block 1316 to transmit the requested web site to the client computing device 102).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Jenkins and ELLIAS to achieve the claimed invention to enable the system to determine that the requested resource is not likely to perform a malicious or otherwise high risk operation on the client computing device (Jenkins, col. 32, lines 38-41).
6. As to claim 11, claim 11 is a corresponding remote browsing administrator device claim that recites similar limitations as of method claim 1; therefore, it is rejected under the same rationale.
7. Claims 2-5, 8-9, 13-15 and 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over ELLIAS-Jenkins, in view of Winn et al. (US 2013/0212680 A1), hereinafter “Winn”.
8. As to claim 2, ELLIAS-Jenkins teaches the method of claim 1, but does not explicitly disclose “retrieving the whitelist of Internet Protocol addresses from a whitelist database”.
In an analogous art, Winn teaches “retrieving the whitelist of Internet Protocol addresses from a whitelist database” (Fig. 4 and [0037]: communicate with one or more data stores 408 to read and/or update one or more blacklists 410 and/or whitelists 412 stored therein).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of ELLIAS-Jenkins and Winn to achieve the claimed invention to record, notify or alert user and/or system administrator of detected security breaches or threats, restrict the network traffic from rogue entities, change security settings or network configurations and the like (Winn, [0033]).
9. As to claim 3, ELLIAS-Jenkins-Win teaches the method of claim 2, wherein the whitelist database is associated with the remote browsing server” (Win, [0035]: blacklists 320 and/or whitelists 322 may include static and/or dynamic lists which may be provided and/or configured by a user, a system administrator, a service provider or the like).
10. As to claim 4, ELLIAS-Jenkins-Winn teaches the method of claim 2, wherein the whitelist database is associated with the client device (Win, [0035]: blacklists 320 and/or whitelists 322 may include static and/or dynamic lists which may be provided and/or configured by a user, a system administrator, a service provider or the like).
11. As to claim 5, ELLIAS-Jenkins-Winn teaches the method of claim 2, wherein the whitelist database is provided by a third party (Win, [0035]: update to the black/white lists may come from administrator servers, third-party service providers and the like).
12. As to claim 8, ELLIAS-Jenkins-Winn teaches the method of claim 1, further comprising: receiving, from the first browser running on the client device, user input indicating that a webpage opened by the first browser is not secure; and adding the internet protocol address associated with the webpage to a blacklist (Winn, Fig. 4 and [0041]: some of the data stored in the one or more data stores 408 (blacklist 410, whitelist 412, logs/reports 414 and rules/policies 416) may be provided by the user).
13. As to claim 9, ELLIAS-Jenkins-Winn teaches the method of claim 8, wherein, in response to the internet protocol address associated with the webpage being added to the blacklist of internet protocol addresses, the method comprises: causing the webpage to be opened by the second browser and the video stream of renderings from the second browser to be displayed via the first browser directly by the first browser (Jenkins, col. 30, lines 52-58: where the end user does not trust the source of the web site (i.e., the web site is in a blacklist), a method of loading and browsing web sites on a remote computing device while only viewing the browsing result on the client computing device 102; and col. 34, lines 24-29: provide a remote desktop connection to the instance of the browser application rendering the web site on the NCC POP 142, and in such a case the client computing device 102 will not receive the actual web site, but rather a view of the instance of the browser application executing on the NCC POP 142).
14. As to claims 12-15 and 18-19, claims 12-15 and 18-19 are corresponding remote browsing administrator device claims that recite similar limitations as of method claims 2-5 and 8-9; therefore, they are rejected under the same rationale.
15. Claims 6-7 and 16-17 are rejected under 35 U.S.C. 103 as being unpatentable over ELLIAS-Jenkins, in view of BEJERASCO et al. (US 2013/0212680 A1), hereinafter “BEJERASCO”.
16. As to claim 6, ELLIAS-Jenkins teaches the method of claim 1, but does not explicitly disclose “receiving, from the first browser running on the client device, user input indicating that a webpage opened by the second browser and being displayed via the video stream of renderings is secure; and adding the internet protocol address associated with the webpage to the whitelist of internet protocol addresses”.
In an analogous art, BEJERASCO discloses “receive a user indication to add the blocked web resources to a whitelist of allowed web resources via user input 25 of the user device 1. The user input 25 is used by the user to input information such as a selection of whether to add URL to a whitelist” ([0043]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of ELLIAS-Jenkins and BEJERASCO to achieve the claimed invention to allow authorized access to a webpage, mark an IP address as trusted, permit network traffic to and from that location.
17. As to claim 7, ELLIAS-Jenkins-BEJERASCO teaches the method of claim 6, wherein, in response to the internet protocol address associated with the webpage being added to the whitelist of internet protocol addresses the method comprises: causing the webpage to be opened directly by the first browser (BEJERASCO, [0043]: receive a user indication to add the blocked web resources to a whitelist of allowed web resources, and allow access to the web resource after receiving the user indication).
18. As to claims 16-17, claims 16-17 are corresponding remote browsing administrator device claims that recite similar limitations as of method claims 6-7; therefore, they are rejected under the same rationale.
19. Claims 10 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over ELLIAS-Jenkins, in view of Hill et al. (US 9,208,316 B1), hereinafter “Hill”.
20. As to claim 10, ELLIAS-Jenkins teaches the method of claim 1, but does not explicitly disclose “if the internet protocol address associated with the request is not on the whitelist of internet protocol addresses one or more types of user input are disabled”.
In an analogous art, Hill discloses “if the internet protocol address associated with the request is not on the whitelist of internet protocol addresses one or more types of user input are disabled” (Fig. 7E and col. 17, lines 1-7: when the phishing web site may be known and present in the blacklist 186, the input controls provided for entry of the user’s credit card number and expiration data has been disabled).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of ELLIAS-Jenkins and Hill to achieve the claimed invention to allow the system to detect and disable potentially harmful items that are embedded within or referenced by retrievable network resources such as web pages and other types of documents (Hill, col. 2, lines 29-32).
21. As to claim 20, claim 20 is a corresponding remote browsing administrator device claim that recites similar limitations as of method claim 10; therefore, it is rejected under the same rationale.
Response to Arguments
22. Applicant’s arguments, see pages 6-7 of the Remarks, filed 07/17/2026, with respect to the rejection(s) of claim(s) 1-2 and 11-12 under Rejection Under 35 USC 102(a)(1) have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of ELLIAS and Jenkins.
23. Further references of interest are cited on Form PTO-892, which is an attachment to this Office Action.
24. A shortened statutory period for reply to this action is set to expire THREE (3) months from the mailing date of this communication. See 37 CFR 1.134.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to QUANG N. NGUYEN whose telephone number is (571) 272-3886.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s SPE, KAMAL B. DIVECHA, can be reached at (571) 272-5863. The fax phone number for the organization is (571) 273-8300.
Information regarding the status of published or unpublished applications may be obtained from the Patent Center. Status information for unpublished applications 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 or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/QUANG N NGUYEN/
Primary Examiner, Art Unit 2453
Prosecution Insights