DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
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 06/22/2026 has been entered.
Claim Rejections - 35 USC § 103
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.
Claim(s) 1, 13 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kolam et al., US-20150143223-A1 (hereinafter “Kolam ‘223”) in view of Boodman et al., US-8407584-B1 (hereinafter “Boodman ‘584”).
Per claim 1 (independent):
Kolam ‘223 discloses: A method for detecting restricted cross-origin requests by a webpage, comprising:
receiving, by a processor, webpage data associated with the webpage;
determining, by the processor, a presence of cross-origin uniform resource locator (URL) data from the webpage data;
(FIG. 1, [0017], a web browser 102 (a processor) sends a request for a webpage to an origin server 104 (e.g., a web publisher, such as www.yahoo.com and www. cnn.com), and web browser 102 receives the content corresponding to the webpage (receiving webpage data associated with the webpage) through a network 106; FIG. 3, [0022], the webpages of a website may be hosted on multiple domains ... from the origin server 104 in domain 1 ... by domain 2 ... by domain 3 ... by domain 4 (domains 2-4 corresponds to cross-origin domains); [0023], The various domains ... determined by parsing the webpage ... As each URL includes its domain information (cross-origin uniform resource locator (URL) data), the domains of the image and video files can be determined by parsing their respective URLs – determining a presence of cross-origin uniform resource locator (URL) data from the webpage data);
determining, by the processor, whether the resource was restricted by the server by cross-origin resource sharing (CORS) security parameters; and
in response to determining that the resource was restricted by the CORS security parameters, selectively generating, by the processor, mitigation data to mitigate presentation of the restricted resource associated with the cross-origin URL data
(FIG. 3, [0024], A web browser security restriction known as the same-origin security policy prevents a web browser (the processor) from accessing resources on a domain (the server) that is not the origin domain of the website (determining whether the resource was restricted by the server). That is, any request from a website has to go to the same origin domain of the website and "cross-domain" requests, referring to a website accessing resources on a domain different from the website's origin domain, is normally denied (restricted) under the same-origin security policy; FIG. 10, [0037], the detection method 340 starts by sending a request for content (the restricted resource associated with the cross-origin URL data) from the parent browsing context (the processor) to the second domain (the server, which is presented by the cross-origin URL data) through the proxy server (342); [0038], Then at 344 ... the method determines whether the CORS authorization header (cross-origin resource sharing (CORS) security parameters; FIG. 4 and para [0028] illustrates an example of a CORS authorization header, in which the “access-control-allow-origin” parameter may specify one or more desired domains) is present in the response received. If the requested content is received from the second domain or if the CORS authorization header is present, then method 340 proceeds to send requests from parent browsing context to obtain resources from the second domain (346). If the requested content is not received or if the CORS authorization header is not present (in response to determining that the resource was restricted by the CORS security parameters), then method 340 employs the content delivery method (selectively generating, by the processor, mitigation data to mitigate presentation of the restricted resource) described above by embedding a first nested browsing context in the parent browsing context of the web browser and sending a sameorigin request for content from the first nested browsing context to the second domain through the proxy server (348); FIG. 7, [0033], the embedded nested browsing context is an inline frame (iframe) of the web browser ... the <iframe> element is used to direct the iframe to request resources from a cross-domain, as specified by the URL of the CORS resource. In some embodiments, attributes of the iframe may be set in such a way that some of the functions or features are disabled; for example, an attribute may be set to turn off visibility – even when a CORS authorization header is absent, an iframe enables a browsing context separate from the parent webpage to be established. Accordingly, cross-domain access validation may be performed within the nested browsing context, that is, mitigation data to mitigate presentation).
Kolam ‘223 does not disclose but Boodman ‘584 discloses: in response to cross-origin URL data being present, generating, by the processor, operating in a privileged security context, an independent request for a resource directly to a server associated with the cross-origin URL from the privileged security context;
(FIG., 3, [Col. 14], ll.19-58, the content script 306 (generating, by the processor, operating in a privileged security context, an independent request) may be written to examine any page loaded in the browser application 112 (the processor) for rendering within the browser window 108 in order to detect a presence of a specific type of content (e.g., a non-linked webpage, or an RSS feed) ... On the other hand, other portions associated with the parent extension files may be privileged ( e.g., may have access to privileged data and/or APIs) ... protected through the use of messages sent between a content script and its parent extension, that is, operating in a privileged security context; [Col. 15], ll. 11-33, while also keeping such privileged extension APIs isolated from the page 110 itself (operating in a privileged security context). For example, the messaging techniques of FIG. 3 may be used to grant access to cross origin requests by the content script (in response to cross-origin URL data being present) (specifically, as is known, "origin" in this context refers generally to the concept that page scripts of pages of a given site may cross-access one another (a server), while page scripts of different sites may not). In general, extensions may communicate with remote servers (a server) that are not in their respective origins (if crossoriginal permission is granted) – for a resource directly to a server associated with the cross-origin URL, and, using the methods of FIG. 3, the content script 306 also may do so (indirectly) by sending a message such as the message 314 (generating, by the processor, operating in a privileged security context, an independent request) to the parent extension 308 that asks the parent extension 308 to make the cross-origin request (in response to cross-origin URL data being present) on its behalf).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified Kolam ‘223 with the permitting of cross-origin communications through a privileged extension having appropriate cross-origin permissions, while isolating privileged extension capabilities from the webpage as taught by Boodman ‘584 because the system would enable controlled access to remote resources without directly exposing privileged capabilities to webpage scripts. Additionally, Boodman ‘584 is analogous to the claimed invention because it teaches providing stable, secure use of content scripts associated with browser extensions [FIG. 1A].
Per claim 13 (independent):
The limitations of the claim(s) correspond(s) to features of claim 1 and the claim(s) is/are rejected for the reasons detailed with respect to claim 1.
Per claim 20 (independent):
The limitations of the claim(s) correspond(s) to features of claim 1 and the claim(s) is/are rejected for the reasons detailed with respect to claim 1.
Claim(s) 2 and 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kolam ‘223 in view of Boodman ‘584 as applied to claims 1 and 13 above, and further in view of Fallows et al., US-20180007093-A1 (hereinafter “Fallows ‘093”).
Per claim 2 (dependent on claim 1):
Kolam ‘223 in view of Boodman ‘584 discloses the elements detailed in the rejection of claim 1 above, incorporated herein by reference.
Kolam ‘223 in view of Boodman ‘584 does not disclose but Fallows ‘093 discloses: The method of claim 1, wherein the cross-origin URL data includes a cross-origin URL, wherein the cross-origin URL includes at least one of a protocol, a path, and a port that is different than at least one of a protocol, a path, and a port associated with the webpage (FIG. 7, [0055], In response to a conventional page request 112, typically initiated by a user of the Web-browser client 52, a load page request is issued to an origin server 34; [0062], Thus, the specific cross-origin resource request (including the cross-origin URL data) from "http://retailer.com:80" (the webpage) to "ws://gateway.com:2750" (the cross-origin URL) for a service "/gwStockService" is determined acceptable. The request will be further supported by creation on demand by the gateway server 42 with the establishment of a TCP-based WebSocket connection to an actual service source "tcp:/ /target.com: 1330/stockService" provided, by way of example, by a remote target server 36 (the cross-origin URL includes at least one of a protocol, a path, and a port that is different than at least one of a protocol, a path, and a port associated with the webpage)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified Kolam ‘223 in view of Boodman ‘584 with the gateway server operating as an intermediary that receives and qualifies a cross-origin request from the Web-browser client and establishes a corresponding connection to a target server as taught by Fallows ‘093 because the system advantageously allows documents loaded by a client system to securely interoperate across different origins, and furthermore provides a secure communications path between the source and target origins [0036]. Additionally, Fallows ‘093 is analogous to the claimed invention because it teaches a cross-document messaging system 40 selectively allows documents loaded by a client system 32 to securely interoperate across different origins [0036].
Per claim 14 (dependent on claim 13):
Kolam ‘223 in view of Boodman ‘584 discloses the elements detailed in the rejection of claim 13 above, incorporated herein by reference.
The limitations of the claim(s) correspond(s) to features of claim 2 and the claim(s) is/are rejected for the reasons detailed with respect to claim 2.
Claim(s) 3-6 and 15-17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kolam ‘223 in view of Boodman ‘584 and Fallows ‘093 and Ben-Dor et al., US-10404662-B1 (hereinafter “Ben ‘662”).
Per claim 3 (dependent on claim 2):
Kolam ‘223 in view of Boodman ‘584 and Fallows ‘093 discloses the elements detailed in the rejection of claim 13 above, incorporated herein by reference.
Kolam ‘223 discloses: The method of claim 2, wherein the determining the presence of the cross-origin URL data comprises analyzing, by the processor, requested data from the webpage data to determine if any cross-origin uniform resource locators are recited (FIG. 1, [0017], a web browser 102 (the processor) sends a request for a webpage to an origin server 104 (e.g., a web publisher, such as www.yahoo.com and www. cnn.com), and web browser 102 receives the content corresponding to the webpage (receiving the webpage data) through a network 106; FIG. 3, [0022], the webpages of a website may be hosted on multiple domains ... from the origin server 104 in domain 1 ... by domain 2 ... by domain 3 ... by domain 4 (domains 2-4 corresponds to cross-origin domains represented by cross-origin uniform resource locators ); [0023], The various domains ... determined by parsing the webpage ... As each URL includes its domain information (for which the presence of the cross-origin uniform URL data is to be determined), the domains of the image and video files can be determined by parsing their respective URLs – analyzing requested data from the webpage data to determine if any cross-origin uniform resource locators are recited).
Kolam ‘223 in view of Boodman ‘584 and Fallows ‘093 does not disclose but Ben ‘662 discloses: wherein the independent request is generated to determine whether the resource is protected by security parameters ([Col. 4], ll. 1-20, CORS:
Due to restrictions posed by W3C (namely "CORS"=Cross-Origin-Resource-Sharing), a third-party JavaScript code can always be executed via <script src=" ... ">, but the actual code can only be accessed as a text if the third-party web-server allows for it - by sending the "Access-Control-Allow-Origin" HTTP header (security parameters) – determine whether the resource is protected by security parameters. So, when a third-party does not allow this, the Policy center can either allow it to execute un-instrumented, or to block it altogether, or alter it to go through the CORS-Proxy as described herein; [Col. 8], ll.8-29, device 101, 102 browser (generating the independent request through the VICE code) will automatically load the VICE computer code that was customized for device's 104 website. The VICE code on device101, 102 browser will then load the third-party code from the third-party servers 105, 106, and execute it while monitoring and preventing unwanted activity without the third-party's knowledge (i.e. the principle of "Evasion")).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified Kolam ‘223 in view of Boodman ‘584 and Fallows ‘093 with the VIDE code executing at the visitor’s browser to mediate the loading and execution of code received from third-party servers through an Access-Control-Allow-Origin header as taught by Ben 662 because the system would enable controlled access and instrumentation of the third-party code. Additionally, Ben ‘662 is analogous to the claimed invention because it teaches protecting a client device that is browsing a website from undesired actions of third-party software [ABSTRACT].
Per claim 4 (dependent on claim 3):
Kolam ‘223 in view of Boodman ‘584 and Fallows ‘093 and ‘Ben 662 discloses the elements detailed in the rejection of claim 3 above, incorporated herein by reference.
Kolam ‘223 discloses: The method of claim 3, wherein the webpage data includes HTML (FIG. 7, [0033], the embedded nested browsing context is an inline frame (iframe) of the web browser. FIG. 7 is a diagram illustrating an embodiment of an HTTP webpage 400 (the webpage data) containing the <iframe> element; see FIG. 7);
Per claim 5 (dependent on claim 3):
Kolam ‘223 in view of Boodman ‘584 and Fallows ‘093 and Ben ‘662 discloses the elements detailed in the rejection of claim 3 above, incorporated herein by reference.
Kolam ‘223 discloses: The method of claim 3, wherein the webpage data includes script code (FIG. 7, [0033], the embedded nested browsing context is an inline frame (iframe) of the web browser. FIG. 7 is a diagram illustrating an embodiment of an HTTP webpage 400 (the webpage data) containing the <iframe> element; see FIG. 7).
Per claim 6 (dependent on claim 2):
Kolam ‘223 in view of Boodman ‘584 and Fallows ‘093 discloses the elements detailed in the rejection of claim 2 above, incorporated herein by reference.
Kolam ‘223 discloses: The method of claim 2, wherein the determining the presence of the cross-origin URL data comprises analyzing, by the processor, at least one returned resource associated with the webpage data to determine if any cross-origin URLs are recited (FIG. 1, [0017], a web browser 102 (the processor) sends a request for a webpage to an origin server 104 (e.g., a web publisher, such as www.yahoo.com and www. cnn.com), and web browser 102 receives the content corresponding to the webpage (receiving the webpage data) through a network 106; FIG. 3, [0022], the webpages of a website may be hosted on multiple domains ... from the origin server 104 in domain 1 ... by domain 2 ... by domain 3 ... by domain 4 (domains 2-4 corresponds to cross-origin domains represented by cross-origin uniform resource locators ); [0023], The various domains ... determined by parsing the webpage ... As each URL includes its domain information (for which the presence of the cross-origin URL data is to be determined), the domains of the image and video files can be determined by parsing their respective URLs – analyzing at least one returned resource associated with the webpage data to determine if any cross-origin uniform resource locators are recited; FIG. 2, [0020], the HTML file (the webpage data) may include text, dependent resources, scripts, and the like. Examples of independent resources include images, videos, audio clips, and APIs. These dependent resources are resources that need to be separately transferred from origin server 104 or from other servers (at least one returned resource associated with the webpage data are determined to be from cross-origin URLs) to web browser 102. For example, as shown in FIG. 2, the list of dependent resources includes an image, which is stored at a location specified by an URL. To display the image on the webpage, web browser 102 sends a separate HTTP request message to the URL, and the image is returned in a separate HTTP response message from the URL (analyzing at least one returned resource to determine if any cross-origin URLs are recited)).
Kolam ‘223 in view of Boodman ‘584 and Fallows ‘093 does not disclose but Ben 662 discloses: wherein wherein the independent request mirrors semantics of a source request ([Col. 4], ll. 1-34, CORS: Due to restrictions posed by W3C (namely "CORS"=Cross-Origin-Resource-Sharing), a third-party JavaScript code can always be executed via <script src=" ... ">, but the actual code can only be accessed as a text if the third-party web-server allows for it - by sending the "Access-Control-Allow-Origin" HTTP header. So, when a third-party does not allow this, the Policy center can either allow it to execute un-instrumented, or to block it altogether, or alter it to go through the CORS-Proxy as described herein; CORS-Proxy: When a third-party's doesn't provide the "Access-Control-Allow-Origin" HTTP header for an HTTP request that returns JavaScript code, the Policy may instruct VICE to alter the URL so that the HTTP request goes to a dedicated "CORS-Proxy" web-server, which internally fetches the Java-Script code using the original URL ...Then, the CORS-Proxy returns the JavaScript code back to the browser - with no changes other than adding the "AccessControl-Allow-Origin" HTTP header (mirrors semantics of a source request): now the browser allows VICE to access the JavaScript as text; [Col. 8], ll.8-29, device 101, 102 browser (generating the independent request through the VICE code) will automatically load the VICE computer code that was customized for device's 104 website. The VICE code on device101, 102 browser will then load the third-party code from the third-party servers 105, 106, and execute it while monitoring and preventing unwanted activity without the third-party's knowledge (i.e. the principle of "Evasion")).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified Kolam ‘223 in view of Boodman ‘584 and Fallows ‘093 with the VIDE code executing at the visitor’s browser to mediate the loading and execution of code received from third-party servers through an Access-Control-Allow-Origin header specially by using a CORS-Proxy as taught by Ben 662 because the system advantageously applies a security policy when CORS access is restricted, selectively blocking the third-party resource or routing the request through the proxy.
Per claim 15 (dependent on claim 14):
Kolam ‘223 in view of Boodman ‘584 and Fallows ‘093 discloses the elements detailed in the rejection of claim 14 above, incorporated herein by reference.
The limitations of the claim(s) correspond(s) to features of claim 3 and the claim(s) is/are rejected for the reasons detailed with respect to claim 3.
Per claim 16 (dependent on claim 15):
Kolam ‘223 in view of Boodman ‘584 and Fallows ‘093 and Ben ‘662 discloses the elements detailed in the rejection of claim 15 above, incorporated herein by reference.
The limitations of the claim(s) correspond(s) to features of claims 4-5 and the claim(s) is/are rejected for the reasons detailed with respect to claims 4-5.
Per claim 17 (dependent on claim 14):
Kolam ‘223 in view of Boodman ‘584 and Fallows ‘093 discloses the elements detailed in the rejection of claim 14 above, incorporated herein by reference.
The limitations of the claim(s) correspond(s) to features of claim 6 and the claim(s) is/are rejected for the reasons detailed with respect to claim 6.
Claim(s) 7-8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kolam ‘223 in view of Boodman ‘584 and Fallows ‘093 and Ben ‘662 and Krishnan, US-20230362160-A1 (hereinafter “Krishnan ‘160”).
Per claim 7 (dependent on claim 6):
Kolam ‘223 in view of Boodman ‘584 and Fallows ‘093 and Ben ‘662 discloses the elements detailed in the rejection of claim 6 above, incorporated herein by reference.
Kolam ‘223 in view of Boodman ‘584 and Fallows ‘093 and Ben ‘662 does not disclose but Krishnan ‘160 discloses: The method of claim 6, wherein the analyzing comprises analyzing metadata of the returned resource (FIG. 1, [0121], the preauthorization data 106 may identify one or more HTTP methods that are allowed to be used to access the resource(s) 110 at the first origin 115. HTTP defines methods to indicate the desired action to be performed on the identified resource. Examples of HTTP methods include: ... HEAD method (to retrieve metadata for an indicated resource without a representation/copy of the indicated resource) – analyzing metadata of the returned resource).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified Kolam ‘223 in view of Boodman ‘584 and Fallows ‘093 and Ben ‘662 with the authorization of cross-origin HEAD request to retrieve metadata associated with a resource without transferring a representation of the resource as taught by Krishnan ‘160 because the technique may reduce unnecessary data transfer and CORS preflight overheard, thereby improving network efficiency and responsiveness. Additionally, Krishnan ‘160 is analogous to the claimed invention because it teaches a system using Cross-Origin Resource Sharing (CORS) preauthorization data for enabling access to cross-origin resources [0007].
Per claim 8 (dependent on claim 7):
Kolam ‘223 in view of Boodman ‘584 and Fallows ‘093 and Ben ‘662 and Krishnan ‘160 discloses the elements detailed in the rejection of claim 7 above, incorporated herein by reference.
Kolam ‘223 discloses: The method of claim 7, wherein the returned resource comprises at least one of HTML text, plain text, and a Json application ([0018], A webpage accessed by web browser 102 may be described by different markup languages, including Hypertext Markup Language (HTML), Extensible Markup Language (XML), and the like. The webpage may also be described by different scripting languages, including JavaScript Object Notation (JSON), and the like).
Claim(s) 9 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kolam ‘223 in view of Boodman ‘584 and Fallows ‘093 and Ben ‘662 and Krishnan ‘160 and KAUBE et al., US-20200053094-A1 (hereinafter “KAUBE ‘094”).
Per claim 9 (dependent on claim 7):
Kolam ‘223 in view of Boodman ‘584 and Fallows ‘093 and Ben ‘662 and Krishnan ‘160 discloses the elements detailed in the rejection of claim 7 above, incorporated herein by reference.
Kolam ‘223 in view of Boodman ‘584 and Fallows ‘093 and Ben ‘662 and Krishnan ‘160 does not disclose but KAUBE ‘094 discloses: The method of claim 7, wherein the metadata comprises a URL listed as at least one of a canonical and a short (FIG. 6, [0059], an example route discovery process 600 ... Using a known RID (indicated at S605), such as that identified in operation S405, operation S610 performs a lookup to locate a canonical resource metadata URL (a URL listed as at least one of a canonical and a short). Such canonical resource metadata may be found at the publisher's page for the article, and the URL for that page may be returned in response to the lookup ... if access to the resource is ensured, as determined in operation S640, the canonical resource URL is returned to the calling process (process 400)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified Kolam ‘223 in view of Boodman ‘584 and Fallows ‘093 and Ben ‘662 and Krishnan ‘160 with the route discovery process using a known resource identifier to location a canonical resource metadata URL as taught by KAUBE ‘094 because the system can efficiently locate an up-to-date resource and provide the canonical resource URL upon determining that the user has access rights to the resource. Additionally, KAUBE ‘094 is analogous to the claimed invention because it teaches the research browser plugin is configured to generate a one-click control and associate the one-click control with a resource locator (e.g., URL) of a selected document version [ABSTRACT].
Per claim 18 (dependent on claim 17):
Kolam ‘223 in view of Boodman ‘584 and Fallows ‘093 and Ben ‘662 discloses the elements detailed in the rejection of claim 17 above, incorporated herein by reference.
The limitations of the claim(s) correspond(s) to features of claims 7-9 and the claim(s) is/are rejected for the reasons detailed with respect to claims 7-9.
Claim(s) 10 and 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kolam ‘223 in view of Boodman ‘584 and Cohen, US-20240314168-A1 (hereinafter “Cohen ‘168”).
Per claim 10 (dependent on claim 1):
Kolam ‘223 in view of Boodman ‘584 discloses the elements detailed in the rejection of claim 1 above, incorporated herein by reference.
Kolam ‘223 in view of Boodman ‘584 does not disclose but Cohen ‘168 discloses: The method of claim 1, wherein the mitigation data includes notification that notifies a user of the restricted resource (FIG. 6-1, [0209], The link "https://vulnerable-website.com" may include a cross origin web element, such that executing the code for nested web element 6-102 (e.g., an iframe web element) may cause a browser application ( e.g., browser application 216 of FIG. 2) to fetch the cross origin web element from the vulnerable website domain; FIG. 6-3, [0247], the JavaScript agent is further configured to cause display, via the user interface, of a notification indicating a threat associated with the nested web element. A notification indicating a threat (notification that notifies a user of the restricted resource) associated with the nested web element may refer to a message or warning of a possible danger (e.g., to a computing resource or data, such as processing capacity, user data, or a connection)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified Kolam ‘223 in view of Boodman ‘584 with the browser detecting a cyber threat associated with a cross-origin nested web element and providing a notification thorough a user interface as taught by Cohen ‘168 because a user may be promptly warned of potentially malicious web content. Additionally, Cohen ‘168 is analogous to the claimed invention because it teaches a browser application (e.g., browser application 216 of FIG. 2) to fetch the cross origin web element from the vulnerable website domain [0209].
Per claim 12 (dependent on claim 1):
Kolam ‘223 in view of Boodman ‘584 discloses the elements detailed in the rejection of claim 1 above, incorporated herein by reference.
Kolam ‘223 in view of Boodman ‘584 does not disclose but Cohen ‘168 discloses: The method of claim 1, wherein the mitigation data includes flag data that associates a security flag with the webpage (FIG. 6-1, [0209], The link "https://vulnerable-website.com" may include a cross origin web element, such that executing the code for nested web element 6-102 (e.g., an iframe web element) may cause a browser application ( e.g., browser application 216 of FIG. 2) to fetch the cross origin web element (the webpage) from the vulnerable website domain; FIG. 6-3, [0249], to display a notification indicating a threat ... a notification may include information (flag data that associates a security flag with the webpage) specific to a threat, such as a type of threat (e.g., identification of a threat as a click-jacking threat, a computer virus threat, a ransomware threat, a computer resource takeover threat, a threat to user data), a source of the threat).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified Kolam ‘223 in view of Boodman ‘584 with the browser detecting a cyber threat associated with a cross-origin nested web element and providing a notification thorough a user interface including a type of threat and/or a source of the threat as taught by Cohen ‘168 because a user may be promptly warned of potentially malicious web content.
Claim(s) 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kolam ‘223 in view of Boodman ‘584 and Burriesci et al., US-20220255955-A1 (hereinafter “Burriesci ‘955”).
Per claim 11 (dependent on claim 1):
Kolam ‘223 in view of Boodman ‘584 discloses the elements detailed in the rejection of claim 1 above, incorporated herein by reference.
Kolam ‘223 in view of Boodman ‘584 does not disclose but Burriesci ‘955 discloses: The method of claim 1, wherein the mitigation data includes display restriction data that restricts the display of the restricted resource (FIG. 5, [0168], a method 500 of deploying countermeasures against unauthorized scripts interfering with the rendering of content elements on information resources ... the computing device can receive an information resource including content elements (BLOCK 503). The computing device can determine whether the information resource includes restricted code (BLOCK 506) (the restricted resource) ... If the rendered imaged includes restricted visual elements, the computing device can alter the image (BLOCK 545) (restricts the display of the restricted resource); [0169], The computing device can subsequently display the information resource (BLOCK 548) (display restriction data)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified Kolam ‘223 in view of Boodman ‘584 with the detection of restricted content at a multiple stages of a rendering process and selectively altering the restricted content before displaying as taught by Burriesci ‘955 because presentation of unauthorized content may be restricted while permitting authorized portions of the information resource to be rendered. Additionally, Burriesci ‘955 is analogous to the claimed invention because it teaches deploying countermeasures against unauthorized scripts interfering with the rendering of content elements on information resources [0168].
Claim(s) 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kolam ‘223 in view of Boodman ‘584 and Cohen ‘168 and Burriesci ‘955.
Per claim 19 (dependent on claim 13):
Kolam ‘223 in view of Boodman ‘584 discloses the elements detailed in the rejection of claim 13 above, incorporated herein by reference.
The limitations of the claim(s) correspond(s) to features of claims 10-12 and the claim(s) is/are rejected for the reasons detailed with respect to claims 10-12.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Ehrhart, US-20160034642-A1 – a cross-origin data representation system that obtains data from a cross-origin data provider and inserts the obtained data into a webpage for presentation to a user. The system thereby enables content originating from a different origin to be incorporated into and presented through the webpage.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SANGSEOK PARK whose telephone number is (571)272-4332. The examiner can normally be reached Monday-Friday 7:30-5:30 and Alternate Fridays 9:00 am-5: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, PHILIP CHEA can be reached at (571)272-3951. 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.
/SANGSEOK PARK/Primary Examiner, Art Unit 2499
Prosecution Insights